1. 引言
相关论文见:
- Srinath Setty(微软研究中心)、Justin Thaler(a16z密码学研究中心以及Georgetown University)、Riad Wahby(Carnegie Mellon University)2023年论文《Unlocking the lookup singularity with Lasso》
- Arasu Arun(New York University)、Srinath Setty(微软研究中心)、Justin Thaler(a16z密码学研究中心以及Georgetown University)2023年论文《Jolt: SNARKs for Virtual Machines via Lookups》
相应的开源代码实现见:
本文主要关注:
- 1)何为SNARKs?
- 2)lookup argument定义
- 3)新的lookup argument——Lasso族:
- Basic-Lasso lookup argument
- Lasso lookup argument
- Generalized-Lasso lookup argument
- 4)新的前端技术——Jolt(全称为Just One Lookup Table):完全就Lasso构建
2. 何为SNARKs?
所谓SNARKs,是指:
- Prover P P P声称其知道满足某些属性的witness w w w:
- 如:某密码学哈希函数 h h h的输出结果 y y y对应的preimage w w w,即知道 w w w使得 h ( w ) = y h(w)=y h(w)=y。
- Trivial Proof为:Prover P P P直接将witness w w w发送给Verifier V V V,Verifier V V V直接检查其是否满足所声称的属性。
- SNARK(Succinct Non-interactive ARgument of Knowledge)可实现相同的效果,但Verifier V V V的计算开销要更低:
- 所谓“succinct”,是指:SNARK proof π \pi π必须比witness w w w要短。
- 检查 π \pi π 要比 “直接检查 w w w” 要快得多——从而节约了Verifier V V V的计算开销。
2.1 SNARK设计细节——通用SNARKs:标准范式
以高级编程语言(如C、Java等)编写的计算机程序 ψ \psi ψ,仍以之前的哈希函数为例:
- 程序 ψ \psi ψ:以 w w w为输入,执行 h h h函数,检查输出是否等于 y y 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 P P的首个消息为 某多项式 h h h,所谓Polynomial-IOP,是指:
- Verifier V V V不需要知道整个多项式 h h h。从而可减轻Verifier V V V的负担,因为描述多项式 h h h所需的size 与 circuit一样大。
- 支持Verifier V V V evaluate h h h at one point。
- 然后,Prover P P P 和 Verifier V V V 之间执行标准的交互式证明。
2.3.2 何为多项式承诺方案?
多项式承诺方案 用于将 “某Polynomial-IOP” 转换为 “某succinct argument”。
Polynomial-IOP的主要问题在于,其并不会直接给出succinct argument,因为其输出与多项式本身一样大。
多项式承诺方案,使得:
- Prover P P P可对多项式做密码学承诺,相应的承诺值很小,类似一个哈希值或group元素等。
- 任意多项式承诺方案应具有binding属性。
多项式承诺方案的核心思想为:
- Prover P P P发送short string C o m ( h ) Com(h) Com(h),来将自身与多项式 h h h绑定。
- Verifier V V V 选择 x x x,并请求Prover P P P evaluate h ( x ) h(x) h(x)。
- Prover P P P发送 y y y(声称 y = h ( x ) y=h(x) y=h(x))以及proof π \pi π(即 y y y值与 C o m ( h ) Com(h) Com(h)以及 x x x一致)。
多项式承诺方案应:
- 对于不正确的evaluation,Prover P P P无法声称convincing proof。
- C o m ( h ) Com(h) Com(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 P P非常慢。现有的基于IOPs+hashing的多项式承诺方案有:
- DARK
- Dew
2.4 现在的SNARK性能
前序博客有:
SNARK Verifier V V V通常是cheap的:
- 相比于trivial proof system,其计算量要小很多。trivial proof system中Verifier V V V需直接使用 w w w验证有效性。
- 不同的SNARK方案开销各不相同:
- Plonk proof:在以太坊上验证Plonk proof约需要20万gas。
- STARK proof:取决于安全级别,约需要1000万gas。
SNARK Prover P P P通常是昂贵的:
- 相比于 直接使用 w w w验证有效性,SNARK Prover P P P的计算量要大约60到80倍。【至少要慢100万倍。】
- Prover P P P的计算开销可并行化。
- 但百万或千万级的减缓仍是制约因素。
SNARK Prover P P P的开销主要分为2大部分:
- 1)前端开销:是指,相比于直接做witness-checking,前端需用多长时间来evaluate the circuit output?
- 3)后端开销:是指,相比于直接基于 w w w对circuit进行evaluate,后端需用多长时间来为“该circuit is satisfied by w w w” 生成a SNARK proof?
以上SNARK Prover P P P的前端开销和后端开销 均至少需放大1000倍,使得SNARK Prover P P P的总体开销至少放大100万倍。
SNARK Prover P P P的瓶颈通常在 多项式承诺方案,但不总在 多项式承诺方案。
2.4.1 MSM——基于multi-exponentiation的承诺方案
对于Multiplicative group,对size为 n n n的multi-exponentiation的计算形式为:
∏ i = 1 n g i x i \prod_{i=1}^{n}g_i^{x_i} ∏i=1ngixi
对于Additive group,相应计算也称为MSM(multi-scalar-multiplication)。
当前流行的基于MSM的多项式承诺方案有:
- KZG
- IPA/Bulletproofs
- PST
- Hyrax
- Dory
若naive直接做MSM计算,需要:
- n n n次group exponentiation运算 + n n n次group multiplication运算。
- 每个group exponentiation运算 要比 每个group multiplication运算 慢约400倍。
若使用Pippenger算法来做MSM计算,相比于直接计算,可节约约 log n \log n logn倍开销:
- 实际性能能提升超过10倍。
若所有exponents(即 x i x_i xi)均为“small”,则可以再额外节约10倍的开销,即:
- 类似于,计算 g i 2 16 g_i^{2^{16}} gi216 要比 计算 g i 2 160 g_i^{2^{160}} gi2160 快10倍。即 1 6 2 16^2 162 vs. 160 160 160。
- 若所有exponents(即 x i x_i xi)最大值为 K K K,且 n > > K n>>K n>>K,则Pippenger算法对于每个committed field element仅需要一次group multiplication运算。【即意味着此时,Pippenger算法比naive算法要快约400倍。当对small field elements承诺时,相应的MSM计算要比常规MSM计算快得多。】【Lasso中会利用这种small K K K带来的优势。】
3. Lookup Arguments:支持SNARK前端生成更小的电路
以range proof为例:
- Prover P P P想要证明某程序执行过程中没有任何整数值超过 2 128 2^{128} 2128,从而避免溢出错误情况。
3.1 range proof的naive方案
naive方案为:在circuit-SAT instance中实现:
- 将程序执行过程中的每个数字 x x x的128 bit field elements 作为 电路的“non-deterministic advice”。
- 若Prover P P P是诚实的,则这128个 field elements应设置为 x x x的二进制表示。
- 该电路中必须check:
- 所有的这128个advice elements b 0 , ⋯ , b 127 b_0,\cdots, b_{127} b0,⋯,b127的取值在 { 0 , 1 } \{0,1\} { 0,1}中。
- 所有的这128个advice elements 确实对应为 x x x的二进制表示,即:
x = ∑ i = 0 127 2 i b i x=\sum_{i=0}^{127}2^ib_i x=∑i=01272ibi
- naive方案是非常昂贵的:
- 一个简单的溢出检查,会在Prover P P P的witness中额外引入128个field elements——这些额外引入的field elements需由Prover P P P进行cryptographically commit。
3.2 range proof的lookup argument方案
Lookup argument提供了比以上naive更好的解决方案:
- 假设Prover和Verifier在某个时刻初始化了某lookup table,其中包含了由 0 0 0到 2 128 − 1 2^{128}-1 2128−1之间的所有整数。
- 然后,range check等价为确认每个 x x x值在该lookup table内,使得range check 成为 single table lookup。
仍然以range check为例,相应的lookup argument定义为:
- 1)令 t = ( 0 , 1 , 2 , 3 , ⋯ , 2 128 − 1 ) t=(0,1,2,3,\cdots,2^{128}-1) t=(0,1,2,3,⋯,2128−1)为具有 N N N个table元素的向量。
- 2)令 a ∈ F m a\in\mathbf{F}^m a∈Fm为一组应包含在上述table的值列表。
- 3)Verifier V V V已知: a a a的承诺值 c m a cm_a cma。
- 4)Prover P P P声称: a a a中所有元素均在table t t t中。
即Prover P P P声称其知道 c m a cm_a cma的opening a a a,使得:- 对于每个 i = 0 , ⋯ , m − 1 i=0,\cdots, m-1 i=0,⋯,m−1,存在 j ∈ { 0 , 1 , ⋯ , N − 1 } j\in\{0,1,\cdots, N-1\} j∈{ 0,1,⋯,N−1},使得 a i = t j a_i=t_j ai=tj。
- 5)通常将这种lookup argument称为unindexed lookup argument。
而indexed lookup argument是指待证明元素中还附加了索引值,indexed lookup argument定义为:
- 1)令 t ∈ F n t\in\mathbf{F}^n t∈Fn为具有 N N N个table元素的向量。
- 2)Prover P P P对向量 ( ( a 1 , b 1 ) , ⋯ , ( a m , b m ) ) ((a_1,b_1),\cdots,(a_m,b_m)) ((a1,b1),⋯,(am,bm))进行承诺。
- 3)Prover P P P声称,对于 i = 1 , ⋯ , m i=1,\cdots,m i=1,⋯,m,有 a i = t [ b i ] a_i=t[b_i] ai=t[bi]。【即 a i a_i ai为value, b i b_i bi对应为table t t t的索引号,Prover P P P声称 a a a中所有元素均存在于 t t t中相应的index。】
3.3 现有lookup argument的Prover开销
当对size为 N N N的table做 m m m次查找时,之前的lookup argument的Prover P P P需对很多field elements进行commit:
- 1)Arya[2018]:需对至少 m + 2 N log m m+2N\log m m+2Nlogm个field elements进行commit。
- 2)Plookup[2020]:需对至少 5 ∗ max { m , N } 5*\max\{m,N\} 5∗max{ m,N}个field elements进行commit。
- 3)HyperPlonk[2023]:需对至少 4 ∗ max { m , N } 4*\max\{m,N\} 4∗max{ m,N}个field elements进行commit。
同时,在以上lookup argument中,为避免Verifier维护整个size为 N N N的table,在预处理阶段,某honest party还必须对整个size为 N N N的table 进行commit。
-
4)Caulk[2022]、Caulk+、flookup、Baloo、cq(cached quotients)将以上Prover P P P中与 N N N呈比例的开销 推送到了 预处理阶段:
- 均需要size为 N N N的SRS。【若table size为 2 25 2^{25} 225,则SRS将达数GB。】
- 在预处理阶段需做 O ( N log N ) O(N\log N) O(NlogN)次group exponentiation运算。
这样预处理之后,cq具有最好的性能:
- cq 的Prover P P P仅需对 8 m 8m 8m个field elements进行commit,并做 O ( m log m ) O(m\log m) O(mlogm)次filed 运算(采用FFT)。【Prover P P P开销与table size N N 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 P P 需对 min { m + N , 2 m + O ( N ) } \min\{m+N, 2m+O(N)\} min{
m+N,2m+O(N)} 个field elements进行commit。
- Up to low-order terms。
- All are small:
- They are in { 0 , ⋯ , m } \{0,\cdots, m\} {
0,⋯,m}。这些均为multiplicity(即只对table中每个元素被访问的次数进行排序):
- 最多有 m / k m/k m/k个值大于 k k k。
- 最多有 m m m个非零值。而零值 cost “nothing”(因为对零值进行commit没有开销)。
- 警告:需要一个polynomial evaluation proof——对应的Prover开销将随着 N N N呈增长(对于某些多项式承诺方案,Prover开销将随着 N N N呈sublinearly增长,也有一些摊销策略)。
- They are in { 0 , ⋯ , m } \{0,\cdots, m\} {
0,⋯,m}。这些均为multiplicity(即只对table中每个元素被访问的次数进行排序):
- 若lookup table是LDE-structured,则不需要对该lookup table进行承诺。
- 除非使用基于KZG的承诺方案,否则无需排序,也无需SRS。
Basic-Lasso与Plookup和cq的性能对比情况为:
- 1)Plookup:
- 1.1)Prover P P P 对至少 5 ∗ max { m , N } 5*\max\{m,N\} 5∗max{ m,N}个field elements进行commit。其中 3 ∗ max { m , N } 3*\max\{m,N\} 3∗max{ m,N}个committed field elements是随机的。
- 1.2)+ 需对lookup table进行commit。
- 1.3)Prover P P P 必须对lookups进行排序(或至少需“group(分类)”),并做FFT运算。
- 2)cq:
- 2.1)经预处理之后,Prover P P P仅需对 8 m 8m 8m个field elements进行commit。其中 7 m 7m 7m个committed field elements是随机的。
- 2.2)若lookup 次数 m m m远小于 N N N,则推荐使用cq:【或者,使用bit-decomposition方案有可能会更好】
- 若可接受cq的预处理,以及size为 N N N的SRS。
- Due to avoiding O ( N ) O(N) O(N) terms。
- 2.3)若lookup 次数 m m m不是远小于 N N N的场景,则Basic-Lasso的Prover P P P 要比cq快约30倍:
- 2.3.1)3倍的加速源于更少的committed field elements。
- 2.3.2)另外10倍的加速源于small field elements。
- 若对looked-up value向量 a a a的commit计时,则10倍加速依赖于table elements是small的。
- 若 a a a中包含 m m m个任意field elements,则10倍加速 将降为 2.5倍加速。
- 2.3.3)此外,cq的Prover P P P需做FFT运算。
3.4.2 Lasso
Lasso中具有整数参数 c > 0 c>0 c>0:
- 可用于“ c c c-decomposable tables”。
- 对size为 N N N的table做单次lookup,可分解为 对size为 N 1 / c N^{1/c} N1/c的table做 c c c次lookup。
- Prover P P P最多需对 3 c m + c N 1 / c 3cm+cN^{1/c} 3cm+cN1/c个filed elements进行commit:
- All are small。
- 若lookup table是LDE-structured,则无需对该lookup table进行commit。
- 当 c = 1 c=1 c=1时,Basic-Lasso为Lasso的特例情况。
举个具备decomposability的例子:对 ( 0 , 1 , 2 , 3 , ⋯ , 2 128 − 1 ) (0,1,2,3,\cdots,2^{128}-1) (0,1,2,3,⋯,2128−1)做range proof:
- Lasso的Prover P P P会将element x x x切分为在 c c c个limbs中做range-check,每个limb包含 128 / c 128/c 128/c bits。
- 如有8个limbs l 1 , ⋯ , l 8 l_1,\cdots,l_8 l1,⋯,l8,每个limb有16 bits。
- Lasso的Verifier V V V需确认每个provided limb均在small range t = ( 0 , 1 , 2 , 3 , ⋯ , 2 16 − 1 ) t=(0,1,2,3,\cdots,2^{16}-1) t=(0,1,2,3,⋯,216−1)且 x = ∑ i = 1 8 2 16 ( i − 1 ) ⋅ l i x=\sum_{i=1}^{8}2^{16(i-1)}\cdot l_i x=∑i=18216(i−1)⋅li。
- 该例子已在Arya[BCGJM 2018]中详述。
- 相应的small table 是LDE-structured的:
- t ( r 1 , ⋯ , r 16 ) = ∑ i = 1 16 2 i − 1 ⋅ r i t(r_1,\cdots,r_{16})=\sum_{i=1}^{16}2^{i-1}\cdot r_i t(r1,⋯,r16)=∑i=1162i−1⋅ri
3.4.3 Generalized-Lasso
不同于Lasso,Generalized-Lasso不要求其lookup table是decomposable的:
- Generalized-Lasso只要求其lookup table是“LDE-structured”。
- 与Lasso一样,Prover P P P具有相同的承诺开销:需对 3 c m + c N 1 / c 3cm+cN^{1/c} 3cm+cN1/c个filed elements进行commit。
- 但是有 c m cm cm个committed field elements不是small的。【因此推荐用Lasso而不是Generalized-Lasso。】
- “LDE-structured” 意味着 关联某lookup table的某特定多项式需可在 O ( log N ) O(\log N) O(logN) time内完成evaluate。
4. 解锁新的SNARK前端技术:Jolt(Just One Lookup Table)
以VM execution应用场景为例:
Prover P P P声称其运行了某特定计算机程序共 m m 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 f f有2个64-bit输入,则相应的lookup table中会存储每个64-bit inputs ( x , y ) (x,y) (x,y) pair的 f ( x , y ) f(x,y) f(x,y):
- 该lookup table size为 2 128 2^{128} 2128。
- Jolt 显示所有的RISC-V指令是decomposable的。
4.1 Jolt开销
对于支持64-bit数据类型(具有“multiply extension”)的RISC-V指令,相应的Jolt开销为:
- 对于每个RISC-V CPU step,Jolt Prover P P P需对约50个filed elements进行commit。
- 这50个field elements中的7个field element 值小于 2 25 2^{25} 225。
- 这50个field elements均不大于 2 64 2^{64} 264。
- 借助基于MSM的多项式承诺,每个CPU step Jolt Prover P P P的开销约为:
- 对5个任意field elements(256-bit)的commit开销。
附加说明:可通过多个“伪指令”来处理2个RISC-V指令:
如,带余数除法运算:
- Prover P P 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 P P的开销约为:
- 对5个任意field elements(256-bit)的commit开销。
- 2)Plonk:对于arithmetic circuit中的每个gate,Plonk Prover P P 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 P P的开销为:
- 至少对275个 31-bit field elements进行commit。约等价为对 275 8 ≈ 35 \frac{275}{8}\approx35 8275≈35个(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 P P需对超过50个field elements 进行commit。
- StarkWare当前采用某251-bit field。
- 对于Cairo VM的每个step,StarkWare Prover P P P需对超过50个(256-bit)field elements 进行commit。
- 要求所采用的field的characteristic至少应为 2 63 2^{63} 263。【因为其采用 0 ∼ 2 63 0\sim 2^{63} 0∼263来表示Cairo CPU内的指令。】
- 因此,对于每个CPU step,至少需对 50 4 ≈ 13 \frac{50}{4}\approx 13 450≈13个(256-bit)field elements进行commit。
5. 当前进展
相应的开源代码实现见:
https://github.com/a16z/Lasso代码库中:
- 当前只实现了Basic-Lasso。
- 当前采用arkworks曲线库以及msm实现。
- 预计经工程优化后,Basic-Lasso的速度可再提升2倍。
- 对Basic-Lasso的并行化正在实现中。
- 对于具有random field elements的table,Basic-Lasso的速度要比,包含 { 0 , 1 , ⋯ , 2 24 } \{0,1,\cdots,2^{24}\} {
0,1,⋯,224} 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 P P 对至少 5 ∗ max { m , N } 5*\max\{m,N\} 5∗max{ m,N}个field elements进行commit。其中 3 ∗ max { m , N } 3*\max\{m,N\} 3∗max{ m,N}个committed field elements是随机的。
- + 需对lookup table进行commit。
- 2)Basic-Lasso的Prover P P P需对 m + N m+N 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
Justin Thaler系列博客
- SNARK Design
- Rollup项目的SNARK景观
- SNARK原理示例
- SNARK性能及安全——Prover篇
- SNARK性能及安全——Verifier篇
- sum-check protocol in zkproof
- sum-check protocol深入研究
lookup系列博客
- PLOOKUP
- PLOOKUP代码解析
- Efficient polynomial commitment schemes for multiple points and polynomials学习笔记
- PLONK + PLOOKUP
- PlonKup: Reconciling PlonK with plookup
- PLONK: permutations over lagrange-bases for oecumenical noninteractive arguments of knowledge 学习笔记
- Plonk代码解析
- RapidUp: Multi-Domain Permutation Protocol for Lookup Tables学习笔记
- Lookup argument总览
- Halo2 学习笔记——设计之Proving system之Lookup argument(1)
- 多变量lookup argument
- cq:fast lookup argument
- Lookup Argument性能优化——Caulk
- 2023年 ZK Hack以及ZK Summit 亮点记
- Research Day 2023:Succinct ZKP最新进展