原題: 「イーサリアムプロトコルの将来の可能性、パート 4: The Verge」
原作者: ヴィタリック・ブテリン
オリジナルコンピレーション：Mensh、ChainCatcher
フィードバックとレビューをくださった Justin Drake、Hsia-wei Wanp、Guillaume Ballet、Icinacio、Rosh Rudolf、Lev Soukhanoy Ryan Sean Adams、Uma Roy に心より感謝いたします。
ブロックチェーンの最も強力な機能の 1 つは、誰でも自分のコンピューター上でノードを実行し、ブロックチェーンの正しさを検証できることです。チェーンコンセンサス (PoW、PoS) を実行している 9596 ノードすべてがルール変更に即座に同意し、新しいルールに従ってブロックの生成を開始したとしても、完全に検証しているノードを実行しているすべてのノードがチェーンの受け入れを拒否することになります。そのような陰謀団の一員ではないミンターは、古いルールに従い続けるチェーンに自動的に集まり、このチェーンを構築し続けますが、完全に認証されたユーザーはこのチェーンに従います。
これがブロックチェーンと集中型システムの主な違いです。ただし、この機能が成り立つためには、完全に検証されたノードを十分な数の人が実際に実行できる必要があります。これは、キャンペーン実行者 (キャンペーン実行者がチェーンを検証しない場合、プロトコル ルールの強制に貢献していないため) と通常のユーザーの両方に当てはまります。現在、消費者向けラップトップ (この記事を書いているラップトップも含む) でノードを実行することは可能ですが、実行するのは困難です。 The Verge はこの状況を変えることを目指しており、チェーンを完全に検証するための計算コストを非常に低くし、すべてのモバイル ウォレット、ブラウザ ウォレット、さらにはスマート ウォッチがデフォルトでチェーンを検証できるようにします。
The Verge 2023 ロードマップ
もともと「Verge」は、イーサリアムの状態ストレージを Verkle ツリー (よりコンパクトな証明を可能にし、イーサリアム ブロックのステートレスな検証を可能にするツリー構造) に移動することを指しました。ノードは、イーサリアムの状態 (アカウント残高、契約コード、ストレージ容量など) をハードドライブに保存せずにイーサリアムブロックを検証できますが、その代わりに数百 KB の証明データと証明の検証に数百ミリ秒の追加時間がかかります。 。現在、Verge は、イーサリアム チェーンの最大限のリソース効率の検証を可能にすることに焦点を当てた、より大きなビジョンを表しています。これには、ステートレス検証テクノロジーだけでなく、すべてのイーサリアム実行を検証するための SNARK の使用も含まれます。
チェーン全体の SNARK 検証に長期的に焦点が当てられていることに加えて、Verkle ツリーが最高のテクノロジーであるかどうかという新たな問題も浮上しています。 Verkle ツリーは量子コンピュータによる攻撃に対して脆弱であるため、現在の KECCAK Merkle Patricia ツリーを Verkle ツリーに置き換えると、後で再度ツリーを置き換える必要があります。 Merkle ツリーの代替方法は、Merkle ブランチを使用して STARK を単純にスキップし、それをバイナリ ツリーに入れることです。歴史的に、このアプローチはオーバーヘッドと技術的な複雑さのため実現不可能であると考えられてきました。しかし最近、Starkware がラップトップ上の ckcle STARK を使用して 1 秒あたり 170 万のポセイドン ハッシュを証明したのを目にしました。GKB のようなテクノロジーのおかげで、より「従来の」ハッシュの証明時間も急速に短縮されています。この 1 年で、「Verge」はよりオープンになり、いくつかの可能性が生まれました。
The Verge: 主要な目標
ステートレス クライアント: クライアントとタグ ノードを完全に認証するために必要なストレージ スペースは、数 GB を超えてはなりません。
(長期) スマートウォッチ上で完全に検証されたチェーン (コンセンサスと実行)。データをダウンロードし、SNARK を確認して完了です。
この章では
ステートレス クライアント: Verkle または STARKs
EVM実行の有効性の証明
合意の有効性の証明
ステートレス検証: Verkle または STARKs
私たちはどのような問題を解決しようとしているのでしょうか?
現在、イーサリアム クライアントはブロックを検証するために数百ギガバイトの状態データを保存する必要があり、その量は年々増加しています。生の状態データは年間約 30 GB ずつ増加するため、トリプルを効率的に更新するには、単一のクライアントが追加データを保存する必要があります。
これにより、イーサリアム ノードを完全に検証できるユーザーの数が減少します。すべてのイーサリアムの状態や数年にわたる履歴を保存できる十分な容量のハード ドライブが広く入手可能である一方で、人々はデフォルトで数百ギガバイトのストレージしか搭載していないコンピュータを購入する傾向があります。また、状態のサイズによって、ノードを初めてセットアップするプロセスに大きな摩擦が生じます。ノードは状態全体をダウンロードする必要があり、これには数時間から数日かかる場合があります。これはあらゆる種類の波及効果をもたらします。たとえば、ノード メーカーがノード設定をアップグレードする際の難易度が大幅に増加します。技術的には、ダウンタイムなしでアップグレードを完了することは可能です。新しいクライアントを起動し、同期するのを待ち、古いクライアントを閉じてキーを転送します。しかし、実際には、これは技術的に非常に複雑です。
どのように機能するのでしょうか?
ステートレス検証は、ノードが状態全体を把握することなくブロックを検証できるようにするテクノロジーです。代わりに、各ブロックには、(i) 値、コード、残高、ブロックがアクセスする状態の特定の場所にあるストレージ、(ii) これらの値が正しいことを示す暗号学的証明が含まれます。
実際、ステートレス検証を実装するには、イーサリアムのステート ツリー構造を変更する必要があります。これは、現在のマークル パトリシア ツリーが、特に最悪の場合の暗号証明スキームの実装に非常に不向きであるためです。これは、それが「オリジナルの」Merblk フォークであっても、STARK に「ラップされる」可能性であっても当てはまります。主な問題は、MPT のいくつかの弱点から生じます。
1. これはヘキサツリーです (つまり、各ノードには 16 の子ノードがあります)。これは、サイズ N のツリーでは、証明には平均 32*(16-1)*log 16(N) = 120* log 2(N) バイト、つまり約 3840 バイトが必要であることを意味します。バイナリ ツリーの場合、必要なのは 32*(2-1)*log 2(N) = 32* log 2(N) バイト、つまり約 1024 バイトだけです。
2. コードはマークル化されていません。つまり、アカウント コードへのアクセスを証明するには、コード全体 (最大 24,000 バイト) を提供する必要があります。
最悪のシナリオは次のように計算できます。
30000000 ガス / 2400 (コールド アカウント読み取りコスト) * (5 * 488 + 24000) = 330000000 バイト
ブランチの数が増えると上部の部分が繰り返されるため、ブランチのコストがわずかに減りました (8* 480 ではなく 5* 480)。しかし、それでも、1 つの時間帯にダウンロードするデータ量はまったく非現実的です。これを STARK でラップしようとすると、次の 2 つの問題に遭遇します: (i) KECCAK は比較的 STARK に不向きです。(ii) 330 MB のデータは、KECCAK のラウンド関数への 500 万回の呼び出しを正当化する必要があることを意味します。 KECCAK の方が効率的であることを STARK に証明してもらったとしても、最も強力なコンシューマ ハードウェア以外のすべてで証明されています。
16 進ツリーを 2 進ツリーに直接置き換え、コードの追加のマークル化を行うと、最悪のシナリオはおよそ 30000000/2400* 32*(32-14+ 8) = 10400000 バイトになります (14 は冗長ビットの減算です)。 2^14 の分岐の場合、8 はコード ブロックの葉に入る証明の長さです)。これには、個々のコード ブロックにアクセスするために請求するガス コストを変更する必要があることに注意してください。これはEIP-4762によって行われます。 10.4 MB の容量ははるかに優れていますが、それでも多くのノードで 1 つのタイムスロットにダウンロードするにはデータ量が多すぎます。したがって、より強力なテクノロジーを導入する必要があります。この点に関しては、Verkle ツリーと STARKed バイナリ ハッシュ ツリーという 2 つの主要なソリューションがあります。
バークルの木
Verkle ツリーは、より短い証明のために楕円曲線ベースのベクトルコミットメントを使用します。これを解く鍵は、ツリーの幅に関係なく、各親子関係の証明部分がわずか 32 バイトであることです。証明ツリーの幅に関する唯一の制限は、証明ツリーが広すぎると証明の計算効率が低下することです。イーサリアムに提案されている実装の幅は 256 です。
したがって、証明における 1 つの分岐のサイズは 32 - 1 og 256(N) = 4* log 2(N) バイトになります。したがって、理論上の最大証明サイズはおよそ 30000000 / 2400 * 32* ( 32 -14 + 8) / 8 = 130000 バイトになります (実際の計算結果は状態ブロックの不均等な分布により若干異なりますが、一次近似としては次のようになります)わかりました）。
もう 1 つ注意すべきことは、上記のすべての例において、この「最悪のケース」は最悪のシナリオではないということです。最悪のケースは、攻撃者が 2 つのアドレスを意図的に「マイニング」して、ツリー プレフィックス内でより長い共通の場所を確保し、いずれかのアドレスからデータを読み取ると、最悪の場合の分岐長がさらに 2 倍に延長される可能性があります。しかし、たとえそうであったとしても、バークル木の最悪の場合の証明長は 2.6 MB であり、これは現在の最悪の場合の検証データと基本的に一致しています。
また、この警告に対して別のことも行いました。「隣接する」ストレージ、つまり同じコントラクトの多数のコード ブロック、または隣接するストレージ スロットへのアクセスを非常に安価にしました。 EIP-4762 は隣接関係の定義を提供し、隣接アクセスに対して 200 ガスのみを請求します。隣接アクセスの場合、最悪のプルーフ サイズは 30000000 / 200* 32 - 4800800 バイトになりますが、それでもほぼ許容範囲内です。セキュリティ上の理由からこの値を減らしたい場合は、隣接するアクセスのコストをわずかに増やすことができます。
STARKed バイナリ ハッシュ ツリー
この手法の原理は一目瞭然です。バイナリ ツリーを作成し、最大 10.4 MB の証明を取得し、ブロック内の値を証明し、証明を証明の STARK に置き換えるだけです。このように、証明自体は、証明されるデータと、実際の STARK からの 100 ～ 300 KB の固定オーバーヘッドのみで構成されます。
ここでの主な課題は検証時間です。基本的に上記と同じ計算を行うことができますが、バイトを数える代わりにハッシュを数える点が異なります。 10.4 MB ブロックは 330,000 ハッシュを意味します。攻撃者がより長いパブリック プレフィックスを持つアドレス ツリーを「マイニング」する可能性を加えると、最悪の場合のハッシュ値は約 660,000 ハッシュになります。したがって、1 秒あたり 200,000 ハッシュを証明できれば問題ありません。
これらの数値は、特に STARK に優しいように設計されたPoseidon ハッシュ関数を使用して消費者向けラップトップで達成されました。しかし、ポセイドン システムはまだ比較的未成熟であるため、多くの人がそのセキュリティをまだ信頼していません。したがって、今後の現実的な道は 2 つあります。
ポセイドンに関する広範なセキュリティ分析を迅速に実行し、L1 で展開できるほど十分に精通します。
SHA 256 や BLAKE など、より「保守的な」ハッシュ関数を使用します。
保守的なハッシュ関数を証明したい場合、Starkware の STARK サークルでは、この記事の執筆時点で消費者向けラップトップで 1 秒あたり 10 ～ 30,000 のハッシュしか証明できません。しかし、STARK テクノロジーは急速に進歩しています。現在でも、GKR ベースのテクノロジーにより、この速度が 100-200k の範囲にまで向上することが証明されています。
ブロックの検証を超えたユースケースを目撃する
ブロックの検証に加えて、より効率的なステートレス検証を必要とする主要な使用例が他に 3 つあります。
Mempool: トランザクションがブロードキャストされる場合、P2P ネットワーク内のノードは、再ブロードキャストする前にトランザクションが有効であることを確認する必要があります。現在の検証には、署名の検証だけでなく、残高が十分でプレフィックスが正しいことのチェックも含まれます。将来的には (EIP-7701 のようなネイティブ アカウント抽象化を使用するなど)、状態アクセスを行う EVM コードの実行が必要になる可能性があります。ノードがステートレスの場合、トランザクションには状態オブジェクトの証明が必要になります。
包含リスト: これは、(おそらく小さくて複雑ではない) プルーフ・オブ・ステークのバリデーターが、(おそらくより大きくてより複雑な) ブロックビルダーの希望に関係なく、次のブロックに強制的にトランザクションを含めることを可能にする提案された機能です。これにより、権力者がトランザクションを遅らせてブロックチェーンを操作する能力が弱まる可能性があります。ただし、これにはバリデーターがリストに含まれるトランザクションの正当性を検証する方法が必要です。
ライトクライアント: ユーザーがウォレットを通じてチェーン (メタマスク、レインボー、ラビーなど) にアクセスできるようにするには、ライトクライアント (Helios など) を実行する必要があります。Helios コアモジュールは、ユーザーに検証済みのクライアントを提供します。状態ルート。完全にトラストレスなエクスペリエンスを実現するには、ユーザーは行うすべての RPC 呼び出しの証拠を提供する必要があります (たとえば、イーサネット呼び出しリクエストの場合 (ユーザーは、呼び出し中にアクセスされたすべての状態を証明する必要があります)。
これらすべてのユースケースに共通しているのは、かなりの数の証明が必要ですが、それぞれの証明は小さいということです。したがって、STARK 証明はそれらにとって実際的な意味を持たず、最も現実的なアプローチは Merkle ブランチを直接使用することです。 Merkle ブランチのもう 1 つの利点は、それが更新可能であることです。状態オブジェクト 2 の証明がルートであると仮定します。 Verkle 証明もネイティブに更新可能です。
既存の研究とのつながりは何ですか:
他に何ができるでしょうか?
残っている主な仕事は、
1. EIP-4762 の影響に関するさらなる分析 (無国籍ガスコストの変化)
2. 移行手順の完了とテストにさらに取り組む。これは、ステートレス環境の実装計画の複雑さの主要な部分である。
3. ポセイドン、アジュタイ、その他の「STARK フレンドリーな」ハッシュ関数のさらなるセキュリティ分析
4. Binius または GKR の観点に基づく、「保守的」（または「伝統的」）ハッシュのための超効率的な STARK プロトコル機能のさらなる開発。
さらに、(i) Verkle ツリー、(ii) STARK フレンドリーなハッシュ関数、および (iii) 保守的なハッシュ関数の 3 つのオプションのいずれかを選択することを間もなく決定します。それらの特徴は次の表に大まかに要約できます。
これらの「見出し番号」に加えて、他にもいくつかの重要な考慮事項があります。
現在、Verkle ツリー コードはかなり成熟しています。 Verkle 以外のコードを使用すると、デプロイが遅れ、おそらくハード フォークが遅れます。特にハッシュ関数分析やバリデーターの実装に追加の時間が必要な場合、または他の重要な機能をイーサリアムに早期に組み込む必要がある場合は、それも問題ありません。
ハッシュを使用して状態ルートを更新すると、Verkle ツリーを使用するよりも高速になります。これは、ハッシュベースのアプローチにより、フルノードの同期時間を短縮できることを意味します。
Verkle ツリーには興味深い監視更新プロパティがあります。Verkle ツリー監視は更新可能です。このプロパティは、メモリプール、インクルード リスト、その他のユースケースに役立ち、実装の効率化にも役立ちます。状態オブジェクトが更新されると、最後の層の内容を読み取らずに最後から 2 番目の層の監視を更新できます。
バークルの木はSNARK耐性がより困難です。 Verkle 証明では、証明サイズを数キロバイトまで削減したい場合、いくつかの困難が生じます。これは、Verkle 証明の検証では多数の 256 ビット操作が導入され、証明システムに大きなオーバーヘッドがあるか、証明システム自体に 256 ビット Verkle 証明部分を含むカスタムの内部構造が必要になるためです。これは無国籍そのものの問題ではありませんが、さらに多くの問題を引き起こします。
量子安全かつ合理的に効率的な方法で Verkle Witness の更新可能性を取得したい場合、別の可能なアプローチは格子ベースの Merkle ツリーです。
最悪の場合、システムの効率が十分ではないことが判明した場合は、この欠点を補うために多次元ガスという予期せぬツールを使用することもできます。 ) 状態アクセスと、場合によっては他の異なるリソースが個別のガス制限を設定します。多次元ガスは複雑さを加えますが、その代わりに平均的なケースと最悪のケースの間の比率をより厳密に制限します。多次元ガスを使用すると、証明する必要がある分岐の最大数は理論的には 12500 から、たとえば 3000 に減らすことができます。これにより、現在でも BLAKE 3 が（かろうじて）十分になります。
多次元ガスにより、ブロックのリソース制限を基盤となるハードウェアの制限とより厳密に一致させることができます
もう 1 つの予期しないツールは、ブロック後のタイムスロットまで状態ルートの計算を遅らせることです。これにより、状態ルートの計算に丸 12 秒かかります。これは、最も極端なケースでも、証明時間としては 1 秒あたり 60,000 ハッシュだけが十分であることを意味します。このことからも、BLAKE 3 は要件をかろうじてしか満たすことができないと考えられます。
このアプローチの欠点は、軽いクライアント レイテンシのスロットが 1 つ追加されることですが、このレイテンシを単なる証明生成レイテンシに削減できる、より賢明な手法があります。たとえば、ノードが証明を生成すると、次のブロックを待つのではなく、すぐに証明をネットワーク上でブロードキャストできます。
ロードマップの他の部分とどのように相互作用するのでしょうか?
ステートレス問題を解決すると、一人の固定点の難易度が大幅に上がります。 Orbit SSF などのシングル プレイヤー ターゲティングの最小バランスを下げるテクノロジーや、分隊ターゲティングなどのアプリケーション レイヤー戦略があれば、これはより実現可能になります。
EOFも導入すると多次元ガス分析が容易になります。これは、多次元ガスの主な実行の複雑さは、親呼び出しのすべてのガスを渡さないサブコールを処理することに起因しており、EOF はそのようなサブコールを不正にするだけでこの問題を簡単に (そしてネイティブに) 解決できるためです。現在のガスの主な使用例の一部に対するプロトコル内の代替手段。
ステートレス検証と履歴の有効期限の間には重要な相乗効果もあります。現在、クライアントは 1 テラバイト近くの履歴データを保存する必要があり、このデータは状態データの何倍も大きくなります。たとえクライアントがステートレスであっても、履歴データを保存する責任からクライアントを解放できなければ、ほぼストレージレスのクライアントの夢は実現しません。この点に関する最初のステップは EIP-4444 です。これは、ポータル ネットワークのトレントまたはポータルに履歴データを保存することも意味します。
EVM実行の有効性の証明
私たちはどのような問題を解決しようとしているのでしょうか?
イーサリアム ブロック検証の長期的な目標は明確です。(i) ブロックをダウンロードするか、ブロック内の利用可能なデータの小さなサンプルのみをダウンロードすることによって、イーサリアム ブロックを検証できるようにする必要があります。(ii) 領域を検証する。仕事を妨げる小さな証拠。これは非常に低リソースの操作であり、モバイル クライアント、ブラウザ ウォレット、または別のチェーン (データ可用性部分なし) でさえ実行できます。
これを達成するには、(i) コンセンサス層 (つまりプルーフ オブ ステーク) と (ii) 実行層 (つまり EVM) で SNARK または STARK プルーフが必要です。前者はそれ自体が課題であり、コンセンサス層のさらなる改善（シングルスロットのファイナリティなど）で対処する必要があります。後者には EVM 実行の証明が必要です。
それは何ですか?またどのように機能しますか?
正式には、イーサリアム仕様では、EVM は状態遷移関数として定義されています。つまり、事前状態 S とブロック B があり、事後状態 S = STF(S, B) を計算しています。ユーザーがライト クライアントを使用している場合、ユーザーは S と S、さらには E を完全には所有していません。代わりに、状態前のルート R、状態後のルート R、およびブロック ハッシュ H を持ちます。
パブリック入力: 状態前のルート R、状態後のルート R、ブロック ハッシュ H
プライベート入力: ブロック本体 B、ブロック Q によってアクセスされる状態のオブジェクト、ブロック Q の実行後の同じオブジェクト、状態証明 (例: マークル分岐) P
主張 1: P は、Q に R で表される状態の一部が含まれていることの有効な証明である
主張 2: Q で STF を実行すると、(i) 実行は Q 内のオブジェクトにのみアクセスし、(ii) データ ブロックは有効で、(iii) 結果は Q になります。
主張 3: Q と P の情報を使用して新しい状態ルートを再計算すると、R が得られます。
これが事実であれば、イーサリアム EVM の実行を完全に認証する軽量クライアントを使用することが可能になります。これにより、クライアントのリソースはすでにかなり少なくなってしまいます。本当に完全に検証された Ethereum クライアントを実現するには、コンセンサス側でも同じ作業を行う必要があります。
EVM 計算の妥当性証明の実装はすでに存在しており、L2 によって頻繁に使用されています。 EVM の有効性証明を L1 で実現可能にするためには、やるべきことがまだたくさんあります。
既存の研究とのつながりは何ですか?
他に何ができるでしょうか?
今日、電子会計システムの有効性は、セキュリティと検証時間という 2 つの領域で不十分であることが判明しています。
安全な有効性を証明するには、SNARK が EVM の計算を実際に検証し、脆弱性がないことを確認する必要があります。セキュリティを向上させるための 2 つの主な手法は、複数のバリデータと形式的検証です。マルチバリデーターとは、複数のクライアントが存在するのと同じように、独立して作成された複数の妥当性証明実装があることを指します。ブロックがこれらの実装の十分に大きなサブセットによって証明された場合、クライアントはブロック部分を受け入れます。形式的検証には、リーン 4 などの数学的定理の証明に通常使用されるツールを使用して、妥当性証明が基礎となる EVM 仕様 (EVM K セマンティクスや Python で記述されたイーサリアム実行層仕様 (EELS) など) の正しい実行のみを受け入れることを証明することが含まれます。 。
検証時間が十分に速いということは、どのイーサリアム ブロックも 4 秒未満で検証できることを意味します。 2 年前に考えていたよりもはるかに近づいていますが、今日、私たちはその目標にはまだ程遠いです。これを達成するには、次の 3 つの方向で進歩する必要があります。
並列化 – 現在の最速の EVM バリデータは、平均 15 秒で Ethereum ブロックを証明できます。これは、数百の GPU 間で並列処理を行い、最後にそれらの作業を一緒にプールすることで実現されます。理論的には、O(log(N)) 時間で計算を証明できる EVM 検証器を作成する方法を正確に知っています。GPU に各ステップを完了させ、最後に「集計ツリー」を作成します。
これを達成するには課題があります。非常に大規模なトランザクションがブロック全体を占有する最悪のシナリオでも、計算の分割はパスごとに行うことはできず、オペコード (EVM や RISC-V などの基盤となる仮想マシンのオペコード) ごとに行う必要があります。仮想マシンの「メモリ」が構成証明の異なる部分間で一貫性を保つようにすることは、実装時の重要な課題です。ただし、この種の再帰的証明を実装できれば、他の側面に改善がなくても、少なくとも証明者の待ち時間の問題は解決されたことがわかります。
証明システムの最適化 - Orion、Binius、GRK などの新しい証明システムにより、汎用計算の検証時間がさらに大幅に短縮される可能性があります。
EVM のガス コストに対するその他の変更 - EVM の多くの点は、特に最悪の場合のシナリオにおいて、証明者にとってより有益になるように最適化できます。攻撃者が証明者を 10 分間ブロックするブロックを構築できる場合、通常のイーサリアム ブロックを 4 秒で証明するだけでは十分ではありません。必要な EVM の変更は、次のカテゴリに大別できます。
- ガスコストの変化 - 演算の証明に時間がかかる場合、たとえ計算が比較的速くても、ガスコストは高くなります。 EIP-7667 は、この点で最も深刻な問題に対処するために提案された EIP です。(従来の) ハッシュ関数のオペコードとプリコンパイルが比較的安価であるため、ハッシュ関数のガス コストが大幅に増加します。これらのガスコストの増加を補うために、比較的耐性の低い EVM オペコードのガスコストを削減し、平均スループットを一定に保つことができます。
- データ構造の置き換え - 状態ツリーをより STARK フレンドリーなアプローチに置き換えることに加えて、トランザクション リスト、レシート ツリー、およびコストがかかることが判明しているその他の構造も置き換える必要があります。 Etan Kissling の EIP によるトランザクションと領収書の構造を SSZ に移行することは、この方向への一歩です。
さらに、前のセクションで説明した 2 つのツール (多次元ガスと遅延状態ルート) もこの点で役立ちます。ただし、ステートレス検証とは異なり、これら 2 つのツールを使用すると、現在必要なことを実行するのに十分なテクノロジがすでにあることを意味し、これらのテクノロジを使用した場合でも、完全な ZK-EVM 検証にはより多くの作業が必要になります。必要な作業が少なくなるだけであることに注意してください。仕事。
上記で言及されていない点の 1 つは、証明者ハードウェアです。つまり、GPU、FPGA、および ASIC を使用して証明をより速く生成します。 Fabric Cryptography、Cysic、Accseal の 3 社がこの分野で進歩を遂げています。これは L2 にとって非常に価値がありますが、L1 にとっては決定的な考慮事項にはなりそうにありません。L1 が高度に分散化された状態を維持することが強く望まれているためです。つまり、証明の生成はイーサリアム ユーザーの合理的な範囲内で行われるべきであり、規制の対象となるべきではありません。単一企業のハードウェアのボトルネック制限。 L2 では、よりプラスのトレードオフが可能になります。
以下の分野では、さらに取り組むべきことがあります。
並列化の証明には、システムのさまざまな部分 (ルックアップ テーブルなど) が「メモリを共有」できることを証明する必要があります。私たちはこれを実現するテクノロジーを知っていますが、実装する必要があります。
最悪の場合の検証時間を最小限に抑える理想的なガスコスト変動のセットを見つけるには、さらに分析を行う必要があります。
システムを証明するためにさらに取り組む必要がある
考えられるコストは次のとおりです。
セキュリティと検証時間: より積極的なハッシュ関数、より複雑な証明システム、またはより積極的なセキュリティの仮定やその他の設計ソリューションを選択すると、検証時間を短縮することができます。
分散化と証明者のタイミング: コミュニティは、対象となる認証者ハードウェアの「仕様」について合意する必要があります。認証機関に大規模な事業体であることを要求しても問題ありませんか?ハイエンドの消費者向けラップトップが 4 秒でイーサリアムブロックを証明できると期待できますか?その中間のどこかでしょうか？
下位互換性が損なわれる程度: 他の欠点は、より積極的なガスコストの変更によって補うことができますが、これにより一部のアプリケーションのコストが不釣り合いに増加する可能性が高く、開発者は経済的に実行可能な状態を維持するためにコードの書き直しと再デプロイを余儀なくされます。同様に、どちらのツールにも独自の複雑さと欠点があります。
ロードマップの他の部分とどのように相互作用するのでしょうか?
L1 EVM 有効性証明の実装に必要なコア テクノロジーは、主に他の 2 つの領域と共有されています。
L2 の有効性の証明 (つまり、「ZK ロールアップ」)
ステートレスな「STARK バイナリ ハッシュ プルーフ」方式
L1 での有効性証明の実装が成功すると、最終的には 1 人で簡単にステーキングできるようになります。最も弱いコンピューター (携帯電話やスマートウォッチを含む) でもステーキングできます。これにより、最小 32 ETH などのシングル ステーキングの他の制限に対処する価値がさらに高まります。
さらに、L1 の EVM の妥当性は、L1 のガス制限を大幅に改善できることを証明しています。
合意の有効性の証明
私たちはどのような問題を解決しようとしているのでしょうか?
SNARK を使用してイーサリアム ブロックを完全に検証したい場合、証明する必要があるのは EVM の実行だけではありません。また、コンセンサスの証明、つまり入金、出金、署名、バリデーター残高の更新、およびイーサリアムのプルーフ・オブ・ステーク部分のその他の要素を処理するシステムの一部も必要です。
コンセンサスは EVM よりもはるかに単純ですが、課題は、L2 EVM 畳み込みがないため、とにかくほとんどの作業を実行する必要があることです。したがって、プルーフ・イーサリアム・コンセンサスの実装は「ゼロから始める」必要がありますが、プルーフ・システム自体は共有の取り組みを基礎にして構築することができます。
それは何ですか?またどのように機能しますか?
ビーコン チェーンは、EVM と同様に状態遷移関数として定義されます。状態遷移関数は主に次の 3 つの部分で構成されます。
ECADD (BLS 署名の検証用)
ペアリング (BLS 署名の検証用)
SHA 256 ハッシュ (ステータスの読み取りと更新に使用)
各ブロックでは、各バリデーターに対して 1 ～ 16 個の BLS 12-381 ECADD を証明する必要があります (署名は複数のセットに含まれる可能性があるため、おそらく複数)。これはサブセット事前計算技術によって補正できるため、各検証者は 1 つの BLS 12-381 ECADD を証明するだけで済みます。現在、スロットごとに 30,000 のバリデーター署名があります。将来的には、単一スロットのファイナリティが達成されると、この状況は 2 つの方向に変化する可能性があります。「総当たり」ルートを選択した場合、スロットあたりのバリデーターの数は 100 万に増加する可能性があります。同時に、Orbit SSF が採用された場合、バリデーターの数は 32,768 人のまま、あるいは 8,192 人に減少することもあります。
BLS アグリゲーションの仕組み: 署名全体の検証には、ECMUL ではなく、参加者ごとに 1 つの ECADD のみが必要です。しかし、30,000 ECADD は依然として多くの証拠です。
ペアリングに関しては、現在スロットごとに最大 128 個のプルーフがあり、128 個のペアリングを検証する必要があることを意味します。 ElP-7549 とさらなる修正により、これをスロットあたり 16 に減らすことができます。ペアの数は少ないですが、コストは非常に高くなります。各ペアの実行 (または証明) には ECADD の数千倍の時間がかかります。
BLS 12-381 演算を証明する際の大きな課題は、BLS 12-381 フィールド サイズと等しい曲線次数を持つ便利な曲線が存在しないことであり、これにより証明システムにかなりのオーバーヘッドが追加されます。一方、イーサリアム用に提案されているバークルツリーはバンダースナッチ曲線を使用して構築されており、BLS 12-381 自体が SNARK システム内のバークル分岐を証明するために使用される自己曲線になります。比較的単純な実装では、1 秒あたり 100 G 1 の加算を証明できますが、証明を十分に高速にするには、ほぼ確実に GKR のような賢いテクニックが必要です。
現時点での SHA 256 ハッシュの最悪のシナリオは、バリデーターショートバランスツリー全体と多数のバリデーターバランスが更新されるエポック遷移ブロックです。各バリデーターの短いバランス ツリーは 1 バイトのみであるため、1 MB のデータが再ハッシュされます。これは、32768 回の SHA 256 呼び出しに相当します。 1,000 のバリデータの残高がしきい値を上回るか下回る場合、バリデータ レコードの有効な残高を更新する必要があります。これは 1,000 のマークル分岐に相当するため、1 万のハッシュが必要になる場合があります。シャッフル メカニズムにはバリデータあたり 90 ビット (したがって 11 MB のデータ) が必要ですが、これはエポック中にいつでも計算できます。単一スロット終端の場合、これらの数はケースバイケースで増減する可能性があります。シャッフルは不要になりますが、Orbit によってシャッフルの必要性がある程度回復される可能性があります。
もう 1 つの課題は、ブロックを検証するために公開キーを含むすべてのバリデーターの状態を再取得する必要があることです。 100 万人のバリデータの場合、公開キーの読み取りだけで 4,800 万バイトと Merkle ブランチが必要になります。これには、エポックごとに数百万のハッシュが必要です。 PoS の有効性を証明しなければならない場合、現実的なアプローチは、何らかの形式の増分検証可能な計算です。つまり、効率的に検索し、構造が更新されることを証明するように最適化された単一のデータ構造を証明システム内に保存します。
全体として、多くの課題があります。これらの課題に最も効果的に対処するには、ビーコン チェーンの大幅な再設計が必要になる可能性があり、これは単一スロット終端への移行と同時に行われる可能性があります。この再設計の特徴は次のとおりです。
ハッシュ関数の変更: 「完全な」SHA 256 ハッシュ関数が使用されるようになったため、パディングにより呼び出しごとに基礎となる圧縮関数への呼び出しが 2 回行われます。代わりに SHA 256 圧縮関数を使用すると、少なくとも 2 倍のゲインが得られます。代わりに Poseidon を使用した場合、100 倍の利益が得られ、すべての問題 (少なくともハッシュの点で) が完全に解決される可能性があります。100 万件の検証を行っても、1 秒あたり 170 万ハッシュ (54 MB) で記録が「読み取られる」ことも可能です。数秒で証明が完成します。
Orbit の場合、シャッフルされたバリデーター レコードを直接保存します。特定の数のバリデーター (8192 や 32768 など) が特定のスロットの委員会として選択された場合、次のように、それらを直接隣り合った状態に置きます。すべてのバリデーターの公開鍵を証明に読み取るにはハッシュが必要です。これにより、すべての残高更新を効率的に完了することもできます。
署名集約: 高性能の署名集約スキームには、ネットワーク内のさまざまなノードが署名のサブセットに対して中間証明を実行する、ある種の再帰的証明が含まれます。これにより、自然に証明作業がネットワーク内の複数のノードに分散され、「最終証明者」の作業負荷が大幅に軽減されます。
その他の署名スキーム: Lamport+Merkle 署名の場合、署名を検証するには 256 + 32 のハッシュが必要ですが、32768 人の署名者を掛けると、9437184 のハッシュが得られます。署名スキームを最適化した後、この結果は小さな定数係数によってさらに改善できます。ポセイドンを使用すると、これが単一スロット内で実証されます。ただし、実際には、再帰的な集計スキームを使用した方が高速です。
既存の研究とのつながりは何ですか?
やるべき作業は何か、そしてその選択方法は次のとおりです。
実際には、イーサリアムコンセンサスの有効性を証明できるまでには何年もかかります。これは、単一スロットのファイナリティ、Orbit の実装、署名アルゴリズムの変更、およびポセイドンのような「積極的な」ハッシュ関数を使用するのに十分な信頼性が必要なセキュリティ分析に要した時間とほぼ同じです。したがって、最も賢明な方法は、STARK との親和性を念頭に置きながら、これらの他の問題に対処することです。
主なトレードオフは、イーサリアムのコンセンサス層を改革するためのより漸進的なアプローチと、より根本的な「一度に多くを変更する」アプローチの間の操作順序にあると考えられます。 EVM の場合、下位互換性の中断を最小限に抑えるため、増分アプローチが合理的です。コンセンサス層に対する下位互換性への影響は少なくなり、SNARK との親和性を最適化するためにビーコン チェーンがどのように構築されるかについてのさまざまな詳細をより「包括的に」再考することにも利点があります。
ロードマップの他の部分とどのように相互作用するのでしょうか?
イーサリアム PoS の長期的な再設計では、STARK の使いやすさ、特に単一スロットのファイナリティ、オービット、署名スキームの変更、および署名の集約を第一に考慮する必要があります。
