Ethereumバリデーター向けポスト量子公開鍵レジストリの設計空間を探る

原文

Exploring the Design Space for a Post-Quantum Public Key Registry for Ethereum Validators — tcoratger (2026-06-01)

著者: Thomas Coratger, Tom Wambsgans, Ladislaus, Thomas Thiery, Justin Drake

Strawmapロードマップに概説されているように、大規模な量子コンピューターの差し迫った脅威からイーサリアムを保護することは最優先事項です。この移行における重要なマイルストーンは、プルーフ・オブ・ステーク (Proof-of-Stake) コンセンサスをBLS署名からポスト量子 (PQ)セキュアな署名スキームに移行することです。

この記事は、ポスト量子公開鍵レジストリの概念と設計空間を探求することを目的としています。重要なのは、実際の移行は段階的に行われることです。まず公開鍵レジストリのフォークが発生し、バリデーターがPQ鍵を登録できるようになります。その後、数回のフォークを経て実際の署名切り替えが行われます。この段階的な展開により、ネットワークは状態を構築し、脆弱性を監視し、基盤となる暗号プリミティブを最終決定するための十分な時間を確保できます。最終的に、ここで生成された議論は正式なEIP（Ethereum 改善提案）へと成熟するでしょう。

歴史的背景とレジストリの必要性

現在のプルーフ・オブ・ステーク設計では、バリデーターの公開鍵 (BLS12-381) は実行層のデポジットコントラクトを介して登録され、その後コンセンサス層によって処理されます。BLS署名は集約において非常に効率的ですが、ショアのアルゴリズム (Shor’s algorithm) によって完全に破られる楕円曲線暗号 (elliptic curve cryptography) に依存しています。

ポスト量子署名への移行は、ネットワーク参加者にとって運用上の大きな困難をもたらします。これらの新しい鍵を生成し、安全に保管するには、バリデーターがコールドストレージ (cold storage) にアクセスし、新しい鍵生成スクリプトを実行し、最も機密性の高い暗号マテリアルとやり取りする必要があります。これは摩擦が大きく、リスクの高い運用上の操作であるため、これらの鍵の登録とコンセンサスでのアクティブな使用を分離する予定です。専用の公開鍵レジストリは、重要なウォームアップフェーズとして機能し、バリデーターがハードウェア設定を安全に管理し、実際のプロトコルアップグレードよりもかなり前にポスト量子アイデンティティに徐々にコミットするための低圧環境を提供します。

パート1：基盤 — 暗号学的コア：eXtended Merkle Signature Scheme (XMSS)

ポスト量子デジタル署名を探求する際、暗号コミュニティは一般的に設計空間をいくつかの主要なファミリーに分類します：格子ベース、コードベース、アイソジェニーベース、多変数、およびハッシュベースです。格子ベース署名 (例：LaBRADORのような証明システムを介したFalcon署名の集約) のようなソリューションは盛んに研究されていますが、それらの安全なパラメータを選択することは非常に複雑であり、そのセキュリティ証明はポスト量子設定における不確実な意味合いを持つ技術に依存することがよくあります。

最終的に、ハッシュベース署名がイーサリアムにとって最も強力な候補として浮上します。それらは、概念的なシンプルさ、実装の容易さ、および複雑な代数構造ではなく、非常に保守的な標準モデルの暗号学的仮定 (基本的な衝突耐性および原像耐性など) への依存により際立っています。

ハッシュベース署名には2つの主要な課題があります。それらはネイティブに集約をサポートせず、鍵の再利用を防ぐために厳密な状態管理を必要とします。集約の問題は暗号学的証明によって別途解決する必要がありますが、イーサリアムのプルーフ・オブ・ステークコンセンサスの構造化された性質は、後者にとって大きな利点をもたらします。バリデーターはエポックごとに正確に1回署名する必要があります。

この厳密なタイムラインにより、完全にステートレスなスキーム (SPHINCS+のように検証時に約10倍のハッシュを必要とする) のかなりの検証オーバーヘッドを回避し、代わりに同期された (ステートフルな) 署名スキームを活用できます。[eXtended Merkle Signature Scheme (XMSS)]は、各署名を特定のシーケンシャルな位置に結び付けることで、このモデルに完全に適合します。XMSSでの二重署名は、攻撃者がそのリーフの署名を偽造するのに十分な中間ハッシュ情報を漏洩させることで鍵を破ることに注意してください。

XMSSの仕組み

XMSSがなぜこれほど効果的なのかを理解するには、ハッシュ関数の基本的な特性から始めて、その構築を段階的に分解することが役立ちます。

構成要素：ハッシュチェーン

暗号学的ハッシュ関数は一方向性 (原像耐性) であるため、出力から入力を簡単に推測することはできません。ハッシュチェーンは、秘密の開始値 (秘密鍵) を取り、それを所定の回数繰り返しハッシュして最終値 (公開鍵) を生成することで、これを活用します。

ハッシュチェーンが256ステップある場合、ステップ100で中間ハッシュを公開することは、秘密を知っていることを証明します。なぜなら、検証者はその値をさらに156回ハッシュするだけで、公開鍵と一致するかどうかを確認できるからです。これがワンタイム署名 (One-Time Signature, OTS) の基礎です。メッセージに署名するには、メッセージを数値 (例：100) に変換し、チェーン内のその特定の位置のハッシュを公開します。

セキュリティのための並列チェーン

単一のハッシュチェーンには致命的な脆弱性があります。メッセージに署名するために位置100のハッシュを公開した場合、攻撃者はあなたの署名をもう一度ハッシュするだけで、位置101にマッピングされるメッセージの署名を偽造できてしまいます。

この偽造を防ぐため、スキームはメッセージを複数の小さなチャンクに分割し、各チャンクに並列ハッシュチェーンを使用し、厳密な数学的制約であるターゲット合計を強制します。署名が有効であるためには、すべてのチャンク値 (チェーン位置) の合計が特定の所定の数値と等しくなければなりません。

この制約のため、攻撃者が1つのチェーンを前方にハッシュして (数値が増加する) 署名を偽造しようとすると、偽造された署名の合計がターゲットを超えてしまいます。合計を再調整して有効なエンコーディングを生成するには、攻撃者は別のチェーンの値を減らすことを余儀なくされます。値を減らすには、チェーンを逆方向に移動する (ハッシュ関数を反転する) 必要があります。暗号学的ハッシュ関数は厳密に一方向性 (原像耐性) であるため、この逆方向への移動は計算上不可能であり、W-OTS署名は完全に安全になります。

偽造試行の分析

署名ベクトル	チェーン 0 (m_0’)	チェーン 1 (m_1’)	チェーン 2 (m_2’)	チェーン 3 (m_3’)	ターゲット合計
オリジナル	2	3	3	1	9
偽造	3	2 (ドロップ)	3	1	9

攻撃が失敗する理由

最初のチェーンを前方に偽造する (2 \rightarrow 3) には、攻撃者は公開された値をもう一度ハッシュするだけです。しかし、これにより合計が10に増加し、プロトコルの厳密なターゲット制約に違反します。

必須のターゲット合計9を維持するため、攻撃者は別のチェーンの値を減らす (3 \rightarrow 2) ことを余儀なくされます。暗号学的ハッシュ関数は厳密に一方向性 (原像耐性) であるため、チェーンを逆方向に移動して値を減らすことは計算上不可能であり、偽造された署名は無効になります。

多回署名へのスケーリング

これらの中間ハッシュを公開すると、本質的にチェーンが消費されるため、この設定は安全に一度だけ使用できます。バリデーターのライフサイクル中に何千ものブロックに署名するには、多回署名スキームが必要です。

XMSSは、独立したワンタイム署名鍵ペアの巨大なシーケンスを生成することでこれを解決します。これらすべてのOTSインスタンスの公開鍵は、巨大なマークルツリー (Merkle tree) のリーフとして配置されます。このマークルツリーのルートが、バリデーターの実際のグローバル公開鍵となります。これが、公開鍵レジストリに提出される小さくコンパクトなデータポイントです。

署名と検証のプロセス

バリデーターが特定のスロットのブロックに署名する必要がある場合、ツリー内の次に未使用のリーフに移動します。最終的な署名には以下が含まれます。

1. 現在のメッセージに対するOTS署名。
2. そのリーフの特定のOTS公開鍵。
3. そのリーフをグローバルマークルルートに接続するマークル認証パス (Merkle authentication path) (兄弟ハッシュ)。

検証者は、OTS署名をOTS公開鍵に対してチェックし、マークルパスを検証して、その特定のリーフがバリデーターの登録されたルートの正当な一部であることを確認します。

登録されるもの：鍵サイズと実用的な影響

XMSSの概念設計を理解したところで、レジストリにとって当然の疑問は、バリデーターが正確に何を提出する必要があり、そのサイズはどれくらいかということです。

公開鍵：52バイト

各バリデーターのXMSS公開鍵は2つの部分で構成されます。

コンポーネント	サイズ	説明
マークルルート	32バイト	バリデーターのXMSSマークルツリーのルートハッシュ。この単一の値は、すべての2^{32}個のワンタイム署名リーフにコミットします。検証者が個々の署名がこのバリデーターに属するかどうかを確認するためにチェックする必要がある唯一のものです。
公開パラメータ	20バイト	鍵作成時に一度だけ生成されるランダム値。すべてのハッシュ計算 (ツリーノード、チェーンステップ、メッセージハッシュ) に混合され、2つの主要な役割を果たします。厳密な標準モデルのセキュリティ証明に不可欠であり、攻撃者がブルートフォース攻撃を試みる際に複数のバリデーターを並行して攻撃できないように、ユーザー間のドメイン分離を提供します。
合計	52バイト

比較として、BLS12-381公開鍵は48バイトです。ポスト量子公開鍵はわずか4バイト大きいだけであり、レジストリのバリデーターごとのストレージオーバーヘッドが無視できるレベルであることを示す驚くべき結果です。大規模な場合、100万人のバリデーターを登録するには、ステートに約52 MiBの公開鍵を保存するだけで済みます。

署名：3,112バイト

各スロットごとのXMSS署名には以下が含まれます。

コンポーネント	サイズ	説明
マークル認証パス	1,024バイト	使用されたリーフからマークルルートまでのパスを再構築するために必要な兄弟ハッシュのリスト。ツリーは32レベルなので、32個の兄弟があり、それぞれ32バイトです。検証者はこのパスを再ハッシュし、結果が公開鍵ルートと一致するかどうかをチェックします。
エンコーディングのランダム性	28バイト	ターゲット合計エンコーディングを生成するためにメッセージハッシュに混合される、署名ごとのランダム値。署名者が必要なターゲット合計に達するまで再サンプリングすることを可能にしますが、その主な目的はセキュリティです。このランダム性がなければ、スキームは64ビットのセキュリティしか提供せず、エンコーディングが誕生日攻撃に対して脆弱になります。
チェーンハッシュ値	2,048バイト	署名者によって公開される64個の中間ハッシュチェーン値 — 並列チェーンごとに1つ。各値は、エンコードされたメッセージチャンクに対応するチェーン内のポイントです。検証者は、この公開された値からチェーンエンドポイントまで各チェーンを前方にたどり、マークルリーフとの一貫性をチェックします。
合計	3,112バイト

これはBLS署名 (96バイト) よりも大幅に大きく、SNARKsによる集約が不可欠である理由です (次セクションを参照)。

秘密鍵：コンシューマーハードウェアで管理可能

素朴な実装では、2^{32}個のリーフを持つ完全なマークルツリーを一度に計算して保存する必要があり、テラバイト単位のストレージと膨大なメモリが必要になります。代わりに、このスキームの参照実装では、トップボトムツリー戦略を使用しています。巨大なツリーを上半分のツリー (高さ16) と2^{16}個の下半分のツリー (それぞれ高さ16) に分割します。

これにより、鍵生成と署名の空間計算量は $\mathcal{O}(\sqrt{\text{lifetime}})$ に低下し、数メガバイトのRAMとディスクスペースしか必要としません。バリデーターは構造全体を保持する代わりに、トップツリーと、現在のボトムツリーと次のボトムツリーの2つのボトムツリーのスライディングウィンドウのみをキャッシュします。次のツリーをキャッシュすることは実用上不可欠です。これにより、現在のボトムツリーが使い果たされたときに (約65,536スロットごと、つまり約9日ごと)、アテステーションを逃すことなくシームレスな移行が保証されます。

重要なことに、これらのキャッシュされたツリー構造は暗号学的に機密ではありません。 それらは単にグローバルマークルルートにつながる中間公開ハッシュです。標準ディスクにプレーンテキストで保存できます。唯一の実際の暗号学的秘密は32バイトのPRFシードです。

なぜKoalaBearなのか？

スキーム内のすべての算術演算は、KoalaBear素体上で、以下のモジュラスで行われます。

p = 2^{31} - 2^{24} + 1

これは31ビットの素数であり、各体要素が単一の32ビットワード (4バイト) に収まることを意味します。小さな体を選択することは意図的であり、パフォーマンスにとって重要です。XMSSスキームとSNARKアグリゲーターの両方が体演算によって支配されるため、すべての乗算と加算は可能な限り高速である必要があります。

31ビット素数には3つの主要な利点があります。

• SIMD並列処理: 4バイト要素はCPUベクトルレジスタに密にパックされます。x86プロセッサでは、AVX2命令は8つの体要素を並列に処理でき (256ビットレジスタ)、AVX512は16個を一度に処理できます (512ビットレジスタ)。ARMプロセッサ (Apple Siliconを含む) では、NEON命令がベクトルあたり4つの要素を処理します。これは、単一のCPU命令で4〜16個の体乗算を同時に実行できることを意味します。
• オーバーフローのリスクなし: 2つの31ビット値を乗算すると、最大で62ビットの結果が生成され、これは64ビットレジスタに快適に収まります。これにより、多倍長演算 (multi-precision arithmetic) やキャリー伝播の必要がなくなり、モジュラー還元 (modular reduction) が自明になります。
• 高い2-adic性: 乗法群の位数は $p-1=2^{24}\times 127$ であり、2-adic性 (two-adicity) は24です。一見小さいように見えますが、これはインターリーブされたリード・ソロモン符号 (Reed-Solomon codes) を利用する際のWHIRのような多線形多項式コミットメントスキーム (multilinear polynomial commitment schemes) の制限要因ではありません。さらに、次数5の拡大体 (${\mathbb{F}}_q$ where $q=p^5$) での演算は、WHIRに必要な128ビットのセキュリティを提供します。

生の算術速度を超えて、KoalaBearは特に、立方体マップ $x\mapsto x^3$ が乗法群の置換であるため選択されました。これは $\gcd (3,p-1)=\gcd (3,2^{24}\times 127)=1$ であるため成り立ちます。この特性はPoseidonにとって重要です。ハッシュ関数には、体上の置換多項式であるS-box (非線形置換層) が必要です。立方体マップはすでに置換であるため、S-boxは次数3を使用できます — これは可能な限り最小です。次数が低いS-boxは、ラウンドあたりの乗算回数が少ないことを意味し、これは直接的にハッシュの高速化とSNARK回路内の制約の削減につながります。比較として、BabyBear ($p=2^{31}-2^{27}+1$) のような他の体は次数7のS-boxを必要とし、BN254ベースのPoseidonは次数5を使用します。

次数3のS-box、高い2-adic性、およびSIMDフレンドリーな要素サイズの組み合わせにより、KoalaBearはこのワークロードに非常に適した体となっています。

本番スキームのパラメータ

以下の表は、これまでの開発ネットワーク (devnet)で使用されてきた完全な本番構成を示しています。分かりやすくするために、パラメータはシステムが制御する部分ごとにグループ化されています。

ライフタイムとメッセージ

これらのパラメータは、鍵の全体的なスコープと、それが何を署名するかを定義します。

パラメータ	値	説明
鍵のライフタイム	2^{32} スロット (12秒スロットで約1632年)	単一の鍵が使用できるスロットの総数。各スロットはマークルツリーのリーフを1つ消費するため、ツリーには2^{32}個のリーフがあります。
メッセージ長	32バイト	署名されるデータのサイズ。実際には、これはアテステーションまたはブロックデータのハッシュであり、常に正確に32バイトです。

メッセージエンコーディング (メッセージがチェーン位置になる方法)

上記のXMSS概要から、メッセージに署名することはハッシュチェーンの中間値を公開することを意味することを思い出してください。しかし、まずメッセージは、署名者に各チェーンのどこで公開するかを指示する一連の数値に変換されなければなりません。この変換はエンコーディングと呼ばれ、これらのパラメータがその仕組みを制御します。

メッセージは、いくつかの新しいランダム性と一緒にハッシュされ、46個の数値 (チェーンごとに1つ) を生成します。各数値は0から7の間です。これらの数値はチャンク値です。特定のチェーンのチャンク値は、署名者にそのチェーンの秘密の開始点から何ステップ進んで値を公開するかを指示します。検証者は、残りのステップをチェーンエンドポイントまで進みます。最大チェーン長が7の場合、チャンク値が5ということは、署名者が5ステップ目で値を公開し、検証者が残りの2回 (7 - 5) ハッシュしてエンドポイントに到達することを意味します。

重要なセキュリティ制約はターゲット合計です。46個のチャンク値の合計が正確に200でなければ、エンコーディングは有効ではありません。これが偽造防止 (比較不能性) メカニズムです。攻撃者が署名を見た後、公開された値を前方にハッシュすることしかできない (チャンク値が増加する) ため、合計を200に保つには他のチャンクを減らす必要があります。チャンクを減らすことはハッシュを反転することを意味し、これは計算上不可能です。固定された合計とチェーンの一方向性が偽造を防ぎます。

46個のチャンク値が一様にサンプリングされた場合、その期待される合計は約161 (46 × 3.5) になります。ターゲットの200は意図的にこの平均よりも高く設定されています。検証者は各チェーンの残りのステップしか進まないため、ターゲット合計が高いほど検証時のハッシュ評価が少なくなります。ここでは、合計で122個のチェーンハッシュ (ターゲットが平均値だった場合は161個) です。チャンク値を最初から一様にするために (ターゲットが予測可能にヒットするように)、メッセージハッシュはアボーティングハイパーキューブ構築を使用します。これはハッシュ出力を拒否サンプリングし、出力要素が一様範囲外に落ちるたびに破棄して再ハッシュします。署名者はその後、新しいランダム性を引き出し、46個の値が正確に200になるまで再エンコードします (最大100,000回の試行)。実際には、有効なエンコーディングはその範囲内で十分に見つかります。

注：署名集約のためのSNARKコンテキストでこれらのハッシュ関数を最適化することは非常に活発な研究分野であるため、正確な基盤となるエンコーディングアルゴリズムは変更される可能性があります。以下のパラメータは現在の作業構成を表していますが、暗号技術がメインネット向けに最終決定されるにつれて、特定の値は進化する可能性があります。

パラメータ	値	説明
並列ハッシュチェーンの数	46	メッセージは46個の独立したチャンクにエンコードされ、チェーンごとに1つです。チェーンが多いほどセキュリティは高まりますが、署名は大きくなります。
チェーンごとのアルファベットサイズ	8	各チャンク値は0から7の間です (つまり、基数8)。これにより、単一チェーンの最大深度が決まります。
最大チェーン長	7ステップ	チェーンに沿って可能な最長のウォーク (アルファベットサイズから1を引いた数)。署名者と検証者は合わせて、チェーンごとに7回を超えるハッシュ評価を行うことはありません。
ターゲット合計	200	エンコーディングが有効であるためには、46個のチャンク値の合計が正確にこの数値でなければなりません。これは偽造防止 (比較不能性) メカニズムです。
最大エンコーディング試行回数	100,000	署名者が有効なエンコーディングを見つけるために異なるランダム性を試行する回数の上限。
エンコーディングのランダム性	7体要素 (28バイト)	各試行でメッセージハッシュに混合される新しいランダム値。検証者がエンコーディングを再現できるように署名に含まれます。
メッセージ体要素長	9体要素 (36バイト)	体要素として再エンコードされ、ランダム性および公開パラメータとともにメッセージハッシュに供給される32バイトのメッセージ。

ハッシュ関数と内部サイズ

これらのパラメータは、スキーム全体で使用されるハッシュ関数を制御します。すべてのサイズは体要素で表されます。各KoalaBear体要素は4バイトなので、4を掛けるとバイト単位のサイズが得られます。

パラメータ	値	説明
内部ハッシュ関数	KoalaBear上のPoseidon1 (幅24および幅16)	すべてのツリーハッシュ、チェーンハッシュ、およびメッセージハッシュに使用される、算術化に適した置換 (arithmetization-friendly permutation)。ツリーノードのマージとメッセージハッシュスポンジには幅24 (24個の体要素を一度に操作) で実行され、単一の値を圧縮するだけでよいステップごとのチェーンハッシュには幅16で実行されます。
メッセージハッシュスポンジレート / キャパシティ	レート15 / キャパシティ9	メッセージハッシュは幅24の置換をスポンジ構造 (sponge) として実行します。24個のステート要素のうち15個が入力/出力データ (レート) を運び、残りの9個がドメイン分離 (キャパシティ) のために予約されています。ツリーとチェーンのハッシュはスポンジとしてではなく、圧縮モードで実行されます。
ハッシュダイジェスト長	8体要素 (248ビット)	各ハッシュ呼び出しの出力サイズ。すべてのツリーノード、チェーンエンドポイント、およびメッセージハッシュは248ビットです。これは、約128ビットの古典的セキュリティと64ビットの量子セキュリティを目標としています。
公開パラメータ長	5体要素 (20バイト)	公開鍵の一部であり、バリデーター間の独立性を確保するためにすべてのハッシュに混合される、バリデーターごとのランダム値。
スポンジキャパシティ	9体要素	幅24のPoseidon1スポンジステートのうち、ドメイン分離のために予約された部分。呼び出しごとの調整と組み合わせることで、ハッシュの異なる用途 (ツリーノード、チェーンステップ、メッセージハッシュ) がコンテキスト間で衝突しないようにします。

ツリー構造と鍵導出

パラメータ	値	説明
マークルツリーの高さ	32レベル (16トップ + 16ボトムに分割)	ツリーには2^{32}個のリーフがあります (スロットごとに1つ)。高さ16のトップツリーと、それぞれ高さ16の多数のボトムツリーに分割され、一度にメモリに保持する必要があるのは2つのボトムツリーだけです。
鍵導出PRF	SHAKE128 (256ビット鍵)	すべての秘密マテリアル (チェーン開始値、署名ごとのランダム性) は、SHAKE128を使用して単一の32バイトマスターシードから決定論的に導出されます。これは、バリデーターが32バイトの値を1つだけバックアップすればよいことを意味します。

leanVMとpqSNARKsによる署名集約

ハッシュベース署名は、BLSで享受している公開集約機能をネイティブにサポートしていません。約100万人のバリデーターがそれぞれ約3.1 KiBの署名をブロードキャストすると、アグリゲーターの帯域幅要件はスロットあたり3 GiBを容易に超え、イーサリアムのスロット制約では全く実現不可能です。

解決策は、これらの同期された多回署名を簡潔な知識の引数 (a pqSNARK) を使用して集約することです。これをエレガントかつ効率的に処理するために、イーサリアムのポスト量子署名検証のために特別に設計された最小限のCairo風zkVMであるleanVMを利用します。leanVMは、AIR固有の最適化を施したSuperSpartan、バスインタラクションのためのLogup、および多線形多項式コミットメントのためのWHIRを利用する高度に最適化された証明スタック上に構築されています。決定的に重要なのは、WHIRが単純な多項式スタッキングを可能にし、各個別の列にマークルコミットする必要を回避し、最終的な証明サイズを大幅に削減することです。

leanVMは、1つの巨大な回路で大量の署名を同時に検証する代わりに、再帰的集約 (recursive aggregation)を使用します。プロトコルは署名者を管理可能なグループに分割し、アグリゲーターはXMSS署名を検証してサブ証明を作成し、その後、プログラム内でleanVM検証者を再帰的に実行してこれらのサブ証明を単一の最終証明にマージします。

コンセンサス層は、報酬、非活動リーク (inactivity leaks)、フォーク選択の重み、スラッシングを処理するために、誰が参加したかを正確に知る必要があるため、集約ペイロードにはleanVM証明と署名者ビットフィールド (現在のBLSアテステーションで使用されているビットリストに類似) の両方が含まれます。leanVM回路は、この付随するビットフィールドによって示される公開鍵の正確なサブセットに対して有効な署名が存在することを証明するように明示的に制約されています。

ハイエンドのコンシューマーハードウェア (例：M4 Max CPU) で実行された最近のベンチマークに基づくと、leanVMは毎秒約1kのXMSS署名の証明スループットを達成します。その証明されたセキュリティ体制 — KoalaBear体の次数5の拡大を介して123ビットの証明可能なセキュリティを提供 — では、2対1の再帰証明の生成には1秒未満しかかからず、PCSレートに応じて約128 KiBから350 KiBの非常にコンパクトな最終証明サイズになります。この再帰的アプローチはうまくスケーリングし、イーサリアムのスロット予算にとってオンチェーン検証とネットワーク伝播を非常に実用的なものにします。

ハッシュ関数：オープンな設計空間

検証プロセスはハッシュ関数評価によって支配されるため、pqSNARKアグリゲーターの効率は選択されたハッシュ関数に大きく依存します。

当初、Poseidon2が主要な候補として浮上しました。これは有限体上でネイティブに動作するため、leanVMのような最新の算術化フレームワークやzkVMに高度に最適化されています。しかし、代数ハッシュ関数を標的とした最近の暗号解読 (cryptanalysis) および攻撃手法 (eprint 2026/306に詳述されているものなど) により、Poseidon2のみに依存することを再考せざるを得なくなっています。

最終的な決定が下されていないため、公開鍵レジストリの設計は柔軟である必要があります。これに対応するため、さまざまなハッシュ関数を使用して公開鍵の生成を許可する可能性があります — これはマルチハッシュ公開鍵レジストリと呼ばれる設計です。

現在のハッシュ候補

ハッシュ関数	算術化効率	暗号解読の成熟度
SHA / BLAKE3	低 (重いビット演算)	高 (非常に実証済み)
Poseidon1	高 (SNARKフレンドリー)	中 (継続的な分析の対象)
Poseidon2	非常に高 (最新の体向けに最適化)	低 (最近の攻撃が懸念を提起)

これはレジストリの設計に直接影響します。レジストリは*ハッシュ関数アジャイル (hash-function-agile)*である必要があり、各公開鍵とともにハッシュ関数識別子を保存して、ネットワークが移行中に複数のハッシュ関数をサポートし、いずれかが非推奨になった場合に移行を義務付けることができるようにする必要があります。

パート2：レジストリ設計の考慮事項

登録プロトコルのメカニズム

登録プロトコル自体は、ビーコンチェーンを圧倒することなく、スムーズで安全かつシビル耐性 (sybil-resistant) のある移行を確実にするための具体的なメカニズムを必要とします。このアップグレードはバリデーターのアイデンティティを根本的に変更するため、鍵登録のライフサイクルは慎重に管理されなければなりません。以下に、バリデーターが実際に鍵を登録する方法の提案アーキテクチャを示します。

• 配信と承認: ポスト量子アイデンティティを既存のバリデーターに安全にバインドするには、配信メカニズムは新しいコンセンサス層の操作 (例：PostQuantumRegistrationメッセージ) を利用する可能性が高いです。この提出は、バリデーターインデックスの明確な所有権を証明するために明示的に承認される必要があります。0x01または0x02の実行層出金クレデンシャル (withdrawal credentials) を持つバリデーターの場合、これはL1の出金アドレスからの署名を伴います。レガシーな0x00クレデンシャルの場合、現在アクティブなBLS鍵からの署名が必要になります。決定的に重要なのは、この登録メッセージには所有証明 (Proof of Possession) — 登録ペイロードに対する単一の有効なXMSS署名 — も含める必要があることです。これがなければ、プロトコルは52バイトの生データを盲目的に受け入れてしまい、サイレントに壊れた鍵生成設定を持つバリデーターは、実際の署名フォークが数年後に発生するまでその失敗を発見できないでしょう。両方の署名が検証されると、ネットワークは52バイトのXMSS公開鍵を受け入れ、ビーコンステートのバリデーターレコードにバインドします。ハッシュ関数アジリティをサポートするため、このバインディングは永続的ではありません。登録メッセージには、バリデーターが将来鍵を更新またはローテーションできるように、シーケンス番号またはバージョンフィールドを含めるべきです。

• ブロックごとの処理上限とステートの成長: 大量登録イベント中のステート肥大化 (state bloat) や計算スパイク (computational spikes) からネットワークを保護するため、プロトコルは厳密な処理キューを強制する必要があります。既存のバリデーターアクティベーションおよび退出チャーン制限 (churn limits) と同様に、スロットごとに処理される登録の数に上限を設けることを提案します (例：MAX_PQ_REGISTRATIONS_PER_BLOCK = 16)。ゴシップネットワーク (gossip network) にブロードキャストされた登録はローカルメモリプール (memory pool) に留まり、ブロックプロポーザー (block proposers) は最大制限までブロックに詰め込みます。これにより、ブロック検証時間が予測可能に低く保たれ、結果として生じるステートの成長が数週間または数ヶ月にわたって平滑化され、ノードリソース要件の突然の急増が防止されます。

• インセンティブと移行タイムライン: 段階的なロールアウトの大きなリスクは、BLS署名が正式に非推奨になる直前の土壇場での殺到であり、処理キューを圧倒し、アクティブなバリデーターが署名できなくなり、ネットワークファイナリティ (network finality) を脅かす可能性があります。これを避けるため、ロールアウトには早期行動を促すメカニズムが組み込まれます。初期のウォームアップフェーズに参加するバリデーターには、最終的なポスト量子アクティベーションキューで優先的な配置が与えられる可能性があります。あるいは、早期登録者に対するアテステーション報酬の控えめな一時的増加 (例：基本報酬のわずかな乗数) が、効率的に採用を促進する可能性があります。最後に、最終期限 (hard deadline) が近づくにつれて、プロトコルは非活動リークを徐々に適用したり、ポスト量子鍵を登録できなかったバリデーターに対して強制退出 (forced exits) を開始したりする「スティック」アプローチを採用し、最終的なスイッチが切り替わる前にアクティブなセットがPQ対応ノードのみで構成されるようにすることができます。

ハッシュ関数アジリティ

ハッシュ関数がまだ最終決定されていないため、レジストリはアジリティを念頭に置いて設計する必要があります。1つのアプローチは、バリデーターが異なるハッシュ関数識別子で鍵を登録できるようにすることです。つまり、各レジストリエントリは52バイトの公開鍵と、選択されたハッシュ関数を示すタグを保持します。後で関数が侵害された場合、影響を受けるバリデーターは再登録を要求されます。あるいは、将来の再登録の摩擦なしに堅牢な将来性を確保するために、プロトコルは最初から2つまたは3つの特定のハッシュ候補 (例：Poseidon1、BLAKE3、SHA-256) の使用を強制することもできます。このシナリオでは、すべてのバリデーターが各義務付けられたハッシュ関数に対して事前に鍵生成を実行し、レジストリにコミットされる最終値は、これらの複数のXMSS公開鍵の連結になります。

鍵生成と登録が前倒しで行われるため、1つのハッシュ関数が侵害された場合でも、バリデーターが鍵を最初から再生成する必要なく、ネットワークは迅速に代替手段に切り替えることができます。このアプローチは優れた将来性を提供しますが、わずかなトレードオフがあります。登録される鍵のサイズが52バイトから104〜156バイトに増加します。幸いなことに、鍵生成の計算オーバーヘッドは最小限です。従来のビット単位のハッシュ関数 (SHA-256、BLAKE3、Monolithなど) は、Poseidonのような代数ハッシュよりも標準CPUでの計算が桁違いに速いため、これらのバックアップツリーの生成は、ベースラインの鍵生成プロセスにわずかな時間しか追加しません。最終的に、ストレージと計算のこのわずかな増加は、それが提供するシームレスなアジリティにとって非常に許容できるトレードオフです。これら2つの解決策は、それぞれに利点と欠点があり、さらなる探求が必要です。

鍵のライフタイムとアクティベーションウィンドウ

XMSS鍵は、本質的に明示的なアクティベーションウィンドウ (activation window) — 開始スロットとマークルツリーの容量によって決定される有限数のアクティブスロット — を伴って生成されます。暗号学的構成が各署名を特定のシーケンシャルな位置に結び付けるため、鍵はこのウィンドウ外のメッセージに署名することは自然にできません。したがって、これらの境界をレジストリに明示的に記録したり、プロトコルレベルで強制したりする必要はありません。バリデーターが利用可能なリーフを使い果たすと、有効な署名を生成する能力を失うだけです。

メモリ効率のため、アクティベーションスロットは65,536スロット (約9日) の境界に揃えられます。これはバリデーターにとって透過的であり、鍵生成ツールが自動的にアライメントを処理します。

シリアライゼーション

すべてのデータ構造は、イーサリアムのコンセンサス層の標準シリアライゼーション形式であるSSZ (Simple Serialize) を使用します。公開鍵は固定サイズの52バイト値であるため、現在のBLS鍵とともに既存のビーコンステートバリデーターレコードに含めるのは簡単です。

バリデーターにとっての実践的考慮事項

ポスト量子鍵の登録は1回限りの操作ですが、巨大なマークルツリーの生成と、結果として生じるマテリアルの安全な保管を伴います。今日の操作と比較して、バリデーターが実際に期待すべきことは以下の通りです。

• 鍵生成は計算負荷が高いがメモリは軽い: バリデーターはオフラインツールを実行し、32バイトのシードを完全なXMSSツリーに展開します。ツリーには2^{32}個のリーフがあるため、これは数十億回のハッシュ評価を伴います。参照実装は、SIMD最適化を使用して利用可能なすべてのCPUコアでこれを並列化します。このプロセスは最新のマルチコアマシン (例：8-16コア) で数時間かかりますが、トップボトムツリー戦略のおかげで、$\mathcal{O}(\sqrt{\text{lifetime}})$ の空間で動作します。これは、数メガバイトの空きRAMがあれば、標準的なマシンで鍵を生成できることを意味します。マスターシークレットが関与するため、この1回限りの操作はエアギャップ (air-gapped) またはコールドストレージマシン (cold-storage machine) で行われなければなりません。
• 秘密鍵と運用鍵: 今日、暗号化されたBLSバリデーターキーストアは約1キロバイトです。PQ時代には、実際の暗号学的秘密 (32バイトのPRFシード) は依然として小さく、厳重に保護され、バックアップされる必要があります。これを失うことは、署名能力を失うことを意味し、回復は不可能です。しかし、運用鍵ファイル (operational key file) — 高速で軽量な署名のために非秘密のトップツリーと現在のボトムツリーペアをキャッシュするもの — はSSZ形式でシリアライズされ、数十メガバイト程度になります。BLS鍵よりも大幅に大きいですが、この運用ファイルはコンシューマーSSDに簡単に収まります。
• 継続的な署名は軽量: 鍵が生成され、運用ファイルが署名インフラストラクチャ (signing infrastructure) にロードされると、各スロットの署名生成には、ほんの数回のハッシュ評価 (最大7ステップの64チェーンをそれぞれたどる、および1回のマークルパスルックアップ) しか必要ありません。これは、12秒のスロット予算内で標準的なコンシューマーハードウェアで楽に実行できるほど高速です。
• コミュニティ主導のツール: 鍵生成のUXを構築するには、最初から強力なステークホルダーの関与 (stakeholder engagement) が必要です。ビーコンチェーンの立ち上げから得られた大きな教訓は、EFのみがdeposit-cliを維持することに依存すると、時間の経過とともにボトルネックになったことです。持続可能なサポート、セキュリティ監査、および機能の反復 (統合 (consolidations) など) を確保するため、PQ鍵生成ツールは、最初からオープンソースのコミュニティ主導の取り組みとして、EF助成金によってインセンティブ付けされることを想定しています。

バリデーターがレジストリに実際に提出するのは、52バイトの公開鍵と単一のXMSS所有証明署名です。これにより、オフライン鍵生成が完全に機能したことがエンドツーエンドで証明されます。この提出は、現在のBLS鍵のデポジットと同様の精神で、標準的なオンチェーントランザクションを介して行うことができます。秘密鍵がバリデーターのマシンから離れることはありません。

未解決の疑問と今後の作業

1. ハッシュ関数の最終決定: Poseidonは継続的な暗号解読に耐えられるか、それともSHA-3/BLAKE3にフォールバックする必要があるか (その場合、証明コストは大幅に増加する)？

2. レジストリ更新メカニズム: バリデーターがハッシュ関数を切り替える必要がある場合、ステートは鍵のローテーションや再登録にどのように対応すべきか？

3. アグリゲーターの経済学: SNARK証明の計算コストは誰が負担するのか？集約はプロトコル報酬 (protocol rewards) によって補償されるべきか？

4. 互換期間: 移行期間中、プロトコルはBLS署名とXMSS署名の両方を同時にサポートすべきか？

5. レジストリのスケーリング: 現在の開発ネットワーク (devnet)は数百のバリデーターしかサポートしていない。本番のイーサリアムには約100万のバリデーターがいる。集約ツリーはどのようにスケーリングするか？

6. 多項式コミットメントの最適化: 現在、小さな体と再帰的スタッキングにおける効率性から、多線形多項式コミットメントにはWHIRに依存している。リード・ソロモンインターリービング戦略を洗練するか、代替の多項式コミットメントスキームを完全に統合することで、証明サイズをさらに縮小できるか？

7. 鍵生成UXとツール: ソロステーカーにとって鍵生成プロセスをアクセスしやすく、間違いのないものにするにはどうすればよいか？deposit-cliから学び、この重要なインフラストラクチャを最初から構築するための、コミュニティ主導で助成金によってインセンティブ付けされたオープンソースの取り組みをどのように育成するか？

8. XMSSの標準モデル vs. ROM: XMSSパラメータを標準モデルからランダムオラクルモデル (ROM)に移行することについて議論が続いている。ROMに依存することは暗号学的に保守的ではないが、署名サイズをIPv6 MTU制限以下に縮小し、複数のPoseidon幅 (16と24) の必要性を排除するだろう。さらに、SNARKアグリゲーターはすでにROMに依存しているため、標準モデルのXMSSは不必要に厳密である可能性がある。より強力な (より多くのラウンドの) Poseidonを採用し、ROMを受け入れてスキームを簡素化すべきか？

9. 有限体の選択 (KoalaBear vs. Goldilocks): KoalaBearは非常に高速だが、その31ビットサイズと低い2-adic性 (24) は証明サイズに厳密な制限を課す — 現在、Logup多重度オーバーフローを防ぐためにleanVMを約16Mサイクルと2M Poseidonに制限している。Goldilocksのような64ビット体への移行は、これらのオーバーフロー制約を解決し、より大きな証明を可能にし、CL残高のネイティブストレージをサポートし、最小限のWHIR計算負荷で128ビットセキュリティ (Poseidonステート8を介して) を容易に達成するだろう。主なトレードオフは証明速度であり、Goldilocksでは現在約2倍遅い。プロトコルは、将来のパフォーマンス最適化を期待して、Goldilocksの容量とエレガンスを優先すべきか？

1投稿 - 1参加者

トピック全文を読む