Glamsterdam: Reworking Ethereum’s Block Assembly Line

A date for the rehearsal

On October 16, 2026, the Ethereum Foundation gave Glamsterdam its next testnet milestone: Hoodi on October 26. Mainnet still has no activation date. For an ETH holder, this announcement requires no mainnet action. For the people running the test network, it marks a coordinated software change.^[1]

The schedule is already concrete in Hoodi’s merged configuration: epoch 132,352, corresponding to 17:42:48 UTC, with a gas-limit target of 200 million. Publishing that configuration prepares clients to follow the same rules at the same moment. It cannot tell us in advance whether the transition will succeed.^[2]

Give each job its own time

Ethereum nodes have to agree on a block and verify what its transactions do. EIP-7732, known as enshrined proposer-builder separation or ePBS, rearranges that work. A builder commits to an execution payload; the proposer includes that commitment, and the builder reveals the payload later. The protocol provides the payment mechanism between those roles.^[3]

The useful change is in the timetable. Consensus checks can happen before full execution validation. A committee reports whether the payload and its blob data arrived in time; that report does not itself certify that every transaction executed correctly. Execution still needs checking, but the workload can occupy more of the available time.^[3]

Give the inspectors a map

More time helps, but a node also needs to know which pieces of its database a block will touch. EIP-7928 adds block-level access lists: records of accessed accounts and storage locations, together with changes after transactions. A client can use this information to fetch data in parallel and organize transaction validation.^[4]

Think of several inspectors receiving the same parts list before work begins. The list saves discovery work; it does not make the inspection optional. The EIP requires checking the supplied list against execution. A block whose list is wrong fails validation. Parallel work must still produce the state required by the block’s transaction order.^[4]

Capacity has a storage bill

The scheduled gas limit is a budget for work measured in gas units. Different operations consume different amounts, so 200 million gas cannot be read as 200 million transactions. EIP-8261 lets the network schedule the target ahead of time. The number describes Hoodi’s planned settings, not an observed mainnet throughput result.^[6][2]

A larger budget also makes lasting database growth matter more. EIP-8037 raises and separately meters state-creation costs, including new accounts, storage and contract code. Capacity expansion therefore comes with changed resource accounting; it is not a uniform discount on every operation.^[7]

The Foundation’s repricing tests found contracts whose fixed gas assumptions need attention. Some cases can be addressed by supplying more gas; others require reviewing the contract’s logic. This is why a testnet milestone matters beyond its date: client teams and application developers can check how the new rules behave before a mainnet rollout.^[5]