Author: imToken
Ethereum's next major upgrade has entered its final sprint.
According to the current official Ethereum roadmap, the Glamsterdam upgrade is planned to officially launch on the mainnet in the second half of 2026. As of the end of June, it has also entered the final testing phase on the developer network. Testing is continuously underway on the multi-client development network, focusing on core features such as enshrined PBS, block-level access lists, and Gas repricing. However, the specific activation time has not been finalized.
Meanwhile, on major social media platforms, the most talked-about aspect is undoubtedly the performance narrative of "mainnet reaching 10,000 TPS" after the upgrade. But beyond that, this upgrade fundamentally reconstructs Ethereum's block production pipeline and execution engine. Its depth of changes and wide-reaching impact have led the developer community to widely acclaim it as "the largest-scale upgrade since The Merge."
So, what exactly does this 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 disruptive changes will it bring to our daily on-chain experience?
I. Why is it the "Largest-Scale 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 overhaul of L1 performance and architecture.
This is also the underlying reality of Ethereum's current "make L1 great again" ethos: how to allow L1 to handle more transactions without simultaneously increasing the cost of running nodes and the risk of network centralization.
However, for ordinary users, Ethereum upgrades are often simplified into one most intuitive question: Will Gas become cheaper? Will throughput increase? To be honest, the upcoming Glamsterdam is difficult to summarize simply with "fee reduction" or "scaling."
Overall, this upgrade involves multiple key aspects of Ethereum's underlying layer, 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 aims to redesign the fundamental paradigm for how Ethereum produces and processes blocks. According to the currently disclosed technical details, the most noteworthy core changes are mainly in three areas:
- Enshrined PBS (ePBS): Restructures the relationship between block proposers and builders, eliminating reliance on external relays;
- Block-Level Access Lists (BALs): Maps out transaction execution paths in advance, 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 needs to know that blocks on Ethereum are not necessarily submitted by the Proposer themselves. Especially under the current MEV-Boost architecture, most Proposers outsource the work of collecting transactions, ordering them, and seeking MEV opportunities to professional Block Builders. The Proposer is primarily responsible for choosing the highest-bidding candidate block from several options and submitting it to the network.
This division of labor, where "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 ultimately disclose the full block while also preventing Proposers from "stealing" block content in advance and refusing payment. Therefore, Relays act as fragile and centralized "trusted middlemen."
The ePBS (Enshrined PBS) proposed by EIP-7732 aims to solve this pain point by incorporating this博弈关系 directly into Ethereum's consensus protocol itself. It eliminates third-party relays, making Builders protocol-native participants. Builders first submit a block commitment and bid, the protocol automatically locks the corresponding payment, and a dedicated "Payload Timeliness Committee" judges whether the Builder timely disclosed the execution payload.
This decouples part of 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 have more time to receive and process larger blocks and more Blob data, thereby creating room for further increasing the Gas Limit.
Secondly, another core breakthrough of Glamsterdam on the execution layer is the 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 before receiving it. Instead, they typically discover these data dependencies gradually during transaction execution.
This is like entering a large warehouse to pick goods without a complete inventory list. Workers must search and process simultaneously, so to avoid two people modifying the same batch of inventory, much of the work must be done strictly in a fixed order (single-threaded serial execution).
Block-Level Access Lists (BALs) act as a complete "state access map" attached to each block. They declare in the block header in advance which addresses and Storage Slots the set of transactions within that block will touch, as well as the state results after transaction execution. With this map, nodes can judge at a glance which transactions will access the same data and which are independent before execution:
For the independent parts, nodes can pre-fetch relevant state data from the hard drive and process transaction validation and state root calculation in parallel for some transactions, instead of cramming all work into a strictly serial queue. Additionally, since BALs also record state changes after transaction completion, some nodes can use these results for state reconstruction during network synchronization and catch-up, without having to execute every single transaction in the block from scratch in all scenarios (the author's personal understanding leans towards a sharding-like concept), potentially moving Ethereum towards a more parallel execution 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 is Gas repricing, which fundamentally recalibrates the Gas pricing for various on-chain operations through economic levers.
The reason is that the current Gas cost on Ethereum does not fully match the actual resource consumption borne by nodes. For example, a purely complex computation typically doesn't leave a long-term burden on nodes after execution. 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.
In the past, the fees for these state-creating actions did not fully reflect the permanent storage costs they incur (state explosion). If Ethereum maintained its original pricing after increasing the Gas Limit, more block space could rapidly transform into uncontrollable state data, eventually 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 general computation Gas and state Gas. It also controls state explosion, meaning operations that create many new accounts, deploy large redundant contracts, or frequently write new state may see increased costs. Conversely, applications primarily consuming immediate computational resources without persistently increasing state will have a more attractive fee structure.
Ultimately, the Gas reform in Glamsterdam cannot be simplistically understood as a "comprehensive fee reduction." Instead, it clarifies how much immediate computational resource a transaction consumes and what long-term storage burden it leaves on the network, then makes different operations pay in a way closer to their true physical cost.
Overall, these three parts, while seemingly independent, jointly point toward the same ultimate goal: to renovate the underlying core infrastructure in advance for Ethereum's mainnet to further and significantly increase Gas Limit and processing capacity.
II. Why Not Just Make Blocks Bigger?
Many might wonder: since it's slow and expensive, why not just increase the Gas Limit and double the block capacity directly?
This is a frequently asked question. In theory, the most direct way to increase mainnet capacity is indeed to raise the maximum Gas allowed per block. A higher Gas Limit means more transactions and computations can fit into one block.
However, the Gas Limit is not a number that can be increased indefinitely. Blindly enlarging blocks triggers a domino effect: nodes need to receive more data, execute more transactions, and calculate new state within the same timeframe. If processing speed can't keep up, nodes with weaker configurations are more likely to fall behind, block propagation and validation may experience delays, ultimately increasing the risk of network forks and centralization.
Meanwhile, more transactions also mean more accounts, contracts, and storage data permanently written into Ethereum's database. This data doesn't automatically disappear after transactions end but accumulates in Ethereum's state database, leading to faster state bloat.
Therefore, Ethereum scaling is not a simple math problem; it needs to solve three problems simultaneously:
- First, how to give nodes more time to propagate and process larger blocks;
- Second, how to reduce performance bottlenecks caused by sequential transaction execution;
- Finally, how to prevent more block space from rapidly transforming into uncontrollable state bloat;
This is the core logic of Glamsterdam. Instead of blindly 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 pipeline, then naturally opens the door for increasing mainnet capacity.
Specifically, ePBS reorganizes the block processing flow within a slot, giving nodes more time to propagate and validate larger blocks; BALs improve client efficiency in reading, executing, and synchronizing by explicitly providing state access relationships; Gas repricing is responsible for limiting unsustainable state growth.
During the collaborative Glamsterdam test in April 2026, core developers conducted focused stress tests around multi-client implementations and explicitly set the technical goal of a credible capacity lower bound of 200 million Gas after the upgrade. Supporting this target is the combined underlying foundation provided by ePBS, BALs, and state Gas repricing.
Of course, 200 million Gas is closer to the system's carrying capacity post-upgrade and the direction for future evolution. It does not mean the mainnet will immediately jump its Gas Limit to this level on the day Glamsterdam activates.
What's truly important is that Ethereum is shifting from past "cautious, tentative scaling" toward "preparing in advance for more substantial mainnet scaling through underlying structural reconstruction."
III. How Will Ordinary Users and the Ethereum Ecosystem Be Affected?
From an ordinary user's perspective, the most relevant question regarding the Glamsterdam upgrade is still whether transaction fees will decrease.
Overall, the answer leans more towards likely decreasing and becoming more stable, rather than all transactions instantly becoming cheaper.
Since ePBS and block-level access lists create conditions for a higher Gas Limit, it's foreseeable that the number of transactions each block can accommodate will definitely increase. If on-chain demand remains constant, the increased supply of block space naturally helps alleviate congestion and reduces the probability of sudden Base Fee spikes.
However, for individual transactions, the impact may vary depending on the operation. For example, simple ETH transfers may benefit from base Gas optimizations; and since BALs provide state paths in advance, wallet accuracy in estimating Gas fees will significantly improve. The糟糕体验 of past failed transactions due to inaccurate wallet Gas estimates during market volatility—yet still paying fees—will become history.
On the other hand, operations like deploying contracts, batch-creating accounts, or writing large amounts of new state may see increased costs due to state repricing. Therefore, Glamsterdam is more likely to result in decreased costs for simple transactions, more stable fees during congested periods, while state-intensive applications start paying a more accurate price for the long-term network resources they occupy.
For users primarily using L2s, this upgrade is not irrelevant. By extending the data propagation window for execution payloads from about 2 seconds to about 9 seconds, ePBS can not only support larger mainnet blocks but also leaves more room for Ethereum to handle more Blob data. After Blob capacity continues to expand, Rollups will have more space to submit transaction data, which in the long run helps stabilize L2 data costs.
Furthermore, for wallets, exchanges, and cross-chain bridges, a more user-perceivable change might come from EIP-7708. Currently, ERC-20 token transfers typically generate standardized Transfer logs. However, some native ETH transfers between smart contracts do not leave equally clear event logs. Wallets and trading platforms often need to rely on additional internal transaction tracing tools to identify these ETH flows.
EIP-7708 requires non-zero ETH transfers and ETH destruction operations to generate standard logs, allowing wallets, exchanges, and cross-chain bridges to more reliably identify deposits, withdrawals, and internal ETH movements within contracts. In the future, users' ETH asset records may become more complete, and some internal transfers that previously required complex transaction tracing to display might be more easily recognized directly by wallets.
For node operators and stakers, the impact is more direct. Glamsterdam changes both execution and consensus layer block processing methods, so nodes and validators need to upgrade to client versions supporting Glamsterdam before mainnet activation. Ordinary token holders do not need to migrate ETH or perform any so-called "asset upgrades" or "token swaps."
Looking further ahead, what Glamsterdam truly affects is how Ethereum rebalances scaling and decentralization. After all, once block capacity increases, if the hardware cost required to run a node rises significantly in tandem, while mainnet throughput increases, the network may become increasingly reliant on large institutions.
The combination of ePBS, block-level access lists, and state Gas repricing attempts to form another scaling path: not simply demanding nodes handle more work in the same timeframe, but reorganizing the block production flow, providing transaction dependency information in advance, and charging different resources according to their actual burden.
This is also the most fundamental difference between Glamsterdam and a simple Gas Limit increase. It does not attempt to solve all of Ethereum's problems with a single EIP but simultaneously reforms three interrelated mechanisms: block production, transaction execution, and state growth.
In Conclusion
In the long term, what Glamsterdam profoundly influences is the narrative direction of how Ethereum rebalances between "high-performance scaling" and "absolute decentralization."
This is also the初心 or inertia of Ethereum that we are becoming increasingly familiar with—facing the步步紧逼 of high-performance monolithic blockchains, it chooses not to take the简单粗暴 route of raising hardware requirements. Instead, it selects a path that strives to maintain its decentralized底色, offering greater underlying resilience. Just like this time, through the combination拳 of rewriting the block pipeline (ePBS), explicitly providing transaction dependencies in advance (BALs), and making different resources pay precisely according to their physical burden (Gas repricing), it is still to carve out greater mainnet capacity while ensuring ordinary people can run nodes and participate in validation.
From this perspective, every划算 Gas fee we pay in the future, the more accurate and clear internal ETH statements in our wallets, and the broader space for fee reductions on L2s may all deeply benefit from the foundation that Glamsterdam lays for Ethereum in the second half of 2026.
