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

According to the current official Ethereum roadmap, the Glamsterdam upgrade is scheduled to go live on the mainnet in the second half of 2026. As of the end of June, it has entered the final testing phase on the developer network, focusing on multi-client development and continuously testing core functions such as built-in PBS, block-level access lists, and gas repricing. However, 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 "mainnet hitting 10,000 TPS" after the upgrade. Beyond this, the upgrade has carried out a fundamental reconstruction of Ethereum's block production pipeline and execution engine. The depth of the changes and the breadth of their impact have led the developer community to widely acclaim it as "the largest upgrade since The Merge."

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

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

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

This is also the most authentic representation of Ethereum's current mission to "make L1 great again"—how to accommodate more transactions in L1 without increasing the costs of running nodes and the risks of network centralization.

However, for ordinary users, previous Ethereum upgrades have typically been simplified to a straightforward question: Will gas be cheaper? Will throughput be greater? But frankly, the upcoming Glamsterdam is difficult to summarize with simple terms like "cost reduction" or "scalability."

Overall, this upgrade involves multiple key aspects of Ethereum's underlying architecture, including who builds the blocks, how transactions are executed, how nodes read and synchronize states, as well as how much gas different on-chain operations should pay. It’s essentially redesigning the foundational paradigm for producing and processing blocks in Ethereum. According to the currently disclosed technical details, the most noteworthy core changes mainly focus on three aspects:

• Built-in PBS (ePBS): Restructuring the game between block proposers and builders, eliminating reliance on external relays;
• Block-Level Access Lists (BALs): Pre-mapping transaction execution to facilitate parallel processing and faster node synchronization;
• Gas Repricing: Introducing a more precise resource billing model to control state bloat in high-throughput environments;

First, to understand built-in PBS, it is important to know that blocks on Ethereum are not necessarily submitted directly by the Proposer. Especially under the current MEV-Boost architecture, the vast majority of Proposers outsource the work of collecting transactions, ordering them, and searching for MEV profits to professional block Builders, while Proposers primarily select the highest bid from multiple candidate blocks to submit to the network.

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

The problem is that the current system has not been fully integrated into Ethereum's underlying protocol—the Proposer and Builder must use off-protocol third-party software and MEV-Boost Relay services to complete block bidding, content delivery, and payment.

This means that the Relay has to ensure that Builders ultimately reveal the complete block while avoiding situations where the Proposer peeks at the block content prematurely and "eats black" by refusing payment, thus assuming a fragile and centralized "trusted intermediary" role.

The ePBS (Enshrined PBS) proposed in EIP-7732 aims to solve this pain point by incorporating this game theory directly into Ethereum's consensus protocol, eliminating third-party relays, making Builders participants recognized by the protocol from the onset, who first submit block commitments and bids, with the protocol automatically locking corresponding payments, and a dedicated "Payload Timeliness Committee" determining whether the Builder has published the execution payload on time.

This can decouple parts of the processing of consensus blocks and execution payload, allowing the propagation and processing window of execution payloads to extend from about 2 seconds to approximately 9 seconds. These few seconds may not seem significant, but they are crucial for Ethereum's scalability—it means that nodes have more time to receive and process larger blocks as well as more blob data, thereby freeing up space to further increase the Gas Limit.

Second, another core breakthrough of Glamsterdam at the execution layer is the Block-Level Access Lists (BALs) proposed in EIP-7928.

As is well known, Ethereum nodes cannot directly ascertain which accounts will be read, which contract storage will be accessed, and which states will be modified before obtaining a block. Instead, they typically discover these data dependencies gradually during the execution of transactions.

This is like entering a large warehouse to fetch items without a complete list of item locations. The staff can only search while processing, so to avoid two people modifying the same batch of inventory simultaneously, a lot of work must be completed in a strict sequential order (single-threaded serial execution).

Block-Level Access Lists (BALs) essentially attach a complete "state access map" to each block. They declare in the block header which addresses and storage slots the set of transactions within that block will access and the resulting states after transaction execution. With this map, nodes can quickly assess which transactions will access the same data and which transactions are conflict-free before execution:

For conflict-free portions, nodes can pre-read related states from the hard drive and parallel process parts of transaction verification and state root calculations, rather than jamming all work into a strictly serial queue. Additionally, as BALs also record state changes after transaction completion, some nodes can utilize these results for state reconstruction when synchronizing and catching up with network status, eliminating the need to execute every single transaction in the block from scratch in all scenarios (the author personally perceives a hint of sharding philosophy here), allowing Ethereum to become a fully parallel executing blockchain.

Thus, in the long term, this is also the key to Ethereum mainnet breaking through performance ceilings.

Lastly, Gas repricing consists of a thorough recalibration of gas pricing for multiple on-chain operations through economic leverage.

The reason is that the current gas costs on Ethereum do not completely match the actual resource consumption borne by nodes. For instance, a purely complex calculation usually does not leave much long-term burden on nodes after execution, but creating a new account, deploying a smart contract, or writing a new storage slot generates data that needs to be permanently stored by all global full nodes.

In the past, the fees for these state-creation actions did not fully reflect the permanent storage costs they incurred (state explosion). If Ethereum maintains its original pricing after increasing the gas limit, more block space may rapidly transform into uncontrollable state data, ultimately crashing the hardware of nodes.

EIP-8037, which has been confirmed as part of the Glamsterdam upgrade, intends to fundamentally reform this rule. This includes separating calculation and state accounting to recalculate costs based on the volume of newly added state data, differentiating ordinary computation gas from state gas; and controlling state explosion so that applications creating large numbers of new accounts, deploying large redundant contracts, or frequently writing new states may face increased operational costs, while applications mainly consuming immediate computing resources without continuously increasing state will have more attractive fee structures.

Ultimately, Glamsterdam's gas reform cannot be simply understood as "a comprehensive cost reduction," but rather clarifying how much immediate computational resources are consumed by a transaction and what long-term storage burden is left for the network, then allowing different operations to pay in a manner more closely aligned with actual physical costs.

Overall, these three parts may seem independent, but they actually point towards the same ultimate goal: to significantly increase the gas limit and processing capacity of the Ethereum mainnet by preemptively improving the core infrastructure underneath.

2. Why can't we just increase block sizes directly?

Many people may wonder, since we find it slow and expensive, why not simply increase the gas limit and double the block capacity directly?

This is an often-discussed issue. Theoretically, increasing the mainnet capacity could indeed be achieved most directly by raising the gas limit allowed per block, 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 adjusted indefinitely. If blocks are blindly made larger, it will trigger a domino effect: nodes need to receive more data, execute more transactions, and compute new states within the same time frame. If processing speeds do not keep up, weaker-configured nodes are more likely to fall behind, and there might be delays in block propagation and verification, ultimately increasing the risks of network forks and centralization.

At the same time, more transactions mean more accounts, contracts, and storage data permanently written into the Ethereum database, and this data will not automatically disappear once transactions are finished but will continue to accumulate in Ethereum's state database, leading to faster state inflation.

Therefore, the challenge of scaling Ethereum is not a simple mathematical problem, but requires solving three problems simultaneously:

• First, how to leave more time for nodes to propagate and process large blocks;
• Second, how to reduce performance bottlenecks caused by executing transactions one after another;
• Lastly, how to prevent more block space from rapidly transforming into difficult-to-control state inflation;

This embodies the core logic of Glamsterdam—not to blindly scale up first and then force nodes to bear the weight, but to reconstruct the methods of block production, transaction execution, and resource pricing first, clearing the pipeline from the bottom up, and then naturally opening the door to increase mainnet capacity.

ePBS improves the processing flow of blocks within slots, allowing more time for nodes to propagate and verify large blocks; BALs provide explicit state access relationships, enhancing client reading, execution, and synchronization efficiency; gas repricing controls unsustainable state growth.

In the collaborative testing of Glamsterdam conducted in April 2026, core developers conducted centralized stress tests around multi-client implementations and clearly set a technical goal of 200 million gas as the credible capacity lower limit post-upgrade. Behind this goal lie the foundational supports jointly provided by ePBS, BALs, and state gas repricing.

Of course, 200 million gas is closer to the carrying capacity of the upgraded system and the direction for gradual evolution in the future, but it does not mean that the mainnet will immediately elevate the gas limit to this level on the day Glamsterdam is activated.

What truly matters is that Ethereum is shifting from cautious trial expansion in the past to "preparing for larger-scale mainnet expansion through structural reconstruction at the bottom level."

3. What impacts will ordinary users and the Ethereum ecosystem experience?

From the ordinary user's perspective, the most pressing concern regarding the Glamsterdam upgrade is whether transaction fees will decrease.

Overall, the answer is more likely to be a hopeful decrease and greater stability rather than that all transactions will become cheaper overnight.

Since ePBS and block-level access lists create conditions for a higher gas limit, it is foreseeable that the volume of transactions each block can accommodate will certainly increase; therefore, with on-chain demand remaining unchanged, the increase in block space supply will naturally help alleviate congestion and reduce the likelihood of sudden spikes in the base fee.

However, when it comes to individual transactions, changes in operational costs may not be consistent. For example, regular ETH transfers might benefit from the optimization of basic gas; and since BALs provide a prior notice of the state path, wallets will greatly enhance their accuracy when estimating gas fees, eliminating the frustrating experience in which historical market volatility led to inaccurate gas estimations by wallets, thus resulting in transaction failures while still incurring fees.

On the other hand, deploying contracts, batch creating accounts, or writing a large amount of new state may incur increased costs due to state repricing. Therefore, Glamsterdam is more likely to result in simple transaction costs decreasing and fees becoming more stable during congestion periods, while state-intensive applications begin to pay more accurately for the long-term occupation of network resources.

For users primarily utilizing L2, this upgrade is not irrelevant. ePBS extends the data propagation window of execution payloads from about 2 seconds to about 9 seconds, not only supporting larger mainnet blocks but also creating space for Ethereum to handle more blob data. As blob capacity continues to expand, Rollup submission of transaction data will be more abundant, which in the long term helps stabilize L2 data costs.

Additionally, a more noticeable change for wallets, exchanges, and cross-chain bridges might come from EIP-7708. Currently, ERC-20 Token transfers typically generate standardized Transfer logs, but native ETH transfers between certain smart contracts do not leave the same clear event records, requiring wallets and trading platforms to often rely on additional internal transaction tracking tools to recognize this portion of ETH flow.

As EIP-7708 mandates that non-zero ETH transfers and ETH destruction operations generate standard logs, wallets, exchanges, and cross-chain bridges will be able to more reliably recognize ETH fluctuations for deposits, withdrawals, and internal contract activities, meaning that future users will likely see more complete ETH asset records. Some internal transfers that previously required complex transaction tracking to be displayed will also be easier for wallets to directly recognize.

For node operators and staking users, the impact is even more direct. Glamsterdam simultaneously alters the block processing methods at the execution layer and consensus layer, so nodes and validators need to upgrade to support a Glamsterdam-compatible client version before mainnet activation. Ordinary holding users do not need to migrate ETH nor undergo any so-called "asset upgrades" or "token exchanges."

In the long-term view, what Glamsterdam truly impacts is how Ethereum finds a new balance between scalability and decentralization. After all, if the hardware costs required to run nodes sharply rise after increasing block capacity, although the mainnet throughput has increased, the network may increasingly depend on large institutions.

Conversely, the combination of ePBS, block-level access lists, and state gas repricing attempts to form an alternative path to scalability: not simply demanding nodes handle more work within the same timeframe, but rearranging the block production process, providing transaction dependency information in advance, and charging different resources based on actual burdens.

This is fundamentally what sets Glamsterdam apart from a simple increase in gas limit; it does not attempt to resolve all of Ethereum's problems through a single EIP but instead simultaneously transforms three interrelated mechanisms regarding block production, transaction execution, and state growth.

Conclusion

In the long run, what Glamsterdam profoundly influences is the narrative direction of Ethereum searching for balance between "high-performance scalability" and "absolute decentralization."

This reflects Ethereum's original intention or inertia—rather than opting for a drastic measure of increasing hardware thresholds in response to the relentless pressure from high-performance monolithic chains, it has chosen a path that strives to maintain its decentralized essence and foster greater foundational resilience, much like this time, with the combination of rewriting the block production pipeline (ePBS), providing explicit transaction dependency information in advance (BALs), and enabling differentiated resource pricing based on physical burdens (gas repricing), still aiming to extract a larger mainnet capacity while ensuring ordinary people can run nodes and participate in validation.

From this perspective, every reasonable gas fee we pay in the future, clearer internal ETH billing in wallets, and the broader scope for L2 fee reductions might all deeply benefit from the foundational restructuring that Glamsterdam is set to deliver in the second half of 2026 for Ethereum.

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