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

For example, in the past two years, the experiences of lower gas fees during transactions and improved cross-chain interoperability are felt by everyone. This is also why Ethereum's scaling has never been a simple "performance race" issue — for ordinary users, higher TPS, larger blocks, and more complex underlying architecture only make sense when they truly translate into lower costs, smoother operations, and a safer wallet experience.

Recently, a series of new dynamics from Ethereum have been pointing to the fact that Ethereum is trying to systematically move the complexities previously borne by wallets, DApps, third-party relayers, and users themselves to the protocol layer.

This includes aspects like the Keyed Nonces participated in by Vitalik, the directional consensus formed around the 200 million Gas Limit floor in the Glamsterdam upgrade, and the continued emphasis on native account abstraction, cross-L2 interoperability, and L1 security enhancement highlighted in the 2026 roadmap.

1. Raising Gas Limit to 200 Million?

First, let's look at the aspect most easily perceived by users: the Gas Limit.

It is well known that within the Ethereum network, each transaction (regardless of whether it is a transfer or contract interaction) requires the consumption of a certain amount of gas, and the Gas Limit capacity of each Ethereum block is fixed, meaning there are limited slots: the more slots there are, the more passengers can be transported in the same time period; the tighter the slots, the more everyone has to bid for the same seat, and gas fees will rise with the tides.

In theory, expanding the block gas limit would indeed directly and significantly enhance the performance of the Ethereum mainnet, but in the past, under the overarching background of rapid development in L2, Ethereum has remained cautious and restrained about this, with most of the scaling pressure intentionally pushed towards the L2 track.

Looking back at the expansion curve of the Ethereum Gas Limit, one can see that from September 2019, when Ethereum's network Gas Limit first broke through 10 million from 8 million, it took seven years for the Gas Limit to grow from 8 million to 60 million, especially as the real acceleration phase began in 2025—growing from 30 million to 36 million in February, then to 45 million in July, and finally to 60 million after the Fusaka upgrade in December.

It can be said that most of the expansion completed will be squeezed into the year 2025. Of course, we have previously mentioned that 2025 is also a crucial year in the history of Ethereum. The Fusaka upgrade just seven months after the Pectra upgrade in May proved that the EF, which has undergone significant leadership adjustments, still has the ability to push for major updates, marking Ethereum's formal entry into an accelerated development rhythm of "two hard forks a year" (for extended reading, see Ethereum 2026: Interpreting 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 contributors of Ethereum participated in an interoperability meeting in the Svalbard archipelago of Norway centered around the Glamsterdam upgrade, with the main goal being to advance the multi-client implementation, testing, and parameter alignment of Glamsterdam. At the end of the meeting, developers had already formed a directional consensus regarding the 200 million Gas Limit after Glamsterdam.

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

However, it is important to emphasize that raising the Gas Limit is not simply about making blocks larger.

If we simply increase the amount of computation each block can accommodate, in the short term, it may reduce fees, but in the long term, it can lead to a heavier burden on nodes, data state inflation, and make it more difficult for ordinary users to run nodes, ultimately undermining the most core decentralized foundation of Ethereum.

Thus, the scaling approach of Glamsterdam is a combination of strategies:

• ePBS (enshrined Proposer-Builder Separation) incorporates the block construction and validation process more clearly into protocol rules, enabling validators to handle larger blocks more securely;
• Block-Level Access Lists (BAL) pre-record the accounts and storage locations that will be accessed during block execution, thus supporting parallel disk reading, parallel transaction validation, and parallel state root computation;
• And EIP-8037 increases the cost of operations related to state creation to avoid rapid state growth after the Gas Limit is raised;

Ultimately, Ethereum is not just looking to "accommodate more transactions," but is also considering how to increase the capacity to accommodate more transactions without raising the operational thresholds for nodes.

This is also the fundamental difference between Ethereum's scaling approach and many high-performance chain narratives, where the continuous pursuit is not to sacrifice validation costs for superficial throughput, but to enhance the mainnet's capacity while maintaining participatory eligibility for ordinary nodes and verifiable systems.

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

If the Gas Limit addresses "how much can a block hold," then Keyed Nonces focus on another more detailed but crucial issue: how should a transaction queue up?

It is well known that in Ethereum, a nonce can be simply understood as the "serial number" of account transactions. Its role is to prevent the same transaction from being executed multiple times, ensuring that transactions sent from the same account are processed in order.

This mechanism is easy to understand in typical transfer scenarios, where transactions are lined up sequentially as the first transaction, second transaction, third transaction, and so on.

But the problem arises when an account's capabilities become more complex, for example, involving privacy transactions, smart wallets, session keys, batch operations, or third-party payments, where a single linear nonce can become a bottleneck. Therefore, EIP-8250 proposes Keyed Nonces, with the core idea being to change the original model where an account had only one nonce queue to one that can 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, and non-zero keys can select independent protocols to manage nonce sequences. Transactions under different keys are independent of each other and do not affect replay.

This sounds very technical, but it can be understood with a more relatable analogy: in the past, an account was like having only one window at a bank, requiring all business to queue at the same line; Keyed Nonces, on the other hand, are like assigning different types of business to different windows, allowing transfers, privacy withdrawals, session authorizations, and batch operations to each have their own channels.

This is especially important for privacy protocols, as they may allow multiple users to initiate transactions through the same shared sender address to avoid tying users' on-chain activities directly to a specific public address. However, under a single nonce mechanism, if one user’s transaction is packaged, it could cause the pending transactions of other users to become inactive or block.

Furthermore, Keyed Nonces allow each spending to choose its nonce domain, for example, derived from a privacy nullifier, thereby reducing such queuing conflicts at the protocol layer.

Vitalik himself has a broader view of its positioning; when introducing EIP-8250, he stated that Keyed Nonces "not only provide stronger support for protocol layer privacy schemes but may also represent the first step in a new state scaling strategy for Ethereum — by creating specially optimized storage types for different use cases, achieving extreme scalability while maintaining protocol decentralization."

In other words, we can simply understand that while Gas Limit solves the "size of blocks," Keyed Nonces explores the "shape of state" — what Ethereum will need to carry in the future is not just more transactions but also a broader variety of transactions.

3. How Will This Affect Ordinary Users?

For the Ethereum ecosystem, many protocol upgrades may seem far removed from ordinary users, but they ultimately fall back to the wallet experience.

Because the real entry point for users to engage with Ethereum is not EIPs, clients, or developer meetings, but each time they make a transfer, authorization, signature, cross-chain interaction, and DApp interaction within their wallets. In other words, changes at the protocol layer only truly accomplish the transformation from technical upgrades to user experience upgrades when those changes are translated into clearer, smoother, and safer operational experiences at the wallet level.

For example, the now-familiar concept of account abstraction is not meant to make users understand more technical terms but to allow users to naturally use on-chain accounts in the future. Therefore, in recent years, batch transactions, gas payments, recovery mechanisms, different signing methods, session authorizations, and more flexible security strategies have gradually become foundational capabilities within wallets.

Similarly, taking Keyed Nonces as an example, it may sound like a very low-level optimization of account queuing mechanisms, but for users, its potential impact is not abstract at all. Today, many users might have encountered similar scenarios during on-chain operations: a transaction is delayed in confirmation, subsequent transactions get stuck, wanting to cancel or expedite a transaction, yet do not understand the relationships between nonce, gas, and replacement transactions, especially when multiple operations run in parallel; one failed step can impact the entire subsequent process.

For ordinary users, these issues may appear as "the wallet is hard to use" or "the chain is not performing well," but behind this is actually related to the single linear nonce design in Ethereum's account model. The direction represented by Keyed Nonces is to allow accounts to execute all operations sequentially along multiple lines rather than just one.

In the future, ordinary transfers, DApp authorizations, privacy transactions, batch transactions, gas payments, etc., can theoretically have more independent execution spaces, reducing the probability of blocking and conflicts with each other.

This will undoubtedly further open up the design space for smart wallets.

More importantly, in the past, these capabilities often required wallets, DApps, relay services, and users to jointly bear the complexities; users needed to understand the scope of authorization, determine whether gas was reasonable, know exactly what they were signing, and repeatedly confirm through multi-step operations like cross-chain transfers, exchanges, staking, and reward retrieval. Any misunderstanding at any step could introduce risks of operational failure and asset loss.

Now, what Ethereum is trying to do is to shift some of this complexity to the protocol layer, allowing wallets to provide users with better interaction abstractions based on more standardized and native underlying capabilities.

This is why Gas Limit, BAL, ePBS, Keyed Nonces, Frame Transactions, native account abstraction, and cross-L2 interoperability seem to belong to different technical modules yet are all serving the same goal: making Ethereum capable of supporting more complex on-chain usage scenarios without sacrificing decentralization and security.

Specifically, when looking at these dynamics together, one can see that Ethereum's recent focus is not scattered:

• Raising the Gas Limit addresses the execution capacity and cost pressure on the mainnet;
• BAL, ePBS, EIP-8037 solve how to maintain node verifiability and controllable state growth during the scaling process;
• Keyed Nonces and Frame Transactions resolve bottlenecks in account models, privacy protocols, and smart wallets at the protocol layer;
• 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 phase.

After all, in the past few years, the market has been more focused on L2 expansions, reducing blob costs, and modular narratives, and users have gradually become accustomed to transferring assets between different L2s and seeking lower-cost interaction environments. However, as the mainnet's Gas Limit continues to rise, the upgrades such as Glamsterdam advance, and as account abstraction and interoperability solutions continue to evolve, the questions Ethereum is addressing are no longer just "how to make transactions cheaper," but "how to make the on-chain experience feel more unified."

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

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

Let us encourage each other.

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