Jun 05, 2025

Trusted Setup Ceremonies: Powers of Tau, Ethereum KZG, and Zcash

A trusted setup is one of the strangest trust models in cryptography.

You generate public parameters that everybody will use later. During generation, some secret randomness exists. If that secret survives, the proof system can be broken. If at least one honest participant contributes randomness and destroys their secret, the final parameters are safe under the ceremony's assumptions.

Open the interactive trusted setup walkthrough

The Short Version

A trusted setup ceremony creates public proving or commitment parameters.

The output is public:

structured reference string
proving key / verifying key
Powers of Tau transcript
KZG trusted setup

The dangerous input is private:

secret randomness
trapdoor
toxic waste

The ceremony exists to make this sentence true:

Nobody knows the final secret.

Modern ceremonies usually use a multi-party computation model:

initial transcript
  -> participant 1 adds secret randomness and deletes it
  -> participant 2 adds secret randomness and deletes it
  -> ...
  -> final public parameters

The core security property is often called a 1-of-N trust assumption. If one participant is honest, uncompromised, and actually deletes their secret, the final trapdoor should be unrecoverable.

Why Trusted Setup Exists

Some proof systems need public parameters before anybody can generate or verify proofs.

For older efficient zk-SNARK constructions, those parameters contain hidden mathematical structure. The public parameters are safe to publish, but they are only safe if the hidden secret used to build them is gone.

Zcash's own educational material states the risk directly: if someone had the secret randomness behind the public parameters, they could create false proofs that verify. For Zcash, that would mean counterfeit coins, not deanonymizing users. See Zcash's zk-SNARK explainer and the original Zcash parameter-generation post for the cleanest version of that threat model.

Ethereum's KZG ceremony used the same broad ceremony idea for a different purpose. Ethereum did not need zk-SNARK proving keys for private payments. It needed a structured reference string for KZG commitments used by EIP-4844 blob transactions.

So the pattern is shared, but the thing being protected is different:

Zcash Sprout/Sapling
  trusted setup protects zk-SNARK soundness
  compromise can enable counterfeit shielded value

Ethereum KZG
  trusted setup protects KZG commitment soundness
  compromise can undermine blob commitment verification assumptions

The Mental Model

Imagine a public list of elliptic-curve points:

G
tau * G
tau^2 * G
tau^3 * G
...
tau^n * G

Everybody can use those points. Nobody should know tau.

The trick is that participants can update the list without learning the final tau.

Start with an initial transcript:

T0 = [G, tau0*G, tau0^2*G, ...]

Participant Alice samples secret a and transforms every element:

T1 = [G, (a*tau0)*G, (a*tau0)^2*G, ...]

Participant Bob samples secret b and transforms the transcript again:

T2 = [G, (b*a*tau0)*G, (b*a*tau0)^2*G, ...]

The final hidden value is effectively:

tau_final = tau0 * a * b * c * ...

If Alice deletes a, Bob deletes b, and at least one participant really did keep their factor secret until deletion, nobody can reconstruct tau_final.

That is the reason a ceremony can be public, auditable, and still depend on a secret that nobody knows.

A Concrete Toy SRS

Real KZG ceremonies use elliptic-curve points. For a hand-checkable example, use a tiny additive group modulo 97.

G = 5
tau = 7
group operation = scalar * G mod 97

Initial SRS:

Term	Scalar	Point data
`G`	`1`	`1 * 5 mod 97 = 5`
`tau * G`	`7`	`7 * 5 mod 97 = 35`
`tau^2 * G`	`7^2 mod 97 = 49`	`49 * 5 mod 97 = 51`
`tau^3 * G`	`7^3 mod 97 = 52`	`52 * 5 mod 97 = 66`

Now let Alice contribute secret a = 3 and Bob contribute secret b = 11.

tau_final = tau * a * b mod 97
tau_final = 7 * 3 * 11 mod 97
tau_final = 231 mod 97
tau_final = 37

Final SRS:

Term	Scalar	Point data
`G`	`1`	`1 * 5 mod 97 = 5`
`tau_final * G`	`37`	`37 * 5 mod 97 = 88`
`tau_final^2 * G`	`37^2 mod 97 = 11`	`11 * 5 mod 97 = 55`
`tau_final^3 * G`	`37^3 mod 97 = 19`	`19 * 5 mod 97 = 95`

This is not secure cryptography. It is the same shape as the real SRS idea, but with tiny numbers so the multiplication is visible.

What The Participant Actually Does

A participant's job is simple in concept and delicate in operations.

Get the current transcript.
Generate fresh entropy.
Use that entropy to derive a secret contribution.
Update the transcript with that secret.
Produce a proof that the update was valid.
Publish or return the updated transcript.
Destroy the secret material.
Keep enough evidence to prove their contribution was included.

In pseudocode:

input: old_transcript

secret = random_scalar()
new_transcript = update(old_transcript, secret)
proof = prove_valid_update(old_transcript, new_transcript, secret)

delete(secret)

output: new_transcript, proof

The actual cryptography is more careful than this pseudocode. Real ceremonies use groups, pairings, subgroup checks, contribution proofs, transcript hashes, and verifier tools. But operationally, this is the loop.

What Can Go Wrong

A ceremony can fail in several ways.

The obvious failure is secret retention. If every participant is malicious or compromised, the trapdoor can be reconstructed.

Implementation bugs are the second failure. A ceremony with many honest people still depends on software correctly generating randomness, updating the transcript, proving the update, and verifying previous contributions.

Coordination is the third failure. If the coordinator can censor, reorder, replay, or substitute transcript states without detection, participants may think they contributed to one output while users later rely on another.

Operational leakage is the fourth failure. Secrets can leak through logs, swap, crash dumps, cloud snapshots, supply-chain attacks, compilers, hardware, microphones, network devices, browser bugs, or malware.

That is why serious ceremonies are not only cryptographic protocols. They are also security productions:

independent implementations
air-gapped machines
public transcript hashes
append-only evidence
participant attestations
audits
verifier scripts
random beacons
hardware destruction
weird entropy rituals

Zcash Sprout: The Original High-Stakes Ceremony

Zcash launched shielded transactions with zk-SNARK public parameters. The secret behind those parameters was called toxic waste because possessing it could let an attacker counterfeit ZEC.

The 2016 Sprout ceremony used six participants. Electric Coin Company described the design as a combination of multi-party computation, air gaps, and evidence trails. Each participant used an air-gapped compute node. Messages moved through physical media. The ceremony created public parameters, then each participant destroyed their private shard.

The key trust model was:

six witnesses
one honest deletion is enough
all six compromised or colluding is the disaster case

This was careful, but it did not scale well. Six people is not a broad public ceremony. Zcash later moved to a more scalable process for Sapling.

Zcash Sapling: Powers of Tau Plus Circuit-Specific MPC

Sapling changed Zcash's proving system and needed new parameters.

The improvement was to split setup into two phases:

Phase 1: Powers of Tau
  circuit-agnostic
  reusable by many circuits

Phase 2: Sapling MPC
  circuit-specific
  creates final Sapling parameters

The Zcash Foundation hosted the Powers of Tau phase between November 2017 and April 2018. Electric Coin Company's completion post says that phase accepted 87 contributions.

The Zcash Company then hosted the Sapling-specific MPC. That phase accepted over 90 contributions through early August 2018.

The participant flow was much friendlier than Sprout:

receive params
run Rust ceremony program
record output hash
upload new_params
later verify final parameters include your contribution

Participants used diverse hardware, operating systems, independent implementations, and personal countermeasures. One famous contribution generated entropy from radioactive material in an airplane.

Sapling still used a trusted setup, but the trust surface was much wider and more auditable than Sprout.

Ethereum KZG: A Trusted Setup For Blob Commitments

Ethereum's KZG ceremony generated a structured reference string for KZG commitments used by EIP-4844, also known as proto-danksharding.

EIP-4844 introduced blob-carrying transactions. The transaction carries versioned hashes, while blob data and KZG commitments/proofs travel alongside the block. Ethereum clients use KZG proof verification to check claims about blob polynomial evaluations.

The ceremony model was a public Powers of Tau ceremony:

participants add secret randomness
sequencer coordinates the current transcript
contributions are verified as the ceremony progresses
final transcript becomes the trusted setup for KZG

The Ethereum Foundation's wrap-up post says the ceremony ran for 208 days, from January 13, 2023 at 13:13 UTC until August 8, 2023 at 23:08 UTC. It received 141,416 contributions. Contributors authenticated with Sign in with Ethereum or GitHub for spam prevention. The final transcript was 242 MB and had a published SHA-256 hash.

The Ethereum KZG setup was broader than Zcash's ceremonies by participant count. It also had a different operational design: public browser contribution, CLI implementations, a sequencer, special contribution windows, transcript verification scripts, and multiple audited components.

Ethereum's Dencun upgrade activated on March 13, 2024 at 13:55 UTC and included EIP-4844. That is when the KZG setup moved from ceremony artifact to live protocol infrastructure.

The Most Important Difference Between Ethereum And Zcash

Zcash used trusted setup for private-payment proof systems.

Ethereum used trusted setup for data-availability commitments.

That difference changes the consequence of compromise.

For Zcash Sprout and Sapling, toxic waste risk was tied to counterfeit shielded value. Zcash's own docs emphasize that this would affect soundness, not reveal private transaction contents.

For Ethereum KZG, the setup is tied to commitment soundness for blob data. The setup supports rollup data availability under EIP-4844. It is not a privacy ceremony and it is not a coin-supply ceremony.

The shared lesson is still the same:

The final artifact is only as credible as:
  the cryptographic protocol,
  the implementation,
  the coordinator,
  the transcript verification,
  and the belief that at least one contribution was honest.

How To Evaluate A Ceremony

When you see "trusted setup" in a protocol, ask these questions.

What Is The Output?

Is the ceremony producing:

a Powers of Tau transcript?
a universal SRS?
a circuit-specific proving key?
a verifier key?
KZG parameters?

Do not evaluate the ceremony in the abstract. Evaluate the exact artifact people will rely on.

What Is The Failure Consequence?

If the trapdoor leaks, can an attacker:

forge proofs?
counterfeit assets?
fake data availability?
break privacy?
only attack one circuit?
attack every circuit built on a shared setup?

The words "trusted setup" do not describe the consequence by themselves.

What Is The Trust Assumption?

Is it:

one coordinator must be honest
one participant must be honest
one participant per phase must be honest
one hardware module must be honest
no setup required

Sapling is a good example of phase-specific trust. A Powers of Tau contribution protects the phase 1 transcript. The circuit-specific Sapling MPC also needs at least one honest contribution.

Can Participants Verify Inclusion?

A serious ceremony should let contributors check that their contribution made it into the final transcript.

Useful artifacts include:

final transcript hash
verifier scripts
public contribution list
participant output hashes
reproducible builds
audit reports
random beacon output

If a participant cannot verify inclusion, the ceremony asks for more social trust than necessary.

How Diverse Was The Execution?

Diversity matters because correlated failure is the real enemy.

Good signs:

independent implementations
different languages
different cryptographic libraries
air-gapped contributions
browser and CLI paths
public and special contributions
independent transcript verification
varied hardware and operating systems
people with reputations attached to attestations

Ten thousand identical browser contributions are useful entropy, but they do not replace independent implementations and careful special contributions.

Trusted Setup vs Transparent Proofs

Not every proof system needs a trusted setup.

STARKs and Halo-style systems avoid the same toxic-waste ceremony model. Zcash's Orchard shielded protocol, introduced with NU5 in May 2022, uses Halo 2 and removes the trusted setup requirement for that newer shielded protocol.

That does not mean trusted setup systems are obsolete. Groth16 and KZG are efficient and widely deployed. Trusted setup is a tradeoff:

trusted setup:
  smaller proofs, fast verification, extra ceremony assumption

transparent setup:
  no toxic-waste ceremony, often different proof-size/performance tradeoffs

The right question is not "trusted setup bad?" The right question is:

What does this protocol gain from the setup,
what can go wrong if the setup fails,
and how well was the ceremony engineered?

A Practical Checklist

For a production zk or commitment system, I would want:

a clear statement of the trapdoor and failure consequence
a public ceremony specification
independent implementations where possible
transcript verification that can be run by outsiders
final artifact hashes pinned in releases
reproducible instructions for participants
inclusion proofs or output hashes for contributors
random beacon use when applicable
public audit reports
operational writeups from special contributors
a plan for upgrades if the proving system or circuit changes

And I would avoid treating participant count as the only metric. Participant count helps, but implementation diversity, operational independence, and verification quality are what turn a large ceremony into a credible ceremony.