The Auditor Who Never Sees the Books
You hand a smart contract 128 bytes. It runs for three milliseconds. It tells you the computation was honest, the balance is sufficient, the transaction is valid. It tells you nothing else. The contract has no idea what the actual balance is, and neither does anyone watching the chain.
That is roughly what a zk-SNARK does. SNARK stands for Succinct Non-interactive ARgument of Knowledge. The word that matters most is succinct. The proof is tiny regardless of how large the computation being proved actually is. And the central puzzle worth understanding is this: how does shrinking the proof not create a loophole a cheater can exploit?
The short answer is polynomial commitment schemes and a hardness assumption called the Knowledge of Exponent. That sentence is useless without the mechanism behind it. Let's open the hood.
Why Size and Security Seem to Be in Tension
In a naive proof system, soundness comes from completeness. If you want someone to believe you ran 10,000 computation steps correctly, you show them all 10,000 steps. A cheater who faked step 4,721 gets caught because the verifier checks everything.
Compress the proof and you're asking the verifier to check less. Which sounds like an invitation to cheat. This is the core tension, and it's the part most explainers gloss over.
The resolution is to transform the computation into a polynomial, then commit to that polynomial in a way that is both hiding and binding. You can't fake the commitment without solving a problem that no known computer, quantum or classical, can solve efficiently.
Here's the mechanism in concrete steps.
Step 1: Arithmetic circuits. Any computation (a transaction, a range check, a hash function) gets compiled into an arithmetic circuit: a directed graph of addition and multiplication gates over a finite field. Zcash's Sapling circuit contains roughly 4 million constraints. That circuit represents everything the prover needs to demonstrate.
Step 2: R1CS to QAP. The circuit is converted into a Rank-1 Constraint System, then into a Quadratic Arithmetic Program. This translation is the work of Gennaro, Gentry, Parno, and Raykova (2013), the paper that made practical SNARKs conceivable. A QAP encodes all constraints as a single polynomial identity: if the prover's witness (their secret inputs) satisfies the computation, a particular polynomial evaluates to zero at all the right points.
Step 3: The polynomial commitment. The prover doesn't send the polynomial itself (that could be enormous). Instead, they commit to it using an elliptic curve operation from the trusted setup. The commitment is a single group element, typically 32 to 48 bytes. The verifier can check that the committed polynomial satisfies the QAP identity without ever seeing the polynomial's coefficients.
The binding property comes from the discrete logarithm problem. Given a commitment C = g^f(s) for some secret point s baked into the setup, finding a different polynomial f' that produces the same C would require computing a discrete log in an elliptic curve group. That's believed to be hard for any efficient adversary.
Step 4: The random challenge (Fiat-Shamir or CRS). Rather than an interactive back-and-forth, the verifier's challenge is either generated via the common reference string from the trusted setup, or derived with the Fiat-Shamir heuristic using a hash function. This collapses the interaction to zero rounds. The prover sends one message; the verifier checks it. Done.
The final proof in Groth16 (the scheme underlying Zcash and many others) is just three elliptic curve group elements. On a 256-bit curve, that's around 128 bytes, whether the underlying circuit has 100 constraints or 4 million.
The Trusted Setup: The Skeleton in the Closet
Here's the wrinkle that soundness discussions usually sidestep.
The security of most deployed zk-SNARKs (Groth16, PLONK, Marlin) depends on a trusted setup ceremony producing a common reference string. If the randomness used during that ceremony, the so-called toxic waste, is ever revealed, a malicious prover can forge proofs for false statements. They could, in principle, mint currency from nothing in a Zcash-style system without anyone detecting it.
Zcash ran two such ceremonies (Powers of Tau, then a Sapling-specific round) with dozens of independent participants. The assumption is that at least one participant destroyed their randomness. One honest participant is enough; all of them would have to collude to compromise the setup.
This is a real, non-trivial trust assumption, and pretending otherwise is just marketing. Universal setups like PLONK's reduce the problem (one ceremony covers many circuits), and transparent setups like STARKs eliminate it entirely by using public randomness. The catch: STARKs produce proofs measured in kilobytes, not bytes. The succinctness-versus-trust tradeoff is real. Anyone who tells you it isn't is selling something.
A Worked Scenario: Two Wallets, One Verification
Say Alice wants to prove to a DeFi protocol that her balance is above 1,000 units without revealing the actual balance. Her balance is 14,200 units.
The prover software encodes the range check (balance >= 1,000) as an arithmetic circuit of roughly a few hundred constraints. It computes a witness: the binary decomposition of 14,200, plus some auxiliary values. It generates a Groth16 proof. Output: three elliptic curve points, 128 bytes, produced in roughly 0.5 to 2 seconds on a modern laptop.
The smart contract runs the verifier: two pairing operations on those three points, plus a handful of field multiplications. About 2 to 3 milliseconds, costing roughly 200,000 to 300,000 gas on Ethereum. The contract learns exactly one bit of information. The range check passed.
Now consider Bob, who only has 400 units. He tries to fake the proof by constructing a false witness. To produce a commitment that satisfies the QAP identity with a lying witness, he'd need to find a polynomial that evaluates correctly at the secret point s from the setup. That requires solving the discrete log problem. He can't. The proof fails verification.
The succinctness (128 bytes) didn't create a loophole. The polynomial commitment sealed it.
What People Get Wrong About "Succinctness"
The common misconception is that succinctness is purely about proof size. It isn't.
In formal definitions, a SNARK is succinct if both the proof size and the verification time are sublinear in the size of the computation being proved. Verification that scales with circuit size isn't really succinct; it's just compressed. Groth16 verification is constant time regardless of circuit size, and that's the property that makes zk-SNARKs genuinely useful for on-chain verification, where every byte and every computation cycle costs money.
Also worth correcting: the zero-knowledge part is optional. A SNARK without zero-knowledge is just a succinct proof of computation. Many applications (rollups proving correct state transitions, for instance) don't require hiding the inputs at all. They use the succinctness without the privacy. The two properties are separable, which is a distinction that gets blurred constantly in popular coverage, and the blurring does real damage to how people reason about what these systems actually guarantee.
The Compression That Doesn't Leak
The proof isn't a compressed transcript of the computation, like a ZIP file you could unpack to recover the steps. It's a cryptographic commitment to a polynomial that encodes the computation, the way a fingerprint encodes a person without resembling them. The verifier never checks the steps; they check an algebraic identity that can only be satisfied if all the steps were correct.
That's the move. Not compression, but a transformation into a mathematical object where correctness and succinctness happen to coincide.
Whether the trusted setup assumptions hold in practice over decades, against adversaries we haven't imagined yet, is genuinely open. The math is tight. The engineering is tested. The assumption is specific and falsifiable. That's about as good as cryptography gets, which is to say: good enough to build on, not good enough to stop thinking about.