Vitalik: なぜ 1 つのスロットでファイナライズを達成しようとするのでしょうか?
著者: ヴィタリック・ブテリン
この投稿のさまざまなバージョンに対するフィードバックやコメントをくださった Justin Drake、Dankrad Feist、Alex Obadia、Hasu などに心より感謝いたします。
現在、(ビーコン チェーン) イーサリアム ブロックはファイナライズに達するまでに 64 ～ 95 スロット (約 15 分) かかります。分散化/ファイナライズ時間/コストのトレードオフ曲線では、どの側面でも悪くない、中程度の長さのトレードオフを選択するのが合理的です。15 分は長すぎず、現在の確認時間に匹敵します。これにより、(以前の要件である 1500 ETH の代わりに) 32 ETH をステーキングした多数のバリデーターがいる場合でも、ユーザーは通常のコンピューターでノードを実行できます。ただし、ファイナライズ時間を 1 つのスロットに短縮するための適切な議論は数多くあります。この記事は、これを行うためのいくつかの考えられる戦略を評価した研究投稿です。
01. 現在のイーサリアムステーキングがどのように、そしてなぜ機能するのか
現在、約 285,000 人のバリデーターがおり、これらのアカウントは 32 ETH を入金しているため、イーサリアムのステーキングに参加できます。バリデーターの数は、実際にステーキングに参加しているユーザー (ステーカー) の数と正確には一致しません。一部の裕福なステーカーは数百のバリデーターを管理している場合があります。 32 ETH という最小ステーク要件により、使用可能なバリデーター アカウントの数が制限され、イーサリアム チェーンがこれらのアカウントを処理するためのコンピューティング能力を確保できるようになります。
スロットごと (12 秒)、新しいブロックがチェーンに追加されます。各スロットには、（ビーコン チェーン）チェーン ヘッドの投票に使用される（バリデーターによって送信された）数千の証明書もあります。これらの証明を入力として受け取り、チェーンの先頭を決定する LMD GHOST と呼ばれるフォーク選択ルールがあります。この数千のプルーフによる並行投票により、イーサリアムは従来の最長チェーン システムよりもはるかに堅牢になり、アクティブな攻撃や重大なネットワーク障害が発生しない限り、単一のスロットであっても、ほぼ常に使用できなくなります。
これらの証明には 2 番目の目的もあります。Casper FFG と呼ばれる大規模なコンセンサス アルゴリズムの投票として機能します。エポックごと (32 スロットごと、約 6.4 分をエポックと呼びます)、すべてのアクティブな検証者は証明を行う機会があります。 2 ラウンドの後、すべてがうまくいけば、前のエポック (およびその中のすべてのブロック) が確定されます。ブロックが完了すると、そのブロックを元に戻すには、すべてのバリデーターの少なくとも 1/3 がデポジット (賭け金) を破棄する必要があります。攻撃のコストは 300 万 ETH 以上です。
バリデータやトランザクションを継続的に検閲することにもコストがかかりますが、検閲攻撃に対抗するには追加のプロトコル介入が必要です。 51% のバリデーター (バリデーターまたはトランザクション) が検閲を開始した場合、被害者とユーザーは少数のソフト フォークを調整して、互いのブロックを構築し、攻撃者を無視することができます。この少数のソフト フォークでは、非アクティブなリークにより攻撃者のデポジットは数百万 ETH を失い、チェーンは数週間以内にファイナライズを再開します。
02. なぜ単一スロットでファイナライズを達成しようとするのでしょうか?
現状を変えて、単一スロットへのファイナライズ時間を短縮してみてください。これにはいくつかの主な理由があります。
ユーザー体験。ほとんどのユーザーは、完了までに 15 分も待ちたくないでしょう。現在、取引所でさえ、わずか 12 ～ 20 回の確認 (約 3 ～ 5 分) でユーザーのデポジットが「完了」したとみなされることがよくありますが、(真の PoS の完了と比較して) 12 ～ 20 回の PoW 確認は安全性が低くなります。単一スロットの確定は、ユーザーがますます慣れてきているスピードに応えると同時に、非常に高いレベルのセキュリティを提供します。
抗MEV組換え。この記事この記事この議論の詳細については、「」を参照してください。
プロトコルの複雑さとバグを軽減する機会。副題
アイデア1：「超委員会」による1枠の確定を実現
Casper FFG コンセンサスの各ラウンドにすべてのバリデーターが参加するのではなく、数千人のバリデーターで構成される中規模のスーパー委員会 (中規模スーパー委員会) のみが参加し、各ラウンドのコンセンサスを単一のスロットで発生させることができます。関連する技術的なアイデアがこの記事の最初に記載されていますetheresear.ch の投稿で紹介されています。
この投稿ではこのアイデアについて詳しく説明しますが、中心となる原則は次のとおりです。
BFT (Byzantine Fault Tolerant) コンセンサスをエポックごとに実行するのではなく、スロットごとに実行します。これは、トランザクションがブロックに含まれると、1 スロット後にトランザクションを取り消すコストが数千 ETH になることを意味します。
単一のスロットを確定するために、すべてのアクティブなバリデーターに依存するわけではありません。代わりに、個々のスロットを最終決定するために、ランダムに選択された数千人のバリデータからなる「スーパー委員会」に依存しています。
画像の説明
副題
「スーパー委員会」への移行による副次的なメリット
グローバルバリデーターからスーパー委員会への移行には、いくつかのインセンティブの利点もあります。
バリデーター ノードを実行するための計算負荷がより安定しました。バリデーター・ノードを実行するためのコンピューティング要件は、バリデーターの総数に比例する必要がなくなり、バリデーターには、バリデーターの数の大幅な増加に対応する強力なマシンが必要になりますが、検証ノードがより安定するため、検証ユーザーはどのようなコンピューティングが必要かを正確に知ることができます。
ほとんどの場合、バリデーターは即座に撤退できます。副題
スーパー委員会はどれくらいの規模でなければなりませんか?
スーパー委員会はバリデーターの数という点で「安全な委員会となるのに十分な規模」でなければならない。ただし、委員会は総ETH（つまり、委員会内のすべてのバリデーターの合計出資額）の観点から十分な規模でなければなりません。削減され妨害されたETHの量は、攻撃によって実際に得られる量よりも大きい必要があり、チェーンを混乱させる巨大な外部インセンティブを持つ強力な攻撃者を阻止または破産させるのに十分な量である必要があります。
どのくらいのETHが必要かというこの問題は、必然的に直感の問題になります。直感を導くためにできる質問をいくつか挙げます。
イーサリアム チェーンが 51% 攻撃されたと仮定すると、コミュニティがオフチェーン ガバナンス イベントを調整して回復するまでに数日かかりますが、ETH の X % が破壊されます。イーサリアムエコシステムに純利益をもたらすには、この X の大きさはどれくらい必要ですか?
大手取引所で数百万の ETH が盗まれ、攻撃者がその収益を賭けてバリデーター カウントの 51% 以上を獲得したとします。それでは、盗まれたすべての資金が破壊される (スラッシュされる) 前に、バリデーターはブロックチェーン上で 51% 攻撃を何回実行できるでしょうか?
51% の攻撃者がすべての MEV を捕捉するために、非常に短期間にブロックチェーンの再編成を繰り返し開始したとします。攻撃者には 1 秒あたりどのレベルのコストを達成してもらいたいですか?
画像の説明
上: 「イーサリアムを攻撃するための最低コストはいくらだと思いますか?」に関するイーサリアム研究者への内部調査の結果。
レイテンシーに依存しない 51% の攻撃のみに焦点を当てる場合、攻撃コストが 100 万 ETH である場合、複雑な悪意のある A の合計 34% も関与する場合、「スーパー委員会」の規模は 200 万 ETH (約 65,536 人の検証者) になることを意味します。バリデーターへの攻撃とネットワーク操作により、スーパー委員会の規模は 300 万 ETH (約 97,152 人のバリデーター) になります。しかし、イーサリアム チェーンの負荷を現在のレベル (スロットあたり約 9,000 人のバリデータ、または約 288,000 ETH) に維持したい場合、これは 96,000 ～ 144,000 ETH の攻撃コストに相当します。 2 つの数字の間には依然として大きな差があります。
副題
アイデア 2: できるだけ多くの認証者を作業させるよう努める
各スロットに多数のバリデーターが参加するブロックチェーンが本当に必要だとします (たとえば、スロットあたり 131,072 個のバリデーター、控えめに言っても 400 万 ETH に相当します)。では、それに基づいてパフォーマンスの数値はどうなるでしょうか?
スロットあたりのオンチェーンコストが思ったほど高くないことを証明するには、多数のバリデーターが必要であることがわかります。
バリデーター レコードを保存するために必要な状態空間は、現在とまったく同じになります (バリデーターごとに約 150 バイト)。
署名を検証するには、131,072 個の公開鍵のランダムなサブセットを加算する必要があります。各楕円曲線の加算は約 1 マイクロ秒で実行できるため、これは約 130 ミリ秒で実行できます。各スロットは 2 回実行する必要があります (ブロックに冗長なプルーフが含まれている場合はさらに実行される可能性があります)。
スロット N でアクティブなバリデーターが通常はスロット N+1 でもアクティブであると仮定すると、オンチェーンの追加コストをさらに最適化できます。これは、スロットごとに、良好な条件下で変数 (デルタ) を計算するだけでよいことを意味します。条件によっては、集合公開キーは数千、さらには数百のバリデーター公開キーで構成される場合があります。最悪の場合でも、常に少なくとも 2 倍の最適化 (つまり、約 65 ミリ秒) を実行できる必要があります。
残された最大の問題は、署名の集約。 1 つのスロットでは 131,072 の検証者が署名を生成および送信しており、これらの署名を大規模な集約署名に迅速に結合する必要があります。
現在、署名の集約は p2p サブネットワークで行われています。 256 人のバリデーターからなる各委員会には、署名集約の独自のサブネットワークがあります。ランダムに選択された 16 の特権アグリゲータがあり、署名を集約してメイン サブネットに送信できます。次に、ブロック提案者は各委員会から最良の署名集合体を取得し、それらを加算して 1 つの大きな署名集合体を形成します。以下に示すように:
これにより、各サブ委員会に負荷がかかり、バリデーターは署名を個別に検証する必要があり、特にネットワークに無効な署名が大量に送信される攻撃が発生した場合、グローバル サブネットでは、n 個の委員会がある場合、提案者は 16*n 個の署名を実行する必要があります。確認されること。
集約は、今後 2 年間で大幅な最適化の対象となる可能性があります。現在、実際のアプリケーションにおける最大のボトルネックは、特に複数のサブネットに存在する必要があるノードの場合、各サブネットの負荷です。
次の 2 つの有望な単純なアプローチによって、大幅な改善が得られます。
サブネットの数を増やす、各サブネットの負荷を増加させることなく、より多くの合計認証を許可します。メイン サブネットの負荷は増加しますが、ダンク シャーディングによってこれを補うことができます。これにより、スロット内のすべての検証者が同じデータに署名できるようになり、効率が向上し、これらの署名をバッチで検証しやすくなります。
多くのバリデータを持つノードでも 1 つのサブネットにのみ参加する必要があるようにネットワーク ルールを変更します。副題
より特化したアグリゲーター
より多くのバリデーターをサポートするために考えられる、より積極的な戦略は、署名の集約をより特殊な役割に変えることです (PBS のブロック ビルダー (提案者/ビルダー分割) スキーム)、この役割では、専門のアクターが各サブネット (またはすべてのサブネット) に常駐し、署名を適切に収集できることが期待されます。これらの参加者は、報酬を受け取ることも、自発的な役割を担うこともできます (すでに多くのバリデーターをステークしているユーザーにとって、この追加コストは非常に低いため)。
この状況に対する単純なプロトコルは、検証者が、(i) 集約署名、(ii) 参加者のビットフィールド (131,072 検証者を想定して 16 KB)、および (iii) これら 2 つのオブジェクトに対する集約者の署名を含む PromotedAggregate メッセージに署名できるようにすることです。
最初のレベルのタイトル
03. 単一スロットでファイナライズするにはどうすればよいですか?
シングルスロットの確認への移行は数年かかるロードマップであり、多くの開発作業がすぐに開始されるとしても、それはイーサリアムが PoS、シャーディング、Verkle ツリーのロールアウトを完了した後になるでしょう。一般に、実装パスはおおよそ次のとおりです。
証明の集約を最適化する取り組みを強化します。いずれにせよ、バリデーターの数は増加すると予想されるため、これは重要な質問です。この問題に関しては、より集中的な研究開発の取り組みが必要です。
一般的なパラメータについて同意する:「スーパー委員会」の規模はどの程度を目指していますか (または、スーパー委員会の規模はすべてのアクティブなバリデーターのセットであり、アクティブなバリデーターの数を制御するために何らかの別のメカニズムを実装します)?どのレベルのオーバーヘッドが許容されますか?オーバーヘッドを削減するにはどのような手法を使用しますか?
単一のスロットを確定するには、調査を行い、合意に達し、理想的な合意とフォーク選択メカニズムを明確にする必要があります。これは、BFT コンセンサス メカニズム (Casper FFG または別のより伝統的なメカニズム) とフォーク選択ルールを組み合わせたもので、フォーク選択ルールはバリデーターの 1/3 以上がオフラインの場合にのみ意味を持ちます。
導入への道筋に合意し、実行します。これには、複数のステップの実装が必要になる場合があります。そのうちの 1 つではスーパー委員会メカニズムを導入し、次のステップで新しいコンセンサスと集約メカニズムを追加します。
単一スロットでファイナライゼーションを実装することの最終的な利点は重要であり、この技術は時間の経過とともに改善されて、この文書で説明されていない他の利点（たとえば、最大バリデータ数の増加を使用して最小ETHステークを削減するなど）を達成する可能性があります。したがって、この記事で説明されている技術的な課題は、より深く焦点を絞った研究開発をできるだけ早く開始する価値があります。
