ProtoStar：通用高效IVC方案

mutourend

已于 2023-08-16 23:21:59 修改

阅读量788

点赞数 1

分类专栏：零知识证明文章标签：零知识证明

于 2023-08-15 23:10:38 首次发布

本文链接：https://blog.csdn.net/mutourend/article/details/132309031

版权

零知识证明专栏收录该内容

349 篇文章

订阅专栏

1. 引言

前序博客有：

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

开源代码实现见：

https://github.com/han0110/plonkish（Rust。实现了HyperPlonk、Sangria、ProtoStar等。）

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：对应 $\text{VDF}(z_0)=F^T(z_0)$
2）Succinct blockchain（如Mina）：对应 $z_i$ 为ledger state， $w_i$ 为第 $i$ 个区块内的交易txs。
3）zkVM、zkEVM

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

1）完备性：已知input $z_{i-1}$ 以及相应的accepted proof $\pi_{i-1}$ ，可为 $z_i=F(z_{i-1},w_i)$ 生成有效proof $\pi_i$ 。
2）Knowledge soundness：根据final output和final IVC proof，可提取出witness（即中间值 $w$ 和 $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$ ： $(x,w)\in R$ ，其中 $x$ 为small claim， $w$ 为large witness。
所谓Split Accumulation/Folding，其核心思想为：将“prove two NP instances” reduce为 ”prove a single instance“。其应具有如下属性：
- 完备性：若 $x_1,x_2$ 是satisfiable的，则 $x$ 也是satisfiable的。
- knowledge soundness：若Prover知道 valid $w$ ，则Prover也知道 valid $w_1,w_2$ 。
Split Accumulation/Folding中主要包含3个核心算法：
- 2.1）Accumulation Prover算法——Acc.P：负责将2个instance fold为1个instance。输入为2个instance $x_1,x_2$ 以及 2个witness $w_1,w_2$ ，输出为1个instance $x$ 和 1个witness $w$ 。
- 2.2）Accumulation Verifier算法——Acc.V：负责检查folded instance是否正确。输入为2个instance $x_1,x_2$ 以及与Acc.P交互的一些metadata信息，输出为instance $x$ 。Accumulation Verifier算法——Acc.V 要比 SNARK.V算法效率高很多。
- 2.3）Accumulation Decider算法——Acc.D：负责检查 $(x,w)\in R$ 。输入为folded instance $w$ 和 folded witness $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$ 呈线性或比例关系。】
2）不支持高效的circuit branching（[KS22（SuperNova）]除外）：
- 除非circuit 与所有可能的 $F$ s（如EVM opcode 集合）呈线性关系，否则无法在runtime时选择step $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 ∣$ 的MSM运算。
  - Recursive circuit：3个group运算。

ProtoStar与HyperNova、SuperNova对比情况为：

ProtoStar的recursive电路中比HyperNova 具有更少的哈希运算以及更少的有限域运算。
ProtoStar支持lookup的开销，要小于HyperNova的lookup。

4. Folding/Accumulation的通用配方

目标：

对NP Relation $R$ instances进行fold。

遵循的流程为：

1）Step 1：为relation $R$ 构建一个multi-round special-sound协议 $\Pi$ 。【该步骤通常很容易实现】
2）Step 2：将协议 $\Pi$ 转换为non-interactive argument $\text{NARK}(\Pi)$ 。【创新之处：对NARK Verifier进行通用&高效转换，进入Step 3】
3）Step 3：为 $\text{NARK}(\Pi)$ 的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$ 修改为 $\text{CV}[\Pi]$ ，具体流程为：

1）Step 1：为relation $R$ 构建一个multi-round special-sound协议 $\Pi$ 。【该步骤通常很容易实现】
2）Step 1.a：将协议 $\Pi$ 转换为对relation $R$ 具有压缩且更简单Verifier 的 $\text{CV}(\Pi)$ 。
3）Step 2：将协议 $\text{CV}[\Pi]$ 转换为non-interactive argument $\text{NARK}(\text{CV}[\Pi])$ 。【创新之处：对NARK Verifier进行通用&高效转换，进入Step 3】
4）Step 3：为 $\text{NARK}(\text{CV}[\Pi])$ 的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$ -special-sound：根据 $k$ 个不同的accepting transcripts，可提取出valid witness。
$(k_1,\cdot,k_u)$ -special-soundness：针对的是multi-round协议。

举个例子：

对于所有的 $i\in [n]$ ，Prover $P$ 知道 $\mathbf{a,b,c}$ ，使得 $\mathbf{a}_i*\mathbf{b}_i=\mathbf{c}_i$ 。

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

相应的：

Prover round数： $R = 1$ ，因Prover只发送了一次消息。
Verifier每个check方程式的最大degree： $D = 2$ 或 $d = 2$
Verifier check的方程式数（或约束数）： $L = n$

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

无需succinct communication/verifier
无需non-interactive

对于以上 $R$ round交互式协议 $\Pi$ ，为将其转换为Non-Interactive Arguments：

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