Written by: imToken

The next major upgrade of Ethereum has entered the sprint phase.

According to the current official Ethereum roadmap, the Glamsterdam upgrade is scheduled 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 of the developer network, and core functions such as built-in PBS, block-level access lists, and gas repricing are continuously being tested around a multi-client development network, although the specific activation time has not yet been finalized.

Meanwhile, the most discussed topic on major social media platforms is undoubtedly the intuitive performance narrative of "the mainnet hitting 10,000 TPS" after the upgrade. Beyond that, this upgrade has fundamentally reconstructed Ethereum’s block production pipeline and execution engine. Its profound changes and wide-ranging impacts have been widely praised by the developer community as "the largest upgrade since The Merge."

So, what exactly has changed with the somewhat cool-sounding name "Glamsterdam" (a combination of the consensus layer upgrade Gloas and the execution layer upgrade Amsterdam)? How will it bid farewell to past pain points, and what disruptive changes will it bring to our everyday on-chain experience?

1. Why is it "the largest upgrade since The Merge"?

If previous upgrades like Dencun and Fusaka mainly paved the way for L2 data availability (Blob), Glamsterdam shifts the focus back to L1, initiating a major overhaul of L1 performance and architecture.

This also reflects Ethereum's current aspiration to "make L1 great again," which involves accommodating more transactions without increasing the costs for running nodes and the risks of network centralization.

However, for ordinary users, historically, Ethereum upgrades have usually been simplified to one intuitive question: Will gas be cheaper? Will throughput be higher? To be honest, the upcoming Glamsterdam is hard to summarize simply as "cost reduction" or "capacity expansion."

Overall, this upgrade involves multiple key aspects of Ethereum's underlying structure, including who constructs the block, how transactions are executed, how nodes read and synchronize states, and how much gas should be paid for various on-chain operations. This effectively means redesigning Ethereum’s fundamental paradigm of block production and processing, and according to the currently disclosed technical details, the most noteworthy core changes focus on three aspects:

• Built-in PBS (ePBS): Restructures the game-theoretic relationship between block proposers and builders, eliminating reliance on external relays;
• Block-level Access Lists (BALs): Pre-maps transaction execution to pave the way for parallel processing and faster node synchronization;
• Gas Repricing: Introduces a more precise resource billing model to control state explosion in high-throughput environments;

First, to understand built-in PBS, it is essential 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 tasks of collecting transactions, arranging orders, and seeking MEV profits to specialized block builders, while the proposer mainly selects the highest bid among multiple candidate blocks to submit to the network.

This division of labor, where builders are responsible for assembly and proposers for submission, is known as PBS (Proposer-Builder Separation).

However, the problem is that the current mechanism has not been fully integrated into Ethereum's underlying protocol—proposers and builders must rely on third-party software outside the protocol and MEV-Boost Relay service to complete block bidding, content delivery, and payments.

This implies that the relay must ensure that builders eventually fully disclose the block while also preventing proposers from "black-eating" by peeking at block contents and refusing payment, thus taking on the frail, centralized role of a "trust intermediary."

The ePBS proposed in EIP-7732 seeks to resolve this pain point by directly incorporating this game-theoretic relationship into Ethereum’s consensus protocol itself, eliminating the need for third-party relays, allowing builders to become protocol-native participants, submitting block commitments and bids first, and the protocol automatically locking corresponding payments, which will then be judged by a specialized "Payload Timeliness Committee" whether the builder timely disclosed the execution payload.

This allows for separating parts of the consensus block and execution payload handling process, extending the window for propagating and processing the execution payload from about 2 seconds to about 9 seconds. These few seconds may seem insignificant but are crucial for Ethereum’s scaling—indicating that nodes can have more time to receive and process larger blocks and more blob data, thereby freeing up space for further increases in the gas limit.

Secondly, another core breakthrough of Glamsterdam in the execution layer is the block-level access lists (BALs) proposed in EIP-7928.

As is well known, currently Ethereum nodes cannot directly know which accounts each transaction will read, which contract storage will be accessed, or which states will be modified before receiving a block; they usually have to gradually discover these data dependencies during the transaction execution process.

This is akin to entering a large warehouse to collect goods without a complete inventory list. Staff can only search while processing transactions, necessitating that a lot of work must be strictly completed in a fixed order (single-threaded serially) to avoid two people modifying the same batch of stock simultaneously.

Block-level access lists (BALs) are equivalent to attaching a complete "state access map" to each block. They pre-declare, in the block header, which addresses and storage slots the collection of transactions within that block will reach, as well as the resulting state after transaction execution. Through this map, nodes can instantly determine which transactions will access the same data and which will not conflict before execution:

This means that for non-conflicting portions, nodes can read the relevant states from the hard disk in advance, perform partial transaction validations and state root calculations in parallel, without having to queue all work in a strictly serial manner. Furthermore, since BALs also record state changes post-transaction, certain nodes can utilize these results for state reconstruction while synchronizing and catching up with network status instead of executing every transaction in the block from scratch in all scenarios (which the author personally interprets with a hint of sharding concept), enabling Ethereum to become a fully parallel-executing blockchain.

Thus, in the long run, this also serves as a foundational key for Ethereum's mainnet to break performance ceilings.

Finally, gas repricing primarily involves extensive calibration of gas pricing for multiple on-chain operations through economic leverage.

The reason is that the current gas costs of Ethereum do not fully align with the resource consumption actually borne by nodes. For example, a complex computation executed typically does not leave much long-term burden on nodes, but creating a new account, deploying a smart contract, or writing into a new storage slot generates data that all full nodes worldwide must permanently store.

In the past, the costs associated with these state-creating behaviors have not fully reflected their resulting permanent storage costs (state explosion). If Ethereum maintains the original pricing after increasing the gas limit, more block space may rapidly convert into uncontrollable state data, ultimately overwhelming the hardware of nodes.

EIP-8037, which has been confirmed to be included in Glamsterdam, is preparing to entirely reconstruct this rule. It involves computing and state separation accounting so that costs are recalibrated based on the volume of newly added state data, separating ordinary computation gas from state gas; it will also control state surges, meaning that creating large numbers of new accounts, deploying large redundant contracts, or frequently writing new states would see operational costs potentially increase, while applications primarily consuming immediate computational resources without continuously increasing state would experience a more attractive fee structure.

Ultimately, the gas reform of Glamsterdam cannot simply be understood as a "comprehensive cost reduction" but is about clarifying how much immediate computational resource a transaction consumes and how much long-term storage burden it places on the network, allowing different operations to pay in a manner closer to their actual physical costs.

Overall, these three parts seem independent but actually point towards the same ultimate goal: to further significantly increase the gas limit and processing capacity of Ethereum’s mainnet, by preparing the foundational core infrastructure.

2. Why not simply increase the block size?

Many might wonder, if slow and costly, why not directly increase the gas limit and double the block capacity?

This is a cliché question. Theoretically, the most straightforward way to increase the capacity of the mainnet is to raise the gas limit that each block is allowed to use. After all, the higher the gas limit, the more transactions and computations a block can accommodate.

However, the gas limit is not a number that can be infinitely increased; blindly enlarging blocks will trigger a domino effect: nodes need to receive more data, execute more transactions, and compute new states within the same time frame. If the processing speed cannot keep up, nodes with weaker configurations are more likely to fall behind, and block propagation and verification may face delays, ultimately increasing the risks of network forks and centralization.

Moreover, more transactions also mean more accounts, contracts, and storage data permanently written into the Ethereum database. This data will not automatically disappear once the transaction concludes but will continuously accumulate in Ethereum's state database, leading to faster state expansion.

Therefore, Ethereum’s scaling challenge is not a simple mathematical issue but requires addressing three simultaneous problems:

• First, how to leave more time for nodes to propagate and process large blocks;
• Second, how to reduce the performance bottlenecks caused by sequential execution of transactions;
• Finally, how to prevent more block space from quickly converting into uncontrollable state explosion;

This encapsulates the core logic of Glamsterdam; it is not about blindly expanding capacity first and then forcing nodes to cope, but about restructuring the way blocks are produced, transactions are executed, and resources are priced, smoothing out the underlying pipelines first, then naturally opening the doors for increasing the capacity of the mainnet.

In this context, ePBS rearranges the block processing workflow within slots, giving nodes more time to propagate and verify large blocks; BALs explicitly provide state access relationships, enhancing the efficiency of clients in reading, executing, and synchronizing; while gas repricing aims to limit unsustainable state growth.

In the cooperative tests of Glamsterdam in April 2026, core developers conducted centralized stress tests focused on multi-client implementations and explicitly set a technical target of 200 million gas as a reliable capacity lower limit after the upgrade. Behind this goal lie the foundational support provided by ePBS, BALs, and state gas repricing.

Of course, 200 million gas is closer to the carrying capacity that the upgraded system is expected to possess and the future direction it can gradually evolve towards; it does not mean that the mainnet will immediately raise the gas limit to this level on the day Glamsterdam is activated.

What is truly important is that Ethereum is transitioning from past "tentative cautious expansions" to "preparing for larger-scale mainnet expansions through underlying structural reconstruction."

3. How will ordinary users and the Ethereum ecosystem be affected?

From the perspective of ordinary users, the most concerning issue regarding the Glamsterdam upgrade is still whether transaction fees will decrease.

Overall, the answer leans toward a hopeful decrease and becoming more stable, rather than all transactions immediately becoming cheaper.

As 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. Thus, if on-chain demand remains unchanged, with an increase in block space supply, this will help alleviate congestion and reduce the probability of sudden spikes in the base fee.

However, when it comes to individual transactions, the changes may not be consistent across different operations. For instance, ordinary ETH transfers may benefit from basic gas optimization; since BALs inform the state paths in advance, wallets will greatly improve in accuracy when estimating gas fees, and the poor experience of transaction failures due to volatility that resulted in inaccurate wallet gas estimates will become a thing of the past.

However, operations like deploying contracts, bulk creating accounts, or writing a large number of new states may increase costs due to state repricing. Therefore, the outcome brought about by Glamsterdam is more likely to be a decrease in simple transaction costs, more stable fees during congestion periods, while state-intensive applications begin to pay more accurate prices for the network resources they occupy in the long term.

For users primarily using L2, this upgrade is also relevant. ePBS extends the data propagation window for execution payloads from about 2 seconds to about 9 seconds, not only supporting larger mainnet blocks but also leaving room for Ethereum to handle more blob data. After the blob capacity continues to expand, the space for Rollup to submit transaction data will be more abundant, which in the long run helps stabilize the data costs for L2.

Moreover, for wallets, exchanges, and cross-chain bridges, a more noticeable change for users may arise from EIP-7708. Currently, ERC-20 token transfers usually generate standardized transfer logs, but some native ETH transfers between smart contracts do not leave the same clear event records. Wallets and trading platforms often need to rely on additional internal transaction tracking tools to identify this portion of ETH flow.

EIP-7708 requires non-zero ETH transfers and ETH destruction operations to generate standard logs, allowing wallets, exchanges, and cross-chain bridges to reliably identify deposits, withdrawals, and internal ETH movements in contracts. This means that future users may see more complete ETH asset records, and some internal transfers that previously required complex transaction tracking to display will be more easily recognized directly by wallets.

For node operators and staking users, the impact is even more direct. Glamsterdam simultaneously changes the block handling methods of both the execution layer and the consensus layer. Therefore, nodes and validators need to upgrade to client versions that support Glamsterdam before the mainnet activation. Ordinary token holders do not need to migrate ETH or undertake any so-called "asset upgrades" or "token exchanges."

In the longer term, what Glamsterdam truly affects is how Ethereum seeks to rebalance between scaling and decentralization. After all, once block capacity increases, if the hardware costs required to run nodes increase drastically, although the mainnet throughput may rise, the network may increasingly depend on large institutions.

The combination of ePBS, block-level access lists, and state gas repricing attempts to form another scaling approach: rather than simply requiring nodes to handle more work in the same time frame, it rearranges the block production process, provides transaction dependency information in advance, and charges different resources according to actual burdens.

This is where Glamsterdam fundamentally differs from a typical gas limit increase; it does not attempt to solve all of Ethereum's problems through a single EIP, but instead simultaneously transforms three interrelated mechanisms of block production, transaction execution, and state growth.

In conclusion

In the long run, what Glamsterdam profoundly impacts is the narrative direction of Ethereum in rediscovering balance between "high-performance scaling" and "absolute decentralization."

This also reflects the increasingly familiar ethos of Ethereum—facing the relentless pressure of high-performance monolithic blockchains, it does not opt for a simplistic and brutal increase in hardware thresholds but chooses a path that seeks to maintain decentralization while enhancing underlying resilience, such as through the combination of rewriting the block pipeline (ePBS), providing transaction dependency information in advance (BALs), and precisely charging different resources based on physical burdens (gas repricing), all in order to extract greater mainnet capacity while ensuring that ordinary individuals can run nodes and participate in validation.

From this perspective, every cost-effective gas fee we pay in the future, clearer and more accurate internal ETH accounting in wallets, and broader rate reduction space for L2 may be deeply benefited from the foundational work that Glamsterdam lays for Ethereum in the second half of 2026.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。