Skill Issue Dev | Dax the Dev
search
Part of series: ZK SNARKs in production

On the death of the trusted setup

9 min read verified human-written
Last updated:
Print view
Sections

The first time I sat down to deploy a Groth16 circuit in anger, I spent more time on the ceremony — the multi-party computation that produces the per-circuit proving and verification keys — than I did on the circuit itself. We ran a Phase 2 ceremony with eleven participants, scattered across four time zones, each contributing a fresh entropy beacon to a 250 MB blob, with the contributions chained over a Phase 1 Powers-of-Tau output we trusted because Aztec’s 2019 ceremony had convinced us. None of the eleven participants was cryptographically obligated to behave; we trusted that at least one of them was honest, that none of them coordinated, and that the entropy was actually random.

Eight years on from the first big Groth16 ceremony — Zcash’s Sapling ceremony in 2018 — the dominant attitude in the ZK research community is that this whole exercise is anachronistic. Universal SRS systems (PLONK, Marlin) let you reuse a single Powers-of-Tau output across every circuit. Transparent setup systems (FRI / STARKs) need no ceremony at all. The cost difference between running a ceremony and not running one is, by 2026, much larger than the cost difference between Groth16 proofs and PLONK proofs. So why do we still ship Groth16?

This post is the long answer. It is also part defence, part eulogy, part roadmap. I am writing this as someone whose SDK still ships per-circuit Groth16 — and who, if I were starting over today, probably wouldn’t.

What a trusted setup actually is

To prove a statement in Groth16, the prover needs a proving key and the verifier needs a verification key. Both are derived from a toxic-waste secret τ\tau that, if it ever leaked, would let an attacker fabricate proofs. The job of the ceremony is to compute the proving and verification keys without anyone — including all ceremony participants combined — ever holding τ\tau in plaintext.

It works because of a property called MPC-with-1-of-n trust: as long as at least one ceremony participant securely deletes their portion of the toxic waste, the secret is destroyed for everyone. You can run the ceremony with 1,000 participants and the security argument requires only that one of them was honest.

Phase 1 is circuit-independent and produces a Powers-of-Tau structured reference string usable by any circuit up to a max constraint count. Phase 2 is circuit-specific — you have to run a fresh ceremony every time the circuit changes.

That second sentence is the entire problem.

The reason “trusted” setups are required is that for cryptographic schemes that need them, there is “toxic waste” data that is generated as part of the protocol that must be deleted; if it is not deleted, an attacker who has it can break the cryptographic scheme.

Vitalik Buterin — How do trusted setups work? (2022) ↗ source

A short history of ceremonies that mattered

Three numbers tell the story:

  • Zcash Sapling (2018): 87 participants, three months of coordination, 220 GB of intermediate transcript.
  • Tornado Cash Phase 2 (2019): 1,114 participants, web-based contributor tooling, two weeks.
  • Ethereum KZG Summoning (2022–23): 141,416 participants, running for over a year, web + CLI + browser-extension contributor tooling.

The Ethereum ceremony is the high-water mark and the one that most decisively shifts the conversation. With 141,000+ participants, a 1-of-n honesty assumption is practically indistinguishable from no honesty assumption at all. The probability that every single one of 141,000 participants colluded to leak τ\tau, and then kept that secret without it leaking out the back, is below the operational threshold of any threat model worth taking seriously.

So: the Ethereum KZG ceremony output is, in 2026, treated as a publicly trustworthy SRS for any circuit that fits inside its size budget. PLONK / Marlin / Halo2-KZG / any KZG-using protocol can reuse it. Aztec Ignition’s 2018 output played the same role for BN254 G1 prior; the Ethereum ceremony is bigger, fresher, and run with 2024-vintage tooling.

The ceremonies that didn’t work matter too. The early-Zcash Sprout ceremony was scrutinised after the fact for inadequate transcript retention and contributor non-determinism. Several smaller projects ran ceremonies with 3–5 contributors and predictable entropy beacons, and the cryptographic community treats their outputs as effectively untrusted. The line between “ceremony” and “ceremony that closes the trust gap” is mostly participant count and entropy-source diversity.

Why per-circuit ceremonies feel anachronistic

There are three setup models in 2026, and they cleanly divide:

The three setup models in 2026. The trend is unmistakably toward universal or transparent setup.
OptionCostLatencyBlast radiusNotes
Groth16 — per-circuit ceremony Phase 1 reusable; Phase 2 must be re-run for every circuit Smallest proofs (~200 bytes); fastest verification If toxic waste leaks for any one circuit, that circuit is broken What ZERA ships today; what most production ZK systems ship today
PLONK / Marlin / Halo2-KZG — universal SRS One ceremony for all circuits; reuse Ethereum KZG SRS ~600-byte proofs; KZG pairing verification If toxic waste leaks, every circuit using that SRS is affected Practical default for any circuit that fits the SRS size
FRI / STARK — no setup Truly transparent; no ceremony at any phase ~50-200 KB proofs; no pairings; verification is logarithmic Cryptographic security from collision-resistant hash; no toxic waste Plonky3, RISC0, SP1; the path with no setup at all

The argument against Groth16 in 2026 is not that the per-circuit ceremony is hard — the tooling is much better than it was in 2018. It’s that:

  1. The proof-size advantage has narrowed. Groth16 proofs are ~200 bytes, KZG-based PLONK proofs ~600 bytes. On a chain that prices verification by gas and not bytes, that’s a marginal difference.
  2. The verification-cost advantage has narrowed. Modern PLONK / Halo2 verifiers on the EVM are within a factor of 2-3 of Groth16’s gas cost, down from 5-10× in 2020.
  3. The agility cost is large. Every circuit change requires a fresh ceremony. For a fast-moving project that wants to upgrade circuits quarterly, this is a real recurring cost.
  4. The composability cost is large. Two Groth16 circuits with separate ceremonies cannot share a verifier; on a universal SRS, two PLONK circuits can.

Groth16 today is the right choice for frozen circuits in stable deployments — circuits you expect to ship once and then run for years without modification. It’s the wrong choice for active research and iteration, which describes most ZK projects in 2026.

Why Groth16 isn’t dead, even so

Two reasons, both engineering:

On-chain verifier ergonomics. Solana’s sol_alt_bn128_pairing syscall is built for Groth16; on-chain PLONK verification on Solana costs hundreds of thousands of compute units more. This is what keeps zera-sdk on Groth16 today: the marginal-cost calculation for a deposit is dominated by the on-chain verifier cost, and Solana’s verifier surface is BN254-Groth16-shaped.

The accumulated zkey ecosystem. Every Groth16 circuit ever shipped has a tested, audited zkey artifact and a corresponding Solidity / Solana / Move verifier contract. Migrating off Groth16 means either (a) re-running ceremonies for the universal SRS path or (b) waiting for the chain’s verifier surface to support transparent setup. (b) is in progress on multiple chains; (a) is mostly done on Ethereum and not yet on Solana.

The death of the trusted setup, like most deaths, is gradual. Groth16 is dying in 2026 the way SHA-1 was dying in 2014 — still everywhere, still working, increasingly the wrong choice for new builds.

The migration path I’d actually take

If I were starting a new ZK project this quarter, the decision tree would be:

  1. Do you need EVM verification? If yes, Halo2-KZG (Axiom fork) and reuse the Ethereum KZG SRS. No fresh ceremony required for circuits up to ~2282^{28} constraints.
  2. Do you need Solana verification? If yes, Groth16 + per-circuit Phase 2 ceremony, until Solana ships a transparent-setup-compatible verifier syscall. Track the SIMD threads for this.
  3. Do you need no on-chain verification at all (zkVM, off-chain proving, audit logs)? Plonky3 with BabyBear or Mersenne31. Transparent setup, fastest prover, smallest deployment surface.
  4. Are you proving recursive computation across many steps (zkVMs, rollups)? Folding scheme — Nova or ProtoStar — over Pasta or Pasta-style cycle. Transparent.

The two cells in this matrix that still pin you to Groth16 are Solana on-chain and very-low-gas EVM verification (rare in 2026 since EVM gas costs have crashed for Halo2 verifiers). For everything else, the universal-or-transparent path is strictly better.

What this means for ZERA today

We ship Groth16. The Phase 2 ceremony for the deposit, transfer, and withdraw circuits ran in late 2025 with 23 participants and is documented in the SDK repo. The output is reproducible; the contributor transcripts are public; we are comfortable with the security argument for the threat model we ship under (consumer privacy on a public L1, not state-actor adversaries).

We will migrate when one of two things happens:

  1. Solana ships a STARK-compatible verifier syscall — at which point the on-chain side stops constraining the off-chain choice, and we move to Plonky3 over BabyBear.
  2. We ship a meaningful circuit upgrade that requires a re-ceremony anyway — at which point the marginal cost of switching to a universal-SRS protocol is much smaller, and we move to PLONK over the Ethereum KZG SRS.

Until one of those happens, Groth16. The cypherpunk part of me wishes (1) had already happened. The shipping part of me knows (1) hasn’t, and that “we use the same proof system as Aztec, Tornado Cash, Iden3, and most of the early Zcash mainnet” is not the worst place to be parked in mid-2026.

What I would change about ceremony culture in 2027

Three things, in order of how much I’d actually push for them:

  1. Standardised contributor transcripts. Every ceremony rolls its own transcript format, contributor verification flow, and beacon-source documentation. A single ceremony-transcript.toml schema — adopted across snarkjs / Trusted-Setup-CLI / community tooling — would make multi-ceremony auditing dramatically easier.
  2. Public ceremony reuse registry. “What’s the freshest Phase 1 over BN254 right now?” is a question I ask quarterly and answer by reading other people’s repos. A simple registry of ceremony output → SRS constraints → audit status → known users would close that gap.
  3. Browser-native ceremony participation. The Ethereum KZG ceremony shipped a beautiful browser participant. Most other ceremonies have not, and the contributor pool reflects that. A reusable browser-ceremony-participation library would broaden the contributor demographics for any future Phase 2.

None of these are research questions. They’re community-tooling questions, and they’re the kind of work that doesn’t get done because it doesn’t publish.

Further reading

Related

Hire me — book a 30-min call $ book →