Distributed Key Generation Protocols

Distributed Key Generation (DKG) solves the trusted dealer problem in threshold cryptography. Without DKG, a central party must generate the key pair and distribute shares, knowing the full private key momentarily. DKG allows n parties to jointly generate a public/private key pair through a protocol where no single party learns the private key, even the protocol coordinator.

Pedersen DKG was the first practical DKG protocol, published in 1991. Each of the n parties generates a random secret s_i and runs a Verifiable Secret Sharing (VSS) protocol to share it. Each party broadcasts commitments to their polynomial coefficients. After all parties share their contributions, the combined secret is the sum of all s_i values, and each party holds a share of this sum.

Feldman VSS (Verifiable Secret Sharing by Feldman, 1987) is the core building block of most DKG protocols. The dealer commits to polynomial coefficients as group elements (C_j = g^{a_j} mod p). Each party receiving a share f(i) can verify it against these commitments by checking that g^{f(i)} equals the product of C_j^{i^j}. This allows parties to detect if the dealer sent incorrect shares.

Joint-Feldman DKG runs Feldman VSS in parallel for all n parties, with each party acting as a dealer for their own secret. Parties then complain if they receive invalid shares. The final key is the sum of secrets from non-complained dealers. However, Joint-Feldman DKG is not secure against adaptive adversaries who corrupt parties based on protocol messages, a weakness identified by Gennaro, Jarecki, Krawczyk, and Rabin.

The GJKR DKG protocol (Gennaro, Jarecki, Krawczyk, Rabin, 1999 and 2007) addressed Joint-Feldman's weaknesses. GJKR uses Pedersen VSS (information-theoretically hiding commitments) instead of Feldman VSS, and adds complaint rounds where parties can dispute invalid shares. The resulting DKG is secure against adaptive adversaries and became the standard theoretical reference for secure DKG.

GJKR DKG requires three rounds: commitment round (each party broadcasts VSS commitments), share round (parties send shares to each other peer-to-peer), and complaint round (parties broadcast complaints about invalid shares). Parties failing to resolve complaints are disqualified. A fourth round combines valid parties' contributions into the final public key and distributed private key shares.

Ethereum's validator key management uses DKG for distributed validator technology (DVT). EIP-4844 and the DVT ecosystem (Obol Network, SSV Network) use threshold BLS signatures over BLS12-381 to allow validator committees to sign blocks without any single operator knowing the full validator key. This improves validator fault tolerance and reduces the risk of slashing from key compromise.

DRAND is a distributed randomness beacon used by the Ethereum beacon chain for unpredictable random number generation. DRAND runs DKG among a set of league of entropy nodes (Cloudflare, EPFL, Protocol Labs, etc.) to generate a threshold BLS key. Each round, t-of-n nodes contribute partial signatures that combine into an unpredictable random value. No single node can bias or predict the output.

DKG is much simpler for Schnorr/EdDSA threshold schemes than for ECDSA. In Schnorr threshold schemes, the distributed private key is simply the sum of party secrets (x = x1 + x2 + ... + xn), and the public key is the sum of public key shares (X = X1 + X2 + ... + Xn). For ECDSA, the non-linearity means DKG must produce multiplicative shares, requiring more complex protocols.

Long-lived threshold key shares can be compromised gradually if an adversary slowly corrupts parties over time. Proactive secret sharing (refresh protocols) periodically re-randomize the shares without changing the underlying key. After a refresh, shares from before the refresh are useless, limiting the window of vulnerability. GJKR and its descendants include refresh protocols that run the same structure as the initial DKG.

DKG is implemented in several production systems. The Ethereum DVT client Obol Charon uses a DKG ceremony based on Pedersen VSS over BLS12-381. Silence Laboratories's Silent Shard uses DKG for mobile MPC wallets. The dkg-go library implements GJKR for Go applications. The Threshold Network (formerly Keep Network) uses DKG for their threshold ECDSA service securing tBTC on Bitcoin.

What is the key property that makes Pedersen DKG superior to a single trusted dealer setup?

DKG eliminates the trusted dealer by having all n parties jointly generate a threshold key pair where no party knows the private key. Pedersen DKG has each party run VSS over their contribution. GJKR adds adaptive security with complaint rounds. DKG underpins Ethereum DVT (Obol, SSV), the DRAND randomness beacon, and production MPC wallet setups. Refresh protocols extend security by periodically re-randomizing shares.