Sumcheck
(Most of the content of this section is from Section 4.1 in Proofs, Args, and ZK by Justin Thaler, which has more detailed explanations of the below.)
This section will first cover the background behind the sumcheck protocol, and then provide an introduction as to why this may be useful in verifying the computation of layerwise arithmetic circuits.
The sumcheck protocol is an interactive protocol which verifies claims of the form: In this statement, is not necessarily multilinear, and .
In other words, the prover, , claims that the sum of the evaluations of a function over the boolean hypercube of dimension is Naively, the verifier can verify this statement by evaluating this sum themselves in time assuming oracle access to (being able to query evaluations of in time), with perfect completeness (true claims are always identified by the verifier) and perfect soundness (false claims are always identified by the verifier).
Sumcheck relaxes the perfect soundness to provide a probabilistic protocol which verifies the claim in time with a soundness error of where is the maximum degree of any variable .
The Interactive Protocol
We start with a straw-man interactive protocol which still achieves perfect completeness and soundness in verifier time and prover time Then, we build on this version of the protocol and introduce randomness to achieve verifier time, with a soundness error of
A non-probabilistic protocol
Note that the sum we are trying to verify can be rewritten as such: Let's say sends the following univariate: One way for to communicate to the univariate is to send evaluations of . While can alternatively send coefficients, we focus on this method of defining a univariate and assume sends the evaluations to .
can verify whether is correct in relation to by checking whether In other words, we have reduced the validity of claim that is the sum of the evaluations of over the -dimensional boolean hypercube to the claim that is the univariate polynomial over a smaller sum.
Now the verifier has evaluations to verify. We can similarly reduce this to claims over even smaller summations. Namely, now the prover sends over the following univariates:
and keep engaging in such reductions until is left to verify evaluations of : this is exactly the evaluations of over the boolean hypercube, assuming that has oracle access to (it can query evaluations of in time).
We have transformed the naive solution, where just evaluates the summation on their own, into an interactive protocol. In the next section we will go over how to slightly modify this by adding randomness to significantly reduce the costs incurred by and .
Schwartz-Zippel Lemma
As a brief interlude, let us go over the Schwartz-Zippel Lemma, which we can use to modify the straw-man protocol. It states that if is a nonzero polynomial with degree , then the probability that for some random value sampled from a set is upper-bounded by .
This is can be seen because by the Fundamental Theorem of Alegbra, has at most roots. We take the probability that we randomly sampled one of those roots out of a set of size .
In the case of sumcheck, we consider the polynomial to be over a field , and our randomly sampled element to be uniformly sampled from .
Introducing randomness
Our main blow-up with the straw-man interactive protocol came from the exponentially growing number of claims had to verify, ending up with evaluations of at the end. Instead, if we found a way for the reduction from to claims on (or the reduction from the claim of to claims on ) to be a one-to-one reduction in terms of number of claims, rather than one claim reduced to two claims, would only have to verify claims, and would only have to send over univariate polynomials.
Let us keep the first step the same, where first sends the following univariate polynomial:
Now, checks whether Instead of sending both and , uniformly samples a random challenge from and sends this to sends a single univariate: checks whether This process is repeated iteratively, until finally in the last round, where sends the following:
Assuming the verifier has oracle access to , the verifier can check whether . The difference between this protocol and the naive protocol above is that at each step, instead of individually verifying and , sends a "challenge" in which responds to by sending over the appropriate univariate polynomial. Therefore we have achieved a one-to-one claim reduction, and the verifier having to only verify one equation per round.
Soundness Intuition
We provide brief intuition for the soundness bound from the above protocol. At any step , the prover can cheat by sending a different univariate polynomial instead of the expected such that , but . This allows them to, ultimately, prove a different original statement: that the sum . Because sends to , we can be confident that does not adversarially choose to be one of the roots of . Then, by the Schwartz-Zippel lemma, the probability that happened to be one of the "zeros" of where is the degree of
Example
We do a short example of the sumcheck protocol in the integers. Let rightfully claims that In order to verify this claim, and engage in a sumcheck protocol.
sends the univariate: verifies that Then, samples the challenge and now computes:
checks that Next, samples another challenge and sends it to who then computes and sends Finally, samples another random challenge and checks whether Indeed,
Why Sumcheck?
In the previous section, we introduced the notion of a multilinear extension of a polynomial , which is defined as Notice that naturally, a multilinear extension is defined by taking the sum over a boolean hypercube, which is what sumcheck proves claims over.
In the next section, we will go over how we can encode layers of circuits as multilinear extensions, and prove statements about the output of these layers using sumcheck.