Ethereum's next major upgrade is now entering the final sprint.
According to the current official Ethereum roadmap, the Glamsterdam upgrade is planned for mainnet activation in the second half of 2026. As of the end of June, it has entered the final testing phase on developer networks. Centered around multi-client devnets, continuous testing is underway for core features like enshrined PBS, block-level access lists, and gas repricing, though the exact activation time has not been finalized.
Meanwhile, on various social media platforms, the most discussed aspect is undoubtedly the compelling performance narrative of "mainnet hitting 10,000 TPS" post-upgrade. However, beyond this, this upgrade represents a fundamental overhaul of Ethereum's block production pipeline and execution engine. The depth and breadth of its changes have led the developer community to widely acclaim it as "the largest-scale upgrade since The Merge."
So, what exactly does this rather cool-sounding "Glamsterdam" (a combination of the consensus layer upgrade Gloas and the execution layer upgrade Amsterdam) change? How will it address past pain points, and what transformative changes will it bring to our daily on-chain experience?
I. Why is it the 'Largest Upgrade Since The Merge'?
If previous upgrades like Dencun and Fusaka primarily paved the way for L2 data availability (Blob), then Glamsterdam shifts the focus back to L1, initiating a major renovation of L1 performance and architecture.
This reflects the underlying ethos of Ethereum's current drive to "make L1 great again": how to enable L1 to process more transactions without simultaneously increasing node operation costs and network centralization risks.
However, for ordinary users, Ethereum upgrades are often simplified to one intuitive question: Will gas become cheaper? Will throughput increase? Frankly, the upcoming Glamsterdam is difficult to summarize simply with terms like "fee reduction" or "scaling."
Overall, this upgrade touches multiple critical aspects of Ethereum's underlying infrastructure, including who builds blocks, how transactions are executed, how nodes read and synchronize state, and how much gas different on-chain operations should pay. It essentially redesigns the foundational paradigm for how Ethereum produces and processes blocks. According to the currently disclosed technical details, the most significant core changes focus on three main areas:
- Enshrined PBS (ePBS): Restructures the game theory between block proposers and builders, eliminating reliance on external relays;
- Block-Level Access Lists (BALs): Provides a pre-defined map for transaction execution, paving the way for parallel processing and faster node synchronization;
- Gas Repricing: Introduces a more precise resource pricing model to control state bloat in high-throughput environments;
First, to understand enshrined PBS, one must know that blocks on Ethereum are not necessarily submitted directly by the Proposer. Especially under the current MEV-Boost architecture, most Proposers outsource the tasks of collecting transactions, ordering them, and searching for MEV opportunities to specialized block Builders. The Proposer is primarily responsible for selecting the candidate block with the highest bid to submit to the network.
This division of labor—"Builder assembles, Proposer submits"—is PBS (Proposer-Builder Separation).
The problem, however, is that this mechanism is not fully encoded into Ethereum's underlying protocol—Proposers and Builders must rely on off-protocol third-party software and MEV-Boost Relay services to complete block bidding, content delivery, and payment.
This means Relays must ensure Builders eventually publish the full block and prevent Proposers from "front-running" by peeking at the block content and refusing payment. Thus, they occupy a fragile and centralized role as a "trusted intermediary."
The ePBS (Enshrined PBS) proposed by EIP-7732 aims to solve this exact pain point. It plans to integrate this game theory directly into Ethereum's consensus protocol itself, eliminating third-party relays entirely. Builders become natively recognized participants in the protocol. They first submit a block commitment and bid, the protocol automatically locks the corresponding payment, and then a dedicated "Payload Timeliness Committee" judges whether the Builder publishes the execution payload on time.
This decouples the processing of the consensus block and the execution payload, extending the propagation and processing window for the execution payload from about 2 seconds to approximately 9 seconds. These few extra seconds, while seemingly small, are crucial for Ethereum scaling—it means nodes gain more time to receive and process larger blocks and more Blob data, thereby creating room to further increase the Gas Limit.
Second, another core breakthrough of Glamsterdam on the execution layer is Block-Level Access Lists (BALs) proposed by EIP-7928.
As is well known, currently, Ethereum nodes cannot directly learn from a block which accounts each transaction will read, which contract storage it will access, or which states it will modify. They typically discover these data dependencies only during the transaction execution process.
This is like entering a large warehouse to retrieve goods without a complete inventory list. Workers must search while processing. Therefore, to prevent two people from modifying the same inventory simultaneously, most work must be done strictly in a fixed order (single-threaded serial execution).
Block-Level Access Lists (BALs) are equivalent to attaching a complete "state access map" to each block. They declare in the block header in advance which addresses and storage slots the transaction set within that block will touch, as well as the resulting state after execution. With this map, nodes can immediately discern which transactions access the same data and which are conflict-free before execution:
For the conflict-free parts, nodes can prefetch related state from disk and perform parallel transaction validation and state root calculation, without needing to queue all work into a strictly serial pipeline. Furthermore, since BALs also record state changes after transaction execution, some nodes can use these results for state reconstruction during network synchronization and catch-up, without having to execute every transaction in the block from scratch in all scenarios (the author's personal interpretation sees a flavor of sharding concepts here), potentially making Ethereum a more parallel-executable blockchain.
Therefore, in the long run, this is also a key underlying element for Ethereum's mainnet to break through its performance ceiling.
Finally, there's Gas Repricing, which fundamentally recalibrates the gas pricing for various on-chain operations primarily through economic levers.
The reason is that Ethereum's current gas costs do not perfectly align with the actual resource consumption borne by nodes. For example, a pure, complex computation, once executed, typically doesn't leave nodes with much long-term burden. However, creating a new account, deploying a smart contract, or writing to a new storage slot generates data that needs to be permanently stored by all full nodes globally.
Historically, the fees for these state-creation behaviors have not fully reflected their permanent storage costs (state explosion). If Ethereum maintains its original pricing after increasing the Gas Limit, the additional block space could quickly translate into uncontrollable state data, ultimately overwhelming node hardware.
EIP-8037, which has been confirmed for inclusion in Glamsterdam, aims to completely restructure these rules. This includes separating computation and state accounting, recalculating costs based on the volume of new state data added, distinguishing between ordinary computation gas and state gas; and controlling state explosion, making operations that create numerous new accounts, deploy large redundant contracts, or frequently write new state potentially more expensive. Meanwhile, applications primarily consuming immediate computational resources without persistently increasing state will find their fee structure more attractive.
Ultimately, Glamsterdam's gas reform shouldn't be simplistically understood as "across-the-board fee reduction." Instead, it clarifies how much immediate computational resource a transaction consumes versus the long-term storage burden it leaves on the network, then makes different operations pay in a way that more closely reflects their true physical cost.
Overall, these three parts, while seemingly independent, collectively point towards the same ultimate goal: to renovate the underlying core infrastructure in advance, paving the way for Ethereum's mainnet to further and significantly increase its Gas Limit and processing capacity.
II. Why Not Simply Make Blocks Bigger?
Many might wonder: if it's too slow and expensive, why not simply increase the Gas Limit and double the block capacity directly?
This is a perennial question. Theoretically, the most direct way to increase mainnet capacity is indeed to raise the maximum gas allowed per block. A higher Gas Limit means a block can accommodate more transactions and computations.
However, the Gas Limit is not a number that can be increased infinitely. Blindly enlarging blocks triggers a domino effect: nodes must receive more data, execute more transactions, and compute new states within the same timeframe. If processing speed can't keep up, weaker nodes are more likely to fall behind, block propagation and validation may experience delays, ultimately increasing the risk of network forks and centralization.
Simultaneously, more transactions also mean more accounts, contracts, and storage data permanently written to Ethereum's database. This data doesn't disappear after the transaction ends but continuously accumulates in Ethereum's state database, leading to faster state bloat.
Therefore, Ethereum scaling is not a simple arithmetic problem; it needs to solve three challenges simultaneously:
- First, how to give nodes more time to propagate and process larger blocks;
- Second, how to reduce the performance bottlenecks caused by serial transaction execution;
- Finally, how to prevent additional block space from rapidly translating into uncontrollable state inflation;
This is the core logic of Glamsterdam. Instead of scaling first and forcing nodes to bear the brunt, it first restructures the methods of block production, transaction execution, and resource pricing, clearing the underlying pipelines, and then naturally opening the door for increased mainnet capacity.
Among these, ePBS rearranges the block processing flow within a slot, giving nodes more time to propagate and validate larger blocks; BALs enhances client efficiency in reading, executing, and synchronizing by explicitly providing state access relationships; and Gas Repricing is responsible for limiting unsustainable state growth.
During the Glamsterdam collaboration test in April 2026, core developers conducted intensive stress testing around multi-client implementations and explicitly proposed a post-upgrade technical target of 200 million gas as a credible capacity floor. The underlying support for this target comes precisely from the combined foundation provided by ePBS, BALs, and state gas repricing.
Of course, 200 million gas is closer to the system's post-upgrade carrying capacity and a direction for future evolution. It does not mean the mainnet's Gas Limit will immediately jump to this level on the day Glamsterdam activates.
What truly matters is that Ethereum is shifting from a past approach of "cautious, incremental scaling" towards "preparing in advance for more substantial mainnet scaling through foundational structural overhaul."
III. How Will Ordinary Users and the Ethereum Ecosystem Be Affected?
From the perspective of ordinary users, the most concerning question about the Glamsterdam upgrade remains: will transaction fees decrease?
Overall, the answer leans more towards likely decreasing and becoming more stable, rather than all transactions becoming instantly cheaper.
Since ePBS and Block-Level Access Lists create conditions for a higher Gas Limit, it can be foreseen that the number of transactions each block can accommodate will definitely increase. With on-chain demand remaining constant, the increased supply of block space should naturally help alleviate congestion and reduce the probability of sudden Base Fee spikes.
However, the impact on individual transactions may vary depending on the operation. For example, simple ETH transfers may benefit from basic gas optimization; and because BALs inform about state paths in advance, wallets' accuracy in estimating gas fees will significantly improve. The poor experience of transaction failures and fees being deducted due to inaccurate wallet gas estimation during market volatility will become a thing of the past.
On the other hand, operations like deploying contracts, batch-creating accounts, or writing large amounts of new state might see increased costs due to state repricing. Therefore, Glamsterdam is more likely to result in lower costs for simple transactions, more stable fees during congestion periods, while simultaneously making state-intensive applications pay a more accurate price for the long-term network resources they occupy.
For users primarily on L2s, this upgrade is not irrelevant. By extending the data propagation window for execution payloads from about 2 seconds to about 9 seconds, ePBS not only supports larger mainnet blocks but also leaves room for Ethereum to handle more Blob data. With continued expansion of Blob capacity, Rollups will have more ample space to submit transaction data, which in the long run helps stabilize L2 data costs.
Additionally, a more user-perceptible change for wallets, exchanges, and cross-chain bridges might come from EIP-7708. Currently, ERC-20 token transfers typically generate standardized Transfer logs, but some native ETH transfers between smart contracts do not leave similarly clear event records. Wallets and trading platforms often need to rely on additional internal transaction tracing 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 bridges to more reliably identify deposits, withdrawals, and internal ETH movements within contracts. In the future, users may see more complete ETH asset records, and some internal transfers that previously required complex transaction tracing to display may be more easily recognized directly by wallets.
For node operators and stakers, the impact is more direct. Since Glamsterdam changes block processing methods on both the execution and consensus layers, nodes and validators need to upgrade to client versions supporting Glamsterdam before mainnet activation. Ordinary ETH holders do not need to migrate their ETH or perform any so-called "asset upgrades" or "token swaps."
Looking further ahead, what Glamsterdam truly impacts is how Ethereum rebalances the trade-off between scaling and decentralization. After all, if increased block capacity leads to a significant simultaneous rise in the hardware costs required to run a node, while mainnet throughput increases, the network might become increasingly reliant on large institutions.
The combination of ePBS, Block-Level Access Lists, and state gas repricing attempts to chart a different scaling path: not simply demanding nodes process more work in the same time, but rather reorganizing the block production flow, providing transaction dependency information in advance, and charging for different resources based on their actual burden.
This is the most fundamental difference between Glamsterdam and a simple Gas Limit increase. It doesn't attempt to solve all of Ethereum's problems with a single EIP, but simultaneously overhauls three interconnected mechanisms: block production, transaction execution, and state growth.
In Conclusion
In the long term, what Glamsterdam profoundly affects is the narrative direction of how Ethereum rebalances "high-performance scaling" with "absolute decentralization."
This also reflects Ethereum's increasingly familiar original intention or inherent tendency—in the face of competitive pressure from high-performance monolithic blockchains, instead of opting for a simple, brute-force increase in hardware requirements, it chooses a path that strives to maintain its decentralized ethos and possesses more fundamental resilience. Just like this time, through a combination of rewriting the block pipeline (ePBS), providing explicit transaction dependencies in advance (BALs), and making different resources pay precisely according to their physical burden (Gas Repricing), the aim is still to carve out greater mainnet capacity under the premise of ensuring ordinary people can run nodes and participate in validation.
From this perspective, every cost-effective gas fee we pay in the future, the more accurate and clear internal ETH transaction records in our wallets, and the broader space for L2 fee reductions will perhaps all deeply benefit from the foundational groundwork that Glamsterdam lays for Ethereum in the second half of 2026.
