Glamsterdam upgrade, Ethereum's L1 scaling solution

Original | Odaily Planet Daily jk

The upcoming Glamsterdam upgrade for Ethereum is considered by core developers to be the largest protocol-level restructuring since The Merge. The name comes from a combination of two parts: the execution layer upgrade retains "Amsterdam," named after the location of previous Devconnect events; the consensus layer upgrade is named "Gloas," after a star. Following the previous Fusaka upgrade, Glamsterdam advances L1 scalability by reorganizing how the network processes transactions and manages its growing database, fundamentally updating the way Ethereum creates and verifies blocks.

This upgrade revolves around three core objectives:

• Accelerated Processing (Parallelization): Reorganizing the way the network records data dependencies, allowing it to securely process a large number of transactions simultaneously, rather than slowly processing them one by one.
• Scalability: Splitting the heavy workload of block creation and verification, 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 obstacles for future increases in Gas limits while avoiding degradation in hardware performance.

The two headline proposals of the upgrade are focused on the consensus layer and the execution layer:

There are two major Headliner proposals. Source: Ethereum

Headliner Proposal One: ePBS, Turning "Outsourced Intermediaries" into "Built-in Rules"

First, let's discuss the headliner proposal for the consensus layer, which separates proposers and builders within the protocol, abbreviated in English as ePBS (EIP-7732).

Every time Ethereum produces a block, it actually involves two steps: one person is responsible for "selecting which block" (the proposer), and another person is responsible for "actually assembling the transactions in the block" (the builder). Currently, this division of labor is not specified by the Ethereum protocol itself, but relies on a group of off-chain "intermediary companies" (commonly referred to as relays) to facilitate the process. This off-chain relationship also creates a path during block verification, forcing validators to hurriedly complete transaction broadcasting and execution within a tight 2-second window, limiting the amount of data the network can handle. For example, this is akin to a restaurant where the ordering and cooking processes rely on an independent external liaison to coordinate the delivery of dishes; if this liaison fails, the kitchen and front desk may not align.

What ePBS does is write this "ordering-cooking" division of labor into the restaurant's own operational manual, no longer relying on external liaisons. As a result, a trusted on-chain block delivery and payment mechanism is directly built into the protocol itself, eliminating the need for third-party middleware. However, if both parties wish to use some complex functions not yet specified in the protocol, they can still choose to revert to using external liaisons. Additionally, to prevent chaos during the "delivery" phase, ePBS has established a "dish verification team" to check "who placed the order" and "whether the dish was prepared on time," thus expanding the original 2-second delivery time window to about 9 seconds, allowing the restaurant to handle more orders at once, which means Ethereum can accommodate more data aimed at Layer 2.

Headliner Proposal Two: BALs, Preparing a "Shopping List" Before Departure

Next, let's discuss the headliner proposal for the execution layer, which is a block-level access list, abbreviated as BALs (EIP-7928).

Currently, the way Ethereum processes transactions is somewhat like a person shopping in a supermarket with their eyes closed: they must first feel for an item, confirm what it is, and then decide how to proceed, which forces them to queue one item at a time. Because the system does not know in advance which data a transaction will use, such as which accounts are involved, it must strictly process transactions in order; otherwise, two transactions might inadvertently try to modify the same data (like the balance of the same address), causing conflicts.

BALs allow this person to obtain a shopping list that clearly states "which shelves to go to and which items to pick up" before they set off. With this list, the system can see in advance which transactions will not "collide" with each other, allowing unrelated transactions to be grouped and processed in parallel instead of queuing one by one. This list also has an additional benefit: when new nodes join the network, they can directly copy the final results recorded in this list without having to recalculate all the complex historical transactions, significantly speeding up the synchronization process for new nodes. To facilitate the circulation of this list within the network, Glamsterdam has also packaged a corresponding transmission protocol upgrade that enables nodes to actually share these access lists, which has now become a mandatory requirement for all execution layer clients.

Supporting Proposals: Reassessing "Space-Occupying" Operations

In addition to these two headliner proposals, Glamsterdam has also packaged two supporting proposals for repricing, which can be understood as adjusting the price list for the network's "storage fees" and "query fees."

• The first proposal addresses operations like creating new accounts and deploying contracts that will "permanently occupy space" in the network. Previously, the fees charged were not proportional to the actual space occupied; now, they will be recalculated based on "charging for each unit of space occupied," aiming to control the overall data growth rate of the network to a safe and predictable level of 120 GiB per year, ensuring that the network can continue to operate on ordinary hardware. Additionally, this storage fee will be accounted for separately, no longer mixed with the computational fees for processing transactions. As long as developers are willing to pay a little more in storage fees, they can still deploy larger and more complex applications without being immediately constrained by the overall Gas limit.
• The second proposal addresses operations like querying and reading existing data in the network, which were previously underpriced and did not keep pace with the actual query costs as data volume increased. This time, the pricing standards for these operation codes will be raised to better reflect the real load conditions of modern hardware, while also preventing individuals from exploiting the low fees to intentionally clog the network with excessive query requests.

Mainnet Launch Date: Not Yet Determined

In terms of the timeline, Glamsterdam is currently in a rather delicate phase. On the official side, the most recent verifiable meeting of all core developers for the execution layer (ACDE) was the 241st, held on July 16, with the main agenda including updates on the Glamsterdam Devnet phase and selecting headliner proposals for the next upgrade, Hegota. A widely referenced schedule in the industry indicated that the Devnet phase underwent eight iterations from 0 to 7, spanning from March 28, 2026, to July 8, followed by the Sepolia testnet fork originally scheduled for August 3, 2026, and the Hoodi testnet fork originally scheduled for August 17, 2026, with the target date for mainnet activation set for September 16, 2026.

The original schedule was for the first half of 2026, Source: Ethereum

However, based on the latest developments, this schedule has likely been postponed. The EthPandaOps team recently launched a new testnet called Plataberget, which is the first short-term public testnet specifically designed for Glamsterdam. The official deployments for Sepolia and Hoodi are expected to be delayed until September, and the target for the mainnet launch has correspondingly shifted to the fourth quarter of 2026. This marks the second time Glamsterdam's timeline has slipped, following the previous postponement from the originally planned first half of 2026. Core developers have repeatedly emphasized that the correctness of the upgrade takes precedence over meeting any specific date, so until the specific block height is locked in during the formal ACD meeting, we may not see this upgrade until the fourth quarter or even the end of the year.