Glamsterdam activates on Hoodi on October 26 at 17:42:48 UTC. The testnet’s gas limit will rise to 200 million, matching Sepolia. ePBS and block-level access lists aim to make larger blocks p
Ethereum will raise the Hoodi testnet’s block gas limit to 200 million on October 26, putting its Glamsterdam upgrade through a demanding test of block production, transaction validation and smart-contract execution.
The Ethereum Foundation confirmed that the upgrade will activate at 17:42:48 UTC, at epoch 132,352 and slot 4,235,264. Hoodi will adopt the same gas-limit configuration introduced on Sepolia on October 6.
The larger blocks are only part of the story. Glamsterdam changes how Ethereum builders deliver blocks, how execution clients identify transaction dependencies and how the network charges for expensive state operations.
Those changes are closely connected. Increasing the amount of gas available per block is relatively straightforward. Ensuring that ordinary nodes can verify the additional execution work quickly enough is considerably harder.
Glamsterdam attempts to address both sides of that problem.
A block gas limit represents the maximum amount of execution work Ethereum permits within a block. It does not specify how many transactions the network can process.
At 200 million gas, a block could theoretically accommodate approximately 9,523 basic ETH transfers, assuming each consumes 21,000 gas. At Ethereum’s nominal 12-second slot interval, that works out to roughly 794 transfers per second.
This is a simplified calculation, not a throughput benchmark.
Real blocks contain contract deployments, token swaps, lending operations and other transactions with different resource requirements. Glamsterdam also changes gas accounting, making comparisons based solely on the 21,000-gas transfer misleading.
More importantly, node performance imposes a practical constraint.
Larger blocks require clients to process more execution work, access more blockchain state and agree on the resulting state changes. If those tasks exceed the time available, validators risk falling behind even when the protocol permits the block size.
Glamsterdam addresses the problem through two complementary changes: additional time for execution validation and greater opportunities to process work in parallel.
EIP-7732 introduces enshrined proposer-builder separation, or ePBS.
Ethereum already relies heavily on specialized block builders. Under the existing model, validators can use external infrastructure such as MEV-Boost and relays to receive bids from builders competing to construct profitable blocks.
ePBS incorporates the proposer-builder arrangement into Ethereum’s consensus rules.
A proposer can commit to a builder’s execution payload before the builder reveals its contents. The protocol manages the associated payment, while a payload timeliness committee helps determine whether the builder delivered the payload and associated blob data on time.
The change also separates consensus validation from execution validation, providing additional time to check the execution payload.
That is particularly relevant as blocks become more demanding to process.
However, ePBS does not eliminate the economics of maximal extractable value, or MEV. Builders will still compete to assemble transactions, and specialized infrastructure may retain advantages in latency, capital and order flow.
The upgrade changes how that market interacts with Ethereum’s protocol. It does not guarantee that block production will become more decentralized.
For validators, the operational implications are immediate. Client teams must implement new duties and interfaces, while operators using external builder infrastructure need compatible software before the fork.
The second major change, EIP-7928, introduces block-level access lists, or BALs.
Ethereum transactions frequently read or modify accounts and storage slots. Determining those dependencies during execution can force clients to perform work sequentially.
BALs provide a record of the accounts and storage locations accessed during a block, together with relevant post-transaction state changes.
With that information, execution clients can prepare state reads in parallel, identify transactions that can be validated concurrently and compute state roots more efficiently.
For example, two transactions interacting with unrelated storage locations may be processed independently. Transactions that modify the same state still require correct ordering and conflict handling.
The improvement therefore depends on the transaction mix.
A block containing many independent operations offers more opportunities for parallel processing than one dominated by transactions competing to update the same contracts.
Implementation quality also matters. The Ethereum Foundation describes BALs as infrastructure for more efficient validation, not proof that every execution client will achieve identical performance.
Together, ePBS and BALs are intended to make the larger execution budget manageable without requiring all nodes to adopt substantially more powerful hardware.
Glamsterdam also changes the cost of using Ethereum’s execution resources.
EIP-8037 increases and separately meters the cost of creating persistent state, including new accounts, storage slots and deployed contract code.
EIP-8038 updates charges for accessing state through operations such as SLOAD, SSTORE and cold account access.
These changes address a different scaling constraint: the long-term burden of maintaining Ethereum’s expanding state.
A transaction that creates persistent storage imposes costs beyond its immediate execution. Nodes must retain and access that data in the future.
The Ethereum Foundation’s August 24 repricing analysis explains that the new schedule was developed around performance targets supporting roughly three times the previous base-layer throughput.
That is a design target, not a measured guarantee of post-upgrade capacity.
The Foundation also replayed historical mainnet transactions under the proposed pricing rules to identify compatibility problems.
Its findings suggest that most contracts would remain unaffected. Some transactions would require higher gas limits, while a smaller group of contracts could fail because their logic depends on assumptions about gas consumption.
The highest-risk patterns include fixed gas stipends, hardcoded gas values in external calls and contract logic that changes behavior according to gasleft().
For developers, these are concrete compatibility concerns rather than theoretical changes to Ethereum’s fee market.
The Ethereum Foundation has published practical resources for teams preparing for Glamsterdam.
Smart-contract developers can check contract addresses using the Glamsterdam Repricing Impact Tool. The tool identifies contracts flagged by historical transaction replay and explains the relevant failure modes.
Developers can also test affected contracts on the Platåberget development network, known as glam-devnet-8, which implements the revised gas schedule.
The Foundation recommends increasing gas limits where sufficient, reviewing fixed-stipend call patterns and checking applications that rely on hardcoded gas assumptions.
Wallet developers and RPC providers should update gas estimation. Cached constants based on the previous schedule could underestimate execution costs and cause transactions to fail.
Hoodi node operators must update both their execution-layer and consensus-layer clients before the activation.
The Foundation’s official compatibility table lists Hoodi-ready releases, including Prysm v7.3.0, Teku 26.10.1, Lighthouse v8.3.0, Besu 26.10.0 and Nethermind 2.2.0.
Operators should verify their exact client versions against the maintained release list, as compatibility information may change.
Validators also need to review client-specific instructions covering ePBS duties, builder connections and gas-limit configuration.
There is no universal configuration flag that applies to every Ethereum client. Using an incompatible release or outdated validator setup could prevent a node from following the upgraded Hoodi chain.
Ordinary ETH holders and Ethereum mainnet users do not need to take action for this testnet activation.
Sepolia’s October 6 activation provided an earlier public test of Glamsterdam’s protocol changes. Hoodi will add another deployment environment while adopting the 200 million gas configuration.
Successful activation would demonstrate that participating clients can coordinate the fork and continue operating under the new rules.
Performance is a separate question.
Developers still need evidence that execution clients can process demanding blocks consistently, that builders deliver payloads reliably and that validators maintain acceptable performance across different workloads.
The Hoodi deployment should also help expose incompatibilities in contract execution, gas estimation and external block-building infrastructure.
The Ethereum Foundation has not announced a mainnet activation date.
For Ethereum’s scaling roadmap, the decisive evidence will come from sustained client performance rather than the gas-limit setting itself. A 200 million gas ceiling expands what the protocol permits. Glamsterdam’s validation changes must demonstrate how much of that capacity the network can safely use.
The post Ethereum’s 200M Gas Test Puts Glamsterdam’s Scaling to the Test appeared first on ETHNews.
