From Gas Limit to "Keyed Nonces": How to Understand the Next Frontier of Ethereum Scalability?

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

For example, in the last two years, many have experienced lower Gas fees for transfers and improved cross-chain interoperability. This is why Ethereum's scaling has never been a simple "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 more secure wallet experiences.

Recently, a series of new developments on Ethereum seem to be pointing towards a systematic effort to shift the complexity previously borne by wallets, DApps, third-party relayers, and users themselves, forward to the protocol layer.

This includes Vitalik's involvement in Keyed Nonces, the directional consensus around a 2 billion Gas Limit floor formed during the Glamsterdam upgrade, and a series of interconnected threads in the 2026 roadmap such as native account abstraction, cross-L2 interoperability, and L1 security enhancements.

1. Gas Limit Increased to 200 Million?

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 – meaning there are limited slots: More slots allow more transactions to be processed in the same timeframe; when slots are tight, users compete for the same seat by bidding up Gas fees.

Theoretically, increasing the block Gas limit would directly and significantly boost Ethereum mainnet performance. However, historically, Ethereum has been cautious about this amidst the rapid development of L2 solutions, pushing most scaling pressure towards the L2 track.

Looking at the historical chart of Ethereum's Gas Limit, we see that after breaking through 10 million from 8 million in September 2019, it took seven years to go from 8 million to 60 million. Notably, the acceleration 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.

One could say that most of the scaling was crammed into 2025. As mentioned before, 2025 was also a pivotal year in Ethereum's history. The Fusaka upgrade, just seven months after the Pectra upgrade in May, proved that the EF, despite major leadership changes, could still drive significant updates, marking Ethereum's official entry into an accelerated development rhythm of "two hard forks per year" (for more, read Ethereum 2026: Decoding the 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 meeting in Svalbard, Norway, focused on the Glamsterdam upgrade. The key objective was to advance multi-client implementation, testing, and parameter alignment for Glamsterdam. By the end of the meeting, developers had formed a directional consensus around a 200 million Gas Limit floor following Glamsterdam.

This implies that, if subsequent processes go smoothly, Ethereum L1's execution capacity could potentially increase from the current ~60 million Gas Limit to the 200 million range. Looking further ahead, the openly discussable attitude within the Ethereum ecosystem towards the Gas Limit has become noticeably more aggressive. EIP-9698 even suggests a "tenfold increase every two years," aiming for a Gas Limit of 3.6 billion by 2029 – 50 times the current level.

However, it's crucial to emphasize that increasing the Gas Limit is not simply about making blocks bigger.

Crudely increasing the computational capacity per block might lower fees in the short term, but in the long run, it would increase node burdens, cause state data to bloat, make it harder for ordinary users to run nodes, and ultimately undermine Ethereum's core foundation of decentralization.

Therefore, the scaling approach for Glamsterdam is a combination of measures:

• ePBS (enshrined Proposer-Builder Separation) more clearly incorporates the block building and validation processes into protocol rules, allowing validators to handle larger blocks more safely;
• Block-Level Access Lists (BAL) pre-record the accounts and storage locations accessed during block execution, enabling parallel disk reads, parallel transaction validation, and parallel state root calculation;
• EIP-8037 aims to prevent excessively rapid state growth following the Gas Limit increase by raising the cost of state-creating operations;

Ultimately, Ethereum isn't just aiming to "fit more transactions," but is also thinking about how to accommodate more transactions without raising the barrier to entry for running a node.

This is the fundamental difference between Ethereum's scaling roadmap and the narratives of many high-performance chains. The goal is not to sacrifice verification cost for superficial throughput, but to enhance the mainnet's own carrying capacity while maintaining node accessibility and system verifiability.

2. Keyed Nonces: Transforming "a Single Line" into "Multiple Channels"

If the Gas Limit concerns "how much a block can hold," Keyed Nonces address a more nuanced but critical issue: how should a transaction queue up?

As we know, in Ethereum, a nonce can be simply understood as the "sequence number" for an account's transactions. It prevents the same transaction from being executed twice and ensures transactions from the same account are processed in order.

In a simple transfer scenario, this mechanism is easy to understand: transactions are processed sequentially – first, second, third, and so on.

However, the problem arises when account capabilities become more complex, involving privacy transactions, smart wallets, session keys, batch operations, or third-party gas payments. A single linear nonce can become a bottleneck. Therefore, EIP-8250 proposes Keyed Nonces. The core idea is to allow an account to have multiple nonce domains instead of just a single nonce queue.

Specifically, it replaces the single sender nonce used in EIP-8141 Frame Transactions with an (nonce_key, nonce_seq) structure. Here, 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, with no replay protection interference.

This sounds technical, but a simple analogy helps: Previously, an account was like a bank with only one teller window – all business had to line up in a single queue. Keyed Nonces are like directing different types of business to different windows: transfers, privacy withdrawals, session authorizations, and batch executions can each use their own channel.

This is particularly important for privacy protocols. To avoid tying users' on-chain activities directly to a single public address, a privacy protocol might have multiple users submit transactions from a shared sender address. Under the single nonce mechanism, once one user's transaction is included, transactions from other users that are still pending could become invalid or blocked.

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

Vitalik himself has an even grander vision for it. Introducing EIP-8250, he clearly stated that Keyed Nonces "are not just stronger support for privacy schemes at the protocol layer, but could also be the first step in Ethereum's new state scaling strategy – achieving extreme scalability while maintaining protocol decentralization by creating specialized, optimized storage types for different use cases."

In other words, if the Gas Limit addresses the "size of the block," Keyed Nonces explores the "shape of the state" – what Ethereum needs to support 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 seem distant from ordinary users, but they ultimately impact the wallet experience.

This is because the entry point for users interacting with Ethereum is not EIPs, clients, or developer meetings, but every transfer, approval, signature, cross-chain action, and DApp interaction within their wallets. Protocol-level changes only truly translate from technical upgrades to user experience improvements when they are translated by wallets into clearer, smoother, and more secure operational experiences.

For example, the now-familiar concept of account abstraction isn't meant to make users understand more technical jargon; it's to enable 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 basic capabilities within wallets.

Similarly, consider Keyed Nonces again. It sounds like a very low-level optimization of the account queuing mechanism, but its potential impact on the user side is not abstract. Many users performing on-chain operations today have likely encountered a scenario: a transaction remains unconfirmed for a long time, blocking subsequent transactions; they try to cancel or accelerate a transaction but don't understand the relationship between nonce, Gas, and replacement transactions. In parallel multi-step operations, one failed step can disrupt the entire subsequent process.

For ordinary users, these problems seem like "the wallet isn't good" or "the chain isn't good," but they are fundamentally related to the design of the single linear nonce in Ethereum's account model. The direction represented by Keyed Nonces allows an account to no longer execute all operations sequentially in a single queue, but to split them into multiple parallel channels based on different usage scenarios.

In the future, operations like regular transfers, DApp approvals, privacy transactions, batch transactions, and gas sponsorship could theoretically have more independent execution spaces, reducing the chance of blocking and conflicting 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 share the complexity. Users had to understand the scope of authorization, judge whether Gas was reasonable, know exactly what they were signing, and repeatedly confirm multi-step operations like cross-chain swaps, staking, and reward claims. A misunderstanding at any step could lead to operational failure and asset loss.

What Ethereum is now attempting to do is to shift some of this complexity forward 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, while seemingly belonging to different technical modules, all serve the same purpose: enabling Ethereum to support more complex on-chain usage scenarios without sacrificing decentralization and security.

Specifically, looking at these developments together reveals that Ethereum's recent focus is not scattered:

• Increasing the Gas Limit addresses mainnet execution capacity and fee pressure;
• BAL, ePBS, EIP-8037 address how to maintain node verifiability and control state growth during the scaling process;
• Keyed Nonces and Frame Transactions address the bottlenecks of the account model, privacy protocols, and smart wallets at the protocol layer;
• Native account abstraction and cross-L2 interoperability further point towards tangible improvements in the user experience.

This also means Ethereum is entering a new phase.

In the past few years, the market focused more on L2 scaling, Blob fee reduction, and the modular narrative. Users gradually became accustomed to moving assets between different L2s in search of lower-cost interaction environments. However, as the mainnet Gas Limit continues to rise, upgrades like Glamsterdam advance, and account abstraction and interoperability solutions evolve, the question Ethereum is answering has shifted from "how to make transactions cheaper" to "how to make the on-chain experience feel like a cohesive 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 utilized 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 proactive risk identification, and smoother on-chain interaction experiences.

Let's hope for that.