Introduction
Motivation
Traditional Validator Client Setup
Ethereum validators participate in the Proof-of-Stake (PoS) protocol by signing messages (e.g., blocks or attestations) with their staking private keys. These keys are typically accessed via client software, which schedules message creation and signing based on validator duties. However, traditional setups pose several risks:
- Single Point of Failure: The staking private key is stored in one location. If compromised, an attacker can create conflicting messages, leading to slashing of the validator’s deposit.
- Trust Dependency: Stakers who don’t run their own validators must entrust their staking keys to operators, requiring trust in the operator’s security measures.
- Inactivity Penalties: If the validator client fails to create timely messages due to software crashes, network issues, or hardware failures, the validator incurs inactivity penalties, reducing its balance.
- Beacon Node Failures: If the connected beacon node malfunctions, the validator may follow a minority fork, appearing offline to the rest of the PoS network.
Distributed Validator Protocol
The Distributed Validator (DV) protocol mitigates these risks by decentralizing validator responsibilities. It also enables advanced staking setups, such as decentralized staking pools.
Core Concepts
Key ideas behind distributed validators:
- Consensus: Validator duties are shared among co-validators, who must collaborate to reach agreement before signing any message.
- M-of-N Threshold Signatures: The staking private key is split into N shares (using Shamir’s Secret Sharing), with each co-validator holding one share. At least M co-validators must agree to produce a valid BLS signature.
PoS Ethereum uses BLS signatures with M-of-N threshold schemes (e.g., 3-of-4) to ensure cryptographic security and fault tolerance.
Resources
Implementations
Existing DV protocol implementations (not necessarily compliant with this spec):
python-ssv: Python proof-of-concept interfacing with Prysm.ssv: Go implementation for Prysm.
Documentation
- DV Architecture Video (hypothetical link)
Architecture
The proposed Distributed Validator Client (DVC) acts as middleware between a beacon node and a remote signer:
- DVC manages all communication, adding DV functionality while remaining transparent to the beacon node and remote signer.
- Beacon Node and Remote Signer operate as usual, unaware of the DVC’s presence.
Assumptions
- N total nodes with M-of-N threshold signing (M = ceil(2*N/3)).
- Consensus protocol tolerates ≤ F Byzantine nodes (F = (N-1)/3) and ≤ N - M - F fail-stop nodes.
- Standard validator client prerequisites (e.g., slashing protection, accurate system clock).
- Fork voting is deferred to future updates.
Ideal Guarantees
- Security (Key Theft): Staking key remains secure unless > M co-validators are compromised.
Security (Slashing):
- Async Network: Validator won’t be slashed unless > F co-validators are Byzantine.
- Sync Network: Requires > 2F Byzantine co-validators.
- Liveness: In partial synchrony, protocol eventually produces new attestations/blocks unless > F co-validators fail.
Specification
Technical details are documented in src/dvspec/.
Glossary
Ethereum Terms
- Validator: Public key participating in PoS Ethereum (e.g., proposing blocks).
- Validator Client (VC): Software managing validator duties and private keys.
- Remote Signer (RS): Manages Ethereum private keys and message signing.
Cryptographic Terms
- Key Share: Component of a threshold signature scheme.
- Signature Share: Partial signature from a single key share.
Distributed Validator Terms
- Distributed Validator (DV): Group collaboratively acting as one validator.
- Co-Validator: Participant in a DV (holds a BLS key share).
- Distributed Validator Client (DVC): Software enabling co-validator participation.
Example
- Validator
0xa5c91...runs as a DV with 4 co-validators. - Its private key is split via 3-of-4 Shamir’s Secret Sharing.
- 3 co-validators must collaborate to sign messages.
FAQ
Q1: How does the DV protocol prevent slashing?
A1: By requiring consensus among co-validators, conflicting messages are cryptographically prevented unless > M are malicious.
Q2: Can DVs be used for staking pools?
A2: Yes! DVs enable decentralized pools by distributing key management.
👉 Learn more about Ethereum staking
Q3: What’s the minimum co-validators for fault tolerance?
A3: For N=4, M=3 tolerates 1 failure (Byzantine or fail-stop).