1. 引言

2. 何为SNARKs？

所谓SNARKs，是指：

Prover $P$ 声称其知道满足某些属性的witness $w$ ：
- 如：某密码学哈希函数 $h$ 的输出结果 $y$ 对应的preimage $w$ ，即知道 $w$ 使得 $h (w) = y$ 。
Trivial Proof为：Prover $P$ 直接将witness $w$ 发送给Verifier $V$ ，Verifier $V$ 直接检查其是否满足所声称的属性。
SNARK（Succinct Non-interactive ARgument of Knowledge）可实现相同的效果，但Verifier $V$ 的计算开销要更低：
- 所谓“succinct”，是指：SNARK proof $\pi$ 必须比witness $w$ 要短。
- 检查 $\pi$ 要比 “直接检查 $w$ ” 要快得多——从而节约了Verifier $V$ 的计算开销。

2.1 SNARK设计细节——通用SNARKs：标准范式

以高级编程语言（如C、Java等）编写的计算机程序 $\psi$ ，仍以之前的哈希函数为例：

程序 $\psi$ ：以 $w$ 为输入，执行 $h$ 函数，检查输出是否等于 $y$ 。

在这里插入图片描述
总体的流程为：

1）Step 1 SNARK系统的前端：将程序 $\psi$ 转换为等价的probabilistic check——通常为某种circuit-satisfiability变种：
- 将“circuit”称为Intermediate Representation（IR），如：arithmetic circuit、R1CS、AIR、“Plonkish IR”、CCS。
2）Step 2 SNARK系统的后端：为circuit-satisfiability/R1CS/AIR/Plonkish等运行某SNARK。

2.2 SNARK前端编译工具

现有的SNARK前端编译工具有：【需对开发者友好程度与电路大小、性能、是否容易引入bug等方面做取舍权衡】

1）Bellman和Circom：以底层硬件描述语言来编写“Witness-checking” 程序 $\psi$ 。
2）ZoKrates、xJSnark等：以受限的领域特定语言来编写程序 $\psi$ 。相关限制有：
- write-once内存；
- 不支持string等重要的数据类型；
- 只有有限的控制流或没有控制流等等。
3）逐步走向高层语言：
- 3.1）各种zkEVM项目：致力于支持EVM bytecode，或者直接支持Solidity。Solidity程序会直接编译为EVM bytecode。
- 3.2）RISC-Zero：致力于支持RISC-V指令集。可将多种高层语言编译为RISC-V指令。
- 3.3）Cairo 1.0：为相对高层的DSL（领域特定语言），可被编译为供名为Cairo VM的简单CPU 使用的汇编语言。

需重点关注SNARK这些前端编译器工具的bug——即高层语言编写的程序与编译后的电路之间的准确映射关系，这将影响SNARKs的长期用途。如前端编译工具的某个bug，可能引起整个L2的资产都被盗。

2.3 SNARK后端

除 “基于linear-PCP的SNARK（如GGPR13、Pinocchio、Groth16等）” 和 “基于folding的SNARK（如Nova等）” 以外，其它SNARK后端设计的关键范式为：【不过，基于linear-PCP的SNARKs采用与特定多项式承诺（KZG）非常相似的技术。】

1）已知R1CS或circuit-satisfiability的 “Polynomial IOP”
2）将 “Polynomial IOP” 与某polynomial commitment方案（多项式承诺方案）结合，可获得succinct interactive argument。
3）借助Fiat-Shamir转换，可将succinct interactive argument 转换为 succinct non-interactive argument。

大多数SNARKs方案的计算瓶颈在多项式承诺方案，而Polynomial-IOP可决定后续多项式承诺方案需commit的多项式有多大。
设计Polynomial-IOP的准则是：让待commit的信息量最小化。

2.3.1 何为Polynomial-IOP？

SNARK协议中，Prover $P$ 的首个消息为某多项式 $h$ ，所谓Polynomial-IOP，是指：

Verifier $V$ 不需要知道整个多项式 $h$ 。从而可减轻Verifier $V$ 的负担，因为描述多项式 $h$ 所需的size 与 circuit一样大。
支持Verifier $V$ evaluate $h$ at one point。
然后，Prover $P$ 和 Verifier $V$ 之间执行标准的交互式证明。

2.3.2 何为多项式承诺方案？

多项式承诺方案用于将 “某Polynomial-IOP” 转换为 “某succinct argument”。
Polynomial-IOP的主要问题在于，其并不会直接给出succinct argument，因为其输出与多项式本身一样大。

多项式承诺方案，使得：

Prover $P$ 可对多项式做密码学承诺，相应的承诺值很小，类似一个哈希值或group元素等。
任意多项式承诺方案应具有binding属性。

多项式承诺方案的核心思想为：

Prover $P$ 发送short string $C o m (h)$ ，来将自身与多项式 $h$ 绑定。
Verifier $V$ 选择 $x$ ，并请求Prover $P$ evaluate $h (x)$ 。
Prover $P$ 发送 $y$ （声称 $y = h (x)$ ）以及proof $\pi$ （即 $y$ 值与 $C o m (h)$ 以及 $x$ 一致）。

多项式承诺方案应：

对于不正确的evaluation，Prover $P$ 无法声称convincing proof。
$C o m (h)$ 和 $\pi$ 应short，且，易于生成。
$\pi$ proof应易于验证。

现有的多项式承诺方案主要有四大类：

1）基于pairing的多项式承诺方案（既不transparent，也不post-quantum）：具有的独特属性为——具有constant sized evaluation proof。现有的基于pairing的多项式承诺方案有：
- KZG10
- PST13
- ZGKPP18
2）基于discrete logarithm的多项式承诺方案（transparent，但不是post-quantum的）：如：
- IPA/Bulletproofs
- Hyrax
- Dory*（Dory不仅需要discrete-log harness，还需要pairings）
3）基于IOPs+hashing的多项式承诺方案（transparent且post-quantum）：如：
- FRI
- Ligero
- Brakedown
4）基于unknown order group的多项式承诺方案（若使用class group则是transparent的，但不是post-quantum的）：由于使用class group，Prover $P$ 非常慢。现有的基于IOPs+hashing的多项式承诺方案有：
- DARK
- Dew

2.4 现在的SNARK性能

前序博客有：

SNARK Verifier $V$ 通常是cheap的：

相比于trivial proof system，其计算量要小很多。trivial proof system中Verifier $V$ 需直接使用 $w$ 验证有效性。
不同的SNARK方案开销各不相同：
- Plonk proof：在以太坊上验证Plonk proof约需要20万gas。
- STARK proof：取决于安全级别，约需要1000万gas。

SNARK Prover $P$ 通常是昂贵的：

相比于直接使用 $w$ 验证有效性，SNARK Prover $P$ 的计算量要大约60到80倍。【至少要慢100万倍。】
Prover $P$ 的计算开销可并行化。
但百万或千万级的减缓仍是制约因素。

SNARK Prover $P$ 的开销主要分为2大部分：

1）前端开销：是指，相比于直接做witness-checking，前端需用多长时间来evaluate the circuit output?
3）后端开销：是指，相比于直接基于 $w$ 对circuit进行evaluate，后端需用多长时间来为“该circuit is satisfied by $w$ ” 生成a SNARK proof？

以上SNARK Prover $P$ 的前端开销和后端开销均至少需放大1000倍，使得SNARK Prover $P$ 的总体开销至少放大100万倍。
SNARK Prover $P$ 的瓶颈通常在多项式承诺方案，但不总在多项式承诺方案。

2.4.1 MSM——基于multi-exponentiation的承诺方案

对于Multiplicative group，对size为 $n$ 的multi-exponentiation的计算形式为：
$\prod_{i=1}^{n}g_i^{x_i}$

对于Additive group，相应计算也称为MSM（multi-scalar-multiplication）。

当前流行的基于MSM的多项式承诺方案有：

KZG
IPA/Bulletproofs
PST
Hyrax
Dory

若naive直接做MSM计算，需要：

$n$ 次group exponentiation运算＋ $n$ 次group multiplication运算。
- 每个group exponentiation运算要比每个group multiplication运算慢约400倍。

若使用Pippenger算法来做MSM计算，相比于直接计算，可节约约 $\log n$ 倍开销：

实际性能能提升超过10倍。

若所有exponents（即 $x_i$ ）均为“small”，则可以再额外节约10倍的开销，即：

类似于，计算 $g_i^{2^{16}}$ 要比计算 $g_i^{2^{160}}$ 快10倍。即 $16^2$ vs. $160$ 。
若所有exponents（即 $x_i$ ）最大值为 $K$ ，且 $n >> K$ ，则Pippenger算法对于每个committed field element仅需要一次group multiplication运算。【即意味着此时，Pippenger算法比naive算法要快约400倍。当对small field elements承诺时，相应的MSM计算要比常规MSM计算快得多。】【Lasso中会利用这种small $K$ 带来的优势。】

3. Lookup Arguments：支持SNARK前端生成更小的电路

以range proof为例：

Prover $P$ 想要证明某程序执行过程中没有任何整数值超过 $2^{128}$ ，从而避免溢出错误情况。

3.1 range proof的naive方案

naive方案为：在circuit-SAT instance中实现：

将程序执行过程中的每个数字 $x$ 的128 bit field elements 作为电路的“non-deterministic advice”。
若Prover $P$ 是诚实的，则这128个 field elements应设置为 $x$ 的二进制表示。
该电路中必须check：
- 所有的这128个advice elements $b_0,\cdots, b_{127}$ 的取值在 ${0,1\}$ 中。
- 所有的这128个advice elements 确实对应为 $x$ 的二进制表示，即：
  $x=\sum_{i=0}^{127}2^ib_i$
naive方案是非常昂贵的：
- 一个简单的溢出检查，会在Prover $P$ 的witness中额外引入128个field elements——这些额外引入的field elements需由Prover $P$ 进行cryptographically commit。

3.2 range proof的lookup argument方案

Lookup argument提供了比以上naive更好的解决方案：

假设Prover和Verifier在某个时刻初始化了某lookup table，其中包含了由 $0$ 到 $2^{128}-1$ 之间的所有整数。
然后，range check等价为确认每个 $x$ 值在该lookup table内，使得range check 成为 single table lookup。

仍然以range check为例，相应的lookup argument定义为：

1）令 $t=(0,1,2,3,\cdots,2^{128}-1)$ 为具有 $N$ 个table元素的向量。
2）令 $a\in\mathbf{F}^m$ 为一组应包含在上述table的值列表。
3）Verifier $V$ 已知： $a$ 的承诺值 $cm_a$ 。
4）Prover $P$ 声称： $a$ 中所有元素均在table $t$ 中。
即Prover $P$ 声称其知道 $cm_a$ 的opening $a$ ，使得：
- 对于每个 $i=0,\cdots, m-1$ ，存在 $j\in\{0,1,\cdots, N-1\}$ ，使得 $a_i=t_j$ 。
5）通常将这种lookup argument称为unindexed lookup argument。

而indexed lookup argument是指待证明元素中还附加了索引值，indexed lookup argument定义为：

1）令 $t\in\mathbf{F}^n$ 为具有 $N$ 个table元素的向量。
2）Prover $P$ 对向量 $((a_1,b_1),\cdots,(a_m,b_m))$ 进行承诺。
3）Prover $P$ 声称，对于 $i=1,\cdots,m$ ，有 $a_i=t[b_i]$ 。【即 $a_i$ 为value， $b_i$ 对应为table $t$ 的索引号，Prover $P$ 声称 $a$ 中所有元素均存在于 $t$ 中相应的index。】

3.3 现有lookup argument的Prover开销

当对size为 $N$ 的table做 $m$ 次查找时，之前的lookup argument的Prover $P$ 需对很多field elements进行commit：

1）Arya[2018]：需对至少 $m+2N\log m$ 个field elements进行commit。
2）Plookup[2020]：需对至少 $5*\max\{m,N\}$ 个field elements进行commit。
3）HyperPlonk[2023]：需对至少 $4*\max\{m,N\}$ 个field elements进行commit。

同时，在以上lookup argument中，为避免Verifier维护整个size为 $N$ 的table，在预处理阶段，某honest party还必须对整个size为 $N$ 的table 进行commit。

4）Caulk[2022]、Caulk+、flookup、Baloo、cq（cached quotients）将以上Prover $P$ 中与 $N$ 呈比例的开销推送到了预处理阶段：
- 均需要size为 $N$ 的SRS。【若table size为 $2^{25}$ ，则SRS将达数GB。】
- 在预处理阶段需做 $O(N\log N)$ 次group exponentiation运算。
这样预处理之后，cq具有最好的性能：
- cq 的Prover $P$ 仅需对 $8 m$ 个field elements进行commit，并做 $O(m\log m)$ 次filed 运算（采用FFT）。【Prover $P$ 开销与table size $N$ 无关。】

3.4 Lasso族的lookup argument

Lasso族的lookup argument有：

1）Basic-Lasso：为最简单直接的lookup argument。
- 性能与现有lookup argument（如Plookup）相当。
2）Lasso和Generalized-Lasso：可用于更大的lookup table，只要其是“structured”，可用于GB级的table。
- Lasso的效率更高，但需要更强的structural属性——本文称为decomposability（可分解性）。
- Generalized-Lasso需要更弱的、名为LDE-structured的属性。其中LDE全称为“Low Degree Extension”。

3.4.1 Basic-Lasso：做indexed lookup开销

Basic-Lasso做indexed lookup的开销为：

Prover $P$ 需对 $min\{m+N, 2m+O(N)\}$ 个field elements进行commit。
- Up to low-order terms。
All are small：
- They are in $\{0,\cdots, m\}$ 。这些均为multiplicity（即只对table中每个元素被访问的次数进行排序）：
  - 最多有 $m / k$ 个值大于 $k$ 。
  - 最多有 $m$ 个非零值。而零值 cost “nothing”（因为对零值进行commit没有开销）。
  - 警告：需要一个polynomial evaluation proof——对应的Prover开销将随着 $N$ 呈增长（对于某些多项式承诺方案，Prover开销将随着 $N$ 呈sublinearly增长，也有一些摊销策略）。
若lookup table是LDE-structured，则不需要对该lookup table进行承诺。
除非使用基于KZG的承诺方案，否则无需排序，也无需SRS。

Basic-Lasso与Plookup和cq的性能对比情况为：

1）Plookup：
- 1.1）Prover $P$ 对至少 $5*\max\{m,N\}$ 个field elements进行commit。其中 $3*\max\{m,N\}$ 个committed field elements是随机的。
- 1.2）＋需对lookup table进行commit。
- 1.3）Prover $P$ 必须对lookups进行排序（或至少需“group（分类）”），并做FFT运算。
2）cq：
- 2.1）经预处理之后，Prover $P$ 仅需对 $8 m$ 个field elements进行commit。其中 $7 m$ 个committed field elements是随机的。
- 2.2）若lookup 次数 $m$ 远小于 $N$ ，则推荐使用cq：【或者，使用bit-decomposition方案有可能会更好】
  - 若可接受cq的预处理，以及size为 $N$ 的SRS。
  - Due to avoiding $O (N)$ terms。
- 2.3）若lookup 次数 $m$ 不是远小于 $N$ 的场景，则Basic-Lasso的Prover $P$ 要比cq快约30倍：
  - 2.3.1）3倍的加速源于更少的committed field elements。
  - 2.3.2）另外10倍的加速源于small field elements。
    - 若对looked-up value向量 $a$ 的commit计时，则10倍加速依赖于table elements是small的。
    - 若 $a$ 中包含 $m$ 个任意field elements，则10倍加速将降为 2.5倍加速。
  - 2.3.3）此外，cq的Prover $P$ 需做FFT运算。

3.4.2 Lasso

Lasso中具有整数参数 $c > 0$ ：

可用于“ $c$ -decomposable tables”。
对size为 $N$ 的table做单次lookup，可分解为对size为 $N^{1/c}$ 的table做 $c$ 次lookup。
Prover $P$ 最多需对 $3cm+cN^{1/c}$ 个filed elements进行commit：
- All are small。
若lookup table是LDE-structured，则无需对该lookup table进行commit。
当 $c = 1$ 时，Basic-Lasso为Lasso的特例情况。

举个具备decomposability的例子：对 $(0,1,2,3,\cdots,2^{128}-1)$ 做range proof：

Lasso的Prover $P$ 会将element $x$ 切分为在 $c$ 个limbs中做range-check，每个limb包含 $128/ c$ bits。
- 如有8个limbs $l_1,\cdots,l_8$ ，每个limb有16 bits。
Lasso的Verifier $V$ 需确认每个provided limb均在small range $t=(0,1,2,3,\cdots,2^{16}-1)$ 且 $x=\sum_{i=1}^{8}2^{16(i-1)}\cdot l_i$ 。
该例子已在Arya[BCGJM 2018]中详述。
相应的small table 是LDE-structured的：
- $t(r_1,\cdots,r_{16})=\sum_{i=1}^{16}2^{i-1}\cdot r_i$

3.4.3 Generalized-Lasso

不同于Lasso，Generalized-Lasso不要求其lookup table是decomposable的：

Generalized-Lasso只要求其lookup table是“LDE-structured”。
与Lasso一样，Prover $P$ 具有相同的承诺开销：需对 $3cm+cN^{1/c}$ 个filed elements进行commit。
- 但是有 $c m$ 个committed field elements不是small的。【因此推荐用Lasso而不是Generalized-Lasso。】
“LDE-structured” 意味着关联某lookup table的某特定多项式需可在 $O(\log N)$ time内完成evaluate。

4. 解锁新的SNARK前端技术：Jolt（Just One Lookup Table）

以VM execution应用场景为例：
Prover $P$ 声称其运行了某特定计算机程序共 $m$ 个steps：

该计算机程序以某VM的汇编语言编写。
当前流行的VM有：RISC-V、Ethereum Virtual Machine（EVM）。

针对VM execution应用场景，当前的前端技术方案为：为每个computation step生成一个电路：

1）指出在该step执行什么指令
2）并执行该指令

而Lasso方案，是将以上“2）并执行该指令” 替换为单个lookup：

对于每个指令，该lookup table中存储了 该指令的entire evaluation table。
若指令 $f$ 有2个64-bit输入，则相应的lookup table中会存储每个64-bit inputs $(x, y)$ pair的 $f (x, y)$ :
- 该lookup table size为 $2^{128}$ 。
- Jolt 显示所有的RISC-V指令是decomposable的。

4.1 Jolt开销

对于支持64-bit数据类型（具有“multiply extension”）的RISC-V指令，相应的Jolt开销为：

对于每个RISC-V CPU step，Jolt Prover $P$ 需对约50个filed elements进行commit。
- 这50个field elements中的7个field element 值小于 $2^{25}$ 。
- 这50个field elements均不大于 $2^{64}$ 。
- 借助基于MSM的多项式承诺，每个CPU step Jolt Prover $P$ 的开销约为：
  - 对5个任意field elements（256-bit）的commit开销。

附加说明：可通过多个“伪指令”来处理2个RISC-V指令：
如，带余数除法运算：

Prover $P$ 可提供商和余数，然后通过乘法和加法运算来检查其正确性。
加法指令可通过少于5个committed 256-bit field elements来处理。

Jolt与Plonk、RISC-Zero、Cairo VM对比：

1）Jolt：针对具有（“multiply extension”的）64-bit数据类型的RISC-V。借助基于MSM的多项式承诺，对于每个CPU step，Jolt Prover $P$ 的开销约为：
- 对5个任意field elements（256-bit）的commit开销。
2）Plonk：对于arithmetic circuit中的每个gate，Plonk Prover $P$ 的开销为：
- 对11个field elements进行commit。
- 这11个field elements中有7个为任意field elements。即使gate values are “small”，也至少有6个为任意field elements。
3）RISC-Zero：针对具有（“multiply extension”的）32-bit数据类型的RISC-V，对于每个CPU step，RISC-Zero Prover $P$ 的开销为：
- 至少对275个 31-bit field elements进行commit。约等价为对 $\frac{275}{8}\approx35$ 个（256-bit）field elements 进行commit。
- 附加说明：RISC-Zero不使用基于MSM的承诺（采用的为FRI承诺方案），使得不便于做相精确对比。
4）Cairo VM：定位为“SNARK-Friendly” very simple CPU。
- Cairo VM会编译为名为AIR的电路，然后用特定的SNARK（从而避免了基于MSM的承诺方案）。
- 对于每个Cairo CPU，Cairo VM Prover $P$ 需对超过50个field elements 进行commit。
- StarkWare当前采用某251-bit field。
  - 对于Cairo VM的每个step，StarkWare Prover $P$ 需对超过50个（256-bit）field elements 进行commit。
  - 要求所采用的field的characteristic至少应为 $2^{63}$ 。【因为其采用 $0\sim 2^{63}$ 来表示Cairo CPU内的指令。】
    - 因此，对于每个CPU step，至少需对 $\frac{50}{4}\approx 13$ 个（256-bit）field elements进行commit。

5. 当前进展

相应的开源代码实现见：

https://github.com/a16z/Lasso（Rust）

https://github.com/a16z/Lasso代码库中：

当前只实现了Basic-Lasso。
当前采用arkworks曲线库以及msm实现。
预计经工程优化后，Basic-Lasso的速度可再提升2倍。
对Basic-Lasso的并行化正在实现中。
对于具有random field elements的table，Basic-Lasso的速度要比，包含 $\{0,1,\cdots,2^{24}\}$ field elements的table，慢3倍到4倍。
- 原因在于：不可避免的开销——对looked-up value vector进行commit。
- 但仍比Halo2+IPA快5倍到15倍，比Halo2+KZG快3倍到7倍。

5.1 Basic-Lasso与Halo2对比

Basic-Lasso与Halo2对比：

1）Halo2为当前流行的，高度工程化的代码库：
- 其为Plonkish电路实现了Plonk backend，并可选支持Bulletproofs/IPA多项式承诺方案或 KZG多项式承诺方案。
- Halo2的lookup argument为Plookup的变种：
  - Prover $P$ 对至少 $5*\max\{m,N\}$ 个field elements进行commit。其中 $3*\max\{m,N\}$ 个committed field elements是随机的。
  - ＋需对lookup table进行commit。
2）Basic-Lasso的Prover $P$ 需对 $m + N$ 个field elements进行commit，且all are small。

在具有16GB RAM的M1 Mackbook Pro上做如下对比：

1）Halo2——Bulletproofs/IPA多项式承诺＋ Pasta curve（Pallas）
2）Halo2——KZG多项式承诺＋ BN254曲线
3）Basic-Lasso——Hyrax多项式承诺＋ Curve25519

单线程运行（未做并行化优化），对应的性能对比为：【KZG要快一点，是因为Bulletproofs的Prover具有非常慢的evaluation proof。】
在这里插入图片描述

参考资料

[1] 2023年8月Justin Thaler给a16z团队分享视频 Lasso, Jolt, and the Lookup Singularity, Part I with Justin Thaler | a16z crypto research talks

Lasso、Jolt 以及 Lookup Singularity——Part 1