Lecture 2: Overview of Modern SNARK Constructions

What this lecture covers

This lecture moves from the interactive zero knowledge proofs of the previous lecture to non-interactive proofs, focusing on SNARKs: succinct non-interactive arguments of knowledge. Dan Boneh explains what makes a proof "succinct" (short and fast to verify, no matter how large the underlying computation), surveys real applications in blockchain scaling, privacy, and even fighting photo misinformation, and then gives a precise definition of NARKs and SNARKs.

By the end, you should understand the formal syntax of a SNARK (setup, prove, verify), what knowledge soundness means, and the general two-part recipe used to build modern SNARKs: pairing a functional commitment scheme (such as a polynomial commitment) with an interactive oracle proof, then compiling the result into something non-interactive with the Fiat-Shamir transform.

Key ideas

• SNARK: a succinct non-interactive argument that a prover knows a witness W such that a circuit C(X, W) = 0, with proof size and verification time far smaller than the underlying computation.
• Arithmetic circuit: a computation expressed as additions and multiplications over a finite field; the circuit's "size" is its number of gates.
• Trivial NARK is not succinct: sending the witness itself, or requiring the verifier to recompute the whole circuit, both fail the succinctness requirement.
• Knowledge soundness: if a verifier accepts a proof, there must exist an extractor that can pull a valid witness out of the prover with roughly the same probability the prover convinces the verifier.
• Trusted, universal, and transparent setup: three tiers of pre-processing, ranging from a setup that must be re-run per circuit and kept secret, to one reusable across circuits, to one requiring no secret randomness at all.
• Functional commitment scheme: a way to commit to a function (such as a polynomial or vector) and later prove evaluations of it without revealing the function itself.
• Interactive oracle proof (IOP): an information-theoretic proof protocol where the prover sends oracles to functions instead of the functions themselves; combined with a commitment scheme, it becomes a SNARK.
• Fiat-Shamir transform: turns a public-coin interactive protocol into a non-interactive one by replacing the verifier's random challenges with a hash of the transcript so far.
• Schwartz-Zippel lemma: two distinct low-degree polynomials agree at a randomly chosen point with only negligible probability, which is the core trick that makes efficient equality tests (and much of SNARK construction) possible.

Walkthrough

What a SNARK is and why it matters (0:00)

Boneh introduces SNARKs through the example of proving knowledge of a message that hashes to a target value, contrasting the trivial (large, slow) proof with a SNARK's short, fast-to-verify proof. He explains ZK-SNARKs add the requirement that the proof reveals nothing about the witness, and traces the commercial interest in SNARKs back to a 1991 paper about a slow computer verifying an unreliable supercomputer — today's analogue being a blockchain verifying off-chain computation.

Blockchain and non-blockchain applications (4:02)

The lecture covers ZK rollups (batching transactions so a chain verifies one short proof instead of many), blockchain bridges, private transactions with compliance proofs, and proof of solvency for exchanges. It then details a non-blockchain application: using SNARKs to prove that a cropped, resized, or grayscaled news photo was derived correctly from a signed original, without needing the original image data (the C2PA standard problem).

Defining arithmetic circuits and NARKs (17:10)

Arithmetic circuits over a finite field are defined formally, with examples including a circuit for SHA-256 and one for signature verification. The lecture then defines a NARK (non-interactive argument of knowledge) as a triple of algorithms (setup, prove, verify) satisfying completeness and knowledge soundness, and notes the trivial NARK where the proof is just the witness.

From NARK to SNARK (25:11)

A SNARK adds succinctness requirements: proof size sub-linear (ideally logarithmic or constant) in the witness size, and verification time sub-linear in the circuit size. This is why pre-processing is needed — the verifier's parameters act as a compressed summary of the circuit. The lecture compares trusted-per-circuit, universal, and transparent setup models, and surveys real systems (Groth16, Plonk/Marlin, Bulletproofs, STARKs) with their proof sizes and verification times.

Formal knowledge soundness (36:15)

The lecture gives a precise game-based definition of adaptive knowledge soundness: for any efficient adversary that produces a circuit, statement, and accepted proof, there must exist an extractor that interacts with the adversary and recovers a valid witness with comparable probability.

Functional commitments (42:17)

Boneh reviews basic commitment schemes (binding and hiding) and generalizes to functional commitments, where the committed object is a function and the prover can later prove evaluations of it. Four important families are introduced: polynomial commitments, multilinear commitments, vector commitments, and inner product commitments, with polynomial commitments (such as KZG) singled out for detailed treatment.

Interactive oracle proofs and the general SNARK recipe (1:05:35)

The lecture explains IOPs as protocols where the prover sends oracles to functions rather than the functions themselves, walks through a worked example (a set-containment IOP using polynomial division), and shows how any IOP paired with a matching commitment scheme yields a SNARK, made non-interactive via Fiat-Shamir. It closes with the "IOP zoo" (Sonic, Marlin, Plonk, Spartan, and others) and a brief look at how developers actually use SNARKs via domain-specific languages and compilers.

Before you watch

• Review the interactive zero knowledge proof concepts from Lecture 1 (completeness, soundness, zero knowledge), since this lecture assumes them.
• Basic familiarity with polynomials over finite fields will help with the polynomial commitment and Schwartz-Zippel sections.
• No blockchain background is required; the lecture explains each application from scratch.

Check your understanding

1. Why does sending the witness directly, as in a trivial NARK, fail to be a SNARK?
2. What problem does pre-processing solve, given that a succinct verifier doesn't have time to even read the whole circuit?
3. How does the Schwartz-Zippel lemma let two parties test whether two committed polynomials are equal without revealing the polynomials?
4. What is the difference between a trusted-per-circuit setup and a universal setup, and why does that difference matter in practice?
5. Explain in your own words how an interactive oracle proof combined with a functional commitment scheme produces a SNARK.