Author | jk
The upcoming Glamsterdam upgrade for Ethereum is seen by core developers as the most extensive protocol-level restructuring since The Merge. The name is a combination of two parts: the execution layer upgrade continues the "Amsterdam" naming from previous Devconnect host cities, while the consensus layer upgrade is named "Gloas" after a star. Following the previous Fusaka upgrade, Glamsterdam advances L1 scaling by restructuring how the network processes transactions and manages its growing database, fundamentally updating how Ethereum creates and validates blocks.
This upgrade revolves around three core objectives:
- Accelerated Processing (Parallelization): Reorganizes how the network records data dependencies, enabling it to safely process many transactions simultaneously rather than slowly one-by-one in sequence.
- Scalability: Splits the heavy workload of block creation and validation, giving the network more time to propagate larger amounts of data without slowing down.
- Sustainability: Adjusts network fees to accurately reflect the long-term hardware costs of storing new data, clearing the way for future gas limit increases while avoiding hardware performance degradation.
The upgrade's two headline proposals fall under the consensus and execution layers respectively:
There are two headline proposals. Source: Ethereum
Headline Proposal One: ePBS, Turning "Outsourced Middlemen" into "Built-in Rules"
First, the consensus layer's headline proposal: enshrined Proposer-Builder Separation, abbreviated as ePBS (EIP-7732).
Each time Ethereum produces a block, it involves two steps: one person 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 mandated by the Ethereum protocol itself, but is instead facilitated by a batch of off-chain "intermediary companies" (jargon: relays). This off-chain relationship also creates a critical path during block validation, forcing validators to rush through transaction broadcasting and execution within a tight 2-second window, limiting the amount of data the network can handle. An analogy: it's like a restaurant's ordering and cooking process originally relying on an independent external coordinator to relay the orders; if this coordinator fails, the kitchen and the front-of-house might end up with mismatched accounts.
What ePBS does is codify this "order-cooking" division of labor into the restaurant's own operational manual, eliminating reliance on the external coordinator. This way, on-chain trusted block delivery and payment mechanisms are directly built into the protocol itself, thus no longer requiring dependence on third-party middleware. However, if the parties wish to use complex features not yet specified in the protocol, they can still choose to revert to using an external coordinator. Meanwhile, to prevent the "order relay" process from being a frantic rush, ePBS also establishes a dedicated "inspection team" to separately verify "who placed the order" and "whether the food was prepared and served on time." The original 2-second order relay window is consequently expanded to approximately 9 seconds, allowing the restaurant to handle more orders in one go—meaning Ethereum can carry more data destined for Layer2.
Headline Proposal Two: BALs, Making a "Shopping List" Before Heading Out
Next, the execution layer's headline proposal: Block-level Access Lists, abbreviated as BALs (EIP-7928).
The current way Ethereum processes transactions is akin to a person going grocery shopping blindfolded: they must touch an item first, confirm what it is, before deciding on the next step, so items must be handled one by one in a queue. Because it's not known in advance which data a transaction will use (e.g., which accounts it involves), the system must process transactions strictly in sequence, one after another. Otherwise, two transactions might unintentionally attempt to modify the same piece of data (like the balance of the same address) simultaneously, causing conflicts and errors.
BALs are equivalent to giving this person a "shopping list" written in advance, specifying "which shelves to go to and which items to pick up." With this list, the system can see ahead of time which transactions are completely unrelated and won't "fight" with each other. It can then group these unrelated transactions and process them concurrently in parallel, rather than having to queue them up one by one. This list has an additional benefit: when new nodes join the network, they can directly copy the final results recorded in this list, without needing to recompute all the complex historical transactions, significantly speeding up the node synchronization process. To facilitate the actual circulation of these lists within the network, Glamsterdam also bundles a supporting transport protocol upgrade that allows nodes to share these access lists. This transport protocol has now become a mandatory requirement for all execution layer clients.
Supporting Proposals: Recalculating Costs for "Space-Occupying" Operations
Besides these two headline proposals, Glamsterdam also bundles two repricing supporting proposals, which can be understood as a price list adjustment for the network's "storage fees" and "query fees," respectively.
- The first involves operations like creating new accounts or deploying contracts, which "permanently occupy space" in the network. Previously, the fee charged was not proportional to the actual space occupied. Now, it will be recalculated to "charge the corresponding fee for each unit of space occupied." The goal is to control the entire network's data growth rate at a safe, predictable level of approximately 120 GiB per year, ensuring the network can continue to run on ordinary hardware. Additionally, this storage fee will be accounted for in a separate, dedicated account, no longer mixed with the computational costs of processing transactions themselves. As long as developers are willing to pay a bit more for storage, they can still deploy larger, more complex applications without being immediately capped by the overall Gas limit.
- The second involves operations like querying or reading existing data within the network. Previously, these were priced too low, not keeping up with the actual query costs after the data volume increased. This time, the pricing standards for these opcodes will be raised, bringing the price closer to the real load conditions of modern hardware, while also preventing malicious actors from exploiting the cheap fees to intentionally clog the network with a flood of query requests.
Mainnet Launch Time: Still Not Finalized
Regarding the timeline, Glamsterdam is currently in a rather delicate phase. Officially, the last verifiable All Core Developers Execution Layer meeting (ACDE) was the 241st, held on July 16th, with the main agenda including the latest progress report on the Glamsterdam Devnet phase and voting for the headline proposal for the next upgrade, Hegota. A widely cited internal schedule previously indicated that the Devnet phase went through eight iterations from 0 to 7, spanning from March 28th to July 8th, 2026. The Sepolia testnet fork was originally scheduled for August 3rd, 2026, the Hoodi testnet fork for August 17th, 2026, and the target date for mainnet activation was September 16th, 2026.
The original schedule was for the first half of 2026. Source: Ethereum
However, based on the latest developments, this schedule has most likely been pushed back. The EthPandaOps team recently launched a new testnet called Plataberget, which is the first short-term public testnet specifically designed for Glamsterdam. Formal deployments on Sepolia and Hoodi are now expected to be postponed until September, and the mainnet launch target has been correspondingly pushed back to the fourth quarter of 2026. This marks the second time Glamsterdam's dates have slipped, following a previous delay from the original first half of 2026. Core developers have repeatedly emphasized that the correctness of the upgrade takes priority over meeting any specific date. Therefore, until a specific block height is officially locked in by an ACD meeting, we may have to wait until the fourth quarter, or even the end of the year, to see this upgrade.
