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

Ethereum's next major upgrade has entered the sprint phase.

According to the current official Ethereum roadmap, the Glamsterdam upgrade is slated for mainnet deployment in the second half of 2026. As of the end of June, it has entered the final testing phase on developer networks, with ongoing testing across multi-client devnets focused on core features like enshrined PBS, block-level access lists, and gas repricing. However, the specific activation date has yet to be finalized.

Meanwhile, across major social media platforms, the most discussed topic is undoubtedly the upgrade's straightforward performance narrative – "Mainnet hitting 10,000 TPS." But beyond this, the upgrade represents a foundational overhaul of Ethereum's block production pipeline and execution engine. The depth and breadth of the changes have led the developer community to widely describe it as "the biggest upgrade since The Merge."

So, what exactly does this upgrade — with its cool-sounding name "Glamsterdam" (combining the consensus layer upgrade Gloas and the execution layer upgrade Amsterdam) — actually change? How will it address past pain points, and what groundbreaking shifts can we expect in our everyday on-chain experience?

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

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

This truly reflects Ethereum's current underlying drive to "Make L1 Great Again" – figuring out how to accommodate more transactions on L1 without simultaneously increasing the cost of running a node and the risk of network centralization.

However, for the average user, past Ethereum upgrades have often been boiled down to one intuitive question: Will gas be cheaper? Will throughput be higher? But honestly, the upcoming Glamsterdam upgrade is hard to summarize simply as "fee reduction" or "scaling."

Overall, this upgrade involves several critical 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 cost. It essentially seeks to redesign the fundamental paradigm for producing and processing blocks on Ethereum. Based on the technical details disclosed so far, the most noteworthy core changes can be grouped into 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): Pre-maps the data dependencies for transaction execution, paving the way for parallel processing and faster node synchronization.
• Gas Repricing: Introduces a more precise resource billing model to control state bloat in high-throughput environments.

First, to understand enshrined PBS, you need to know that blocks on Ethereum aren't necessarily assembled by the Proposer themselves. Especially in the current MEV-Boost architecture, most Proposers outsource the tasks of collecting transactions, ordering them, and capturing MEV (Maximal Extractable Value) to specialized block Builders. The Proposer's main role is to select the highest-bidding block from multiple candidates submitted and attest to it on the network.

This division of labor – "Builders assemble, Proposers propose" – is known as PBS (Proposer-Builder Separation).

The problem, however, is that this mechanism isn't fully integrated into Ethereum's core protocol. Proposers and Builders must rely on third-party software and MEV-Boost Relay services outside the protocol to handle block bids, content delivery, and payment.

This means the Relay acts as a fragile and centralized "trusted intermediary." It must ensure the Builder eventually reveals the full block publicly, while also preventing the Proposer from seeing the block contents early and then refusing to pay – a classic "rogue" scenario.

EIP-7732 proposes ePBS (Enshrined PBS) to solve this exact pain point. It aims to enshrine this game-theoretic relationship directly into Ethereum's consensus protocol, eliminating the need for a third-party relay. Builders would become natively recognized protocol participants. They would first submit a block commitment and a bid; the protocol would automatically lock in the corresponding payment. A specialized "Payload Timeliness Committee" (PTC) then verifies if the Builder revealed the execution payload on time.

This would decouple parts of the processing between the consensus block and the execution payload, extending the window for the execution payload's propagation and processing from roughly 2 seconds to about 9 seconds. These few extra seconds are critically important for Ethereum's scalability – they give nodes more time to receive and process larger blocks and more Blob data, freeing up space to further increase the Gas Limit.

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

As is well known, currently, before an Ethereum node receives a block, it doesn't know which accounts each transaction will read, which contract storage slots it will access, or what state it will modify. The node typically discovers these data dependencies gradually *while* executing the transactions.

It's like entering a large warehouse to pick items without a map of item locations. Workers have to search and process simultaneously. To prevent two people from modifying the same inventory, a significant amount of work must be done strictly in a fixed order (single-threaded serial execution).

Block-Level Access Lists (BALs) provide a complete "state access map" attached to each block. They declare upfront, in the block header, which addresses and storage slots the set of transactions within the block will touch, as well as the resulting state changes after execution. With this map, a node can easily determine which transactions access the same data and which ones do not conflict, before execution begins.

For the non-conflicting parts, the node can pre-read the relevant state from the hard drive and process some transaction validation and state root calculation in parallel, rather than funneling all work into a strictly serial queue. Furthermore, because BALs also record the post-execution state changes, nodes catching up or syncing network state can use these results for state reconstruction without needing to re-execute every single transaction in a block from scratch for all scenarios (personally, this echoes elements of sharding conceptually). This paves the way for Ethereum to become a fully parallelized blockchain.

Therefore, in the long run, this is a fundamental key for Ethereum's mainnet to break through its performance ceiling.

Finally, there's Gas Repricing. This primarily involves a significant calibration of gas pricing for various on-chain operations using economic levers.

The reason is that Ethereum's current gas costs don't perfectly match the actual resource burden borne by nodes. For example, a purely complex calculation imposes little long-term burden on nodes after execution. However, creating a new account, deploying a smart contract, or writing to a new storage slot creates data that every full node globally must store permanently.

Historically, the fees for these state-creating actions didn't fully reflect their permanent storage costs (state bloat). If Ethereum were to increase the Gas Limit while maintaining the old pricing, more 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 reform this rule. This includes separating the accounting for computation and state, recalculating costs based on the volume of newly added state data, and separating general computation gas from state gas. It also aims to control state explosion, making operations that create many new accounts, deploy large redundant contracts, or frequently write new state potentially more expensive. Conversely, applications that primarily consume instant compute resources without persistently increasing the state would have a more attractive fee structure.

Ultimately, the gas reform in Glamsterdam cannot be simplistically understood as "across-the-board fee reduction." Instead, it's about clarifying how much instant compute resource a transaction consumes and how much long-term storage burden it leaves on the network, then charging different operations based on a cost closer to the true physical resources used.

Overall, these three components seem independent but collectively point towards a single ultimate goal: to fundamentally overhaul the core underlying infrastructure of the Ethereum mainnet, paving the way for a further significant increase in the Gas Limit and processing power.

2. Why not just make blocks bigger?

Many people might wonder: if it's too slow and expensive, why not just directly increase the Gas Limit and double the block capacity?

This is a recurring question. Theoretically, the most direct way to increase mainnet capacity is indeed to raise the Gas Limit per block, as a higher Gas Limit allows a block to contain more transactions and computations.

However, the Gas Limit isn't a number that can be increased infinitely. Blindly increasing block size 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, causing delays in block propagation and validation, ultimately increasing the risk of network forks and centralization.

Simultaneously, more transactions mean more permanent data (accounts, contracts, storage) written to Ethereum's database. This data doesn't disappear when the transaction ends; it accumulates in the state database, leading to faster state bloat.

Therefore, Ethereum's scaling challenge isn't a simple mathematical problem. It needs to solve three issues concurrently:

• First, how to give nodes more time to propagate and process large blocks.
• Second, how to reduce the performance bottleneck caused by sequential transaction execution.
• Third, how to prevent more 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 later. It's about first restructuring block production, transaction execution, and resource pricing from the ground up – clearing the pipes at the base layer – and then naturally opening the door for increasing mainnet capacity.

Specifically, ePBS rearranges the block processing flow within a slot, giving nodes more time to propagate and validate large blocks. BALs improve the efficiency of client state reading, execution, and synchronization by explicitly providing state access relationships. Gas repricing curbs unsustainable state growth.

During a collaborative Glamsterdam test in April 2026, core developers conducted intensive stress tests on multi-client implementations and explicitly set a technical target of 200 million Gas as a credible lower bound for capacity post-upgrade. This target is supported precisely by the combined foundations of ePBS, BALs, and state gas repricing.

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

What truly matters is that Ethereum is moving from a past strategy of "cautious, exploratory scaling" towards "preparing for more substantial mainnet scaling through deep structural reform."

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

From an ordinary user's perspective, the most important 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 will immediately become cheaper."

Since ePBS and Block-Level Access Lists create the conditions for a higher Gas Limit, it's foreseeable that each block will be able to accommodate more transactions. With constant on-chain demand, an increase in block space supply naturally helps alleviate congestion and reduces the probability of sudden spikes in the Base Fee.

However, for individual transactions, the impact may vary depending on the operation. For instance, simple ETH transfers might benefit from basic gas optimizations. Moreover, because BALs pre-declare the state access paths, wallets will be significantly more accurate when estimating gas fees. The frustrating experience of wallet gas estimates being off due to market volatility, leading to failed transactions but still incurring fees, could become a thing of the past.

On the other hand, operations involving contract deployment, batch account creation, or writing large amounts of new state might become more expensive due to state repricing. Therefore, the likely outcome of Glamsterdam is lower costs for simple transactions, more stable fees during congestion, while state-intensive applications start paying a more accurate price for the network resources they permanently consume.

For users primarily on L2s, this upgrade is also relevant. ePBS extends the data propagation window for execution payloads from about 2 seconds to about 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 usually generate standardized Transfer logs. However, native ETH transfers between certain smart contracts do not always leave such clear event records. Wallets and exchanges often rely on additional internal transaction tracking tools to identify this ETH flow.

EIP-7708 mandates that non-zero ETH transfers and ETH burns generate standard logs. This would allow wallets, exchanges, and bridges to more reliably identify deposits, withdrawals, and ETH movements within contracts. In the future, users' ETH asset records might be more complete, and internal transfers that previously required complex transaction tracing to display could be directly identified by wallets.

For node operators and stakers, the impact is even more direct. Glamsterdam changes block processing in both the execution and consensus layers. Therefore, nodes and validators need to upgrade their client software to 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's true impact lies in how Ethereum renegotiates the balance between scaling and decentralization. After all, if increasing block capacity simultaneously requires a significant jump in hardware requirements to run a node, the mainnet throughput might increase, but the network could become increasingly reliant 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 simply about asking nodes to process more work in the same time; it's about rearranging the block production flow, providing transaction dependency information upfront, and charging for different resources based on their actual burden.

This is the 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 interconnected mechanisms: block production, transaction execution, and state growth.

Final Thoughts

In the long run, Glamsterdam's most profound influence will be on the narrative of Ethereum finding a new equilibrium between "high-performance scaling" and "absolute decentralization."

This aligns with Ethereum's well-known初心 (original intention) or inertia – when facing pressure from high-performance monolithic blockchains, it chooses not to simply raise hardware requirements. Instead, it opts for a path that strives to maintain its decentralized character and offers greater underlying resilience. Just like this time, through the combination of rewriting the block pipeline (ePBS), explicitly providing transaction dependencies upfront (BALs), and accurately charging for different resources based on their physical burden (Gas Repricing), the goal remains to carve out significantly larger mainnet capacity while ensuring ordinary people can still run nodes and participate in validation.

Looking at it from this perspective, every low gas fee we pay in the future, the more accurate and clear internal ETH statements in our wallets, and the broader room for L2 fee reductions, will likely be profoundly indebted to the foundation Glamsterdam re-lays for Ethereum in the second half of 2026.