分散型バリデータ技術
分散型バリデータ技術 (DVT) は、バリデータの安全性に対する方法論であり、鍵管理と署名の責任を複数の関係者に分散させることで、単一障害点を減らし、バリデータの回復力を高めます。
これは、バリデータを保護するために使用される秘密鍵を「クラスタ」に編成された多数のコンピュータに分割することで実現します。 このメリットは、鍵が1つの機器に完全に保存されていないため、攻撃者による鍵へのアクセスが非常に困難になることです。 また、必要な署名を各クラスタの一部の機器で行うことができるため、一部のノードがオフラインになることも許容されています。 これにより、ネットワークの単一障害点が減り、バリデータセット全体がより堅牢となります。
DVTが必要な理由とは
セキュリティ
バリデータは、コンセンサスに参加するためのバリデータ鍵と、資金にアクセスするための引き出し鍵の2つの公開鍵と秘密鍵のペアを生成します。 バリデータは引出鍵をコールドストレージ内に保管できますが、バリデータ秘密鍵は24時間365日オンラインである必要があります。 バリデータの秘密鍵が漏洩した場合、攻撃者はバリデータを管理することができ、ステーカーのETHがスラッシングされたり紛失する可能性があります。 DVTはこのリスクを軽減するのに役立ちます。 その方法について紹介します。
DVTを使用することで、ステーカーはバリデータの秘密鍵をコールドストレージに保管したまま、ステーキングに参加することができます。 これは、元のバリデータ鍵を暗号化し、それをキーシェアに分割することで実現します。 鍵の共有はオンラインで行われ、バリデータの分散運用を可能にする複数のノードに分散されます。 これは、イーサリアムのバリデータがBLS署名を使用するため可能であり、加法的である。 これは、イーサリアムのバリデータが加法的なBLS署名を使用しているため、実現することができます。つまり、その構成要素を合計することで鍵を再構築することができます。 これにより、ステーカーは完全にオリジナルの「マスター」バリデータ鍵をオフラインで安全に保管することができます。
単一障害点なし
バリデータが複数のオペレーターや複数の機器に分割されている場合、オフラインになることなく、個々のハードウェアやソフトウェアの障害に耐えることができます。 また、クラスタ内のノード間で多様なハードウェアおよびソフトウェア構成を使用することで、障害のリスクを軽減することもできます。 このレジリエンスは、単一ノードのバリデータ構成では利用できません (これはDVTレイヤーから提供されます)。
クラスタ内における機器のコンポーネントの1つがダウンした場合 (例えば、バリデータクラスタに4人のオペレータが存在し、そのうちの1人がバグのある特定のクライアントを使用している場合)、他のオペレータがバリデータとしての稼働を継続します。
分散化
イーサリアムの理想的なシナリオは、できるだけ多くの独立したバリデータを持つことです。 しかし、いくつかのステーキングプロバイダは非常に人気があり、ネットワーク上の総ステーキングETHの大部分を占有しています。 DVTは、ステークホルダーの分散化を維持しつつ、こうしたオペレータの存在を可能にします。 これは、各バリデータの鍵が多くの機器に分散しているため、バリデータが悪事を働くには、より大きな共謀が必要になることを意味します。
DVTが存在しない場合、ステーキングプロバイダは、すべてのバリデータに対して、1つか2つのクライアント構成しかサポートせず、クライアントのバグによる影響が大きくなります。 DVTを使用することで、複数のクライアント構成と異なるハードウェアにリスクを分散し、多様性によりレジリエンスを生み出すことができます。
DVTは、イーサリアムに次のようなメリットを提供します:
- イーサリアムのプルーフ・オブ・ステークコンセンサスの分散化
- ネットワークの可用性を確保
- バリデータのフォールトトレランスを実現
- バリデータ操作に対する信頼の最小化
- スラッシングとダウンタイムのリスク最小化
- 多様性の向上 (クライアント、データセンター、場所、規制など)
- バリデータ鍵管理のセキュリティ強化
DVTの仕組み
DVTソリューションには次のコンポーネントが含まれています:
- シャミアの秘密分散法(opens in a new tab) - バリデータはBLS鍵(opens in a new tab)を使用します。 個々のBLSの「キーシェア」("key shares") は、1つの集約された鍵 (署名) にまとめることができます。 DVTは、バリデータの秘密鍵はクラスタ内の各オペレータのBLS署名を組み合わせたものです。
- 閾値署名方式(opens in a new tab) - 署名業務に必要な個々のキーシェアの数を決定します (例: 4つのうち3つ)。
- 分散鍵の生成(opens in a new tab) - キーシェアを生成する暗号化プロセスで、既存または新規のバリデータ鍵の共有をクラスタ内のノードに配布するために使用されます。
- 秘匿マルチパーティ計算(opens in a new tab) - 正確なバリデータ鍵は、マルチパーティ計算を使用して秘密裏に生成されます。 正確な鍵は、どのオペレータにも決して知られることはありません (オペレータは、その一部のみ知っています)。
- コンセンサスプロトコル - コンセンサスプロトコルは、ブロック提案者となるノードを1つ選択します。 クラスタ内の他のノードとブロックを共有し、そのノードが集約署名にキーシェアを追加します。 十分な数のキーシェアが集まると、イーサリアム上でブロックが提案されます。
分散型バリデータにはフォールトトレランスが組み込まれており、個々のノードの一部がオフラインになっても稼働を続けることができます。 これは、クラスタ内の一部のノードが悪意を持っていたり、遅延している場合でも、クラスタがレジリエンスを持つことを意味します。
DVTのユースケース
DVTは、広い範囲でステーキング業界にとって重要な意味を持ちます:
個人ステーカー
DVTはまた、正確な鍵を完全にオフラインで管理しながら、バリデータ鍵をリモートノードに分散させることで、ノンカストディアル・ステーキングを可能にします。 つまり、ホームステーカーは必ずしもハードウェアを準備する必要はありません。一方でキーシェアを分散することで、潜在的なハッキングリスクの対策をすることができます。
ステーキング・アズ・ア・サービス(SaaS)
多くのバリデータを管理するオペレータ (ステーキングプールや機関投資家など) は、DVTを利用してリスクを低減することができます。 インフラを分散することで、運用に冗長性を持たせ、使用するハードウェアの種類を多様化することができます。
DVTは複数のノードで鍵管理の責任を分担するため、運用コストも共有できます。 また、DVTはステーキングプロバイダの運用リスクと保険コストを低減することができます。
ステーキングプール
標準的なバリデータ設定により、ステーキングプールとリキッドステーキングプロバイダは、利益と損失がプール全体で共有されるため、様々なレベルの単一オペレータを信頼する必要があります。 また、これまでは他に選択肢がなかったため、署名鍵の保護についてはオペレータに依存しています。
従来、複数のオペレータにステークを分散する努力がされてきましたが、依然として各オペレータはかなりのステークを独立して管理しています。 単一のオペレータに依存することは、そのオペレータのパフォーマンスが低下したり、ダウンタイムを経験したり、危険にさらされたり、悪意を持って行動した場合に、計り知れないリスクを伴います。
DVTを活用することで、オペレータに求められる信頼は大幅に低減されます。 プールは、オペレータがバリデータ鍵の保管を必要とせずにステークを維持できます (キーシェアのみが利用されるため)。 また、管理されるステークをより多くのオペレータに分散させることができます (例えば、1人のオペレータが1,000のバリデータを管理する代わりに、DVTによってそれらのバリデータを複数のオペレータがまとめて管理できるようになります)。 異なるオペレータ構成によって、あるオペレータが停止しても他のオペレータが引き続き証明できます。 その結果、冗長性と多様性が生まれ、報酬を最大化すると同時に、パフォーマンスとレジリエンスの向上につながります。
単独オペレータの信頼を最小化するもう1つのメリットは、ステーキングプールがよりオープンかつパーミッションレスな状態でオペレータの参加を可能にします。 これにより、サービスのリスクを軽減します。例えば、より小規模なステーカーと大規模なステーカーをペアにするなど、厳選されたオペレーターのセットとパーミッションレスのオペレーターのセットの両方を使用して、イーサリアムの分散化を促進します。
DVTを使用するデメリット
- 追加の構成要素 - DVTノードを導入することで、欠陥や脆弱性のある部品が1つ増えます。 これを緩和する方法は、DVTノードの複数の実装を目指すことです。つまり、コンセンサス層や実行層と同様に、複数のDVTクライアントを利用することです。
- 運用コスト - DVTはバリデータを複数の当事者間で分散させるため、運用に必要なノードが1つではなく、より多くのノードが必要となり、運用コストが増加します。
- 潜在的な待ち時間の増加 - DVTは、バリデータを操作する複数のノード間でコンセンサスを得るためにコンセンサスプロトコルを利用するため、潜在的な待ち時間が増加する可能性があります。
参考文献
- イーサリアム分散バリデータの仕様 (ハイレベル)(opens in a new tab)
- イーサリアム分散バリデータの技術仕様(opens in a new tab)
- シャミアの秘密分散デモアプリ(opens in a new tab)