Ethereum Glamsterdam Upgrade: Largest-Ever Underlying Restructuring, Mainnet Date Still Undecided

Original: Odaily Planet Daily (@OdailyChina)

Author: jk

Ethereum's upcoming Glamsterdam upgrade is viewed by core developers as the most extensive protocol-level restructuring since The Merge. The name combines two parts: the execution layer upgrade retains "Amsterdam," named after the host city of a previous Devconnect, while the consensus layer upgrade is named "Gloas," after a star. Following the previous Fusaka upgrade, Glamsterdam advances L1 scalability by restructuring how the network processes transactions and manages its growing database, fundamentally updating the way Ethereum creates and validates blocks.

This upgrade revolves around three core objectives:

• Faster Processing (Parallelization): Restructuring how the network records data dependencies, enabling it to safely process a large number of transactions simultaneously, rather than sequentially one by one.
• Scalability: Splitting the heavy work of block creation and validation, giving the network more time to propagate larger amounts of data without slowing down.
• Sustainability: Adjusting network fees to accurately reflect the long-term hardware costs of storing new data, clearing the path for future gas limit increases while avoiding hardware performance degradation.

The upgrade's two headline proposals sit on the consensus and execution layers respectively:

There are two headline proposals. Source: Ethereum

Headline Proposal 1: ePBS — Turning the "Outsourced Middleman" into a "Built-in Rule"

Let's start with the consensus layer headline proposal: in-protocol Proposer-Builder Separation, abbreviated as ePBS (EIP-7732).

Every time Ethereum produces a block, it happens in two steps: one party is responsible for "selecting which block" (the proposer), and another is responsible for "actually assembling the transactions within the block" (the builder). Currently, this division of labor is not defined by the Ethereum protocol itself, but is coordinated by a set of off-chain "intermediaries" (known in the industry as relays). This off-chain relationship also creates a bottleneck during block validation, forcing validators to hastily complete transaction broadcast and execution within a tight 2-second window, limiting the amount of data the network can handle. To use an analogy, it's like a restaurant where the ordering and cooking processes rely on an external coordinator to relay orders — if that coordinator fails, the kitchen and the front of house may end up out of sync.

What ePBS does is write this "order-cook" division of labor into the restaurant's own operational manual, eliminating the reliance on external coordinators. This way, a trusted on-chain mechanism for block delivery and payment is built directly into the protocol itself, removing the need for third-party middleware — although both parties can still choose to use external coordinators if they want complex features not yet defined in the protocol. Additionally, to avoid the chaos of the "food delivery" step, ePBS establishes a dedicated "dish inspection group" to separately check "who placed the order" and "whether the dish was prepared and served on time." This expands the original 2-second delivery window to approximately 9 seconds, allowing the restaurant to handle more orders at once — meaning Ethereum can carry more data for Layer 2 networks.

Headline Proposal 2: BALs — Preparing a "Shopping List" Before Departure

Now for the execution layer headline proposal: Block Access Lists, abbreviated as BALs (EIP-7928).

Currently, Ethereum processes transactions somewhat like a person shopping blindfolded: you have to touch an item and confirm what it is before deciding the next step, forcing everything to be processed one at a time. Because the system doesn't know in advance which data a transaction will use — such as which accounts it will involve — it must process transactions strictly in order; otherwise, two transactions might accidentally attempt to modify the same data (like the balance of the same address) at the same time, causing conflicts and errors.

BALs essentially give this person a shopping list written in advance, specifying "which shelves to visit and which items to pick." With this list, the system can see in advance which transactions won't conflict with each other at all, allowing it to group unrelated transactions and process them in parallel, rather than lining them up one by one. The list also comes with an additional benefit: when new nodes join the network, they can directly copy the final results recorded in this list without having to recompute all the complex historical transactions, dramatically speeding up the synchronization process for new nodes. To enable this list to actually circulate through the network, Glamsterdam also includes a supporting transport protocol upgrade that allows nodes to share these access lists, and this transport protocol has already become mandatory for all execution layer clients.

Supporting Proposals: Recalculating the Costs for "Space-Consuming" Operations

Beyond these two headline proposals, Glamsterdam also packages two supporting re-pricing proposals — essentially adjusting the price list for the network's "storage fees" and "query fees" respectively.

• The first targets operations like creating new accounts and deploying contracts that "permanently occupy space" on the network. Previously, fees were not well proportional to actual space usage. Now, they will be re-priced on a "pay for each unit of space occupied" basis, aiming to cap the network's overall data growth rate at a safe, predictable level of 120 GiB per year, ensuring the network remains sustainable on ordinary hardware. Additionally, these storage fees will be tracked in a separate account, no longer mixed with the computational costs of processing transactions. As long as developers are willing to pay slightly higher storage fees, they can still deploy larger, more complex applications without being abruptly constrained by the overall gas limit.
• The second targets operations that query or read existing data on the network. Previously underpriced relative to the actual cost of querying now-larger datasets, this upgrade will raise fees for these opcodes to better reflect the real load on modern hardware, while also preventing anyone from exploiting cheap fees to deliberately clog the network with excessive query requests.

Mainnet Launch Timeline: Not Yet Set

In terms of scheduling, Glamsterdam is currently in a rather delicate phase. Officially, the most recent verifiable All Core Developers Execution (ACDE) call was the 241st, held on July 16, with the main agenda including updates on the Glamsterdam Devnet phase and voting on headline proposals for the next upgrade, Hegota. A widely cited schedule earlier showed the Devnet phase underwent eight iterations from 0 to 7, spanning March 28 to July 8, 2026, with the Sepolia testnet fork originally slated for August 3, 2026, the Hoodi testnet fork for August 17, 2026, and a target mainnet activation date of September 16, 2026.

Originally scheduled for H1 2026. Source: Ethereum

However, based on the latest developments, this timeline has likely been pushed back. The EthPandaOps team recently launched a new testnet called Plataberget, the first short-lived public testnet specifically designed for Glamsterdam, with formal Sepolia and Hoodi deployments expected to follow only in September. The mainnet launch target has correspondingly slipped to Q4 2026. This marks the second time Glamsterdam's date has slipped, after already being delayed from its original H1 2026 timeframe. Core developers have repeatedly emphasized that the correctness of the upgrade takes priority over meeting any specific date, so until an official ACD meeting locks in a specific block height, we may not see this upgrade until Q4 or even the end of the year.