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

1. 引言

前序博客：

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) * 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^0C_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^nz)$ 的不同的evaluations值，其中 $i$ 表示第几列， $n$ 表示第几个cycle。Prover发送每个 $P_i$ 的“necessary evaluations”给Verifier，使得Verifier可计算出 $C (z)$ 。
- RISC Zero中，将"necessary evaluations $P_i(w^nz)$ "，称为 $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^nz)$ 和 $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'(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