A 200M gas block that reaches a validator late is not capacity. It is a missed attestation, a stressed execution client, and eventually a reason for operators to centralize around the few stacks that can absorb the damage. The Ethereum Glamsterdam upgrade addresses that uncomfortable fact: layer-1 throughput can increase only when block construction, propagation, execution, and state accounting change together.
Glamsterdam combines the consensus-layer Gloas fork and the execution-layer Amsterdam fork, with a target in Q3 / H2 2026 and no exact mainnet slot announced. Its core package under Meta EIP-7773 includes EIP-7732 enshrined proposer-builder separation, EIP-7928 Block-Level Access Lists, EIP-8037 state creation gas repricing, and EIP-2780 resource-based intrinsic transaction gas. This is a protocol and infrastructure upgrade, not a token event: there is no ETH migration, and any request to “upgrade” or move ETH for Glamsterdam is a scam.
Glamsterdam is not a promise of free throughput. It is an attempt to make higher throughput measurable, schedulable, and expensive in the places where Ethereum has historically underpriced it.
Ethereum Glamsterdam Upgrade and ePBS: Repairing the Slot Timeline
Ethereum validators already use proposer-builder separation in practice. MEV-Boost, relays, and builders are common machinery for separating block construction from block proposal. The architectural weakness is plain: that machinery is off-protocol. A relay can be useful, but it should not be the load-bearing component for payment enforcement and payload coordination.
EIP-7732 makes the split protocol-native
Under EIP-7732, the proposer first selects a consensus block that commits to a builder bid. The execution payload arrives later in the 12-second slot. The protocol enforces payment by the winning builder, while a Payload Timeliness Committee, or PTC, attests that the payload was revealed within its required window. Relays can remain operational infrastructure, but they are no longer required to make the separation trustworthy.
Think of the slot as two linked pipelines, not one critical path. First, consensus data moves through the validator network and establishes the builder commitment. Then the execution payload gets its own delivery and validation period. Documentation from Ethereum.org and infrastructure operators puts the practical gain at an effective data-propagation window expanding from roughly 2 seconds to about 9 seconds. That margin is what a 200M gas ambition needs.
It doesn’t make execution free, and it doesn’t remove the need for good peering. It changes when validators must decide. A node can validate and attest to the consensus portion without waiting for every byte of a large execution payload under the old, narrow deadline. This is deliberately conservative performance engineering: preserve the 12-second slot and improve its internal scheduling rather than shrink the slot until geographic latency becomes the protocol’s dominant feature.
What validators should measure
Runbooks need explicit ePBS telemetry. Record proposer receipt time, builder-bid selection time, payload-reveal time, PTC attestation outcomes, engine API errors, and the fraction of slots where local validation finishes close to deadline. Correlate those events with peer count, packet retransmissions, CPU steal time, and execution-client garbage collection pauses. A simple “head slot is advancing” alert won’t expose a payload-timeliness problem until it becomes expensive.
My judgement: treating relays as permanently harmless convenience infrastructure is the wrong default. ePBS reduces relay dependence, but it adds consensus-critical timing paths inside client code. Operators should test delayed payload reveals and partial peer failures as seriously as missed block proposals. Complexity did not disappear. It moved to a more inspectable, protocol-defined location.
Block-Level Access Lists Turn Serial State Into Schedulable Work
EIP-7928, Block-Level Access Lists or BALs, provides the execution metadata that makes parallelism credible. A BAL is the set of addresses and state locations touched during block execution, including accounts that change and accounts merely read. It is not a transaction access list repeated at block scale. It is a post-execution description of the block’s actual state footprint.
The block header gains block_access_list_hash, the Keccak-256 hash of the RLP-encoded block access list. The BAL itself lives separately in the execution layer and travels through the Engine API as part of the ExecutionPayload, rather than being embedded in the block body. EIP-7928 measurements put the average compressed BAL at around 72.4 KiB. Its growth is constrained by block gas, not a fixed number of list entries.
Why the data structure matters
Without advance knowledge of state touches, an execution client usually follows the safest pattern: execute transactions serially, discover reads and writes as they happen, then update state. BALs let a client prefetch relevant trie data, partition transactions whose accesses do not overlap, and spread post-state root calculation across cores. In practical terms, the payload enters the Engine API; BAL decoding creates a state-read plan; disk reads run concurrently; independent EVM work runs across workers; known state changes feed parallel hashing; and the resulting root is checked against the block commitment.
This also opens a more consequential path: executionless state updates. A synchronizing node can use BAL-provided state changes to apply transitions without replaying every transaction serially. Fast-sync and archival implementations may benefit substantially, though the operational proof burden remains high. State-root correctness is not a feature where “close enough” means anything useful.
payload -> Engine API -> decode BAL -> prefetch state
| |
| +-> conflict-aware EVM workers
+-> validate BAL and post-state values
workers -> parallel state hashing -> verify post-state rootBALs have costs. Builders must construct and encode them correctly. Execution clients need robust decoding, validation, cache management, and Engine API support. Larger working sets can trade serial disk stalls for higher RAM pressure and burstier NVMe reads. I’d rather see operators publish boring per-client BAL benchmarks than celebrate aggregate TPS-equivalent figures; the former shows where decentralized operation actually breaks.
On Platåberget, instrument BAL byte size, decode duration, prefetched read count, cache hit rate, worker utilization, conflict rate, and post-state hashing time. Compare batches with overlapping storage slots against batches whose account sets are intentionally disjoint. Parallel execution gains will depend on workload. A block full of popular AMM pools is not the same machine problem as a block of independent transfers.
Ethereum Glamsterdam Upgrade Gas Rules: Capacity With a State Bill
Ordered pathways visualize how block-level access lists can expose safe parallel work.
The public headline is a credible post-Glamsterdam 200M gas limit target, rising from roughly 60M gas today. The engineering constraint is underneath it: Ethereum cannot multiply execution capacity while keeping gas prices that treat durable state creation as a side effect. EIP-8037 and EIP-2780 make that constraint explicit.
EIP-8037 introduces state-gas
EIP-8037 defines CPSB, cost per state byte, and targets average state growth of 120 GiB per year at a reference block gas limit of 150M gas units. Its accounting includes values such as STATE_BYTES_PER_STORAGE_SET at 64 bytes and STATE_BYTES_PER_NEW_ACCOUNT at 120 bytes. The proposal separates execution-gas from state-gas: computation and ordinary operational work consume execution-gas, while durable state creation consumes state-gas.
The transaction pays the sum. EIP-2780 establishes a pre-execution phase after intrinsic-gas validation but before the first EVM frame, splitting supplied gas into gas_left and state_gas_reservoir. The EIP-7825 transaction gas limit applies only to execution-gas, while state-gas remains bounded by tx.gas. This reservoir model matters because state-dependent charges, including new-account creation and certain delegation costs, move out of a simplistic intrinsic-gas bucket and into metered runtime behavior.
EIP-2780 also replaces the historical flat 21,000 gas intrinsic transaction model with resource-based components for base transaction cost, account access, value writes, and logging overhead including the EIP-7708 transfer log. A standard ETH transfer to an existing account still totals 21,000 gas under current draft values. A zero-value transfer can land around 15,000 gas, while a self-transfer can be around 12,000 gas. Some simple transfers are described as up to 71% cheaper against older scenario-specific estimates. The visible price varies because the resource use varies.
Wallets and gas estimators can’t keep assuming every transfer has one familiar price. Test existing-account transfers, new-account transfers, zero-value calls, self-transfers, contract deployment, and storage writes separately. A transaction that creates an account now has a state bill. Underestimating it means failed user flows; overestimating everything means hiding the protocol’s intended efficiency signal.
200M gas is a vote, not a switch
Glamsterdam does not hard-code 200M gas at activation. Validators still signal the network gas limit through gas-vote behavior, and a gradual increase is the sensible operational path. Reports and devnet analyses describe up to 10,000 TPS-equivalent throughput for suitable workloads, but TPS-equivalent is not a stability metric. Propagation delay, reorg behavior, payload timeliness, disk queue depth, and state growth decide whether a higher limit is safe.
Higher gas without state repricing would push storage costs onto future node operators. EIP-8037 does not solve every long-term state-management question, but it clearly corrects an old incentive mismatch. Applications that create state casually should read it as a protocol-level price signal, not an obscure accounting detail.
Platåberget Testnet: A Glamsterdam Readiness Lab
The Platåberget testnet was announced by the Ethereum Foundation as a short-lived, permissionless public network scheduled to fork to Glamsterdam on 20 August 2026 and remain available for a few months. It is useful middle ground between tightly controlled devnets and longer-running testnets such as Sepolia and Hoodi. Teams can join, break their own assumptions, and report results before those assumptions become mainnet incidents.
The planned network uses around 50,000 validators across roughly 50 nodes and exercises varied client combinations. Execution clients listed for Glamsterdam-devnet-8 include Besu, Geth, Erigon, Nethermind, Reth, Nimbus-EL, and Ethrex. The fork includes ePBS, BALs, state-gas repricing, transfer rules for new accounts, smart-contract size limits raised from 24 KiB to 64 KiB, and initcode limits increased from 48 KiB to 128 KiB.
Build a staging cluster that resembles production rather than a single happy-path container. Pair your selected consensus and execution clients, preserve realistic NAT and firewall rules, and export metrics into Prometheus, Grafana, and ELK. Kubernetes, Nomad, and Docker Compose all work for the control plane; bare metal remains useful when you need honest NVMe and network behavior. The point is repeatability, not orchestration fashion.
Use four test families: sustained existing-versus-new-account transfers; deployments close to the 64 KiB contract limit; storage-heavy workloads that force state-gas consumption; and transaction storms with both high account overlap and deliberately disjoint access patterns. Inject packet loss, delayed payload reveals, constrained disk IOPS, and CPU contention. Record missed attestations and execution latency alongside application-level failures. A validator can look healthy while a wallet’s gas model is quietly wrong.
The May 2026 interop event in Svalbard, Norway, hardened Glamsterdam devnets around ePBS stabilization, the 200M gas limit floor, and EIP-8037 repricing values. Platåberget is not a decorative preview network. It is where client interoperability, operating procedures, and application assumptions should be tested under shared rules.
Capacity, Decentralization, and the Operator’s Real Decision
Solana offers a useful contrast without requiring a tribal argument. Its official changelog reported testnet slot times reduced from 300ms to 250ms as of the 13 August 2026 update, following work toward 200ms slots from prior 400ms operation. Agave also changed snapshot intervals from 100 slots to 200 slots. Solana pursues performance with short slots, a highly parallel runtime, and assertive hardware assumptions.
Ethereum’s Glamsterdam upgrade keeps the 12-second slot and tries to use more of it: ePBS widens the payload-propagation window, BALs expose parallel work, and state-gas charges for persistent resource consumption. That design fits Ethereum’s aim of retaining broad validator participation. It also means operators cannot wave away hardware requirements. More CPU cores, ample RAM, high-throughput SSD or NVMe storage, and stable network links are becoming baseline planning concerns.
There is real centralization pressure here. Larger blocks and more client complexity favor teams with stronger hardware, deeper observability, and more time to test. Pretending otherwise would be unserious. The countermeasure is not freezing the protocol at 60M gas; it is demanding efficient implementations, open benchmarking, shared operational tooling, and cautious gas-limit voting backed by public evidence. It’s fine for a prototype, not for a fleet, to raise limits without that evidence.
Preparing for higher capacity remains an operational discipline: measure, test, and protect resilience.
The concrete takeaway is straightforward: before mainnet has a Glamsterdam slot, run your client pair on Platåberget, measure its ePBS deadlines, characterize BAL processing, and audit every gas estimator that assumes 21,000 means what it used to mean. The open question is sharper: when the network votes toward 200M gas, will your node be verifying a block—or merely hoping it arrives in time?