Author: imToken
Objectively speaking, for some time now, many users' intuitive understanding of Ethereum has often not come from roadmap or developer meetings, but from specific on-chain operations.
For example, in recent years, what everyone has personally felt includes lower Gas during transfers, improved cross-chain interoperability experiences, and so on. This is precisely why Ethereum's scaling has never been a simple 'performance race' problem—for ordinary users, higher TPS, larger blocks, and more complex underlying architectures only make sense when they are truly translated into lower costs, smoother operations, and safer wallet experiences.
And recently, a series of new developments in Ethereum happen to point towards Ethereum's attempt to systematically shift the complexity that was previously borne by wallets, DApps, third-party relayers, and users themselves, forward to the protocol layer.
Among these are Keyed Nonces with Vitalik's involvement, the directional consensus formed around the 200 million Gas Limit floor in the Glamsterdam upgrade, and the series of subtle clues in the 2026 roadmap that continue to emphasize native account abstraction, cross-L2 interoperability, and L1 security strengthening.
I. Gas Limit Increased to 200 Million?
First, let's look at the most easily perceived point for users: Gas Limit.
As is well known, in the Ethereum network, every transaction (whether it's a transfer or a contract interaction) consumes a certain amount of Gas, and the Gas Limit capacity of each Ethereum block is fixed, meaning the number of 'slots' is limited: the more slots, the more 'passengers' can be transported in the same time period; the more slots are tight, people have to bid for the same seat, and Gas fees also rise.
Theoretically, expanding the block Gas limit would indeed directly and significantly improve the performance of the Ethereum mainnet. However, in the past, against the backdrop of significant developments in routes like L2, Ethereum has been relatively cautious and restrained about this. Most of the scaling pressure has been intentionally directed towards the L2 track.
Looking at the expansion curve of Ethereum's Gas Limit reveals that after the Ethereum network's Gas Limit first broke through 10 million from 8 million in September 2019, it wasn't until this year, over 7 years, that the Gas Limit increased from 8 million to 60 million. Especially, it truly entered the acceleration phase only in 2025—from 30 million to 36 million in February, increased again to 45 million in July, and upgraded to 60 million after the Fusaka upgrade in December.
It can be said that most of the expansion was squeezed into the year 2025. Of course, as we mentioned earlier, 2025 is also a crucial year in Ethereum's development history. The Fusaka upgrade, just 7 months after the May Pectra upgrade, proved that the EF, despite undergoing significant leadership changes, still has the ability to drive major updates. It also marked Ethereum's formal entry into an accelerated development rhythm of 'two hard forks per year' (See Extended Reading《Ethereum 2026: Interpreting EF's Latest Protocol Roadmap, Officially Entering the Era of 'Engineering Upgrades'?》).
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 conference in Svalbard, Norway, focusing on the Glamsterdam upgrade. The key goals were to advance the multi-client implementation, testing, and parameter alignment for Glamsterdam. At the end of the conference, developers had formed a directional consensus around a 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 approximately 60 million Gas Limit to a magnitude of 200 million. On a longer time scale, the Ethereum ecosystem's publicly discussable attitude towards Gas Limit has clearly become much more 'radical'. The EIP-9698 proposal even suggests 'increasing tenfold every two years', raising the Gas Limit to 3.6 billion by 2029, which is 50 times the current level.
However, it needs to be emphasized here that increasing the Gas Limit is not simply about making blocks bigger.
If it only roughly increases the computational capacity each block can hold, it might lower fees in the short term, but in the long run, it would burden nodes more heavily, cause state data inflation, and also mean it becomes more difficult for ordinary users to run nodes, ultimately weakening Ethereum's most core decentralized foundation.
Therefore, Glamsterdam's scaling approach is a combination punch:
- ePBS (enshrined Proposer-Builder Separation) more clearly incorporates the block building and verification process into protocol rules, allowing validators to more securely handle larger blocks;
- Block-Level Access Lists (BAL) pre-record the accounts and storage locations to be accessed during block execution, thereby supporting parallel disk reads, parallel transaction verification, and parallel state root calculation;
- And EIP-8037 increases the cost of state creation-related operations to avoid excessive state growth after the Gas Limit is increased.
Ultimately, Ethereum doesn't just want to 'fit more transactions'; it's also thinking about how to not make node operation thresholds increasingly higher while fitting more transactions.
This is also the fundamental difference between Ethereum's scaling roadmap and many high-performance chain narratives. It has always pursued not sacrificing verification cost for superficial throughput, but rather increasing the mainnet's own carrying capacity while trying to maintain ordinary node participation and system verifiability.
II. Keyed Nonces: Turning 'One Queue' into 'Multiple Lanes'
If Gas Limit solves 'how much a block can hold', then Keyed Nonces focuses 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 'sequence number' of an account's transaction. 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 ordinary transfer scenarios: it's the first transaction, second transaction, third transaction in sequence, queued one after another.
However, the problem is that when account capabilities become more complex, such as involving private transactions, smart wallets, session keys, batch operations, third-party payment, etc., a single linear nonce can become a bottleneck. Therefore, the core idea of Keyed Nonces, proposed in EIP-8250, is to change from an account having only one nonce queue to being able 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 independent protocol-managed nonce sequences. Transactions under different keys are independent of each other, and replay protection does not interfere between them.
This sounds technical, but it can be understood with a life analogy: In the past, an account was like having only one window at a bank, all business had to queue in the same line; Keyed Nonces is like assigning different businesses to different windows. Transfers, private withdrawals, session authorizations, batch executions can each take their own lane.
This is especially important for privacy protocols because, to avoid directly binding users' on-chain activities to a single public address, privacy protocols might have multiple users initiate transactions through the same shared sender address. However, under a single nonce mechanism, once one user's transaction is packaged, it could cause other users' waiting transactions to become invalid or blocked.
Whereas Keyed Nonces allows each withdrawal to choose its own nonce domain, for example, derived from a privacy nullifier, reducing this queuing conflict from the protocol layer.
Vitalik's own positioning of it is even more ambitious. When introducing EIP-8250, he clearly stated that Keyed Nonces 'not only provides stronger support for protocol-layer privacy solutions, but may also be the first step in Ethereum's new state scaling strategy—by creating storage types specifically optimized for different use cases, achieving ultimate scalability while maintaining protocol decentralization.'
In other words, it can be simply understood as: Gas Limit solves the 'size of the block', while Keyed Nonces explores the 'shape of the state'—what Ethereum needs to carry in the future is not just more transactions, but more types of transactions.
III. How Will This Affect Ordinary Users?
For the Ethereum ecosystem, many protocol upgrades seem far from ordinary users, but ultimately they all land on the wallet experience.
Because the real entry point for users to interact with Ethereum is not EIPs, clients, or developer meetings, but every transfer, authorization, signature, cross-chain, and DApp interaction within the wallet. That is to say, changes at the protocol layer only truly complete the transformation from technical upgrade to user experience upgrade when they are translated into clearer, smoother, and safer operational experiences at the wallet layer.
For example, the now familiar account abstraction is not meant to make users understand more technical terms, but to allow users to more naturally use on-chain accounts in the future. Therefore, in recent years, batch transactions, Gas payment by others, recovery mechanisms, different signature methods, session authorizations, and more flexible security strategies have gradually become basic capabilities in wallets.
Similarly, taking Keyed Nonces as an example, it sounds like a very low-level optimization of the account queuing mechanism. But on the user side, its potential impact is not abstract. Because today, many users may have encountered similar scenarios during on-chain operations: a transaction is not confirmed for a long time, subsequent transactions get stuck; wanting to cancel or speed up a transaction but not understanding the relationship between nonce, Gas, and replacement transactions; especially during parallel multi-step operations, one failed step affects all subsequent processes.
For ordinary users, these problems seem like 'the wallet isn't easy to use' or 'the chain isn't easy to use'. But behind them is actually related to the design of the single linear nonce in the Ethereum account model. The direction represented by Keyed Nonces is to allow accounts to no longer have to execute all operations in order through one queue, but to split into multiple parallel lanes according to different usage scenarios.
In the future, ordinary transfers, DApp authorizations, private transactions, batch transactions, Gas payment by others, and other operations could theoretically have more independent execution spaces, reducing the probability of blocking and conflicts with each other.
This will undoubtedly further expand the design space for smart wallets.
More importantly, in the past, these capabilities often required the complexity to be shared among wallets, DApps, relay services, and users. Users needed to understand authorization scopes, judge whether Gas was reasonable, know exactly what they were signing, and repeatedly confirm in multi-step operations like cross-chain, swapping, staking, and claiming rewards. Any misunderstanding at any step could lead to operational failure and asset loss risk.
What Ethereum is now trying to do is to move part of this complexity forward to the protocol layer, allowing wallets to provide better interaction abstraction 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, seemingly belonging to different technical modules, are actually all serving the same thing: enabling Ethereum to carry more complex on-chain usage scenarios without sacrificing decentralization and security.
Looking specifically, putting these dynamics 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 in account models, privacy protocols, and smart wallets at the protocol layer;
- Native account abstraction and cross-L2 interoperability further point towards the experience improvements that ordinary users can truly feel.
This also means Ethereum is entering a new stage.
After all, in the past few years, the market paid more attention to L2 scaling, Blob fee reduction, and modular narratives. Users also gradually got used to transferring assets between different L2s and finding lower-cost interaction environments. However, as the mainnet Gas Limit continues to increase, upgrades like Glamsterdam progress, and account abstraction and interoperability solutions continue to evolve, the question Ethereum is answering is no longer just 'how to make transactions cheaper', but 'how to make the on-chain experience more like a whole'.
In this process, the importance of wallets will undoubtedly be further amplified.
Because wallets are not only the entry point for users into Ethereum, but also the interface through which protocol capabilities are truly understood and used by users. In the future, the more complex the underlying upgrades, the more they 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 encourage each other.
