What will Ethereum address in the next phase after scaling?

Written by: imToken

If we were to string together Ethereum's upgrades over the past few years into a single thread, the key theme would undoubtedly be "scaling."

From Dencun's introduction of Blobs to significantly reduce the burden on Rollups, to Pectra's adjustments to validator efficiency and staking mechanisms, and then to Fusaka's implementation of PeerDAS to reduce the data distribution burden, the protocol layer has focused almost all its efforts on one thing: enabling Ethereum to absorb more data while avoiding raising the barrier to entry for nodes too high.

This combination of measures has indeed worked. The data costs for Rollups have decreased, and the mainnet Gas Limit is steadily increasing. Ethereum is no longer as prohibitively expensive as it was during the last bull market, with transaction fees often reaching tens of dollars.

But even with wider roads, driving is still awkward: We still have to move assets between three or four L2 chains, and it's easy to accidentally access the wrong chain; A transaction might be packaged in seconds, but bridges and exchanges make you wait for over ten minutes before confirming; Professional Builders almost monopolize block packaging, and if you want to send a sensitive transaction, it might be rejected at any time due to unspoken rules outside the protocol; Not to mention that even today, a new user who just wants to transfer a few hundred USDC still has to figure out why their wallet must have ETH, what a Nonce is, and what Gas is; These issues, on the surface, manifest as friction in user experience, but behind them lie deeper protocol mechanisms such as confirmation rules, block construction, censorship resistance, and account models. This is precisely the new problem Ethereum has begun to address centrally from Glamsterdam to Hegotá, from Q4 2026 to 2027. I. Scaling Continues, But "Stitching Together" L1 and L2 Of course, scaling won't stop. Glamsterdam still has a strong performance orientation, with two of the most noteworthy features being ePBS (EIP-7732) and BAL (Block-level Access Lists, EIP-7928). Simply put: ePBS formally enshrines the division of labor between Proposers and Builders, which already exists extensively outside the protocol, into the protocol itself, and also scientifically segments the time windows for block production and verification, providing sufficient buffer for running larger blocks in the future; BAL essentially provides an "access list" at the beginning of each block, allowing nodes to pre-fetch data and even process it in parallel at a glance, effectively addressing storage I/O bottlenecks; However, beyond scaling, the real pain point for most people today is not Ethereum's TPS (transactions per second). It's not about whether it's high enough, but rather that "there are too many chains." For example, ETH is on the mainnet, memes are on the Robinhood Chain, USDC used for payment settlement might be on Arbitrum, and USDC for bottom-fishing might be on Base... For the Ethereum Foundation, rollups are all part of the Ethereum ecosystem, but for users, it's no different from exchanging currency or getting a visa. Therefore, to stitch these scattered pieces back into a cohesive network, besides cross-chain protocols showcasing their capabilities, a recently promoted underlying mechanism at the protocol layer is worth noting—FCR (Fast Confirmation Rule). Many people believe that a transaction is complete once it's included in a block, but at the cryptographic and consensus level, a newly created block can undergo minor reorganizations. For Ethereum to achieve truly irreversible "finality," it requires two epochs, approximately 13 minutes. This is fine for normal transactions, but it's torture for cross-chain bridges, large-scale clearing, and centralized exchanges. To avoid the risk of reorganizations, they have no choice but to make you wait. The ingenuity of FCR lies in not having to wait for the full Finality process of over ten minutes, but instead utilizing the Attestations that validators continuously generate, and based on the accumulated voting weight, determining earlier whether a block has gained sufficiently strong consensus support. According to the Ethereum Foundation's goals, assuming the network remains synchronized, FCR is expected to advance this "strong confirmation" to approximately 15-30 seconds. While not equivalent to full finality, this is sufficient to provide an earlier confirmation signal with a clear security model for many bridges, cross-chain communications, and infrastructures that currently have to wait for finality. More importantly, FCR does not require a hard fork to be enabled; it is closer to a set of confirmation rules that can be gradually adopted by consensus clients and infrastructure. Once various L2, cross-chain bridges, and wallets begin using this signal, the significant cross-layer delays caused by "waiting for L1 finality" today could be reduced from tens of minutes to tens of seconds. This also means that in the future, when you transfer an asset, the backend may quietly cross two or more chains, but on the frontend, you only need to click to confirm, and the funds will arrive quickly. II. A more fundamental question: Who has the power to decide whether a transaction can be recorded on the blockchain? However, as blocks become larger and Builders become more professional, Ethereum faces another very typical dilemma. Since professional Builders have maximized block construction efficiency with top-tier computing power and order flow, the power of life and death over the vast majority of blocks naturally falls into the hands of a few large institutions. This brings an extremely dangerous hidden danger: censorship. If some Builders, due to compliance pressures, business competition, or simply dislike certain privacy protocols, deliberately turn a deaf ear in the mempool and refuse to package your legitimate transactions, even if you have your private key and sufficient gas, your transaction may still be blocked off-chain. If decentralization cannot even guarantee the most basic "censorship-resistant transaction access," then high throughput is just a castle in the air. This is why FOCIL (Fork-choice Enforced Inclusion Lists, EIP-7805) is placed in such a crucial position in Hegotá's plan. Its logic is extremely simple and brutal: to put a tight rein on Builders. In each slot, the protocol randomly selects a group of independent validators and asks them to add the legitimate pending transactions they see in the mempool to an "Inclusion List." Builders can still freely arrange the transaction order to earn MEV, but the blocks they submit must include all transactions from the inclusion list. If a Builder maliciously ignores this list, all validators on the network will remove that block from the fork selection rules. In other words, you can earn money through your skills, but you cannot decide for the entire network who is eligible to use Ethereum. This mechanism, once established, also addresses another long-standing but elusive weakness of Ethereum: privacy, which everyone is eagerly anticipating. As we all know, in the past, discussions about privacy often revolved around zero-knowledge proofs, hidden addresses, and mixing pools. However, as soon as the Builder recognizes that "this is a call to a privacy contract," it rejects it, instantly crippling your mathematical magic. Currently, in Ethereum's privacy roadmap, FOCIL addresses precisely the most vulnerable point. After all, as long as the protocol layer can guarantee the access rights of every legitimate transaction, upper-layer privacy exploration has no future. While more radical privacy proposals like EIP-8182 (which attempts to introduce a protocol-level native Shielded Pool) are still in the candidate discussion stage, the trend is already clear: privacy can no longer be treated as a peripheral function of a third-party DApp; it must gradually become a fundamental part of Ethereum's underlying infrastructure.

III. The final step: Native AA and a more user-friendly wallet

The architectural adjustments discussed earlier mostly occurred behind the scenes, while this third thing is closely related to the actual user experience of ordinary users.

That is, Ethereum has finally made up its mind to carry out major surgery on the EOA account model that has lasted for more than ten years.

Frankly, Ethereum's current private key signature model is utterly inhumane for the average internet user: Losing a private key means certain death; having thousands of stablecoins in your wallet can prevent asset transfers due to a mere 0.001 ETH transaction fee; engaging in DeFi requires approval followed by swapping, necessitating three signatures to complete a single transaction; transaction nonces are strictly queued, and a single blocked transaction can cripple the entire system. In the first two upgrades, the community made various compromises. For example, they developed ERC-4337, using contract wallets outside the protocol as a workaround; and they introduced EIP-7702 in Pectra, allowing ordinary addresses to temporarily attach a piece of contract logic for some flexibility. But 7702 is ultimately just a temporary bridge. The real focus of Hegotá's work is the true native account abstraction EIP-8141 (Frame Transactions). In simple terms, an Ethereum transaction used to tightly bind three things together: who proves it's you (verification), who pays the gas fee (gas payment), and what the transaction is supposed to do (execution). EIP-8141, however, breaks these three things down into different "frames" at the protocol level: Verification Frame: No longer locked to a fixed ECDSA elliptic curve signature, it supports more flexible verification methods such as Passkey, and further integrates with capabilities like mobile fingerprint and Face ID, making key rotation and account recovery more natural; Payment Frame: Gas sponsorship is natively implemented. Applications can directly pay gas on behalf of new users, or you can specify in the payment frame to directly deduct USDC from the transfer, eliminating the need for relays to buy and sell off-chain; Execution frame: Naturally supports atomic batch processing, authorization and exchange are done in one step, taking effect simultaneously on success and rolling back cleanly on failure; If EIP-8250 (Keyed Nonces), which is currently under discussion, is added, future accounts may even have multiple parallel Nonce tracks. Once these capabilities are natively integrated into the protocol, wallets like imToken will experience a qualitative leap in their product design. It's worth noting that in the past, wallets spent most of their time reminding users to prepare gas, explaining why a transaction was stuck, educating users on how to copy mnemonic phrases, and helping users switch RPCs between different chains. In the future, when signature algorithms, gas payment, access control, and transaction routing can all be programmed, wallets can finally return to their rightful place, becoming a silent operating system between users and the decentralized world. It will remain entirely in the hands of the user, just as before, but using it will be as natural as scanning a QR code to pay with Alipay or unlocking with a fingerprint. In conclusion, looking back at Ethereum's upgrade trajectory over the past few years, the path is actually extremely clear. Dencun solved the Blob problem; Pectra continued to expand while improving validator and account capabilities; Fusaka paved the way for greater data throughput with PeerDAS; and the upcoming Glamsterdam will further lay the foundation for higher gas limits and parallel execution through structural changes such as ePBS and BAL. Scaling is not over yet, but it's no longer the only issue. Ethereum has finally freed up resources to address the most fundamental and troublesome problems. This is why, when EF reorganized its protocol development direction in 2026, it summarized it into three very simple goals: Scale, Improve UX, and Harden the L1. Ethereum has already proven to the world that it can be a world computer that never stops. The next step is to make it truly seamless for ordinary people to use.