Ethereum 分散バリデータの仕様を 1 つの記事で読む
原題:「イーサリアム分散バリデータ仕様」
原文はアディティヤ・アスガオンカルによって書かれました
最初のレベルのタイトル
副題
モチベーション
従来のバリデータクライアントのセットアップ
イーサリアムバリデーターは、ステークされた秘密鍵を使用してメッセージ (ブロックやプルーフなど) に署名することで、プルーフオブステーク (PoS) プロトコルに参加します。ステーキング秘密キーには、バリデーターに割り当てられた責任に従ってメッセージの作成と署名を調整するクライアント ソフトウェアを介してのみアクセスできます。従来のバリデータ クライアントのセットアップにはいくつかのリスクが伴います。
· ステークされた秘密キーは 1 か所に存在します。攻撃者がこのキーを入手すると、競合するメッセージが作成され、検証デポジットが没収される可能性があります。
独自のバリデーターを実行しないステーカーは、ステーキング秘密鍵をオペレーターに引き渡す必要があります。ステーキングされた秘密鍵を安全に保つためには、そのオペレーターを信頼する必要があります。
· バリデータークライアントソフトウェアがバリデーターの義務を果たすためのタイムリーなメッセージを作成できない場合、バリデーターは非アクティブになり、残高が減ります。
これは、ソフトウェアのクラッシュ、ネットワークの停止、ハードウェアの障害などが原因である可能性があります。
· バリデータ クライアントが接続されているビーコン ノードに障害が発生した場合、バリデータは少数のノードが配置されているフォークをたどる可能性があり、その結果、PoS プロトコルの他の部分でオフライン ステータスが発生します。
分散バリデータプロトコル
基本的な考え方
基本的な考え方
注意: 分散バリデータ仕様で導入された新しい用語の説明については、用語集を参照してください。 (翻訳者注: 記事の最後を参照)
分散バリデータの背後にある 2 つの基本概念は次のとおりです。
コンセンサス: 単一のバリデーターの責任は複数の共同バリデーターに分割され、メッセージが署名される前に投票方法について合意するために協力する必要があります。
· M-of-N しきい値署名: 検証者のステーキング秘密鍵は N 個の部分に分割され、各共同検証者が共有を保持します。少なくとも M 個の共通バリデーターが投票方法について合意に達すると、各自のシェアを使用してメッセージに署名し、これらのシェアから結合された署名を再構築できます。
PoS イーサリアムは BLS 署名スキームを使用しており、秘密鍵は M-of-N 秘密共有テクノロジ (Shamir の秘密共有スキームを使用) を使用して M-of-N しきい値署名を実現できます。
(翻訳者注: Shamir's Secret Sharing は、分散方式で秘密を保護するために使用されます。秘密は複数の部分に分割され、これらの部分は共有と呼ばれ、これらの共有を使用して元の秘密を再構築できます。また、Shamir's Secret Sharing を介して復号化するには、最小シェア数 (しきい値と呼ばれます)。
副題
リソース
成し遂げる
以下は、分散バリデータ技術の既存の実装です (ただし、必ずしもこの仕様の実装であるわけではありません)。
python-ssv: Python での分散バリデーター プロトコルの概念実証実装であり、Ethereum クライアント Prysm と対話します。
書類
書類
副題
全体的なアーキテクチャ
この仕様では、分散検証クライアント (DVC) ソフトウェアをビーコン ノードとリモート署名者 (RS) の間のミドルウェアとして実装する方法を提案します。
· ビーコン ノードとリモート署名者間のすべての通信は DVC によって管理されるため、追加の分散バリデーター機能を提供できます。
副題
仮定する
· 合計 N 個のノードがあり、M-of-N しきい値署名スキームがあると仮定します。
BFT コンセンサス プロトコルとの互換性のために、M = ceil(2 * N / 3) と仮定します。
· この仕様は、ある種のリーダーベースで安全性を重視したコンセンサスプロトコルを前提としており、共同検証者が同じプルーフ/ブロックを選択して署名できるようにします。コンセンサス プロトコルは M 個の正しいノードで正常に実行され、合計 N 個のノードのうち F = (N-1)/3 個以下のビザンチン ノードと、N - M - F 個以下のフェイルストップ ノードで正常に実行されると仮定します。 (翻訳者注: ビザンチン ノードとは、ネットワーク内の他のノードに意図的に嘘をついたり誤解を与えたりする裏切りノードを指します。)
バリデータ クライアントを安全に実行するための通常の前提条件には、最新のスラッシュ耐性のあるデータベース、正しいシステム クロックなどが含まれると想定しています。
副題
理想的な保証
セキュリティ（鍵の盗難防止）：
N 人の共同検証者のうち M 人を超える検証者のセキュリティが侵害されない限り、誓約者の秘密鍵は安全です。
・セキュリティ（斬り込み防止）：
非同期ネットワークの仮定の下では、共同バリデーターの 3 分の 1 以上が離脱者にならない限り、バリデーターが削減されることはありません。
同期ネットワークの仮定の下では、共同バリデーターの 3 分の 2 以上が離脱者にならない限り、バリデーターが削減されることはありません。
仕様
仕様
最初のレベルのタイトル
副題
イーサリアムのコンセプト
Validator: プルーフ・オブ・ステーク Ethereum 検証に参加する公開鍵。フェーズ 0 では、バリデーターは、ビーコン チェーン ブロックの構成証明とブロック提案の責任を実行することが期待されます。
· Validator Client (Validator Client、VC): バリデーターの役割を実行するソフトウェア。 VC は検証者の秘密鍵にアクセスできます。
副題
暗号化の概念
キー共有: しきい値署名スキームの一部である単一のキー。
副題
分散型バリデーターの概念
· 分散バリデーター (DV): 参加者のグループが集合的にバリデーターの職務を実行します。検証者の秘密鍵は複数の参加者間で秘密裏に共有されるため、参加者の一定の過半数のしきい値がなければ完全な署名を形成することはできません。
· Co-Validator: DV プロトコルに参加して、特定の検証者の BLS 公開キーしきい値検証者になります。
副題
例
上記の用語を使用したイラストの例:
· 公開キー 0xa5c91... を持つ Ethereum バリデーターは、分散バリデーターとして実行されています。
· バリデーター 0xa5c91... の分散バリデーターには 4 人の共同バリデーターが参加しています。
· 0xa5c91... に関連付けられた秘密キーは、3-of-4 秘密分散スキームを使用して 4 つの共同認証者間で分割され、これにより 3-of4 しきい値署名スキームが確立されます。
もっと簡単に言えば、0xa5c91... の秘密キーは 4 つの共有に分割され、それぞれが共同認証者の 1 人によってホストされるため、0xa5c91 から秘密キーを取得するには少なくとも 3 つの共同認証者が協力する必要があります。 .. 署名を生成します。
元のリンク
