Ethereum’s Glamsterdam Rehearsal: Scaling Becomes a Coordination Problem

Glamsterdam turns block production into a staged pipeline: commit, reveal, map state access, then validate with more time and parallelism. Editorial illustration, 18 October 2026.

Executive summary

Ethereum’s next upgrade is best understood not as a single increase in throughput, but as a redesign of the constraints that have kept Layer 1 capacity scarce. Glamsterdam activated on the Sepolia testnet on 6 October. On 16 October, the Ethereum Foundation scheduled its next public rehearsal for Hoodi at 17:42:48 UTC on 26 October, together with a Hoodi gas-limit increase to 200 million. Mainnet has no decided activation date. That distinction matters: the architecture is concrete enough to assess, but its production readiness and ultimate capacity remain hypotheses under test.

The upgrade joins three mechanisms. Enshrined proposer-builder separation, or ePBS, moves the exchange between block proposers and specialized builders into Ethereum’s consensus rules and separates the consensus block from the later execution-payload reveal. Block-level access lists, or BALs, record which accounts and storage locations a block touches and how state changes after transactions, enabling clients to prepare data and perform more validation work in parallel. Gas repricing raises and separates charges for creating and accessing persistent state so that a larger gas limit does not silently become an uncontrolled subsidy to database growth.

The thesis of this report is that Glamsterdam is a bid to make scale safe by changing the choreography of verification, not merely by raising a ceiling. ePBS buys time; BALs expose dependencies; repricing protects the resource base. None alone delivers durable scale. Together they could make substantially larger blocks practical while keeping verification within reach of independent operators. They also create new protocol complexity, shift latency semantics, formalize the builder role and break a small class of applications built around fixed gas assumptions. The investable or operational signal is therefore not the advertised gas limit. It is whether diverse clients, validators and builders can execute this new pipeline reliably under adverse conditions.

What has happened—and what has not

The status is unusually important because “upgrade announced” is easily mistaken for “mainnet capacity delivered.” The Ethereum Foundation’s Hoodi announcement records Sepolia activation at epoch 353,024, slot 11,296,768 on 6 October, and schedules Hoodi at epoch 132,352, slot 4,235,264 on 26 October. It explicitly lists mainnet as TBD. The ethereum.org roadmap describes Q4 2026 as expected, not confirmed, and warns that although scope is frozen, the draft meta-EIP can still change before mainnet.

This sequence is a risk-control process. Sepolia gives application developers a live environment; Hoodi is designed around staking and validator testing; mainnet follows only after implementers judge the evidence adequate. Users and ETH holders need take no action for the Hoodi fork, while Hoodi node operators must update both execution and consensus clients. The proper analytical posture is therefore conditional: Glamsterdam has passed one public milestone, not its final examination.

timeline
    title Glamsterdam's evidence ladder
    6 Oct 2026 : Sepolia activation completed
               : Public client and application testing
    16 Oct 2026 : Hoodi schedule announced
    26 Oct 2026 : Hoodi activation scheduled
                : Gas limit targeted at 200M
    Mainnet : Activation date undecided
            : Capacity outcome remains conditional

The core redesign: from a compressed race to a pipeline

Today, the economic role of building a high-value block is already commonly outsourced, but that relationship depends on out-of-protocol infrastructure. EIP-7732 brings this division into consensus. A proposer includes a builder’s commitment; the builder reveals the corresponding execution payload afterward; the protocol accounts for payment; and a payload timeliness committee reports whether the payload and blob data appeared on time. This is more than removing a relay dependency. It changes the allocation of time within Ethereum’s 12-second slot.

Under the existing design, validators must receive the block and complete consensus checks, execution, data-availability work and fork-choice evaluation against a tight attestation deadline. ePBS splits the consensus-critical path from execution validation. The EIP describes six seconds for the next proposer and nine seconds for other validators to validate a payload, rather than forcing all work into the early hot path. Smaller consensus messages can propagate first, while the larger execution payload follows. This is the temporal headroom on which larger blocks depend.

There is a semantic price. A transaction included by a builder in slot N is not broadly execution-validated until the chain progresses through slot N+1. “Included” and “widely validated” become more visibly distinct moments. For trading systems, bridges and other latency-sensitive applications, this is not equivalent to a longer finality period, but it is a reason to model receipt, payload availability, execution validation and economic finality separately.

sequenceDiagram
    participant B as Builder
    participant P as Proposer
    participant C as Consensus network
    participant T as Timeliness committee
    participant V as Validators
    B->>P: Commit payload bid and payment
    P->>C: Publish beacon block with commitment
    C-->>V: Validate consensus path first
    B->>T: Reveal execution payload and blobs
    T->>C: Attest timely presence and availability
    V->>V: Execute and validate with extended window
    V->>C: Build and attest on resulting head

Protocol enforcement improves the fairness of the proposer-builder exchange, yet formalization is not decentralization by itself. Builders become protocol-recognized, staked actors with additional duties. Economies of scale in order flow, simulation and low-latency networking can remain. ePBS can remove trusted middleware from the exchange without removing industrial concentration from block construction. That is a crucial counterweight to simplistic claims that enshrining PBS “solves MEV.” It solves a narrower coordination and trust problem while creating a cleaner base for future censorship-resistance mechanisms.

Access maps turn execution into schedulable work

Time is useful only if clients can use it. EIP-7928 requires a block-level access list that records the accounts and storage locations accessed, plus post-transaction state changes. The list provides an explicit dependency map. Clients can prefetch state from disk, identify independent work, execute transactions in parallel where safe and compute state roots more efficiently.

The distinction between parallel validation and unconstrained parallel execution matters. Ethereum transactions still have ordered state effects; two transactions touching the same storage cannot simply be run independently. BALs make conflicts legible and allow clients to schedule around them. They are infrastructure for parallelism, not a promise that every workload scales linearly with processor count.

The proposal’s own historical-block size analysis illustrates the trade. Across a sample of 100 mainnet blocks, BALs including storage reads averaged 91.3 KB raw and 42.7 KB after compression; the reported compressed range was 11.7–78.7 KB. Storage operations represented 85.3% of list size, and the analysis estimated roughly 300.2 MB per day of additional node bandwidth at 12-second blocks. These are proposal-study figures, not a universal forecast: larger future blocks and different workloads could change them. Still, they expose the bargain. Ethereum adds structured metadata and bandwidth so validators can save random database work and unlock concurrency.

The scaling bargain: a longer validation window and explicit dependency maps must be balanced by honest resource pricing and control of new failure modes.

For infrastructure providers, BAL performance will therefore be a more informative signal than synthetic transaction counts. Relevant observations include propagation size at high utilization, disk-read reduction, client-to-client variance, state-root computation time and behavior when lists are late or unavailable. If only well-provisioned operators realize the parallelism benefit, nominal throughput could rise while practical operator diversity falls.

Repricing is the fiscal side of the upgrade

A higher gas limit expands the amount of computation the protocol is willing to admit, but not all gas imposes the same enduring cost. Persistent state must be stored and accessed by future nodes. Glamsterdam’s repricing package acknowledges that an execution budget set for yesterday’s database can undercharge today’s hardware burden.

EIP-8037 raises and separately meters state creation—new accounts, storage slots and deployed bytecode—while EIP-8038 updates charges for state access. The Foundation’s repricing impact analysis says these operations were last broadly adjusted in the 2021 Berlin fork and describes the new schedule as derived from a performance target compatible with roughly a threefold increase in base throughput.

That “roughly 3x” is a design target, not a measured mainnet outcome. Nor does a 200M Hoodi limit imply the same mainnet setting. The stronger point is economic: capacity and conservation are being shipped together. Cheap state creation would allow a larger block budget to accelerate permanent database growth, raising the cost of running a node and undermining the decentralization that makes blockspace valuable. Repricing makes the party that creates or repeatedly touches expensive state bear more of the cost.

Historical transaction replay found the large majority unchanged, according to the Foundation, but a small set of contracts can degrade or fail. Most flagged cases can be addressed with a higher transaction gas limit. The harder cases embed assumptions such as fixed gas stipends, hard-coded call gas or branches based on remaining gas. This is a classic protocol-upgrade asymmetry: aggregate compatibility can be excellent while a thin tail carries material application risk. Wallets and RPC providers also need correct gas estimation; stale constants can convert a theoretically compatible contract into a failed user transaction.

Institutional implications

First, Ethereum is expanding Layer 1 without abandoning its rollup strategy. The Foundation’s March L1–L2 framework assigns L1 the role of resilient settlement, shared state, liquidity and DeFi, while L2s provide customization and extreme scale. Glamsterdam strengthens that base layer: more L1 capacity can reduce contention for settlement and interoperability, while rollups remain differentiated execution environments. The upgrade is therefore better read as a rebalancing of the stack than an admission that rollups failed.

Second, protocol economics are becoming more resource-specific. Separating state creation, state access, calldata and other dimensions reduces cross-subsidies hidden inside one gas number. This improves sustainability but can redistribute costs among applications. State-heavy protocols may pay more even as simple transfers or compute-heavy workloads benefit from broader capacity. Investors and treasuries should avoid treating “higher gas limit” as synonymous with uniformly cheaper usage.

Third, the operational perimeter widens. Validators must understand new ePBS duties; builders must manage protocol-level commitments and capital; client teams must correctly implement BAL construction and validation; application teams must test repricing. The system may reduce reliance on a particular trusted relay workflow while increasing the number of consensus-relevant interfaces. That trade can be worthwhile, but only client diversity and adversarial testing can demonstrate it.

Risks, counterarguments and tests that matter

Complexity risk. ePBS substantially changes fork choice and introduces empty-payload states, builder accounting and timeliness attestations. BALs add another consensus-bound object. Interactions among consensus, execution, networking and fee accounting are where rare bugs can become systemic.

Builder concentration. Protocol recognition can make the builder market safer without making it competitive. The right metrics include builder share, fallback/self-build behavior, payment failures and geographical or client concentration—not simply relay removal.

Latency interpretation. Deferred broad execution validation may confuse applications that equate a block reference with fully checked execution. Infrastructure should expose states accurately rather than compressing them into a single “confirmed” label.

Home-node pressure. More bandwidth for BALs and larger payloads may be offset by parallel disk access and extra validation time, but the net effect is empirical. Hardware requirements under sustained high utilization should be published across client combinations and ordinary equipment.

Compatibility tail risk. A small affected contract population can still include high-value or highly composable components. Historical replay is strong evidence, but it cannot cover future call paths, private order flow or every integration. The August analysis appropriately urges targeted testing instead of assuming that majority compatibility protects every dependency.

Schedule risk. The official date remains undecided. A delay after Hoodi would be evidence of the test process functioning, not necessarily failure. Conversely, a calendar target should not substitute for clean multi-client operation.

The decision framework is straightforward: watch whether Hoodi activates cleanly; whether payload reveals and committee attestations remain reliable under stress; whether BAL overhead remains bounded and produces real client speedups; whether gas-estimation failures are rare; and whether credible home-node configurations keep pace. Those observations measure the thesis. Token price does not.

Conclusion

Glamsterdam’s importance lies in how it links three scarce resources: time, information and persistent state. ePBS reallocates time within a slot and internalizes the proposer-builder exchange. BALs publish the information clients need to schedule validation efficiently. Repricing prevents new capacity from becoming an unpriced claim on every future node. The architecture is coherent because each mechanism addresses a different bottleneck in the same scaling equation.

But coherence is not completion. As of 18 October, Sepolia is evidence, Hoodi is the next experiment, and mainnet remains a decision. Institutions should resist both extremes: dismissing the upgrade because it does not instantly eliminate builder concentration, or capitalizing its maximum throughput before production data exists. The credible case is narrower and more consequential. Ethereum is attempting to turn block production from a compressed serial race into an explicit, measurable pipeline—while charging more honestly for the state that pipeline leaves behind. If Hoodi and subsequent mainnet evidence validate that bargain across diverse hardware and clients, Glamsterdam will mark not merely a bigger Ethereum, but a more governable way to make it bigger.

Direct sources

• Ethereum Foundation — Glamsterdam Hoodi Testnet Announcement, 16 Oct 2026

• ethereum.org — Glamsterdam roadmap overview

• EIP-7732 — Enshrined Proposer-Builder Separation

• EIP-7928 — Block-Level Access Lists

• EIP-7928 supporting analysis — BAL Size Analysis

• Ethereum Foundation — Glamsterdam Repricing Impact, 24 Aug 2026

• EIP-8037 — State Creation Gas Cost Increase

• EIP-8038 — State-access Gas Cost Update

• Ethereum Foundation — How L1 and L2s Can Build the Strongest Possible Ethereum, 23 Mar 2026

Research cut-off: 18 October 2026, UTC. Testnet schedules and mainnet scope remain subject to change.