For many users, their most direct impression of Ethereum in recent years has not come from roadmaps or developer conferences, but from the on-chain actions they perform again and again.
For example, many users have felt transfer gas fees becoming lower over the past two years, and cross-chain interoperability becoming smoother. This is why Ethereum scaling has never been just a “performance race.” For everyday users, higher TPS, larger blocks, and more complex architecture only matter when they translate into lower costs, smoother interactions, and a safer wallet experience.
Recently, a series of Ethereum developments have pointed in the same direction: Ethereum is trying to systematically shift some of the complexity previously handled by wallets, DApps, third-party relayers, and users themselves down to the protocol layer.
These include Keyed Nonces, a proposal Vitalik has been involved in; the directional consensus around a 200 million gas limit floor in the Glamsterdam upgrade; and a set of connected signals in the 2026 roadmap, including native account abstraction, cross-L2 interoperability, and stronger L1 security.
1. Raising the Gas Limit to 200 Million?
Let’s start with the part users can notice most directly: the gas limit.
Every Ethereum transaction — whether a transfer or a contract interaction — consumes gas. Each Ethereum block has a fixed gas limit, meaning block space is limited: the more space there is, the more “passengers” can be carried at once; when space is tight, users bid for the same seats, and gas fees naturally rise.
In theory, increasing the block gas limit can significantly improve Ethereum mainnet performance. But against the backdrop of rapid L2 development, Ethereum has remained cautious, intentionally channeling much of the scaling pressure toward L2s.
Looking at Ethereum’s gas limit history, after the network first rose from 8 million to over 10 million in September 2019, it took roughly seven years to reach 60 million. The real acceleration came in 2025: from 30 million to 36 million in February, then to 45 million in July, and finally to 60 million after the Fusaka upgrade in December.
In other words, most of this expansion was concentrated in 2025. As we noted before, 2025 was also a critical year in Ethereum’s history. The Fusaka upgrade, coming just seven months after Pectra in May, showed that even after major leadership changes at the Ethereum Foundation, Ethereum could still deliver major upgrades. It also marked Ethereum’s move into an accelerated cadence of “two hard forks per year.”
Related reading: “Ethereum 2026: Interpreting EF’s Latest Protocol Roadmap—Is Ethereum Entering an Engineering-Driven Upgrade Era”
Source: Etherscan
According to the Ethereum Foundation’s Soldøgn Interop Recap published on May 2, more than 100 Ethereum core contributors gathered in Svalbard, Norway, for an interoperability meeting focused on Glamsterdam. The meeting aimed to advance multi-client implementation, testing, and parameter alignment. By the end, developers had reached broad consensus around a 200 million gas limit after Glamsterdam.
If the process goes smoothly, Ethereum L1 execution capacity could rise from today’s roughly 60 million gas limit to around 200 million. Over a longer horizon, the Ethereum ecosystem has clearly become more open — even more aggressive — in publicly discussing gas limit increases. EIP-9698 even proposes a 10x increase every two years, raising the gas limit to 3.6 billion by 2029, about 50 times today’s level.
But it is important to emphasize that increasing the gas limit is not simply about making blocks bigger.
If each block’s computational capacity is increased in a brute-force way, fees may fall in the short term. But over the long term, it could increase node burdens, accelerate state growth, make it harder for ordinary users to run nodes, and ultimately weaken Ethereum’s core foundation of decentralization.
That is why Glamsterdam’s scaling approach is a coordinated package:
- ePBS, or enshrined Proposer-Builder Separation, brings block building and validation more clearly into protocol rules, allowing validators to handle larger blocks more safely.
- Block-Level Access Lists, or BAL, record in advance which accounts and storage locations will be accessed during block execution, enabling parallel disk reads, parallel transaction verification, and parallel state root computation.
- EIP-8037 increases the cost of state-creating operations, helping prevent state growth from accelerating too quickly after the gas limit is raised.
In the end, Ethereum is not only trying to include more transactions. It is also asking how to do so without making node operation increasingly difficult.
This is the fundamental difference between Ethereum’s scaling roadmap and many high-performance-chain narratives. Ethereum is not trying to trade higher verification costs for superficial throughput. Instead, it aims to increase mainnet capacity while preserving ordinary node participation and system verifiability as much as possible.
2. Keyed Nonces: Turning “One Queue” into “Multiple Channels”
If the gas limit answers “how much can fit into one block,” then Keyed Nonces focus on a more detailed but equally important question: how should a transaction wait in line?
In Ethereum, a nonce can be understood as the “sequence number” of an account’s transactions. It prevents the same transaction from being executed twice and ensures that transactions from the same account are processed in order.
This mechanism is easy to understand in simple transfer scenarios: the first transaction, the second transaction, the third transaction, and so on, all lined up in order.
But as account capabilities become more complex — involving privacy transactions, smart wallets, session keys, batched operations, and third-party gas sponsorship — a single linear nonce can become a bottleneck. EIP-8250’s Keyed Nonces address this by allowing an account to have multiple nonce domains instead of only one nonce queue.
More 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 use independently managed nonce sequences at the protocol level. Transactions under different keys are independent, and their replay protection does not interfere with one another.
This may sound technical, but a simple analogy helps: in the past, an account was like having only one service counter at a bank, where every type of task had to wait in the same line. Keyed Nonces are like opening separate counters for different tasks, so transfers, private withdrawals, session authorizations, and batch executions can each use their own channel.
This is especially important for privacy protocols. To avoid directly linking users’ on-chain activity to a single public address, a privacy protocol may allow multiple users to send transactions through the same shared sender address. With a single nonce, once one user’s transaction is included, other users’ pending transactions may become invalid or blocked.
Keyed Nonces allow each transaction or spend to choose its own nonce domain — for example, one derived from a privacy nullifier — reducing this kind of queueing conflict at the protocol layer.
Vitalik frames it even more broadly. When introducing EIP-8250, he said Keyed Nonces are “not only stronger support for protocol-layer privacy schemes, but may also be the first step toward a new state-scaling strategy for Ethereum: creating storage types optimized for different use cases, enabling very high scalability while preserving protocol decentralization.”
Put simply, the gas limit addresses the “size of the block,” while Keyed Nonces explore the “shape of state.” What Ethereum needs to support in the future is not just more transactions, but more types of transactions.
3. How Will This Affect Everyday Users?
For the Ethereum ecosystem, many protocol upgrades may seem far removed from everyday users. But in the end, they all land in the wallet experience.
Users do not experience Ethereum through EIPs, clients, or developer meetings. They experience it through every transfer, approval, signature, cross-chain action, and DApp interaction inside their wallet.
In other words, protocol-layer changes only become true user experience upgrades when wallets translate them into clearer, smoother, and safer interactions.
Account abstraction, now widely discussed, is a good example. Its purpose is not to make users learn more technical terms, but to help them use on-chain accounts more naturally. That is why batch transactions, gas sponsorship, recovery mechanisms, different signing methods, session authorization, and more flexible security policies are gradually becoming basic wallet capabilities.
Keyed Nonces are similar. They sound like a low-level optimization to an account’s transaction queueing mechanism, but from the user’s perspective, their potential impact is not abstract at all.
Many users have likely encountered this: one transaction remains unconfirmed for a long time, later transactions get stuck, and the user wants to cancel or speed it up but does not understand the relationship between nonce, gas, and replacement transactions. When multiple actions are happening in parallel, one failed step can affect everything that follows.
To everyday users, these issues may look like “the wallet is hard to use” or “the chain is hard to use.” But behind them is Ethereum’s account model, where a single linear nonce determines execution order.
Keyed Nonces point toward a model where accounts no longer have to execute every action through a single queue. Instead, they can split different use cases into multiple parallel channels.
In theory, regular transfers, DApp approvals, privacy transactions, batch transactions, gas sponsorship, and other actions could each have more independent execution space, reducing the chance that they block or conflict with one another.
This will undoubtedly open up more design space for smart wallets.
More importantly, these capabilities used to require wallets, DApps, relayer services, and users to share the complexity. Users had to understand authorization scope, judge whether gas was reasonable, know exactly what they were signing, and repeatedly confirm multi-step actions such as bridging, swapping, staking, and claiming rewards. Any misunderstanding along the way could lead to failed operations or asset-loss risk.
What Ethereum is trying to do now is shift part of this complexity into the protocol layer, so wallets can build better interaction abstractions on top of more standardized, native capabilities.
That is why gas limit, BAL, ePBS, Keyed Nonces, Frame Transactions, native account abstraction, and cross-L2 interoperability may seem like separate technical modules, but they are all serving the same goal: enabling Ethereum to support more complex on-chain use cases without sacrificing decentralization or security.
Looking at these developments together, Ethereum’s recent priorities are more coherent than they may first appear:
- Gas limit increases address mainnet execution capacity and fee pressure.
- BAL, ePBS, and EIP-8037 address how to preserve node verifiability and keep state growth under control during scaling.
- Keyed Nonces and Frame Transactions address protocol-layer bottlenecks in the account model, privacy protocols, and smart wallets.
- Native account abstraction and cross-L2 interoperability point toward experience improvements that everyday users can actually feel.
This also means Ethereum is entering a new stage.
Over the past few years, the market has focused more on L2 scaling, blob-driven fee reductions, and the modular blockchain narrative. Users have also grown used to moving assets across L2s and looking for lower-cost environments to interact on-chain.
But as the mainnet gas limit continues to rise, upgrades such as Glamsterdam move forward, and account abstraction and interoperability solutions continue to evolve, Ethereum is no longer only asking “how to make transactions cheaper.”
It is also asking: “How can the on-chain experience feel more like one coherent whole?”
Along the way, wallets will become even more important.
Wallets are not only the entry point into Ethereum; they are also the interface through which users understand and use protocol capabilities. The more complex the underlying upgrades become, the more wallets need to translate them into clearer signing prompts, more understandable transaction paths, earlier risk detection, and smoother on-chain interactions.
Let’s keep building toward that future.