Glamsterdam Upgrade: Ethereum's L1 Scalability Solution

Original | Odaily Planet Daily jk

The upcoming Glamsterdam upgrade for Ethereum is considered by core developers to be the most significant protocol-level restructuring since The Merge. The name is a combination of two parts: the execution layer upgrade retains the name "Amsterdam," derived from the location of past 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 how Ethereum creates and verifies blocks.

This upgrade revolves around three core objectives:

• Accelerated Processing (Parallelization): Reorganizing how the network records data dependencies, allowing it to safely handle 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 the way for future increases in Gas limits while avoiding hardware performance degradation.

The two flagship proposals of the upgrade focus 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 from builders, abbreviated as ePBS (EIP-7732).

Every time Ethereum produces a block, it actually involves two steps: one person is responsible for "choosing which block" (the proposer), and another person is responsible for "assembling the transactions in the block" (the builder). Currently, this division of labor is not defined by the Ethereum protocol itself, but relies on a group of off-chain "intermediary companies" (known as relays) to facilitate the process. This off-chain relationship creates a bottleneck during block verification, forcing validators to rush to broadcast and execute transactions within a tight 2-second window, limiting the amount of data the network can handle. For example, this is like a restaurant where the ordering and cooking processes rely on an independent external coordinator to manage the delivery of dishes; if this coordinator 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, eliminating the reliance on external coordinators. As a result, a trustworthy on-chain block delivery and payment mechanism is directly built into the protocol itself, thus no longer needing to rely on third-party middleware. However, if both parties want to use some complex functions not yet defined in the protocol, they can still choose to revert to external coordinators. Additionally, to avoid chaos in the "delivery" process, ePBS has established a "dish inspection team" to check "who ordered" and "whether the dish is ready on time," thereby extending the original 2-second delivery window to about 9 seconds, allowing the restaurant to handle more orders at once, which means Ethereum can accommodate more Layer 2 data.

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

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

Currently, Ethereum's method of processing transactions is somewhat like a person shopping in a supermarket with their eyes closed: they must first feel a product, confirm what it is, and then decide how to proceed, which means they can only queue one item at a time. Because they do not know in advance which data a transaction will use, such as which accounts are involved, the system must strictly process transactions one by one 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 conflict 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 bundled a corresponding transmission protocol upgrade, allowing 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 bundled 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 involves 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 run on standard 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 bit more in storage fees, they can still deploy larger and more complex applications without being constrained by the overall Gas limit.
• The second proposal addresses operations like querying and reading existing data in the network, which previously had pricing that was too low to keep up with the actual query costs after the data volume increased. This time, the pricing standard for these operations will be raised to better reflect the real load on 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

Regarding the timeline, Glamsterdam is currently in a rather delicate phase. Officially, the most recent verifiable meeting of all core developers (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.

Originally scheduled for the first half of 2026, Source: Ethereum

However, recent developments suggest that 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 of Sepolia and Hoodi are expected to be delayed until September, and the mainnet launch target has correspondingly shifted to the fourth quarter of 2026. This marks the second time Glamsterdam has experienced a date shift, 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 formal ACD meeting locks in a specific block height, we may not see this upgrade until the fourth quarter or even the end of the year.

This content is provided for general informational purposes only and doesn't constitute financial, investment, legal, or tax advice. Any events, rewards, online promotions, or related information mentioned herein should not be considered a recommendation, solicitation, or invitation to purchase, sell, trade, or otherwise deal in any crypto assets. Crypto assets are highly volatile and may result in loss. The availability of WEEX services, products, and related events may vary by region. You are responsible for ensuring that your participation is in accordance with applicable local laws and regulations.