Golden DKG and Context-Dependent Threshold Decryption

Miden's private validator project aims to make TEE-equipped validators each store encrypted records of the transactions they check, such that no validator can open a record alone. Opening one takes a threshold of validators, reserved for cases such as forensic audits, where a request targets one transaction and must not become a standing decryption ability.

Two cryptography problems follow. The validators must create a shared key without trusting any one member, and decryption shares given for one approved request must work for nothing else. golden-dkg is a Rust implementation of the two schemes that fit these problems. The Golden DKG (ePrint 2025/1924), and the EHTDH1 variant of the Context-Dependent Threshold Decryption paper (ePrint 2025/279).

A distributed key generation protocol, or DKG, lets validators create a shared secret key without the full key ever existing on one machine. Running a "traditional" DKG is a ceremony. Participants exchange private shares, raise complaints about bad shares, answer those complaints, and agree on the final validator set, round by round. Every round needs everyone online and responsive, and missing validators can stall the setup. It is like organizing a conference call across time zones. You wait on the stragglers, and when one person drops you start the call over.

Golden DKG cuts this to one broadcast per validator, total: each validator posts one dealing, containing encrypted shares for the others. A cheap Diffie-Hellman value protects each share, and an exponent VRF lets anyone verify that the dealing is well formed. The dealings are independent public objects on a bulletin board. One validator can post right now and another a bit later, and most of the remaining work is local.

With 50 validators the Golden paper estimates 223 kB of bandwidth and 13.5 s of runtime per validator, against 27.8 MB and 40.5 s an ElGamal-based construction, hence a large improvement over the state of the art. This repository's BLS12-381/Jubjub backend (one of several) measures 375.5 kB and 6.98 s at 50 validators and 1.27 MB and 20.7 s at 100, delivering the estimated improvements in practice — and we'll keep improving on those results !

EHTDH1 applies after the shared key exists, and improves over simple deployments of threshold decryption. Ordinary threshold decryption shares for one ciphertext can combine across blocks, epochs, or consensus views, even though fewer validators approved any one context. EHTDH1 binds every share to the setup, the ciphertext, and the caller's context. Each validator mixes its decryption-key share with a share of zero from a second Golden DKG run. When enough validators use the same context, the zero shares cancel and decryption succeeds. Shares from different contexts do not cancel, so the mathematics enforces the separation on its own.

The implementation fills in details the papers leave to applications. It defines canonical wire encodings, binds messages to the setup and participant registry, commits protocol data to transcripts, and separates the generic protocol from its proof backends. It supports BLS12-381/Jubjub and Secp256k1/Secq256k1 through bulletproofs-cycle, a Bulletproofs implementation that is not tied to the Ristretto group.

For Miden's private validators, these pieces mean the validators can create and rotate their key without a trusted dealer, and can release a record key only for a specific request that authorized a specific access scope. They are one part of the design. Submission encryption and later TEE isolation are separate pieces and are not in this repository.

By François Garillot ( @huitseeker) and Miden’s Crypto & VM team.

‍