Basic idea of lookups in SNARKs is similar to what has been used in LUTs in processors. Having a table and a set of lookups , and , such that table represents all possible legal values of a computation and lookup represent input to the computation.

Let’s take an example of k-bit XOR computation:

Naïve way of doing would mean having arithmetic constraints on each bit, which would amount to

SoK

For doing lookups in a table of size . Assuming, commitments are multi-exponentiations.

ProtocolCommitment CostComments
Plookup
Hyperplonk
Baloo, CaulkMove table commitment cost to preprocessing phase, but requires SRS of size .
cq, FFTcommit to table only once in preprocessing
logUp
Lasso

Plookup

builds a permutation argument similar to plonk’s permutation argument to prove that witness values exist in lookup table in the same order, i.e. these two sequences are permutation of of length .

Note: means is sorted by , i.e. value of appear in same order as . So, plookup is basically just another permutation argument on neighbouring values.

Any lookup consists of (input, output) pair that can be compressed in a field element and looked up in table . Purpose is to prove is included and is sorted by . Plookup takes approach of set differences to check that a vector is subsequence of the other. Explained really well here. Note, plookup uses randomised set differences of form as another sequence with same set difference can be easily found.

Let’s build the intuition behind the protocol:[^1]

  • Take two sequences and such that . This means, every value of t must appear in f.
  • Take another sequence such that , in other words .
    • Define two multivariate polys .
  • Now, let’s take our witness values and extend by concatenating such that . Thus, every element of is now sorted according to and is already sorted according to .
    • This means, there will be indices in such that , and equals as multisets.

So, the relation holds when following relation satisfies:

Protocol

  1. computes and commits two polynomials s.t. and
  2. computes quotient polynomial that aggregates :
  3. checks:
&(x-\omega^{N})Z(x)(1+\beta)(\gamma+f(x))(\gamma(1+\beta)+t(x)+\beta t(\omega x))=\\&(x-\omega^N)Z(\omega x)(\gamma(1+\beta)+h_{1}(x)+\beta h_{1}(\omega x))(\gamma(1+\beta)+h_{2}(x)+\beta h_{2}(\omega x)) \end{align})$$ We can extend the plookup protocol for multiple ## [[logUp-lookup]] ## [cq](https://eprint.iacr.org/2022/1763) cq uses the trick of logarithmic derivative to create lookup for *"large tables"*. so, it says that for two polynomials $p(x)=\prod_{a\in A}(x+a)$ and $q(x)=\prod_{b\in B}(x+b)$ are equal iff rational functions: $\frac{p'(x)}{p(x)}=\frac{q'(x)}{q(x)}$. ## [Lasso](https://eprint.iacr.org/2023/1216) ### Unindexed v/s Indexed Lookup args - Unindexed: lookup into table only needs to assert that $m_i \in N$, i.e. it doesn't matter where in the table the looked up operand lies. - Indexed: lookups inside table are indexed. - More formally: $\forall i \in [m],\ \exists (b_{i},m_{i}) \implies m_{i}=N[b_{i}]$ Table structures: - LDE-structured: also called *decomposable* in the paper. - MLE-structured: table can be expressed an MLE polynomial, evaluable in logarithmic time. - According to the Lasso paper, almost all useful tables like in Jolt, are MLE structured. ## Resources - [Ingonyama: Brief History of Lookup Arguments](https://github.com/ingonyama-zk/papers/blob/main/lookups.pdf) [^1]: Note that the protocol described in this article is from [Plonkup](https://eprint.iacr.org/2022/086) paper which extends plookup protocol with alternating method for $s$.