LogUp-GKR
This article explores how the Halo2 Lookup, LogUp, and LogUp-GKR protocols have evolved.
Last updated
This article explores how the Halo2 Lookup, LogUp, and LogUp-GKR protocols have evolved.
Last updated
Demonstrating that all values in Set belong to Set is the core feature of Lookup. In ZK, this Lookup is used to prove that a value falls within a specific range or to reference a value proven in another circuit. . Recently, it has converged into implementing one of two approaches: LogUp-GKR or Lasso. At ProgCrypto 2023, as seen in from the PSE team, the performance of the two methods is reported to be nearly identical. In this article, we aim to discuss how Halo2 Lookup evolved into LogUp-GKR, as observed in the video.
1
1
2
2
1
3
3
1
1
1
2
2
1
3
3
1
1
1
1
1
1
0
2
2
1
0
0
1
3
2
2
0
3
0
3
3
0
0
0
0
0
0
0
0
0
0
These constraints can be expressed as follows:
The first row must equal 1.
These constraints can be expressed as follows:
1
0
1
1
1
1
1
0
0
2
2
1
0
1
0
0
1
3
2
2
20/9
0
0
3
0
3
3
2
0
1
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
2
1
1
2
1
1
0
0
1
1
1
1
1
0
0
0
2
2
1
0
1
0
0
0
1
3
2
2
20/9
0
0
0
3
0
3
3
2
0
1
0
0
0
0
0
1
0
0
1
a
b
c
d
e
0
0
1
f
g
h
i
j
0
0
0
0
0
0
0
0
1
1
4
1
2
1
3
2
1
2
1
3
3
2
0
0
0
0
0
0
0
0
0
0
Lemma 3 of LogUp summarizes that Multiset Check, based on products, can be replaced with a sum-based method as shown below:
Lemma 5 of LogUp summarizes how multiplicity can be utilized in the sum-based method:
Both lemmas can be derived informally by taking the logarithm on both sides of the Multiset equality based on products followed by taking derivative of both sides. The converse is shown following the reverse process.
The first row must equal 0.
The last row must equal 0. (Unlike the running product column, the check for equality to 1 is removed.)
These constraints can be expressed as follows:
1
0
1
1
4
1
0
0
0
2
1
3
2
-2/3
0
0
1
2
1
3
-5/6
0
0
3
2
0
0
-9/20
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
The constraints can be expressed as follows:
where the first two constraints force the two output fractions to add up to zero.
The interaction between the prover and verifier proceeds in the following sequence:
The verifier checks the validity of these values.
The values in the bottom layer will be filled as described in the LogUp-GKR paper. Using the previous LogUp example, it would look as follows:
(0, 0, 0, 0)
1
(1, 0, 0, 0)
1
(0, 1, 0, 0)
1
(1, 1, 0, 0)
1
(0, 0, 1, 0)
1
(1, 0, 1, 0)
1
(0, 1, 1, 0)
1
(1 1, 1, 0)
1
(0, 0, 1, 1)
4
(1, 0, 1, 1)
3
(0, 1, 1, 1)
1
(1, 1, 1, 1)
0
We have reviewed the evolution from Halo2 Lookup to LogUp-GKR. Initially, the process started with univariate polynomials, but from LogUp onward, multivariate polynomials were used. As the protocol evolved, the number of committed polynomials decreased, leading to improved performance, as illustrated in the examples above.
Prerequisites: See and for more details
In the arithmetization of PLONK or AIR, witnesses and public values are commonly filled into a table. Here, let’s assume there are an input polynomial and a table polynomial . Typically, the number of the rows is in the form of a power of 2. In this case, the columns of the table are interpreted as polynomials, and the rows are interpreted as the domain. In the example below, the columns of the table are interpreted as univariate polynomials, and is the 4-th root of unity. Therefore, holds.
In the table above, can be expressed as follows, where refers to the Lagrange Basis. (See for more information.)
On the other hand, if the domain is expressed as a boolean hypercube as shown below, it can also be interpreted as a multivariate polynomial. (Here, , unlike the previous example, represents a 2-dimensional vector.)
In the table above, can be expressed as follows. (See for more details)
Lookup tries to prove that all the unique values in set are also in set . In practice, is much smaller and consists of unique, non-repeating values.
All rows larger than and are filled with zeros. In Halo2 Lookup, new polynomials (or auxiliary columns) and are created as shown below. Before creating and , and must be committed. (For convenience, is included below, but it is not actually a committed polynomial.)
is a polynomial derived from sorting and must satisfy one of the following conditions:
If it is the first row, the values of and must be the same.
The values of and its preceding column must be the same.
If and are not the same, and must have the same values.
If it can be proven that and satisfy the constraints above, the previously discussed MultiSet Check can now be applied. A new polynomial is then defined to run MultiSet Check, which must satisfy the following constraints. The column representing is referred to as the running product column.
The next row is the value obtained by multiplying the current by and dividing by .
The last row must equal either 0 or 1. While a value of 1 is trivial, 0 occurs when and are sampled in such a way that either the numerator or denominator becomes zero, causing all subsequent entries to be filled with zeros.
For example, if and , will be filled as follows. Before constructing , and must be committed (For convenience, is included below, but it is not actually a committed polynomial). Since the index of the last row is 4, .
In a Polynomial Interactive Oracle Protocol (PIOP), we use a Polynomial Commitment Scheme (PCS) to transform the problem into an Interactive Oracle Protocol (IOP). The verifier must open several values via the oracle to check the correctness of the relationship above. Assuming we open at , the maximum number of values per polynomial to open is 2.
Since this could break the ZK property, additional random values to are added to two columns as shown in the table below. (For convenience, is included but is not actually a committed polynomial.)
When using Halo2 Lookup, if there are input polynomials referencing , there are columns to commit, as there are values of each , , and . The downside of this method is inefficiency, as the same is referenced repeatedly, requiring redundant computations with and . Considering that Lookup is often used to verify ranges, this cost cannot be ignored.
For more details, refer to .
In the , the protocol is described for multivariate polynomials, but here it is described for univariate polynomials as used in Scroll Halo2.
Let us assume there are two polynomials referencing , as shown below:
To solve the problem above, let us create a polynomial that indicates the degree of multiplicity. Before creating , , , and must be committed.
Based on this, let us assume that, as before, a running product column is created. However, with expressed as an exponent, it can no longer be represented as a polynomial.
By applying this, a new polynomial can be defined, which must satisfy the following constraints. The column representing this is referred to as the running sum column.
The next row is the value obtained by adding to the current and subtracting .
Before constructing , must be committed. If , will be filled as shown below. (For convenience, and are included below but are not actually committed polynomials.)
In Scroll Halo2, constraints are flexibly expressed with fractional sums, whereas in the original LogUp, they are strictly expressed with polynomial sums. This is also the case in and presented by Polygon Miden at ZKSummit 12.
With the strict method, the degree of the constraint polynomial can increase, which is why the original LogUp separately creates a helper function as shown below:
When using univariate LogUp, if there are input polynomials referencing , there are 2 columns to commit: and .
By introducing in LogUp, the computational overhead is reduced. If is large, the reduction becomes even more significant. However, there is still overhead associated with generating and committing . Can this overhead be eliminated?
In , inspired by Lasso, GKR is introduced to further enhance Lookup performance. The height of a layer as 3 can be represented as a layered circuit in GKR as follows:
Here, represents the fraction sum where is the numerator and is the denominator.
Hence, is formally defined as below.
The prover sends , , , to the verifier.
The verifier samples and and sends them to the prover.
The prover and verifier execute the sumcheck protocol to assert over the equation below until the final layer.
For the final layer, the prover sends to the verifier.
The verifier computes and compares it with the claim .
The verifier samples and sends it to the prover.
The prover sends to the verifier.
The verifier queries at and compares the result with the .
For the final layer, the prover sends to the verifier.
The verifier computes and compares it with the claim .
The verifier samples and sends it to the prover.
The prover sends to the verifier.
The verifier compares with the claim .
1 +
2 +
1 +
3 +
1 +
1 +
2 +
2 +
1 +
2 +
3 +
When using LogUp-GKR, if there are input polynomials referencing , only 1 column needs to be committed. Additionally, the issue in LogUp with excessively high degrees of constraints has also been resolved.
Written by from