In October 2016, six people gathered in locations across three continents to perform a cryptographic ritual that would secure hundreds of billions of dollars in future Zcash transactions. Each participant generated random numbers, used them to compute part of a mathematical structure, and then destroyed the random numbers irreversibly. If even one participant successfully destroyed their randomness, the resulting parameters would be secure. If all six were compromised – by coercion, hacking, or collusion – an attacker could forge Zcash transactions, creating coins from nothing with no detectable trace.
This was the Zcash Sprout ceremony. It generated the structured reference string (SRS) that powered Zcash’s zk-SNARK proof system for its first two years. The ceremony took days of coordination, involved air-gapped computers, electromagnetic shielding, and the physical destruction of hardware. One participant incinerated their computer. Another used a process involving radioactive decay as a randomness source.
This is what a trusted setup ceremony looks like. It is the most unusual security requirement in modern cryptography: a one-time ritual where participants must create and then permanently destroy secret values – “toxic waste” – that would break the entire system if they survived.
Why Trusted Setups Exist
Zero-knowledge proof systems based on zk-SNARKs (Succinct Non-interactive Arguments of Knowledge) require public parameters that encode a mathematical structure derived from secret randomness. These parameters – called the Common Reference String (CRS) or Structured Reference String (SRS) – enable provers to construct proofs and verifiers to check them.
The SRS is analogous to a public key for the entire proof system. But unlike a standard public key, the corresponding “private key” (the secret randomness used to generate the SRS) can forge proofs – it can create valid-looking proofs for false statements. In a cryptocurrency context, this means counterfeiting. In a voting system, this means stuffing the ballot box. In any ZK application, it means the soundness guarantee collapses.
The secret randomness must exist during generation and must not exist afterward. This is the “toxic waste” problem.
The Mathematical Structure
For a Groth16-style zk-SNARK (the most widely deployed construction), the SRS consists of elliptic curve points of the form:
[tau^0]G, [tau^1]G, [tau^2]G, ..., [tau^d]G
[tau^0]H, [tau^1]H, [tau^2]H, ..., [tau^d]H
[alpha * tau^i]G, [beta * tau^i]G, [beta * tau^i]H
where tau, alpha, and beta are secret scalars, G and H are generators of two elliptic curve groups used in pairing-based cryptography, and d is the maximum degree of the polynomials in the constraint system (determined by the circuit being proven).
The SRS encodes powers of the secret tau in the exponent of elliptic curve points. Due to the hardness of the elliptic curve discrete logarithm problem, knowing [tau^i]G does not reveal tau. But knowing tau directly would allow an attacker to compute arbitrary polynomial evaluations, which is precisely what is needed to forge proofs.
Multi-Party Computation: Distributing Trust
The solution to the toxic waste problem is secure multi-party computation: distribute the generation of tau across multiple participants such that no single participant (or any subset smaller than all participants) can reconstruct the full secret.
The Sequential MPC Protocol
The most common approach is a sequential ceremony where each participant:
- Receives the current SRS parameters from the previous participant.
- Generates a fresh secret scalar s_i.
- Multiplies each SRS element by the appropriate power of s_i: [tau^k]G becomes [(tau * s_i)^k]G… but actually it works element by element: each [tau^k]G is raised to s_i^k by scalar multiplication.
- Provides a proof (typically a Schnorr-like proof) that they correctly multiplied by a value they know.
- Destroys s_i.
- Passes the updated SRS to the next participant.
After n participants, the effective secret is tau = s_1 * s_2 * … * s_n. To reconstruct tau, an attacker must obtain all n individual secrets. If even one participant successfully destroys their secret, tau is unrecoverable.
The security guarantee is “1-of-n honest”: the ceremony is secure if at least one participant is honest. This is an extremely favorable trust assumption – it requires the adversary to compromise every participant, rather than a majority or a threshold.
Powers of Tau
The Powers of Tau ceremony, proposed by Sean Bowe and implemented for Zcash Sapling (2018), separated the ceremony into two phases:
Phase 1 (universal): Generate the powers of tau. This phase is independent of the specific circuit being proven. The result can be reused across multiple applications.
Phase 2 (circuit-specific): Combine the Phase 1 output with the specific constraint system of the application to produce the final SRS.
Zcash’s Powers of Tau Phase 1 ceremony ran continuously from November 2017 to April 2018, accepting contributions from 87 participants worldwide. The ceremony used BLS12-381, a pairing-friendly curve, and generated parameters supporting circuits of up to 2^21 (approximately 2 million) constraints.
The Hermez (now Polygon Hermez) ceremony for their zkEVM attracted over 100 participants. The Perpetual Powers of Tau ceremony, maintained by the Ethereum community, has accumulated over 80 contributions and remains open for additional participants.
Notable Ceremonies
Zcash Sprout (2016)
Six participants. Air-gapped computers. Electromagnetic shielding. Physical destruction of hardware. The ceremony was documented in detail, including video evidence of the hardware destruction. Despite the rigor, the small number of participants remained a concern – compromising all six was not theoretically implausible for a nation-state adversary.
Zcash Sapling (2018)
Eighty-seven participants in Phase 1 (Powers of Tau). Over 90 participants in Phase 2. The larger participant set dramatically increased confidence: an attacker would need to compromise all 87 Phase 1 contributors and all Phase 2 contributors to break soundness.
Aztec Connect (2022)
The Aztec Network ran a ceremony for their Ignition universal setup, attracting hundreds of participants through a web-based contribution interface. Participants contributed randomness through a browser application, reducing the technical barrier to participation. The ceremony generated parameters for the PLONK proof system.
Ethereum KZG Ceremony (2023)
The largest trusted setup ceremony in history. Over 141,000 participants contributed randomness to generate the KZG (Kate-Zaverucha-Goldberg) structured reference string used in Ethereum’s EIP-4844 (Proto-Danksharding). The ceremony ran from January to April 2023 and accepted contributions via a web interface, a CLI tool, and custom implementations.
The KZG ceremony generated parameters for commitment schemes used in Ethereum’s blob transactions. The massive participant count – over 141,000 – made the 1-of-n trust assumption extraordinarily strong. An attacker would need to compromise every single one of 141,000+ independent contributors.
The Problem with Circuit-Specific Setups
Groth16, the most efficient zk-SNARK in terms of proof size (3 group elements, ~128 bytes) and verification time (3 pairings), requires a circuit-specific setup. The SRS is bound to a specific computation: if you change the circuit (add a feature, fix a bug, modify the logic), you need a new ceremony.
This is operationally painful. Every update to a zk-SNARK application requires coordinating a new multi-party computation ceremony with sufficient participants to maintain the trust assumption. For rapidly iterating protocols, this is prohibitive.
Universal and Updatable Setups
PLONK (Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge), published by Gabizon, Williamson, and Ciobotaru in 2019, introduced a universal setup: a single ceremony generates parameters that can be used for any circuit up to a maximum size. The setup is also updatable – new participants can contribute randomness at any time, strengthening the trust assumption after the initial ceremony.
Marlin (Chiesa et al., 2020) similarly provides a universal setup, though with different performance tradeoffs.
The shift toward universal and updatable setups has significantly reduced the ceremony burden. A single ceremony with many participants generates parameters that serve an entire ecosystem of applications, and the security can be strengthened over time as more participants contribute.
Eliminating Trusted Setup Entirely
The strongest response to the trusted setup problem is to avoid it altogether. Two major approaches accomplish this:
zk-STARKs
zk-STARKs (Scalable Transparent Arguments of Knowledge), developed by Eli Ben-Sasson et al. at StarkWare, use hash functions and algebraic coding theory rather than elliptic curve pairings. They require no structured reference string – only a public random string that can be generated from a seed (such as the digits of pi or the hash of a public value). This “transparency” eliminates the trusted setup entirely.
The tradeoff: STARK proofs are larger (tens of kilobytes versus ~128 bytes for Groth16) and slower to verify (though verification remains fast in absolute terms – milliseconds for typical circuits).
Bulletproofs
Bulletproofs (Bunz et al., 2018) provide zero-knowledge range proofs and general arithmetic circuit proofs without a trusted setup. They rely on the discrete logarithm assumption rather than pairings. Monero uses Bulletproofs for range proofs in RingCT. The tradeoff is logarithmic proof size (rather than constant) and linear verification time (rather than constant).
The Tradeoff Landscape
| System | Setup | Proof Size | Verify Time | Post-Quantum |
|---|---|---|---|---|
| Groth16 | Circuit-specific | ~128 B | ~3 pairings | No |
| PLONK | Universal, updatable | ~400 B | ~1 pairing + linear | No |
| STARKs | Transparent | ~50-200 KB | O(log^2 n) | Yes |
| Bulletproofs | Transparent | ~700 B (range) | O(n) | No |
The trend is clearly toward transparent (setup-free) systems, with STARKs gaining ground as implementation efficiency improves and proof compression techniques reduce proof sizes.
Verifying a Ceremony
How does the public know that a ceremony was performed correctly?
Contribution proofs. Each participant provides a cryptographic proof (typically a discrete log proof of knowledge) demonstrating that they correctly multiplied the SRS elements by a value they know. These proofs can be verified by anyone.
Transcript publication. The entire ceremony transcript – each participant’s output and contribution proof – is published. Anyone can verify the chain of computations.
Randomness verification. Some ceremonies require participants to derive their randomness from a publicly verifiable source (such as a future block hash) to prevent pre-computation attacks.
What cannot be verified. No ceremony can prove that participants actually destroyed their secrets. This is the fundamental limitation: the 1-of-n trust assumption requires at least one participant to have genuinely destroyed their toxic waste. No cryptographic proof can verify destruction – it is a physical act, not a mathematical one. The defense is having so many participants that the probability of universal compromise is negligible.
The Stealth Cloud Perspective
Stealth Cloud’s zero-knowledge architecture does not currently deploy zk-SNARKs that require a trusted setup. The encryption and authentication primitives – AES-256-GCM, SIWE (Sign-In with Ethereum), and key management based on the Web Crypto API – operate without structured reference strings.
But the trajectory of privacy technology points toward ZK proofs for increasingly complex operations: proving that a query was sanitized without revealing the query, proving that a session was destroyed without revealing the session contents, proving that a user holds a valid credential without revealing which credential.
When Stealth Cloud integrates zero-knowledge proofs for these purposes, the choice between trusted-setup and transparent systems will be a design decision with direct implications for the trust model. A platform built on the principle that no component should be trusted – not the server, not the infrastructure operator, not the network – cannot easily accept a trust assumption that requires believing 141,000 ceremony participants all acted honestly.
Transparent proof systems – STARKs, Bulletproofs, and their successors – align more naturally with a zero-trust architecture. They replace social trust (the belief that at least one participant was honest) with mathematical trust (the belief that hash functions are collision-resistant). For a Swiss-domiciled privacy platform, the distinction is not academic. It is architectural.
The ceremony secures the system. The absence of a ceremony eliminates the need for faith.