Ethereum’s Quantum Resistance Marathon Starts with the Gunshot at Hegotá

2029 Countdown: Ethereum‘s Quantum Resistance Marathon Starts with the Gunshot at Hegotá

Foresight News特邀专栏作者
2026-09-09 11:00
This article is about 5164 words, reading the full article takes about 8 minutes
Not a quantum-resistant upgrade, yet decisive to its success: Understanding Hegotá.
AI Summary
Expand

• Core Thesis: The Ethereum Foundation, in response to the quantum computing threat, has set December 2029 as the engineering deadline for completing quantum resistance upgrades at the Layer 1 network level, positioning the Hegotá upgrade as the critical starting point for determining whether subsequent plans can proceed on schedule.
• Key Elements:
  1. The Ethereum Foundation is working under a conservative assumption, preparing as if Q-day could arrive as early as 2030, with the goal of achieving full quantum resistance across the execution, consensus, and data layers by December 2029.
  2. Quantum resistance upgrades require years of advance preparation, as they involve multiple cryptographic structures that must go through specification design, client implementation, security review, and mainnet coordination processes — they cannot be swapped in at the last minute.
  3. Under the baseline roadmap, Glamsterdam is slated for launch in December 2026, with L* (the full quantum resistance target) set for December 2029. In between, five upgrades including Hegotá, I*, and J* must be completed — an aggressive pace.
  4. Hegotá is not itself a quantum-resistant upgrade, but its S-level proposals — EIP-7805 FOCIL (Fork-choice enforced Inclusion List) and EIP-8141 Frames (Programmable Transaction Validation) — lay the groundwork for the subsequent migration.
  5. FOCIL aims to constrain block builders’ power to filter transactions through validator voting, while Frames provides “cryptographic agility,” enabling accounts to flexibly switch signature schemes in the future.
  6. Multiple A-level proposals, such as EIP-8365 (exiting BLS withdrawal credentials) and EIP-8298 (account code reuse), collectively support account security and the quantum-resistant migration path.
  7. The protocol team plans to reassess quantum developments in January 2027. The 2029 deadline can be adjusted if necessary, but until then, it is treated as a work target that cannot be easily conceded.

Original author: KarenZ, Foresight News

Quantum computers haven’t yet knocked on blockchain’s door, but the Ethereum Foundation has already circled a date on its calendar: December 2029.

This is the engineering deadline the Ethereum Foundation Protocol Team has set for itself: preparing under the scenario where quantum threats could emerge earlier, aiming to complete the quantum-resistance overhaul of Ethereum’s Layer 1 before the risk truly becomes imminent.

The planned Hegotá upgrade, while it won’t directly transform Ethereum into a fully quantum-resistant blockchain, will determine whether subsequent plans can proceed on schedule.

EF Sets a Preliminary 2029 Deadline for “Q-Day”

“Q-day” is typically used to refer to a hypothetical point in time when quantum computers with real-world attack capabilities emerge, posing a substantial threat to existing public-key cryptography systems.

No one can accurately predict when it will arrive. The Ethereum Foundation has also explicitly acknowledged that most credible predictions place Q-day after 2030 — possibly much later — and there is also a possibility it may never come.

The Ethereum Foundation Protocol Team has adopted a relatively conservative engineering assumption: Ethereum’s Layer 1 should be prepared in advance for the scenario where Q-day could arrive as early as 2030.

To this end, the Protocol Team has proposed a goal — to ensure that the execution, consensus, and data layers of Ethereum’s Layer 1 possess complete quantum-resistance capabilities by December 2029.

This goal is also not set in stone. The Protocol Team plans to reassess quantum computing developments in January 2027, incorporating input from external experts. Until then, the 2029 deadline will be treated as a work target that cannot be easily compromised.

The reason quantum-resistant transformation requires years of advance preparation is that Ethereum does not rely on just one cryptographic technique, nor can it complete the migration by simply swapping out a signature algorithm. How user accounts prove transaction authorization, how validators participate in consensus, and how data is verified all involve different cryptographic structures. Any modification must go through spec design, client implementation, security reviews, devnet testing, and mainnet coordination — it’s impossible to start only after the threat has already materialized.

Hegotá Isn’t a “Quantum-Resistance Upgrade,” But It Is the First Test of the Entire Plan

According to the baseline roadmap currently published by the Ethereum Foundation Protocol Team, the Glamsterdam network upgrade is scheduled for mainnet in December 2026, with full quantum-resistance capabilities planned for L*, the fifth hard fork after Glamsterdam, targeting December 2029. From Glamsterdam to L*, there are only three years. To complete Hegotá, I*, J*, K*, and L* in sequence, the average gap between each upgrade would be only approximately 7.2 months.

This is an extremely aggressive timeline. Currently, the Ethereum Foundation has not published firm mainnet dates for Hegotá, I*, J*, and K* individually. What is certain is that client teams expect to begin implementing Hegotá as early as late Q4 2026, while research, specifications, and testing for multiple subsequent versions must proceed in parallel.

Under the current roadmap, the primary arrangements for each phase are as follows:

• Hegotá: Positioned at the starting point of this roadmap. The Foundation’s positioning is very clear: Hegotá itself is not a quantum-resistance upgrade, but it will determine whether subsequent quantum-resistance upgrades can proceed on schedule.
• I*: Deploys a quantum-resistant public key registry, establishing the protocol foundation for accounts to register and use quantum-resistant public keys; meanwhile, decoupling consensus is currently the leading core candidate direction for this version, with larger-scale state structure design and migration work also expected to begin with I*.
• J*: Establishes a “minimum viable quantum-resistant” Layer 1, i.e., MV-PQ. Its key components include a quantum-resistant heartbeat mechanism on the consensus layer, post-quantum leanDA sampling on the data layer, and post-quantum leanSPHINCS transactions on the execution layer.
• K*: Under the current baseline ordering, introduces enforced execution proofs. At that point, the direction for validators will be to verify succinct execution proofs rather than having every validator re-execute the full block.
• L*: Under the current baseline ordering, fills in the quantum-resistant attestation messages needed for complete quantum-resistant consensus — namely, post-quantum attestations — and by December 2029, achieves the complete quantum-resistance goal across the execution, consensus, and data layers.

However, the task ordering of K* and L* has not yet been finalized. The Protocol Team is evaluating a swap proposal: moving quantum-resistant attestation messages from L* up to K* to achieve full quantum-resistance capabilities earlier, while postponing enforced execution proofs from K* to L*. If this proposal is adopted, the specific responsibilities of K* and L*, as well as the upgrade cadence, would change accordingly. Therefore, the most accurate statement at this stage is: December 2026 is the current mainnet target for Glamsterdam, December 2029 is the target for L* and full quantum-resistance capabilities under the baseline roadmap; the internal ordering of K* and L* may still be adjusted.

Researchers, client developers, security reviewers, and testing teams must not only complete Hegotá but also prepare specifications and prototypes for I*, J*, K*, and L* in advance. If Hegotá incorporates too many interdependent features, it could not only delay its own launch but also consume team re

Therefore, the Ethereum Foundation Protocol Team has categorized Hegotá candidate proposals into S (2 items), A (15 items), B (8 items), C (7 items), DFI (28 items), and TBD (2 items) — 62 candidate proposals in total. S-level means must-deliver; A-level means high priority and expected delivery; B-level requires meeting conditions such as specifications, prototypes, or owner confirmation; C-level is currently below the inclusion threshold; DFI indicates not recommended for inclusion in this upgrade; and TBD means to be determined.

Hegotá’s Two S-Level Items: FOCIL and Frames

Among the Hegotá classifications published by the Protocol Team, only two EIPs have reached S-level: EIP-7805 FOCIL on the consensus layer, and EIP-8141 Frame transactions on the execution layer.

They address two critical issues in the transaction lifecycle: whether an eligible transaction can be included in a block, and through what methods an account can authorize and execute transactions.

FOCIL (EIP-7805) stands for “Fork-choice enforced Inclusion Lists.” Its goal is to improve Ethereum’s transaction inclusion guarantees.

Currently, professional block builders dominate block production. This division of labor helps improve block construction efficiency, but if block production remains concentrated among a small number of builders for extended periods, they may also gain significant transaction censoring power. FOCIL therefore adds a layer of validator-imposed inclusion constraints on top of the normal block construction process.

Under FOCIL’s design, each slot selects a set of validators to form an “inclusion list committee.” Committee members each create and broadcast inclusion lists based on the pending transactions they observe. The block builder for the next slot collects these lists and includes transactions that meet execution conditions when constructing the block. Validators responsible for attesting to the new block also save the inclusion lists they received in a timely manner and check whether the block satisfies the corresponding requirements.

If a block omits transactions from the saved lists without justifiable reason, attesters will not vote for that block. Even if such a block remains valid at the execution layer, it cannot gain the consensus support needed to enter the canonical chain. This is FOCIL’s significance: it doesn’t let committee members directly modify blocks, but instead constrains block builders’ choices through whether validators vote.

The accompanying EIP-8369 further describes which transactions are suitable for FOCIL’s mandatory inclusion guarantees. The reasons for omitting ordinary transactions are relatively easy to verify; Frames transactions allow programmable verification, which carries higher assessment costs, so additional limits on the accessible state scope and verification budget are needed.

In simple terms, FOCIL doesn’t take block builders’ work away from them — it adds a consensus-layer rule for builders: you can still arrange most transactions in the block, but you cannot persistently ignore qualified transactions listed by the committee without reasonable cause.

Frame Transactions (EIP-8141) address the account-layer problem. They plan to make transaction validation, transaction execution, and gas payment more programmable at the protocol layer, providing the foundation for native account abstraction. Vitalik is one of the co-authors of EIP-8141.

Currently, most ordinary Ethereum accounts rely on fixed types of private key signatures. Frames aims to enable accounts to use more flexible validation logic — for example, adopting new signature schemes, combining multiple authorization conditions, or allowing other accounts to pay transaction fees. It can also support signature aggregation and allow future introduction of new signature schemes without requiring a separate hard fork for each one.

But Frames itself is not a complete quantum-resistant signature scheme, nor will it immediately phase out existing keys after Hegotá launches. What it provides is “cryptographic agility”: if a signature scheme change is needed in the future, accounts can migrate through programmable validation rather than being permanently locked into one key system.

Frames also requires two A-level proposals as core companions. EIP-8250 Keyed Nonces allows the same sender to use mutually independent nonce channels, so different transactions don’t block each other due to sharing a strict sequence; EIP-8272 allows transactions to use recent on-chain state that validators can check, enabling related privacy transactions to also benefit from FOCIL’s inclusion guarantees.

Therefore, FOCIL and Frames are not two unrelated features. The former changes which eligible transactions must be included in a block, while the latter changes the validation structure of transactions themselves. Whether the two can work together safely is one of Hegotá’s most important testing tasks.

Beyond the S-Level, Which Other EIPs Are Worth Attention?

S-level proposals define Hegotá’s main storyline, but several A-level proposals will equally impact Ethereum’s future account security, quantum-resistance migration, execution proofs, and re

First is EIP-8365. It plans to initiate a gradual phase-out of certain BLS withdrawal credentials, as these credentials still rely on cryptographic techniques that could lose security against sufficiently powerful quantum attacks. The Protocol Team believes this migration can begin early without waiting for the complete quantum-resistant consensus design to be finalized.

On the account security front, EIP-7906, EIP-8298, and EIP-8151 are regarded as an extended combination for Frames.

EIP-7906 introduces a Transaction Assertions mechanism, allowing transactions to verify whether specified outcomes have occurred before final submission. This mechanism aims to reduce losses caused by malicious contracts draining wallet assets and certain MEV behaviors. However, the specific read scope of this proposal is still being researched and narrowed down, so the current design cannot be treated as a locked final specification.

EIP-8298 allows accounts to reuse existing contract code, enabling delegated accounts to further transform into smart contract accounts with full code. EIP-8151 restricts addresses with existing account code from continuing to rely on traditional ecRecover authentication.

Only when these two proposals are combined can accounts truly stop treating old secp256k1 keys as the highest control credential, establishing a complete path for eventually exiting the legacy key system.

EIP-8025 (optional execution proofs) is related to the future zkEVM roadmap. It plans to incorporate the changes needed for optional execution proofs into a unified execution specification, reducing the problem of different zkVM projects maintaining forked versions of each other over the long term.

EIP-8279 (block access list byte-level) and EIP-8131 (unified transaction content layer) form a set of execution security proposals. Both set minimum pricing standards for block access lists and transaction content, respectively, aiming to limit attackers from exploiting underpriced content to create extreme resource burdens. They first address worst-case block processing costs rather than directly announcing increased network capacity. Whether to use the resulting security margin to expand capacity requires separate decisions in the future.

EIP-3298 plans to completely remove the gas refund mechanism, reducing special cases in metering, implementation, and testing; EIP-5920 (PAY Opcode) allows contracts to transfer ETH without executing receiver code, clearly separating “transferring value” from “calling contracts.”

Meanwhile, some proposals that have drawn attention remain at B-level.

For example, EIP-8198 (Quick Slots) aims to shorten slot time, but the Protocol Team requires it to first complete specifications covering core protocol changes, a full prototype, downstream impact assessments, and proof that it won’t interfere with subsequent decoupled consensus design. The reason is that slot time doesn’t just affect block production speed — it also impacts network propagation, consensus judgments, and applications’ assumptions about time.

Additionally, EIP-8368 and EIP-8372 are listed as “TBD” (to be determined). Both proposals concern gas limits and state reata after Glamsterdam launches in December 2026 before determining whether recalibration is needed

How many EIPs Hegotá ultimately includes is not the sole criterion for measuring the success of this upgrade.

More importantly, it must deliver FOCIL, Frames, and their core companions without sacrificing security and testing quality, while leaving sufficient research and development res minimum complete quantum-resistant consensus

Under current targets, Glamsterdam will kick off this compact upgrade cycle in December 2026, and L* under the baseline roadmap will reach the finish line in December 2029. Each upgrade in between cannot afford to merely complete its own features — it must also ensure the next phase can continue moving forward.

Whether the quantum threat will become a reality before 2030 is something no one can answer with certainty. But Ethereum’s current choice is already clear: first set a deadline for the risk, then require every proposal to prove through specifications, prototypes, and testing that it is ready for mainnet.

https://blog.ethereum.org/2026/09/07/protocol-hegota-eips

https://blog.ethereum.org/2026/09/07/protocol-priorities

https://x.com/VitalikButerin/status/2073459000398463446

ETH
technology
Welcome to Join Odaily Official Community
Subscription Group：
https://t.me/Odaily_News
Chat Group：
https://t.me/Odaily_GoldenApe
Official Account：
https://twitter.com/OdailyChina
Chat Group：
https://t.me/Odaily_CryptoPunk
Recommended Articles

Decentralization or loss of control? In the era of autonomous Agents, what kind of “verifiable authorization” do we need?

VVV surges over 60% in a day — is privacy + AI becoming the next explosive narrative?

Income vs. Buybacks: Which Stock-Paired Meme Platform Tokens Are Worth Accumulating?

Search
Article Catalog
Author Library
Foresight News
Bitcoin‘s “Bounce Has Ended,” Formally Entering Late Bear Market Phase?
Ethereum Q1 2026 Review: On-Chain Activity Hits All-Time High, Tokenized Assets Lead the Industry
Robinhood Chain Ecosystem Overview: Which Projects Are Worth Getting In Early On?
Article Ranking
Daily
Weekly

64-year-old Man Tops Fomo Leaderboard, “Diamond Hands” Bonkguy’s Meme Legend
AMC CEO Slams Robinhood Stock Tokens, Same-Named Meme Coin Unexpectedly Lifts the Stock Price?
JINQIAN rockets to $80M then zeroes out in two hours; “stock-crypto pairing” becomes a custom-made “pump and dump”
Solana is getting anxious: Official backing propels a memecoin past $100M market cap overnight, Toly looks to win over Robinhood
Tonight’s US Nonfarm Payrolls Big Test: “Good News” Is Also “Bad News”
Download Odaily App
Let Some People Understand Web3.0 First
IOSAndroid
About UsContact UsJoin UsFriendly LinksAdvertising Cooperation
User AgreementPrivacy PolicyDisclaimerOdaily Brand Media Kit | Official Logo & Visual Guidelines
Beijing Ruike Culture Media Co., Ltd.
京ICP备 2026027382号京公网安备11010502060861号

Source: www.odaily.news