これは、Polkadot Consensus シリーズのパート 2 です。
このシリーズの紹介では、コンピューター ネットワークが 3 つの質問に答えるのに役立つコンセンサス アルゴリズムについて概説します。 GRANDPA は 2 番目の問題に対処します。
1. 次の変更を提案できるのは誰ですか?
2. 最終的な変更はどのセットですか?
3. 誰かがルールを破ったらどうなりますか?
GRANDPA は Polkadot の最終ツールであり、その役割はモデル チェーンを正しく選択することであり、GRANDPA への一連の変更が最終ステップであることを示します。 GRANDPA は独自にブロックを生成しません。代わりに、GRANDPA バリデーターは別のブロック生成コンポーネント (パート 3 で説明します) からブロックをインポートします。
副題
おじいちゃん協定
GRANDPA は、バリデーターがブロックではなくチェーンに投票するという点で、他の Byzantine Fault Tolerant (BFT) ブロックチェーン アルゴリズムとは異なります。このプロトコルは移行投票メカニズムを採用しており、GRANDPA アルゴリズムは投票数が最も多いブロック番号を見つけ、それが最終投票とみなされます。このプロセスにより、複数のブロックを同時に実行できます。
GRANDPA は他のブロックチェーンファイナライゼーションツールを妨げていたボトルネックを取り除くため、最後の部分は重要です。 Practical Byzantine Fault Tolerance の他の PBFT 派生製品と同様に、GRANDPA の複雑さは O(n²) です。つまり、ノードの数が 2 倍になると、4 倍の数のメッセージを送信する必要があります。ブロック生成を決定論的プロセスの一部とするコンセンサス システムにより、これらのメッセージを各ブロックに送信できるようになります。ブロック生成を別のモジュールに分離することで、より効率的な方法 (BABE の場合は O(n)) でブロックを生成し、1 回の投票でいくつかのブロックを最終決定できます。
この例を理解するには、Kusama ノードからの次のログ メッセージを見てください。
Idle (24 peers), best: #664257 (0x706c…76b7), finalized #664253 (0xe4ab…4d2a)
Imported #664258 (0xee71…6321)
Idle (24 peers), best: #664258 (0xee71…6321), finalized #664256 (0x809a…a5d8)
1 ラウンドで、GRANDPA は 3 つのブロック (664,254 ～ 664,246) を確定したことに注意してください。
副題
おじいちゃんラウンド
投票者は次の操作を行って新しいブロックを生成します。
1. 「プライマリ」として指定されたノードは、以前に得られたと思われる最も高い投票数を持つブロックを最終ブロックとしてブロードキャストします。
2. ネットワーク遅延を待った後、各バリデーターは、最終化され最終とみなされるべきであると考えられる最高投票数のブロックに対する「事前投票」をブロードキャストします。バリデーターの大多数が正直であれば、このブロックは元のブロードキャスト チェーンを拡張するはずです。したがって、新しいチェーンは最終的なチェーンよりも数ブロック長くなる可能性があります。
3. 各検証者は、事前投票の計算に従って、最も高い票を獲得した最終ブロックを決定できます。事前投票セットが最後に確定したチェーンにまで及ぶ場合、各バリデーターはそのチェーンを「事前実行」します。
4. 各バリデータは、新しく決定されたチェーンに関する情報を配信するために十分な事前実行を受信するまで待機します。
PBFT や Hotstuff などの他のビザンチン フォールト トレラント アルゴリズムとの微妙だが重要な違いは、この投票ラウンドのクリティカル パスに関して意見の変更がないことです。各ラウンドの主な内容は変更されますが、この変更は非同期ネットワークで新しいラウンドを開始するだけであるため、部分同期ネットワークでは、メイン ランドが割り当てられていない場合でも、プロトコルは常に前進します。
検証者の事前投票または事前実行の 3 分の 2 以上がプロトコルプロセスで得られた場合、プロセスを完了できることを示します。ファイナリティを達成するには、無限のバリデータセットのファイナリティを持つことができるチェーンとは異なり、バリデータのハンド内の投票数を制限する必要があります。投票者のセットを選択する方法は、GRANDPA プロトコルの外部で定義されたロジックです (セクション 4 を参照)。
副題
安全上の責任: 事故が起こったとき
GRANDPA には、バリデーターにセキュリティ違反に対する責任を負わせるセキュリティ アカウンタビリティと呼ばれる機能があります。異なるチェーン内の 2 つのブロックが決定されたときにセキュリティ競合が発生した場合、セキュリティ責任機能は事故後の調査に似ています。
しかし、その前に、2 つの相反するチェーンがどのように形成されるかは明らかです。 BFT システムは常に、問題のバリデーターの最大数が総バリデーターのほんの一部 (この場合は 3 分の 1) であるという条件に基づいて構築されます。バリデーター セットが上記の要件を満たしていない場合は、競合する 2 つのチェーンを最終的にクリアするために、バリデーターの少なくとも 3 分の 1 が両方のチェーンに投票します。
この例では、バリデーターが 10 個あります。これは、システムが許容できる誤ったバリデーターの最大数が 3 であることを意味します (f = (10-1)/3)。 4 つの不正なバリデータ (赤) とネットワーク パーティションがある場合、誠実なバリデータ (青) の各セットは、それぞれのブロックを最終的なものにすることができます。
2 つの相反するチェーンに投票することは曖昧な行為です。実際、あいまいさは BFT システムに対する攻撃であると誰もが考えていますが、GRANDPA ではこの動作を検出できます。
まず、なぜノードが前のブロックを考慮せずに新しいブロックに投票したのかを尋ねます。誠実な検証者であれば、この質問に答えるために、2 番目の事前投票または事前実行を有効にする必要があります。これは、2 番目のブロックが常に過半数の票を獲得するためです。
最初の質問が正しい場合は、2 番目の質問をします。第 1 回投票のどの投票用紙を見ましたか?私たちは基本的に、他のバリデーターを承認し、同僚から受け取ったすべての投票を開示するよう求めています。これら 2 つのセットの結合のどこかに、競合する 2 つのチェーンに投票したバリデーターが見つかります。上記の結果が確認されると、大きなペナルティが課せられますが、これはオンチェーンのロジック作業の結果にすぎず、コンセンサスではありません。
副題
GRANDPAが使いやすさと効果を実現する方法
上記のログ メッセージを覚えていますか?最終ブロックは、最良のブロックの後の 2 番目のブロックであることに注意してください。この遅れは、実際には、ブロックの生成と完了を異なる状態に保つ上で利点となります。
Idle (24 peers), best: #664258 (0xee71…6321), finalized #664256 (0x809a…a5d8)
Polkadot を含むブロックチェーン相互運用システムには、データの可用性に関する問題があります。コレーターがバリデーターにブロックをコミットしているが、他のパラチェーン コレーターがそれを認識していないことを想像してください。ブロック情報を送信したコレクターがオフラインになった場合はどうなりますか?バリデーターは、すべてのパラチェーンコレクターがブロック情報を取得できるように、完全なブロック情報を一定期間保存するのを支援する責任があります。
バリデーターはブロック候補に投票する前に検証することになっていますが、私たちはブロック候補が確実に検証するようにしたいと考えています。 Polkadot には、ブロックを検証し、リレー チェーン内の無効なパラチェーンを指摘するなど、バリデーターによる不正行為を報告できるフィッシャーとして知られるノードが多数存在します。
最終的に選択されたブロックが無効なブロックや、照合器が再構築できないブロックになることは決して望ましくありません。チェーンの最後にあるいくつかのブロックの検証可能性を維持することで、フィッシング詐欺師がブロックが正しいことを検証し、検証者が良心的であることを検証できるようになります。
元のリンク:
元のリンク:https://polkadot.network/polkadot-consensus-part-2-grandpa/
翻訳 / マイク
編集 / ドリー
