はじめに: ETH2.0 での Casper FFG の実装
編集者注: この記事は以下から引用しましたイーサリアム愛好家 (ID: ethfans)編集者注: この記事は以下から引用しました
イーサリアム愛好家 (ID: ethfans)
イーサリアム愛好家 (ID: ethfans)
、著者: Aditya Asgaonkar、翻訳および校正: Min Min & A Jian、Odaily が許可を得て転載。
前回の記事では、Casper FFG の基本について説明しました。この記事の最初の部分では、Eth2.0 ビーコン チェーンで使用される Casper FFG 実装について簡単に説明します。 2 番目の部分では、ビーコン チェーンのフォーク選択ルールと、ブロックチェーンの活性度に関連するその他の要素について説明します。
この記事では、ETH 2.0 仕様のいくつかの概念を直接説明し、可能な限り仕様内の関連パラメータと関数へのリンクを添付します。これらのリンクは情報提供のみを目的としており、この記事を理解するためにリンクの内容を読む必要はありません。
パート 1 - Casper FFG メカニズム
スロット、エポック、および証明書
スロット(タイムスロット):ブロックチェーン上の時間がスロットに応じて分割されており、各スロット中に新しいブロックが提案されます。現在、スロットの期間は SECONDS_PER_SLOT = 12、つまり 12 秒です。システムは、新しいブロックを作成するために各スロットにバリデーターを割り当てます。
エポック (期間): Casper FFG メカニズムは完全なブロック ツリーには適用されませんが、特定のスロットでのブロックの投票のみが考慮されます。このようにして、投票状況に応じて確実性をチェックする際に、あまりにも多くのソースブロックとターゲットブロックのペアを検証する必要がなくなり、コストが節約されます。これらのスロット間の間隔は十分に長いため、FFG ファイナリティ チェックが実行されるたびに、バリデーターが新たに送信した投票の大部分が表示されます。各エポックは特定の数のスロットで構成されており、現在のパラメータは SLOTS_PER_EPOCH = 32、つまり 1 エポック = 32 スロット = 6.4 分です。 FFG メカニズムは、これらのエポック境界 (「チェックポイント」または「エポック境界ブロック」(EBB)) にあるブロックのみを考慮します。
- SLOTS_PER_EPOCH = 3、ブロック A、D、G がチェックポイントの場合のスロットとエポックのケース -
アテステーション (証人メッセージ): アテステーションは Casper FFG 投票であり、ソース ブロックとターゲット ブロック、アテステーションが生成されたときのスロット番号、バリデーターの識別子などの情報が含まれます。証明書は検証者によってピアツーピア ネットワークにブロードキャストされ、最終的にブロック提案者によって選択されてブロックにパッケージ化されます。
Casper FFG メカニズムの変更
前回の記事で述べたファイナライゼーションの定義には 1 つ変更があります。
決定性の達成:ブロックBが以下の条件を満たす限り、決定性が得られます。
合理化ブロック B_0 は次の条件を満たします。
[B_0, B_1, ... , B_n] (n >= 1) のチェーン上にスロット番号ごとに増加する一連のチェックポイントがあり、すべて合理化されています。
画像の説明
- 黄色のブロックは位置揃え、赤色のブロックは確定 -
変更された定義には、前回の投稿で説明した Casper FFG セキュリティ証明の概要がまだ保持されています。セキュリティ証明の詳細については、この記事の「セキュリティ」セクションを参照してください。
副題
Casper FFG による確定的検出
ビーコン チェーンのオンチェーン FFG メカニズムは、ブロックと認証を処理することで確実性を検出するように設計されています。各エポック境界で、このメカニズムは新しい証明書を処理し、合理化および最終化されたブロックを更新します。
オンチェーン FFG メカニズムは、考えられるすべてのソース ブロックとターゲット ブロックのペアの認証ではなく、特定のソース ブロックとターゲット ブロックのペアの認証のみを処理するため、コストが削減されます。具体的には、このメカニズムは現在および前のエポック (さらに他のいくつかの条件) の証明のみを処理します。したがって、オンチェーン FFG メカニズムはすべての決定論的なインスタンスを検出できません。つまり、このオンチェーンメカニズムは強固ですが、完全ではありません。
チェーン上の FFG メカニズムの仕様は非常に簡単です。
最初のステップは、ブロックの妥当性をチェックすることです。つまり、最新の 2 つのエポックからの証明を使用して、最新の 2 つのエポック境界ブロックの妥当性を検証します。
次のステップは、ブロックの最終性をチェックすることです。つまり、最後の 2 つのエポック境界ブロックの最終性をチェックします。確定的チェックでは、ソース ブロックと宛先ブロックの 4 つのペアのみが使用されます (パフォーマンスの向上と仕様の簡素化のため)。バックトラック距離も制限されています)。
画像の説明
- 確定的チェックにおけるチェックポイントのステータス (黄色のブロックは両端揃え、赤色のブロックは確定済み) -
Casper FFG メカニズムは、ブロックの確実性を確保するためのルールを概説していますが、このメカニズムがネットワークの稼働性をどのように保証するかについては言及していません (注: この記事は、ネットワークの稼働性を証明しようとするものではなく、稼働性を達成するために期待されるプロセスの概要を説明しています。より厳密な分析については、この記事を参照してください)。このセクションでは主に、活性に関する 2 つの主要な考慮事項を紹介します。
どのブロックがチェーンの先頭であるかを決定するためにバリデーターによって使用されるフォーク選択ルール
ブロックと証明書の生成スキームとそれに続くバリデータ
副題
HLMD GHOST フォークの選択ルール
ブロックを提案するバリデーターは、まずブロックチェーンの (ローカルで観察された) 先端を決定する必要があります。これを行うには、ハイブリッド最新メッセージ駆動 (HMLD) GHOST フォーク選択ルールを使用する必要があります。
このフォーク選択の仕様は次のとおりです。
ステップ 1 で最新の合理化ブロックとして特定された合理化ブロックを使用していないブロックはすべて除外されます。
通常の LMD GHOST ルールを使用して、リーフ ブロックが見つかるまでブロック ツリーをたどります。
フォークの選択の詳細については、この投稿の「ハイブリッド LMD GHOST」セクションを参照してください。
副題
バリデータプログラム
プロポーザル スケジュール: システムは、ブロック プロポーザーとして機能するバリデーターを各エポックの各スロットに割り当てます。検証者は、フォーク選択ルールに従ってローカル ビューのブロック ツリー上のチェーンの先頭を見つけて、新しいサブブロックを生成します。検証者は、確認した証明書をブロックにパッケージ化して報酬を得ることができます。これらの証明書は、確実性チェックの実行時に計算のためにオンチェーン FFG メカニズムに入力されます。
証人計画 (認証スケジュール): 各エポックで、各バリデーターは (特定のスロットで) 認証を生成する必要があります。実際、各エポックでは、バリデータ セット全体が同じサイズの SLOTS_PER_EPOCH 委員会にランダムに分割され、各委員会は現在のエポックの特定のスロットに割り当てられて、証明書を生成します。証明書を生成するとき、検証者は、ローカル ビューに従って、最新のファイナライズされたブロックをソース チェックポイントとして取得し、チェーンの先頭に最も近いチェックポイントをターゲット チェックポイントとして使用します (FFG 投票を開始します)。
https://github.com/ethereum/eth2.0-specs/tree/dev/specs/phase0


