Ethereum’s next major upgrade cycle is now focusing on Glamsterdam, a protocol package anticipated to shape the network’s post-Pectra scaling and block-production strategy. The upgrade is under close scrutiny as it addresses two of Ethereum’s most significant and enduring limitations: the identity of block producers and the extent of execution capacity that the base layer can reliably accommodate. Developer materials and EIP discussions highlight enshrined proposer-builder separation and block-level access lists as two of the most significant topics in the Glamsterdam conversation. Together, they assist in outlining a longer-term trajectory aimed at increased throughput, avoiding the simplistic approach of requiring every node operator to take on additional load without implementing structural modifications.
EIP-7732, often referred to as enshrined proposer-builder separation, aims to integrate a portion of the existing external block-building market into the architectural framework of Ethereum’s protocol. Currently, block construction frequently relies on external relay infrastructure and specialised participants. The system has facilitated the network’s management of maximum extractable value; however, it has simultaneously sparked apprehensions regarding centralisation and the potential for censorship pressure. By advancing proposer-builder separation towards the protocol layer, Ethereum developers aim to diminish dependence on off-protocol arrangements and establish a clearer distinction between validators who propose blocks and builders who assemble them. It represents a technical modification, yet it directly addresses the objectives of decentralisation inherent to Ethereum.
EIP-7928, which addresses block-level access lists, seeks to enhance execution predictability by pinpointing state access patterns at the block level. In straightforward terms, validators and clients could obtain improved insights regarding the requirements a block must fulfil prior to its processing. That is significant because parallel execution becomes challenging when the system lacks knowledge about which transactions are prone to conflict. If block-level access lists function as designed, they may assist Ethereum in managing increased activity without transforming each block into a more cumbersome and less predictable load for nodes. That is why the proposal is frequently examined in conjunction with elevated gas-limit objectives and more extensive Layer 1 scaling initiatives. The most attention-grabbing aspect of the Glamsterdam narrative is the potential trajectory toward a 200 million petrol limit.
Such an enhancement would signify a substantial escalation from the current base-layer capacity and would indicate a markedly distinct Ethereum L1, provided it can be realised securely. However, the phrasing is significant: this serves as a roadmap and testing objective, rather than a promise that every aspect is finalised for mainnet precisely as outlined in the existing devnet documentation. Ethereum upgrades typically undergo a protracted sequence involving specification, client implementation, development networks, testing networks, and ultimate coordination. That process is intentionally slow. Glamsterdam holds significance as it illustrates the network’s ongoing efforts to enhance the base layer, rather than merely directing activity towards rollups. The risk lies in the potential for aggressive capacity increases, which, if not accompanied by meticulous client and node management, could undermine the decentralisation attributes that Ethereum aims to safeguard.