ビーコン チェーンの代替: 累積的な委員会ベースのファイナリティ モデル
ソース | ethresear.ch
著者 | ヴィタリック・ブテリン
これはビーコン チェーン用に提案された代替設計であり、遠い将来 (現在計画されている CBC に代わる) のモデルに切り替えることができ、次の主要な機能を提供しようとしています。
➤ 通常の状況では、意味のある単一スロットの経済的確実性（つまり、テンダーミントのような特性）を提供します
たとえ大多数のバリデーターが単一のスロットを再編成するために共謀に参加したとしても、実行コストは現在よりもはるかに高くなり、その結果、コンセンサス抽出可能価値 (CEV) が減少します。
➤ LMD GHOST フォークの選択への高い依存性を取り除き、既知の欠陥を回避し、次のことを導入する必要があります。複雑なハイブリッド フォークの選択ルール、これらの欠陥を修正します。
➤ 最低入金額の引き下げとバリデーターの数の増加が可能になる可能性
予備知識
予備知識
CONSENSUS を非同期安全なコンセンサス アルゴリズム (Tendermint、Casper FFG など) とする。コンセンサス アルゴリズムはスロットとビュー (ビュー ビュー) を含むように設計されていると仮定します。つまり、一定期間ごとにコンセンサスに達しようとします。また、重み付けされたバリデーターのセット (既存の BFT コンセンサス アルゴリズムに簡単に追加できるプロパティ) を入力として受け取ることも想定しています。
以下の設計では、ファイナライズに必要なバリデーターのセットがルックアップごとに異なるように、CONSENSUS を変更します。つまり、関数 get_validator_set(view_number: int) -> Map[Validator, int] (int はバリデーターバランスを表します) の入力としてバリデーターセットの代わりに CONSENSUS が使用され、バリデーターの新しいビューを生成できます。セット。 get_validator_set には、バリデーター セットがビュー間で最大 1/r だけ変化するというプロパティが必要です。ここで、 r (r=65536 ) は回復期間の長さです。より正式には、次のことを期待します。
このうち、|x| は x 値の絶対値の合計を返し、diff は各キー値を減算した後の値を返します (例: diff({a: 0.1, b:0.2}, {b:0.1) 、c:0.3}) = {a: 0.1、b: 0.1、c: -0.3})。
実際には、隣接する 2 つのバリデーター セット間の差異には、既存のバリデーターの差し引かれた残高が含まれ、新しく追加されたバリデーターの比率は、差し引かれた残高の比率に等しくなります。
1/r の最大バリデータ セット デルタ関数は、以前のバリデータがまだ完成していない場合にのみ使用できることに注意してください。以前のバリデータセットが確定している場合、CONSENSUS のインスタンスが変化するため、get_validator_set 関数の内部ランダム性も完全に変化し、この場合、隣接する 2 つのバリデータセットは完全に異なるものになります。
機構
機構
フォーク選択には 2 つのレベルを使用します。
➤ LATEST_FINALIZED_BLOCK (最新のファイナライズされたブロック) を選択します
➤ LATEST_FINALIZED_BLOCK から始めて、他のフォーク選択肢 (LMD GHOST など) を使用してブロックヘッダーを選択します
CONSENSUS アルゴリズムは、get_post_state(LATEST_FINALIZED_BLOCK) によって生成されたデータに基づくバリデーター セット生成関数を入力として受け取り、スロットごとに 1 回表示できます。有効なプロポーザルには、LATEST_FINALIZED_BLOCK の有効な子孫ブロックが含まれている必要があります。バリデーターは、その部分がフォークの選択に勝ち、ブロックチェーンの一部になった場合にのみ、ブロック提案を準備して投票します。
画像の説明
注: スロットは常に、現在のビュー番号に、以前に正常に完了した各バリデーター セットのビュー番号の合計を加えたものに等しくなければなりません。
以下の罰則があります。
➤ コンセンサスアルゴリズムによって決定される通常のスラッシュペナルティ
最初のレベルのタイトル
FFG の代替: シングルスロット エポック Casper FFG
上記の設計の代替案は、Casper FFG を使用しますが、エポックをスロット長と等しくします。 Casper FFG は、同じ委員会がブロックとその子孫を最終決定するのを妨げようとしないため、動作が異なります。この違いに対応するには、(i) 1/3 ではなく 1/4 の安全しきい値を適用する必要があります。(ii) スロットがファイナライズされた場合、バリデータ セットは完全ではなく最大 1/4 を置き換えるというルールを適用する必要があります。
このような設計では、理論的には 1 つのスロット (ただし 1 つのスロットのみ) の再編成を実装するのにコストはかかりません。また、グラフの最後には「最大ファイナリティのスロットまで」"最初のレベルのタイトル
特性
ブロックがファイナライズされると、競合するブロックがファイナライズされるために次のいずれかが発生する必要があります。
➤ 委員会で問題が発生し、別のブロックをダブルファイナライズしたためにバリデーターの 1/3 以上が削減されました
➤ 最新の委員会はオフラインであり、r/3 スロットの後、委員会は十分にシャッフルされ、スラッシュされることなく別のブロックを完成させることができます。ただし、これには重大な妨害行為ペナルティが伴います（攻撃者の残高の 1/3 以上）
いずれの場合も、ファイナライズされたブロックをロールバックする場合でも、少なくとも DEPOSIT_SIZE * COMMITTEE_SIZE / 3 (デポジット額 * 委員会サイズ / 3) の ETH が消費される必要があります。 COMMITTEE_SIZE = 131,072 (Eth2 委員会のスロットごとのバリデーターの数、理論上の最大値は 400 万) に設定すると、この値は 1,398,101 ETH になります。
ソリューションのその他の重要な機能には次のようなものがあります。
➤ バリデーターがデポジットされた数に関係なく、スロットごとに COMMITTEE_SIZE (コミッティー・サイズ) のトランザクションを処理する場合、バリデーターの負荷は安定します。
➤ 検証者の負荷は、委員会に参加する必要がないときはスリープ状態にできるため、軽減されます。
最初のレベルのタイトル
スケーリング: 小規模な委員会によるチェーンの確認
効率を上げるために COMMITTEE_SIZE を減らす必要がある場合は、次の調整を行うことができます。
➤ 単一の確認では真の最終性を示さなくなったことを反映して、「ファイナライゼーション」の名前を「確認」に変更しました。
➤ 最新の確認済みブロックを選択するのとは異なり、確認済みブロックのチェーン ヘッドが最も長い確認済みブロックを選択します（ただし、COMMITTEE_LOOKAHEAD で確認されたブロックのロールバックは拒否されるため、COMMITTEE_LOOKAHEAD の確認が実際の最終性を表します）
➤ get_validator_set はステータス情報のみを使用し，確認前の COMMITTEE_LOOKAHEAD は使用しないでください
➤ ビューの番号はスロットの番号である必要があります（これにより、同じバリデータセットが異なるチェーンで合意に達しようとしていることが推測しやすくなります。これは、一部の確認が破られた場合にのみ発生します）
このスキームは上記の機能をすべて保持していますが、新しい機能も導入しています。ブロックが複数の確認を取得した場合 (たとえば、ブロックがファイナライズされ、チェーンの子孫ブロックが k-1 の確認を取得した場合、合計 k 個の連続した確認が行われるため、ブロックに影響を与える)、ブロックをロールバックするには、複数の委員会でのコンセンサス保証に違反する必要があります。これにより、複数の委員会のセキュリティ レベルが積み重なることが可能になります。k 件の確認をロールバックするには、COMMITTEE_SIZE * DEPOSIT_SIZE * k / 3 ETH が必要で、委員会が分岐するには k = COMMITTEE_LOOKAHEAD が必要です。
最初のレベルのタイトル
具体的な値の例
「ファイナリティを解除するにはETHが必要である」ことに注意してください"この数値は、攻撃者がステーキングされた ETH の合計 (つまり数百万の ETH) の半分以上を制御するのと同等のバリデーターの数を制御していると想定しており、この数値は攻撃者が失う ETH です。しかし、これは、2,730,174,762 ETH を持っている人がこれらの ETH をランダムに燃やして単一スロットをロールバックできるという意味ではありません。
元のリンク: https://ethresear.ch/t/a-model-for-cumulative-committee-based-finality/10259
