From Glamsterdam to Hegotá: After expansion, what will the next phase of Ethereum address?

CN
1 hour ago

If you string together the upgrades of Ethereum over the past few years, the key theme is undoubtedly "scaling."

From Dencun introducing Blob to significantly reduce taxes on Rollup, to Pectra adjusting the efficiency of validators and the staking mechanism, and then to Fusaka implementing PeerDAS to lower data distribution burdens, the protocol layer has almost poured all its energy into one thing: allowing Ethereum to handle more data while not raising the threshold for nodes too high.

This combination of measures is indeed effective; the data cost for Rollup has decreased, and the mainnet Gas Limit is steadily increasing, making Ethereum no longer deter users with fees in the dozens of dollars like in the last bull market.

But while the road is wider, driving remains awkward:

  • We still have to move assets between three or four L2s, and with just a moment of inattention, we could transfer to the wrong chain;
  • A transfer gets packaged in seconds, yet bridges and exchanges insist you wait more than ten minutes before confirming;
  • Professional Builders almost monopolize block packaging, and if you want to send a sensitive transaction, it may be rejected by unwritten rules outside the protocol at any moment;
  • Not to mention that even today, a new user entering the space still has to first understand why they need ETH in their wallet, what Nonce is, and what Gas is, just to transfer a few hundred USDC.

These issues manifest as friction in user experience, but behind them are deeper protocol mechanisms involving confirmation rules, block construction, censorship resistance, and account models.

This is also the new issue that Ethereum is starting to focus on from Glamsterdam to Hegotá, from Q4 2026 to 2027.

1. Scaling continues, but begins to "stitch" L1 and L2

Of course, scaling will not hit the brakes.

Glamsterdam still carries a heavy performance orientation, with two notable items, one called ePBS (EIP-7732) and the other BAL (Block-level Access Lists, EIP-7928). In simple terms:

  • ePBS formalizes the already existing division of labor between Proposers and Builders outside the protocol into the protocol, while also scientifically slicing the time window for block production and validation to leave room for larger blocks in the future;
  • BAL allows blocks to list an "access list" at the start, allowing nodes to readily fetch data or even process it in parallel, effectively solving storage I/O bottlenecks;

However, beyond scaling, the real pain for most people today is not whether Ethereum's TPS is high enough, but rather "there are too many chains."

For example, ETH is in the mainnet, memes are on Robinhood Chain, USDC for payment settlements might be on Arbitrum, and USDC for bottom fishing is on Base...

For the Ethereum Foundation, Rollups are part of Ethereum's landscape, but for users, it’s no different from dealing with cross-border currency exchange or applying for a visa.

Therefore, to stitch the scattered pieces back into a network, in addition to cross-chain protocols showcasing their capabilities, a recent underlying mechanism pushed by the protocol layer is worth paying attention to — FCR (Fast Confirmation Rule).

Many people think that once a transaction is packed into a block, it’s confirmed, but at the cryptographic and consensus layers, a recently added block can very well encounter small reorganizations, requiring Ethereum to complete two Epochs for true irreversible "finality," which roughly takes 13 minutes.

This may not matter for routine transfers, but for cross-chain bridges, large settlements, and centralized exchanges, it becomes a torment; to avoid reorganization risks, they can only make you wait.

The cleverness of FCR lies in not requiring you to foolishly wait for complete finality for over ten minutes, but rather leveraging the attestations that validators will continuously generate to assess earlier whether a block has obtained enough consensus support based on accumulated voting weights.

According to the targets set by the Ethereum Foundation, under the condition of normal network synchronization, FCR is expected to bring this “strong confirmation” down to about 15 to 30 seconds, and while not equivalent to full finality, it already provides an earlier and clear safety signal for bridges, cross-chain communication, and infrastructures that currently must wait for finality.

More specifically, FCR does not need to wait for a hard fork to activate; it resembles a set of confirmation rules that can be gradually adopted by consensus clients and infrastructures.

Once various L2s, cross-chain bridges, and wallets begin using this signal, the significant cross-layer delays today caused by "waiting for L1 finality" could potentially be compressed from minutes to seconds.

This also means that in the future, when you transfer an asset, it may quietly cross two or more chains in the background, but at the frontend, you just need to click confirm once, and it will arrive quickly.

2. A deeper proposition: Who has the power to decide if a transaction can go on-chain?

However, as blocks get larger and Builders become more specialized, Ethereum faces another classic dilemma.

Since professional Builders can maximize block construction efficiency with top-tier computing power and order flows, the authority over the vast majority of blocks naturally falls into the hands of a few large institutions.

This brings about an extremely dangerous hidden risk: censorship.

If certain Builders, due to regulatory pressures, business competition, or simply disliking certain privacy protocols, deliberately remain silent in the memory pool and refuse to package your legitimate transactions, even if you have your private key and sufficient Gas, your transaction could still be trapped outside the chain (see further reading "Incorporating Anti-Censorship in Protocol: Who Decides Whether an Ethereum Transaction Can Go On-chain?").

If decentralization can't even maintain the basic "anti-censorship transaction admission," then a higher throughput is nothing but a castle in the air.

This is why FOCIL (Fork-choice Enforced Inclusion Lists, EIP-7805) was placed in such a crucial position in the planning of Hegotá.

Its logic is extremely simple and straightforward: it imposes constraints on Builders.

For each Slot, the protocol randomly selects a group of independent ordinary validators who will compile a list of legitimate transactions they see in the memory pool into an "Inclusion List," and while Builders can still freely arrange the transaction order to earn their MEV, the blocks they submit must honestly include the transactions on this list.

If a Builder dares to maliciously ignore this list, validators across the network will directly exclude the block based on the forking choice rules. In other words, you can profit from your skills, but you cannot decide for the entire network who is qualified to use Ethereum.

Once this layer of mechanism is established, it also addresses a long-standing shortcoming in Ethereum that many have been eagerly anticipating, which is privacy, and it has finally found a foothold.

It is well known that in the past when discussing privacy, it often revolved around zero-knowledge proofs, stealth addresses, and mixing pools, but as long as Builders recognize "this is a call to a privacy contract" and reject it, your mathematical magic is instantly thwarted.

Currently, in Ethereum's privacy approach, FOCIL effectively blocks precisely the areas where it’s most likely to get bottlenecked; after all, as long as the protocol layer can firmly protect the admission rights of every legitimate transaction, privacy exploration at the upper layer can have a viable path.

At present, more radical privacy proposals like EIP-8182 (attempting to introduce a protocol-level native Shielded Pool) are still in the candidate discussion stage, but the trend is already very clear, namely that privacy can no longer be regarded as a peripheral function of a third-party DApp; it must gradually become the basic utilities of Ethereum’s underlying infrastructure.

3. The last step, native AA and wallets that are no longer anti-user

The architectural adjustments discussed earlier primarily occur beneath the surface, while the third matter will closely relate to the actual user experience.

That is, Ethereum has finally made the decision to perform major surgery on the EOA account model that has lasted for over a decade.

To be honest, the private key signature model that Ethereum has used until now is utterly anti-user for even slightly more average internet users:

If the private key is lost, it’s an irreversible disaster; having thousands of stablecoins in the wallet means nothing if you are just short 0.001 ETH for fees, temporarily making assets untransferable; playing DeFi requires you to first approve and then swap, with three signature clicks to complete one task; transaction Nonce must strictly follow its order, if one is stuck, the whole family is stuck.

In the first two rounds of upgrades, the community tried various compromises. For example, they created ERC-4337 to indirectly save the day with contract wallets outside the protocol; and also introduced EIP-7702 in Pectra to allow regular addresses to temporarily mount a segment of contract logic for more flexibility.

But EIP-7702 is ultimately just a temporary bridge, while the main event locked in Hegotá is the true native account abstraction EIP-8141 (Frame Transactions).

It can be simply understood that in the past, a transaction on Ethereum tightly bound three things together: who proves it is you (validation) + who pays the money (Gas fee) + what exactly is to be done (execution), while EIP-8141 separates these three aspects into different "frames" at the protocol’s underlying level (see further reading "Native Account Abstraction + Anti-Quantum Threat: Why Hasn't EIP-8141 Become Ethereum's Headliner for Hegotá?"):

  • Validation Frame: No longer locked into a fixed ECDSA elliptic curve signature, it can support more flexible validation methods like Passkeys, further integrating capabilities like phone fingerprints and Face ID to make key rotation and account recovery feel more natural;
  • Payment Frame: Native Gas sponsorship. Applications can directly pay Gas for new users, or you can designate that the payment frame deducts directly from your USDC in the transfer, eliminating the need for relayers to resell off-chain;
  • Execution Frame: Naturally supports atomic batch processing, with authorization + exchange happening in one action—if successful, they take effect together; if it fails, everything simply rolls back.

If coupled with the in-discussion EIP-8250 (Keyed Nonces), future accounts might even have multiple parallel Nonce tracks.

Once these capabilities are inherently embedded in the protocol, for wallets like imToken, the product form will undergo a qualitative liberation.

It’s important to note that previously, most of the wallet's energy was spent reminding users to prepare Gas, explaining why a transaction was stuck, educating users on how to write down mnemonic phrases, and helping users switch RPCs between different chains.

In the future, when signing algorithms, Gas sponsorship, permissions, and transaction routing can all be programmed, wallets can finally return to their rightful position as a silent operating system between users and the decentralized world.

Like before, it will still be completely controlled by users, but using it will feel as natural as scanning to pay with Alipay or unlocking with a fingerprint.

In conclusion

Looking back at Ethereum's upgrade progression over the past few years, the path is actually very clear.

Dencun addressed Blob; Pectra continues to scale while improving validator and account capabilities; Fusaka paves the way for greater data throughput with PeerDAS; the upcoming Glamsterdam will lay a foundation for higher Gas Limits and parallel execution through structural changes like ePBS and BAL.

Scaling has certainly not ended, but it is no longer the sole issue.

Ethereum has finally freed its hands to directly face those most fundamental and frustrating problems, which is why the Ethereum Foundation summarized its protocol development direction into three very simple goals when reassessing in 2026:

Scale, Improve UX, and Harden the L1.

Ethereum has long proven that it can become a perpetual global computer; now is the time for ordinary people to genuinely use it smoothly.

免责声明:本文章仅代表作者个人观点,不代表本平台的立场和观点。本文章仅供信息分享,不构成对任何人的任何投资建议。用户与作者之间的任何争议,与本平台无关。如网页中刊载的文章或图片涉及侵权,请提供相关的权利证明和身份证明发送邮件到support@aicoin.com,本平台相关工作人员将会进行核查。

Share To
APP

X

Telegram

Facebook

Reddit

CopyLink