Distributed Validators represent the Ethereum Staking End Game.
Distributed Validators
represent the Ethereum Staking End Game.
Distributed Validators (DVs) let multiple nodes or operators run validators together, eliminating single points of failure and reducing slashing risk.
obol'S DV Implementation
✔️
Introduces Byzantine and Crash Fault Tolerance
✔️
Minimizes slashing risk through DKG process
✔️
Lets multiple entities operate nodes trustlessly
✔️
Reduces client diversity risk and centralized stake
Learn more
THE PROBLEM WITH EARLY STAKING INFRASTRUCTURE
Legacy validators are fragile.
Early staking infrastructure has held Ethereum back. Most legacy validators 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. Every legacy validator is a single point of failure for the network.
Ethereum deserves better. This is why we built Distributed Validators.
the new standard for STAKING
Distributed Validators are next-generation staking infrastructure.
Distributed Validators enable multi-node operation. DV clusters allow multiple nodes or operators, eliminating single points of failure and slashing risk. DVs are set up through a Distributed Key Generation event, so no single entity ever has access to the full private key. Each node and operator in a DV cluster operates as a single logical validator via Obol’s DV middleware layer. Charon is the first DV middleware client. Obol will soon move to a multi-client architecture at the middleware layer when Nethermind builds its DV client, Pluto.
Distributed Validators are the most secure and performant way to stake. This is why they are replacing legacy validator infrastructure.
How a DV works
Distributed Validators offer best-in-class security and resilience.
Distributed Validators use threshold signing. Each node submits a partial signature and the entries get aggregated into one full signature at the middleware layer. As long as >66% of the nodes are online, the validator stays online.
Threshold signing makes Distributed Validators secure. No single copy of the full validator private key exists.
Why DVs Are the New Standard
Why DVs Are the New Standard
Superior performance and slashing resistance
Thanks to the multi-node configuration, Distributed Validators can continue operating even if one-third of the nodes go offline. This feature results in high uptime and resilience without the slashing risks associated with running legacy validators.
Private key distribution and security
With DVs, validator key shares are generated through a Distributed Key Generation (DKG) ceremony, ensuring that no single copy of the full validator private key exists. This significantly reduces the risk of key compromise since more than two-thirds of the key shares would need to be stolen to derive the full key.
Byzantine Fault Tolerance
Multiple Charon clients come to consensus on validator duties and behave as a single unified Proof-of-Stake validator. With a supermajority of honest nodes, the system achieves Byzantine Fault Tolerance.
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 runs Ethereum’s Proof-of-Stake consensus layer, commonly referred to as the Beacon Chain.
The consensus client runs Ethereum’s Proof-of-Stake consensus layer, commonly referred to as the Beacon Chain.
DV middleware client
The DV client intercepts the standardized REST API communication between any consensus client and validator client pair. It coordinates with other 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 standardized REST API communication between any consensus client and validator client pair. It coordinates with other 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 operates as it would with a legacy setup, using the assigned validator key shares it receives to sign a message before passing it back to the client for aggregation.
The validator client operates as it would with a legacy setup, using the assigned validator key shares it receives to sign a message before passing it back to the client for aggregation.
How Obol Compares to
Other DV Implementations
Obol differs from other DV implementations in that it’s optimized for security and decentralization.
With the DKG, threshold signing, and other features, it’s the most Ethereum-aligned DV solution.
Obol differs from other DV implementations in that
it’s optimized for security and decentralization.
With the DKG, threshold signing, and other features,
it’s the most Ethereum-aligned DV solution.
Byzantine & crash fault tolerant
Obol DVT
Other DVT
Byzantine and Crash Fault Tolerant
✔️
✔️
Key shares reduce slashing risk
✔️
✔️
Non-custodial reward splits
✔️
?
DKG with no private keys put onchain
✔️
❌
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
✔️
?
DKG with no private keys put onchain
✔️
❌
No non-ETH token risk
✔️
❌
Swappable cluster participants
✔️
✔️
Obol Is Ethereum’s Composable Middleware Layer
Obol Is Ethereum’s Composable Middleware Layer
Our DV solution offers security, resilience, and composability. Our mission is to strengthen and decentralize Ethereum.
Our DV solution offers security, resilience, and composability. Our mission is to strengthen and decentralize Ethereum.
Superior performance and slashing resistance
Thanks to the multi-node configuration, Distributed Validators can continue operating even if one-third of the nodes go offline. This feature results in high uptime and resilience without the slashing risks associated with running legacy validators.
Private key distribution and security
With DVs, validator key shares are generated through a Distributed Key Generation (DKG) ceremony, ensuring that no single copy of the full validator private key exists. This significantly reduces the risk of key compromise since more than two-thirds of the key shares would need to be stolen to derive the full key.
Byzantine Fault Tolerance
Multiple Charon clients come to consensus on validator duties and behave as a single unified Proof-of-Stake validator. With a supermajority of honest nodes, the system achieves Byzantine Fault Tolerance.
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. Nethermind’s Pluto will also soon provide an alternative to the first DV client, Charon, at the middleware layer. Embracing client diversity ensures a DV cluster will remain unaffected by issues affecting any one client.
Why DVs Are the New Standard
Join the Ethereum Staking End Game
Upgrade to the end game staking configuration with Obol Distributed Validators.
Get Started
Product Suite
Get Started
Product Suite
Get Started
Product Suite
THE PROBLEM WITH EARLY STAKING INFRASTRUCTURE
Legacy validators are fragile.
Early staking infrastructure has held Ethereum back. Most legacy validators 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. Every legacy validator is a single point of failure for the network.
Ethereum deserves better. This is why we built Distributed Validators.
the new standard for STAKING
Distributed Validators are next-generation staking infrastructure.
Distributed Validators enable multi-node operation. DV clusters allow multiple nodes or operators, eliminating single points of failure and slashing risk. DVs are set up through a Distributed Key Generation event, so no single entity ever has access to the full private key. Each node and operator in a DV cluster operates as a single logical validator via Obol’s DV middleware layer. Charon is the first DV middleware client. Obol will soon move to a multi-client architecture at the middleware layer when Nethermind builds its DV client, Pluto.
Distributed Validators are the most secure and performant way to stake. This is why they are replacing legacy validator infrastructure.
How a DV works
Distributed Validators offer best-in-class security and resilience.
Distributed Validators use threshold signing. Each node submits a partial signature and the entries get aggregated into one full signature at the middleware layer. As long as >66% of the nodes are online, the validator stays online.
Threshold signing makes Distributed Validators secure. No single copy of the full validator private key exists.
THE PROBLEM WITH EARLY STAKING INFRASTRUCTURE
Legacy validators are fragile.
Early staking infrastructure has held Ethereum back. Most legacy validators 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. Every legacy validator is a single point of failure for the network.
Ethereum deserves better. This is why we built Distributed Validators.
the new standard for STAKING
Distributed Validators are next-generation staking infrastructure.
Distributed Validators enable multi-node operation. DV clusters allow multiple nodes or operators, eliminating single points of failure and slashing risk. DVs are set up through a Distributed Key Generation event, so no single entity ever has access to the full private key. Each node and operator in a DV cluster operates as a single logical validator via Obol’s DV middleware layer. Charon is the first DV middleware client. Obol will soon move to a multi-client architecture at the middleware layer when Nethermind builds its DV client, Pluto.
Distributed Validators are the most secure and performant way to stake. This is why they are replacing legacy validator infrastructure.
How a DV works
Distributed Validators offer best-in-class security and resilience.
Distributed Validators use threshold signing. Each node submits a partial signature and the entries get aggregated into one full signature at the middleware layer. As long as >66% of the nodes are online, the validator stays online.
Threshold signing makes Distributed Validators secure. No single copy of the full validator private key exists.