Halo2 introduced a ZK lookup scheme, building on the ideas of Plookup. Given two vectors of numbers (actually, elements of some large finite field ) and , a lookup argument is an argument that
each is equal to some .
does not have to contain every element of . Also, can contain duplicates (as can ). But every element of has to appear somewhere in .
Nova introduced the idea of folding: a way to aggregate SNARKs (roughly, by taking random linear combinations of witness vectors) so that a large number of incrimental computations can be verified all at once. Nova described an explicit folding scheme for R1CS systems. Sangria gave a folding scheme for PLONKish arithmetizations, but also suggested (under Future Work – Higher Degree Custom Gates) that the same folding technique could work for any polynomial "custom gates".
The purpose of this note is to describe an explicit folding scheme for a Halo2 lookup argument. This is a special case of a general folding scheme for polynomial custom gates.
The Setup
Generally, we use capital letters as vectors, and the matching lower case letters refer to their coordinates. For example, a vector would have its entries labeled .
Imagine we have lookup arguments that we want to combine into one. In other words, we have vectors , and vectors . We know that each entry of is equal to some entry of , each entry of is equal to some entry of , and so forth.
(One common use case is evaluating a function by lookup table. In this case, the vectors are all equal to some publicly known which encodes the values of the function; the vectors encode some claimed evaluations of the function at specific points.)
In any case, we have lookup arguments that we want to fold together. The main ideas are as follows.
Halo2 tells us how to verify a single lookup, using permutations of and and a number of polynomial constraints. In more detail, for each , the prover finds a permutation of and a permutation of such that, for each , either
, or
.
For each , the prover and verifier carry out a grand product protocol to prove that is a permutation of and is a permutation of .
First, the verifier sends the prover random challenges and (for each ).
Based on those random challenges, the prover creates two new vectors and , the "grand product vectors".
In order to verify the lookup, the verifier checks a list of polynomial identities involving the vectors , , , , , and , and the random challenge scalars and .
To fold lookups together, we take a random linear combination of all the associated vectors , as well as the challenges and .
To verify the folded lookup requires a bit of algebra with the polynomial constraints, since nonlinear polynomials do not play well with taking linear combinations.
An example
Suppose we want to verify that are odd numbers, while are even.
3
1
6
2
7
3
4
4
3
5
4
6
5
7
4
8
First of all, the prover computes permutations such that each entry of is equal, either to the previous entry of , or to the same entry of . Similarly for and . Here's one way to do this:
3
3
4
4
3
1
4
8
5
5
4
2
7
7
6
6
You can check that:
is a permutation of , and similarly for the other three columns.
Each entry of is either the same as the entry of next to it, or a repeat of the previous entry of . The first entry , the and the are all the same as the adjacent entries of , while the second is a repeat of the first.
The same holds for .
Next, the prover sends the verifier commitments to all eight vectors above. The verifier replies with random challenges .
The prover uses the random challenges to compute grand products. Since the algebra is messy, we won't show an example here. What's important to know is just that the lookup problem can be translated into checking some polynomial conditions and
So far we have two lookup arguments: one for the odd numbers, and one for the evens. Now let's fold them together. First, the prover will send the verifier commitments to some cross-terms. (These are an algebraic artifact related to the nonlinearity of the polynomials .)
Then the verifier sends the prover a random challenge . (In our example, let's imagine .)
Finally, the prover computes the linear combinations and so forth.
603
201
403
403
407
403
403
801
403
605
405
205
405
807
607
607
Something strange happened here: The "lookup" and "permutation" relations are no longer satisfied. The number appears in but not in . The vector is not a permutation of . It looks like we've thrown out all the nice properties that made the lookup argument work.
But in fact polynomials save the day! The "folded" vectors will still satisfy a polynomial identity that we'll be able to write down, and that's what the prover will verify.
The Procedure
Relaxed AIRs
To start, we introduce the main object, a relaxed AIR, in the style of Sangria. The main idea of a relaxed AIR, like the relaxed R1CS analogue from Nova, is a polynomial constraint that involves a "slack term." While we can do this for general custom gates following the outline of Sangria, for this presentation we will specialize to lookups.
In the Halo2 setup, the prover starts with and ends up with vectors , using 2 scalars and supplied by the verifier (or Fiat-Shamir) to construct the grand products and . The prover then needs to prove that the following 7 equations hold:
.
Call these equations through respectively. In these equations, the vectors are constant and public. Just like in Halo2, they are used to implement zero knowledge.
Let . (In general, is the maximum number of distinct "shifts" that occur in any of the polynomial constraints. Since we have and in the same constraint – meaning the polynomial involves both and – we take for this protocol.)
To implement zero knowledge, only the first rows of the vectors will participate in the lookup. The last rows will be chosen by the prover at random.
: and for all . (In the Halo2 writeup, this is denoted and called a Lagrange basis polynomial– which of course is what becomes when you encode a column as a polynomial.)
: for , and otherwise (i.e. selects the last rows).
: for , and otherwise (i.e. selects the -st row, the last row before the "blind" rows).
This notation is very compressed. A couple of points:
Each polynomial equation corresponds to polynomial equations of the same form where each capital letter corresponds to substituting for , being the -th coordinate for the vector . The coordinates of the vectors, the 's, do not appear as arguments since they are constants.
We use to mean that when we unpack equation , instead of substituting , we substitute .
For each vector , each will only depend on entries , and possibly .
In any single , most of the arguments would not be used. Examples:
Consider the third equation This is shorthand for constraints of the form for each , where is the -th coordinate of .
In the first equation, would correspond to constraints , where
For lookups, we define the following "relaxed versions" of the equations above:
,
,
.
We define a relaxed lookup instance to be a tuple satisfying the above 8 equations (where is shorthand for the four vectors ). (In contrast to a "standard" lookup instance, which contains only the data , a relaxed lookup instance also contains the scaling factor and slack vectors .)
Whenever we have two instances and to fold together, we also define 5 "cross terms"
corresponding to the first relaxed equations. (This is because those equations are quadratic and the remainder are linear; we explain this a bit more below)
We now explain the new notation. First, is a "homogenizing" scalar considered as an additional input to each , so each relaxed is actually constraints of the form where:
each is a vector ;
for , we have .
For example, recall that used to encode constraints of form the new relaxed would instead encode constraints of the form
It remains to understand the roles of the cross terms and the slack terms , which is the key insight in Nova / Sangria. The main idea here is that we really want the equations to satisfy constraints of the form
where and are shorthand meaning "all the arguments." Concretely, this expression is equalities of the form
where the two arguments and encode and where, for example, and .
It turns out that the last polynomials through already satisfy this relationship, because they are linear. Because through are not linear, this relationship does not hold. However, we can introduce the cross terms to get:
Each corresponds to equations, and take all the inputs from both and . For example, corresponds to, as runs from to ,
To see this explicitly with we compute
as desired. By doing this, the 's are acting as an "error term" due to being nonlinear, and the 's act as an accumulated error due to all the 's.
Details of the Protocol (Halo2 lookups)
We first define a "one-round protocol" as follows:
To initialize folding, initializes a "cumulative lookup instance" where are all equal to zero.
initializes a cumulative committed instance where are all equal to zero.
When we fold in a new lookup instance , constructs a relaxed lookup instance by:
constructing permutations and as in Halo2,
sending commitments (including opening randomness) of to ,
requesting random challenges and from (or Fiat-Shamir) for that round,
constructing and from as in Halo2,
setting and for all ,
and run Protocol 1.
overwrites that is: apply Protocol 1, using the current as the first input and the new relaxed instance as the second input. During each step, we need a new for our "folding randomness".
During Protocol 1, builds the committed relaxed instance out of commitments sent from . Using , overwrites
After steps, the folding is complete. All that remains is for to convince that the final folded tuple is a legitimate witness to the committed instance , which is done as in the usual Halo2.
Comparison with Sangria
Scope
Sangria had outlined an approach to custom gates. Our lookup protocol is almost, but not quite, a special case of that procedure, mainly because of the roles of and . Instead, what we have here is a special case of "custom gates with verifier randomness," a concept that's a slight generalization of Sangria's approach to custom gates.
For completeness, we make explicit many of the ideas in Sangria's outline in our writeup of the general folding scheme.
Knowledge soundness
This protocol satisfies knowledge soundness: a cheating prover cannot convince the verifier to accept a folded proof unless the prover actually knows satisfying witnesses. We give a proof of knowledge soundness in our writeup.
In outline, the proof (very similar to as done in Sangria and Nova) is as follows. The idea is to imagine an extractor that interacts with the prover. The extractor is allowed to rewind the prover to a previous state. In practice, this means the extractor (playing the role of verifier) can send the prover different challenges , and see how the prover responds. Like in Nova and Sangria, by testing enough different values and doing a bit of algebra, the extractor can recover the witnesses that were folded together. Once the extractor can recover the folded witnesses, since Halo2 lookups themselves are knowledge sound, we know the prover must know valid lookup witnesses.
Our proof of knowledge soundness in the general scheme is only a bit more complicated than that of Sangria, partly due to the polynomials of arbitrary degree (although again Sangria had an outline already in Section 3.3) and partly due to the fact that we have "verifier randomness," as stated above. We have to take care that the verifier-provided randomness and does not mess things up.