Ethereum’s Glamsterdam upgrade launched on the Sepolia testnet at 1:53 pm UTC on Tuesday, marking a critical rehearsal before mainnet activation. The update focuses on advancing layer-1 scaling through enshrined proposer-builder separation (ePBS) and block-level access lists (BALs), alongside gas pricing adjustments that better reflect execution costs. These changes aim to improve network throughput by enabling parallel processing of transactions and state validation, moving away from Ethereum’s current single-lane mode.
The upgrade includes EIP-7732, which separates block proposers from builders and consensus validation from execution validation, allowing validators more time to process payloads. EIP-7928 introduces enforced block-level access lists to record accessed accounts and storage locations, facilitating efficient parallel state reading and root computation. The Ethereum Foundation previously established a 200 million gas limit floor for Glamsterdam, a significant increase from the current limit of approximately 60 million. Following this testnet launch, developers will determine activation dates for the Hoodi testnet and subsequently the mainnet. Post-Glamsterdam, work begins on the Hegotá upgrade, with 66 proposals under review as of August.
The deployment of Glamsterdam on Sepolia signals a structural shift in Ethereum’s consensus and execution layers, prioritizing throughput efficiency without immediately raising the gas limit. By implementing enshrined proposer-builder separation and block-level access lists, the protocol addresses bottlenecks inherent in single-lane transaction processing. This technical evolution is designed to harden the layer-1 infrastructure while supporting greater scalability, positioning Ethereum to handle increased institutional and retail demand more effectively.
From an operational risk perspective, the transition to parallel processing and new validation timelines requires rigorous testing across subsequent testnets like Hoodi before mainnet activation. The substantial jump to a 200 million gas limit floor indicates aggressive performance targets, but also necessitates careful monitoring of client stability and network resilience. Developers must ensure that these architectural changes do not introduce vulnerabilities or consensus failures during the final stages of rollout.
