zk-SNARKs Explained: How the Proofs Work, What the Setup Risks, and What They Cost

Updated November 10, 2026.

March 31, 2026. Google's Quantum AI team publishes new estimates for how few qubits it would take to break the elliptic-curve cryptography under Bitcoin and Ethereum. They don't publish the circuit. Too dangerous. Instead they publish a zero-knowledge proof that the circuit exists and hits the numbers, built with Succinct's SP1 zkVM and a Groth16 zk-SNARK.

Seventeen days later, Trail of Bits publishes a "better" proof. Fewer qubits. Fewer operations. Zero of the expensive gates. Same verification key. It passes Google's verifier.

They didn't break the cryptography. They found two bugs in the program being proven: an unchecked input that skipped the gate counter, and a missing check that let a quantum operation do something physics doesn't allow. Google patched it, and its science stands.

The math held. The statement was wrong.

That's the most useful thing you can know about zk-SNARKs before you rely on one. A SNARK proves exactly what it was told to prove, very efficiently, and nothing else. Here's how they work, where the trust actually sits, and what it costs.

If you want the basics of zero-knowledge proofs first, start with the pillar explainer. This post goes one level down.

What the name actually says

zk-SNARK stands for Zero-Knowledge Succinct Non-interactive ARgument of Knowledge. The acronym is ugly, but every word is doing work.

• Zero-knowledge. The verifier learns that the statement is true. Nothing else. Not the balance, not the identity, not the inputs.
• Succinct. The proof is tiny and fast to check, no matter how big the computation behind it. A Groth16 proof in Zcash's Sapling protocol is 192 bytes, whether the circuit has eight thousand constraints or a hundred thousand.
• Non-interactive. The prover sends one message. No back-and-forth. That's what lets a proof sit in a block and be checked by anyone, later, without the prover around.
• Argument. In cryptography, a "proof" is sound even against an attacker with unlimited computing power. An "argument" is sound against attackers who can't break a specific math problem. Hold onto that word. It's where quantum computing comes in.
• of Knowledge. The prover doesn't just show a valid answer exists. They show they actually hold it.

The term goes back to Bitansky, Canetti, Chiesa, and Tromer in 2012. The construction most people mean today is Groth16, from Jens Groth in 2016: three elliptic-curve points and a handful of pairing checks.

How a SNARK works, in four steps

You don't need the polynomial math to understand where the risk is. You need the shape of the pipeline.

1. Write the statement as a circuit

A computer can't prove "this customer has enough funds." It can prove that a set of arithmetic equations holds. So step one is translating the rule into a circuit: a long list of additions and multiplications over a finite field, with constraints that must all be true at once. This translation is called arithmetization. Groth16 uses a format called R1CS (rank-1 constraint system). PLONK-family systems use their own variant.

Take a simple payment rule: "I own a coin in this pool, I haven't spent it, and the amounts balance." As a circuit, that becomes:

• The coin's commitment (a hash that hides its value and owner) sits in the pool's Merkle tree.
• I know the secret key that opens it.
• A nullifier, a unique tag derived from that secret, is published so the network can block a second spend without learning which coin it was.
• Inputs equal outputs plus fee, and no amount is negative.

The private values (keys, amounts, the path through the tree) are the witness. The public values (the tree's root, the nullifier) are the public inputs. Developers write these circuits in languages like Circom or Noir, or skip hand-written circuits by using a zkVM such as SP1 or RISC Zero, which proves the execution of an ordinary program.

2. Run the setup

The setup turns the circuit into two keys. The proving key is large and goes to whoever generates proofs. The verification key is small and goes to whoever checks them, often a smart contract.

Generating those keys takes secret random numbers. More on that in a minute, because it's the part that keeps cryptographers up at night.

3. Prove

The prover plugs the witness into the circuit, uses the proving key, and produces the proof. This is the expensive part. Proving takes far more compute than just running the computation, often seconds to minutes and frequently on GPUs for large circuits.

4. Verify

The verifier takes the proof, the public inputs, and the verification key and runs a fixed check. For Groth16, that's a few pairing operations: milliseconds on a laptop, and on Ethereum roughly a quarter-million gas per proof. The check takes about the same time whether the underlying computation was tiny or enormous. That asymmetry is the whole point.

The audit analogy

If you've read a SOC 2 Type II report, you already understand the trust model. The auditor opines that the controls operated effectively as described. The opinion is worth exactly as much as the description. If management described the wrong controls, you get a clean opinion on the wrong thing.

A SNARK is the same. The verifier checks the proof against the circuit. It doesn't check whether the circuit captures the business rule you care about. That's what happened to Google. The circuit is the control description, and it's where you put your review budget.

The trusted setup problem

Back to those secret random numbers. In Groth16, the setup uses secret values, nicknamed toxic waste, to build the keys. Then the secrets are supposed to be destroyed.

If someone keeps them, they can forge proofs that pass verification for false statements. In a private payment system, that means minting coins out of nothing. And because the pool is shielded, nobody can see the counterfeit.

What toxic waste does not do is reveal private data. Groth16 proofs are zero-knowledge regardless of who ran the setup. The risk is integrity, not confidentiality. For a ledger, integrity is the bigger deal.

Ceremonies: one honest person is enough

The fix is a multi-party computation, or ceremony. Each participant adds their own randomness and destroys it. The final keys are safe as long as at least one participant was honest. You don't need to trust everyone. You need to trust that not everyone colluded.

The history shows how this has matured:

• October 21–23, 2016. Zcash's first ceremony uses six participants, each on their own hardware in their own location.
• November 2017 to April 2018. The Zcash Foundation runs Powers of Tau, a general-purpose first phase that accepts 87 contributions, followed by a Sapling-specific phase that drew more than 90 contributions.
• January 13 to August 8, 2023. Ethereum's KZG ceremony collects 141,416 contributions over 208 days. Strictly speaking, this one supports the KZG commitments behind EIP-4844 data blobs rather than a SNARK, but it's the same one-honest-participant model at a scale no one had tried.

When the setup itself is wrong

The scariest story in this space isn't a stolen secret. It's a design flaw.

On March 1, 2018, Zcash cryptographer Ariel Gabizon found that the parameters generated for the original BCTV14 proving system contained extra elements that were included by mistake and that would let a cheating prover get around a consistency check. In plain terms: infinite counterfeiting. The team fixed it quietly with the Sapling upgrade on October 28, 2018, and disclosed it on February 5, 2019. The flaw didn't affect privacy, and the company found no evidence of exploitation by monitoring the totals in the shielded pool.

Nobody did anything wrong in the ceremony. The math paper had a bug. That's a different risk category, and it's one your vendor's ceremony transcript can't rule out.

Universal and setup-free alternatives

Two developments changed the setup picture.

Universal setups. PLONK (Gabizon, Williamson, and Ciobotaru, 2019) uses one universal and updatable setup for any circuit up to a size limit. You run one big ceremony, possibly add your own contribution, and reuse it. Change your circuit and you don't need a new ceremony. Groth16 needs one per circuit.

No setup at all. Halo (Bowe, Grigg, and Hopwood, 2019) showed how to get recursive proofs without a trusted setup, using an inner-product argument instead of pairings. Its successor, Halo 2, went live when Zcash's NU5 upgrade activated on May 31, 2022, and Zcash's new Orchard pool has needed no trusted setup since.

The price is size. The Ethereum institutional-privacy knowledge base at ethsystems.org puts Groth16 proofs at about 200 bytes, PLONK over KZG at about 400 bytes, and PLONK over an inner-product argument at about 1 KB. Still small. Just not the smallest.

Zcash has now run three proof systems in under six years: BCTV14, then Groth16, then Halo 2. Plan for that kind of migration if you build on this.

Where SNARKs show up in the real world

Private payments. Zcash is the original. Shielded transactions hide sender, receiver, and amount, and viewing keys let a holder disclose transaction details to an auditor or regulator without making them public. The full story is in the Zcash post.

Tornado Cash used zk-SNARKs to break the on-chain link between deposits and withdrawals. OFAC sanctioned it in August 2022 and delisted it on March 21, 2025 after the Fifth Circuit ruled in Van Loon v. Treasury. That history tells you the compliance question around privacy tools is about how they're used and governed, not about the math.

One correction to a common claim: Monero doesn't use zk-SNARKs. It uses ring signatures, stealth addresses, and Bulletproofs range proofs. More on Bulletproofs in the STARKs and Bulletproofs post.

Validity rollups. This is where most SNARK verification on Ethereum happens today. A rollup runs thousands of transactions off-chain and posts one succinct proof that they were all processed correctly.

Most "zk-rollups" use the succinct part and skip the zero-knowledge part. Transaction data is public. They're scaling tools, not privacy tools. If a vendor says "we're on a zk-rollup, so it's private," ask them to show you.

Proving off-chain computation. zkVMs let you prove that an ordinary program ran correctly. Many of them generate a STARK-style proof internally and then wrap it in a Groth16 SNARK, shrinking hundreds of kilobytes down to a few hundred bytes so it's cheap to check on Ethereum. Google's quantum proof is this pattern.

Compliance and identity. Proving a customer is over 18, in an allowed jurisdiction, or not on a sanctions list without handing over the underlying record. This is where regulated firms get interested. See ZK in finance and ZK beyond payments for the use cases.

What it really costs

You'll find precise-looking figures online for proving times, implementation budgets, and compliance savings. Most don't trace back to a source. Here's what I can stand behind.

• Proving compute. Heavy, and it grows with circuit size. Large circuits want GPUs or a proving service. Verification is cheap.
• Specialized talent. Circuit engineers and ZK auditors are scarce. Under-constrained circuits, where a check you meant to include isn't actually enforced, are a well-known bug class in ZK audits. Google's bug was a cousin of it.
• Setup governance. For Groth16, every circuit change means a new ceremony. For universal setups, you inherit someone else's ceremony and should read its transcript.
• Quantum exposure. Groth16 and PLONK over KZG rely on elliptic-curve pairings. A large enough quantum computer running Shor's algorithm breaks those, and the main risk is that someone forges proofs. The zero-knowledge property of an existing Groth16 proof doesn't depend on that hardness, so old proofs don't suddenly leak. The encryption around them in a payment system is often elliptic-curve too, and that's a separate exposure.

What a regulated firm should check

If you're a bank, an asset manager, or an audit firm, you're accountable for the outcome whether or not you understand the cryptography. These are the questions I'd ask.

1. What exactly does the circuit prove? Get the statement in plain English and compare it with the business rule. Ask who audited the circuit, not just the proof system.
2. What's the setup model? Circuit-specific, universal, or none. If there's a ceremony, how many participants, is the transcript public, and could you contribute?
3. What's the upgrade path? Proof systems change. Ask how proofs and keys get rotated when a flaw shows up, and who decides.
4. Who can see what? Zero-knowledge doesn't remove your recordkeeping duties. You still need to produce records for examiners. Check whether the design supports selective disclosure, such as viewing keys, and who holds them.
5. How long does the proof need to hold? A proof checked once at settlement is a different risk from a proof that underwrites a ledger for twenty years. For the long horizon, read the post-quantum comparison.
6. Is "zk" doing privacy work or just scaling work? Ask what's actually hidden from whom.

SNARKs are real, deployed, and useful. A 192-byte proof that a hundred-thousand-constraint computation ran correctly is a remarkable thing.

But don't ask whether the proof verifies. It will. Ask what it's a proof of.