Ethereum’s Next Phase: Bridging L1 and L2, Enhancing Privacy, and Improving UX

If you trace Ethereum's upgrades over the past few years, the defining theme is undoubtedly "scaling."

From the introduction of blobs with Dencun, which significantly reduced costs for Rollups, to Pectra adjusting validator efficiency and staking mechanisms, and further to Fusaka implementing PeerDAS to reduce data distribution burdens, the protocol layer has devoted nearly all its efforts to one goal: enabling Ethereum to process more data without raising the barrier for nodes.

This combination of strategies has truly worked: Rollup data costs have dropped significantly, and the mainnet Gas Limit has been steadily increasing, making Ethereum’s transaction fees no longer as prohibitive as the tens of dollars seen during the last bull market.

But even though the road has been widened, driving still feels awkward:

• We still have to move assets between two or three L2s, and it’s easy to withdraw to the wrong chain.
• A transfer is clearly bundled in seconds, but the bridge and exchange still make you wait over ten minutes to confirm.
• Professional builders almost monopolize block packaging; if you want to send a sensitive transaction, you may随时 be blocked by external protocol norms;
• Not to mention that even today, a new user who simply wants to transfer a few hundred USDC must first figure out why there needs to be ETH in their wallet, what Nonce is, and what Gas is;

These issues appear on the surface as user experience friction, but they involve deeper protocol mechanisms such as confirmation rules, block construction, censorship resistance, and account models.

And this is precisely the new issue Ethereum begins to centralize processing on, from Glamsterdam to Hegotá, from Q4 2026 to 2027.

Of course, scaling won't hit the brakes.

Glamsterdam still has a strong performance orientation, with the two most notable features being ePBS (EIP-7732) and BAL (Block-level Access Lists, EIP-7928); in simple terms:

• ePBS formally integrates into the protocol the existing separation between Proposers and Builders that already occurs extensively outside the protocol, while also more scientifically dividing the block production and validation time windows to provide ample buffer for larger blocks in the future;
• BAL essentially lists an "access checklist" at the beginning of the block, allowing nodes to prefetch data or even process it in parallel at a glance, specifically addressing storage I/O bottlenecks;

Beyond scaling, today most people’s real pain isn’t whether Ethereum’s TPS is high enough—it’s that “there are too many chains.”

For example, ETH is on mainnet, the meme you're trading is on Robinhood Chain, the USDC used for payment settlement might be on Arbitrum, and the USDC you want to buy the dip with is on Base...

For the Ethereum Foundation, rollups are all part of the Ethereum ecosystem, but for users, it’s no different from exchanging currency across borders or applying for a visa.

Therefore, to reassemble the scattered puzzle pieces into a network, in addition to cross-chain protocols each showcasing their own capabilities, a fundamental mechanism recently promoted at the protocol level deserves attention—FCR (Fast Confirmation Rule).

Many people think a transaction is final once it's included in a block, but at the cryptographic and consensus level, a newly produced block may still undergo minor reorganizations. True irreversible finality on Ethereum requires waiting through two Epochs, which takes approximately 13 minutes.

This is fine for regular transfers, but it’s a nightmare for cross-chain bridges, large-scale settlements, and centralized exchanges—they can only make you wait patiently to avoid the risk of reorganization.

The cleverness of FCR lies in not having to wait passively for the full十几分钟 of Finality; instead, it leverages the Attestations that validators naturally produce continuously, and determines earlier whether a block has gained sufficient consensus support based on the accumulated voting weight.

According to the Ethereum Foundation’s targets, under normal network synchronization, FCR is expected to advance this “strong confirmation” to approximately 15–30 seconds. Although not equivalent to full finality, it is already sufficient to provide an earlier confirmation signal with a well-defined security model for many bridges, cross-chain communication systems, and infrastructure that currently must wait for finality.

More specifically, FCR does not require waiting for a specific hard fork to be enabled; it is more like a set of confirmation rules that can be gradually adopted by consensus clients and infrastructure.

Once various L2s, cross-chain bridges, and wallets adopt this signaling system, the cross-layer delays currently caused by "waiting for L1 finality"—often lasting minutes—could be reduced to just seconds.

This also means that in the future, when you transfer an asset, the backend may quietly bridge across two or more chains, but on the frontend, you only need to click confirm, and the funds will arrive shortly.

However, as blocks grow larger and builders become more professional, Ethereum faces another classic dilemma.

Since professional builders have maximized block construction efficiency through top-tier computing power and order flow, the fate of the vast majority of blocks naturally rests in the hands of just a few major institutions.

This creates an extremely dangerous risk: censorship.

If certain builders, due to compliance pressures, commercial competition, or simply disliking certain privacy protocols, deliberately ignore and refuse to include your legitimate transaction in the mempool—even if you hold the private key and have provided sufficient gas—your transaction may be effectively stuck off-chain (see further reading: “Writing Censorship Resistance into the Protocol: Who Decides Whether an Ethereum Transaction Gets on Chain?”).

If decentralization cannot even preserve the most basic principle of censorship-resistant transaction access, no amount of throughput matters—it’s just a castle in the air.

This is why FOCIL (Fork-choice Enforced Inclusion Lists, EIP-7805) holds such a critical position in Hegotá’s planning.

Its logic is extremely straightforward: it puts a tight rein on the Builder.

For each slot, the protocol randomly selects a group of ordinary independent validators to compile an "Inclusion List" containing all legitimate pending transactions they observe in the mempool. You, as the Builder, are still free to arrange transaction ordering to capture your MEV, but the block you submit must include all transactions from the list.

If a Builder dares to maliciously ignore this list, all network validators will immediately discard this block from the fork choice rule. In other words, you can earn money through your skills, but you cannot decide for the entire network who is eligible to use Ethereum.

Once this mechanism is in place, it finally provides a foundation for Ethereum’s long-anticipated but迟迟未推进短板—privacy.

It’s well known that in the past, when people talked about privacy, they constantly mentioned zero-knowledge proofs, stealth addresses, and mixers—but as soon as a Builder recognizes “this is a call to a privacy contract,” they can simply reject it, rendering your mathematical magic useless.

Currently, in Ethereum’s privacy roadmap, FOCIL addresses precisely the most vulnerable point—after all, as long as the protocol layer can guarantee access rights for every legitimate transaction, privacy innovations at the upper layers stand a chance.

More aggressive privacy proposals like EIP-8182 (which attempts to introduce a protocol-level native Shielded Pool) are still in the proposed stage, but the trend is clear: privacy can no longer be treated as an edge feature of a third-party DApp—it must gradually become foundational infrastructure on Ethereum.

The previous discussion about structural adjustments mostly occurred beneath the surface, while the third matter will be closely related to the actual user experience of ordinary users.

That is, Ethereum has finally decided to make a major overhaul of the EOA account model that has been in place for over a decade.

To be honest, the private key signature model that Ethereum has continued to use is extremely unnatural for even slightly average internet users:

Losing your private key means irreversible loss; even with thousands of stablecoins in your wallet, your assets are temporarily frozen because you’re short by just 0.001 ETH for gas fees; using DeFi requires approving before swapping, and you need to sign three times to complete one action; transaction nonces must be strictly ordered—once one gets stuck, everything else halts.

In the first two upgrades, the community made various compromises—such as introducing ERC-4337 to circumvent limitations using contract wallets outside the protocol, and adding EIP-7702 in Pectra to allow regular addresses to temporarily attach contract logic for added flexibility.

But 7702 is ultimately just a footbridge; the real highlight locked in by Hegotá is the native account abstraction EIP-8141 (Frame Transactions).

Simply put, previously, an Ethereum transaction tightly bundled three tasks together—such as who verifies your identity, who pays for the gas, and what action is being executed—while EIP-8141 breaks these three tasks apart at the protocol level into distinct “frames” (see further reading: Native Account Abstraction + Quantum Resistance: Why Isn’t EIP-8141 Ethereum’s Hegotá Headliner?):

• Verification frame: No longer locked into fixed ECDSA elliptic curve signatures, supporting more flexible verification methods such as Passkey, and further integrating capabilities like fingerprint and Face ID on mobile devices to make key rotation and account recovery more seamless;
• Payment Frame: Gas sponsorship native. Applications can directly pay gas fees for new users, or you can specify in the payment frame to deduct USDC directly from the transfer—no more need for relayers to buy and sell gas off-chain;
• Execution frame: Natively supports atomic batching—authorization and exchange happen in one step; if successful, all actions take effect together; if failed, everything rolls back cleanly and completely.

Adding the EIP-8250 (Keyed Nonces) currently under discussion could enable future accounts to have multiple parallel nonce tracks.

Once these capabilities are natively embedded into the protocol, wallet products like imToken will experience a qualitative leap in their product form.

In the past, most of the wallet’s efforts were spent reminding users to prepare gas, explaining why a transaction was stuck, educating users on how to write down their seed phrases, and helping users switch between different chain RPCs.

In the future, when signature algorithms, gas sponsorship, permission controls, and transaction routing can all be programmed, wallets will finally return to their rightful place as a silent operating system between users and the decentralized world.

It remains fully under your control, just as before, but using it will feel as natural as scanning a payment code on Alipay or unlocking with your fingerprint.

Looking back at Ethereum's upgrade milestones over the past few years, the path has been extremely clear.

Dencun addresses blobs; Pectra continues scaling while enhancing validator and account capabilities; Fusaka paves the way for greater data throughput with PeerDAS; next up, Glamsterdam will lay the groundwork for higher gas limits and parallel execution through structural changes like ePBS and BAL.

Scaling is still not over, but scaling is no longer the only issue.

Ethereum has finally turned its attention to the most fundamental and challenging issues, which is why, when EF realigned its protocol development priorities in 2026, it distilled them into three very simple goals:

Scale, improve UX, and harden the L1.

Ethereum has long proven to the world that it can be a never-down world computer; now, it’s time to make it truly seamless for ordinary people to use.