The Merge 以来最大规模升级？Glamsterdam 如何影响以太坊？

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

According to the current Ethereum official 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 entered the final testing phase on developer networks, with ongoing tests focusing on multi-client development networks for core functionalities like enshrined PBS, block-level access lists, and gas repricing. However, the specific activation date has not yet been finalized.

Meanwhile, across major social media platforms, the most discussed topic is undoubtedly the intuitive performance narrative of "Mainnet hitting 10,000 TPS" post-upgrade. However, beyond this, the upgrade involves a ground-up reconstruction of Ethereum's block production pipeline and execution engine. The depth and breadth of these changes have led the developer community to widely hail it as the "biggest 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 disruptive changes will it bring to our daily on-chain experience?

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

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

This is a true reflection of Ethereum's current underlying ambition to "Make L1 Great Again"—finding ways to accommodate more transactions on L1 without concurrently increasing the cost of running a node or the risk of network centralization.

For regular users, however, Ethereum upgrades are often boiled down to one simple question: Will gas fees be cheaper? Will throughput be higher? But to be honest, the upcoming Glamsterdam upgrade is hard to summarize simply as "fee reduction" or "scaling."

Overall, this upgrade involves multiple critical underlying aspects of Ethereum, including who builds blocks, how transactions are executed, how nodes read and synchronize state, and how much gas different on-chain operations should cost. Essentially, it's about redesigning the fundamental paradigm of how Ethereum produces and processes blocks. Based on the technical details disclosed so far, the core changes worthy of the most attention are concentrated in three areas:

• Enshrined PBS (ePBS): Restructuring the game theory relationship between block proposers and builders, eliminating reliance on external relays.
• Block-Level Access Lists (BALs): Pre-mapping the data accessed by transactions, laying the groundwork for parallel processing and faster node sync.
• Gas Repricing: Introducing a more precise resource billing model to control state bloat in high-throughput environments.

First, to understand enshrined PBS (ePBS), you need to know that blocks on Ethereum aren't always submitted directly by the Proposer. Especially under the current MEV-Boost architecture, most Proposers outsource the tasks of collecting transactions, ordering them, and seeking MEV opportunities to specialized block Builders. The Proposer's main role is to select the highest-bidding candidate block from several options and submit it to the network.

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

The problem is that this current mechanism hasn't been fully enshrined into Ethereum's core protocol. Proposers and Builders must rely on third-party software outside the protocol, specifically MEV-Boost Relay services, to handle block bids, content delivery, and payments.

This means the Relay acts as a fragile and centralized "trusted intermediary," needing to ensure the Builder eventually publishes the full block while also preventing the Proposer from "cheating" by previewing the block content and refusing to pay.

EIP-7732, which proposes ePBS (Enshrined PBS), aims to solve this pain point by integrating this game theory relationship directly into Ethereum's consensus protocol. It removes the need for third-party relays, making Builders natively recognized participants in the protocol. Builders submit block commitments and bids, the protocol automatically locks in corresponding payments, and a specialized "Payload Timeliness Committee" verifies if the Builder published the execution payload on time.

This decouples part of the processing of consensus blocks from execution payloads, extending the window for propagating and processing execution payloads from about 2 seconds to roughly 9 seconds. While a few seconds may not seem significant, it's crucial for Ethereum's scaling—it gives nodes more time to receive and process larger blocks and more Blob data, freeing up space for further increases in the Gas Limit.

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

As is well known, currently, before an Ethereum node receives a block, it cannot know from the block itself which accounts each transaction will read, which contract storage it will access, or what state it will modify. Nodes typically discover these data dependencies progressively as they execute the transactions.

This is like entering a large warehouse to pick items without a complete inventory location list; workers have to search and process simultaneously. To prevent two people from modifying the same stock, a significant amount of work must be done strictly in a fixed order (single-threaded serial execution).

Block-Level Access Lists (BALs) are akin to attaching a complete "state access map" to each block. They declare upfront in the block header which addresses and storage slots the block's set of transactions will touch, and the resulting state after execution. With this map, nodes can instantly identify which transactions access the same data and which are conflict-free before executing any:

For conflict-free transactions, nodes can pre-read the relevant state from the hard drive, verify some transactions in parallel, and compute the state root concurrently, without forcing all work into a strictly serial queue. Furthermore, since BALs also record state changes post-execution, nodes catching up with the network state can use these results for state reconstruction in some scenarios, avoiding the need to re-execute every single transaction in every block (This author understands it has a flavor of sharding concepts), potentially making Ethereum a fully parallelized blockchain.

Therefore, in the long run, this is a key underlying factor for breaking through the performance ceiling of the Ethereum mainnet.

Finally, there's Gas Repricing, which significantly calibrates the gas pricing for multiple on-chain operations using economic levers.

The reason is that current Ethereum's gas costs do not perfectly match the actual resource consumption burden on nodes. For example, a purely complex computation usually leaves little long-term burden on a node once executed. However, creating a new account, deploying a smart contract, or writing to a new storage slot creates data that all full nodes globally must store permanently.

In the past, the fees for these state-creating actions didn't fully reflect their permanent storage costs (state bloat). If Ethereum maintained its current pricing while increasing the Gas Limit, more block space could be quickly converted into unmanageable state data, ultimately overwhelming node hardware.

EIP-8037, confirmed for inclusion in Glamsterdam, aims to completely restructure these rules. This includes separate accounting for computation and state, recalculating costs based on the volume of new state data, separating general computation gas from state gas; and controlling state explosion, increasing the operational cost for applications creating many new accounts, deploying large redundant contracts, or frequently writing new state, while making fee structures more attractive for applications primarily consuming immediate computing resources without adding persistent state.

Ultimately, the gas reform in Glamsterdam cannot be simplistically understood as "universal fee reduction." It's about clarifying how much immediate computing 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 their true physical resource usage.

Overall, these three parts may seem independent, but they all point towards the same ultimate goal: to significantly increase the Gas Limit and processing capacity of the Ethereum mainnet by first overhauling the core underlying infrastructure.

2. Why Can't We Just Make Blocks Bigger?

Many might wonder, if the mainnet is slow and expensive, why not just increase the Gas Limit and double the block capacity directly?

This is a common 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 allows a block to accommodate more transactions and computation.

However, the Gas Limit isn't a number that can be increased indefinitely. Blindly making blocks larger triggers a domino effect: nodes would need to receive more data, execute more transactions, and compute new state within the same timeframe. If processing speeds can't keep up, nodes with weaker hardware will fall behind, leading to potential delays in block propagation and verification, ultimately increasing the risk of network forks and centralization.

Simultaneously, more transactions mean more accounts, contracts, and storage data permanently written to Ethereum's database. This data doesn't automatically disappear after transactions finish; it accumulates in the Ethereum state database, causing state to bloat faster.

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

• 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 more block space from rapidly turning into uncontrollable state bloat.

This is the core logic of Glamsterdam. It's not about blindly scaling first and forcing nodes to bear the cost. It's about first reconstructing block production, transaction execution, and resource pricing methods—clearing the pipes from the bottom up—to naturally open the door for higher mainnet capacity.

Here, ePBS provides nodes more time to propagate and validate large blocks by rearranging the block processing flow within a slot. BALs improve the efficiency of clients reading, executing, and syncing state by explicitly providing state access relationships. Gas repricing focuses on limiting unsustainable state growth.

During the Glamsterdam collaborative testing in April 2026, core developers conducted intensive stress tests on multi-client implementations and clearly set a technical target of 200 million Gas as the credible capacity floor post-upgrade. This target is fundamentally supported by the combined efforts of ePBS, BALs, and state gas repricing.

Of course, 200 million Gas is more about the system's potential capacity post-upgrade 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.

What truly matters is that Ethereum is shifting from "cautious, tentative scaling" to "preparing in advance for more substantial mainnet scaling through underlying structural reconstruction."

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

From a regular user's perspective, the most critical question regarding the Glamsterdam upgrade remains whether transaction fees will decrease.

Overall, the answer leans towards a likely decrease and more stable fees, rather than all transactions becoming instantly 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 increase. Assuming on-chain demand stays constant, an increase in block space supply will naturally help alleviate congestion and reduce the probability of sudden Base Fee spikes.

However, the change for individual transactions may differ. For instance, simple ETH transfers might benefit from basic gas optimization. Furthermore, because BALs disclose state paths in advance, wallets' accuracy in estimating gas fees will significantly improve. The frustrating experience of failed transactions due to inaccurate wallet gas estimates during volatile market conditions, which still deduct fees, may become a thing of the past.

Conversely, operations like deploying contracts, creating accounts in batches, or writing large amounts of new state might see cost increases due to state repricing. So, Glamsterdam is more likely to result in lower costs for simple transactions, more stable fees during congestion, and state-intensive applications paying a more accurate price for their long-term network resource usage.

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

Additionally, for wallets, exchanges, and cross-chain bridges, a more easily noticeable change might come from EIP-7708. Currently, ERC-20 token transfers typically generate standardized Transfer logs, but native ETH transfers between some smart contracts do not leave equally clear event records. Wallets and exchanges often rely on additional internal transaction tracing tools to identify these ETH flows.

EIP-7708 requires non-zero ETH transfers and ETH burns to generate standard logs, enabling wallets, exchanges, and bridges to more reliably identify deposits, withdrawals, and internal ETH movements within contracts. In the future, users might see more complete records of their ETH assets, and internal transfers that previously required complex tracing to display will be more easily identified directly by wallets.

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

Looking further ahead, Glamsterdam truly impacts how Ethereum renegotiates the balance between scaling and decentralization. After all, if hardware requirements for running a node increase significantly alongside block capacity, the mainnet's throughput might rise, 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: not simply requiring nodes to do more work in the same time, but rearranging the block production process, providing transaction dependency information in advance, and charging 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 fix all of Ethereum's problems with a single EIP, but simultaneously overhauls three interconnected mechanisms: block production, transaction execution, and state growth.

Final Thoughts

In the long run, what Glamsterdam profoundly influences is the narrative direction of Ethereum rebalancing between "high-performance scaling" and "absolute decentralization."

This also echoes the familiar初心 or inertia of Ethereum: when faced with the relentless pressure from high-performance monolithic chains, it chooses not to simply raise the hardware barrier. Instead, it opts for a path that strives to maintain its decentralized character and possesses greater underlying resilience. This time, through the combination of rewriting the block pipeline (ePBS), explicitly providing transaction dependencies in advance (BALs), and charging different resources precisely based on physical burden (Gas Repricing), the goal remains to carve out a 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 accurate and clear internal ETH statements in our wallets, and the broader potential for L2 fee reductions, will all deeply benefit from the foundation that Glamsterdam is laying for Ethereum in the second half of 2026.