Lecture 4: Interactive Proofs and the Sum-Check Protocol

What this lecture covers

This lecture answers a specific question: how do you build a SNARK using an interactive proof as the main building block? It follows Dan Boneh's second lecture, which introduced SNARKs and functional commitments, and it prepares the ground for later lectures on Plonk and polynomial commitment schemes. Justin Thaler first pins down what an interactive proof is and how it differs from a SNARK, then works through the sum-check protocol and multilinear extensions in detail.

After watching, you should be able to explain the difference between a SNARK and an interactive proof (interactivity, statistical versus computational soundness, and knowledge soundness), state what the sum-check protocol proves and why it is efficient, and describe how Merkle trees and multilinear extensions are used as building blocks for a circuit-satisfiability SNARK.

Key ideas

• SNARK: a succinct non-interactive argument of knowledge — a proof that is short and fast to verify, that can be written down and checked by anyone without interaction, and that is only sound against computationally bounded (polynomial-time) provers.
• Interactive proof: a protocol where a prover and verifier exchange challenges and responses; it must satisfy completeness (an honest prover convinces the verifier) and statistical soundness (a lying prover is caught with overwhelming probability, regardless of its computing power).
• Knowledge soundness vs standard soundness: knowledge soundness requires the prover to actually know a witness, not just that one exists; SNARKs (the 'k' in the acronym) target knowledge soundness, which is the meaningful notion in most cryptographic applications.
• Fiat-Shamir transformation: replaces the verifier's random challenges with hashes of the prover's prior messages, turning an interactive public-coin protocol into a non-interactive, publicly verifiable one.
• Merkle tree: a vector commitment scheme built from a collision-resistant hash function; opening any entry requires only a logarithmic-size authentication path.
• Multilinear extension: the unique multilinear polynomial that agrees with a Boolean function on all 0/1 inputs; small differences between two functions blow up into large differences between their extensions, which is what makes them useful for succinct checks.
• Sum-check protocol: an interactive proof that lets a verifier confirm the sum of a multivariate polynomial's evaluations over the Boolean hypercube, using only order(L) verifier time plus one oracle query, instead of 2^L evaluations.
• Circuit-satisfiability SNARK: built by encoding a correct computation transcript as a polynomial, defining an auxiliary polynomial that vanishes on the Boolean hypercube exactly when the transcript is valid, and using sum-check (applied to its sum of squares) to verify that vanishing property.

Walkthrough

What is a SNARK, revisited (0:00)

The lecture opens with the hashing example from lecture two: proving knowledge of a message that hashes to zero. The trivial proof (send the message) is not succinct, so succinctness requires a shorter, faster-to-verify proof than the witness itself. Thaler breaks down the acronym SNARK letter by letter: succinct, non-interactive (postable to a blockchain), and argument of knowledge (sound only against bounded provers, and requiring the prover to know a witness).

Interactive proofs and how they differ from SNARKs (0:21)

Using the example of a resource-limited user offloading computation to a cloud provider, the lecture defines an interactive proof as a challenge-response protocol satisfying completeness and statistical soundness. It then contrasts interactive proofs with SNARKs along three axes: interactivity versus non-interactivity, statistical versus computational (argument) soundness, and standard soundness versus knowledge soundness. Examples illustrate when each soundness notion is meaningful, such as an expensive-computation claim (no witness, so only standard soundness applies) versus a claim of knowing a Bitcoin wallet's secret key (knowledge soundness required).

From interactive proofs to SNARKs, and commitment schemes (4:27)

To turn an interactive proof into a SNARK for circuit satisfiability, the prover commits to the witness with a cryptographic commitment scheme instead of sending it directly, then uses an interactive proof to show the committed witness satisfies the circuit, revealing only what the verifier needs. The lecture surveys functional commitments — polynomial, multilinear polynomial, and vector commitments — as the building blocks used later.

Merkle trees as vector commitments (6:45)

The lecture works through Merkle trees in detail: committing to a vector via a root hash, opening a leaf with a logarithmic-size authentication path, and why the scheme is binding (opening a leaf to two values would require a hash collision). It also sketches, and dismisses, a naive attempt to build a polynomial commitment scheme directly from a Merkle tree over all evaluations of a polynomial, showing why it is both too slow for the prover and gives no guarantee about the committed function's degree.

The Schwartz-Zippel lemma and multilinear extensions (20:14)

Thaler recaps the Schwartz-Zippel lemma for multivariate polynomials and introduces polynomial extensions, focusing on multilinear extensions of Boolean functions. He shows, with a worked 2x2 example and a Lagrange-interpolation formula, why multilinear extensions act as distance-amplifying encodings, and gives an algorithm that evaluates a multilinear extension at any point in time proportional to the size of the function's domain.

The sum-check protocol (34:44)

The core of the lecture: the sum-check protocol, round by round. In each round the prover sends a univariate polynomial claimed to equal a partial sum, the verifier checks consistency with the running claim and picks a random point to bind that variable, and the process recurses on one fewer variable. The lecture proves completeness and a soundness bound of roughly (degree x number of variables) / field size, and gives the cost profile: linear communication in the number of variables, fast verification, and a prover that runs close to the time needed just to evaluate the polynomial.

Counting triangles with sum-check (1:23:19)

As a clean application, the lecture applies sum-check to counting triangles in a graph, reinterpreting an adjacency matrix as a function over Boolean inputs and its multilinear extension. This lets a verifier run in time proportional to the input size (order n^2) rather than the slower matrix-multiplication time needed to solve the problem directly.

The circuit-satisfiability SNARK from sum-check (1:35:32)

The lecture closes by building a SNARK for circuit satisfiability: encode a computation transcript as a function over gate labels, extend it to a polynomial H, and construct a related polynomial G_H (using multilinear extensions of the circuit's wiring predicates) that vanishes on every Boolean input exactly when H encodes a correct transcript. Checking that G_H vanishes everywhere is reduced to a sum-check on the sum of its squared evaluations, giving a verifier that runs in time logarithmic in the circuit size and a prover close to linear time.

Before you watch

• Review lecture two's introduction to SNARKs, knowledge soundness, and functional commitments, since this lecture builds directly on that vocabulary.
• Be comfortable with polynomial basics: degree, evaluation, and the idea that a polynomial is determined by enough sample points.
• Familiarity with the Schwartz-Zippel lemma (that two distinct low-degree polynomials rarely agree at a random point) will make the soundness arguments easier to follow.

Check your understanding

1. What three properties distinguish a SNARK from an interactive proof, and why does the Fiat-Shamir transformation erase two of them?
2. Why is knowledge soundness a meaningful requirement in some settings but not others? Give one example of each from the lecture.
3. In the sum-check protocol, what does the verifier check in each round, and why does picking a random evaluation point catch a cheating prover?
4. Why does a naive Merkle-tree-based polynomial commitment fail to guarantee that the committed function is actually a low-degree polynomial?
5. How does the polynomial G_H reduce the complicated claim 'H encodes a correct transcript' into the simpler claim 'G_H vanishes on the Boolean hypercube'?