Ethereum upgrade widens block-validation window to nine seconds
Glamsterdam will extend Ethereum’s block-validation timing from about two seconds to six–nine seconds; node operators are testing changes on the permissionless Platåberget testnet.
Node operators are rehearsing the Glamsterdam upgrade on the permissionless Platåberget testnet, where protocol changes expand the typical two-second block-validation critical path into a six- to nine-second window and add new block-building roles, timing rules and gas accounting.
Platåberget is maintained by ethPandaOps and launched on Aug. 13. The network has an open validator set and provides client-pair images, checkpoint sync tools and deposit flows so teams can test coordinated upgrades across both execution and consensus clients. The testnet will remain available until Glamsterdam reaches mainnet and focuses on client software, staking setups, builder onboarding and supporting infrastructure rather than general application testing.
The largest architectural change being tested is EIP-7732, the enshrined proposer-builder separation (ePBS). The proposal separates consensus-block validation from execution-payload validation, introduces staked builders and creates a Payload Timeliness Committee to report whether builders revealed payloads within required time windows. Under the proposed timing, the designated next proposer has six seconds to validate a payload, while other validators have nine seconds. Operators are testing builder onboarding, payload timing, fork-choice behavior and basic node uptime under those extended timing constraints.
Testing also covers EIP-7928, which adds block-level access lists that record the accounts and storage locations touched by a block. That map is intended to let clients parallelize disk reads, transaction validation, state-root calculation and state reconstruction. Any throughput gains from access lists will depend on each client’s implementation and how those clients use the dependency map to run tasks in parallel.
Other proposals on Platåberget include EIPs 2780, 8037 and 8038. Gas-accounting changes in those proposals require attention from application and infrastructure teams. Platåberget’s public page gives an 18,000-gas example for a plain ETH transfer. The EIP-2780 reference case instead totals 21,000 execution gas for a transfer to an existing externally owned account, composed of a 12,000 base charge, a 3,000 cold-recipient access charge and a 6,000 value charge.
State-related proposals assign 183,600 state gas for creating a new account and raise a storage write from 2,800 gas to 10,000 gas. Teams need to recheck hardcoded subcall gas amounts, cached fee estimates, refund-dependent flows and workloads that create accounts or write storage, including token mints, airdrops and factory-deployed contracts.
Platåberget includes tools to run fork-choice tests, builder onboarding and payload-timing tests under load, along with resources for checkpoint syncing and deposits. Operators run paired client releases-an execution client with a consensus client-to verify the new division of responsibilities in real-world scenarios. The rehearsal is intended to surface implementation differences and gas-accounting effects before Glamsterdam is deployed to mainnet.








