ProtoStar:通用高效IVC方案

1. 引言

前序博客有:

斯坦福大学Benedikt B¨unz 以及 Espresso团队Binyi Chen 2023年论文《Protostar: Generic Efficient Accumulation/Folding for Special-sound Protocols》。

开源代码实现见:

Nova、HyperNova及ProtoStar之间的关系为:

  • Nova:fold with error terms
  • HyperNova:fold with sumcheck
  • ProtoStar:fold the sumcheck itself

ProtoStar与HyperNova、SuperNova对比情况为:

  • ProtoStar的recursive电路中 比HyperNova 具有更少的哈希运算 以及 更少的有限域运算。
  • ProtoStar支持lookup的开销,要小于HyperNova的lookup。
    在这里插入图片描述

ProtoStar的关键特性为:

  • 1)为高效folding/accumulation schemes提供通用配方
  • 2)为expressive relations构建simple Special-sound协议
    在这里插入图片描述
  • 3)ProtoStar IVC的recursive circuit中仅需要3个group运算,支持:
    • 3.1)任意high-degree gates
    • 3.2)任意large lookup tables
    • 3.3)VM中任意数量的opcodes
      在这里插入图片描述

2. Incrementally Verifiable Computation(IVC)

IVC的目标是:证明(非确定性)递归计算的正确性。
在这里插入图片描述
IVC的应用场景有:

  • 1)Verifiable delay functions:对应 VDF ( z 0 ) = F T ( z 0 ) \text{VDF}(z_0)=F^T(z_0) VDF(z0)=FT(z0)
  • 2)Succinct blockchain(如Mina):对应 z i z_i zi为ledger state, w i w_i wi为第 i i i个区块内的交易txs。
  • 3)zkVM、zkEVM

IVC概念首次在[Valiant08]论文中指出,其Prover P F P_F PF和Verifier V F V_F VF形式为:
在这里插入图片描述
即IVC的Verifier V F V_F VF仅需接收最后一个step的输出 z m z_m zm和proof π m \pi_m πm,即可验证之前的 m m m个step的计算是否都正确。
IVC应具备如下属性:

  • 1)完备性:已知input z i − 1 z_{i-1} zi1以及相应的accepted proof π i − 1 \pi_{i-1} πi1,可为 z i = F ( z i − 1 , w i ) z_i=F(z_{i-1},w_i) zi=F(zi1,wi)生成有效proof π i \pi_i πi
  • 2)Knowledge soundness:根据final output和final IVC proof,可提取出witness(即中间值 w w w z z z)。

IVC针对的是Prove chain of computations,可将其扩展为Proof-Carrying Data(PCD)-》即Prove tree/DAG of computations。 ProtoStar可扩展为支持PCD,不过为表述方便,本文主要以IVC来陈述。

IVC的具体方案实现有:

  • 1)基于SNARKs构建的IVC方案:如[Val08, BCCT13, BCTV14, COS20]。
    在这里插入图片描述
    基于SNARKs构建的IVC方案并不实用,其主要缺点有:

    • 昂贵的recursive verifier circuit。
    • 昂贵的pairing-friendly cycles或trusted setup。
  • 2)基于Split Accumulation/Folding构建的IVC方案:如[KST21(Nova), BCLMS20(Proof-Carrying Data without Succinct Arguments)]。
    NP Relation R R R ( x , w ) ∈ R (x,w)\in R (x,w)R,其中 x x xsmall claim, w w wlarge witness。
    所谓Split Accumulation/Folding,其核心思想为:将“prove two NP instances” reduce为 ”prove a single instance“。其应具有如下属性:

    • 完备性:若 x 1 , x 2 x_1,x_2 x1,x2是satisfiable的,则 x x x也是satisfiable的。
    • knowledge soundness:若Prover知道 valid w w w,则Prover也知道 valid w 1 , w 2 w_1,w_2 w1,w2

    Split Accumulation/Folding中主要包含3个核心算法:

    • 2.1)Accumulation Prover算法——Acc.P:负责将2个instance fold为1个instance。输入为2个instance x 1 , x 2 x_1,x_2 x1,x2 以及 2个witness w 1 , w 2 w_1,w_2 w1,w2,输出为1个instance x x x 和 1个witness w w w
    • 2.2)Accumulation Verifier算法——Acc.V:负责检查folded instance是否正确。输入为2个instance x 1 , x 2 x_1,x_2 x1,x2 以及 与Acc.P交互的一些metadata信息,输出为instance x x xAccumulation Verifier算法——Acc.V 要比 SNARK.V算法 效率高很多。
    • 2.3)Accumulation Decider算法——Acc.D:负责检查 ( x , w ) ∈ R (x,w)\in R (x,w)R。输入为folded instance w w w 和 folded witness w w w。【Acc.D算法可能不是succinct的,可使用SNARK来委托Acc.D的计算。】
      在这里插入图片描述
      基于Split Accumulation/Folding构建的IVC方案:如[KST21(Nova), BCLMS20(Proof-Carrying Data without Succinct Arguments)]。其主要架构为:
      在这里插入图片描述

3. Why ProtoStar?

ProtoStar论文的主要目的是:

  • 支持zkEVM等应用。

现有的Nova方案在做zkEVM应用时,效率不够高,主要原因在于现有的Acc/Folding schemes(Nova):【其中1)和2)对于实现zkEVM应用来说是至关重要的。】

  • 1)采用R1CS约束系统:为支持degree 2 gates的传统约束系统。其缺陷为:
    • 单个gate表达性不足,如不支持high-degree 自定义gate 或 lookup gate。
    • 现有的Nova系列(如Sangria、Origami等)支持Plonk/lookup gates,但效率仍不够高。【Prover/Verifier cost与degree d d d呈线性或比例关系。】
  • 2)不支持高效的circuit branching([KS22(SuperNova)]除外):
    • 除非circuit 与 所有可能的 F F Fs(如EVM opcode 集合) 呈线性关系,否则无法在runtime时选择step F F F。EVM opcode集合中可能有数百条指令,而每个step只从中选择一个opcode来执行。
  • 3)具有不同proofs的Ad-hoc constructions:
    • 没有统一的、通用的框架。

ProtoStar的亮点为:

  • 1)实现了IVC和PCD方案的通用配方:
    • 可高效fold任意special-sound multi-round协议(Nova是ProtoStar的特例情况)
  • 2)可对highly expressive gates进行高效folding和IVC:
    • 2.1)high-degree gates + lookup + non-uniform computation:
      • 很容易扩展为支持Customizable Constraint System(CCS)[STW23]
    • 2.2)主要的IVC证明开销为:【与gate degree以及lookup table size均无关】
      • 1个size为 ∣ w ∣ |w| w的MSM运算。
      • Recursive circuit:3个group运算。

ProtoStar与HyperNova、SuperNova对比情况为:

  • ProtoStar的recursive电路中 比HyperNova 具有更少的哈希运算 以及 更少的有限域运算。
  • ProtoStar支持lookup的开销,要小于HyperNova的lookup。
    在这里插入图片描述

4. Folding/Accumulation的通用配方

目标:

  • 对NP Relation R R R instances进行fold。

遵循的流程为:

  • 1)Step 1:为relation R R R构建一个multi-round special-sound协议 Π \Pi Π。【该步骤通常很容易实现】
  • 2)Step 2:将协议 Π \Pi Π转换为non-interactive argument NARK ( Π ) \text{NARK}(\Pi) NARK(Π)。【创新之处:对NARK Verifier进行通用&高效转换,进入Step 3】
  • 3)Step 3:为 NARK ( Π ) \text{NARK}(\Pi) NARK(Π)的verifier check 构建 folding/accumulation scheme。
    在这里插入图片描述

不过仅有以上流程是不够的,否则还会有Sangria的缺陷:

  • 对于high-degree gates,Sangria Prover的复杂度高。

为此,为高效支持high-degree gates,需额外在Step 1和Step 2之间增加Step 1.a,并将Step 2和Step 3中的 Π \Pi Π 修改为 CV [ Π ] \text{CV}[\Pi] CV[Π],具体流程为:

  • 1)Step 1:为relation R R R构建一个multi-round special-sound协议 Π \Pi Π。【该步骤通常很容易实现】
  • 2)Step 1.a:将协议 Π \Pi Π转换为 对relation R R R具有 压缩且更简单Verifier 的 CV ( Π ) \text{CV}(\Pi) CV(Π)
  • 3)Step 2:将协议 CV [ Π ] \text{CV}[\Pi] CV[Π]转换为non-interactive argument NARK ( CV [ Π ] ) \text{NARK}(\text{CV}[\Pi]) NARK(CV[Π])。【创新之处:对NARK Verifier进行通用&高效转换,进入Step 3】
  • 4)Step 3:为 NARK ( CV [ Π ] ) \text{NARK}(\text{CV}[\Pi]) NARK(CV[Π])的verifier check 构建 folding/accumulation scheme。
    在这里插入图片描述

这样,即使gate degree高,对于Prover和Verifier来说,其所需做的group运算次数 均与 gate degree(或verifier equations degree)无关。

总体的通用配方为:
在这里插入图片描述

4.1 何为Special-Sound协议?

Special-Sound协议,为一种(可能具有multiple rounds的)交互式协议。
所谓special-sound,是指:

  • k k k-special-sound:根据 k k k个不同的accepting transcripts,可提取出valid witness。
  • ( k 1 , ⋅ , k u ) (k_1,\cdot,k_u) (k1,,ku)-special-soundness:针对的是multi-round协议。

举个例子:

  • 对于所有的 i ∈ [ n ] i\in [n] i[n],Prover P P P知道 a , b , c \mathbf{a,b,c} a,b,c,使得 a i ∗ b i = c i \mathbf{a}_i*\mathbf{b}_i=\mathbf{c}_i aibi=ci

相应的 1 1 1-special-sound protocol实现为:Prover将 a , b , c \mathbf{a,b,c} a,b,c都发送给Verifier,Verifier需检查 n n n个方程式,即:对于所有的 i ∈ [ n ] i\in [n] i[n] a i ∗ b i = c i \mathbf{a}_i*\mathbf{b}_i=\mathbf{c}_i aibi=ci是否都成立。
在这里插入图片描述

相应的:

  • Prover round数: R = 1 R=1 R=1,因Prover只发送了一次消息。
  • Verifier每个check方程式的最大degree: D = 2 D=2 D=2 d = 2 d=2 d=2
  • Verifier check的方程式数(或约束数): L = n L=n L=n

1 1 1-special-sound protocol易于设计的主要原因在于:

  • 无需succinct communication/verifier
  • 无需non-interactive

对于以上 R R R round交互式协议 Π \Pi Π,为将其转换为Non-Interactive Arguments:

  • 1)第一步:通过“commit-and-open”:将每轮发送(长)消息,转换为,每轮发送(短很多的vector commitment)承诺值。仅在最后一轮,发送消息承诺值的同时,附加所有轮的原始消息 m 1 , ⋯   , m R m_1,\cdots,m_R m1,,mR(即对所有轮的承诺值进行open)。Verifier在做 L L L个degree为 D D D的方程式check的同时,还需对所有承诺值做“cm-open”检查。
    即交互式协议 Π \Pi Π 转换为了 交互式committed协议 cm [ Π ] \text{cm}[\Pi] cm[Π]
    在这里插入图片描述
  • 2)第二步:通过“Fiat-Shamir”,将交互式committed协议 cm [ Π ] \text{cm}[\Pi] cm[Π] 转换为了 非交互式协议 NARK [ Π ] \text{NARK}[\Pi] NARK[Π],其中:
    • 承诺值列表 x \mathbf{x} x是small的。
    • 每轮消息列表 w \mathbf{w} w通常是big的。
    • Verifier最终需:
      • (通常借助哈希函数)来生成random challenge r 1 , ⋯   , r R − 1 r_1,\cdots,r_{R-1} r1,,rR1
      • 对所有承诺值做“cm-open”检查
      • L L L个degree为 D D D的方程式check
        在这里插入图片描述
  • 3)第三步:对非交互式协议 NARK [ Π ] \text{NARK}[\Pi] NARK[Π]的 Verifier checks 做Folding/Acc,其中:【为简化,忽略了public input】
    • 借助slack u u u,每个 A C C ACC ACC的check方程式 均具有相同的degree d d d
    • 不同于NARK Verifier每个check方程式右侧均为0, A C C ACC ACC的check方程式右侧可以为relaxed error e ⃗ \vec{e} e 。error vector e ⃗ \vec{e} e 的承诺值为 E E E
      在这里插入图片描述
      接下来是要将 A C C ACC ACC π \pi π fold,获得新的 A C C ACC ACC
      在这里插入图片描述
      在这里插入图片描述
      在这里插入图片描述
      但是,以上folding scheme对于high-degree是效率低下的,原因在于:
    • 为计算承诺值 E j \mathbf{E}_j Ej,Prover需做 O ( d L ) O(dL) O(dL)次group运算。当 d d d很大是,该计算是昂贵的。
    • 为fold C i \mathbf{C}_i Ci以及 E \mathbf{E} E,Verifier需做 O ( d ) O(d) O(d)次group运算。当 d d d很大是,该计算是昂贵的。
  • 4)第四步:因第三步实现的folding scheme对high-degree是效率低下的,需对High-degree gates的verification checks进行压缩。
    • 4.1)针对Prover端计算瓶颈:
      在这里插入图片描述
      • a)思路一:将 L L L个verifier equation checks reduce为 单个equation check,这样就相当于将 L L L压缩为1,从而可直接使用trivial identity commitment,而无需做任何group运算。
        但是这样做存在2个问题:
        • gate degree(即合并后的方程式degree)更高了,为: d + L d+L d+L
        • 合并后的方程式的 L L L个单项具有不同的degree,不再具备同态性,无法再进行fold。
          在这里插入图片描述
    • b)思路二:额外增加一轮,针对用于合并方程式的random challenge β \beta β,Prover发送所有 β i \beta^i βi的承诺值 [ B i = β i ] i = 1.. L [B_i=\beta^i]_{i=1..L} [Bi=βi]i=1..L,对此,Verifier仅需检查 B i + 1 = B i ⋅ β B_{i+1}=B_i\cdot \beta Bi+1=Biβ。通过将Verifier check方程式中的 β \beta β替换为 承诺值 [ B j ] [B_j] [Bj],从而将Verifier check方程式 的:【不过这回增加Acc Prover的计算开销,其需要额外多对 O ( L ) O(L) O(L)个项进行承诺。而 L L L通常很大,这个开销也很大。】
      • degree 由 “思路一中的 d + L d+L d+L” 降为 “ d + 1 d+1 d+1”,
      • 且,所有单项具有相同的degree,具备同态属性,从而可复用之前的folding思想。
        在这里插入图片描述
    • c)思路三:为解决思路二中Acc Prover需对 O ( L ) O(L) O(L)项做承诺的计算开销问题,在思路二的基础之上,Verifier check方程式中额外再引入一个变量 [ B j ′ ] [B_j'] [Bj],使得Verifier check方程式中的degree由 “思路二中的 ( d + 1 ) (d+1) (d+1)” 变为 ( d + 2 ) (d+2) (d+2)
      • 将Acc Prover的 “对 O ( L ) O(L) O(L)项做承诺的计算开销问题” reduce为 “对 O ( L ) O(\sqrt{L}) O(L )项做承诺的计算开销问题”——即Acc Prover仅需要额外做 O ( L ) O(\sqrt{L}) O(L )次group运算 来 commit m R + 1 m_{R+1} mR+1
      • 需对 { B j , B j ′ } \{B_j, B_j'\} { Bj,Bj}进行check。即Acc Chks需额外增加: O ( L ) O(\sqrt{L}) O(L )次degree-2 check,以检查所有 { B j , B j ′ } \{B_j, B_j'\} { Bj,Bj}的正确性。————》》可对 “这些 O ( L ) O(\sqrt{L}) O(L )个degree-2 check” reduce为 “单个方程式”。为此,有 d − 1 d-1 d1个cross error terms,对应每项都为单个域元素;对中间项可进行承诺,对应的承诺值为一个group元素,也与degree无关。
        为此,需额外引入一个对size为 O ( L ) O(\sqrt{L}) O(L )的error vector进行承诺的独立运算。
      • Acc Verifier的开销为:为fold C i \mathbf{C}_i Ci E \mathbf{E} E,需要 R + 2 R+2 R+2次group运算。【对于lookup来说,没有额外开销】
        在这里插入图片描述

5. 如何为expressive relation构建高效的special-sound协议?

至此,Folding/Accumulation的通用配方为:
在这里插入图片描述
接下来,需要解决的是“如何为expressive 约束系统构建 Π s p s \Pi_{sps} Πsps”。

5.1 对algebraic约束构建 Π s p s \Pi_{sps} Πsps

expressive algebraic约束有:

  • 1)permutation relation/high-degree gate-check relation
  • 2)Non-uniform circuit selection relation
    在这里插入图片描述
  • 3)Customizable constraint system(CCS)[STW23]

对于这些algebraic约束,可直接构建1-move special-sound协议:

  • Prover发送witness,Verifier check这些algebraic 方程式。
    即对应“Step 1:为relation R R R构建一个multi-round special-sound协议 Π \Pi Π。【该步骤通常很容易实现】”。

在这里插入图片描述

5.2 对非algebraic约束构建 Π s p s \Pi_{sps} Πsps

expressive non-algebraic约束有:

  • lookup

[Hab22(Multivariate lookups based on logarithmic derivatives)]的lookup argument思路为:
在这里插入图片描述
对应构建的special-sound协议为:
在这里插入图片描述

5.3 ProtoStar(和CCS)的special-sound协议

在这里插入图片描述

参考资料

[1] Binyi Chen 2023年7月在PSE分享视频 Deep dive into Protostar paper & protocol - Binyi Chen
相应slide:zkStudyClub - ProtoStar (Binyi Chen & Benedikt Bünz, Espresso Systems)
[2] Binyi Chen 2023年7月在zkStudyClub分享视频 zkStudyClub - ProtoStar (Binyi Chen & Benedikt Bünz, Espresso Systems)
[3] 2023年6月episode Episode 280: ProtoStar with Benedikt Bünz and Binyi Chen
[4] Ariel Gabizon 2023年5月twitter recent history of folding
[5] Benedikt Bünz 2023年5月twitter 官宣ProtoStar论文

Nova系列博客

猜你喜欢

转载自blog.csdn.net/mutourend/article/details/132309031
今日推荐