From Gas Limit to "Keyed Nonces": How to Understand the Next Step in Ethereum Scalability?

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

For example, in the past two years, many have personally experienced lower Gas fees for transfers and improved cross-chain interoperability. This is precisely why Ethereum's scaling has never been a simple "performance competition" issue—for ordinary users, higher TPS, larger blocks, and more complex underlying architecture only become meaningful when they translate into lower costs, smoother operations, and a more secure wallet experience.

Recently, a series of new developments in Ethereum all point towards a systematic effort to shift the complexity—previously borne by wallets, DApps, third-party relays, and users themselves—forward into the protocol layer.

These include Vitalik's involvement in Keyed Nonces, the directional consensus reached around a 2 billion Gas Limit floor during the Glamsterdam upgrade, and the sustained emphasis in the 2026 roadmap on native account abstraction, cross-L2 interoperability, and L1 security hardening—a series of interconnected clues.

1. Increasing the Gas Limit to 2 Billion?

Let's start with the most user-perceptible aspect: the Gas Limit.

As is well known, in the Ethereum network, every transaction (whether a transfer or a contract interaction) consumes a certain amount of Gas, and each Ethereum block has a fixed Gas Limit capacity. In other words, the number of "seats" is limited: the more seats available, the more passengers can be transported in a given period; the tighter the seats, the more users have to bid for the same spot, driving up Gas fees.

Theoretically, increasing the block Gas limit directly and significantly enhances the performance of the Ethereum mainnet. However, in the past, Ethereum has been relatively cautious about this, especially given the major development of the L2 scaling route. Most of the scaling pressure was intentionally directed towards the L2 track.

Looking at the historical curve of Ethereum's Gas Limit, one can see that after breaking through 10 million for the first time in September 2019 (from 8 million), it took seven years—until this year—to go from 8 million to 60 million. The acceleration only truly began in 2025: 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 scaling occurred within the single year of 2025. Of course, as we have previously mentioned, 2025 has also been a pivotal year in Ethereum's history. The Fusaka upgrade, arriving just 7 months after the May Pectra upgrade in 2025, proved that the EF, despite undergoing significant leadership restructuring, still has the capacity to push major updates. It also marked Ethereum's official entry into an accelerated development rhythm of "two hard forks per year" (further reading: "Ethereum 2026: Interpreting the EF's Latest Protocol Roadmap, Formally Entering the 'Engineering Upgrade' Era?").

Source: Etherscan

According to the Soldøgn Interop Recap published by the Ethereum Foundation on May 2, over 100 core Ethereum contributors participated in an interoperability meeting centered around the Glamsterdam upgrade in Svalbard, Norway. The key goal was to advance multi-client implementation, testing, and parameter alignment for Glamsterdam. By the end of the meeting, developers had reached directional consensus on a 2 billion Gas Limit floor for the period following Glamsterdam.

This means that, if subsequent processes proceed smoothly, Ethereum L1's execution capacity could be further increased from the current ~60 million Gas Limit to the order of 2 billion. Looking at a longer time horizon, the Ethereum ecosystem's publicly discussable attitude towards the Gas Limit has become noticeably more "aggressive". EIP-9698 even proposes to "increase by ten times every two years," aiming for a Gas Limit of 3.6 billion by 2029—50 times the current level.

However, it is crucial to emphasize here that increasing the Gas Limit is not simply about making blocks larger.

If we merely and roughly increase the computational capacity each block can hold, it might lower fees in the short term, but it would lead to heavier node burdens, state data bloat, and make it harder for ordinary users to run nodes over the long term. This would ultimately weaken Ethereum's core foundation of decentralization. The Glamsterdam scaling strategy is therefore a combined toolkit:

• ePBS (enshrined Proposer-Builder Separation) more clearly incorporates the block building and verification process into protocol rules, allowing 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, enabling parallel disk reads, parallel transaction verification, and parallel state root calculations.
• EIP-8037 aims to prevent excessively rapid state growth when the Gas Limit is increased by raising the cost of operations related to state creation.

In essence, Ethereum isn't just trying to "fit in more transactions"; it's thinking about how to fit in more transactions without making the barrier to running a node increasingly high.

This is the fundamental difference between Ethereum's scaling path and the narratives of many high-performance chains. The pursuit has never been about sacrificing verification cost for superficial throughput, but rather about increasing the mainnet's own carrying capacity while maintaining, as much as possible, ordinary node participation and system verifiability.

2. Keyed Nonces: Turning a "Single Queue" into "Multiple Lanes"

If the Gas Limit solves the problem of "how much a block can hold," then Keyed Nonces addresses a more detailed but equally critical question: How should transactions queue up?

As is well known, in Ethereum, a nonce can be simply understood as the "sequence number" of a transaction for an account. Its purpose is to prevent the same transaction from being executed twice and to ensure that transactions from the same account are processed in order.

In a standard transfer scenario, this mechanism is straightforward: the first transaction, the second transaction, the third transaction, all lined up sequentially in order.

The problem arises when account capabilities become more complex, involving features like privacy transactions, smart wallets, session keys, batch operations, and third-party fee sponsorship. In these cases, the single linear nonce can become a bottleneck. Therefore, the core idea of Keyed Nonces, proposed in EIP-8250, is to change a single account from having one nonce queue to being able to have multiple nonce domains.

Specifically, it replaces the single sender nonce in 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 select independent, protocol-managed nonce sequences. Transactions under different keys are independent of each other, and their replay protection does not interfere.

This sounds very technical, but can be understood with a real-world 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 types of business to different windows—transfers, privacy withdrawals, session authorizations, and batch executions can each use their own dedicated lane.

This is especially 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 from the same shared sender address. With a single nonce mechanism, once one user's transaction is included in a block, it could invalidate or block other users' pending transactions.

Keyed Nonces allow each outgoing transaction to choose its own nonce domain—for example, derived from a privacy nullifier—thereby reducing such queue conflicts at the protocol level.

Vitalik Buterin himself has an even grander vision for this. When introducing EIP-8250, he explicitly stated that Keyed Nonces are "not just stronger support for protocol-level privacy schemes; they might also be the first step towards a new state scaling strategy for Ethereum. By creating specialized storage types optimized for different use cases, it could achieve extreme scalability while maintaining the protocol's decentralization."

In other words, one can simply think of the Gas Limit as solving the "size of the block," while Keyed Nonces explores the "shape of the state" — what Ethereum needs to accommodate in the future is not just more transactions, but more *types* of transactions.

3. How Will This Affect Ordinary Users?

For the Ethereum ecosystem, many protocol upgrades might seem far removed from ordinary users, but they ultimately impact the wallet experience.

Because the entry point for users to truly interact with Ethereum is not EIPs, clients, or developer meetings, but every single transfer, authorization, signature, cross-chain operation, and DApp interaction within their wallets. In other words, changes at the protocol layer only truly complete the transformation from a technical upgrade to a user experience upgrade when they are translated into clearer, smoother, and safer operational experiences at the wallet layer.

For example, the now widely familiar concept of account abstraction is not about making users understand more technical jargon, but about enabling them to use on-chain accounts more naturally in the future. This is why features like batch transactions, gas sponsorship, recovery mechanisms, different signature methods, session authorizations, and more flexible security policies are gradually becoming foundational capabilities within wallets.

Similarly, take Keyed Nonces. It sounds like a very low-level optimization of the account queuing mechanism, but from the user's perspective, its potential impact is far from abstract. Many users on-chain today may have encountered a scenario like this: a pending transaction takes forever to confirm, blocking subsequent transactions; trying to cancel or speed up a transaction without fully understanding the relationship between nonce, gas, and replacement transactions. This is especially troublesome when multiple operations are attempted in parallel, where one failed step can cascade and affect all subsequent processes.

To an ordinary user, these problems manifest as "the wallet is hard to use" or "the chain is slow," but behind the scenes, it is often related to the design of the single linear nonce in Ethereum's account model. The direction represented by Keyed Nonces is to allow an account to no longer be forced to execute all operations sequentially in a single line but to be able to split them into multiple parallel lanes based on different usage scenarios.

This would mean that operations like regular transfers, DApp authorizations, privacy transactions, batch transactions, and gas sponsorship could theoretically have more independent execution space, reducing the probability of blocking and conflicting with each other.

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 collectively bear the complexity. Users had to understand authorization scopes, judge whether Gas fees were reasonable, know exactly what they were signing, and repeatedly confirm multi-step operations involving cross-chain transfers, swaps, staking, and reward claims. A misunderstanding at any step could lead to operational failure and asset loss risk.

What Ethereum is currently attempting to do is precisely to push some of this complexity forward into the protocol layer. This allows wallets to provide better interaction abstraction for users based on more standardized, native underlying capabilities.

This is why Gas Limit, BAL, ePBS, Keyed Nonces, Frame Transactions, native account abstraction, and cross-L2 interoperability—though seemingly belonging to different technical modules—are all serving the same purpose: enabling Ethereum to support more complex on-chain use cases without sacrificing decentralization and security.

Specifically, when looking at these developments together, it becomes clear 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 the scaling process.
• Keyed Nonces and Frame Transactions address the bottlenecks in the account model, privacy protocols, and smart wallets at the protocol layer.
• Native account abstraction and cross-L2 interoperability point directly towards the tangible experience improvements that ordinary users will feel.

This also signifies that Ethereum is entering a new phase.

After all, in the past few years, the market has focused more on L2 scaling, Blob fee reduction, and modularity narratives. Users have also grown accustomed to moving assets between different L2s to find lower-cost interaction environments. But as the mainnet Gas Limit continues to rise, upgrades like Glamsterdam advance, 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 feel like a cohesive whole."

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

Because the wallet is not just the user's gateway into Ethereum; it is also the interface through which the protocol's capabilities are truly understood and utilized by users. In the future, the more complex the underlying upgrades, the more they need to be translated through the wallet into clearer signature prompts, more understandable transaction paths, more proactive risk identification, and a smoother on-chain interaction experience.

Let's work towards this together.