The biggest upgrade since The Merge? How will Glamsterdam affect Ethereum?

Ethereum's next major upgrade has entered its final sprint phase.

According to the current Ethereum official roadmap, the Glamsterdam upgrade is planned to go live on the mainnet in the second half of 2026. As of the end of June, it has also entered the final testing phase on developer networks. Multi-client devnets are currently engaged in continuous testing of core functionalities such as enshrined PBS, block-level access lists, and Gas repricing. However, the specific activation date has not yet been finalized.

Meanwhile, across various social media platforms, the most discussed topic is undoubtedly the upgrade's straightforward performance narrative of "mainnet hitting 10,000 TPS." But beyond this, the upgrade fundamentally restructures Ethereum's block production pipeline and execution engine. Its depth and breadth of changes have led the developer community to widely hail it as "the most significant upgrade since The Merge."

So, what exactly does this cool-sounding name, "Glamsterdam" (a portmanteau of the consensus layer upgrade Gloas and the execution layer upgrade Amsterdam), entail? How will it address past pain points, and what transformative changes will it bring to our everyday on-chain experience?

1. Why is it the "Most Significant Upgrade Since The Merge"?

If previous upgrades like Dencun and Fusaka primarily paved the way for L2 data availability (Blobs), then Glamsterdam refocuses efforts back onto L1, initiating a major overhaul of L1 performance and architecture.

This truly reflects Ethereum's current underlying ambition to "make L1 great again"—figuring out how to enable L1 to accommodate more transactions without simultaneously increasing the cost of running a node and the risk of network centralization.

For average users, however, Ethereum upgrades are often distilled into one key question: Will Gas fees become cheaper? Will throughput increase? But honestly, the upcoming Glamsterdam upgrade is difficult to summarize simply with terms like "fee reduction" or "scaling."

Overall, this upgrade touches upon several 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 cost. It essentially aims to redesign the fundamental paradigm of how Ethereum produces and processes blocks. Based on the technical details disclosed so far, the core changes worth focusing on are primarily concentrated in three areas:

• Enshrined PBS (ePBS): Restructuring the game-theoretic relationship between block proposers and builders, eliminating reliance on external relays.
• Block-Level Access Lists (BALs): Pre-mapping transaction execution paths, paving the way for 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 enshrined PBS, one needs to know that blocks on Ethereum are not necessarily proposed 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 capturing MEV opportunities to specialized block Builders. The Proposer's main role is to select the highest-bidding block from several candidates and submit it to the network.

This division of labor—where "Builders assemble, Proposers propose"—is Proposer-Builder Separation (PBS).

The problem, however, is that this mechanism is not fully integrated into Ethereum's base protocol. Proposers and Builders must rely on third-party software outside the protocol, specifically the MEV-Boost Relay service, to handle block bids, content delivery, and payments.

This means the Relay acts as a fragile and centralized "trusted intermediary." It must ensure the Builder eventually reveals the complete block, while also preventing the Proposer from "stealing" the block content and refusing to pay. This creates a vulnerable and centralized point of trust.

EIP-7732, which proposes ePBS (Enshrined PBS), aims to solve this pain point by integrating this game-theoretic interaction directly into Ethereum's consensus protocol. It would eliminate the third-party relay, making the Builder a natively recognized participant in the protocol. The Builder would first submit a block commitment and bid, the protocol would automatically lock in the corresponding payment, and a specialized "Payload Timeliness Committee" would verify whether the Builder revealed the execution payload on time.

This separation of the consensus block and execution payload processing allows the window for the execution payload's propagation and processing to be extended from roughly 2 seconds to about 9 seconds. These few extra seconds, seemingly small, are critical for Ethereum scaling—they give nodes more time to receive and process larger blocks and more Blob data, thereby creating room to further increase the Gas Limit.

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

Currently, before an Ethereum node receives a block, it cannot directly know which accounts each transaction will read, which contract storage slots it will access, or which state it will modify. The node typically discovers these data dependencies incrementally during transaction execution.

This is like entering a large warehouse to retrieve items without a complete inventory location list. Workers must search and process simultaneously. To prevent two people from modifying the same stock simultaneously, a large amount of work must be done in a strict, sequential (single-threaded) order.

Block-Level Access Lists (BALs) act like a complete "state access map" attached to each block. They declare, right in the block header, which addresses and storage slots the set of transactions in that block will touch, as well as the resulting state after execution. With this map, nodes can determine upfront which transactions access the same data and which ones do not conflict:

For non-conflicting parts, nodes can pre-read relevant state from the hard drive and process some transaction verification and state root calculation in parallel, rather than forcing all work into a strictly serial queue. Furthermore, because BALs also record the state changes after transactions are completed, nodes syncing or catching up to the network state can use these results for state reconstruction in some cases, without having to re-execute every single transaction in a block from scratch. (The author personally interprets this as carrying a hint of sharding philosophy), potentially turning Ethereum into a fully parallelized execution blockchain.

Therefore, in the long term, this is a key underlying enabler for breaking through Ethereum's mainnet performance ceiling.

Finally, there's Gas repricing, which primarily involves a significant recalibration of Gas costs for various on-chain operations using economic leverage.

The reason is that current Ethereum Gas costs do not perfectly align with the actual resource consumption borne by nodes. For example, a pure complex computation usually leaves little long-term burden on a node after execution. However, creating a new account, deploying a smart contract, or writing to a new storage slot generates data that all full nodes globally must store permanently.

In the past, the fees for these state-creating actions did not fully reflect their permanent storage costs (state bloat). If Ethereum were to increase the Gas Limit while maintaining existing pricing, the extra block space could quickly be converted into uncontrollable state data, ultimately overwhelming node hardware.

EIP-8037, which has been confirmed for inclusion in Glamsterdam, aims to completely overhaul this rule. This includes separate accounting for computation and state, recalculating costs based on the volume of new state data added, distinguishing between general computation Gas and state Gas. It also involves controlling state bloat, making operations that create many new accounts, deploy large redundant contracts, or frequently write new state potentially more expensive. Conversely, applications that mainly consume immediate computational resources without persistently increasing state will find the fee structure more attractive.

Ultimately, the Gas reforms in Glamsterdam cannot be simply interpreted as "universal fee reduction." Instead, it's about clarifying how much immediate computational resource a transaction consumes versus how much long-term storage burden it leaves on the network, and then charging different operations based on a cost closer to their true physical resource consumption.

Overall, these three parts appear independent but collectively point towards a single ultimate goal: to substantially increase the Gas Limit and processing capacity of the Ethereum mainnet by proactively upgrading the core underlying infrastructure.

2. Why Not Just Make Blocks Bigger?

Many might wonder, since things are slow and expensive, why not just directly increase the Gas Limit and double the block capacity?

This is a common question. Theoretically, the most direct way to increase mainnet capacity is indeed to raise the Gas Limit per block. A higher Gas Limit means each block can accommodate more transactions and computation.

However, the Gas Limit is not a number that can be increased infinitely. Blindly making blocks larger triggers a domino effect: nodes need to receive more data, execute more transactions, and calculate new state within the same timeframe. If processing speeds can't keep up, nodes with weaker hardware are more likely to fall behind. Block propagation and validation could also experience delays, ultimately increasing the risk of network forks and centralization.

Furthermore, more transactions also mean more accounts, contracts, and storage data permanently written to Ethereum's database. This data doesn't disappear when transactions end; it accumulates in Ethereum's state database, causing state to bloat faster.

Therefore, scaling Ethereum isn't a simple mathematical problem. It requires solving three issues simultaneously:

• First, how to give nodes more time to propagate and process larger blocks.
• Second, how to reduce the performance bottleneck caused by sequential transaction execution.
• Third, how to prevent increased block space from quickly turning into uncontrollable state bloat.

This is the core logic of Glamsterdam. It's not about blindly scaling first and forcing nodes to cope, but rather about first restructuring the methods of block production, transaction execution, and resource pricing. It aims to clear the underlying plumbing so that the door can be naturally opened for increasing mainnet capacity.

Here, ePBS buys nodes more time for propagating and validating large blocks by rearranging the block processing flow within a slot. BALs improve the efficiency of client state reading, execution, and synchronization by explicitly providing state access relationships. Gas repricing is responsible for limiting unsustainable state growth.

During the Glamsterdam collaboration test in April 2026, core developers conducted intensive stress tests across multiple client implementations and explicitly set a technical target of a credible lower bound of 200 million Gas capacity post-upgrade. Behind this target lies the foundational support provided by ePBS, BALs, and state Gas repricing.

Of course, 200 million Gas is more of an indicator of the system's post-upgrade capacity and a direction for future evolution. It doesn't mean the mainnet will immediately jump its Gas Limit to this level on the day Glamsterdam activates.

The truly important point is that Ethereum is shifting from "cautious, tentative scaling" towards "preparing for more substantial mainnet scaling through underlying structural reorganization."

3. How Will Ordinary Users and the Ethereum Ecosystem Be Affected?

From an ordinary user's perspective, the most relevant question regarding the Glamsterdam upgrade remains whether transaction fees will decrease.

Overall, the answer leans towards "likely to decrease and become more stable," rather than all transactions becoming cheaper immediately.

Since ePBS and Block-Level Access Lists create conditions for a higher Gas Limit, it's predictable that the transaction capacity per block will increase. With constant on-chain demand, increased block space supply naturally helps alleviate congestion and reduces the probability of sudden Base Fee spikes.

However, the impact on individual transactions may vary. For example, simple ETH transfers might benefit from base Gas optimizations. Furthermore, because BALs disclose state paths in advance, the accuracy of wallet Gas estimation will significantly improve. The frustrating past experience where inaccurate wallet Gas estimates led to transaction failures (but still incurred fees) during market volatility will become history.

However, operations like deploying contracts, batch-creating accounts, or writing large amounts of new state may see increased costs due to state repricing. Therefore, the more likely outcome of Glamsterdam is lower costs for simple transactions, more stable fees during congestion, while state-intensive applications begin paying more accurate prices for their long-term network resource usage.

For users primarily on L2s, this upgrade is also relevant. ePBS extends the data propagation window for execution payloads from ~2 seconds to ~9 seconds. This not only supports larger mainnet blocks but also leaves room for Ethereum to handle more Blob data. With increased Blob capacity, Rollups will have more space to submit transaction data, which in the long run helps stabilize L2 data costs.

Furthermore, for wallets, exchanges, and bridges, a more user-visible change might come from EIP-7708. Currently, ERC-20 token transfers typically generate standardized Transfer logs, but native ETH transfers between some smart contracts don't leave equally clear event records. Wallets and exchanges often rely on additional internal transaction tracking tools to identify this ETH flow.

EIP-7708 requires non-zero ETH transfers and ETH burning operations to generate standard logs. This allows wallets, exchanges, and bridges to more reliably identify deposits, withdrawals, and ETH changes within contracts. In the future, users will likely see more complete ETH asset records, and internal transfers that previously required complex transaction tracing to display will be more easily recognized by wallets directly.

The impact on node operators and stakers is even more direct. Glamsterdam changes block processing methods at both the execution and consensus layers. Therefore, nodes and validators will need to upgrade to client versions supporting Glamsterdam before mainnet activation. Regular ETH holders do not need to migrate their ETH or perform any so-called "asset upgrade" or "token swap."

Looking further ahead, Glamsterdam truly impacts how Ethereum re-finds its balance between scaling and decentralization. After all, if increasing block capacity simultaneously raises hardware requirements for running a node, the mainnet's throughput might increase, but the network could become increasingly dependent on large institutions.

The combination of ePBS, Block-Level Access Lists, and state Gas repricing attempts to forge an alternative scaling path. It's not about simply demanding nodes handle more work in the same time. Instead, it's about rearranging the block production process, 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 try to solve all of Ethereum's problems with a single EIP; instead, it simultaneously overhauls three interrelated mechanisms: block production, transaction execution, and state growth.

Final Thoughts

In the long run, Glamsterdam's most profound impact will be on the narrative trajectory of Ethereum's rebalancing between "high-performance scaling" and "absolute decentralization."

This also reflects Ethereum's well-known core principle or inertia—facing relentless pressure from high-performance monolithic chains, it doesn't choose to simply and crudely raise the hardware barrier. Instead, it selects a path that strives to maintain its decentralized foundation and offers greater underlying resilience. Just like this time, through a combination of rewriting the block pipeline (ePBS), proactively providing explicit transaction dependencies (BALs), and accurately charging different resources based on physical burden (Gas repricing). The goal remains to squeeze out significantly larger mainnet capacity while ensuring ordinary people can still run nodes and participate in validation.

From this perspective, every cost-effective Gas fee we pay in the future, the more precise and clear internal ETH bills in our wallets, and the broader fee reduction potential for L2s, will likely owe a great deal to the foundation Glamsterdam is laying for Ethereum in the second half of 2026.