Vitalik: 単一スロットでのファイナリティへの道

BTC0.0₂₀

ETH0.0₂₀

HTX0.0₂₀

SOL0.0₂₀

BNB0.0₂₀

BTC0.0₂₀

ETH0.0₂₀

HTX0.0₂₀

SOL0.0₂₀

BNB0.0₂₀

Vitalik: 単一スロットでのファイナリティへの道

ECN以太坊中国

2022-11-01 04:00

本文约7722字，阅读全文需要约31分钟

シングルスロットのファイナリティを達成するために対処する必要がある主な問題は何ですか?

原題：「Paths toward single-slot finality》

原題：「

原作者：ヴィタリック・ブテリン、イーサリアム創設者

原文編集：Double Spending（@doublespending）、ECNコミュニティボランティア

この記事のさまざまなバージョンについてレビューとフィードバックを提供してくれた Justin Drake、Dankrad Feist、Alex Obadia、Hasu、Anders Elowsson、および hackmd 匿名の仲間たちに特別に感謝します。

現在、イーサリアムブロックはファイナリティを達成するために 64 ～ 95 スロット (約 15 分) を必要とします。これは合理的であり、分散化/ファイナリティ時間/オーバーヘッド曲線の妥協点です。15 分は長すぎず、既存の取引所の確認時間に匹敵し、ユーザーはデポジットサイズが 32 であるため多数のバリデーターがあるにもかかわらず、 ETH (初期段階での誓約に必要な 1500 ETH の代わり)。ただし、ファイナリティ時間を短縮する十分な理由がまだあります。スロット

。これは、この目標を達成するためのロードマップをレビューする研究状況のレビューです。

現在の運用モードとイーサリアムステーキングの基礎

イーサリアムの LMD GHOST + Casper FFG コンセンサスは、プルーフオブステークブロックチェーンで人気のある 2 つの主流コンセンサスアルゴリズムの間の妥協案です。チェーンベースのコンセンサスアルゴリズム:
各スロット (イーサリアムでは 12 秒など、事前に設定された時間間隔) でメッセージ (ブロック) が生成されます。チェーンベースのコンセンサスアルゴリズムは参加者の数を最大化し、チェーンの負荷を軽減しますが、フォークが発生しやすく、ファイナリティの概念がありません。従来の BFT (ビザンチンフォールトトレランス) コンセンサスアルゴリズム:

各スロットでは、ブロックを生成するバリデーターを除いて、各バリデーターが 2 つのメッセージ (「証明書」、翻訳者注: つまり「証人」) を生成し、1 つのスロットのブロックが次のスロットに配置されます。不可逆的 "ファイナリティ」は開始前に達成されました。従来の BFT コンセンサスアルゴリズムは、ファイナリティを達成するまでの時間を最小限に抑えますが、チェーンの負荷が高く、少数の参加者のみをサポートするという犠牲を伴います。

純粋なチェーンベースのシステムとは異なり、イーサリアムコンセンサスアルゴリズムは、各スロットでチェーンヘッド上で数千の証人投票を並行して実行します。エポック (32 スロット、または 6.4 分) ごとに、すべてのアクティブなバリデーターは 1 回目撃 (証明) する機会があります。 2 エポック後、Casper FFG ファイナライザーがブロックをファイナライズし、それ以降、ブロックをロールバックするには、少なくとも 3 分の 1 のバリデーターがステークデポジットを燃やす必要があり、攻撃コストは 400 万 ETH を超えます。これは、スロットの後にファイナライゼーションが達成される純粋に従来の BFT システムとは区別されます。

したがって、イーサリアムが今日達成していることは次のとおりです。中程度のファイナライズ時間
— 単一スロットでの従来の BFT ファイナライズに比べて時間がかかりますが、数週間や数か月ではなく、チェーンベースのコンセンサスアルゴリズムのように提供されることもありません適度なチェーン負荷
- スロットあたり数千のメッセージですが、従来の BFT を使用する場合は数十万未満のメッセージ適度な数のノード

——検証者になるには32 ETHのプレッジが必要: チェーンベースのコンセンサスアルゴリズムと比較して閾値が高く、チェーンベースのコンセンサスアルゴリズムでは少量のトークンでもコンセンサスに参加できます。トークンがしきい値を大幅に下回っています

イーサリアムによる高強度チェーンロードのサポートは、BLS 署名集約の効率向上によって可能になります。これらの効率の向上により、高強度 (1 秒あたりのメッセージ数の観点から) が可能なチェーンロードを、中程度のデータと CPU オーバーヘッドのみを必要とするチェーンロードに変換できます。

BLS 署名集約は、複数の署名を 1 つに集約することによって機能します。そのため、集約された署名の検証には、参加者あたり 1 つの追加の楕円曲線加算 (乗算ではなく) のみが必要であり、64 バイトで任意の数の参加者に対応できますが、各参加者は追加のビットを 1 つだけ必要とします。店。

チェーンベースのコンセンサスアルゴリズムと従来の BFT コンセンサスアルゴリズムの組み合わせと、BLS から得られる純粋な効率の向上が、イーサリアムの現在のコンセンサスアルゴリズムを形成しています。

では、なぜ変更するのでしょうか?

オリジナルのイーサリアムコンセンサスプロトコルが上記の推論に基づいて開発されて以来、数年間に大きな良いニュースと大きな悪いニュースがありました。

悪いニュース: ハイブリッドコンセンサスメカニズムには実際には多くの避けられない問題がある

ハイブリッドコンセンサスメカニズムは、フォーク選択ルールとファイナリティツールを組み合わせたもので、前者はスロットごとにコンセンサスを進めるために使用され、後者は後でブロックをファイナライズするために使用されます。ハイブリッドコンセンサスメカニズムの最大の問題は次のとおりです。

ユーザーエクスペリエンス: ほとんどのユーザーは、トランザクションが完了するまで 15 分も待ちたくありません。現在、取引所でさえ、一般に 12 ～ 20 回の確認 (約 3 ～ 5 分) 後にデポジットが「完了」したと見なされますが、12 ～ 20 回の PoW 確認ではセキュリティ保証が弱くなります (PoS の完了と比べて実際とは異なります)。
MEV の再編成: ハイブリッドコンセンサスメカニズムでは、短期的な再編成が可能であるという事実が依然として残っており、そのため、ほぼ過半数または過半数を有する悪意のあるバリデータが、ブロックチェーンの再編成を共謀して MEV の価値を抽出するための扉を開いています。この記事では、この議論をさらに詳しく展開します。
相互作用の欠陥: Casper FFG のファイナライゼーションと LMD GHOST フォークの選択の間の「インターフェイス」は、重大な複雑さの原因となっており、修正にかなり複雑なパッチを必要とする多くの攻撃につながり、さらに多くの弱点が時折発見されます。

プロトコルのさらなる複雑さ: バリデータセットシャッフルなどのメカニズムを維持するために、数百行の仕様が使用されます。

朗報: BLS 集約により、非常に大規模なバリデータセットが想像以上に可能になる

BLS によって達成される具体的な効率は過去 3 年間で飛躍的に向上し、私たちは大量のメッセージとデータを効率的に処理して結合する方法についてさらに学びました。

BLS を使用して多数のバリデータをサポートすると、次の 2 つの大きなボトルネックに直面します。
最終検証: N 人の検証者からの署名を検証するには、グループ公開鍵を計算するために最大 N/2 ECADD と、参加者を保存するために N ビット (N/8 バイト) のビットフィールドが必要です。実際には、ビューのマージに必要な冗長なアグリゲータにより、これらの数は 16 倍も増加する必要があります。

集約: N 人の検証者のそれぞれによって送信された署名を集約署名に結合します。これには、処理するには合計で少なくとも 96*N バイトの帯域幅が必要で、G2 グループの上に少なくとも N 個の ECADD が必要です (計算量が 4 倍以上) が、サブネット間での分散がより簡単になります。

実際、最終的な検証は非常にうまくスケールされます。 1 つの ECADD は約 500 ナノ秒 (ns) で実行できるため、100 万回の ECADD には約 500 ミリ秒 (ms) かかります。 100 万個のバリデータビットフィールドのサイズはわずか 128 KB です。

ビューマージの冗長性では、スロットごとに最大 16 個の個別の署名を検証する必要がある場合があります。これにより、データストレージ要件がまだ管理可能な 2 MB (EIP-4844 のブロックあたりの BLOB データのサイズ上限とほぼ同じ) に増加します。ブロックあたりの呼び出しデータサイズの現在の上限）、最悪の場合の ECADD 操作コストは約 8 倍に増加します（巧妙な事前計算トリックにより、16 倍に増加する必要はありません）。

これらは最悪の場合の値であり、通常の場合、16 個のアグリゲータのビットフィールドはほぼ同一であるため、複数のアグリゲーションによる大きな追加コストを圧縮できます。

集計はさらに困難ですが、かなり実行可能です。最近の研究により、多数の署名を 1 つのスロット内に集約する方法についての理解が大幅に深まりました。幸いなことに、スロットごとに数十万の署名を処理することが可能であると信じる十分な理由があるということですが、最適なソリューションを特定して合意するには、さらなる研究作業がまだ必要です。

これら 2 つの事実を組み合わせると、トレードオフはもはやチェーンベースの PoS と BFT ベースの PoS の間の妥協に傾いているのではなく、ブロックごとの完全な従来の BFT ルートに近いソリューションになっていることがわかります。

単一スロットのファイナリティを達成するには、どのような重要な問題に対処する必要がありますか?

重要な質問が 3 つあります。正確なコンセンサスアルゴリズムを開発する: 私たちはこれを非常に重視しているため、Tendermint や他の既存の BFT アルゴリズムをあまり受け入れません。バリデーターがオフラインの場合でも、ブロックチェーンは生き続けることができます (これは従来の BFT では提供されません)。この活性化を可能にするために、フォーク選択ルール、非アクティブリーク、および回復メカニズムを追加する必要があります。理想的には、最適なセキュリティが得られます。ネットワークが同期されている場合、フォールトトレランスレートは次のようになります。。
; ネットワークが同期していない場合、フォールトトレランスレートは最適な集約戦略を決定します。可能な限り最高のから集計したい
バリデーターの署名を取得してブロックにパックすると、ノードのオーバーヘッドは許容できるレベルになります。

バリデーターの経済モデルを決定します。集約と最終検証の 2 つのステップが改善されたにもかかわらず、単一スロットのファイナライズされたイーサリアムは、最終的には現在のイーサリアムよりも少ないバリデーター数の理論上の上限をサポートできるようになる可能性があります。この数が参加バリデーターの数を下回った場合、参加をどのように制限し、どのような犠牲を払うのでしょうか?

正確なコンセンサスアルゴリズムはどのようなものになるでしょうか?

前述のように、Casper FFG + LMD GHOST の「ファイナライゼーションチェーン + オプティミスティックチェーン」パラダイムに従うコンセンサスアルゴリズムが必要です。極端な条件下では、オプティミスティックチェーンはロールバックできますが、ファイナライゼーションチェーンは決してロールバックできません。これには、既存のコンセンサスと同様のフォーク選択ルールとファイナリティツールの組み合わせが必要ですが、1 つの重要な違いがあります。現在、通常、フォーク選択ルールとファイナリティツールは同時に実行されますが、単一のスロットでファイナリティの世界では、フォーク選択ルール、またはファイナリティツール: 未満の場合

のバリデーターがオンラインで正常に動作している場合は前者を実行し、そうでない場合は後者を実行します。

このアルゴリズムの具体的な提案はまだ進行中であり、正式な結果や論文はまだ発表されていません。

最適な集約戦略を開発する上での問題は何ですか?まず、現在集計がどのように行われているかを見てみましょう。 1 つのスロットには約検証者は次のように分類されます。委員会、それぞれ約

検証者。まず、各委員会のバリデーターは、その委員会専用の P2P サブネットで署名をブロードキャストします。各委員会には 16 の指定されたアグリゲータがあり、各アグリゲータは確認したすべての署名を結合して 1 つの集約署名 (96 バイト + 256 ビットフィールド) にします。指定されたアグリゲータは、集約された署名をメインサブネットに公開します。

次に、ブロックの提案者は、各委員会から集約された署名のうち最も優れたもの (つまり、参加者の合計バランスが最も大きいもの) を選択し、それをブロックに詰め込みます。ビューマージフォーク選択用のパッチでは、他の集約の署名を含むサイドカーオブジェクトも追加されます。これにより、各委員会の少なくとも 1 つのアグリゲータが正当なアグリゲータの影響を受けている限り、ビューマージメカニズムが悪意のある動作から保護されます。このモデルを単一のスロットがファイナリティを達成するシナリオに拡張したい場合は、すべてのスロットを処理できる必要があります。

(または、どんなに多くても) バリデーター。これには、次の 2 つのトレードオフのいずれかが必要です。
より多くのバリデーターに対応するには、1 つの委員会のバリデーターの数を増やすか、委員会の数を増やすか、あるいはその両方を行います。3層の集合体、2層の委員会構造に移行します。まず、署名は次のように分割されます。のグループが集約されると、サイズは次のようになります。

グループ、そして最後にバリデーターの完全なセットです。

前者はより大きな p2p ネットワーク帯域幅を必要とし、後者はより高いレイテンシーを必要とし、ビューのマージがすべてのレベルの悪意のあるアグリゲータの影響を受けないようにするため、p2p サブネットレベルが高くなるにつれてリスクが高まり、複雑さが増します。

これら 2 つの戦略に関する分析研究が進行中です。

バリデータ経済モデルにはどのような問題があるのでしょうか?現在、イーサリアムには約アクティブなバリデーター (正確には執筆時点で 445,064) がおり、それぞれ 32 ETH がステーキングされています。単一スロットのファイナリティが達成されるまでに、バリデーターの数は次のように増加する可能性があります。

またはそれ以上です。

これは大きな問題を引き起こします。スロットごとに N 人のバリデーターからの署名しか処理できないが、N 人を超えるバリデーターが参加したい場合、誰が参加し誰が残るかをどのように決定すればよいでしょうか?

どのような解決策であっても、セキュリティの保証と考えられるステーキングシステムの 1 つ以上の機能を弱体化する必要があるため、これは重大な問題です。

朗報: 自発的なバリデータ残高統合のサポートによるメリット

シングルスロットのファイナリティでは委員会の概念が削除されるため (ダンクシャーディングでさえ固定サイズの委員会を使用しないため)、バリデーターの有効残高上限である 32 ETH はもう必要ありません。 p2p ネットワークの安定性を考慮すると、依然として高い上限 (例: 2048 ETH) が必要ですが、これでも、リッチユーザーに属する多数のバリデータスロットが少数のバリデータスロットに統合されることを意味します。。

Zipf の法則を使用して、裕福なユーザーとバリデータースロットを統合することの見返りを見積もることができます。特定の残高を持つステーカーの数は、その残高に反比例します (つまり、残高 100 ～ 2000 ETH を持つステーカーの数は、その数と等しくなります)参加者の数の 10 倍、1000 ～ 2000 ETH の残高を持つステーカーの数）。

ビーコンチェーンの初期の履歴データを使用すると、Zipf の法則は分布にかなり正確に適合しているようです。ジップの法則に従うと仮定すると、ステークはおよそETH、今日必要ですバリデータースロット。バンドルこの式に 3,350 万 ETH を入力すると、合計 65,536 人の誓約者を得ることができ、今日のイーサリアムは消費する必要があります。

バリデータースロット。したがって、有効なバランスの上限を完全に削除すると、処理する必要があるバリデータースロットの数が 65536 に減りますが、2048 ETH の上限（現在の 32 ETH から増加）を維持すると、追加のバリデーターは約 1000 ～ 2000 個だけ追加されます。現在のケースでは、単一スロットのファイナリティを処理できるようにするために、合計パフォーマンスがわずか約 2 倍、または負荷が約 2 倍になります。

副次的な利点として、これは、残高の一部ではなく全額をステーキングできる小規模なステーカーにとっても公平です (たとえば、現在 48 ETH を所有している人は ETH の 2/3 しかステーキングできません)。ステーキング報酬は自動的に再ステークされるため、小規模なバリデーターでも複利の恩恵を受けることができます。実際、まさにこの理由から、ステーキングの上限を 2048 ETH に引き上げるのは良い考えかもしれません。

ただし、依然として例外に対処する必要があります。(i) バリデーター残高の分配がZipfの法則に従っていない、または(ii) 裕福なバリデーターが残高を統合するつもりがない、または(iii) 3,300万ETHを超えるステークを保有している。

私は、これらの状況に対処するための 2 つの現実的な戦略を考えました。それは、スーパー委員会とバリデーターセットのサイズに上限を設けることです。

アイデア 1: スーパー委員会

すべてのバリデーターが Casper FFG の各ラウンドに参加するわけではなく、数万人で構成される中規模のスーパー委員会のみが参加するため、各ラウンドのコンセンサスはスロット内で発生します。

この技術的なアイデアは、この投稿で初めて紹介されました。この投稿ではこのアイデアについて詳しく説明していますが、中心となる原則は単純です。常に、バリデーターの完全なセットからランダムに抽出された、中規模のスーパー委員会 (例: 400 万 ETH 相当) が 1 つだけアクティブです。チェーンがファイナリティに達するたびに委員会が変更され、メンバーの最大 25% が新しいバリデータのランダムなサンプルに置き換えられます。

この戦略では、「誰が残り、誰が去っていくのか?」は、全員が一部の時間に留まり、別の時間の一部を離れることになります。

スーパー委員会はどれくらいの規模でなければなりませんか?

この質問は、より単純な質問に要約されます。51% がイーサリアムを攻撃するには、どれくらいのコストがかかりますか?理想的には、攻撃と妨害行為に対するペナルティによって削減されたETHの量は、攻撃による実際の利益よりも大きい必要があります。攻撃のコストは、チェーンを破壊するという強力な外部動機を持つ強力な攻撃者を阻止または犠牲にするのに十分なほど高くなければなりません。

この目標を達成するためにどのくらいのETHが必要かという質問への答えは、必然的に直感に頼ることになります。以下のような質問が考えられます。
イーサリアムが 51% 攻撃され、コミュニティがオフチェーンガバナンスを調整して回復するまでに数日かかり、ETH の X% が焼かれたとします。イーサリアムエコシステムに純利益をもたらすには、X の大きさはどのくらい必要ですか?
大規模な取引所がハッキングされ、その結果数百万 ETH が失われたと仮定します。攻撃者はその収益を預け、バリデーターの 51% を乗っ取ります。攻撃者は、盗まれた資金が完全に破壊されるまでに、チェーンに対して 51% 攻撃を何回実行できるでしょうか?
Justin Drake の推定によると、ビットコインに対するスポーンキャンプ攻撃 (つまり、コミュニティが PoW アルゴリズムを変更するまで続く 51% 攻撃) の現在のコストは約 100 億ドル、またはビットコイン市場価値の 1% であると示唆されています。イーサリアムに対する 51% 攻撃のコストは何倍になるでしょうか?

画像の説明

イーサリアム研究者による内部投票

ネットワーク遅延に依存しない 51% 攻撃のみに焦点を当てると、100 万 ETH の攻撃コストは、200 万 ETH サイズのスーパー委員会 (約 65,536 人のバリデーター) を意味します。悪意のあるバリデーターとネットワーク操作を複雑に組み合わせた 34% 攻撃も考慮すると、その規模は 300 万 ETH (約 97,152 人のバリデーター) となります。

複雑さのコスト

攻撃コストの削減に加えて、このスキームのもう 1 つの大きな弱点は、プロトコルの複雑さや分析の複雑さなどの複雑さです。特に：
スーパー委員会を選出して交代させるには、数百行の仕様コードが必要です。
裕福なバリデーターは、利回りのボラティリティを下げるためにETHを複数のバリデータースロットに分割するため、実効残高上限を引き上げることで一部の利益が失われます。

一時的に高額な手数料または高額な MEV が発生した場合、スーパー委員会はスワップアウトを避けるためにファイナリティを意図的に遅らせ、手数料と MEV を引き続き徴収できるようにする場合があります。

アイデア 2: 検証者セットのサイズの上限を設定する

次の 2 種類のキャッピングスキームのいずれか (または両方) を試すことができます。
担保に供されるETHの総額の上限を設定する

検証者の総数の上限を設定する

各キャッピングスキームは、注文ベースのメカニズム (スタックまたはキュー) または経済モデルによって規制されるメカニズムを選択して実装できます。

シーケンスベースのメカニズムには多くの問題があります。その理由を理解するには、次の 2 種類の注文ベースの戦略を検討してください。
Keep Oldest Validator (OVS): バリデータのセットがいっぱいの場合、他の誰も参加できません

最新のバリデータを保持 (NVS): バリデータのセットがいっぱいの場合、最も古いバリデータが追い出されます。

どちらのカテゴリーも深刻な問題を抱えています。 OVS には、早期ステーカーの「王朝」と化すリスクがあり、彼らが離脱すると、再び参加する機会を永久に失う可能性があります。これにより、バリデーターがバリデーターセットに参加するために離れるたびに、MEV オークションや長いキューが発生することになります。一方で、NVS は永続的な MEV オークションをトリガーする可能性があり、これによりチェーン全体が混乱します。これは、追い出されたバリデーターがすぐに再参加することを望むため、真の新規プレーヤーと競合するためです。

経済モデルを通じて担保されたETHの総額の上限を設定もう 1 つのオプションのメカニズムは、経済モデルを使用して上限を設定することです。参加したいバリデーターが多すぎる場合は、一部のバリデーターが諦めて去るまで、新旧のバリデーターすべてを罰します。簡単なアプローチは、バリデーターの報酬式を現在のものから変更することです。

次のように変更します。で行儀の良いバリデータに対する報酬です (パフォーマンスの低いバリデータは比較的低い報酬を受け取ります)。

現在アクティブなバリデーターの合計 ETH 残高です。曲線はおおよそ次のようになります。曲線の左側では、バリデーターの報酬は現在のメカニズムに沿って機能します。ただし、ステークされた ETH の総量が数百万に増加すると、報酬関数は加速度的に低下し始め、約 2,500 万 ETH でゼロを下回ります。優先手数料と MEV 利回りが損失をカバーするのに十分であるという特別なケースでは、バリデーターは、ベースペイオフがゼロまたはマイナスであっても、喜んでステーキングを継続する可能性があります。報酬曲線は次のとおりです

ETH (約 3,350 万 ETH) は負の無限大になる傾向があるため、外部報酬がどれほど高くても、バリデーターセットのサイズはこの上限を超えることはできません。

このアプローチの利点は、動的キューの設計を完全に回避できることです。平衡点がどこにあるかに関係なく、平衡点に達します。バリデーターセットのサイズは最終的に平衡点に達します (現在の状況では、これ以上参加したいバリデーターは存在しません)。。

このアプローチの主な欠点は、カーブの右側付近で攻撃が継続的にブロックされることです。攻撃者が他のバリデーターに加わり、すぐに追い出すことができます。しかし、これは他のスキームに比べれば小さな問題です。なぜなら、これは MEV が異常に高い場合にのみ発生する可能性があり、この攻撃は非常に高価である (数百万の ETH を必要とする) からです。

もう1つの大きな欠点は、大部分のバリデーターが「疎外される」未来、つまり収益の変動に対する許容度が高いため、大規模なステーカーが小規模なステーカーを上回ってしまうという未来に私たちを導く可能性があることです。

経済モデルにより検証者の総数の上限を設定同じロジックを使用して、バリデーターの数に比例したペナルティを追加することで、バリデーターの数を制限することができます。たとえば、バリデータの上限を設定したい場合、

、できるよ：

もう 1 つのアプローチは、変動最小残高を追加することです。バリデーターの総数が上限を超えた場合、残高が最も低いバリデーターが追い出されます。変動最低残高は、新しいタイプの悪意のある攻撃に挑戦します。裕福なバリデーターは、小規模なバリデーターを追い出すために、賭けた資金を分割します (これにより、報酬が増加します), なぜなら、誓約額の総額は

減少しました）。 Zipf ディストリビューションではそのような攻撃が価値のない点までバリデータスロットごとの料金を増やすことで、これを軽減できます。ただし、Zipf ディストリビューションに従わなくなった場合、潜在的な脆弱性が残ります。