分散型バリデータ技術

分散型バリデータ技術 (DVT) は、単一障害点を減らし、バリデータの回復力を高めるために、鍵管理と署名の責任を複数の当事者に分散させるバリデータセキュリティへのアプローチです。

これは、バリデータを保護するために使用される秘密鍵を、「クラスター」として編成された多数のコンピューターに分割することによって行われます。この利点は、鍵全体が単一のマシンに保存されないため、攻撃者が鍵にアクセスすることが非常に困難になることです。また、必要な署名は各クラスター内のマシンのサブセットによって実行できるため、一部のノードがオフラインになることも許容されます。これにより、ネットワークから単一障害点が減少し、バリデータセット全体がより堅牢になります。

なぜDVTが必要なのか？

セキュリティ

バリデータは、コンセンサスに参加するためのバリデータ鍵と、資金にアクセスするための引き出し鍵という、2つの公開鍵と秘密鍵のペアを生成します。バリデータは引き出し鍵をコールドストレージで安全に保管できますが、バリデータの秘密鍵は24時間365日オンラインである必要があります。バリデータの秘密鍵が侵害された場合、攻撃者はバリデータを制御できるようになり、スラッシングやステーカーのETHの損失につながる可能性があります。DVTは、このリスクを軽減するのに役立ちます。その仕組みは以下の通りです。

DVTを使用することで、ステーカーはバリデータの秘密鍵をコールドストレージに保管したままステーキングに参加できます。これは、元の完全なバリデータ鍵を暗号化し、それをキーシェア（鍵の共有部分）に分割することによって実現されます。キーシェアはオンライン上に存在し、複数のノードに分散されることで、バリデータの分散運用を可能にします。これが可能なのは、イーサリアムのバリデータが加法的なBLS署名を使用しているためです。つまり、構成要素を合計することで完全な鍵を再構築できるのです。これにより、ステーカーは完全で元の「マスター」バリデータ鍵を安全にオフラインで保管できます。

単一障害点の排除

バリデータが複数のオペレーターと複数のマシンに分割されている場合、個々のハードウェアやソフトウェアの障害に耐え、オフラインになることはありません。クラスター内のノード全体で多様なハードウェアおよびソフトウェア構成を使用することで、障害のリスクをさらに減らすこともできます。この回復力は、単一ノードのバリデータ構成では得られないものであり、DVTレイヤーによってもたらされます。

クラスター内のマシンのコンポーネントの1つがダウンした場合（たとえば、バリデータクラスターに4人のオペレーターがいて、そのうちの1人がバグのある特定のクライアントを使用している場合）、他のオペレーターがバリデータの稼働を継続させます。

分散化

イーサリアムにとっての理想的なシナリオは、独立して運用されるバリデータが可能な限り多く存在することです。しかし、少数のステーキングプロバイダーが非常に人気を集め、ネットワーク上でステーキングされたETH総額のかなりの部分を占めるようになっています。DVTは、ステークの分散化を維持しながら、これらのオペレーターの存在を許容することができます。これは、各バリデータの鍵が多数のマシンに分散されており、バリデータが悪意を持つにははるかに大規模な共謀が必要になるためです。

DVTがない場合、ステーキングプロバイダーはすべてのバリデータに対して1つか2つのクライアント構成のみをサポートする方が簡単であり、クライアントのバグの影響が大きくなります。DVTを使用すると、複数のクライアント構成や異なるハードウェアにリスクを分散させ、多様性による回復力を生み出すことができます。

DVTはイーサリアムに以下の利点をもたらします：

イーサリアムのプルーフ・オブ・ステーク (PoS) コンセンサスの分散化
ネットワークの**ライブネス（可用性）**の確保
バリデータの**フォールトトレランス（耐障害性）**の構築
**トラストミニマイズ（最小限の信頼）**されたバリデータ運用
最小限に抑えられたスラッシングおよびダウンタイムのリスク
多様性の向上（クライアント、データセンター、場所、規制など）
バリデータ鍵管理のセキュリティ強化

DVTはどのように機能するのか？

DVTソリューションには、以下のコンポーネントが含まれています：

シャミアの秘密分散法 (opens in a new tab) - バリデータはBLS鍵 (opens in a new tab)を使用します。個々のBLS「キーシェア」（鍵の共有部分）を組み合わせて、単一の集約鍵（署名）にすることができます。DVTでは、バリデータの秘密鍵は、クラスター内の各オペレーターのBLS署名を組み合わせたものになります。
しきい値署名スキーム (opens in a new tab) - 署名義務に必要な個々のキーシェアの数（例：4つのうち3つ）を決定します。
分散型鍵生成 (DKG) (opens in a new tab) - キーシェアを生成する暗号化プロセスであり、既存または新規のバリデータ鍵のシェアをクラスター内のノードに分散させるために使用されます。
マルチパーティ計算 (MPC) (opens in a new tab) - 完全なバリデータ鍵は、マルチパーティ計算を使用して秘密裏に生成されます。完全な鍵が個々のオペレーターに知られることはなく、オペレーターは自分自身の部分（「シェア」）しか知ることはありません。
コンセンサスプロトコル - コンセンサスプロトコルは、1つのノードをブロック・プロポーザーとして選択します。プロポーザーはクラスター内の他のノードとブロックを共有し、他のノードは集約署名に自身のキーシェアを追加します。十分な数のキーシェアが集約されると、ブロックがイーサリアム上で提案されます。

分散型バリデータにはフォールトトレランスが組み込まれており、一部の個々のノードがオフラインになっても稼働し続けることができます。これは、クラスター内の一部のノードが悪意を持っていたり、怠惰であったりしても、クラスターが回復力を持つことを意味します。

DVTのユースケース

DVTは、ステーキング業界全体に大きな影響を与えます：

ソロステーカー

また、DVTは、完全な鍵を完全にオフラインに保ちながら、バリデータ鍵をリモートノードに分散させることを可能にすることで、ノン・カストディアルなステーキングを実現します。これは、ホームステーカーが必ずしもハードウェアに費用をかける必要がないことを意味し、キーシェアを分散させることで潜在的なハッキングに対する耐性を強化するのに役立ちます。

ステーキング・アズ・ア・サービス (SaaS)

多数のバリデータを管理するオペレーター（ステーキングプールや機関投資家ステーカーなど）は、DVTを使用してリスクを軽減できます。インフラストラクチャを分散させることで、運用に冗長性を持たせ、使用するハードウェアの種類を多様化することができます。

DVTは複数のノード間で鍵管理の責任を共有するため、運用コストの一部も共有できることを意味します。また、DVTはステーキングプロバイダーの運用リスクと保険コストを削減することもできます。

ステーキングプール

標準的なバリデータ設定のため、ステーキングプールやリキッド・ステーキングプロバイダーは、利益と損失がプール全体で社会化されるため、単一オペレーターに対するさまざまなレベルの信頼を持たざるを得ません。また、これまで他に選択肢がなかったため、署名鍵の保護をオペレーターに依存しています。

従来、複数のオペレーターにステークを分散させることでリスクを分散させる努力がなされてきましたが、各オペレーターは依然として独立してかなりのステークを管理しています。単一のオペレーターに依存することは、そのオペレーターのパフォーマンスが低下したり、ダウンタイムが発生したり、侵害されたり、悪意を持って行動したりした場合に、計り知れないリスクをもたらします。

DVTを活用することで、オペレーターに求められる信頼は大幅に軽減されます。プールは、オペレーターがバリデータ鍵を保管することなくステークを保持できるようにすることができます（キーシェアのみが利用されるため）。また、管理されるステークをより多くのオペレーター間で分散させることも可能になります（たとえば、1人のオペレーターが1000個のバリデータを管理する代わりに、DVTを使用すると、それらのバリデータを複数のオペレーターで共同運用できるようになります）。多様なオペレーター構成により、1人のオペレーターがダウンした場合でも、他のオペレーターが引き続きアテステーション（証明）を行うことができます。これにより、冗長性と多様性がもたらされ、パフォーマンスと回復力が向上すると同時に、報酬が最大化されます。

単一オペレーターへの信頼を最小限に抑えることのもう1つの利点は、ステーキングプールがよりオープンでパーミッションレスなオペレーターの参加を許可できることです。これにより、サービスはリスクを軽減し、キュレーションされたオペレーターとパーミッションレスなオペレーターのセットの両方を使用することで（たとえば、ホームステーカーや小規模なステーカーを大規模なステーカーとペアにするなど）、イーサリアムの分散化をサポートできます。

DVTを使用する潜在的な欠点

追加のコンポーネント - DVTノードを導入すると、障害が発生したり脆弱になったりする可能性のある別の部分が追加されます。これを軽減する方法は、DVTノードの複数の実装、つまり複数のDVTクライアントを目指すことです（コンセンサスレイヤーと実行レイヤーに複数のクライアントがあるのと同様です）。
運用コスト - DVTはバリデータを複数の当事者間に分散させるため、単一のノードだけでなく、運用に必要なノードが増え、運用コストが増加します。
レイテンシの増加の可能性 - DVTは、バリデータを運用する複数のノード間でコンセンサスを達成するためにコンセンサスプロトコルを利用するため、レイテンシが増加する可能性があります。

参考文献

ページの最終更新: 2026年2月23日