关于Lasso、Jolt和SNARK设计最新进展的技术常见问题解答

1. 引言

前序博客有：

Ulvetanna团队Benjamin E. Diamond和Jim Posen（以下简称D&P）近期发布了论文《Succinct Arguments over Towers of Binary Fields》：

改进了Ligero/Brakedown多项式承诺方案
并将其与基于sum-check的SNARK方案（如Lasso）结合。
开源代码见：
- https://github.com/recmo/binius（Rust + Sage）【基于plonky3等库】【Binius：针对硬件优化的SNARK】

本文主要用于响应Lasso、Jolt和Binius常见问题FAQ。

2. 问题1：借助D&P多项式承诺方案，Jolt prover证明RISC-V程序速度？

相对于RISC-V程序的原生执行，一旦Jolt实现了D&P多项式承诺方案，Jolt prover的速度能有多快？

Jolt Prover，对RISC-V CPU rv32im的每个step的约800个bit进行commit。
需注意：

某些RISC-V指令，由多个伪指令来实现。如division指令，实际是由Prover提供商和余数，然后通过乘法、加法、等式检查来实现的。
当Jolt Prover的lookup table实现为 $GF[2^{128}]$ 的分解表示时，实际每个step所commit的bit数可能会变。

借助D&P多项式承诺方案，并假设递归不是瓶颈，则对于有 $T$ 个step的计算，其主要承诺开销为：

1）对总共约 $200 T$ 字节应用additive FFT的开销。更准确来说，Ligero/Brakedown Prover会做 $O(\sqrt{T})$ 个size为 $O(\sqrt{T})$ 的独立FFT——这样的总工作量更少，且比单个size为 $O (T)$ 的FFT更高度并行化。
2）使用标准哈希函数，如Keccak或SHA2，来对约 $200 T$ 字节进行哈希运算的开销。

经验上来看，D&P发现，以上FFT开销和哈希开销，对prover time的影响基本相当。

以Keccak哈希的约70 RISC-V cycles per byte为例，其用时，比简单运行该RISC-V程序而无correctness proof，要慢约3万倍。即，为证明某RISC-V程序 $\Psi$ ，Jolt prover（当其自身在RISC-V中实现）至少需要比 $\Psi$ 多3万倍个cycles。

这些承诺开销足够“快”，使得prover的瓶颈可能在于其运行sum-check协议中的field运算（即使包含了对small-characteristic fields的优化（The Sum-Check Protocol over Fields of Small Characteristic））。因此，粗略来说，可猜测Jolt prover（当其自身也在RISC-V中实现）至少需要比简单运行 $\Psi$ RISC-V程序多约5万倍个cycles。

整个评估过程有点粗糙，是基于zkVM的prover开销来初步评估的。

尽管5万倍看起来慢了很多，但其比18个月前在Measuring SNARK performance: Frontends, backends, and the future的100万倍，要快了约20倍。其主要改进在于：

由Lasso和Jolt解锁的：
- 更少的承诺数据量
- 以及，每个承诺值具有更小的size
更好的承诺方案：如在基于hash的SNARKs中，改进使用快速哈希函数，并利用所承诺值的smallness。

3. 问题2：D&P提供了对Keccak和Grøstl的fast SNARK，原因何在？是否有其它哈希函数适用该技术？

D&P提供了对Keccak和Grøstl的fast SNARK，原因何在？是否有其它哈希函数适用该技术？

作为NIST表中，Keccak/SHA3为以太坊预编译合约的不二之选，也是Type-1 zkEVM的关键瓶颈。【SHA3为官方NIST表中，Keccak为以太坊预编译，二者差异很小，与SNARK开销无关。】

D&P考虑Grøstl，是因为其有更快的prover，同时拥有很多Keccak优点。特别是：

Grøstl受到了严格的密码分析审查，因为它进入了NIST SHA-3竞赛的最后一轮（尽管它最终没有被选中），而且它使用了AES S-Box。由于AES加速指令AES-NI，Grøstl在英特尔芯片上的运行速度甚至比Keccak更快。

使用Grøstl的D&P prover速度要比使用Keccak更快，因为：

Grøstl原生定义于 $GF[2^8]$
从而意味着，相比于Keccak，D&P prover需承诺的field元素数更少。【详细见后面的问题9，承诺更少的域元素数对Prover的好处】
结论是Grøstl应该比Keccak更容易接受（递归）SNARK，因为它对prover和on chip都更快。

D&P SNARKs不局限于Keccak和Grøstl，该技术还可用于其它哈希函数，如SHA2等。

4. 问题3：Lasso/Jolt是否锚定为基于椭圆曲线的承诺方案？

问题3：Lasso/Jolt是否锚定为基于椭圆曲线的承诺方案？

答案是否定的。Lasso/Jolt并不锚定为基于椭圆曲线的承诺方案，但其受益于先前的工作，可与基于椭圆曲线的承诺方案结合使用。

由于基于椭圆曲线的承诺方案中，当Prover需对随机域元素承诺时开销特别大，因此当使用基于椭圆曲线的承诺方案时，为实现性能最优，Lasso/Jolt会尽量避免对随机域元素进行承诺。

简短来说，之前使用椭圆曲线承诺方案所设计的SNARKs，并未利用对small values承诺的优势，而，在基于哈希的承诺方案中，已利用该优势——使用small fields。

在之前使用基于哈希承诺方案的成果之上，Lasso/Jolt主要做了2方面改进：

1）D&P展示了，基于哈希的承诺方案，其受益于仅对small field元素进行承诺的优势，超过之前认知。
如当今的承诺方案，对1-bit value承诺和对32-bit value承诺，的prover开销是一样的。而，D&P方案，对1-bit value承诺的开销要便宜近32倍。详情见Boosting Lasso+Jolt through faster commitments – with far-reaching consequences。
2）Lasso和Jolt不仅会确保Prover仅对small field元素进行承诺，还会确保，相比于non-sum-check-based SNARKs，其commit的域元素数更少。
事实上，Jolt中会仔细计算所有所承诺域元素的bit复杂度，并确保其比现有zkVM的数量要更少得多。

几个月前Lasso/Jolt发布时，另一个技术麻烦让我们强调了基于曲线的承诺：

FRI：为数月前仅有的，具有polylogarithmic proof size的hash-based承诺方案，其针对的是单变量多项式。而Lasso/Jolt使用multilinear多项式。见2023年10月博客Need for Speed: efficient multilinear PCS in Lasso and Jolt。
- 已知的多个将FRI调整为适于multilinear多项式的方案，都会增加额外开销（prover time、proof size，或同时增加prover time和proof size）。当时评估这些方案非常没有吸引力：
  - 2019年论文《Transparent Polynomial Delegation and Its Applications to Zero Knowledge Proof》
  - 2022年论文《Gemini: Elastic SNARKs for Diverse Environments》
  - 2022年论文《HyperPlonk: Plonk with Linear-Time Prover and High-Degree Custom Gates》
  - 2023年论文《Improving logarithmic derivative lookups using GKR》
  - 最新的2023年论文《BaseFold: Efficient Field-Agnostic Polynomial Commitment Schemes from Foldable Codes》中：支持具有polylogarithmic proof size的“direct” multilinear commitments，但其Prover要比Brakedown的慢，且其proof size比FRI的大。

不同于FRI，Ligero/Brakedown承诺方案直接应用于multilinear多项式，具有非常快的prover。当之前来说，为降低proof size，对Ligero/Brakedown承诺方案做递归是困难的，因为Verifier需要做大量哈希运算，使得递归是昂贵的。而D&P方案，通过对哈希实现更快的SNARKs，可大幅降低其递归开销。

5. 问题5：Lasso/Jolt中仅对small values承诺时，curve-based承诺方案是否优于hash-based承诺方案？与认可D&P SNARKs是否冲突？

正如之前2023年7月博客 17 misconceptions about SNARKs (and why they hold us back)中所指出：

1）在一些重要的SNARK应用中，hash-based的SNARKs肯定不是最具性能的，因为这些SNARK应用在椭圆曲线group的基域。此时curve-based的承诺方案会更快。证明任何关于椭圆曲线密码系统的statement（如，授权区块链交易的ECDSA数字签名 knowledge proof）都属于这一类。
2）即使是基于small characteristic field的应用，hash-based方案与curve-based方案的性能对比也是复杂的。如，取决于hash-based方案中所采用的哈希函数有多快。
当今很多项目，为支持递归，都使用更慢的哈希函数，如Poseidon。使用Poseidon这样的哈希函数，当像Lasso/Jolt那样对small values承诺时，使得hash-based方案，要比curve-based方案慢得多。详情见 multilinear多项式承诺方案benchmark对比。但是即使使用更快的哈希函数，也不确定其能更快，具体见2023年8月twitter讨论。

与现有的FRI hash-based承诺方案相比，D&P促进了hash-based承诺方案：

基于characteristic two field，对hash-based承诺方案加速。
支持prover更好的利用现有committed values的smallness。

除非证明原生定义于其它有限域的statement，目前认为，基于characteristic two field的Ligero/Brakedown是可行的。

总之，目前来看，人们相信hash-based方案比curve-based方案更快，的主要原因在于：

当今流行的SNARKs，如Plonk，需要Prover对随机域元素进行承诺，而不是对small域元素进行承诺。对随机域元素进行承诺时，curve-based方案是非常慢的。

Lasso/Jolt指出，无需要求prover对随机域元素进行承诺。在这种情况下，这种比较至少更微妙。到目前为止，基于曲线的方案实际上更快，但随着D&P的改进，现在情况正好相反（除非针对基于large field原生定义的statement）。

6. 问题5：hash-based承诺方案，具有low security？

像FRI或Ligero/Brakedown这样的hash-based承诺方案本身并没有什么不安全的地方。但是，项目已经普遍将性能置于安全之上，使得所部署的FRI配置，对已知攻击是接近可行的，并假设这些对FRI的已知攻击是最优的。

Ligero/Brakedown承诺的一个好处是，关于FRI的主要猜测（即其在Johnson bound之外的proximity参数下的推测安全性）是不相关的，因此SNARK设计者不可能将安全性建立在这种猜测的基础上。

同样，Justin Thaler长期以来一直担心在SNARK部署中使用表面上“SNARK-friendly”的哈希，如Poseidon。这些哈希（即使是最长的哈希）的安全性也没有像Keccak这样的标准哈希那样受到严格审查。

在上述两种情况下，Justin Thaler的观点都是，为了弥补当今SNARK的性能缺陷，项目一直在危害安全。消除这些做法的最简单方法是简单地开发性能更好的SNARK。

与此相关的是，Justin Thaler认为目前手工设计“SNARK-friendly”虚拟机和实现这些虚拟机的约束系统的做法是一个主要的安全问题（也是开发人员资源的巨大消耗者），因为设计约束系统和开发从高级语言到自定义虚拟机的汇编代码的新编译器容易出错。希望Jolt通过证明标准指令集确实和SNARK一样友好，并消除手工设计实现这些指令集的约束系统的任何需求或动机，使这种做法过时。

消除具有负面安全影响的做法的方法是想出更具性能的SNARK，使该做法变得无关紧要。

7. 问题6：D&P的多项式承诺方案中使用Reed-Solomon code，而Brakedown可使用任意code。是否有必要探索其它code，以实现最优性能？

问题6：D&P的多项式承诺方案中使用Reed-Solomon code，而Brakedown可使用任意code。是否有必要探索其它code，以实现最优性能？

答案是肯定的。

8. 问题7：Ligero/Brakedown的Prover性能在哪些方面优于FRI？

问题7：Ligero/Brakedown的Prover性能在哪些方面优于FRI？

当对very small values进行承诺时，D&P大幅改进了prover time，这是Ligero/Brakedown独有的，至少目前是这样。此外：

当对small values进行承诺时，D&P不仅改进了prover time，还改进了prover space。特别对于hash-based SNARKs来说，prover space是主要瓶颈。如，Polygon zkEVM prover需要250GB+ 来证明处理消耗约1000万gas的a batch of transactions的电路
Ligero/Brakedown所使用的纠错码，具有更大的灵活性。事实上，D&P对small values承诺的大部分改进，都是通过简单使用Ligero/Brakedown内的concatenated codes来实现的。
当使用Reed-Solomon code时，Ligero/Brakedown prover会做许多small FFTs，而不是做一个big FFT。这可节约FFT runtime中的a factor of two，且具有更好的并行化。
FRI需要同时做FFT和IFFT（技术层面来说，其源自FRI实际需要对所承诺多项式在多个点进行evaluate）。
Ligero/Brakedown prover可跳过IFFT（技术层面来说，跳过IFFT源自Ligero/Brakedown选择纠错码的超级灵活性）。若使用a “Reed-Solomon blowup factor” of 2（为针对prover time优化的blowup factor），则其可约33%的prover time。
Ligero/Brakedown evaluation proofs无需prover做额外的Merkle hashing。而FRI prover需要做额外的Merkle hashing（尽管FRI可将evaluation proofs的这种Merkle hashing开销，摊销到多个committed多项式）。

9. 问题8：是否可认为D&P对 $GF [2]$ 元素的承诺，要比对 $GF[2^2]$ 元素便宜？进而比对 $GF[2^4]$ 元素便宜？

问题8：是否可认为D&P对 $GF [2]$ 元素的承诺，要比对 $GF[2^2]$ 元素便宜？进而比对 $GF[2^4]$ 元素便宜？

用D&P承诺方案，对一组values进行commit时，所需的prover time，仅依赖于：

确定这些values所需的总的bits数。指定 $0$ 到 $2^b$ 的某value，需要 $b$ 个bits。

D&P SNARKs中的其它prover开销，确实会随，用于encode那些bits的field elements数量而增加。【具体见后面问题9。】

Brakedown多项式承诺方案，可使用任意所需的纠错码，来对待承诺的values vector（subvector）进行编码。若待承诺的values在 $GF [2]$ 内，但想要将其编码到更大的域 $GF[2^{16}]$ 。（这么做的技术原因很多，事实上，若想要对长度长达 $2^{16}$ 的vector进行编码时，这是有必要的。）

为此，可简单使用code concatenation：

将所有的 $GF [2]$ values按chunk size $16$ 分组，然后将每个chunk的 $16$ 个 $GF [2]$ values，“pack”进单个 $GF[2^{16}]$ 域元素内。这样，可将待承诺的域元素数降低16倍。
然后可对域 $GF[2^{16}]$ （称为“outer code”）应用任意纠错码。
将最终获得的codeword，“unpack”进 $16$ 个 $GF [2]$ 元素内，且该结果编码了定义于 $GF [2]$ 的“inner code”。

这样，以上concatenated方案，降低了所承诺向量的长度（以域元素数来衡量）为 $16$ 倍，但需要prover做pack和unpack操作，同时将inner code用于每个（unpacked）outer codeword symbol。

通过对Brakedown简单应用concatenated codes，已实现了很多D&P成果优势。但，D&P采用了一种不同的方式，来实现了甚至更快的prover（代价为稍微大一点点的proof）。如，D&P实际方案，避免了将inner code用于每个（unpacked）outer codeword symbol 的开销。

10. 问题9：既然D&P对 ${0,1\}$ 承诺非常cheap，为何不将计算中的所有values分解为二进制表示？即，为何不将整个计算实现为Boolean电路？是否对电路内的每个input bit和gate分配了“full” field element？

问题9：既然D&P对 ${0,1\}$ 承诺非常cheap，为何不将计算中的所有values分解为二进制表示？即，为何不将整个计算实现为Boolean电路？是否对电路内的每个input bit和gate分配了“full” field element？

D&P中的SNARK for Keccak，其prover确实仅对 ${0,1\}$ values进行commit，但对于通用场景，其不是个好思路。

事实上：

D&P的承诺时长，会随所有committed values的bit复杂度总和，而增加，与这些values切分至多少个域元素无关。（这也是为何在SNARK for Keccak中，仅对one-bit values进行承诺是可行的。）

但是，这并不意味着，所有开销都与所承诺的域元素数无关。特别地，D&P承诺方案的evaluation proof size，会随所承诺的域元素数 $N$ 增加， $O(\sqrt{N})$ 。

另外，D&P SNARKs中，一些sum-check协议应用中所需求和的terms数，会随所承诺的域元素数增加。粗略来说，当对 $x$ 倍个域元素进行commit，则sum-check prover需对 $x$ 倍个terms求和。对small-characteristic fields的优化（The Sum-Check Protocol over Fields of Small Characteristic））可减轻该开销，但减轻的量并不够。即，相比于将 $x$ 个one-bit values pack进单个 $x$ -bit域元素来commit，直接对 $x$ 个one-bit values进行commit的sum-check prover要更慢。为减轻对多个on-bit values进行承诺的开销，在承诺之后，D&P为，将 $x$ 个one-bit values pack进单个 $x$ -bit域元素来commit，提供了sum-check-based协议。从而避免为多个committed values花费过多的sum-check-prover time，同时又保留其优势（特别地，一旦某bit decomposition被承诺，当使用sum-check证明时，则像bitwise AND之类的特定操作无需任何额外的承诺开销）。

11. 问题10：D&P所使用的characteristic two field的优势何在？

问题10：D&P所使用的characteristic two field的优势何在？

优势很多，包括但不限于：

D&P重度利用tower field构建。在characteristic two field上下文中，是指，构建 $GF[2^2]$ 作为 $GF [2]$ 的degree-2 extension， $GF[2^4]$ 作为 $GF [4]$ 的degree-2 extension， $GF[2^8]$ 作为 $GF[2^4]$ 的degree-2 extension，等等以此类推。1986年论文AN ITERATED QUADRATIC EXTENSION OF GF(2) 为已知的高效characteristic two field tower构建。
sum-check协议为多变量多项式 $g$ 计算 $\sum_{x\in \{0,1\}^n}g(x)$ 。Boolean hypercube ${0,1\}^n$ （及其subcubes）为power-of-two size，因此subfields与subcubes良好对齐。D&P利用该属性，很容易就可将多个small-field元素pack进单个更大扩域的元素内。
D&P，当前使用Ligero/Brakedown多项式承诺方案中的Reed-Solomon码。高效的Reed-Solomon编码需要additive FFTs，其在characteristic two field内工作很好，但在其它域内不行。但是，也可使用其它codes来完全避免FFT，如：
- 2021年论文Brakedown: Linear-time and field-agnostic SNARKs for R1CS
- 2023年论文Brakedown’s expander code
真实硬件可很好地处理characteristic two field。真实计算机是基于power-of-two-sized数据类型的。可无需填充，很好地匹配寄存器、cached lines等的最大信息。Intel甚至在其芯片内集成了 $GF[2^8]$ 域运算的原语指令，其速度特别快。见Galois Field New Instructions (GFNI) Technology Guide。利用Intel的这些原语指令，可实现非常快的 $GF[2^k]$ 运算，甚至是 $k > 8$ ——当使用tower构建时。

12. 问题11：使用D&P承诺方案的递归SNARK，其最小proof size是否有限制？

问题11：使用D&P承诺方案的递归SNARK，其最小proof size是否有限制？

答案是肯定的。使用Ligero/Brakedown承诺方案的SNARKs的“recursion threshold”有点高。“recursion threshold”指的是proof size，对Verifier递归应用基于Brakedown/Ligero SNARK，不再生成更短的proof。期望“recursion threshold”为数MB级别的。

如需更小的proof，可通过与smaller-proof SNARKs组合使用来实现。具体见后面的问题12。（如果这被证明是错误的，这不应该被视为Binius的失败，而是对当今流行的SNARK的可扩展性的控诉。如果他们不能在合理的时间内证明所哈希的几个MB的数据，怎么能称之为可扩展的？）

无论如何，除了降低proof size之外，还有一些原因表明快速递归组合很重要。最值得注意的是，它是控制prover空间需求的关键工具。由于（非递归）SNARK对prover来说是高度空间密集型的，人们会将大型计算分解为小块，分别证明每一块，并使用递归证明将这些块“链接”在一起（有关这一点的说明，请参阅RISC Zero的continuations机制）。D&P为Keccak等标准哈希函数提供的快速SNARK使这种递归证明能够快速完成，即使proof有点大。

13. 问题12：假设将使用D&P承诺方案的SNARK，与，基于椭圆曲线的SNARK（如Plonk或Groth16）组合，以降低proof提交上链的验证开销。是否需证明包含“non-native”域运算的statements，因D&P的verifier基于 $GF[2^{128}]$ 运算，而基于曲线的SNARKs使用更大的素数域？

问题12：假设将使用D&P承诺方案的SNARK，与，基于椭圆曲线的SNARK（如Plonk或Groth16）组合，以降低proof提交上链的验证开销。是否需证明包含“non-native”域运算的statements，因D&P的verifier基于 $GF[2^{128}]$ 运算，而基于曲线的SNARKs使用更大的素数域？

答案是肯定的。这是潜在挑战。但未来可解决该问题。

可能可行的方案之一是：

1）先与某使用hash-based多项式承诺方案和shorter proofs的SNARK组合，（可能是转换为multilinear多项式承诺方案的FRI，或BaseFold），然后再与curve-based SNARK组合。注意FRI可原生支持characteristic two field，且该设置已在原始FRI论文中考虑。与FRI本身相反，当前流行SNARKs中使用类似域的限制源自，其使用的是non-sum-check-based polynomial IOPs。

这并未消除non-native域运算的问题，但可大幅减轻，因对足够大的多项式，相比于Ligero/Brakedown verifier，FRI verifier做的总运算数更少，其中field运算数尤其要更少。具体见Comparison of FRI vs. Ligero proof sizes。

14. 问题13：使用D&P承诺方案的SNARKs，是否可与folding schemes（如Nova）结合使用？

问题13：使用D&P承诺方案的SNARKs，是否可与folding schemes（如Nova）结合使用？

该问题与问题12类似。folding schemes使用椭圆曲线——通常定义于大素数域，而D&P承诺方案使用的是power-of-two sized fields。

随着folding schemes的进一步发展，未来可能在SNARK设计中发挥重要作用。但是，其可能无法简单地与，基于very small characteristic fields的hash-based SNARKs，很好地结合。

基于椭圆曲线的承诺方案和folding schemes，应用于基于large fields原生定义的statements，或prover space为最重要的场景。从prover space角度来说，folding schemes要远远优于其它SNARKs。因为相比于其它SNARKs，folding schemes会将large computations，切分为小得多的片段。否则，应使用，基于small-characteristic fields的hash-based方案。

随着folding schemes未来发展，有可能能超过hash-based方案。

根据The Pantheon of Zero Knowledge Proof Development Frameworks (Updated!)，在某些测试维度，Nova性能已超过hash-based SNARKs。（尽管许多人声称当前基于哈希的SNARK比基于曲线的SNARK更快）。

15. 问题14：为何D&P结论不明显？能否简单地将多个small域元素串联之后，再做“pay by the bit” with hashing-based多项式承诺？

问题14：为何D&P结论不明显？能否简单地将多个small域元素串联之后，再做“pay by the bit” with hashing-based多项式承诺？

hash-based承诺方案有2大运算，均为实际实现瓶颈：

FFTs运算：更通用来说，是某纠错码的编码操作
哈希运算

即使待FFT运算的向量内的所有制都是small的（即少数bits），FFT转换中的Twiddle factor仍然是larger的，因此，仍需基于larger values做运算。此外，由FFT生成的向量中，包含了与FFT输入相关的“extra”域元素，且这些额外域元素并不是small的——甚至更糟，若像D&P中那样使用non-systematic code，则整个编码向量都将不再是small的，而不仅仅是“extra”域元素不small。当计算承诺值是，这是所需哈希的FFT的后果。因此，不仅FFT内域原酸开销不再受益于待承诺的small values，哈希开销也不再受益于待承诺的small values。

确保small values转换为更快的FFT和更快的Merkle哈希的明智方法是将这些small values中的许多打包到单个域元素中，这就可以转换为具有bigger values的shorter vector，而不是具有smaller values的longer vector。characteristic two tower field被设计为使得这种pack操作实际上对应于简单地将small values的二进制表示连接在一起，以获得（连接的）域元素的二进制表示。这正是D&P所做的。

然而，事情并不像上述段落所暗示的那样简单。大多数复杂情况的出现并不是由于承诺过程本身（只涉及一个或多个FFT-transformed向量的Merkle-hash），而是由于多项式evaluation proof过程中发生的事情。在多项式承诺方案的这一点上，有多个（子）域四处浮动，例如Reed-Solomon编码的字母表、在evaluation过程中从中提取随机值的扩域等。这些不同域的相互作用很难定义和分析。

参考资料

[1] Justin Thaler 2023年11月20日博客 A technical FAQ on Lasso, Jolt, and recent advancements in SNARK design
[2] Justin Thaler 2023年11月21日twitter