What Is DKG and Why Does Gonka Need It?
Distributed Key Generation (DKG) is a cryptographic protocol where multiple participants jointly create a shared key — without any single party ever holding the complete secret. In Gonka's context, DKG underpins the BLS threshold signature scheme that secures epoch transitions and cross-chain bridge operations.
Traditional approaches rely on a trusted dealer to generate and distribute key shares. Gonka eliminates this single point of failure entirely. Every validator participates as both a dealer and a verifier, creating a trustless key generation process anchored to on-chain consensus.
How It Works: The Four Phases
Phase 1: Initiation and Slot Assignment
When a new epoch begins, the inference module finalizes the validator set with their weights. It then calls the bls module to kick off DKG. The system assigns slot indices proportionally — a validator with 10% weight gets 10% of the total slots (e.g., 100 out of 1,000).
Each validator's secp256k1 public key (already registered on-chain) is used for encrypting shares via ECIES. No additional key generation step is needed.
Phase 2: Dealing
Every validator generates a secret polynomial of degree t_slots (where t_slots + 1 shares are needed to reconstruct a signature, typically >50% of total slots). They compute public commitments to each coefficient and encrypt individual shares for every other validator's assigned slots.
All of this is submitted on-chain via MsgSubmitDealerPart within a fixed block window (default: 5 blocks). The chain stores commitments and encrypted shares, then checks whether validators covering more than half the total slots have submitted. If not — the DKG fails and must restart.
Phase 3: Verification
Each validator retrieves all dealer submissions, decrypts the shares intended for their slots, and verifies them against the public commitments. Valid shares are aggregated into final slot secret shares.
Once verified, validators submit MsgSubmitVerificationVector to confirm successful processing. Again, a block-based deadline applies (default: 3 blocks). The chain checks that verified validators cover >50% of slots.
Phase 4: Completion and Group Key
The chain aggregates the primary commitments (C_k0) from all successful dealers to compute the Group Public Key — a BLS12-381 G2 point. This key is stored on-chain and emitted via EventGroupPublicKeyGenerated.
Each validator now holds their private slot shares and the shared group public key. Any t_slots + 1 slot holders can jointly produce a valid threshold signature.
Chain of Trust Across Epochs
When a new epoch's DKG completes, validators from the previous epoch sign the new Group Public Key using their old slot shares. This creates a cryptographic chain of trust:
- Epoch N validators produce a BLS threshold signature over Epoch N+1's group key
- The signed data includes chain ID and both epoch IDs for cross-chain security
- The G2 public key is split into three 32-byte chunks for ABI-compatible encoding
- Keccak256 hash of the encoded data serves as the message to sign
This mechanism is critical for the Ethereum bridge — it allows smart contracts to verify that a legitimate validator set endorsed each key transition.
Technical Details
Curve: BLS12-381 (Ethereum-compatible) - Secret shares and polynomials: scalar field elements - Group public key and commitments: G2 points (96 bytes compressed) - Signatures: G1 points (48 bytes compressed)
Timing: All deadlines use block heights, not wall-clock time. This ensures deterministic, consensus-safe transitions regardless of network latency.
Encryption: ECIES with secp256k1 keys for share distribution. Validators reuse their existing account keys — no separate key management required.
Threshold: With I_total = 1000 slots and t_slots = 500, any 501+ slot shares can reconstruct a valid signature. Since slots are weight-proportional, this means >50% of stake must participate.
Why This Matters
DKG in Gonka serves three purposes:
- Trustless security — no single validator can forge signatures or reconstruct the group secret
- Weight-proportional voting — a validator's signing power matches their stake through slot allocation
- Bridge integrity — the chain-of-trust mechanism lets Ethereum contracts verify Gonka's validator set transitions without trusting any external party
The recent fix in #824 addressed a consensus edge case in the dealer phase transitions, ensuring that the DKG process handles timing boundaries correctly across all validators.