A zk-SNARK is a zero-knowledge form of a SNARK: a succinct, noninteractive argument of knowledge. It lets a prover convince a verifier that they know a secret witness satisfying a statement without revealing that witness. The desired practical shape is costly proof generation, very fast verification, and a small proof suitable for storage or transmission. section 1.3.4 section 19.1 section 19.7
Figure 19.1 Ali Baba’s cave illustrates the concept of zero-knowledge proof. The prover knows a secret and the verifier wants them to prove they know it, but the verifier doesn’t need to know the secret themselves.
The cave scenario separates the claim from the secret: the prover demonstrates knowledge of a route-opening secret, while the verifier need not learn it. section 19.1
A traditional zero-knowledge proof is interactive: a verifier challenges a prover and receives responses. A SNARK removes that communication exchange by making the argument noninteractive. Adding zero knowledge ensures that the proof establishes knowledge of a valid solution rather than exposing the solution’s details. section 19.1 section 19.7
The statement to be proved is expressed as a quadratic arithmetic program (QAP). A QAP contains additions and multiplications, with each multiplication treated as a gate. Gate inputs and outputs are wires whose values are taken modulo the torsion-field size. Public statement wires are distinguished from private witness wires, so a verifier can check the public claim while the witness remains private. section 19.0 section 19.5 section 19.7
A proof workflow separates fixed setup data from record-specific witness data:
- Construct the fixed QAP describing the allowed computation and its gate equations. section 19.5 section 19.7
- Generate a common reference string (CRS) from pairing-friendly-curve points and random values. section 19.5 section 19.7
- Combine QAP data, CRS data, and witness values to create a compact proof represented by three points. section 19.5
- Use the CRS and proof record to evaluate the verification equation and accept or reject the statement. section 19.5 section 1.3.4
The QAP encodes each gate at a distinct point and uses left, right, and output Lagrange-interpolant functions. These functions select a gate by being 1 at its point and 0 at the others. The fundamental relation checks that multiplied left and right inputs agree with the output construction; a mismatch rejects the record. Cross terms are collected in h(x), while t(x) is the product over gate points. Expanding the Lagrange functions into polynomial coefficients reduces the CRS size. section 19.7
The CRS depends on random setup values that must be destroyed. These values are called toxic waste: if an adversary learns them, they can create proofs with arbitrary inputs. This makes setup secrecy an operational security requirement, not merely an implementation detail. section 19.7
Five-program proof pipeline
A small C implementation divides the work into shared routines in snarkbase.c plus four ordered programs: snark_qap.c produces QAP data, snark_crs.c produces CRS data, snark_proof.c creates proof points, and snark_verify.c checks the result. Larger applications retain this division but may use thousands of witness values for each public value, leaving proof creation slow and verification fast. section 19.5
Figure 19.5 SNARK example code subroutine relationships
The subroutine diagram makes the file dependencies explicit: shared routines support QAP setup, CRS generation, proof creation, and final verification. section 19.5
zk-SNARKs fit settings where a party must establish authorization or correctness without disclosing sensitive information, such as financial amounts or medical conditions. Their value comes from combining privacy with a compact, quickly checked noninteractive proof. section 1.3.4 section 19.7
