What is a Distributed Validator?
Distributed Validators (DVs) enable multiple nodes or parties to run validators together.
obol'S DV Implementation
✔️
Byzantine & crash fault tolerant
✔️
Key shares reduce slashing risk
✔️
No private keys put on chain
✔️
No non-ETH token risk
Learn more
The problem with validators today
Traditional validators are fragile
Most validators today run on a single machine, using a single private key. If that machine goes down, that validator goes down. Worse still, if that private key is compromised, that validator is compromised.
Each validator is a single-point-of-failure for the Ethereum network.
the new standard for validators
DVs enable multi-node operation
A distributed validator cluster consists of multiple nodes (ideally 4, 7, or 10). Each node within a cluster has a partial validator key share that is generated in a distributed key generation ceremony (DKG). The nodes within a DV cluster operate together as a single logical validator through the inclusion of a DV middleware client, Charon.
Distributed validators enable fault tolerance for validators without introducing slashing risk.
How a DV works
Threshold signing enables secure & resilient operation
During operation, Charon coordinates what each validator signs by reconstituting the partial signatures into an aggregate signature for the distributed validator. As long as >66% of the nodes within a cluster are online, the validator stays online.
Distributed validators improve security by ensuring that at no time is the full validator private key present in a single place.
The Capabilities of DVs
The Capabilities of DVs
High availability without slashing
Distributed validator clusters can continue operating normally even with up to one-third of the nodes offline or malfunctioning. This feature allows for high uptime without the slashing risks associated with running two or more copies of a traditional validator.
High Availability Without Slashing
Distributed validator clusters can continue operating normally even with up to one-third of the nodes offline or malfunctioning. This feature allows for high uptime without the slashing risks associated with running two or more copies of a traditional validator.
Private key distribution & security
Validator key shares are generated through a distributed key generation (DKG) ceremony, ensuring that the full key never exists. This greatly reduces the risk of validator key compromise since more than two-thirds of the key shares would need to be stolen to derive the full validator private key.
Private key distribution & security
Validator key shares are generated through a distributed key generation (DKG) ceremony, ensuring that the full key never exists. This greatly reduces the risk of validator key compromise since more than two-thirds of the key shares would need to be stolen to derive the full validator private key.
Byzantine fault tolerance
Multiple Charon clients come to consensus on validator duties and behave as a single unified proof-of-stake validator, achieving byzantine-fault tolerance given a supermajority of honest nodes.
Byzantine fault tolerance
Multiple Charon clients come to consensus on validator duties and behave as a single unified proof-of-stake validator, achieving byzantine-fault tolerance given a supermajority of honest nodes.
Client diversity
Each node within a DV cluster can run their own combination of execution, consensus, and validator clients, allowing client diversity to be built directly into a validator. This ensures a DV cluster will remain unaffected by issues with any one client.
Client diversity
Each node within a DV cluster can run their own combination of execution, consensus, and validator clients, allowing client diversity to be built directly into a validator. This ensures a DV cluster will remain unaffected by issues with any one client.
Obol's DV Node Client Stack
Obol's DV Node Client Stack
Execution client
The execution client runs the EVM and manages the transaction pool for the Ethereum network. These clients provide execution payloads to consensus clients for inclusion into blocks.
The execution client runs the EVM and manages the transaction pool for the Ethereum network. These clients provide execution payloads to consensus clients for inclusion into blocks.
Consensus client
The consensus client's duty is to run the Proof of Stake consensus layer of Ethereum, commonly referred to as the Beacon Chain.
The consensus client's duty is to run the Proof of Stake consensus layer of Ethereum, commonly referred to as the Beacon Chain.
DV middleware client
The DV client intercepts the standardised REST API communication between any consensus client and validator client pair, and coordinates with other Charon clients in the cluster to reach consensus on what to present the validator to sign, and then to aggregate the returned signature.
The DV client intercepts the standardised REST API communication between any consensus client and validator client pair, and coordinates with other Charon clients in the cluster to reach consensus on what to present the validator to sign, and then to aggregate the returned signature.
Validator client
The validator client functions as normal, using the validator key share to sign a message it has received from Charon, before passing it back to Charon for aggregation.
The validator client functions as normal, using the validator key share to sign a message it has received from Charon, before passing it back to Charon for aggregation.
Obol’s No-Compromises DV Implementation
Byzantine & crash fault tolerant
Obol DVT
Other DVT
Byzantine & crash fault tolerant
✔️
✔️
Key shares reduce slashing risk
✔️
✔️
Non-custodial reward splits
✔️
?
No private keys put on chain
✔️
❌
No non-ETH token risk
✔️
❌
Swappable cluster participants
...
✔️
Byzantine & crash fault tolerant
Obol DVT
Other DVT
Byzantine & crash fault tolerant
✔️
✔️
Key shares reduce slashing risk
✔️
✔️
Non-custodial reward splits
✔️
?
No private keys put on chain
✔️
❌
No non-ETH token risk
✔️
❌
Swappable cluster participants
...
✔️
Byzantine & crash fault tolerant
✔️
✔️
Byzantine & crash fault tolerant
Obol DVT
Other DVT
Non-custodial reward splits
✔️
✔️
Key shares reduce slashing risk
✔️
✔️
Non-custodial reward splits
✔️
?
No private keys put on chain
✔️
❌
No non-ETH token risk
✔️
❌
Swappable cluster participants
...
✔️
A Composable DV Middleware
We built our DV solution as a middleware, prioritising security, resilience, and composability. This is in support of our mission to strengthen and decentralize Ethereum.
High Availability Without Slashing
Distributed Validator Clusters can continue operating normally even with up to 1/3rd of the nodes offline or malfunctioning. This feature allows for high uptime without the slashing risks associated with running two or more copies of a traditional validator.
Private Key Distribution & Security
Validator key shares are generated through a Distributed Key Generation (DKG) ceremony, ensuring that the full key never exists. This greatly reduces the risk of validator key compromise since more than two-thirds of the key shares would need to be stolen to derive the full validator private key.
Byzantine Fault Tolerance
Multiple Charon clients come to consensus on validator duties and behave as a single unified proof-of-stake validator, achieving byzantine-fault tolerance given a supermajority of honest nodes.
Client Diversity
Each node within a DV cluster can run their own combination of EL, CL, and validator clients, allowing client diversity to be built directly into a validator, ensuring it will remain unaffected by issues with any one client.
The capabilities of DV
Get Started
Enter Obol’s decentralized operator ecosystem.
Get Started
Products
Get Started
Products
Get Started
Products
The problem with validators today
Traditional validators are fragile
Most validators today run on a single machine, using a single private key. If that machine goes down, that validator goes down. Worse still, if that private key is compromised, that validator is compromised.
Each validator is a single-point-of-failure for the Ethereum network.
The problem with validators today
Traditional validators are fragile
Most validators today run on a single machine, using a single private key. If that machine goes down, that validator goes down. Worse still, if that private key is compromised, that validator is compromised.
Each validator is a single-point-of-failure for the Ethereum network.
the new standard for validators
DVs enable multi-node operation
A distributed validator cluster consists of multiple nodes (ideally 4, 7, or 10). Each node within a cluster has a partial validator key share that is generated in a distributed key generation ceremony (DKG). The nodes within a DV cluster operate together as a single logical validator through the inclusion of a DV middleware client, Charon.
Distributed validators enable fault tolerance for validators without introducing slashing risk.
the new standard for validators
DVs enable multi-node operation
A distributed validator cluster consists of multiple nodes (ideally 4, 7, or 10). Each node within a cluster has a partial validator key share that is generated in a distributed key generation ceremony (DKG). The nodes within a DV cluster operate together as a single logical validator through the inclusion of a DV middleware client, Charon.
Distributed validators enable fault tolerance for validators without introducing slashing risk.
How a DV works
Threshold signing enables secure & resilient operation
During operation, Charon coordinates what each validator signs by reconstituting the partial signatures into an aggregate signature for the distributed validator. As long as >66% of the nodes within a cluster are online, the validator stays online.
Distributed validators improve security by ensuring that at no time is the full validator private key present in a single place.
How a DV works
Threshold signing enables secure & resilient operation
During operation, Charon coordinates what each validator signs by reconstituting the partial signatures into an aggregate signature for the distributed validator. As long as >66% of the nodes within a cluster are online, the validator stays online.
Distributed validators improve security by ensuring that at no time is the full validator private key present in a single place.
The problem with validators today
Traditional validators are fragile
Most validators today run on a single machine, using a single private key. If that machine goes down, that validator goes down. Worse still, if that private key is compromised, that validator is compromised.
Each validator is a single-point-of-failure for the Ethereum network.
The problem with validators today
Traditional validators are fragile
Most validators today run on a single machine, using a single private key. If that machine goes down, that validator goes down. Worse still, if that private key is compromised, that validator is compromised.
Each validator is a single-point-of-failure for the Ethereum network.
the new standard for validators
DVs enable multi-node operation
A distributed validator cluster consists of multiple nodes (ideally 4, 7, or 10). Each node within a cluster has a partial validator key share that is generated in a distributed key generation ceremony (DKG). The nodes within a DV cluster operate together as a single logical validator through the inclusion of a DV middleware client, Charon.
Distributed validators enable fault tolerance for validators without introducing slashing risk.
the new standard for validators
DVs enable multi-node operation
A distributed validator cluster consists of multiple nodes (ideally 4, 7, or 10). Each node within a cluster has a partial validator key share that is generated in a distributed key generation ceremony (DKG). The nodes within a DV cluster operate together as a single logical validator through the inclusion of a DV middleware client, Charon.
Distributed validators enable fault tolerance for validators without introducing slashing risk.
How a DV works
Threshold signing enables secure & resilient operation
During operation, Charon coordinates what each validator signs by reconstituting the partial signatures into an aggregate signature for the distributed validator. As long as >66% of the nodes within a cluster are online, the validator stays online.
Distributed validators improve security by ensuring that at no time is the full validator private key present in a single place.
How a DV works
Threshold signing enables secure & resilient operation
During operation, Charon coordinates what each validator signs by reconstituting the partial signatures into an aggregate signature for the distributed validator. As long as >66% of the nodes within a cluster are online, the validator stays online.
Distributed validators improve security by ensuring that at no time is the full validator private key present in a single place.