Ethereum財団、2029年までに量子耐性アップグレードの期限を設定

原文：KarenZ、Foresight News

量子コンピューターはまだブロックチェーンの扉をノックしていませんが、イーサリアム財団はすでにカレンダーに2029年12月をマークしています。

これはイーサリアム財団のプロトコルチームが自ら設定したエンジニアリングの期限である：量子脅威が早期に発生する可能性を想定し、リスクが実際に迫る前に、イーサリアムレイヤー1ネットワークの量子耐性向上を完了することを目指している。

計画中のHegotáは、イーサリアムを完全な量子耐性ブロックチェーンに直接変更するものではないが、その後の計画が予定通り進むかどうかを決定づける。

「Q-day」は、現実的な攻撃能力を持つ量子コンピュータが登場し、現在の公開鍵暗号システムが実質的な脅威にさらされるという仮想的な時間点を指す。

それがいつ訪れるかを正確に予測できる者は誰もいない。イーサリアム財団も、信頼できる予測の多くがQ-dayは2030年以降になる可能性が高いこと、さらにそれよりずっと後になる可能性や、一向に到来しない可能性もあることを明確に認めている。

イーサリアム財団のプロトコルチームは、イーサリアムレイヤー1が、Q-dayが2030年にもっとも早く到来する可能性に備えて、保守的なエンジニアリング仮定を採用している。

そのため、プロトコルチームは、2029年12月までにイーサリアムレイヤー1の実行、コンセンサス、データの3つの部分に完全な量子耐性を実装することを目標としています。

この目標は常に変更されないわけではありません。プロトコルチームは、2027年1月に外部専門家の意見を踏まえて、量子計算の進展状況を再評価する予定です。それまでの間、2029年の期限は容易に妥協しない作業目標として扱われます。

量子耐性への対応を数年前から準備する必要があるのは、イーサリアムが単一の暗号技術のみを使用しているわけではなく、署名アルゴリズムを一つ変更するだけで移行が完了するわけではないからです。ユーザーアカウントが取引の承認をどのように証明するか、バリデーターがコンセンサスにどのように参加するか、データがどのように検証されるかは、それぞれ異なる暗号構造を伴います。いかなる変更も、仕様設計、クライアント実装、セキュリティレビュー、開発ネットワークでのテスト、およびメインネットでの調整を経なければならず、脅威が実際に発生してから対応を始めるわけにはいきません。

エーテリアム財団プロトコルチームが現在公表している基準ロードマップによると、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*：MV-PQと呼ばれる「最小限の量子耐性」レイヤーを構築。その主要な構成要素には、コンセンサス層の量子耐性ハートビートメカニズム、データ層の後量子leanDAサンプリング、および実行層の後量子leanSPHINCSトランザクションが含まれる。
• K*：現在の基準に基づいて並べ替え、強制実行証明を導入します。これにより、バリデーターは各ブロックを再実行するのではなく、簡潔な実行証明を検証する方向に進化します。
• 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áグレーディングにおいて、S級に認定されたEIPは2つだけです：コンセンサス層のEIP-7805 FOCILと、実行層のEIP-8141 Frameトランザクション。

それらは、トランザクションライフサイクルにおける2つの重要な課題を処理します：条件を満たすトランザクションがブロックに含まれるかどうか、およびアカウントがどのようにしてトランザクションを検証して実行するかです。

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

現在、プロのブロックビルダーがブロック生成を主導しています。この役割分担はブロック構築の効率を向上させますが、ブロック生成が長期的に少数のビルダーに集中すると、彼らは強いトランザクション選別能力を獲得する可能性があります。そのため、FOCILは通常のブロック構築プロセスに加えて、バリデーターによる採用制約を追加しています。

FOCILの設計によると、各スロットには「納入リスト委員会」（IL委員会）が構成されます。委員会メンバーは各自が確認した保留中のトランザクションに基づいて納入リストを作成し、それをブロードキャストします。次のスロットのブロック構築者は、これらのリストを収集し、ブロックを構築する際に実行条件を満たすトランザクションを含めます。新規ブロックの検証を担当するバリデーターは、自らが適時に受信した納入リストを保存し、ブロックが関連する要件を満たしているかを確認します。

ブロックに正当な理由なく、バリデータが保存したトランザクションのリストが含まれていない場合、プローバーはそのブロックに投票しません。このようなブロックは、実行レベルでは有効であっても、規範チェーンへの入場に必要なコンセンサスを獲得できません。これがFOCILの意義です：委員会メンバーがブロックを直接変更するのではなく、バリデータが投票するかどうかによって、ブロック構築者の選択を制約します。

対応するEIP-8369は、FOCILの強制的適用保障を受けるのに適した取引をさらに詳細に説明しています。通常の取引の見落としの原因は比較的容易に検証できますが、Frames取引はプログラマブルな検証を許可するため、検証コストが高くなります。そのため、読み取れる状態の範囲と検証予算を追加で制限する必要があります。

簡単に言えば、FOCILはバリデーターがブロックビルダーの仕事を奪うのではなく、ビルダーに次のコンセンサス層のルールを追加します：あなたは依然としてブロック内の大部分の取引を配置できますが、委員会がリストアップした適格な取引を合理的な理由なく継続的に無視することはできません。

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

現在、大多数の一般 Ethereum アカウントは固定タイプの秘密鍵署名に依存しています。Frames は、新しい署名方式の採用、複数の認証条件の組み合わせ、または他のアカウントによる取引手数料の支払いなど、より柔軟な検証ロジックをアカウントで使用できるようにすることを目的としています。また、署名の集約をサポートし、各署名方式ごとに個別のハードフォークを実施することなく、今後新しい署名方式を導入することも可能にします。

ただし、Frames自体は完全な耐量子署名スキームではなく、Hegotáのローンチ後すぐに既存のキーを置き換えるものではありません。Framesは「暗号アジャリティ」を提供します：将来的に署名スキームを変更する必要が生じた場合、アカウントはプログラム可能な検証を通じて移行でき、特定のキー体系に永続的に縛られることはありません。

Frames には、核心的な補完として、さらに2つのA級提案が必要です。EIP-8250 Keyed Nonces は、同一送信者が互いに独立したnonceチャネルを使用できるようにし、異なるトランザクションが厳密な順序を共有することによるブロッキングを回避します。EIP-8272 は、トランザクションが検証者が確認可能な最近のチェーン上の状態を使用できるようにし、関連するプライバシートランザクションにもFOCILが提供する含入保証を可能にします。

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

S級提案はHegotáのメインラインを定義していますが、A級提案の複数項目も、イーサリアムの将来のアカウントセキュリティ、量子耐性移行、実行証明、リソース評価に影響を与えます。

まずEIP-8365です。これは、十分な強度の量子攻撃に対して安全性を失う可能性のある暗号技術に依然として依存している一部のBLS引き出し認証情報に対して、段階的な脱退を開始する計画です。プロトコルチームは、完全な量子耐性コンセンサス設計が確定するのを待たずに、この移行を早期に開始できると判断しています。

アカウントセキュリティにおいて、EIP-7906、EIP-8298、およびEIP-8151はFramesの拡張コンビネーションと見なされます。

EIP-7906は、トランザクションの最終提出前に指定された結果が発生しているかを検証するトランザクションアサーションメカニズムを導入します。このメカニズムは、悪意のあるコントラクトによるウォレット資産の吸い上げや、一部のMEV行為による損失を軽減することを目的としています。ただし、この提案の具体的な読み取り範囲は現在も研究・限定中であるため、現在の設計を確定済みの最終仕様として固定することはできません。

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

これらの二つの提案を組み合わせることで、アカウントはようやく古い secp256k1 鍵を最高制御権限として使用することを真正に停止し、旧鍵体系からの脱却に向けた完全なパスを構築できます。

EIP-8025（オプション実行証明）は、今後のzkEVMロードマップに関連しています。この仕様は、オプション実行証明に必要な変更を統一実行仕様に組み込むことで、異なるzkVMプロジェクトが長期的に互いの分岐バージョンを維持する問題を軽減することを目的としています。

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

EIP-3298は、ガス返金メカニズムを完全に削除し、計測、実装、テストにおける特殊ケースを減らすことを目的としています。EIP-5920（PAYオペコード）は、受信側のコードを実行せずにETHを転送できるようにし、「価値の転送」と「コントラクトの呼び出し」を明確に分離します。

一方で、注目されているいくつかの提案は依然としてB級にとどまっています。

たとえば、EIP-8198（Quick Slots）はスロット時間を短縮することを目的としていますが、プロトコルチームは、核心プロトコル変更の仕様、完全なプロトタイプ、下流への影響評価を完了し、後続のコンセンサス分離設計に干渉しないことを証明するよう求めています。その理由は、スロット時間がブロック生成速度だけでなく、ネットワーク伝播、コンセンサス判断、およびアプリケーションの時間に対する仮定にも影響を与えるためです。

また、EIP-8368 および EIP-8372 は「TBD」（未定）としてリストされています。これらの提案はガス制限とステートリソースの評価に関係しており、プロトコルチームは、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