Written by: imToken

Objectively speaking, over the past period, many users' intuitive feelings about Ethereum often do not come from roadmaps or developer meetings, but from specific on-chain operations.

For example, in the past two years, users have broadly felt the decreasing Gas fees during transfers and the improvements in cross-chain interoperability. This is also why Ethereum's scalability has never been simply a "performance race" issue—for ordinary users, higher TPS, larger blocks, and more complex underlying architecture are only meaningful when they truly translate into lower costs, smoother operations, and safer wallet experiences.

Recently, a series of new developments in Ethereum have pointed out that Ethereum is attempting to systematically shift the complexities previously borne by wallets, DApps, third-party relayers, and users themselves to the protocol layer.

This includes Keyed Nonces participated in by Vitalik, the directional consensus formed around the 200 million Gas Limit floor during the Glamsterdam upgrade, and a series of underlying trends mentioned in the 2026 roadmap, such as native account abstraction, cross-L2 interoperability, and reinforcement of L1 security.

1. Increasing the Gas Limit to 200 million?

First, let’s look at the easiest aspect for users to perceive: the Gas Limit.

As we know, every transaction (whether it's a transfer or a contract interaction) on the Ethereum network consumes a certain amount of Gas, and the Gas Limit capacity of each Ethereum block is fixed, meaning the slots are limited: the more slots there are, the more passengers can be transported in the same period; the tighter the slots, the more everyone has to compete for the same seat, causing Gas fees to rise.

Theoretically speaking, expanding the block Gas limit will directly and significantly enhance the performance of the Ethereum mainnet, but in the context of the past expansion of L2 and other routes, Ethereum has been relatively restrained and cautious, and most expansion pressure has been intentionally directed toward L2.

Looking back at the expansion curve of Ethereum’s Gas Limit, you'll find that after breaking through 10 million from 8 million in September 2019 for the first time, it took until this year for the Gas Limit to move from 8 million to 60 million in 7 years, especially accelerating only in 2025—going from 30 million in February to 36 million, then up to 45 million in July, and further to 60 million after the Fusaka upgrade in December.

It can be said that most of the expansion has been concentrated in the year 2025, and as mentioned earlier, 2025 is also a crucial year in Ethereum's history. The Fusaka upgrade, just 7 months after the Pectra upgrade in May, demonstrated that the Ethereum Foundation, after a significant leadership adjustment, still has the ability to drive major updates and marked the official entry into a rhythm of "two hard forks a year" for accelerated development (see the extended reading "Ethereum 2026: Interpreting the EF's Latest Protocol Roadmap, Officially Entering the 'Engineering Upgrade' Era?").

Source: Etherscan

According to the Soldøgn Interop Recap released by the Ethereum Foundation on May 2, over 100 core Ethereum contributors participated in an interoperability meeting in Svalbard, Norway, focused on advancing the multi-client implementation, testing, and parameter alignment of the Glamsterdam upgrade, where developers reached a directional consensus regarding a 200 million Gas Limit.

This means that if subsequent processes go smoothly, the execution capacity of Ethereum’s L1 is expected to increase from the current approximate 60 million Gas Limit to a level of 200 million. In a longer time dimension, the Ethereum ecosystem's public attitude toward Gas Limit discussions has clearly become more "radical." The EIP-9698 proposal even suggests "increasing tenfold every two years," aiming to raise the Gas Limit to 3.6 billion by 2029, which is 50 times the current level.

However, it should be emphasized that raising the Gas Limit is not simply about making the block larger.

If the calculation capacity that each block can accommodate is increased blindly, it may lower fees in the short term, but in the long term, it leads to increased burdens on nodes and state data inflation, meaning that regular users will find it more difficult to run nodes, ultimately undermining the core decentralization foundation of Ethereum.

Therefore, the expansion approach of Glamsterdam is a set of combined strategies:

• ePBS (enshrined Proposer-Builder Separation) more clearly incorporates the block construction and validation processes into the protocol rules, allowing validators to safely handle larger blocks;
• Block-Level Access Lists (BAL) record in advance the accounts and storage locations that will be accessed during block execution, which supports parallel disk reads, parallel transaction verification, and parallel state root calculations;
• And EIP-8037 raises the costs of operations related to state creation to avoid too rapid state growth after the Gas Limit increase;

Ultimately, Ethereum is not just interested in “accommodating more transactions,” but also in figuring out how to accommodate more transactions without raising the operating threshold for nodes.

This is also a fundamental difference between Ethereum's expansion narrative and that of many high-performance chains; the goal is not to sacrifice validation costs for superficial throughput, but to enhance the mainnet’s carrying capacity while ensuring ordinary nodes can participate and the system can be verified.

2. Keyed Nonces: Turning "One Queue" into "Multiple Channels"

If the Gas Limit addresses "how much can one block hold," then Keyed Nonces focus on another more detailed but crucial question: how should a transaction be queued?

As is well known, in Ethereum, a nonce can be simply understood as the "serial number" of an account's transactions. Its purpose is to prevent the same transaction from being executed multiple times and to ensure that transactions initiated by the same account are processed in order.

This mechanism is easy to understand in ordinary transfer scenarios, as the first transaction, the second transaction, and the third transaction are queued in order.

However, problems arise when account capabilities become more complex, such as in situations involving privacy transactions, smart wallets, session keys, batch operations, or third-party payments, where a single linear nonce can become a bottleneck. Therefore, the core idea behind EIP-8250’s Keyed Nonces is to allow an account, which traditionally only has one nonce queue, to have multiple nonce domains.

Specifically, it replaces the single sender nonce in EIP-8141 Frame Transaction with a (nonce_key, nonce_seq) structure, where nonce_key == 0 corresponds to the traditional account nonce, while non-zero keys can choose to independently manage nonce sequences in separate protocols, with transactions under different keys operating independently without replay effects on each other.

This may sound very technical, but can be understood with a relatable analogy: previously, an account was like having only one window at the bank, where all transactions had to line up in the same queue; Keyed Nonces are like distributing different transactions across different windows, allowing transfers, privacy withdrawals, session authorizations, and batch executions to each follow their own channels.

This is particularly important for privacy protocols, as to avoid directly binding a user’s on-chain activities to a specific public address, privacy protocols may allow multiple users to initiate transactions through the same shared sender address, but under a single nonce mechanism, when one user’s transaction is packaged, it could lead to other users’ pending transactions being invalidated or blocked.

With Keyed Nonces allowing each expenditure to choose its own nonce domain, for example, derived from a privacy nullifier, it decreases such queuing conflicts at the protocol layer.

Vitalik himself positions it even more grandly; in introducing EIP-8250, he clearly states that Keyed Nonces "not only provide stronger support for privacy schemes at the protocol layer but may also be the first step towards Ethereum's new state scalability strategy—achieving extreme scalability while maintaining the protocol's decentralization by creating storage types optimized for different use cases."

In other words, it can be simply understood that while Gas Limit addresses "the size of the block," Keyed Nonces explore "the shape of the state"—what Ethereum needs to support in the future is not just more transactions but a wider variety of transactions.

3. How Will This Affect Ordinary Users?

For the Ethereum ecosystem, although many protocol upgrades may seem distant from ordinary users, they ultimately impact wallet experiences.

Because the true entry point for users to interact with Ethereum is not through EIPs, clients, or developer meetings, but rather every transfer, authorization, signature, cross-chain interaction, and DApp operation within the wallet. In other words, changes at the protocol layer are only truly completed when they are translated into clearer, smoother, and safer operational experiences at the wallet level.

For instance, the well-known concept of account abstraction is not meant to make users understand more technical terms but to allow users to use on-chain accounts more naturally in the future. Hence, in recent years features like batch transactions, Gas payments, recovery mechanisms, different signing methods, session authorization, and more flexible security policies have gradually become essential capabilities in wallets.

Similarly, with Keyed Nonces, it sounds like a very fundamental optimization mechanism for account queuing, but on the user side, its potential impacts are not abstract. Today, many users may have encountered scenarios where a transaction remains unconfirmed for a long time, causing subsequent transactions to be stuck. They wish to cancel or speed up the transaction but do not understand the relationship between nonce, Gas, and replacement transactions, especially when multiple operations are parallel; one failed step can impact the entire subsequent process.

For ordinary users, these issues may seem like "the wallet is not user-friendly" or "the chain is not functioning well," but they are actually connected to the design of a single linear nonce in Ethereum’s account model. The direction represented by Keyed Nonces is to allow accounts to no longer execute all operations in a single linear order but to split different usage scenarios into multiple parallel channels.

In the future, ordinary transfers, DApp authorizations, privacy transactions, batch transactions, Gas payments, etc., can theoretically have more independent execution spaces, reducing the probabilities of blockage and conflict.

This undoubtedly will further expand the design space for smart wallets.

More importantly, in the past, these capabilities often required wallets, DApps, relay services, and users to share the complexities, with users needing to understand the scope of authorizations, judge whether Gas is reasonable, and know what they are signing, while having to repeatedly confirm during multi-step operations such as cross-chain, exchanges, staking, and claiming rewards. Any misunderstanding at any step could lead to operational failures and asset loss risks.

Now, what Ethereum is attempting to do is to shift some complexities to the protocol layer, allowing wallets to utilize more standardized and native underlying capabilities to provide better interaction abstractions for users.

This is why Gas Limits, BAL, ePBS, Keyed Nonces, Frame Transactions, native account abstractions, and cross-L2 interoperability, seemingly from different technical modules, are actually all serving the same goal: to enable Ethereum to support more complex on-chain usage scenarios without sacrificing decentralization and security.

Specifically, putting these dynamics together reveals that Ethereum's recent focus is not scattered:

• Raising the Gas Limit addresses the execution capacity and cost pressures of the mainnet;
• BAL, ePBS, and EIP-8037 solve how to maintain node verifiability and controllable state growth during the expansion process;
• Keyed Nonces and Frame Transactions address the bottlenecks of account models, privacy protocols, and smart wallets at the protocol level;
• Native account abstraction and cross-L2 interoperability further point to the experiential improvements that ordinary users can truly feel.

This also means that Ethereum is entering a new stage.

After all, over the past few years, the market was more focused on L2 expansion, Blob fee reductions, and modular narratives, and users gradually became accustomed to transferring assets between different L2s to seek lower-cost interaction environments. However, as the mainnet Gas Limit continues to rise, upgrades like Glamsterdam are advancing, and the evolution of account abstraction and interoperability solutions continues, the questions Ethereum is now addressing are no longer just "how to make transactions cheaper," but "how to make the on-chain experience feel more like a cohesive whole."

In this process, the importance of wallets will undoubtedly be further amplified.

Because wallets are not just an entry point for users into Ethereum but also the interface through which protocol capabilities are truly understood and used. In the future, the more complex the underlying upgrades are, the more they need to be translated through wallets into clearer signing prompts, more understandable transaction paths, better risk recognition, and smoother on-chain interaction experiences.

Let’s encourage each other.

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