Every zero-knowledge proof (ZKP) needs a set of public parameters — the "design" that both the prover and verifier rely on. But who creates that design? And crucially: does anyone hold a secret from the moment it's made?
This is the heart of the transparent setup vs trusted setup debate, and it decides how much trust a blockchain actually demands. Some proofs are born from a trusted setup — a ceremony where secret randomness ("toxic waste") must be destroyed. Others come from a transparent setup — public randomness that anyone can verify, with no secrets at all.
Let's walk into a Vietnamese workshop to see both philosophies side by side.
The Workshop: Who Holds the Master Key?
Imagine a craftsman who builds tamper-proof padlocks. Every lock in the village uses his design. Two ways he can publish that design:
- The trusted way: The craftsman secretly builds a master key while casting the locks. He swears he destroyed the copy. Everyone must trust him — if a copy survives, whoever holds it can open any lock without the owner's knowledge.
- The transparent way: He carves the entire lock blueprint into the village square for all to read. No master key ever exists. Anyone can inspect the blueprint, verify it's sound, and even rebuild the locks themselves.
Both produce working locks. But they answer "who holds the design secret?" very differently. In the trusted way, someone did hold a secret during setup — and we must believe it's gone. In the transparent way, nobody ever held one.
That single difference cascades into proof size, verification speed, and long-term security.
What Is a Trusted Setup?
A trusted setup is a procedure that generates the public parameters (the Common Reference String or Structured Reference String, CRS/SRS) a zk-SNARK needs before any proof can be made.
During the setup, participants sample secret random values — the famous toxic waste. These secrets are used to compute the public parameters, then they must be destroyed. If anyone retains them, they can forge valid proofs for statements that aren't true, and no verifier would ever catch it.
The Two Flavors of Trusted Setup
| Flavor | How it works | Example systems |
|---|---|---|
| Per-circuit | A new ceremony for every circuit. Change the program, run setup again. | Groth16 |
| Universal | One ceremony reused for all circuits up to a size bound. | PLONK, KZG |
Groth16 is the classic example. It produces the smallest proofs (~200 bytes) and the fastest verification (just 3 pairing equations), which is why it dominates on-chain. But every new circuit needs its own ceremony.
PLONK improves on this with a universal (or "updatable") setup — one ceremony serves many circuits. It's more flexible, but still trusted.
The Ceremony and the Toxic Waste
To make a trusted setup safer, projects run it as a multi-party computation (MPC) ceremony — the famous Powers of Tau. Hundreds (sometimes over 140,000, as in Ethereum's 2023 KZG ceremony) of participants each add secret randomness and destroy their share.
The security model is reassuring: the ceremony is secure as long as at least one participant is honest and destroys their share. The "toxic waste" — the secret τ, α, β, γ, δ — vanishes forever if any single person does the right thing.
But this is a social trust assumption, not a mathematical one. You're trusting the ceremony, not the math.
Figure 1: Who holds the design secret — trusted ceremony vs transparent setup
What Is a Transparent Setup?
A transparent setup produces public parameters from public, verifiable randomness — or, in some schemes, needs no setup at all. There is no secret to destroy, no ceremony to run, no "toxic waste" to worry about.
Because the parameters come from public constants, anyone can recompute and verify them. There is never a moment where a secret exists that could be leaked or stolen.
Transparent Systems You'll Meet
| System | Setup | Proof size | Note |
|---|---|---|---|
| zk-STARK | Transparent | ~100 KB | Hash-based, post-quantum resistant |
| Bulletproofs | Transparent | ~1.5 KB | Linear-time verifier |
| Halo2 | Transparent (IPA) | ~2-4 KB | Native recursion |
Halo2 deserves special attention. It's built on PLONK's arithmetization (PLONKish) but replaces the trusted setup with an Inner Product Argument (IPA) plus an accumulation scheme. The result: no trusted setup, and native recursive proof composition. Zcash's Orchard, Scroll, and Taiko all use it. This is why "plonk halo2" often appear together in the same sentence — Halo2 is the transparent cousin of PLONK.
zk-STARKs go even further. Their security rests on hash functions alone, making them post-quantum resistant — the only family in this comparison that survives a large quantum computer.
The Core Trade-off: Trust vs. Efficiency
The transparent vs trusted choice isn't free. Here's the real cost:
| Property | Groth16 | PLONK | Halo2 | zk-STARK |
|---|---|---|---|---|
| Setup | Trusted, per-circuit | Trusted, universal | Transparent | Transparent |
| Proof size | ~200 B | ~400 B | ~2-4 KB | ~100 KB |
| Verifier | Very fast (3 pairings) | Fast | Moderate | Moderate |
| Post-quantum | No | No | No | Yes |
| Recursion | Limited | Limited | Native | Native |
The pattern is unmistakable: removing the trusted setup makes proofs larger and verification slower. Groth16's tiny ~200-byte proof is only possible because it leans on a per-circuit ceremony. Transparent systems pay for their trustlessness with bigger proofs.
Why? Trusted-setup schemes like KZG commit to a whole polynomial with one group element — extremely compact. Transparent schemes like FRI (STARK) commit to many evaluations via a Merkle tree, which is bigger but needs no secret.
Figure 2: Trusted ceremony vs transparent derivation
The Real Danger: A Systemic Single Point of Failure
Why does the industry care so much about removing the trusted setup? Because a compromised ceremony is a single point of failure for an entire system.
If all ceremony participants collude — or are all compromised — the toxic waste is effectively recovered, and arbitrary fake proofs can be minted. Every proof made under those parameters is suspect. For a zk-rollup securing billions in value, that's an unacceptable systemic risk.
A transparent setup has no such failure mode. Since no secret ever exists, there is nothing to collude over or steal. The trust assumption is zero by construction.
The "Design Secret" in a Transparent World
In the trusted world, "who holds the design secret?" is answered with a trust ceremony. In the transparent world, the answer is simpler and stronger: nobody — because the design is public and reproducible.
This is a philosophical shift as much as a technical one. Transparent setup aligns perfectly with the blockchain ethos of "don't trust, verify." The design itself is open, verifiable, and owned by no one.
When to Choose Which?
There's no universal winner — it depends on your priorities.
Choose a Trusted Setup (Groth16 / PLONK) When:
- Proof size is critical — On-chain verification where calldata costs money (Groth16's ~200 bytes).
- Verification speed matters most — High-throughput settlement layers need millisecond verification.
- Mature tooling is needed — Circom, snarkjs, Arkworks have years of auditing.
- The circuit is stable — If you rarely change circuits, per-circuit setup is fine.
- You can run a trusted ceremony — And you accept the social trust model.
Real-world: Zcash (Sapling), Tornado Cash, zkSync Lite, Aztec, Polygon zkEVM.
Choose a Transparent Setup (Halo2 / STARK) When:
- Trust minimization is paramount — No ceremony, no toxic waste, ever.
- Quantum resistance is required — Long-lived secrets and archives (STARK only).
- Native recursion is needed — Proving proofs of proofs (Halo2, STARK).
- You want to avoid ceremony logistics — No coordinating hundreds of participants.
- The circuit evolves — No re-running setup when it changes (Halo2).
Real-world: Zcash Orchard, Scroll, Taiko, Starknet, PSE zkEVM.
Figure 3: Transparent vs trusted setup trade-off table
The Hybrid Reality
Here's what few explain: most production "transparent" rollups still settle with a trusted-setup SNARK on-chain.
Starknet: STARK proof → compressed → Groth16 SNARK verified on Ethereum
Scroll: Halo2 (transparent) proof → verified via pairing precompilesWhy? Ethereum's precompiles are built for pairing-based SNARK verification (BLS12-381), not FRI. Verifying a raw STARK on-chain costs ~5M gas; a Groth16 proof costs ~200k gas — a 25x difference.
So the industry pattern is:
- Prove with a transparent system (Halo2, STARK) for trustlessness and scalability.
- Settle with a trusted-setup SNARK for tiny, cheap on-chain proofs.
This pragmatic hybrid gets most of the transparency benefits while keeping gas costs low. The "plonk halo2" pairing is a perfect example — PLONK's universal setup and Halo2's transparent recursion are often composed in the same rollup.
Figure 4: Hybrid pipeline — transparent proving, SNARK settlement
FAQ: Your Questions Answered
Q: Is a trusted setup dangerous?
A: Not if the ceremony is run properly. With MPC and many participants, a trusted setup is secure as long as one honest participant destroys their share. The risk is systemic — if everyone colludes, fake proofs are possible. Transparent setups eliminate this risk entirely.Q: Why are transparent proofs so much larger?
A: Trusted-setup schemes (KZG) commit to a polynomial with one compact group element. Transparent schemes (FRI, IPA) commit to many evaluations via Merkle trees or inner-product arguments, which are larger but need no secret.Q: Is Halo2 transparent or trusted?
A: Transparent. Halo2 uses an Inner Product Argument instead of a trusted setup, and adds native recursion. It's the transparent evolution of PLONK — which is why the two are often compared together.Q: Which is more quantum-resistant?
A: zk-STARKs. Their security reduces to hash collision resistance. Groth16, PLONK, and Halo2 all rely on elliptic-curve pairings or discrete log, which Shor's algorithm breaks on a large quantum computer.Q: Do I need a trusted setup for my own project?
A: Only if you pick a pairing-based scheme like Groth16 or PLONK. If you choose Halo2 or STARK, you get a transparent setup for free — no ceremony, no coordination, no toxic waste.Q: Which is "better" — transparent or trusted?
A: It depends. Trusted setups win on proof size and verification speed (great for on-chain gas). Transparent setups win on trust minimization, quantum resistance, and recursion. Many production systems combine both.Summary: Two Philosophies, One Goal
| Approach | Design secret | Best for | Price |
|---|---|---|---|
| Trusted setup (Groth16/PLONK) | Held during ceremony, must be destroyed | Tiny proofs, fast on-chain verify | Social trust assumption |
| Transparent setup (Halo2/STARK) | Never exists — public & reproducible | Trust minimization, recursion, quantum | Larger proofs, slower verify |
The question "who holds the design secret?" separates two generations of zero-knowledge proofs. Trusted setups made ZKP practical with compact, instant proofs — at the cost of a ceremony you must trust. Transparent setups traded that size for the strongest guarantee blockchain offers: no one ever held the secret, because the design belongs to everyone.
Understanding transparent setup vs trusted setup isn't about declaring a winner. It's about knowing what trust you're accepting — and choosing the system whose design secret (or lack of one) matches your needs.
Word count: ~1,850 | Primary keyword: "transparent setup" | Secondary: "trusted setup khác biệt", "plonk halo2"