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*：耐量子公開鍵レジストリを展開し、アカウントが耐量子公開鍵を登録・使用するためのプロトコル基盤を確立する。同時に、コンセンサスの分離（decoupling）が現在このバージョンの主要な候補方向であり、規模の大きい状態構造設計と移行作業もI*から始まると見込まれる。
• J*：「最小実行可能な耐量子」レイヤー1（MV-PQ）を確立する。その主要構成要素には、コンセンサス層の耐量子heartbeatメカニズム、データ層のポスト量子leanDAサンプリング、実行層のポスト量子leanSPHINCSトランザクションが含まれる。
• K*：現在の基準順序によれば、强制执行証明（enforcement proofs）を導入する。その際、バリデータの发展方向は、各バリデータが完全なブロックを再実行するのではなく、簡潔な実行証明を検証することになる。
• L*：現在の基準順序によれば、完全な耐量子コンセンサスを実現するために必要な耐量子証明メッセージ、すなわちpost-quantum attestationsを補完し、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が提供するのは「暗号敏捷性」である。将来署名スキームの変更が必要になった場合、アカウントはプログラム可能な検証を通じて移行を完了でき、永久に一つの鍵体系に縛られることはない。

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

したがって、FOCILとFramesは互いに無関係な機能ではない。前者はブロックに含めなければならない適格トランザクションを変え、後者はトランザクション自体の検証構造を変える。両者が安全に連携できるかどうかが、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（統一トランザクションコンテンツレイヤー）は、一連の実行セキュリティ提案である。両者はそれぞれブロックアクセスリストとトランザクションコンテンツに最低価格設定基準を設け、攻撃者が価格設定の低いコンテンツを利用して極端なリソース負担を生み出すことを制限することを目的とする。これらはまず最悪ケースのブロック処理コストを解決するものであり、ネットワーク容量の引き上げを直接宣言するものではない。その結果生まれるセキュリティマージンを容量拡大に利用