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

Null

Written by: imToken

Objectively speaking, over the past period, many users’ intuitive experiences with Ethereum often did not come from roadmaps or developer meetings, but from repeated specific on-chain operations.

For example, in the past two years, everyone has felt that Gas for transfers has become increasingly cheaper, and the experience of cross-chain interoperability has improved, among other things. This is also why scaling Ethereum has never been just a “performance race”—for ordinary users, higher TPS, larger blocks, and more complex underlying architectures only matter when they translate into lower costs, smoother operations, and safer wallet experiences.

Recently, a series of new developments on Ethereum are precisely pointing to the fact that Ethereum is trying to systematically shift the complexity previously borne by wallets, DApps, third-party relayers, and users themselves to the protocol layer.

This includes, among others, Vitalik’s involvement in Keyed Nonces, the direction consensus formed around the 200 million Gas Limit floor during the Glamsterdam upgrade, and a series of ongoing themes emphasized in the 2026 roadmap, such as native account abstraction, cross-L2 interoperability, and enhanced L1 security.

1. Raising Gas Limit to 200 Million?

Let’s first look at the most perceptible aspect for users: Gas Limit.

As is well known, in the Ethereum network, each transaction (whether transfer or contract interaction) consumes a certain amount of Gas, and the Gas Limit per block is fixed—meaning limited slots: the more slots, the more passengers can be transported at the same time; the tighter the slots, the more users must bid for the same seat, driving up Gas fees.

Theoretically, increasing the block Gas cap can directly and significantly improve Ethereum’s mainnet performance. However, in the past, Ethereum has been cautious and restrained in this regard, especially given the rapid development of Layer 2 solutions, with most scaling efforts intentionally directed toward L2.

Looking at the Gas Limit scaling curve, we see that in September 2019, Ethereum’s Gas Limit first exceeded 10 million from 8 million. Over the next seven years, it grew from 8 million to 60 million, with a real acceleration only in 2025—going from 30 million to 36 million in February, then up to 45 million in July, and after the Fusaka upgrade in December, reaching 60 million.

Most of the scaling was completed within 2025. As previously mentioned, 2025 is also a crucial year in Ethereum’s development history. Just seven months after the Pectra upgrade in May, the Fusaka upgrade demonstrated that EF, despite major leadership changes, still has the capacity to push significant updates. It also marked Ethereum’s transition into an accelerated development rhythm of “two hard forks per year” (see also “Ethereum 2026: Interpreting EF’s Latest Protocol Roadmap, Entering the Era of ‘Engineering Upgrades’?”).

Source: Etherscan

According to the Ethereum Foundation’s Soldøgn Interop Recap published on May 2, over 100 core contributors to Ethereum participated in an interoperability meeting on the Svalbard archipelago in Norway, focusing on advancing the multi-client implementation, testing, and parameter alignment for the Glamsterdam upgrade. By the end of the meeting, a directional consensus had been formed around a 200 million Gas Limit for Glamsterdam.

This means that if subsequent processes go smoothly, Ethereum L1’s execution capacity could be further increased from the current approximately 60 million Gas Limit to the 200 million range. Looking at the longer-term horizon, the community’s public attitude toward Gas Limit has become much more “aggressive”: proposals like EIP-9698 even suggest “a tenfold increase every two years,” aiming to raise Gas Limit to 3.6 billion by 2029—50 times the current limit.

However, it’s important to emphasize that increasing Gas Limit is not simply about making blocks bigger.

Roughly increasing the amount of computation per block might lower fees in the short term, but in the long run, it could burden nodes more heavily, cause state data to balloon, and make running a node more difficult for ordinary users—ultimately weakening Ethereum’s core decentralization.

Therefore, Glamsterdam’s scaling approach is a combination of strategies:

• ePBS (enshrined Proposer-Builder Separation) clarifies the block construction and validation process within protocol rules, enabling validators to handle larger blocks more securely;

• Block-Level Access Lists (BAL) pre-record accounts and storage locations accessed during block execution, supporting parallel disk reads, transaction validation, and state root computation;

• EIP-8037 increases the costs associated with state creation operations to prevent rapid state growth after Gas Limit increases.

At its core, Ethereum’s goal isn’t just to “fit more transactions,” but to do so without raising the barrier for node operation.

This is the fundamental difference between Ethereum’s scaling approach and many high-performance chains: Ethereum aims not to sacrifice validation costs for superficial throughput but to enhance the mainnet’s capacity while keeping participation and verifiability accessible for ordinary nodes.

2. Keyed Nonces: Turning “One Queue” into “Multiple Channels”

If Gas Limit addresses “how much can fit in a block,” then Keyed Nonces focus on a more detailed but critical issue: how should transactions be queued?

In Ethereum, nonces are simply the “sequence number” for an account’s transactions, preventing replay and ensuring transactions from the same account are processed in order.

This mechanism works well for simple transfers—transactions are processed sequentially: first, the first transaction, then the second, and so on.

But problems arise when accounts become more complex—such as involving privacy transactions, smart wallets, session keys, batch operations, or third-party payers. A single linear nonce can become a bottleneck. That’s where EIP-8250’s Keyed Nonces come in: the core idea is to replace the single nonce queue with multiple nonce domains.

Specifically, it replaces the single sender nonce in EIP-8141’s Frame Transaction with a structure of (nonce_key, nonce_seq), where nonce_key=0 corresponds to the traditional account nonce, and non-zero keys can be managed independently by protocols. Transactions under different keys are independent and non-replayable with each other.

This may sound technical, but it can be understood with a simple analogy: in the past, an account was like having only one window at a bank—every operation queued behind the same line. Keyed Nonces are like splitting different types of transactions into different windows, so transfers, privacy withdrawals, session authorizations, and batch executions can each go through their own channels.

This is especially important for privacy protocols, which aim to prevent user activity from being directly linked to a single public address. Privacy protocols might allow multiple users to share a sender address, but under a single nonce system, a transaction from one user could cause conflicts or invalidations for others’ pending transactions.

Keyed Nonces enable each transaction to choose its own nonce domain—derived, for example, from privacy nullifiers—reducing queue conflicts at the protocol level.

Vitalik himself sees this as a broader strategy: when introducing EIP-8250, he explicitly states that Keyed Nonces “not only support stronger privacy solutions at the protocol layer but may also be the first step in Ethereum’s new state scaling strategy—creating specialized storage types for different use cases, achieving maximum scalability while maintaining protocol decentralization.”

In other words, it’s a way to address not just block size (Gas Limit), but the “shape of state”—Ethereum’s future not only needs to carry more transactions but also more diverse types of transactions.

3. How Will This Affect Ordinary Users?

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

Because users’ actual entry point into Ethereum isn’t through EIPs, client updates, or developer meetings, but through every transfer, authorization, signature, cross-chain operation, and DApp interaction within wallets. That is, protocol-level changes only truly translate into better user experiences when they are reflected in clearer, smoother, and safer wallet operations.

For example, account abstraction, which everyone is familiar with, isn’t just about understanding more technical terms. It’s about enabling users to interact more naturally with on-chain accounts in the future. Over recent years, features like batch transactions, Gas payments on behalf of users, recovery mechanisms, different signature schemes, session authorizations, and more flexible security policies have gradually become core wallet capabilities.

Similarly, Keyed Nonces may sound like a low-level account queuing optimization, but its potential impact on users is tangible. Today, many users encounter scenarios like delayed transaction confirmations, stuck subsequent transactions, or difficulty canceling or speeding up transactions. They often don’t understand how nonce, Gas, and replacement transactions relate, especially when multiple operations run in parallel—one failed step can block the entire process.

To ordinary users, these issues seem like “wallet usability” or “chain usability” problems, but they are fundamentally related to the single linear nonce design in Ethereum’s account model. Keyed Nonces point toward a future where accounts are no longer restricted to a single sequential queue but can have multiple parallel channels based on different use cases.

In the future, simple transfers, DApp authorizations, privacy transactions, batch operations, and Gas payments could each have more independent execution spaces, reducing conflicts and blockages.

This will undoubtedly expand the design space for smart wallets.

More importantly, these capabilities have traditionally required wallets, DApps, relayers, and users to jointly bear complexity—users need to understand authorization scopes, judge whether Gas is reasonable, know what they are signing, and repeatedly confirm multi-step operations like cross-chain transfers, swaps, staking, and rewards. Any misunderstanding can lead to failed operations or asset loss.

Ethereum’s current approach is to shift some of this complexity to the protocol layer, allowing wallets to provide better interaction abstractions based on more standardized, native protocol capabilities.

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

Looking at these developments together, Ethereum’s recent focus is clear:

• Raising Gas Limit addresses mainnet capacity and fee pressure;

• BAL, ePBS, and EIP-8037 tackle how to maintain verifiability and controlled state growth during scaling;

• Keyed Nonces and Frame Transactions solve protocol-layer bottlenecks related to account models, privacy, and smart wallets;

• Native account abstraction and cross-L2 interoperability further aim to improve user experience.

This signals that Ethereum is entering a new phase.

In recent years, the market has focused more on L2 scaling, fee reductions, and modular narratives, with users gradually accustomed to transferring assets across different L2s and seeking lower-cost interactions. But as mainnet Gas Limit continues to rise, upgrades like Glamsterdam advance, and account abstraction and interoperability solutions evolve, the question Ethereum is answering is no longer just “how to make transactions cheaper,” but “how to make on-chain experiences feel more like a unified whole.”

In this process, the importance of wallets will only grow.

Because wallets are not only the entry point for users into Ethereum but also the interface through which protocol capabilities are truly understood and utilized. The more complex the underlying upgrades, the more they need to be translated into clearer signatures, more understandable transaction flows, upfront risk alerts, and smoother on-chain interactions.

Let’s work together towards that.