This a short post explaining the multivariate sum-check: a fundamental subprotocol used throughout multivariate succinct arguments (e.g. Spartan, HyperPlonK, etc). Roughly speaking, it often serves the same role as the divisibility check in the univariate contexts.
This post assumes familiarity with finite fields, polynomials and lagrange interpolation/basis.
Introduction
The multivariate sum-check enables a prover to convince a verifier that a particular multivariate polynomial sums to a particular value over a product of sets: , i.e.
Normally is a tensor space (hypercube) ; most commonly the Boolean hypercube :
Goal
Computing is expensive: taking time, even with some clever memoization tricks. The goal of the sum-check protocol is for the verifier to outsource this computation to an untrusted prover.
Communication
In the multivariate sum-check protocol the prover sends field elements to the verifier and the verifier sends field elements to the prover. This is logarithmic in the size of the hypercube since .
End of the Protocol
At the end of the protocol the verifier will need to evaluate the polynomial at a single point to check the prover’s claim. The verifier can either evaluate themselves (which may/may not be expensive) or delegate this computation to the prover using a multivariate polynomial commitment (relying on cryptography).
Hence, with logarithmic communication and computation in the size of , the sum-check allows the verifier to reduce the problem of summing a polynomial over to checking the value of that polynomial at a single point .
The Sum-Check Protocol
Recall the claim we want to verify:
Define the polynomial “summing away” :
Obviously if we also “sum away” the last variable we get :
At this point the sum-check protocol is straightforward:
- The (untrusted) prover sends a polynomial
- The verifier checks:
At this point the verifier needs to check that is indeed the correct polynomial, i.e.
To do so, the verifier samples and evaluating both sides at this point:
The green part the verifier can compute directly, by evaluating the polynomial at . The red part requires a large summation, but the dimension of the hypercube has been reduced by one (we got rid of ). Rather than computing this summation themselves, the verifier recursively use the sum-check protocol, asking the prover to show new the claim:
Where and .
End of the Protocol
After recursively applying the sum-check protocol above times, replacing each variable one-by-one, the verifier will be left with the claim:
At which point the verifier can either evaluate the polynomial herself (as in GKR) or delegate this computation to the prover using a polynomial commitment (as in e.g. Spartan).
Soundness
If then:
Is at most and the degree of is the maximal degree of in the polynomial – usually a small constant: in the most common case of multilinear polynomials it is just 1. This follows from the Schwartz-Zippel lemma.
To get a soundness analysis for all rounds (after recursively applying the sum-check) one can apply a union bound over each recursion step and arrive at a soundness error of:
In the multilinear case this is just .
Addendum: Efficiency via Lagrange Basis
Having the prover compute:
Directly is expensive in most applications.
Instead the prover can compute smaller sums and combine them using Lagrange interpolation. Recall the Lagrange basis polynomials for : for each we define the unique degree polynomial such that:
- It evaluates to at :
- It evaluates to on the rest of :
We can write the polynomial in -Lagrange basis:
With this rewrite the prover can compute the polynomial as:
This assumes that which is usually the case in applications, e.g. in the common case of multilinear polynomials summed over the Boolean hypercube. Otherwise the prover needs to compute the sum for a larger .
