RISC Zero STARK证明系统时序图及规范

1. 引言

前序博客：

• RISC Zero zkVM 白皮书
• RISC Zero的手撕STARK

RISC Zero证明系统核心是基于STARK的，实现的是DEEP-ALI和FRI。从高层来看，RISC Zero的prover设计与ethSTARK Documentation – Version 1.2 和 https://github.com/facebook/winterfell 非常相似。

RISC Zero证明系统代码见：

• https://github.com/risc0/risc0/blob/main/risc0/zkp/src/prove/prover.rs（Rust）

2. Setup Phase

RISC Zero协议中包含2个setup phase：

• 1）第一个setup phase 为Circuit Setup：针对每个zkVM版本，做一次setup。
• 2）第二个setup phase 为Program Setup：针对每个RISC-V二进制可执行文件，做一次setup，用于构建Image ID。

2.1 Circuit Setup

Circuit Setup是透明的，用于给Prover和Verifier构建公共参数。这些公共参数包括：

• trace columns数量和长度
• 所选择的哈希函数和Merkle化结构
• 枚举所有要强化的约束

2.2 Program Setup

Program Setup用于构建Image ID。Image ID，由RISC-V二进制可执行文件 和 Circuit Setup所构建的公共参数，共同透明确定。
Image ID的生成方式为：

• 1）将RISC-V二进制可执行文件加载进zkVM内存
• 2）记录整个机器状态的Merkle snapshot。
• 3）将该Merkle root用作Image ID。

为确认该Image ID的正确性，任何可访问该RISC-V二进制可执行文件的人，都可重复运行该Program Setup。

3. Main Trace和Auxiliary Trace

Setup phase之后，Prover会：

• 1）在zkVM中执行该二进制可执行文件
• 2）计算每列的Low-Degree Extension
• 3）对Extended Main Execution Trace进行commit

然后基于Verifier提供的随机值，Prover会再：

• 4）计算并commit Extended Auxiliary Execution Trace。

相比于ethSTARK Documentation – Version 1.2 ，RISC Zero额外增加了一轮交互，以支持出基础AIR约束之外的其它约束。然后使用ethSTARK Documentation – Version 1.2中的DEEP-ALI和FRI来处理Main Trace和Auxiliary Trace上的约束。添加Auxiliary Execution Trace，可实现与Vanilla STARK协议相关的各种增强功能。具体的增强功能见：

• From AIRs to RAPs - how PLONK-style arithmetization works

RISC Zero使用Auxiliary Execution Trace来支持：

• 1）对memory verification 的permutation argument。
  • 当前的permutation argument实现为PlONK中的grand product accumulator argument。
  • 计划后续替换为log derivative accumulator argument。
  • permutation argument中：
    • 对应内存的操作，按原始顺序和permuted顺序，在Main Trace中commit；
    • grand product accumulator则在Auxiliary Trace中commit。
• 2）对范围检查的lookup argument。
  • 当前的lookup argument实现为PLOOKUP。
  • 计划后续替换为log derivative accumulator argument。
  • lookup argument中：
    • tables和witness在Main Trace中commit；
    • grand product accumulator则在Auxiliary Trace中commit。
• 3）支持快速密码学运算的大整数accelerator。bigint accelerator对大整数$a,b$乘法的实现为：
  • 请求host提供乘积$c$，作为非确定性advice。
  • Verifier提供随机值$r$。
  • 将$a,b,c$解析为多项式，强化约束：$a(r)\ast b(r)==c(r)$。
  • bigint accelerator中：
    • $a,b,c$在Main Trace中commit；
    • $a,b,c$在$r$处的evaluations值，则在Auxiliary Trace中commit。

3. DEEP-ALI和FRI

RISC Zero的 DEEP-ALI和FRI 实现 与 ethSTARK Documentation – Version 1.2 中一致。详情也可参看RISC Zero zkVM 白皮书。

4. RISC Zero STARK证明系统时序图

4.1 Extended Main Execution Trace

RISC Zero Prover执行guest程序可执行二进制文件，生成Main Execution Trace。
Main Execution Trace是按列排布的。具有的列类型有：

• 1）control列：用于：
  • 系统初始化和关机。
  • 在执行之间，加载初始程序代码到内存。
  • 与程序执行无关的其它控制信号。
• 2）data列：包含了输入和计算数据，二者均是private的。data列按2种排序进行commit：
  • 按程序执行顺序后，进行commit
  • 先按寄存器排序，然后再按clock cycle排序后，进行commit。这样重排后的列，支持高效验证RISC-V内存操作。
• 3）auxiliary/accum列：用于permutation argument、lookup argument以及bigint accelerator电路。

在完成data列 和 auxiliary/accum列 计算之后，Prover会在这些列的末端，添加一些随机噪声，以让该协议是zero-knowledge的。

在完成Main Execution Trace计算，并添加完必要的噪声之后，Prover会对Main Execution Trace进行编码：

• 1）使用iNTT，将每列转换为一个多项式，这些列的多项式为Trace Polynomials，以$P_i(x)$来表示。
• 2）基于扩展域，对data列多项式和control列多项式进行evaluate。将这些基于更大域的evaluations值，称为Extended Main Execution Trace。
• 3）将Extended Main Execution Trace 承诺为2棵不同的Merkle Trees，将这2个Merkle Roots发送给Verifier。

4.2 Extended Auxiliary Execution Trace

对于Verifier所发送的“用于permutation argument、lookup argument和bigint accelerator中的多个随机扩域元素”，实际是使用SHA-2 CRNG，以transcript-thus-far为熵源，来生成这些随机扩域元素。

然后Prover：

• 使用这些随机扩域元素，来生成auxiliary/accum列
• 计算auxiliary/accum列的Low-Degree Extension，来构建Extended Auxiliary Execution Trace。
• 将Extended Auxiliary Execution Trace 承诺为一棵Merkle Tree，并将相应的Merkle Root发送给Verifier。

4.3 DEEP-ALI（Part 1）

对于Verifier所发送的“随机约束混合参数$\alpha$”，实际是使用SHA-2 CRNG，以transcript-thus-far为熵源，来生成该随机值。

在DEEP-ALI（Part 1）中，Prover使用：

• 1）随机约束混合参数$\alpha$：为公开的
• 2）Trace Polynomials：为private的。以$P_i$表示。
• 3）Rule Checking Polynomials：为公开已知的。假设有$k$个rule checking polynomials，表示为$R_0,R_1,\cdots ,R_{k-1}$。
• 4）Zeros Polynomial：为公开已知的。以$Z(x)$表示。

来构建一些Low Degree Validity Polynomials（LDVP），具体的细节流程为：

• 1）Prover，根据$k$个公开已知的Rule Checking Polynomials $R_0,R_1,\cdots ,R_{k-1}$，从private Trace Polynomials的角度，生成$k$个 Constraint Polynomials $C_0(x),C_1(x),\cdots ,C_{k-1}(x)$。
  • 这些Constraint Polynomials 的关键点在于，对于这$k$个rule中的每一个规则和所关联trace的每个输入$z$，若该trace “pass the test”，则有$C_j(z)=0$。
• 2）使用“随机约束混合参数$\alpha$”，Prover将$k$个 Constraint Polynomials ，合并为一个 Mixed Constraint Polynomial $C$，有$C(x)={\alpha }^0{C}_0(x)+\cdots +{\alpha }^{k-1}{C}_{k-1}(x)$。
  • 注意，若在某point $z$，每个$C_j$均返回$0$值，则有$C(z)=0$。
• 3）Prover，使用公开已知的Zeros Polynomial $Z(x)$，来计算High Degree Validity Polynomial $V(x)=\frac{C(x)}{Z(x)}$。
  • Zeros Polynomial $Z(x)$，为任意诚实构建的$C(x)$，的divisor。换句话说，诚实Prover构建的$V(x)$，为具有比$C(x)$具有更低degree的多项式。
  • 称“V(x)”是“high degree”，是相对Trace Polynomials $P_i$而言的。
• 4）Prover，将High Degree Validity Polynomial $V(x)$，切分为4个 Low Degree Validity Polynomials $v_0(x),v_1(x),v_2(x),v_3(x)$。
• 5）Prover，对Low Degree Validity Polynomials进行evaluate，并将其编码为一棵Merkle Tree，将相应的Merkle Root发送给Verifier。
• 6）使用Fiat-Shamir来选择out-of-domain evaluation point $z$。将$z$称为“DEEP Test Point”。

4.4 DEEP-ALI（Part 2）

接下来，Verifier想要验证$C,Z,V$在“DEEP Test Point” $z$处所声称的关系，即确认$V(z)Z(z)=C(z)$：

• 1）Prover发送每个Low Degree Validity Polynomial $v_i$ 在 $z$ 处 的evaluation值，使得Verifier可据此计算出$V(z)$。
• 2）计算$C(z)$要更复杂点。因“rule checks”可检查跨多列和跨多个clock cycles的关系，为evaluate $C(z)$，需要许多形如$P_i(w^{n}z)$的不同的evaluations值，其中$i$表示第几列，$n$表示第几个cycle。Prover发送每个$P_i$的“necessary evaluations”给Verifier，使得Verifier可计算出$C(z)$。
  • RISC Zero中，将"necessary evaluations $P_i(w^{n}z)$"，称为$P_i$在$z$处的“taps”。
• 3）现在Verifier可检查$V(z)Z(z)=C(z)$。
• 4）尽管这些asserted evaluations没有相关的Merkle分支，但DEEP技术提供了一种替代常规Merkle proof的方法。

目前为止，Prover给Verifier发送的taps $P_i(w^{n}z)$ 和 $v_i(z)$值，均没有相关的Merkle分支，无法提供Merkle proof。Prover需借助DEEP技术来证明其发送taps的正确性，为此Prover需使用这些taps来构建DEEP Polynomials：

• 将$P_i$在$z$处的taps，表示为$((x_1,P_i(x_1)),\cdots ,(x_n,P_i(x_n)))$，Prover构建的DEEP Polynomial为$P_i^{\prime }(x)=\frac{P_i(x)-{\bar{P}}_i(x)}{(x-x_1)\cdots (x-x_n)}$，其中${\bar{P}}_i(x)$为对$P_i$ taps 插值而来的多项式。
  使用相同的DEEP技术，对每个$P_i$和每个$v_i$，各自构建一个DEEP Polynomial，并发送每个DEEP Polynomial系数给Verifier。

至此，trace validity的claim，就reduce为：

• 对每个$P_i$和每个$v_i$的DEEP Polynomials事实上均为low-degree polynomial，的claim了。

Verifier所发送的“用于FRI batching的随机扩域元素”，实际是“DEEP混合参数”，Prover使用该参数，将这些DEEP Polynomials混合为一个 FRI Polynomial，然后使用FRI协议来证明该FRI Polynomial是一个low-degree polynomial即可。

4.5 FRI协议

FRI（Fast, Reed-Solomon Interactive Oracle Proof of Proximity）协议，为RISC Zero计算完整性证明系统的最后一环。
RISC Zero证明系统中FRI协议的实现见：

• https://github.com/risc0/risc0/blob/main/risc0/zkp/src/prove/fri.rs（Rust）

FRI协议中包含了一系列commit和query交互：

• 1）每次commit时，Prover会对，对应具有lower-degree polynomial evaluations的，新的（smaller）Merkle Tree进行commit。逐轮的承诺值依赖于一个随机混合参数，该随机混合参数支持在后续的query轮做audit-trail。
  • 在每个commit轮中，RISC Zero的实现为：FRI Polynomial degree和关联的Merkle tree size，均以$16$倍减少。
  • RISC Zero会运行commit轮，知道FRI Polynomial的degree小于等于255。
• 2）每次query时，Prover会公开每个FRI承诺值的Merkle 分支（和叶子节点）。使用Fiat-Shamir Heuristic来选择query轮中要公开的分支。
  • 不同的query轮个数，提供了安全级别和计算效率之间的权衡取舍。

【
在FRI协议公布不久，就发现了DEEP-FRI协议。早期认为DEEP-FRI协议改进了FRI协议的可靠性。但Proximity Gaps for Reed-Solomon Codes论文中指出，原始的FRI协议，具有与DEEP-FRI相同的可靠性，且计算复杂度还要更低。因此RISC Zero证明系统选择使用原始的FRI协议。
】

参考资料

[1] Proof System Sequence Diagram and Spec
[2] About the FRI Protocol

RISC Zero系列博客

• RISC0：Towards a Unified Compilation Framework for Zero Knowledge
• Risc Zero ZKVM：zk-STARKs + RISC-V
• 2023年 ZK Hack以及ZK Summit 9 亮点记
• RISC Zero zkVM 白皮书
• Risc0：使用Continunations来证明任意EVM交易
• Zeth：首个Type 0 zkEVM
• RISC Zero项目简介
• RISC Zero zkVM性能指标
• Continuations：扩展RISC Zero zkVM支持（无限）大计算
• A summary on the FRI low degree test前2页导读
• Reed-Solomon Codes及其与RISC Zero zkVM的关系
• RISC Zero zkVM架构
• RISC-V与RISC Zero zkVM的关系
• 有限域的Fast Multiplication和Modular Reduction算法实现
• RISC Zero的Bonsai证明服务
• RISC Zero ZKP协议中的商多项式
• FRI的Commit、Query以及FRI Batching内部机制
• RISC Zero的手撕STARK
• RISC Zero zkVM guest程序优化技巧 及其 与物理CPU的关键差异
• ZK*FM：RISC Zero zkVM的形式化验证
• Zirgen MLIR：RISC-Zero的ZK-circuits形式化验证
• 以RISC Zero ZK Fraud Proof赋能Optimistic Rollups
• zkSummit10 亮点记
• 技术探秘：在RISC Zero中验证FHE——由隐藏到证明：FHE验证的ZK路径（1）
• 技术探秘：在RISC Zero中验证FHE——RISC Zero应用的DevOps（2）