ビーコン チェーン バリデータ: 冗長性のリスクとフェイルオーバー

編集者注: この記事は以下から引用しましたイーサリアム愛好家 (ID: ethfa​​ns)イーサリアム愛好家 (ID: ethfa​​ns)

イーサリアム愛好家 (ID: ethfa​​ns)

、著者: Aditya Asgaonkar、翻訳: A Jian、Odaily が許可を得て転載。

最初のレベルのタイトル

バリデーターとバリデータークライアント

ベリファイアはビーコン チェーンに関連する概念であり、ベリファイアはビーコン チェーンのコンセンサス プロセスの参加者です。検証者は公開鍵によって識別され、各検証者には異なる時点でビーコン チェーンを検証するタスクが割り当てられます。これらの任務をうまく達成できれば報酬が得られますが、逆に任務を怠った場合は報酬が得られないだけでなく、厳しい罰が与えられます。フェーズ 0 では、これらの告発はブロックの提案とビーコン チェーンでの証明書の提出に限定されます。

バリデーターは、その職務を実行するためにバリデーター・クライアント (VC) と呼ばれるソフトウェアを使用する必要があります1。すべてのビーコン チェーン クライアント チームは、クライアント ソフトウェア パッケージの 1 つとして VC を使用しています。

• 言うまでもなく、バリデーターはクライアントが最大限の利益を享受し、あらゆるペナルティを回避できるように、クライアントが 24 時間 365 日オンラインでいられることを望んでいます。高可用性を実現する一般的な方法は、冗長性とフェイルオーバーのメカニズムをセットアップすることです。この記事では、バリデーターに冗長性の危険性を説明し、ビーコン チェーン内の VC の合理的なフェイルオーバーを提案します。
• 損失/ペナルティの種類
• バリデーターは、重大度の低い順に次の 3 種類の損失に直面します。

報酬のフラストレーション: バリデーターがタスクに割り当てられたときに実行に失敗すると、TA はタスクに対応する報酬を受け取ることができません。バリデーターの資本 (元本) は減少しませんが、報酬を受け取る機会を失うだけです。遅い作業のペナルティ: 検証者が証人メッセージを送信せず、その時点でビーコン チェーンがブロック 2 を完了できない場合、検証者の資産はわずかに減ります (もちろん、関連する報酬は得られません)。スラッシュペナルティ: バリデーターが Casper FFG ルールに違反する証人メッセージを送信した場合、バリデーターは即座にスラッシュされます。バリデーターの資本は特定の比率 3 で減らされ、バリデーターは追い出され、再度使用できなくなります。コンセンサス（したがって、将来の報酬からも除外されます）。さらに、ビーコン チェーンは誓約された ETH を転送および取得できないため、検証者の残りの資金はすべてビーコン チェーンにロックされ、使用できなくなります (ビーコン チェーンが関連機能を有効にするまで)。

(翻訳者注: 著者はここで損失を見逃しています。ビーコン チェーンがファイナリティを取得できない場合、証人メッセージを送信しなかった検証者が速度低下で罰せられるだけでなく、メッセージを送信した証人も損失を被ることになります。ただし、損失は前者に比べて小さいですが、著者はこの記事で主に検証者のオフラインに関連する損失について説明しているため、これも理解できます)。

最初の 2 つの損失タイプは、VC がオフラインであるバリデーターによって経験される可能性がありますが、3 つ目は、VC を誤って設定したバリデーター (またはビーコン チェーンが明示的に攻撃された場合) によってのみ経験されます。冗長VC設備の危険性

一部の利害関係者は、冗長 VC を実行することが 1 つの VC がオフラインになった場合の保険だと信じているかもしれません。しかし実際には、冗長な VC 施設は安全ではなく、バリデーターは最終的に罰金を科される可能性が非常に高いです。

実際の例を見てみましょう。

画像の説明

・VCの冗長化が斬撃に繋がる！ -VCのフェイルオーバープロトコル

注: 「フェイルオーバー」と言うときは、VC が停止した後に新しい VC インスタンスを手動または自動で再起動することを意味します。ただし、自動フェイルオーバー メカニズムの使用はお勧めしません。実装が適切でないと、VC が 2 つあります。ラインに掛かっています！

前のセクションの要点は、バリデーターは一度に 1 つのライブ VC インスタンスのみをデプロイする必要があるということです。しかし、VC は常に間違いを犯します。このリスクにどう対処すればよいでしょうか?ステーカーは、この状況に対処するために、事前に独自のフェイルオーバー プロトコルを定義する必要があります (新しいバリデータ クライアント インスタンスを再起動する使用方法を決定する)。安全で信頼性の高いフェイルオーバー プロトコルを開発する前に、まずバリデータ クライアントに組み込まれているセキュリティ機能であるスラッシュ保護について見てみましょう。画像の説明

• - スラッシュプロテクション機構 -
• スラッシュ保護メカニズム: ビーコン チェーン クライアント チームによって開発されたすべての VC ソフトウェアには、予期せぬイベントに対する自動フェールセーフ デバイスとしてスラッシュ保護メカニズムが備わっています。スラッシュ ルールによれば、認証メッセージのペアのみがスラッシュになります。結果を判断するには、このメッセージのペアをチェックするだけで済みます。その後、VC は、VC 自身が署名したすべてのメッセージとブロックをローカルのスラッシュ プロテクション データベースに保存できます。新しい認証メッセージ/ブロックに署名する場合、VC は、新しいメッセージがデータベース内の古いメッセージと競合するかどうか (スラッシュ付きメッセージ ペアを形成するかどうか) を確認し、競合しない新しいメッセージにのみ署名するだけで済みます。
• したがって、VC には正しく安全な動作を保証する 3 つのメカニズムが必要です。

ビーコン チェーンに関する情報を取得するための完全に同期されたビーコン チェーン ノード (BN)検証者は秘密鍵に署名して実際にメッセージに署名しますタイムリーなスラッシュによりデータベースをフェールセーフとして保護します

適切なフェイルオーバー プロトコルでは、どちらかのメカニズムの障害を考慮する必要があります。最初の 2 つは簡単に保証できます。冗長 BN は新しい VC 接続用に維持でき、署名キーはバックアップ フォルダーから読み取り専用ファイルとしてコピーすることもできます。

注: SD カードは信頼性の高いストレージ デバイスではないため、Raspberry Pi 上で VC を実行しているステーカーは、スラッシュ保護されたデータベースを失う可能性が特に高くなります。

私が提案するフェイルオーバーソリューション

シンプルだが有用な解決策は、冗長 BN を維持し、冗長検証キーに簡単にアクセスできるようにすることです。

• 画像の説明
• - VCの初期設定とマルチシナリオフェイルオーバープロトコル -
• この設定では、さまざまなエラーが処理スキームに対応する分布を持ちます。

BN エラー - その後、冗長 BN に移行します

バリデータキーファイルがありません - コールドストレージのバックアップキーファイルからコピーされましたスラッシュ保護されたデータベースの損失 - データベースを再構築するか、ライブ バックアップから復元しますhttps://youtu.be/awBX1SrXOhk。キー分割ベリファイア(つまり、回復力のあるバリデーター機能を実装する正しい方法)最適な回復力インフラストラクチャには主要な分割テクニックが必要です。これについては別の記事で説明します。詳細については、次のトークビデオをご覧ください。