Objectively speaking, in recent times, many users' intuitive perception of Ethereum often doesn't come from roadmap updates or developer meetings, but from specific on-chain operations.
For example, in the past couple of years, people have tangibly felt lower Gas fees during transfers and improved experiences with cross-chain interoperability. This is precisely why Ethereum's scaling has never been purely a "performance race" issue—for ordinary users, higher TPS, larger blocks, and more complex underlying architectures are only meaningful when they genuinely translate into lower costs, smoother operations, and a more secure wallet experience.
A series of recent developments in Ethereum happen to be pointing towards its attempt to systematically shift complexities previously borne by wallets, DApps, third-party relayers, and users themselves, forward to the protocol layer.
Among these are Vitalik's involvement with Keyed Nonces, the directional consensus formed around the 200 million Gas Limit floor during the Glamsterdam upgrade, and the continuing threads highlighted in the 2026 roadmap, including native account abstraction, cross-L2 interoperability, and L1 security reinforcement.
One: Gas Limit Increase to 200 Million?
First, let's look at the aspect most easily perceived by users: Gas Limit.
As is well known, in the Ethereum network, every transaction (whether a transfer or contract interaction) consumes a certain amount of Gas, and each Ethereum block has a fixed Gas Limit capacity, meaning limited slots: more slots allow more "passengers" to be carried in the same timeframe; more competition for the same seat drives up Gas fees.
Theoretically, increasing the block Gas limit would directly and significantly boost Ethereum mainnet performance. However, in the past, against the backdrop of significant developments like L2, Ethereum has been relatively cautious and restrained in this regard. Most scaling pressure has been intentionally directed toward the L2 track.
Looking at the history of Ethereum's Gas Limit expansion reveals that after first surpassing 10 million from 8 million in September 2019, it took until this year—seven years—for the Gas Limit to increase from 8 million to 60 million. Notably, acceleration truly began in 2025—increasing from 30 million to 36 million in February, to 45 million in July, and then to 60 million after the Fusaka upgrade in December.
It can be said that most of the expansion was crammed into the year 2025. As we've mentioned before, 2025 was also a crucial year in Ethereum's development history. The Fusaka upgrade, just 7 months after the May Pectra upgrade, proved that the Ethereum Foundation (EF), despite major leadership changes, retained the ability to push major updates. It also marked Ethereum's official entry into an accelerated development rhythm of "two hard forks per year" (Extended reading: "Ethereum 2026: Interpreting EF's Latest Protocol Roadmap, Officially Entering the 'Engineering Upgrade' Era?").
Source: Etherscan
According to the Ethereum Foundation's Soldøgn Interop Recap released on May 2nd, over 100 core Ethereum contributors participated in an interoperability meeting in Svalbard, Norway, centered on the Glamsterdam upgrade. The key goals were advancing multi-client implementation, testing, and parameter alignment for Glamsterdam. By the meeting's end, developers had reached a directional consensus regarding a 200 million Gas Limit post-Glamsterdam.
This means that if subsequent processes proceed smoothly, Ethereum L1's execution capacity is expected to increase from the current ~60 million Gas Limit to around 200 million. Over a longer timeframe, the Ethereum ecosystem's publicly discussable stance on the Gas Limit has clearly become much more "aggressive." EIP-9698 even proposes "doubling every two years," aiming to raise the Gas Limit to 3.6 billion by 2029, which would be 50 times the current level.
However, it's crucial to emphasize that increasing the Gas Limit isn't simply about making blocks bigger.
If we merely brute-force increased the computational load each block can handle, in the short term it might lower fees, but long-term it would lead to heavier node burdens and state data bloat. This also means it becomes more difficult for ordinary users to run nodes, ultimately undermining Ethereum's core decentralized foundation.
Therefore, Glamsterdam's scaling approach is a combination of measures:
- ePBS (enshrined Proposer-Builder Separation) more clearly incorporates block building and validation processes into protocol rules, allowing validators to process larger blocks more securely;
- Block-Level Access Lists (BAL) pre-record the accounts and storage locations to be accessed during block execution, enabling parallel disk reads, parallel transaction validation, and parallel state root calculations;
- EIP-8037, by increasing the cost of state creation-related operations, aims to prevent excessive state growth after the Gas Limit increase.
Ultimately, Ethereum doesn't just want to "fit more transactions," but is also thinking about how to do so without making node operation increasingly inaccessible.
This is the fundamental distinction between Ethereum's scaling roadmap and many high-performance chain narratives. Ethereum has consistently pursued not sacrificing verification costs for superficial throughput, but rather increasing the mainnet's own carrying capacity while preserving ordinary node participation and system verifiability as much as possible.
Two: Keyed Nonces: Turning 'One Line' into 'Multiple Channels'
If Gas Limit addresses "how much can fit in a block," then Keyed Nonces focuses on another more detailed yet crucial question: how should transactions queue up?
As is well known, in Ethereum, a nonce can be simply understood as the "sequence number" for an account's transactions. Its role is to prevent the same transaction from being executed repeatedly and to ensure transactions from the same account are processed in order.
This mechanism is easy to understand in simple transfer scenarios: the first transaction, second transaction, third transaction, and so on, queued sequentially.
The problem arises when account capabilities become more complex, involving private transactions, smart wallets, session keys, batch operations, third-party payment sponsors, etc. In these cases, a single linear nonce can become a bottleneck. Therefore, the core idea of EIP-8250's Keyed Nonces is to change from an account having only one nonce queue to having multiple nonce domains.
Specifically, it replaces the single sender nonce from EIP-8141 Frame Transactions with a (nonce_key, nonce_seq) structure. Here, nonce_key == 0 corresponds to the traditional account nonce, while non-zero keys can opt for independent protocol-managed nonce sequences. Transactions under different keys are independent of each other, preventing replay and not affecting one another.
This sounds technical, but it can be understood with a real-life analogy: Before, an account was like a bank with only one window; all business had to queue in the same line. Keyed Nonces is like assigning different services to different windows—transfers, private withdrawals, session authorizations, batch executions can each take their own channel.
This is particularly important for privacy protocols. To avoid directly linking a user's on-chain activity to a single public address, privacy protocols might have multiple users initiate transactions through a shared sender address. However, under a single nonce mechanism, once one user's transaction gets packaged, it could cause other users' pending transactions to become invalid or blocked.
Keyed Nonces allows each spending action to choose its own nonce domain, for example, derived from a privacy nullifier, reducing this queuing conflict at the protocol layer.
Vitalik himself positions it even more grandly. When introducing EIP-8250, he explicitly stated that Keyed Nonces "is not only stronger support for protocol-layer privacy solutions, but could also be the first step in a new Ethereum state scaling strategy—achieving ultimate scalability while maintaining protocol decentralization by creating specialized, optimized storage types for different use cases."
In other words, one could simply understand it as: Gas Limit solves "block size," while Keyed Nonces explores the "shape of state." Ethereum aims to carry not just more transactions, but more *kinds* of transactions in the future.
Three: How Will This Affect Ordinary Users?
For the Ethereum ecosystem, many protocol upgrades may seem distant from ordinary users, but they ultimately manifest in the wallet experience.
Because the real entry point for users interacting with Ethereum isn't EIPs, clients, or developer meetings, but every transfer, authorization, signature, cross-chain, and DApp interaction within a wallet. That is to say, changes at the protocol layer only truly complete the transition from technical upgrade to user experience upgrade when they are translated into clearer, smoother, and more secure operational experiences at the wallet layer.
For instance, the now-familiar concept of account abstraction isn't about making users understand more technical terms, but about enabling users to use on-chain accounts more naturally in the future. That's why in recent years, features like batch transactions, Gas sponsorship, recovery mechanisms, different signature methods, session authorizations, and more flexible security policies have gradually become basic wallet capabilities.
Similarly, taking Keyed Nonces as an example, it sounds like a very low-level optimization of account queuing mechanisms. But from the user's perspective, its potential impact is not abstract. Many users today may have encountered scenarios during on-chain operations where a transaction is pending for too long, blocking subsequent ones; wanting to cancel or speed up a transaction but not understanding the relationship between nonce, Gas, and replacement transactions; especially during multi-step parallel operations, one failed step can disrupt the entire subsequent flow.
For ordinary users, these issues might seem like "the wallet is bad" or "the chain is bad," but in fact, they are related to the design of the single linear nonce in Ethereum's account model. The direction represented by Keyed Nonces is to allow accounts to no longer execute all operations sequentially in one queue, but to split into multiple parallel channels according to different usage scenarios.
In the future, operations like regular transfers, DApp authorizations, privacy transactions, batch transactions, and Gas sponsorship could theoretically have more independent execution spaces, reducing the probability of mutual blocking and conflicts.
This will undoubtedly 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 complexity. Users had to understand authorization scopes, judge if Gas was reasonable, know exactly what they were signing, and repeatedly confirm multi-step operations across bridging, swapping, staking, claiming rewards, etc. Any misunderstanding could lead to operational failure and asset loss risks.
What Ethereum is now attempting to do is shift some of this complexity forward to the protocol layer, allowing wallets to provide better interaction abstractions for users based on more standardized, more native underlying capabilities.
This is also why Gas Limit, BAL, ePBS, Keyed Nonces, Frame Transactions, native account abstraction, and cross-L2 interoperability, while seemingly belonging to different technical modules, are all serving the same goal: enabling Ethereum to carry more complex on-chain usage scenarios without sacrificing decentralization and security.
Looking specifically, putting these developments together reveals that Ethereum's recent focus is not scattered:
- Gas Limit increase addresses mainnet execution capacity and fee pressure.
- BAL, ePBS, EIP-8037 address how to maintain node verifiability and controlled state growth during scaling.
- Keyed Nonces and Frame Transactions address bottlenecks at the protocol layer for account models, privacy protocols, and smart wallets.
- Native account abstraction and cross-L2 interoperability further point towards tangible experience improvements for ordinary users.
This also signifies that Ethereum is entering a new phase.
After all, in recent years, the market has focused more on L2 scaling, Blob fee reductions, and modular narratives. Users have also gradually become accustomed to moving assets between different L2s and seeking lower-cost interaction environments. However, as mainnet Gas Limits continue to rise, upgrades like Glamsterdam progress, and account abstraction and interoperability solutions evolve, the question Ethereum is now answering is no longer just "how to make transactions cheaper," but "how to make the on-chain experience more like a cohesive whole."
In this process, the importance of wallets will undoubtedly be further amplified.
Because wallets are not just the entry point for users into Ethereum; they are also the interface through which protocol capabilities are truly understood and utilized by users. In the future, the more complex the underlying upgrades, the more they will need to be translated by wallets into clearer signature prompts, more understandable transaction paths, more upfront risk identification, and smoother on-chain interaction experiences.
Let's work towards this together.
