Imagine outsourcing an intensive computation and receiving a result you cannot inspect. A zk-SNARK lets a prover show that the result came from a valid execution while hiding selected inputs or outputs. The proof is non-interactive, short—often hundreds of bytes—and quick to verify, often within milliseconds. section 15.3
A general-purpose zk-SNARK typically combines these pieces:
- Translate a program into arithmetic constraints or polynomials. The proof system does not directly prove that ordinary program code ran; it proves that the resulting equations hold. section 15.3.1 section 15.3.6
- Represent the computation as a polynomial relation. At an intuitive level, the prover demonstrates knowledge of polynomials f(x) and h(x) such that f(x) = t(x)h(x), without revealing the secret polynomial. section 15.3.1
- Hide evaluations with homomorphic commitments and bilinear pairings, allowing the verifier to check relationships without receiving the underlying values. section 15.3.1
- Check the relation at a random point rather than comparing entire polynomials. The Schwartz-Zippel lemma makes unequal polynomials disagree at most points, producing a small proof. section 15.3.4
From a branching function to a proof
For a function that returns a × (b + 3) when w is true and a + b otherwise, the computation can be expressed as w × (a × (b + 3)) + (1 − w) × (a + b) = v. A zk-SNARK can prove that secret a and public values b and w produce v correctly, while omitting selected inputs or intermediate values. section 15.3.6 section 15.3.9
Setup is a major safety consideration. Many constructions use a common reference string containing commitments to powers of a hidden random value. If the setup secret is retained, it can enable forged proofs; multiparty computation can reduce the risk when at least one participant is honest and destroys its contribution. Transparent or non-SNARK schemes may be preferable when different properties matter more than proof size. section 15.3 section 15.3.4
