จาก Gas Limit ถึง "Keyed Nonces" ทำความเข้าใจจุดหมายต่อไปของความสามารถในการขยายตัวของ Ethereum ได้อย่างไร

Objectively speaking, over the past period, many users' intuitive perception of Ethereum often hasn't come from roadmap discussions or developer meetings, but rather from specific on-chain operations.

For example, in the past two years, users have widely felt that Gas fees for transfers are getting lower, and cross-chain interoperability experiences have improved. This is why Ethereum's scaling has never been a simple "performance competition" issue—for ordinary users, higher TPS, larger blocks, and more complex underlying architectures only make sense when they translate into lower costs, smoother operations, and a more secure wallet experience.

Recently, a series of new developments in Ethereum precisely point to the network's attempt to systematically shift the complexity—previously borne by wallets, DApps, third-party relayers, and users themselves—into the protocol layer.

These include Vitalik's involvement in Keyed Nonces, the directional consensus around the 200 million Gas Limit floor formed during the Glamsterdam upgrade, and a series of subtle but significant 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 we know, in the Ethereum network, each transaction (whether a transfer or contract interaction) consumes a certain amount of Gas. The Gas Limit of each Ethereum block is fixed, meaning there's limited capacity: More spots mean more "passengers" can be transported in the same timeframe; tighter spots mean everyone has to bid for the same seat, driving up Gas fees.

Theoretically, increasing the block Gas limit would directly and significantly boost Ethereum mainnet performance. However, in the past, with the rise of L2 scaling solutions, Ethereum has been relatively cautious about this, deliberately pushing most scaling pressure onto the L2 track.

Looking at Ethereum's Gas Limit scaling curve, after breaking through 10 million for the first time in September 2019 (from 8 million), it took seven years to go from 8 million to 60 million. The acceleration really only began in 2025—from 30 million to 36 million in February, up to 45 million in July, and then to 60 million after the Fusaka upgrade in December.

Most of the scaling happened in 2025 alone. Of course, as we've noted before, 2025 was also a pivotal year in Ethereum’s history. The Fusaka upgrade, coming just seven months after the May Pectra upgrade, proved that the EF, despite major leadership changes, could still drive significant updates. It also marked Ethereum's official entry into an accelerated development rhythm of "two hard forks per year" (for further reading, see Ethereum 2026: Interpreting the Latest EF Protocol Roadmap, Officially Entering the Era of "Engineering Upgrades"?).

Source: Etherscan

According to the Ethereum Foundation's Soldøgn Interop Recap released on May 2, over 100 core Ethereum contributors participated in an interoperability meeting in Svalbard, Norway, focused on the Glamsterdam upgrade. The main goals were advancing multi-client implementation, testing, and parameter alignment for Glamsterdam. By the meeting's end, developers had reached a directional consensus on a 200 million Gas Limit floor post-Glamsterdam.

This means, if subsequent processes go smoothly, Ethereum L1's execution capacity could potentially increase from the current ~60 million Gas Limit to around 200 million. Looking at an even longer timeline, the Ethereum ecosystem's attitude towards publicly discussing Gas Limit increases has become noticeably more "aggressive." EIP-9698 even suggests "doubling every two years," aiming to increase the Gas Limit to 3.6 billion by 2029, 50 times the current level.

However, it's crucial to emphasize that increasing the Gas Limit isn't simply about making blocks larger.

If done crudely, just increasing the computational capacity per block, it might lower fees in the short term. But in the long term, it would increase node burden, cause state data bloat, and make it harder for ordinary users to run nodes, ultimately undermining Ethereum's most core value: decentralization.

So, Glamsterdam's scaling approach is a combination of strategies:

• ePBS (enshrined Proposer-Builder Separation) integrates block building and validation processes more clearly 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 validation, and parallel state root computation.
• EIP-8037 increases the cost of state-creating operations to prevent excessively rapid state growth when the Gas Limit is raised.

Fundamentally, Ethereum isn't just trying to "fit more transactions"; it's thinking about how to accommodate more transactions without raising the barrier to running a node.

This is the fundamental difference between Ethereum's scaling roadmap and many high-performance blockchain narratives. It's never been about sacrificing validation cost for superficial throughput; it's about enhancing the mainnet's capacity while maintaining node accessibility and system verifiability.

2. Keyed Nonces: Transforming "One Line" into "Multiple Lanes"

If the Gas Limit addresses "how much a block can hold," Keyed Nonces focuses on a more subtle but critical question: how should a transaction queue up?

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

This mechanism is easy to understand in a simple transfer scenario: first transaction, second transaction, third transaction, and so on, lined up sequentially.

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

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 independently manage protocol-owned nonce sequences. Transactions under different keys are independent and don't affect each other's replay protection.

This sounds technical, but a simple analogy helps: Previously, an account was like a bank with only one window, and all business had to wait in the same line. Keyed Nonces are like assigning different businesses 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 activities to a public address, privacy protocols might allow multiple users to submit transactions through a single shared sender address. Under the single nonce mechanism, once one user's transaction is packaged, it can invalidate or block other users' pending transactions.

Keyed Nonces allow each outgoing transaction to choose its own nonce domain, for instance, derived from a privacy nullifier, reducing such queuing conflicts at the protocol layer.

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

In other words, think of it this way: Gas Limit solves "block size," while Keyed Nonces explores the "shape of the state"—Ethereum's future isn't just about handling more transactions, but about handling more *types* of transactions.

3. How Will This Affect Ordinary Users?

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

The user's actual entry point into Ethereum isn't EIPs, clients, or developer meetings; it's every transfer, authorization, signature, cross-chain move, and DApp interaction within their wallet. Protocol-level changes only truly transform from a technical upgrade into a user experience upgrade when they are translated into clearer, smoother, and more secure operational experiences within the wallet.

For example, account abstraction, now a familiar concept, isn't meant to make users understand more technical jargon. It's meant to make using on-chain accounts more natural in the future. This is why batch transactions, gas sponsorship, recovery mechanisms, different signature methods, session authorizations, and more flexible security policies are gradually becoming foundational features in wallets.

Take Keyed Nonces again. It sounds like a very low-level account queuing optimization, but from a user's perspective, its potential impact is not abstract. Many users today might have encountered similar scenarios: a pending transaction not confirming, subsequent transactions getting stuck, wanting to cancel or speed up a transaction but not understanding the relationship between nonce, gas, and replacement transactions. This is especially problematic when operating multiple transactions in parallel, where a single failure can disrupt the entire subsequent process.

For ordinary users, these problems appear as "the wallet is hard to use" or "the chain is slow," but the root cause is related to the single linear nonce design in Ethereum's account model. The direction represented by Keyed Nonces allows accounts to execute operations not just in a single sequential line but to split them into parallel channels based on different usage scenarios.

In the future, common operations like transfers, DApp authorizations, privacy transactions, batch operations, and gas sponsorship could, in theory, have more independent execution spaces, reducing the probability of blocking and conflicts.

This will undoubtedly further expand the design space for smart wallets.

More importantly, in the past, these capabilities required shared complexity between wallets, DApps, relay services, and users. Users had to understand authorization scopes, judge whether gas was reasonable, know what they were actually signing, and repeatedly confirm multi-step operations like cross-chain transfers, swaps, staking, and reward claims. Any misunderstanding could lead to operation failure or asset loss.

What Ethereum is currently attempting is to shift part of this complexity to the protocol layer, allowing wallets to provide better interaction abstractions based on more standardized and native underlying capabilities.

This is why concepts like 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 goal: enabling Ethereum to support more complex on-chain use cases without sacrificing decentralization or security.

Specifically, when you look at these developments together, the recent focus of Ethereum isn't scattered:

• Gas Limit increase addresses mainnet execution capacity and fee pressure.
• BAL, ePBS, EIP-8037 tackle how to maintain node verifiability and controlled state growth during scaling.
• Keyed Nonces and Frame Transactions solve bottlenecks at the protocol layer for account models, privacy protocols, and smart wallets.
• Native account abstraction and cross-L2 interoperability point directly to experience improvements that ordinary users can feel.

This also signals that Ethereum is entering a new phase.

In recent years, the market has focused more on L2 scaling, Blob fee reduction, and modular narratives. Users have gradually become accustomed to moving assets between different L2s in search of cheaper interaction environments. But as the mainnet Gas Limit continues to increase, upgrades like Glamsterdam progress, 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 the on-chain experience feel like a cohesive whole."

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

Because the wallet is not only the user's entry point to Ethereum but also the interface through which protocol capabilities are truly understood and used. In the future, the more complex the underlying upgrade, the more it needs 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.