Vitalikの新しい記事：Ethereumプロトコルの可能な未来 The Verge

実際のところ、Ethereumコンセンサスの有効性証明を得るには数年かかるでしょう。

原文タイトル：《Possible futures of the Ethereum protocol, part 4: The Verge》

執筆：Vitalik Buterin

翻訳：Mensh，ChainCatcher

 

特に、Justin Drake、Hsia-wei Wanp、Guillaume Ballet、Icinacio、Rosh Rudolf、Lev Soukhanoy Ryan Sean Adams、Uma Royのフィードバックとレビューに感謝します。

ブロックチェーンの最も強力な機能の一つは、誰でも自分のコンピュータでノードを実行し、ブロックチェーンの正当性を検証できることです。たとえ9596個のチェーンコンセンサス（PoW、PoS）ノードが即座にルール変更に同意し、新しいルールでブロックを生成し始めたとしても、完全検証ノードを実行している人はそのチェーンを受け入れません。このような陰謀グループに属さないマイナーは自動的に旧ルールを守るチェーンに集まり、そのチェーンを構築し続け、完全検証ユーザーもそのチェーンに従います。

これはブロックチェーンと中央集権型システムの重要な違いです。しかし、この特性を成立させるには、完全検証ノードの運用が十分多くの人にとって現実的でなければなりません。これはバリデーターにも（バリデーターがチェーンを検証しなければ、プロトコルルールの実行に貢献していないため）、一般ユーザーにも当てはまります。現在、コンシューマ向けノートPC（この記事執筆時に使用しているノートPCも含む）でノードを動かすことは可能ですが、実際には困難です。The Vergeはこの状況を変え、完全検証チェーンの計算コストを低減し、すべてのモバイルウォレット、ブラウザウォレット、さらにはスマートウォッチでもデフォルトで検証できるようにすることを目指しています。

The Verge 2023 ロードマップ

当初、「Verge」はEthereumの状態ストレージをVerkleツリーに移行することを指していました。Verkleツリーは、よりコンパクトな証明を可能にするツリー構造で、Ethereumブロックのステートレス検証を実現します。ノードはEthereumの状態（アカウント残高、コントラクトコード、ストレージなど）をハードディスクに保存せずにEthereumブロックを検証でき、その代償として数百KBの証明データと数百ミリ秒の追加検証時間が必要です。現在、Vergeはより大きなビジョンを表し、Ethereumチェーンの最大限のリソース効率検証の実現に焦点を当てています。これにはステートレス検証技術だけでなく、Ethereumのすべての実行をSNARKで検証することも含まれます。

チェーン全体のSNARK検証への長期的な注目に加え、もう一つの新しい課題はVerkleツリーが最適な技術かどうかです。Verkleツリーは量子コンピュータの攻撃に弱いため、現在のKECCAK Merkle PatriciaツリーをVerkleツリーに置き換えた場合、将来的に再度ツリーを置き換える必要があります。Merkleツリーの自己代替案は、Merkleブランチの使用をスキップしてSTARKを直接バイナリツリーに入れることです。歴史的には、オーバーヘッドと技術的複雑さから、この方法は実現不可能と考えられてきました。しかし最近、StarkwareがノートPC上でckcle STARKsを使い、毎秒170万回のPoseidonハッシュを証明したことや、GKBなどの技術の登場により、より「伝統的」なハッシュ値の証明時間も急速に短縮されています。そのため、過去1年で「Verge」はよりオープンになり、いくつかの可能性を持つようになりました。

The Verge：主要目標

• ステートレスクライアント：完全検証クライアントとマークルノードに必要なストレージは数GBを超えないこと。
• （長期）スマートウォッチ上でチェーン（コンセンサスと実行）を完全検証。データをダウンロードし、SNARKを検証して完了。

本章の内容

• ステートレスクライアント：VerkleかSTARKsか
• EVM実行の有効性証明
• コンセンサスの有効性証明

ステートレス検証：VerkleかSTARKsか

どんな問題を解決するのか？

現在、Ethereumクライアントはブロックを検証するために数百GBの状態データを保存する必要があり、この量は毎年増加しています。元の状態データは毎年約30GB増加し、各クライアントは三つ組を効率的に更新するために追加データも保存しなければなりません。

これにより、完全検証Ethereumノードを運用できるユーザー数が減少します。すべてのEthereum状態や何年分もの履歴を保存できる大容量ハードディスクは広く存在しますが、一般的に購入されるPCは数百GBのストレージしかありません。状態サイズはノード初期構築時にも大きな摩擦を生みます。ノードは全状態をダウンロードする必要があり、これには数時間から数日かかることもあります。これが連鎖的な影響を生みます。例えば、ノード運用者がノード設定をアップグレードする難易度が大幅に上がります。技術的にはダウンタイムなしでアップグレード可能ですが（新クライアントを起動し、同期を待ち、旧クライアントを停止してキーを転送）、実際には技術的に非常に複雑です。

どうやって動作するのか？

ステートレス検証は、ノードが全状態を保持せずにブロックを検証できる技術です。代わりに、各ブロックには証明（witness）が付属し、そこには(i)そのブロックがアクセスする状態の特定位置の値・コード・残高・ストレージ、(ii)それらの値が正しいことを示す暗号証明が含まれます。

実際にステートレス検証を実現するには、Ethereumの状態ツリー構造を変更する必要があります。現在のMerkle Patriciaツリーは、暗号証明スキームの実装に極めて不向きで、特に最悪の場合に顕著です。「元の」Merkleブランチも、「STARKでラップ」する可能性も同様です。主な困難はMPTのいくつかの弱点に由来します：

1.これは16分岐ツリー（各ノードに16個の子ノード）です。つまり、サイズNのツリーで証明には平均32*(16-1)*log16(N) = 120*log2(N)バイト、2^32項目のツリーで約3840バイト必要です。バイナリツリーなら32*(2-1)*log2(N) = 32*log2(N)バイト、約1024バイトで済みます。

2.コードがMerkle化されていません。つまり、アカウントコードへのアクセスを証明するには、最大24000バイトの全コードを提供する必要があります。

 

最悪の場合は次のように計算できます：

30000000 gas / 2400（コールドアカウント読み取りコスト）*（5 * 488 + 24000) = 330000000バイト

ブランチコストはやや低下します（5*480を8*480の代わりに使用）、分岐が多い場合は上部が重複するためです。しかし、それでも1スロット内でダウンロードするデータ量は現実的ではありません。STARKでラップしようとすると、(i)KECCAKがSTARKに不向き、(ii)330MBのデータはKECCAKラウンド関数を500万回証明する必要があり、最強のコンシューマハードウェア以外では証明できない可能性が高いです。たとえSTARKでKECCAK証明の効率を上げてもです。

もし16進ツリーをバイナリツリーに直接置き換え、コードも追加でMerkle化すれば、最悪の場合は30000000/2400*32*(32-14+8)=10400000バイト（14は2^14分岐の冗長ビットの減算、8はコードブロックリーフへの証明長）。これはgasコストを変更し、各コードブロックへのアクセスに課金する必要があります；EIP-4762がその例です。10.4MBはかなり良いですが、多くのノードにとって1スロット内でダウンロードするにはまだ多すぎます。したがって、より強力な技術が必要です。ここで有力な2つの解決策がVerkleツリーとSTARKedバイナリハッシュツリーです。

Verkleツリー

Verkleツリーは楕円曲線ベースのベクトルコミットメントを使い、より短い証明を実現します。鍵は、ツリーの幅に関係なく、各親子関係の証明部分が32バイトで済むことです。証明ツリーの幅の唯一の制限は、幅が広すぎると証明計算効率が下がることです。Ethereum向け提案の実装幅は256です。

したがって、証明中の単一ブランチのサイズは32 - log256(N) = 4*log2(N)バイトとなります。理論上の最大証明サイズは約30000000 / 2400 *32*(32-14+8)/8 = 130000バイト（状態ブロックの分布が不均一なため実際は多少異なりますが、一次近似としては妥当です）。

また、上記すべての例で「最悪の場合」は本当の最悪ではありません。攻撃者がツリー内で長い共通プレフィックスを持つ2つのアドレスを「採掘」し、その一方からデータを読み取ることで、最悪のブランチ長がさらに2倍になる可能性があります。しかし、そうした場合でもVerkleツリーの最悪証明長は2.6MBで、現在の最悪の検証データとほぼ一致します。

さらに、隣接するストレージ領域（同一コントラクトの複数コードブロックや隣接ストレージスロット）へのアクセスコストを非常に低く設定できます。EIP-4762は隣接の定義を提供し、隣接アクセスには200gasのみ課金します。隣接アクセスの場合、最悪証明サイズは30000000/200*32-4800800バイトとなり、許容範囲内です。安全のためこの値を減らしたい場合は、隣接アクセスの料金を少し上げることもできます。

STARKedバイナリハッシュツリー

この技術の原理は明快です。バイナリツリーを作り、最大10.4MBの証明を取得し、ブロック内の値を証明し、その証明をSTARKで置き換えます。これにより、証明自体は証明対象データと、実際のSTARKによる100-300kBの固定オーバーヘッドだけになります。

主な課題は検証時間です。上記とほぼ同じ計算ができますが、バイト数ではなくハッシュ値を計算します。10.4MBのブロックは33万ハッシュ値に相当します。攻撃者がアドレスツリーで長い共通プレフィックスを持つ可能性を加味すると、最悪で約66万ハッシュ値となります。1秒あたり20万ハッシュ値を証明できれば問題ありません。

Poseidonハッシュ関数を使ったコンシューマノートPCでは、これらの数値はすでに達成されています。PoseidonはSTARKフレンドリー設計ですが、まだ比較的新しく、その安全性を信頼していない人も多いです。したがって、現実的な前進策は2つあります：

1. Poseidonの安全性分析を迅速に大量に行い、L1での導入に十分な信頼を得る
2. より「保守的」なハッシュ関数（SHA256やBLAKEなど）を使う

保守的なハッシュ関数の証明では、StarkwareのSTARKサークルは執筆時点でコンシューマノートPCで毎秒1万～3万ハッシュ値しか証明できません。ただし、STARK技術は急速に進歩しています。今日でもGKRベースの技術でこの速度を10万～20万に引き上げる見込みがあります。

ブロック検証以外の証明利用ケース

ブロック検証以外にも、より効率的なステートレス検証が必要な3つの主要ユースケースがあります：

• メモリプール：トランザクションがブロードキャストされると、P2Pネットワーク内のノードは再ブロードキャスト前にトランザクションの有効性を検証する必要があります。現在の検証は署名検証だけでなく、残高やプレフィックスの確認も含みます。将来的には（例えばEIP-7701のようなネイティブアカウント抽象化を使う場合）、EVMコードの実行が必要となり、状態アクセスも発生します。ノードがステートレスの場合、トランザクションには状態オブジェクトの証明が付属する必要があります。
• インクルージョンリスト：これは提案中の機能で、（規模が小さく複雑でない）PoSバリデーターが、（規模が大きく複雑な）ブロックビルダーの意思に関係なく、次のブロックにトランザクションを強制的に含めることを可能にします。これにより、権力者がトランザクション遅延でブロックチェーンを操作する能力が弱まります。ただし、バリデーターがインクルージョンリスト内トランザクションの有効性を検証できる必要があります。
• ライトクライアント：ユーザーがウォレット（Metamask、Rainbow、Rabbyなど）でチェーンにアクセスする場合、ライトクライアント（Heliosなど）を実行する必要があります。Heliosのコアモジュールはユーザーに検証済み状態ルートを提供します。完全な信頼レス体験には、ユーザーが行う各RPCコールに証明が必要です（例えばeth_callリクエストでは、呼び出し中にアクセスしたすべての状態の証明が必要）。

これらのユースケースはすべて、証明がかなり多く必要ですが、各証明は小さいという共通点があります。したがって、STARK証明は実用的ではなく、現実的にはMerkleブランチを直接使うのが最適です。Merkleブランチのもう一つの利点は更新可能性です：ブロックBをルートとする状態オブジェクトXの証明があれば、子ブロックB2とその証明を受け取ったとき、証明をB2ルートに更新できます。Verkle証明もネイティブに更新可能です。

既存研究との関連：

• Verkle trees
• John KuszmaulによるVerkle treeの元論文
• Starkware
• Poseidon2 paper
• Ajtai（格子困難性ベースの代替高速ハッシュ関数）
• Verkle.info

他に何ができるか？

残された主な作業は：

1.EIP-4762の影響（ステートレスgasコスト変化）に関するさらなる分析

2.移行プログラムの完成とテスト、これはあらゆるステートレス環境実装の複雑性の主な部分

3.Poseidon、Ajtai、その他「STARKフレンドリー」ハッシュ関数のさらなる安全性分析

4.「保守的」（または「伝統的」）ハッシュ向けの超高効率STARKプロトコル機能のさらなる開発（BiniusやGKRベースのアプローチなど）

また、近いうちに次の3つの選択肢から1つを選ぶことになります：(i)Verkleツリー、(ii)STARKフレンドリーハッシュ関数、(iii)保守的ハッシュ関数。それぞれの特徴は下表にまとめられます：

これらの「見出し数字」以外にも、いくつか重要な考慮事項があります：

• 現在、Verkleツリーのコードはかなり成熟しています。Verkle以外のコードを使うと、デプロイが遅れ、ハードフォークも遅れる可能性が高いです。これは、ハッシュ関数分析やバリデーター実装に追加時間が必要な場合や、Ethereumに早期に組み込みたい他の重要な機能がある場合には問題ありません。
• ハッシュ値による状態ルート更新はVerkleツリーより速いです。つまり、ハッシュベースの方法はフルノードの同期時間を短縮できます。
• Verkleツリーは興味深い証明更新特性を持っています。Verkleツリー証明は更新可能です。この特性はmempool、インクルージョンリスト、他のユースケースに有用で、実装効率向上にも役立つ可能性があります。状態オブジェクトが更新された場合、最下層を読み込まずに下から2層目の証明を更新できます。
• VerkleツリーはSNARK証明が難しいです。証明サイズを数千バイトまで小さくしたい場合、Verkle証明は困難をもたらします。これは、Verkle証明の検証が大量の256ビット演算を導入し、証明システムに大きなオーバーヘッドが必要か、256ビットVerkle証明部分を含むカスタム内部構造が必要になるためです。これはステートレス自体には問題ありませんが、困難が増します。

量子安全かつ合理的に効率的な方法でVerkle証明の更新性を得たい場合、格子ベースのMerkleツリーも一つの可能性です。

最悪の場合、証明システムの効率が十分でない場合、多次元gasという意外なツールを使ってこの不足を補うこともできます：(i)calldata、(ii)計算、(iii)状態アクセス、その他異なるリソースごとに個別のgas制限を設ける。多次元gasは複雑性を増しますが、平均と最悪の比率をより厳密に制限できます。多次元gasがあれば、理論上証明が必要な最大ブランチ数は12500から例えば3000に減らせます。これにより、BLAKE3も今日なら（ぎりぎり）使えます。

多次元gasはブロックのリソース制限を基盤ハードウェアのリソース制限により近づける

もう一つの意外なツールは、状態ルート計算をブロック後のスロットに遅らせることです。これにより、状態ルート計算に12秒間使えるため、最悪の場合でも1秒あたり6万ハッシュの証明時間で十分となり、BLAKE3もぎりぎり要件を満たせます。

この方法の欠点は、ライトクライアントの遅延が1スロット分増えることですが、証明生成遅延だけに遅延を抑える巧妙な技術もあります。例えば、証明はどのノードでも生成後すぐネットワークにブロードキャストでき、次のブロックを待つ必要はありません。

ロードマップの他の部分との相互作用は？

ステートレス問題の解決は、ソロステーキングの難易度を大幅に下げます。Orbit SSFのような技術や、アプリケーション層の戦略（クワッドステーキングなど）でソロステーキングの最低残高を下げられれば、より現実的になります。

EOFを同時に導入すれば、多次元gas分析がより容易になります。多次元gasの主な実行複雑性は、親呼び出しの全gasを伝播しない子呼び出しの処理にありますが、EOFではこのような子呼び出しを違法にすれば、この問題は些細になります（ネイティブアカウント抽象化は部分gasの現在の主要用途にプロトコル内代替を提供します）。

ステートレス検証と履歴期限切れには重要な相乗効果もあります。現在、クライアントは約1TBの履歴データを保存しなければなりません。これは状態データの数倍です。クライアントがステートレスでも、履歴データ保存の責任を解除できなければ、ほぼストレージレスクライアントの夢は実現しません。最初のステップはEIP-4444で、履歴データをtorrentsやPortal Networkに保存することを意味します。

EVM実行の有効性証明

どんな問題を解決するのか？

Ethereumブロック検証の長期目標は明確です——次の方法でEthereumブロックを検証できるべきです：(i)ブロックをダウンロード、またはデータ可用性サンプリングの一部だけをダウンロード、(ii)ブロック有効性の小さな証明を検証。これは非常に低リソースな操作で、モバイルクライアントやブラウザウォレット、さらには他のチェーンでも（データ可用性部分なしで）実行できます。

これを実現するには、(i)コンセンサス層（PoS）と(ii)実行層（EVM）の両方をSNARKまたはSTARKで証明する必要があります。前者自体が課題で、コンセンサス層の継続的な改良（単一スロットファイナリティなど）で解決すべきです。後者はEVM実行証明が必要です。

それは何で、どう動作するのか？

形式的には、Ethereum仕様ではEVMは状態遷移関数として定義されています：前状態S、ブロックBがあり、後状態S' = STF(S, B)を計算します。ユーザーがライトクライアントを使う場合、SやS'、Eを完全には持っていません。代わりに、前状態ルートR、後状態ルートR'、ブロックハッシュHを持っています。

• 公開入力：前状態ルートR、後状態ルートR'、ブロックハッシュH
• 秘密入力：ブロック本体B、ブロックQがアクセスする状態内オブジェクト、Q'実行後の同じオブジェクト、状態証明（Merkleブランチなど）P
• 主張1：PはQがRで表される状態の一部を含む有効な証明である
• 主張2：Q上でSTFを実行すると、(i)実行過程でQ内部のオブジェクトのみアクセスし、(ii)ブロックは有効で、(iii)結果はQ'となる
• 主張3：Q'とPの情報で新しい状態ルートを再計算するとR'になる

このような仕組みがあれば、完全検証Ethereum EVM実行のライトクライアントが実現できます。これによりクライアントのリソース消費はかなり低くなります。完全検証Ethereumクライアントを実現するには、コンセンサス側でも同様の作業が必要です。

EVM計算の有効性証明の実装はすでに存在し、L2で広く使われています。L1でEVM有効性証明を実用化するには、まだ多くの作業が必要です。

既存研究との関連は？

• EFPSE ZK-EVM（より良い選択肢があるため廃止）
• Zeth（EVMをRISC-0 ZK-VMにコンパイルして動作）
• ZK-EVM形式検証プロジェクト

他に何ができるか？

現在、電子記帳システムの有効性証明には2つの課題があります：安全性と検証時間です。

安全な有効性証明には、SNARKがEVMの計算を正しく検証し、脆弱性がないことを保証する必要があります。安全性向上の主な技術はマルチバリデーターと形式検証です。マルチバリデーターは、複数の独立した有効性証明実装があり、そのうち十分なサブセットがブロックを証明すればクライアントが受け入れる方式です。形式検証は、Lean4など数学定理証明用ツールを使い、有効性証明がEVM仕様（EVM Kセマンティクスやpythonで書かれたEthereum Execution Layer Specification（EELS）など）を正しく実行することを証明します。

十分に速い検証時間とは、Ethereumブロックを4秒未満で検証できることです。現状ではこの目標にはまだ遠いですが、2年前よりはかなり近づいています。これを実現するには3つの方向で進展が必要です：

• 並列化——現在最速のEVMバリデーターは平均15秒でEthereumブロックを証明できます。これは数百GPUで並列化し、最後に集約することで実現しています。理論的には、O(log(N))時間で計算を証明できるEVMバリデーターを作る方法は完全に分かっています：各ステップを1GPUが担当し、「集約ツリー」を作る：

実現には課題があります。最悪の場合、非常に大きなトランザクションがブロック全体を占めると、計算の分割はトランザクション単位ではなく、オペコード（EVMやRISC-Vなどの仮想マシンのオペコード）単位で行う必要があります。証明の異なる部分間で仮想マシンの「メモリ」を一貫させることが実装上の鍵です。ただし、こうした再帰証明が実現できれば、他の改良がなくても少なくともバリデーターの遅延問題は解決します。

• 証明システムの最適化——Orion、Binius、GRKなど新しい証明システムにより、汎用計算の検証時間がさらに大幅に短縮される可能性が高いです。
• EVM gasコストの他の変更——EVMの多くは、最悪の場合でもバリデーターに有利になるよう最適化できます。攻撃者がバリデーターを10分間ブロックするブロックを作れるなら、通常のEthereumブロックを4秒で証明できても不十分です。必要なEVM変更は大きく次の3つに分けられます：
• gasコストの変更——ある操作が証明に非常に時間がかかるなら、計算自体が速くても高いgasコストにすべきです。EIP-7667はこの点で最も深刻な問題に対処するために提案されました：伝統的なハッシュ関数のgasコストを大幅に引き上げます。証明コストが低いEVMオペコードのgasコストを下げて平均スループットを維持できます。
• データ構造の置換——STARKにより適した方法で状態ツリーを置き換えるだけでなく、トランザクションリストやレシートツリーなど証明コストの高い構造も置き換える必要があります。Etan Kisslingによるトランザクション・レシート構造のSSZ移行EIPはその一歩です。

さらに、前節で述べた2つのツール（多次元gasと遅延状態ルート）もこの分野で役立ちます。ただし、ステートレス検証と異なり、これらのツールを使う場合、現在必要な作業は十分な技術がすでにありますが、完全なZK-EVM検証にはさらに多くの作業が必要です——ただし必要な作業は少なくなります。

上記で触れていない点として、バリデーター用ハードウェアがあります：GPU、FPGA、ASICを使って証明生成を高速化することです。Fabric Cryptography、Cysic、Accsealはこの分野で進展している3社です。これはL2では非常に価値がありますが、L1では決定的な要素にはなりにくいです。L1は高度な分散化を維持する必要があり、証明生成はEthereumユーザーの合理的な範囲内で行われ、特定企業のハードウェアのボトルネックに依存すべきではありません。L2ではより積極的なトレードオフが可能です。

これらの分野にはさらに多くの作業が必要です：

• 並列証明には証明システムの異なる部分が「共有メモリ」（ルックアップテーブルなど）を使える必要があります。技術は分かっていますが、実装が必要です。
• 最悪の場合の検証時間を最小化する理想的なgasコスト変更セットを見つけるため、さらなる分析が必要です。
• 証明システム自体のさらなる開発が必要です

考えられるトレードオフ：

• 安全性とバリデーター時間：より積極的なハッシュ関数、複雑な証明システム、積極的な安全仮定や他の設計を選ぶと、バリデーター時間を短縮できる可能性があります。
• 分散化とバリデーター時間：コミュニティはバリデーター用ハードウェアの「スペック」について合意する必要があります。バリデーターが大規模事業体でも良いのか？ハイエンドコンシューマノートPCで4秒以内にEthereumブロックを証明できるべきか？その中間か？
• 後方互換性の破壊度：他の不足はより積極的なgasコスト変更で補えますが、これは特定アプリのコストを不釣り合いに増やし、開発者が経済的に成立させるためにコードを書き直し再デプロイを強いられる可能性が高いです。同様に、これら2つのツールにも独自の複雑性と欠点があります。

ロードマップの他の部分との相互作用は？

L1 EVM有効性証明に必要なコア技術は、他の2分野と大きく共有されています：

• L2の有効性証明（「ZK rollup」）
• ステートレスな「STARKバイナリハッシュ証明」方式

L1で有効性証明が実現すれば、最弱のコンピュータ（スマホやスマートウォッチも含む）でもステーキングできる「イージーソロステーキング」が最終的に実現します。これにより、ソロステーキングの他の制限（32ETH最低限度など）を解決する価値がさらに高まります。

また、L1のEVM有効性証明はL1のgas上限を大幅に引き上げることができます。

コンセンサスの有効性証明

どんな問題を解決するのか？

SNARKでEthereumブロックを完全検証したい場合、証明すべきはEVM実行だけではありません。コンセンサス、つまりシステム内での入金・出金・署名・バリデーター残高更新・Ethereum PoS部分の他要素も証明する必要があります。

コンセンサスはEVMよりはるかに単純ですが、L2 EVMロールアップがないため、いずれにせよ大部分の作業は「ゼロから」行う必要があります。したがって、Ethereumコンセンサスの証明実装は「ゼロから」必要ですが、証明システム自体は共通基盤上に構築できます。

それは何で、どう動作するのか？

ビーコンチェーンはEVM同様、状態遷移関数として定義されています。状態遷移関数は主に3つの部分で構成されます：

• ECADD（BLS署名検証用）
• ペアリング（BLS署名検証用）
• SHA256ハッシュ値（状態の読み取り・更新用）

各ブロックで、各バリデーターについて1～16回のBLS12-381 ECADD（複数の集合に署名が含まれる場合はそれ以上）を証明する必要があります。サブセット事前計算技術で補えるため、各バリデーターにつき1回のBLS12-381 ECADDと考えられます。現在、各スロットで3万バリデーター署名があります。将来、単一スロットファイナリティが実現すれば、2方向に変化する可能性があります：「力技」路線なら各スロットのバリデーター数は100万に増えるかもしれません。一方、Orbit SSFならバリデーター数は32768、あるいは8192に減るかもしれません。

BLSアグリゲーションの仕組み：合計署名の検証は各参加者1回のECADDで済み、ECMULは不要です。しかし3万回のECADDは依然として大きな証明量です。

ペアリングについては、現在各スロット最大128個の証明があり、128回のペアリング検証が必要です。ElP-7549や更なる修正で各スロット16回に減らせます。ペアリング回数は少ないですが、コストは非常に高いです：各ペアリングの実行（または証明）時間はECADDの数千倍です。

BLS12-381演算の証明の主な課題は、BLS12-381フィールドサイズと等しい曲線位数を持つ便利な曲線がないことです。これがどの証明システムにも大きなオーバーヘッドをもたらします。一方、Ethereum提案のVerkleツリーはBandersnatch曲線で構築されており、BLS12-381自体がVerkleブランチ証明用のSNARKシステム内自己曲線となります。単純な実装でも毎秒100G1加算を証明できます。証明速度を十分に速くするにはGKRのような巧妙な技術がほぼ必須です。

SHA256ハッシュ値については、最悪の場合はエポック変換ブロックで、全バリデーターショートバランスツリーと多くのバリデーター残高が更新されます。各バリデーターのショートバランスツリーは1バイトなので、1MBのデータが再ハッシュされます。これは32768回のSHA256呼び出しに相当します。1000バリデーターの残高が閾値を超える・下回る場合、バリデーター記録の有効残高更新が必要で、1万回のハッシュ値が必要です。シャッフルメカニズムは各バリデーター90ビット（11MBのデータ）ですが、これはエポック内の任意タイミングで計算できます。単一スロットファイナリティの場合、これらの数字は状況により増減します。シャッフルは不要になりますが、Orbitではある程度復活する可能性もあります。

もう一つの課題は、ブロック検証のために全バリデーター状態（公開鍵含む）を再取得する必要があることです。100万バリデーターの場合、公開鍵だけで4800万バイト、さらにMerkleブランチが必要です。これにより各エポックで数百万回のハッシュ値が必要です。PoS有効性を証明する必要がある場合、現実的な方法は何らかのインクリメンタル検証可能計算：証明システム内に個別データ構造を保存し、高速検索とその構造の更新証明を可能にすることです。

要するに、課題は多いです。これらの課題に最も効率的に対処するには、ビーコンチェーンの抜本的な再設計が必要であり、これは単一スロットファイナリティへの移行と同時に行われる可能性が高いです。この再設計の特徴は次のようなものです：

• ハッシュ関数の変更：現在は「完全な」SHA256ハッシュ関数を使っているため、パディングのため各呼び出しで2回の圧縮関数呼び出しが必要です。SHA256圧縮関数に切り替えれば少なくとも2倍の効率化が可能です。Poseidonに切り替えれば100倍の効率化も可能で、ハッシュ値面の問題は完全に解決します（毎秒170万ハッシュ値（54MB）なら、100万バリデーター記録も数秒で証明に「読み込め」ます）。
• Orbitの場合、シャッフル後のバリデーター記録を直接保存：特定数のバリデーター（8192や32768など）をスロットの委員会として選ぶ場合、それらを状態内で隣接して保存し、最小限のハッシュで全バリデーター公開鍵を証明に読み込めます。これにより残高更新も効率的に行えます。
• 署名アグリゲーション：高性能署名アグリゲーションスキームは何らかの再帰証明を伴い、ネットワーク内の異なるノードが署名サブセットの中間証明を行います。これにより証明作業がネットワーク内の複数ノードに分散され、「最終証明者」の負担が大幅に減ります。
• 他の署名スキーム：Lamport+Merkle署名の場合、署名検証に256+32ハッシュ値が必要です。32768署名者なら9437184ハッシュ値です。署名スキームを最適化すればこの値も小さな定数倍で改善できます。Poseidonを使えば1スロット内で証明できますが、実際には再帰アグリゲーションスキームの方が速いです。

既存研究との関連は？

• 簡潔なEthereumコンセンサス証明（同期委員会のみ）
• 簡潔SP1内のHelios
• 簡潔BLS12-381プリコンパイル
• Halo2ベースのBLS集合署名検証

他に必要な作業やトレードオフ：

実際のところ、Ethereumコンセンサスの有効性証明を得るには数年かかるでしょう。これは単一スロットファイナリティ、Orbit、署名アルゴリズムの変更、安全性分析に必要な時間とほぼ同じであり、Poseidonのような「積極的」ハッシュ関数を使うのに十分な信頼を得るためにも時間がかかります。したがって、最も賢明なのはこれら他の問題を解決しつつ、STARKフレンドリー性を考慮することです。

主なトレードオフは、おそらく実装順序に関するもので、Ethereumコンセンサス層の改革を段階的に進める方法と、より積極的に「一度に多くを変える」方法の間での選択です。EVMの場合、段階的アプローチは後方互換性への影響を最小化できるため合理的です。コンセンサス層の場合、後方互換性の影響は小さく、ビーコンチェーンの構築方法の細部をより「包括的」に再考し、SNARKフレンドリー性を最適化するメリットもあります。

ロードマップの他の部分との相互作用は？

Ethereum PoSの長期再設計では、STARKフレンドリー性が最優先事項となるべきです。特に単一スロットファイナリティ、Orbit、署名スキーム変更、署名アグリゲーションにおいて重要です。