2029年へのカウントダウン：イーサリアムの耐量子マラソン、Hegotáから号砲

原文著者：KarenZ、Foresight News

量子コンピューターがまだブロックチェーンの扉を叩いていないうちに、イーサリアム財団はすでにカレンダーに一つの日付を丸で囲んだ。2029年12月だ。

それはイーサリアム財団プロトコルチームが自らに課した工学的期限である。量子の脅威がより早く到来する可能性のあるシナリオに備え、リスクが実際に迫る前に、イーサリアムのレイヤー1ネットワークの耐量子化を完了させることを目指す。

計画中のHegotáは、イーサリアムを完全に耐量子なブロックチェーンに直接変えるものではないが、後続の計画が予定通り進められるかどうかを左右することになる。

EFが「Q-day」に2029年の期限を前倒しで設定

「Q-day」は通常、現実的な攻撃能力を持つ量子コンピューターが出現し、既存の公開鍵暗号体系が実質的な脅威に直面する仮想的な時点を指す。

それがいつ到来するかは、誰にも正確に予測できない。イーサリアム財団も、多くの信頼できる予測ではQ-dayは2030年より後、場合によってはかなり後になるとされ、また到来しない可能性もあることを明確に認めている。

イーサリアム財団プロトコルチームが採用しているのは、やや保守的な工学的仮定である。イーサリアムのレイヤー1は、Q-dayが早ければ2030年に到来する可能性に備えて事前に準備すべきだというものだ。

そのため、プロトコルチームは一つの目標を掲げた。2029年12月までに、イーサリアムのレイヤー1の実行、コンセンサス、データの3つの部分に完全な耐量子能力を備えさせることである。

この目標も永遠に調整されないわけではない。プロトコルチームは2027年1月に外部専門家の意見を交えて、量子コンピューティングの発展状況を再評価する計画だ。それまでは、2029年の期限は容易に譲れない作業目標として扱われる。

耐量子化に何年も前から準備が必要なのは、イーサリアムが一種類の暗号技術だけを使っているわけではなく、署名アルゴリズムを一つ交換すれば移行が完了するわけでもないからだ。ユーザーアカウントが取引の承認をどう証明するか、バリデーターがどうコンセンサスに参加するか、データがどう検証されるかは、それぞれ異なる暗号構造に関わる。いかなる変更も、仕様設計、クライアント実装、セキュリティレビュー、開発ネットワークでのテスト、メインネットでの調整を経る必要があり、脅威が現れてから着手するわけにはいかない。

Hegotáは「耐量子アップグレード」ではないが、計画全体の最初の試験である

イーサリアム財団プロトコルチームが現在公表しているベースラインロードマップによると、Glamsterdamネットワークアップグレードは2026年12月にメインネットへ展開される予定で、完全な耐量子能力はGlamsterdam後の5回目のハードフォークL*に位置づけられ、その目標時期は2029年12月とされている。GlamsterdamからL*まではわずか3年しかなく、Hegotá、I*、J*、K*、L*を順次完了するには、平均して各アップグレードの間隔は約7.2か月しかない。

これはかなり野心的なスケジュールだ。現在、イーサリアム財団はHegotá、I*、J*、K*について、それぞれ確定したメインネット展開時期を公表していない。確実なのは、クライアントチームが早ければ2026年第4四半期後半からHegotáの実装を開始する見込みで、複数の後続バージョンの研究、仕様、テストを並行して進めなければならないということだ。

現在のロードマップに基づく各段階の主な内容は以下の通りである。

• Hegotá：このロードマップの出発点に位置する。公式の位置づけは非常に明確で、Hegotá自体は耐量子アップグレードではないが、後続の耐量子アップグレードが予定通り進められるかどうかを左右する。
• I*：耐量子公開鍵レジストリを展開し、アカウントの登録と耐量子公開鍵の使用のためのプロトコル基盤を確立する。同時に、コンセンサスの分離が現時点でこのバージョンの有力な中核候補であり、大規模な状態構造の設計と移行作業もI*から始まると予想される。
• J*：「最小限の実行可能な耐量子」レイヤー1、すなわちMV-PQを確立する。その主要構成要素には、コンセンサス層の耐量子ハートビートメカニズム、データ層のポスト量子leanDAサンプリング、実行層のポスト量子leanSPHINCSトランザクションが含まれる。
• K*：現在のベースライン順序では、強制実行証明を導入する。その時点でバリデーターの発展方向は、各バリデーターが完全なブロックを再実行するのではなく、簡潔な実行証明を検証することになる。
• L*：現在のベースライン順序では、完全な耐量子コンセンサスに必要な耐量子証明メッセージ、すなわちポスト量子アテステーションを追加し、2029年12月に実行層、コンセンサス層、データ層の完全な耐量子目標を達成する。

ただし、K*とL*のタスク順序はまだ最終決定されていない。プロトコルチームは、耐量子証明メッセージをL*からK*に前倒しして完全な耐量子能力をより早く実現し、同時に強制実行証明をK*からL*に延期するという入れ替え案を評価している。この案を採用した場合、K*とL*の具体的な役割とアップグレードのペースはそれに応じて変わる。したがって、現段階で最も正確な言い方は、2026年12月がGlamsterdamの現在のメインネット目標であり、2029年12月がベースラインロードマップにおけるL*と完全な耐量子能力の目標である、ということだ。K*とL*の内部順序は依然として調整される可能性がある。

研究者、クライアント開発者、セキュリティレビュー担当者、テストチームは、Hegotáを完了させると同時に、I*、J*、K*、L*の仕様とプロトタイプを事前に準備しなければならない。Hegotáに相互に影響する機能を多く盛り込みすぎると、自身の展開が遅れるだけでなく、後続の耐量子作業に必要なチームのリソースを占有してしまう。

そのため、イーサリアム財団プロトコルチームはHegotáの候補提案をS（2件）、A（15件）、B（8件）、C（7件）、DFI（28件）、TBD（2件）の等級に分類し、合計62件の候補提案とした。S級は必ず提供しなければならないもの、A級は優先度が高く提供が見込まれるもの、B級は仕様、プロトタイプ、または担当者の確認などの条件を満たす必要があるもの、C級は現時点では採用ラインを下回るもの、DFIは今回のアップグレードへの組み込みを推奨しないもの、TBDは未定を意味する。

Hegotáの2つのS級：FOCILとFrames

プロトコルチームが公表したHegotáの分類では、S級に入ったEIPは2つだけである。コンセンサス層のEIP-7805 FOCILと、実行層のEIP-8141 Frameトランザクションだ。

これらはそれぞれ、トランザクションライフサイクルにおける2つの重要な問題を扱う。条件を満たすトランザクションがブロックに入れるかどうか、そしてアカウントがどのような方法でトランザクションを検証・実行できるか、である。

FOCIL（EIP-7805）の正式名称は「フォーク選択ルールによって強制される包含リスト」（Fork-choice enforced Inclusion Lists）である。その目標は、イーサリアムのトランザクション包含保証を改善することだ。

現在、専門のブロックビルダーがブロック生成を主導している。この分業はブロック構築の効率向上に役立つが、ブロック生成が長期的に少数のビルダーに集中すると、彼らが強いトランザクション選別能力を持つ可能性もある。FOCILはそのため、通常のブロック構築プロセスの外側に、バリデーターからの包含制約を一層追加する。

FOCILの設計によると、各スロットで一組のバリデーターが選ばれ、「包含リスト委員会」（IL committee）を構成する。委員会メンバーは自分たちが見ている保留中のトランザクションに基づいて、それぞれ包含リストを作成・ブロードキャストする。次のスロットのブロックビルダーはこれらのリストを収集し、ブロック構築時に実行条件を満たすトランザクションを追加する。新しいブロックを証明するバリデーターも、自分がタイムリーに受け取った包含リストを保存し、ブロックが対応する要件を満たしているかをチェックする。

ブロックが正当な理由なくバリデーターの保存したリストのトランザクションを欠落させた場合、証明者はそのブロックに投票しない。そのようなブロックは実行層では依然として有効なブロックであっても、正規チェーンに入るために必要なコンセンサスの支持を得られない。これがFOCILの意義である。委員会メンバーが直接ブロックを修正するのではなく、バリデーターが投票するかどうかを通じて、ブロックビルダーの選択を制約するのだ。

付随するEIP-8369は、どのトランザクションがFOCILの強制包含保証を受けるのに適しているかをさらに記述する。通常のトランザクションの欠落理由は比較的検証しやすいが、Framesトランザクションはプログラム可能な検証を可能にするため、判断コストが高く、読み取り可能な状態範囲と検証予算を追加で制限する必要がある。

平たく言えば、FOCILはバリデーターにブロックビルダーの仕事を奪わせるのではなく、ビルダーにコンセンサス層のルールを一つ追加するものだ。ブロック内の大部分のトランザクションは依然として自分で配置できるが、合理的な理由なく委員会がリストした適格なトランザクションを無視し続けることはできない。

Frame Transactions（EIP-8141）はアカウント層の問題を扱う。トランザクション検証、トランザクション実行、ガス支払いをプロトコル層でよりプログラム可能にし、ネイティブなアカウント抽象化の基盤を提供することを計画している。VitalikはEIP-8141の共同著者の一人である。

現在、ほとんどの通常のイーサリアムアカウントは固定型の秘密鍵署名に依存している。Framesは、アカウントがより柔軟な検証ロジックを使用できるようにすることを目指している。例えば、新しい署名方式の採用、複数の認可条件の組み合わせ、他のアカウントによる取引手数料の支払いなどだ。また、署名集約をサポートし、将来新しい署名方式を導入する際に、方式ごとに個別のハードフォークを行う必要をなくすこともできる。

しかし、Frames自体は完全な耐量子署名方式ではなく、Hegotáの展開後に既存の鍵を即座に廃止するものでもない。それが提供するのは「暗号アジリティ」である。将来署名方式を変更する必要が生じた場合、アカウントはプログラム可能な検証を通じて移行を完了でき、一つの鍵体系に永久に固定されることはない。

Framesには、中核となる付随物として2つのA級提案も必要である。EIP-8250 Keyed Noncesは、同じ送信者が互いに独立したnonceチャネルを使用できるようにし、異なるトランザクションが厳密な順序を共有することで互いにブロックされるのを防ぐ。EIP-8272は、トランザクションがバリデーターのチェック可能な最近のオンチェーン状態を使用できるようにし、関連するプライバシートランザクションもFOCILが提供する包含保証を得られるようにする。

したがって、FOCILとFramesは互いに無関係な2つの機能ではない。前者はブロックがどの適格なトランザクションを含めなければならないかを変え、後者はトランザクション自体の検証構造を変える。両者が安全に連携できるかどうかは、Hegotáの最も重要なテストタスクの一つである。

S級以外に、注目すべきEIPはどれか？

S級提案がHegotáの主軸を定義するが、複数のA級提案もイーサリアムの将来のアカウントセキュリティ、耐量子移行、実行証明、リソース課金に影響を与える。

まずEIP-8365である。これは一部のBLS引き出し資格情報の段階的廃止を開始することを計画している。これらの資格情報は、十分に強力な量子攻撃に直面した場合に安全性を失う可能性のある暗号技術に依存しているためだ。プロトコルチームは、この移行は完全な耐量子コンセンサスの設計が確定するのを待たずに前倒しで開始できると考えている。

アカウントセキュリティに関しては、EIP-7906、EIP-8298、EIP-8151がFramesの拡張セットと見なされている。

EIP-7906はトランザクションアサーション（Transaction Assertions）メカニズムを導入し、トランザクションが最終的に送信される前に、指定された結果が発生したかどうかをチェックする。このメカニズムは、悪意のあるコントラクトがウォレット資産を抜き取ることや、一部のMEV行為による損失を減らすことを目的としている。ただし、この提案の具体的な読み取り範囲はまだ研究中で絞り込みが行われているため、現在の設計を確定した最終仕様として書くことはできない。

EIP-8298は、アカウントが既存のコントラクトコードを再利用できるようにし、委任されたアカウントを完全なコードを持つスマートコントラクトアカウントへとさらに転換させる。EIP-8151は、既存のアカウントコードを持つアドレスが従来のecRecover認証に依存し続けることを制限する。

これら2つの提案が組み合わさることで、アカウントは古いsecp256k1鍵を最高管理資格情報として本当に停止でき、将来旧鍵体系から脱却するための完全な経路を確立できる。

EIP-8025（オプションの実行証明）は将来のzkEVMロードマップに関連する。オプションの実行証明に必要な変更を統一実行仕様に組み込み、異なるzkVMプロジェクトが長期的に互いに分岐したバージョンを保守する問題を減らすことを計画している。

EIP-8279（ブロックアクセスリストのバイト層）とEIP-8131（統一トランザクションコンテンツ層）は、実行セキュリティ提案の一組である。両者はそれぞれブロックアクセスリストとトランザクションコンテンツに最低課金基準を設定し、攻撃者が低価格のコンテンツを利用して極端なリソース負荷を生み出すのを制限することを目的としている。これらがまず解決するのは最悪ケースのブロック処理コストであり、ネットワーク容量の増加を直接宣言するものではない。その結果生じる安全余裕を容量拡大に使うかどうかは、後で別途決定する必要がある。

EIP-3298はガス払い戻しメカニズムを完全に撤廃し、計量、実装、テストにおける特殊ケースを減らすことを計画している。EIP-5920（PAY Opcode）は、コントラクトが受信側のコードを実行せずにETHを転送できるようにし、「価値の転送」と「コントラクトの呼び出し」を明確に分離する。

一方、注目を集めている一部の提案は依然としてB級にとどまっている。

例えば、EIP-8198（Quick Slots）はスロット時間の短縮を目指しているが、プロトコルチームは、コアプロトコルの変更を網羅する仕様、完全なプロトタイプ、下流への影響評価を先に完了し、後続のコンセンサス分離設計を妨げないことを証明するよう求めている。理由は、スロット時間がブロック生成速度だけでなく、ネットワーク伝播、コンセンサス判断、アプリケーションの時間に関する前提にも影響するからだ。

また、EIP-8368とEIP-8372は「TBD」（未定）に分類されている。2つの提案はガス制限と状態リソース課金に関わるもので、プロトコルチームはGlamsterdamが2026年12月にメインネットへ展開された後のデータを待って、再調整が必要かどうかを判断することにした。

Hegotáに最終的にいくつのEIPが組み込まれるかは、今回のアップグレードの成否を測る唯一の基準ではない。

より重要なのは、安全性とテスト品質を犠牲にすることなくFOCIL、Frames、およびその中核となる付随物を提供できるかどうか、同時にI*の公開鍵登録とコンセンサス分離、J*の最小限の実行可能な耐量子能力、K*とL*の実行証明と完全な耐量子コンセンサスのために十分な研究開発リソースを残せるかどうかである。

現在の目標によると、Glamsterdamは2026年12月にこの緊密なアップグレードサイクルを開始し、ベースラインロードマップにおけるL*は2029年12月に終点に到達する。途中の各アップグレードは、自分の機能を完了するだけでは不十分で、次の段階が継続して進められることを保証しなければならない。

量子の脅威が2030年までに現実のものとなるかどうか、誰にも確かな答えは出せない。しかし、イーサリアムの現在の選択はすでに明確である。まずリスクに期限を設定し、それから各提案が仕様、プロトタイプ、テストを通じてメインネットに参入する条件を備えていることを証明させるのだ。

記事参考：

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