Abstract

Distributed Key Generation (DKG) allows a group of participants to jointly produce a public key and corresponding secret key shares such that no single participant ever holds the complete private key. For proof-of-stake validator networks that use BLS signatures for attestations and block proposals, DKG is the protocol that makes distributed validator technology (DVT) practical - splitting a validator key across multiple nodes so that the validator remains live and signing even if a subset of nodes goes offline, while the full private key is never materialized in any one place. The practical deployment challenges of DKG in adversarial validator environments are substantially different from the idealized synchronous models most DKG protocols assume.

DKG Protocol Families

The two most widely studied DKG protocol families are Pedersen DKG (based on Feldman’s verifiable secret sharing with a distributed randomness generation step) and the more recent GJKR (Gennaro-Jarecki-Krawczyk-Rabin) protocol, which provides stronger security guarantees in the presence of malicious participants. Both protocols require a complaint round where participants can broadcast evidence of misbehavior by a dealer, and both assume a reliable broadcast channel - which maps awkwardly onto a peer-to-peer validator network where nodes may be temporarily offline or censored. The dkg crate from the Zcash Foundation and the blst-integrated DKG implementation in Obol Network’s Charon client are two production-adjacent implementations that handle the reliable broadcast problem using a coordinator or pre-committed ordering mechanism.

DVT Deployments on Ethereum

As of late 2025, distributed validator technology is in active production deployment on the Ethereum mainnet via Obol Network and SSV Network. Both use threshold BLS signatures where a t-of-n quorum of operator nodes must sign each attestation, and the validator’s effective BLS key is a combined public key generated through a DKG ceremony at validator registration time. Obol’s Charon middleware intercepts the validator client’s signing requests and distributes them to the participant nodes, collecting partial signatures and combining them without any node seeing the full private key. SSV uses a similar architecture but with a more permissionless operator marketplace. The DVT Foundation, a cross-project consortium including Ethereum Foundation researchers, maintains compatibility specifications to prevent fragmentation of the DKG and threshold signature protocols used across implementations.

Handling Asynchrony and Malicious Participants

Real-world DKG over the internet must tolerate asynchronous message delivery. Classic DKG protocols assume synchronous rounds with timeouts, and a node that fails to respond within a round can be treated as malicious, but setting timeouts too aggressively causes false disqualifications of honest nodes with high latency. The FROST DKG protocol (Komlo and Goldberg, 2020), designed for threshold Schnorr signing, addresses this with a simplified two-round design that is more robust to network variability, though it requires an honest majority. For Byzantine fault tolerance without an honest majority assumption, protocols derived from ADKG (Asynchronous DKG, Kate et al.) use asynchronous verifiable secret sharing (AVSS) and can tolerate up to t < n/3 Byzantine participants without timing assumptions - at the cost of significantly higher message complexity. Ethereum’s DVT use case operates under an honest majority assumption in practice, making FROST-derived protocols a pragmatic fit.

Key Resharing and Operational Continuity

A DKG ceremony produces key shares that must be redistributed if the set of participating nodes changes - due to operator churn, hardware failures, or security rotation. Key resharing allows the existing threshold of share-holders to produce a new set of shares for a new participant set without materializing the original private key. Obol’s implementation supports resharing through a second DKG round that treats the existing shares as inputs to a new secret sharing. Operationally, resharing ceremonies introduce a window where both old and new share sets are valid, requiring careful coordination to avoid signing with stale shares while the new ceremony completes - a transition that is straightforward in theory but requires explicit state-machine management in production validator software.