---
title: 分散型バリデータ技術
description: 分散型バリデータ技術は、複数の関係者によるイーサリアムバリデータの分散運用を可能にします。
lang: ja
template: staking
sidebarDepth: 2
summaryPoints:
  - バリデータの署名鍵を複数のマシンやオペレーターに分割し、単一障害点を排除します。
  - 個々のハードウェア、ソフトウェア、またはオペレーターの障害が発生しても、バリデータをオンラインに保ちます。
  - ソロ・ステーカー、ステーキングサービス、ステーキング・プールによって現在使用されている本番インフラストラクチャです。
---

## 分散型バリデータ技術とは何ですか？ {#what-is-dvt}

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

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

![単一のバリデータ鍵が鍵のシェアに分割され、さまざまなコンポーネントを持つ複数のノードに配布される仕組みを示す図。](./dvt-cluster.png)

DVTは、ステーキングの別の方法ではありません。これは、あらゆるステーキングのセットアップで使用できるソフトウェアのレイヤーです。
- [ソロ・ステーカー](/staking/solo/)はチームを組んでバリデータを共同で実行したり、個人のソロ・ステーカーがDVTを使用してソロ・ステーキングのセットアップに回復力を追加したりできます。
- [ステーキングサービス](/staking/saas/)や[ステーキング・プール](/staking/pools/)は、DVTを使用して回復力を追加し、ステーキングインフラストラクチャを強化したり、バリデータの運用を多数の独立したオペレーターに分散させたりできます。

## なぜDVTが必要なのですか？ {#why-do-we-need-dvt}

### セキュリティ {#security}

バリデータは、コンセンサスに参加するためのバリデータ鍵と、資金にアクセスするための引き出し鍵という2つの公開鍵・秘密鍵ペアを生成します。バリデータは引き出し鍵をコールドストレージで保護できますが、アテステーションやブロック提案など、24時間体制で割り当てられた義務に署名するために、バリデータの秘密鍵は24時間365日オンラインである必要があります。鍵をオンラインに保つと盗難のリスクにさらされますが、DVTはそのリスクを制限します。オンラインになるのは鍵のシェア（分割された鍵）のみであり、完全な鍵がオンラインになることはありません。

バリデータの秘密鍵が侵害された場合、攻撃者はバリデータを制御でき、スラッシングやステーカーのETHの損失につながる可能性があります。DVTはこのリスクを軽減します。DVTを使用すると、元の完全なバリデータ鍵は暗号化され、鍵のシェアに分割されます。鍵のシェアはオンラインに存在し、バリデータを共同で運用する複数のノードに分散されますが、完全な「マスター」鍵は安全にオフラインに保たれます。この分散が可能になるのは、[イーサリアム](/)のバリデータが加法的なBLS署名を使用しているためです。つまり、構成要素を合計することで完全な鍵を再構築できます。鍵のシェアで作成された部分的な署名は、完全な鍵に対して有効な署名に結合されるため、日々の署名に完全な鍵自体は必要ありません。クラスターが分散型鍵生成を使用して新しいバリデータ鍵を生成する場合、完全な秘密鍵が単一のマシンに存在することは決してありません。

### 単一障害点の排除 {#no-single-point-of-failure}

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

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

### 分散化 {#decentralization}

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

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

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

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

## DVTはどのように機能しますか？ {#how-does-dvt-work}

DVTの実装は通常、クラスター内の各マシンで追加のソフトウェアとして実行されます。このソフトウェアはミドルウェアとして機能し、ノードのバリデータクライアントとコンセンサス・クライアントの間に位置し、クラスター内の他のノードと連携して、バリデータの義務が集合的に署名されるようにします。

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

- **[シャミアの秘密分散法](https://medium.com/@keylesstech/a-beginners-guide-to-shamir-s-secret-sharing-e864efbf3648)** - バリデータは[BLS鍵](https://en.wikipedia.org/wiki/BLS_digital_signature)を使用します。バリデータの秘密鍵は複数の「鍵のシェア」に分割でき、BLS署名は加法であるため、それらの鍵のシェアで作成された部分的な署名を組み合わせて、完全なバリデータ鍵に対して有効な単一の署名にすることができます。
- **[しきい値署名スキーム](https://medium.com/nethermind-eth/threshold-signature-schemes-36f40bc42aca)** - 署名の義務に必要な個々の鍵のシェアの数（例：4つのうち3つ）を決定します。
- **[分散型鍵生成 (DKG)](https://medium.com/toruslabs/what-distributed-key-generation-is-866adc79620)** - 鍵のシェアを生成する暗号化プロセスであり、既存または新規のバリデータ鍵のシェアをクラスター内のノードに分散させるために使用されます。
- **[マルチパーティ計算 (MPC)](https://messari.io/report/applying-multiparty-computation-to-the-world-of-blockchains)** - 完全なバリデータ鍵は、マルチパーティ計算を使用して秘密裏に生成されます。完全な鍵が個々のオペレーターに知られることはなく、彼らは自分自身の部分（「シェア」）しか知ることはありません。
- **コンセンサスプロトコル** - コンセンサスプロトコルは、1つのノードをブロック・プロポーザーとして選択します。プロポーザーはクラスター内の他のノードとブロックを共有し、他のノードは集約署名に自身の鍵のシェアを追加します。十分な数の鍵のシェアが集約されると、ブロックがイーサリアム上で提案されます。

分散型バリデータにはフォールトトレランスが組み込まれており、個々のノードの一部がオフラインになっても実行を継続できます。バリデータノードのクラスターは、その中の一部のノードが悪意を持っていたり怠惰であったりしても、回復力を維持します。

## 本番環境でのDVT {#dvt-in-production}

分散型バリデータは現在、メインネット上でソロ、サービス、およびプール・ステーキング全体で実行されています。この活動の大部分は、以下の2つのネットワークが占めています：

<ProductDisclaimer />

- **Obol**は、マシンのクラスターがバリデータを共同で運用（「スクワッド・ステーキング」）できるようにするオープンソースのDVTミドルウェアクライアントであるCharonを開発しています。グループは分散型鍵生成を実行し、Obolの[DV Launchpad](https://docs.obol.org/learn/readme/launchpad)を通じてクラスターを構成します。Obolクラスターは、リドのSimple DVTモジュールや、ホームオペレーターをフォールトトレラントなクラスターにオンボーディングするEtherFiのOperation Solo Stakerプログラムなど、[ステーキングプロトコル](/staking/pools/)や[ステーキングサービス](/staking/saas/)によって本番環境で使用されています。
- **SSV Network**は、独立したノードオペレーターによるパーミッションレスなネットワークです。バリデータ鍵は鍵のシェアに分割され、選択されたオペレーターのセットに分散され、彼らが集合的にバリデータの義務を実行します。単一のオペレーターが完全な鍵を保持することは決してありません。ステーキングサービスやプールはSSV上で大規模なバリデータセットを実行しており、Obolと同様に、リドのSimple DVTモジュールで使用されています。

## DVTのユースケース {#dvt-use-cases}

DVTは、より広範なステーキング業界に重要な影響を与えます：

### ソロ・ステーカー {#solo-stakers}

DVTは**スクワッド・ステーキング**を可能にします。これは、友人、コミュニティメンバー、またはローンチパッドを通じて調整された見知らぬ人などの少人数のグループが、各自のマシン全体で単一のバリデータを共同で実行することです。バリデータが義務を実行するには、グループのしきい値（たとえば、4人のうち3人）がオンラインである必要があるため、単一のメンバーのダウンタイム、ハードウェア障害、またはミスによってバリデータがオフラインになることはありません。分散型鍵生成で鍵が作成される場合、どのメンバーも完全な署名鍵を保持することはありません。

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

### ステーキング・アズ・ア・サービス (SaaS) {#saas}

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

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

### ステーキング・プール {#staking-pools}

標準的なバリデータのセットアップにより、ステーキング・プールやリキッド・ステーキングプロバイダーは歴史的に、利益と損失がプール全体で社会化されるため、個々のオペレーターに大きな信頼を置く必要がありました。また、DVTが登場するまでは他に選択肢がなかったため、署名鍵の保護をオペレーターに依存していました。

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

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

単一オペレーターへの信頼を最小限に抑えることのもう1つの利点は、ステーキング・プールがよりオープンでパーミッションレスなオペレーターの参加を許可できることです。現在、一部のステーキング・プールは本番環境でこれを行っています。マルチオペレーターのDVTクラスターにより、プロトコルはホームステーカーや小規模なオペレーターを大規模なプロのオペレーターとペアリングし、キュレーションされたオペレーターセットとパーミッションレスなオペレーターセットを組み合わせることができます。

## DVTを使用する際の潜在的な欠点 {#potential-drawbacks-of-using-dvt}

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

## よくある質問 {#faq}

<ExpandableCard title="ステーキングにDVTは必要ですか？" eventCategory="DVT" eventName="clicked do I need DVT to stake">
いいえ。バリデータクライアントを実行している単一のマシンは、DVTソフトウェアなしで機能し、これは依然として一般的なホームステーキングのセットアップです。DVTは、フォールトトレランスを追加し、単一障害点を排除するオプションのレイヤーです。これは、個々のマシンの障害からバリデータを生き残らせたい場合や、バリデータを実行する責任を他の人と共有したい場合に役立ちます。
</ExpandableCard>

<ExpandableCard title="DVTはETHや引き出し鍵を分割しますか？" eventCategory="DVT" eventName="clicked does DVT split my ETH">
いいえ。DVTは、アテステーションやブロック提案などのコンセンサスの義務に使用されるバリデータの_署名_鍵のみを分割します。あなたのステークは常にバリデータに設定された引き出しアドレスによって制御され、DVTの影響を受けません。ペクトラアップグレード以降、引き出しアドレスの保持者は、署名鍵をまったく必要とせずに、実行レイヤーから直接バリデータのエグジットをトリガーすることもできます。
</ExpandableCard>

<ExpandableCard title="クラスター内のノードがオフラインになるとどうなりますか？" eventCategory="DVT" eventName="clicked what happens if nodes go offline">
ノードのしきい値（たとえば、4つのうち3つ）がオンラインである限り、バリデータは義務を実行し続けます。一度に多くのノードがオフラインになった場合、バリデータは単にオフラインになり、十分な数のノードが戻るまで報酬を逃します。これは他のオフラインのバリデータと同じです。オフラインになることはスラッシングの対象となる違反ではありません。
</ExpandableCard>

<ExpandableCard title="クラスターは4つのうち3つである必要がありますか？" eventCategory="DVT" eventName="clicked does a cluster have to be 3 of 4">
いいえ。「4つのうち3つ」は最も小さな一般的な構成にすぎず、このページ全体で例として使用されています。クラスターのサイズと署名のしきい値は、クラスターの作成時に選択されます。

クラスターは通常、しきい値がノードの3分の2のスーパーマジョリティになるようにサイズ設定されます。これにより、障害のあるメンバーやオフラインのメンバーを許容しながら、クラスターが署名を継続できるようになります。4ノードのクラスターは3つで署名し、1つの障害を許容します。7ノードは5つで署名し、2つを許容します。10ノードは7つで署名し、3つを許容します。より大きなクラスターは、実行するマシンの増加とそれらの間の調整の増加を犠牲にして、より多くのフォールトトレランスを獲得します。

[クラスターのサイズと回復力の詳細](https://docs.obol.org/next/learn/charon/cluster-configuration#cluster-size-and-resilience)
</ExpandableCard>

<ExpandableCard title="DVTはプール・ステーキングと同じですか？" eventCategory="DVT" eventName="clicked is DVT the same as pooled staking">
いいえ。プール・ステーキングは、多くの人々からのETHを組み合わせてバリデータに資金を提供し、いくつかの[ステーキング方法](/staking/)の1つです。DVTはバリデータを_運用_するためのインフラストラクチャです。1つのバリデータの署名を複数のマシンとオペレーターに分散させます。この2つは補完的です。多くのプールはDVTを使用してオペレーターセットを分散させますが、DVT自体は誰のETHもプールしません。
</ExpandableCard>

## 参考文献 {#further-reading}

- [イーサリアムの分散型バリデータ技術 (DVT) - 完全な紹介](https://www.cyfrin.io/blog/full-introduction-to-ethereum-distributed-validator-technology-dvt) - Cyfrin
- [DVTとは何か、そしてイーサリアムでのステーキングをどのように改善するのか？](https://blog.obol.org/what-is-dvt-and-how-does-it-improve-staking-on-ethereum/) - Obol
- [イーサリアム分散型バリデータの仕様（ハイレベル）](https://github.com/ethereum/distributed-validator-specs)
- [イーサリアム分散型バリデータの技術仕様](https://github.com/ethereum/distributed-validator-specs/tree/dev/src/dvspec)
- [Obolドキュメント](https://docs.obol.org/)
- [SSV Networkドキュメント](https://docs.ssv.network/)
- [リド Simple DVTモジュール](https://operatorportal.lido.fi/modules/simple-dvt-module)
- [シャミアの秘密分散法デモアプリ](https://iancoleman.io/shamir/)