Written by: imToken
Ethereum's next major upgrade has entered the final sprint phase.
According to the current official Ethereum roadmap, the Glamsterdam upgrade is scheduled to launch on mainnet in the second half of 2026. As of the end of June, it has entered the final testing phase on the developer network, with ongoing tests on the multi-client devnet focusing on core features such as built-in PBS, block-level access lists, and gas re-pricing. However, the exact activation date has not yet been finalized.
Meanwhile, the most discussed topic across social media platforms is undoubtedly the direct performance narrative of "Mainnet Surge to 10,000 TPS" after the upgrade. However, beyond this, the upgrade has completely restructured Ethereum’s block production pipeline and execution engine—its depth and breadth of changes have been widely hailed by the developer community as "the largest upgrade since The Merge."
So, what exactly changed with the somewhat cool-sounding “Glamsterdam”—a blend of the consensus layer upgrade Glados and the execution layer upgrade Amsterdam? How will it leave past pain points behind, and what groundbreaking changes will it bring to our everyday on-chain experience?
I. Why is it the largest upgrade since the Merge?
If the previous Dencun and Fusaka upgrades primarily paved the way for L2 data availability (blobs), then Glamsterdam refocuses attention on L1, sparking a major overhaul of L1 performance and architecture.
This is also the most authentic underlying reality behind Ethereum’s current “Make L1 Great Again” initiative: how to accommodate more transactions on L1 without increasing the cost of running nodes or the risk of network centralization.
However, for average users, past Ethereum upgrades are often simplified into one most intuitive question: Will gas fees become cheaper? Will throughput increase? But honestly, the upcoming Glamsterdam upgrade is difficult to summarize simply as “lower fees” or “scaling.”
Overall, this upgrade involves multiple critical components of Ethereum’s underlying architecture, including who builds blocks, how transactions are executed, how nodes read and synchronize state, and how much Gas should be paid for different on-chain operations—essentially requiring a redesign of Ethereum’s foundational paradigm for producing and processing blocks. Based on the technical details disclosed so far, the most significant changes focus on three key areas:
- Built-in PBS (ePBS): Restructures the relationship between block proposers and builders, eliminating reliance on external relays;
- Block-level Access Lists (BALs): Pre-map transaction execution to enable parallel processing and faster node synchronization;
- Gas Repricing: Introducing a more precise resource billing model to control state bloat in high-throughput environments;
To understand built-in PBS, it’s important to know that blocks on Ethereum are not necessarily submitted directly by the Proposer. Under the current MEV-Boost architecture, most Proposers outsource the tasks of collecting transactions, ordering them, and seeking MEV opportunities to professional Block Builders, while the Proposer primarily selects the highest-bidding candidate block to submit to the network.
This division of labor—where Builders assemble blocks and Proposers submit them—is known as PBS (Proposer-Builder Separation).
The issue is that this current mechanism has not been fully integrated into Ethereum’s underlying protocol—Proposers and Builders must rely on external third-party software and the MEV-Boost Relay service to submit block bids, deliver block contents, and process payments.
This means Relay must ensure that the Builder ultimately publishes the full block, while also preventing the Proposer from prematurely viewing the block content and then refusing payment—a role that makes Relay a vulnerable and centralized "trusted intermediary."
EIP-7732 proposes ePBS (Enshrined PBS) to address this pain point by directly integrating this博弈 relationship into Ethereum’s consensus protocol itself, eliminating third-party relays and making Builders natively recognized participants in the protocol. Builders first submit block commitments and bids; the protocol automatically locks in the corresponding payments, and then a dedicated "Payload Timeliness Committee" determines whether the Builder disclosed the execution payload on time.
This allows the consensus block and execution payload processing steps to be decoupled, extending the window for propagating and processing execution payloads from approximately 2 seconds to about 9 seconds. Although these few seconds may seem minor, they are crucial for Ethereum’s scalability—giving nodes more time to receive and process larger blocks and more blob data, thereby creating room to further increase the Gas Limit.
Second, Glamsterdam’s other core breakthrough at the execution layer is Block-Level Access Lists (BALs), proposed by EIP-7928.
It is well known that, currently, Ethereum nodes cannot directly determine from a block which accounts each transaction will read, which contract storage it will access, or which state variables it will modify; instead, these data dependencies are typically discovered incrementally during transaction execution.
It’s like entering a large warehouse to retrieve items without a complete inventory map, forcing staff to search and process items on the go—so to prevent two people from modifying the same stock simultaneously, much of the work must be completed strictly in a fixed sequence (single-threaded serially).
Block-level Access Lists (BALs) essentially attach a complete "state access map" to each block. They pre-declare in the block header which addresses and storage slots the transactions within the block will access, as well as the resulting state after execution. With this map, nodes can immediately determine, before execution, which transactions will access the same data and which transactions are non-conflicting.
For non-conflicting portions, nodes can proactively read relevant states from disk and parallelize parts of transaction validation and state root computation, rather than forcing all work into a strictly sequential pipeline. Additionally, since BALs record state changes after transactions are completed, some nodes can leverage these results to reconstruct state during synchronization and catch-up, avoiding the need to re-execute every transaction in a block from scratch in all scenarios (in my personal understanding, this bears a resemblance to sharding concepts), enabling Ethereum to become a fully parallel-executing blockchain.
Therefore, in the long term, this is a fundamental key to Ethereum mainnet breaking through its performance ceiling.
Finally, there is the gas re-pricing, which involved significant adjustments to the gas pricing of multiple on-chain operations through economic levers.
The reason is that the current Ethereum gas costs do not fully align with the actual resource consumption borne by nodes. For example, a complex computation typically leaves little long-term burden on nodes once executed, whereas creating a new account, deploying a smart contract, or writing to a new storage slot generates data that must be permanently stored by all full nodes globally.
In the past, the fees for these state-creation actions did not fully reflect the permanent storage costs they imposed (state explosion). If Ethereum maintained its original pricing after increasing the gas limit, more block space would quickly be converted into uncontrolled state data, ultimately overwhelming node hardware.
EIP-8037, already confirmed to be included within Glamsterdam, is preparing to completely overhaul this rule. It includes separating computation and state accounting to recalculate costs based on the volume of new state data, distinguishing between regular computation gas and state gas; it also aims to curb state bloat, making operations more expensive for applications that create large numbers of new accounts, deploy bulky redundant contracts, or frequently write new state, while making the fee structure more attractive for applications that primarily consume immediate computational resources without continuously expanding state.
Ultimately, Glamsterdam’s gas reform cannot be simply understood as a blanket reduction in fees; rather, it involves accurately assessing how much immediate computational resource a transaction consumes and how much long-term storage burden it imposes on the network, then aligning fees for different operations more closely with their true physical costs.
Overall, these three components, though seemingly independent, collectively aim toward the same ultimate goal: prematurely upgrading the core underlying infrastructure to significantly increase the Gas Limit and processing capacity of the Ethereum mainnet.
II. Why can't we simply increase the block size?
Many people might wonder: if the network is too slow and expensive, why not simply increase the Gas Limit to double the block capacity?
This is a well-known issue. In theory, the most direct way to increase mainnet capacity is indeed to raise the Gas limit per block, since a higher Gas limit allows more transactions and computations to be included in each block.
However, the gas limit is not a number that can be infinitely increased. Once blocks are blindly enlarged, it triggers a domino effect: nodes must receive more data, execute more transactions, and compute new states within the same time frame. If processing speeds cannot keep up, lower-spec nodes are more likely to fall behind, causing delays in block propagation and validation, ultimately increasing the risk of network forks and centralization.
Meanwhile, more transactions mean more accounts, contracts, and storage data are permanently written to the Ethereum database. This data does not automatically disappear after transactions end but instead accumulates continuously in Ethereum’s state database, causing the state to grow faster.
Therefore, Ethereum scaling is not a simple mathematical problem, but rather requires solving three challenges simultaneously:
- First, how to give nodes more time to propagate and process large blocks;
- Second, how to reduce the performance bottleneck caused by sequential transaction execution;
- Finally, how can we prevent additional block space from rapidly turning into uncontrolled state bloat;
This is the core logic of Glamsterdam: rather than blindly scaling up and forcing nodes to bear the burden, it first reimagines block production, transaction execution, and resource pricing—clearing the pipeline at the foundational level—to naturally open the door to increased mainnet capacity.
Among these, ePBS rearranges the block processing workflow within slots to give nodes more time to propagate and verify large blocks; BALs improve the efficiency of clients in reading, executing, and synchronizing by explicitly providing state access relationships; and gas repricing addresses unsustainable state growth.
During the Glamsterdam collaborative test in April 2026, core developers conducted intensive stress testing on multi-client implementations and established a technical target of 200 million gas as the minimum trusted capacity post-upgrade. This target is underpinned by the combined support of ePBS, BALs, and state gas re-pricing.
Of course, 200 million gas is closer to the system's capacity after the upgrade and the direction it can gradually evolve toward—it does not mean that the mainnet will immediately raise the gas limit to this level on the day Glamsterdam is activated.
What truly matters is that Ethereum is shifting from its past approach of "cautious, incremental scaling" to preparing for significantly larger mainnet scaling through fundamental architectural restructuring.
III. What impact will ordinary users and the Ethereum ecosystem experience?
From the perspective of an ordinary user, the most important question regarding the Glamsterdam upgrade is still whether transaction fees will decrease.
Overall, the answer is more likely to point toward a potential decline and greater stability, rather than all trades becoming immediately cheaper.
Since ePBS and block-level access lists create conditions for a higher gas limit, it is foreseeable that the number of transactions each block can accommodate will certainly increase. With on-chain demand remaining unchanged, the increased supply of block space will naturally help alleviate congestion and reduce the likelihood of sudden spikes in the base fee.
However, for individual transactions, the impact of different operations may vary. For example, a standard ETH transfer may benefit from basic Gas optimization; furthermore, since BALs provide state paths in advance, wallets will significantly improve their Gas fee estimation accuracy. The frustrating experience of failed transactions due to inaccurate Gas estimates caused by market volatility—yet still incurring transaction fees—will become a thing of the past.
However, operations such as deploying contracts, bulk account creation, or writing large amounts of new state may incur higher costs due to state repricing. Therefore, Glamsterdam is more likely to result in lower costs for simple transactions, more stable fees during periods of congestion, and state-intensive applications beginning to pay more accurate prices for long-term network resource usage.
This upgrade is also relevant to users who primarily use Layer 2 networks. ePBS extends the data propagation window for execution payloads from approximately 2 seconds to about 9 seconds, enabling not only larger mainnet blocks but also providing additional capacity for Ethereum to handle more blob data. As blob capacity continues to expand, Rollups will have more room to submit transaction data, which, over the long term, helps stabilize Layer 2 data costs.
Additionally, a more noticeable change for wallets, exchanges, and cross-chain bridges may come from EIP-7708. While ERC-20 token transfers typically generate standardized Transfer logs, native ETH transfers between certain smart contracts do not leave equally clear event records. Wallets and trading platforms often rely on additional internal transaction tracking tools to identify these ETH movements.
EIP-7708 requires non-zero ETH transfers and ETH burn operations to generate standard logs, enabling wallets, exchanges, and cross-chain bridges to more reliably detect deposits, withdrawals, and internal ETH changes within contracts. As a result, users may see more complete ETH transaction records in the future, and internal transfers that previously required complex transaction tracing to identify will now be more easily recognized directly by wallets.
For node operators and stakers, the impact is more direct. Glamsterdam changes how blocks are processed at both the execution and consensus layers, so nodes and validators must upgrade to Glamsterdam-compatible client versions before mainnet activation. Ordinary ETH holders do not need to migrate their ETH or perform any so-called “asset upgrade” or “token swap.”
Looking further ahead, what Glamsterdam truly impacts is how Ethereum redefines the balance between scalability and decentralization. After all, if increasing block capacity leads to a simultaneous and substantial rise in the hardware costs required to run nodes, the mainnet’s throughput may increase—but the network could become increasingly reliant on large institutions.
The combination of ePBS, block-level access lists, and state gas repricing aims to create an alternative scaling path: rather than simply requiring nodes to process more work in the same amount of time, it reorganizes the block production process, provides transaction dependency information in advance, and charges for different resources based on their actual burden.
This is also the fundamental difference between Glamsterdam and a typical gas limit increase: rather than attempting to solve all of Ethereum’s problems through a single EIP, it simultaneously transforms three interrelated mechanisms—block production, transaction execution, and state growth.
In conclusion
In the long term, Glamsterdam will profoundly influence the narrative around Ethereum’s quest to rebalance between high-performance scaling and absolute decentralization.
This is also the original intent or inertia of Ethereum that has become increasingly familiar to everyone—facing the growing pressure from high-performance monolithic public chains, Ethereum has chosen not to simply raise hardware barriers, but instead pursued a path that preserves its decentralized essence and offers greater foundational resilience. This is exemplified by its recent combination of measures: rewriting the block pipeline (ePBS), explicitly pre-announcing transaction dependencies (BALs), and precisely charging for different resources based on their physical burden (Gas re-pricing)—all aimed at squeezing out significantly greater mainnet capacity while ensuring that ordinary users can still run nodes and participate in validation.
From this perspective, every cost-effective gas fee we pay in the future, more accurate and transparent internal ETH billing in our wallets, and the broader potential for lower fees on L2s may all greatly benefit from the foundational overhaul Glamsterdam is laying for Ethereum in the second half of 2026.