multilinear多项式承诺方案benchmark对比

1. 引言

前序博客有：

Lasso、Jolt 以及 Lookup Singularity——Part 1
Lasso、Jolt 以及 Lookup Singularity——Part 2
深入了解Lasso+Jolt

Lasso lookup中，multilinear多项式承诺方案的高效性至关重要。

本文重点关注4种multilinear多项式承诺方案的实现和benchmark：

1）Ligero: native & recursive implementation; benches, 【交互式】
2）Brakedown: native implementation; benches, 【交互式】
3）Hyrax: native implementation; benches, 【交互式】
4）multilinear KZG: benches. 【非交互式】

目前为止，没有在单个库中基于同样的backend实现了以上4种multilinear多项式承诺方案。如：

现有的Hyrax学术实现，是基于Python的。
multilinear KZG：基于Rust，以arkworks库为backend。
Ligero和Brakedown：基于Rust，以ZCash库为backend。

本文：

基于arkworks实现了Hyrax、Ligero和Brakedown
基于https://github.com/EspressoSystems/jellyfish（也是以arkworks库为backend）的现有multinear KZG 添加了benchmark
为Ligero实现了Halo2 verifier，以支持潜在的链上验证。

具体开源代码实现见：

https://github.com/HungryCatsStudio/poly-commit（Rust）【运行cargo bench来benchmark】
- 已向https://github.com/arkworks-rs/poly-commit提交Ligero、Brakedown和Hyrax的PR，当前正在review中。
- 已向https://github.com/EspressoSystems/jellyfish/pull/390提交了KZG bench的PR，已被merge。
  - jellyfish KZG time bench：cargo bench --bench="pcs" --features="test-srs"
  - jellyfish KZG size bench：cargo bench --bench="pcs-size" --features="test-srs"

在对以上multilinear多项式承诺方案进行benchmark时，重点关注以下维度：

Prover time
Verifier time
Proof size
On-chain verification 链上可验证
Recursion friendliness 递归友好性

本文bench所采用的硬件为AMD Ryzen™ 9 7950X3D：

CPU: 16 cores / 32 threads @ 4.2 GHz
Generation: Raphael (Zen 4) with AMD 3D V-Cache™ Technology
RAM: 128 GB ECC DDR5 RAM

2. native benchmark

本文所选的4个multilinear多项式承诺方案中，有3个是天然交互式的。通过应用Fiat-Shamir transform，可将这些交互式方案转换为非交互式的。所谓Fiat-Shamir transform，实际上是通过某密码学hash-based sponge来实例化。

递归验证所需的hashing in-circuit，若采用基于bitwise运算的哈希函数（如SHA256），要比采用algebraic哈希函数（如Poseidon），慢几个数量级。

为此，对于Ligero，考虑2个变种：

1）基于SHA256所优化的原生哈希
2）支持递归的Poseidon哈希（R）。

KZG是非交互式的，其无需Fiat-Shamir transformation。

Ligero的结论，足以支撑非交互式Brakedown和非交互式Hyrax的结论。

需注意的是，Jolt中的特定应用所承诺的元素是“small”的，为此，将考虑对Hyrax采用额外的变种：

使用专门针对 $< 60$ bits优化后的改进版MSM。
相比于任意（A）系数场景MSM， $< 60$ bits的版本是small变种（S）。

在对以上方案做benchmark时，一个重要事实是：

Ligero proof size 要大于 Brakedown proof size。
当给矩阵输入相同的多项式系数时，自然会认为Brakedown具有更大的proof size，因为需open更多的columns。

因此在实际实现时，Ligero总是生成square matrices，而Brakedown的列数比行数多。为此，需对Ligero的实现进行调整，使其与Brakedown采用相同的arrangement。这样：

prover time要大一点。
但verifier工作量减少了：因为每列所需哈希的元素数减少了。

实际实现时，Brakedown采用的是Brakedown: Linear-time and field-agnostic SNARKs for R1CS论文中的第三行参数（small distance）：
在这里插入图片描述
与采用Larger distance的linear codes版本的Brakedown相比，small distance版本具有更大的 $t$ 值（即更大的open列数），但改进了prover time。

为此，本文实际benchmark了6个版本的方案：

1）multilinear KZG
2）Hyrax（S）：所承诺的元素为 $< 60$ bits的值。
3）Hyrax（A）：所承诺的元素为任意值。
4）Ligero：采用优化后的基于SHA256的哈希函数。【基于linear-code】
5）Ligero（R）：采用支持递归的Poseidon哈希函数。【基于linear-code】
6）Brakedown：【基于linear-code】

Ligero、Ligero（R）和Brakedown均是基于linear-code的，其共享用于编码系数矩阵中每一行所选择的linear函数带来的运算模式。

实际实现时，多项式系数取自于BN254曲线的scalar field。选择BN254曲线是为了支持潜在的以太坊链上验证需求。

KZG和Hyrax的安全性上限取决于做group运算所选择的椭圆曲线，更准确来说，是取决于所关联的特定group的DLP（Discrete Logarithm Problem） hardness。

Ligeror和Brakedown实现时采用安全参数，致力于实现128 bits的安全性。

需注意的是，尽管致力于为这些基于linear-code的方案实现128位安全性，而不是BN254 DLP的110位安全性，性能上有一定的差异，源自于要open相对少一点的列——仅为a few percentage points。

2.1 Prover计算开销bench

以下所有值的单位为ms，空白表示未运行相应的bench（如，仅关注少量方案的large $n$ 情况）。横杠表示试图运行，但超过了bench机器的计算资源。

2.1.1 Prover commit时长bench

在这里插入图片描述
相关数据分析有：

当多项式的变量参数个数 $n$ 小于22个时，Ligero方案的commit时长有优势。这与Brakedown论文中的结论一致。Brakedown具有渐进的linear time，且事实上，但具有足够大的 $n$ 值时，Ligero具有额外的 $\log(n)$ 因子负担。当有 $n\geq 24$ 的multi-linear多项式，Brakedown的优势开始显现。
Ligero（R）的commit（open以及验证）时长，要比Ligero慢得多。
实际所实现的基于Linear-code的方案（Ligero、Ligero（R）和Brakedown），在opening阶段都缺少了一个明显的优化：
- Prover应无需对所有列重新哈希，因为其已在commit阶段哈希过了。
- 当使用高效基于bitwise的哈希原生运算时，这可能不是大额开销，但仍然有改进空间。
- 该问题的核心在于，受限于当前的arkworks trait定义，Prover无法在commit和opening阶段共享除实际commitments（以及所谓的“randomness”）之外的任何数据。为此，也向arkworks提交了PR试图解决该问题：added the auxiliary data of the prover for opening。

2.1.2 Prover open时长bench

下表数据单位为ms。
在这里插入图片描述
Prover的open时长竞争更激烈，但对于足够大的 $n$ 值，Ligero险胜于multilinear KZG。

2.2 Verifier计算开销bench

2.2.1 验证时长bench

下表中数据单位为ms。
在这里插入图片描述
相关数据分析有：

Ligero为基于Linear-code的方案（Ligero、Ligero（R）和Brakedown）中的expected winner。因为Ligero，由于其相对大的code distance，其open的列数是small的。
为实现一定级别的安全性，Brakedown需要open更多的列。
与commit时长不同，在所bench的 $n$ 值区间，无法看到Brakedown的渐进优势。猜测当 $n$ 值非常大时，可能Brakedown的优势会明显，但实际上无法bench。

2.3 size大小bench

2.3.1 Proof size大小bench

下表中数据单位为字节。
在这里插入图片描述
很明显，在Proof size方面，基于椭圆曲线运算的方案（KZG和Hyrax）要吊打其它方案几个数量级。其中的winner是KZG。

基于linear-code的多项式承诺方案的proof size为 $\mathcal{O}(2^{n/2})$ 。

2.3.2 commitment size大小bench

下表中数据单位为字节。
在这里插入图片描述
实际bench时，有必要考虑commitment size：

Hyrax为唯一的 commitment size与多项式size相关的 multilinear多项式承诺方案。其系数矩阵中的每行对应一个椭圆曲线点。
除Hyrax之外的方案，其commitment size均为相对小的常量值：
- 基于linear-code的PCS，其commitment size为哈希摘要。
- KZG的commitment为单个group元素——对于BN254曲线，正好也是64字节。

3. recursive benchmark

当讨论SNARK recursion或composition时，是指将某verifier的验证流程（inner）作为另一（outer）方案的的电路：

首先对inner电路运行Prover，以获取有效的（inner）proof。
然后将该（inner）proof作为outer电路的输入（通常为private输入）。
最后为outer电路运行Prover，其暗含了认可该inner verifier。

递归的好处在于：

可使用具有fast prover但large proof size的方案，将该fast-prover方案 “wrap” 在某short-proof方案中，从而获得所需的small proof。
满足特定的verifier逻辑要求，如链上verifier仅支持Groth16 proof。

因为，为让outer verifier信服某statement，需同时运行inner prover和outer prover。因此实际应仔细权衡取舍。

杜宇递归验证，无需关注“native” verifier time，因为该inner-verifier已包含在outer prover中。

在递归benchmark时，当前仅有Ligero方案的试验数据。实际是基于Axiom的halo2-lib来实现的Ligero方案——由Modulus Labs的小伙伴实现，未来将开源。

根据Ligero所需open的列数，来推断Brakedown中需open的列数。并基于https://github.com/axiom-crypto/halo2-lib#bn254-msm中所提供的BN254 MSM benchmark，初步评估了KZG和Hyrax。

MSM为multi-scalar multiplication简称（即将一组group元素相加，每个group元素乘以可能不同的scalar值），为KZG和Hyrax多项式承诺方案中的核心运算。

3.1 递归Prover计算开销

除了以上所描述的outer-prover开销。当实际实现递归验证方案时，还需考虑inner prover，为满足递归友好性，先前提到的SHA256哈希函数开销巨大，因此更适合使用电路友好的Poseidon哈希函数。

3.1.1 proof生成时长（Halo2）

下表数据单位为秒。
在这里插入图片描述
相关数据分析有：

Hyrax的开销，为对2个size为 $2^{n/2}$ 的MSM的，具有 $n$ 个变量的multilinear多项式的，证明时长。基于https://github.com/axiom-crypto/halo2-lib/blob/15bca77fd383a7cb04099483cb6a3524c3615b0d/halo2-ecc/src/bn254/tests/msm.rs#L67 Halo2-lib，使用不同数量的base-scalar pairs来bench。
KZG开销，为基于 https://github.com/axiom-crypto/halo2-lib/blob/15bca77fd383a7cb04099483cb6a3524c3615b0d/halo2-ecc/src/bn254/tests/pairing.rs#L49 的单个pairing的bench，其乘以 $n$ 。实际multilinear KZG验证计算中包含了一个multipairing of $n$ pairs，通常可优化为比 $n$ 个独立pairing 运算更快。
Brakedown当前未做递归proof生成时长bench。
- 因为所选的硬件配置，已无法为大型多项式运行Ligero verifier。原因在于，当 $n = 18$ 时，有超过25万个halo2 advice cells，大多数都源自基于linear-code多项式方案在非交互式设置下所需的大量哈希。
- 而相同参数配置下，Brakedown所需的open列数，要比Ligero多一个数量级。且由于Brakedown verifier需对每列进行哈希，认为在当前配置下，无法运行递归Brakedown。

在对Hyrax和KZG进行递归证明生成时长评估时，仅关注核心开销——MSM/pairing，并完全忽略辅助开销，如让该方案成为非交互式的。

3.2 递归Verifier计算开销

此处是指outer-verifier开销。如上所属，在递归配置下，inner verifier自身影响不大（offline sanity checks除外）——其永远不会原生运行，其计算已包含在outer-prover中。

所有电路均运行在halo2中，仅需 $< 1$ 秒的runtime。从而推断出，若运行在EVM-verifier中，其gas开销也可接受。本文不展开讨论。

3.3 递归Verifier proof size

Halo2 proof size与Halo 2电路参数紧耦合，即，与advice table中的最大行数 $k$ 呈对数关系。此外，proof size除随 $k$ 变化之外，仅在fastest prover中展示所选择的 $k$ 值，如上面“递归Prover计算开销”所述，对KZG、Hyrax和Brakedown也遵循相同的方法。

下表中数字单位为字节。
在这里插入图片描述
相关数据分析有：

当 $k = 20$ 时，对于 $n = 14$ 和 $n = 20$ ，Hyrax具有最快的verifier；当 $k = 19$ 时， $n$ 取14到20之间的中间值时，具有最快的runtime。这即粗略解释了增加 $n$ 值，并不会同步doubling proof size。
对于递归prover time，对最大的Ligero实例运行超时，可推断为brakedown也将超时。

3. 结论

选择合适的multilinear多项式承诺方案并不容易。

当实现以上方案时，发现仍有很大的代码和参数优化空间，具体取决于优化目标——是prover time还是verifier time等等。

以上benchmarks仅是开始。很多opening proof generations实例都可在Lasso中batch，而每个多项式分别进行承诺。

ZKP proof的链上验证是很有趣的应用场景，随着SNARKs的进步，将加快相关项目落地。

尽管如此，个人认为，这项技术的未来用户将是链下的，如AI judge或身份证明（proof-of-identity）：

未来不局限于小的proof size
亚秒级的验证时长可能也是不必要的；
真正的瓶颈在于Prover。

基于linear-code的multilinear多项式承诺方案在这一领域提供了良好的折衷：

其矩阵结构，具有高并行性；
选择code distance的灵活性；
像Brakedown这样的一些方案也是域不可知的：
没有FFT意味着对该域的group unit的限制更少。

如果在未来一两年内，随着理论和实现的进步，至少一个数量级的改进，并不足为奇。在那之前，还没有明确的赢家，尽管这个multilinear多项式承诺方案家族目前似乎是一个不错的选择。

4. 未来工作展望

未来工作有：

1）Zeromorph：将任意单变量方案，转换为multilinear方案。对已知的单变量方案应用Zeromorph，能否带来更好的性能？
2）BaseFold：最新的multilinear多项式承诺方案，见BaseFold: Efficient Field-Agnostic Polynomial Commitment Schemes from Foldable Codes。
3）能否为基于linear-code的multilinear多项式承诺方案，做一些修改，使其受益于“small”系数呢？
4）升级更新的电路友好的哈希函数。某些新的双倍友好的构建，致力于在native和in-circuit efficiency中做权衡。如Monolith: Circuit-Friendly Hash Functions with
New Nonlinear Layers for Fast and Constant-Time Implementations。
5）对多个多项式的batch openings进行bench，并对多个queries进行bench。
- Ligero没有同态承诺，因此对同一多项式open多个点时，可通过线性组合来实现；而对多个多项式oepn同一（或多个）点时，使用哈希并没有任何明显的捷径。这不用于基于椭圆曲线的方案。详情见From one {point,poly} to multi {point,poly} commitment schemes。
6）更多方案以及更多方案变种。