How to understand Ethereum's next stop for scalability?

Article 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 on-chain operations.

For example, in the past two years, everyone has felt that Gas fees for transfers have become lower, and cross-chain interoperability has improved, among other things. This is also why scaling Ethereum has never been just a matter of 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, up 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 ongoing emphasis in the 2026 roadmap on native account abstraction, cross-L2 interoperability, and enhanced L1 security—these are all subtle signals.

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 a transfer or a contract interaction) consumes a certain amount of Gas, and the Gas Limit per block is fixed—meaning limited slots: more slots, more passengers per time; fewer slots, everyone has to bid for the same seat, driving up Gas fees.

Theoretically, increasing the block Gas cap can directly and significantly improve Ethereum’s performance. However, in the context of Ethereum’s broader development, especially with the rise of Layer 2 solutions, this has been approached cautiously. Most scaling pressure has been intentionally directed toward L2.

Looking at Ethereum’s Gas Limit growth curve, we see that in September 2019, the Gas Limit first surpassed 10 million from 8 million. Over the next seven years, it grew from 8 million to 60 million, with a real acceleration starting 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 this scaling happened in 2025. As previously mentioned, 2025 is a crucial year in Ethereum’s development history. Just seven months after the Pectra upgrade in May, the Fusaka upgrade demonstrated that even after major leadership changes, EF still has the capacity to push significant updates. It also marked Ethereum’s transition into a faster development rhythm of “two hard forks per year.”

According to the Ethereum Foundation’s Soldøgn Interop Recap released on May 2, over 100 core contributors 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 after Glamsterdam.

This means that if subsequent processes go smoothly, Ethereum’s L1 execution capacity could further increase from the current around 60 million to the 200 million level. Looking at the longer-term, Ethereum’s open attitude toward Gas Limit increases has become much more “radical”: EIP-9698 even proposes “a tenfold increase every two years,” raising the Gas Limit to 3.6 billion by 2029—50 times the current limit.

But it’s important to emphasize that raising Gas Limit is not simply about making blocks bigger.

If it’s just a brute-force increase in the amount of computation per block, short-term, it might lower fees, but long-term, it could burden nodes more, cause state data bloat, 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, allowing 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 calculations;

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

Ultimately, Ethereum isn’t just about “fitting more transactions,” but about how to increase capacity without raising the barrier for node operation.

This is the fundamental difference between Ethereum’s scaling approach and many high-performance chains: it 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 queued sequentially: first, first; second, second; third, third.

But problems arise when accounts become more complex—privacy transactions, smart wallets, session keys, batch operations, third-party payers—then a single linear nonce can become a bottleneck. EIP-8250’s 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 sounds very technical, but can be understood with a simple analogy: In the past, an account was like having only one window at a bank—all transactions queued in the same line; Keyed Nonces are like splitting different types of transactions into different windows—transfers, privacy withdrawals, session authorizations, batch executions—each with its own channel.

This is especially important for privacy protocols, which aim to prevent linking user activity directly to a single public address. Privacy protocols might have multiple users sharing a sender address, but under a single nonce scheme, a transaction from one user could invalidate or block others’ pending transactions.

Keyed Nonces allow each transaction to choose its own nonce domain—for example, derived from a privacy nullifier—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 at the protocol layer but could 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,” but “state shape”—Ethereum’s future will carry not only more transactions but 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 EIPs, client software, or developer meetings, but 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 as clearer, smoother, and safer operations in wallets.

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. 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 fundamental wallet capabilities.

Similarly, Keyed Nonces might 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 transactions, or difficulty canceling or speeding up transactions. They often don’t understand nonce, Gas, or replacement transactions, especially when multiple operations run in parallel—one failed step can block subsequent ones.

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. The direction represented by Keyed Nonces is to allow accounts to operate on multiple parallel channels instead of a single queue.

In the future, simple transfers, DApp authorizations, privacy transactions, batch operations, and Gas payments could 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 could lead to failed operations or asset loss.

What Ethereum is trying to do now is to shift some of this complexity to the protocol layer, enabling wallets to provide better interaction abstractions 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 separate modules, all serve the same goal: to enable 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 to address mainnet capacity and fee pressures;

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

• Keyed Nonces and Frame Transactions to solve account model, privacy, and wallet bottlenecks at the protocol level;

• Native account abstraction and cross-L2 interoperability to improve user experience in a tangible way.

This signals that Ethereum is entering a new phase.

In recent years, the market has focused more on L2 scaling, fee reduction, and modular narratives. Users have grown accustomed to transferring assets across different L2s and seeking lower-cost interactions. But as mainnet Gas Limit continues to rise, and upgrades like Glamsterdam, account abstraction, and interoperability evolve, the question Ethereum is answering is no longer just “how to make transactions cheaper,” but “how to make the entire on-chain experience more integrated.”

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

Because wallets are not just entry points into Ethereum—they are the interface through which protocol capabilities are 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.