1. 引言

RISC Zero提供了开源的虚拟机+零知识证明系统，即zero-knowledge virtual machine（简称zkVM）。当在zkVM中执行某RISC-V二进制文件时，其输出为：

• 二进制文件执行结果
• ＋ 一个computational receipt，提供了计算完整性的零知识证明。

RISC Zero的证明系统采用zk-STARK，基于以下关键要素：

• FRI协议
• DEEP-ALI
• 基于HMAC-SHA-256的PRF

1.1 可验证计算

可验证计算的时代即将到来：我们现在生活在这样一个世界里，分布式系统中不受信任方的行为 可 使用计算完整性的证明 快速轻松地被验证为值得信任的。这项技术是零知识密码学和交互式证明领域几十年来不断进步的结果。数年来，在现实世界的应用程序中实现 可验证计算 已经变得实用和有影响力。最初的应用表明，零知识证明是确保区块链隐私的有力工具，该技术已经发展到了计算完整性的证明，并成为数字世界的关键基础设施的地步。我们预计，可验证计算不仅是区块链扩容问题的答案，也是解决推特机器人和垃圾电话等问题的答案。在一个信任越来越稀缺的世界里，可验证计算提供了一条前进的道路。

成千上万的开发人员渴望开始编写可验证的软件。但目前用于编写可验证软件的系统要求开发人员学习具有各种限制和挑战的全新语言。为了使Rust和C++等语言的可验证软件开发成为可能，RISC Zero建立了一种机制来证明任意RISC-V计算的完整性。

1.2 可验证RISC-V

当在RISC Zero zkVM中执行某RISC-V二进制文件时，输出结果的同时还会输出一个computational receipt。该receipt中包含了：

• 一个密码学seal，作为计算完整性的零知识证明。

通过对可编译为RISC-V的任意代码提供密码学seal，RISC Zero zkVM提供了一个构建真正可信任软件的平台，将信将疑的第三方可在数毫秒内验证其代码执行结果的真实性。
“running a verifier” 以确保大规模计算的完整性的想法是数字安全世界的一个新颖补充。

实际RISC Zero的receipt由3大部分组成：

• Image ID：为SHA of the executable code，执行代码的哈希值。
• Seal：为Proof that an executable code was run，证明代码已运行。
• Journal：为计算结果。
  

1.3 形式化可验证的Verifier

形式化验证是将代码转换为模型的过程，该模型可以通过数学工具进行推理，以确保与安全性和正确性相关的属性。形式化验证用于确保一段代码确实在做它应该做的事情。为了确保RISC Zero verifier（检查receipts）在没有安全漏洞的情况下运行，RISC Zero团队正在对其verifier实现进行形式化验证。具体见：

• https://www.github.com/risc0/risc0-lean4（Lean+Rust）

1.4 RISC Zero证明系统

RISC Zero zkVM：

• 证明系统基于Eli Ben-Sasson等人2018年论文 Scalable, transparent, and post-quantum secure computational integrity
• RISC Zero receipt的seal为a zk-STARK
• 算术化方案为具有预处理的randomized AIR，具体见Aztec 2021年的From AIRs to RAPs - how PLONK-style arithmetization works。
• 随机化预处理构造了：
  • PLONK-based memory permutation argument的约束
  • PLOOKUP-based range-check的约束
• 预处理完之后，STARK实例化使用了：
  • DEEP-ALI协议：见Eli Ben-Sasson等人2019年论文DEEP-FRI: Sampling Outside the Box Improves Soundness
  • FRI协议：见Eli Ben-Sasson等人2017年论文Fast Reed-Solomon Interactive Oracle Proofs of Proximity

2. 核心思想以及背景知识

RISC Zero receipt背后的证明系统是基于execution trace和一些约束来强化计算完整性checks的。
核心思想为：

• An assertion of computational integrity can be viewed as an assertion that an execution trace satisfies a set of constraints.

2.1 execution trace的列

当一段代码在机器上运行时，execution trace（或简称trace），记录了该计算在每个clock cycle（时钟周期）的机器完整状态。通常将execution trace写成长方形数组，每一行对应机器在某特定时刻的完整状态，每一列展示了该计算的某些特定方面（如存储在特定RISC-V寄存器中的值）在每个时钟周期的当时记录。
RISC Zero的execution trace列主要分为：

• 1）控制列——公开的：控制列中的数据描述了RISC-V架构，多种控制信号定义了执行阶段，进而定义了应用什么约束。【在源代码中，将控制列称为“Code”列】
• 2）数据列——私有的：数据列中的数据表示了处理器和内存的运行状态。为高效检查RISC-V内存操作的完整性，与RISC-V内存操作关联的每个寄存器都有2个关联列：
  • 一列表示原始的执行顺序；
  • 一列表示按内存位置排序，然后按时钟周期排序后的结果。
• 3）Accumulator列——私有的：RISC Zero使用accumulators来，对基于PLONK的permutation check 以及 基于PLOOKUP的range check，的grand-product constraints进行实例化。Accumulator列中包含了关联的累加数据，Accumulator列中的元素，及其关联约束，在随机化预处理阶段就已构建。

2.2 通过约束强化计算完整性

对计算完整性的断言，可重塑为，对“某execution trace满足特定约束集”的断言。这些约束强化了：

• zkVM执行RISC-V ISA一致。
• 每个约束都是对特定约束值的low-degree多项式关系。
• execution trace有效，当且仅当每个约束evaluates to 0。

示例一：约束$(k)(k-1)=0$强化了$k$要么为0，要么为1。
示例二：约束$j-2k=0$强化了$j=2k$。

在实际实现时，为强化RISC-V指令集架构的计算完整性，包含了数千约束，每个约束都表示为某多变量多项式（其输入可能包含多个（之前）时钟周期的寄存器值）。
从上层来看，约束强制要求zkVM操作的以下每个阶段都按要求执行：

• 1）Init初始化阶段：将所有寄存器值初始化为0。
• 2）Setup阶段：准备加载ELF文件。
• 3）Load阶段：加载RISC-V二进制文件到内存。
• 4）Reset阶段：结束加载阶段，并准备执行。
• 5）Body阶段：主要执行阶段。该阶段执行用户自定义代码。
• 6）RamFini阶段：为memory permutation（PLONK）生成bytes-based grand product accumulation值。
• 7）BytesFini阶段：为PLOOKUP生成bytes-based grand product accumulation值。

这些约束加在一起，强制要求计算声称的输出与预期的rv32im（The RISC-V Instruction Set Manual Volume I: Unprivileged ISA）执行一致。

2.3 Arguments 和 Proofs of Knowledge

RISC Zero receipt中的seal为a STARK——a scalable, transparent argument of knowledge。

An argument of knowledge支持Prover证明某“assertion of knowledge”的正确性。更正式的说话是，Prover断言其知道某witness $\mathbf{w}$满足某些约束$\mathbf{x}$。当用于对计算完整性的断言时，execution trace为witness，约束为各种定义计算完整性的规则。

在3.3节，将展示Interactive Oracle Proof（IOP）协议（(BCS16)Interactive Oracle Proofs）。IOPs中包含了Prover与Verifier之间的一系列交互，整个协议中Prover的消息依赖于Verifier在各个节点提供的随机值。IOP协议为理论模型，事实上，zkVM使用非交互版本的IOP协议，其中Verifier的参与通过Fiat-Shamir transform替换为了HMAC-SHA-256。
在IOP协议上下文中，seal组成了a proof of knowledge。在代码中，proof变成了argument——原因在于，argument依赖于HMAC-SHA-256作为random oracle的安全性，而proof无密码学安全假设。更准确来说，seal是a STARK。Fiat-Shamir Heuristic使得可基于IOP协议的soundness分析来派生出STARK的安全性。

3. RISC Zero IOP协议

本章将展示交互版本的RISC Zero写意思，并在IOP模型上下文中分析该协议的knowledge soundness。

3.1 IOP协议概述

在交互式oracle proof中，Prover 通过一系列交互使 将信将疑的Verifier 信服 某断言。在每一轮，Prover基于双方已知的某domain 对一个或多个函数的evaluations进行commit。Verifier可能不会读取完整的Prover messages，而是query这些Prover messages。IOP模型使用oracle access的概念将这些query理想化。该理论模型，可在不指向任何密码学原语的情况下，证明本协议的soundness。
RISC Zero receipt中的seal，为交互式协议中的transcript，并以某random oracle作为verifier。当zkVM完成某方法的执行之后，相应的结果seal就用作计算完整性的zero-knowledge proof，将某密码学imageID（用于表示所执行的RISC-V二进制文件） 关联到 所断言的代码输出，这样使得第三方可快速验证。

本协议包含了：

• 1）透明的set-up阶段：构建对Prover和Verifier双方已知的特定协议参数，包括trace列数量和长度，以及所能强化的约束的完整枚举。
• 2）随机化预处理阶段：
• 3）Main主阶段

3.1.1 Set-up阶段

每个程序仅需要做一次Set-up阶段，生成的公共参数可用于生成任意数量的execution proofs。这些公共参数包括：

• 电路说明
• 对zkVM的约束
• 待执行程序的密码学标识符
• 处理哈希、DEEP-ALI、FRI的各种参数

这些参数要么通过可信通道分发给Provers和Verifiers，要么可根据程序定义（如，源代码）独立计算。
“transparency透明”属性，是指：

• 具备，仅使用公共信息，就可独立重计算出公共参数，的能力。

3.1.2 随机化预处理阶段

set-up完毕之后，Prover运行程序，生成控制列和数据列，然后开始随机化预处理。
随机化预处理，会构建memory accumulators和bytes accumulators。
在随机化预处理阶段，Prover会发送2个trace承诺值：

• 1个对控制列的承诺值
• 1个对数据列的承诺值

为生成trace承诺值，会使用Reed-Solomon编码将trace列，编码为，trace blocks，然后将trace blocks承诺到Merkle trees。

以${\mathbf{w}}_{control}$和${\mathbf{w}}_{data}$来表示witnesses，以$Com({\mathbf{w}}_{control})$ 和 $Com({\mathbf{x}}_{control})$ 来表示相应的承诺值。在完成对${\mathbf{w}}_{control}$和${\mathbf{w}}_{data}$这2个承诺之后，Prover使用verifier-randomness 来构建 accum blocks，并发送第3个承诺值$Com({\mathbf{w}}_{accum})$，以支持permutation argument和lookup argument。【由于reveal了每棵树的许多分支，RISC Zero commit Merkle caps，而不是Merkle roots，详情见附录B 以及 Alessandro Chiesa等人2021年论文 Subquadratic SNARGs in the Random Oracle Model】

3.1.3 Main主阶段

Main主阶段中包含了：

• 一个标准的AIR-FRI协议，使用DEEP-ALI（见Eli Ben-Sasson等人2019年论文DEEP-FRI: Sampling Outside the Box Improves Soundness）
• batched FRI协议（见 Eli Ben-Sasson等人2021年论文 Proximity Gaps for Reed-Solomon Codes），与StarkWare和 Polygon Zero的Plonky2方案类似：
  • StarkWare团队的2023年 ethSTARK文档
  • Polygon Zero团队的2022年 Plonky2: Fast Recursive Arguments with PLONK and FRI

Main主阶段的基本流程为：

• Prover使用约束和execution trace来生成validity多项式$f_{validity}$，使用$f_{validity}$来构建validity witness ${\mathbf{w}}_{validity}$，并发送$Com({\mathbf{w}}_{validity})$给Verifier。* Verifier响应随机值$z\in {\mathbb{F}}_q$。
• Prover evaluate $f_{validity}$ at $z$，并使用DEEP quotienting技术来构建DEEPAnswerSequence。

3.2 IOP定义

回想下 (BCS16)Interactive Oracle Proofs 中的interactive oracle proof。在IOP模式下下，本协议满足 Eli Ben-Sasson等人2018年论文 Scalable, transparent, and post-quantum secure computational integrity 的STIK定义。【STIK和STARK之间缩写词的区别在于用“IOP”代替了“ARgument”。】

借鉴StarkWare团队的2023年 (Sat21) ethSTARK文档第5张的AIR定义和符号，以及，Aztec 2021年的From AIRs to RAPs - how PLONK-style arithmetization works的借助预处理对AIR随机化的概念，RISC Zero的IOP证明了Prover知道某witness满足某RAP（Randomized AIR with Preprocessing）实例，具体定义为：
$A_{RAP}=(\mathbb{F},\mathbb{K},e,{\mathbf{w}}_{RAP},{\mathbf{n}}_{{\sigma }_{mem}},{\mathbf{n}}_{{\sigma }_{bytes}},h,d,s,w,\beta ,I,C_{set})$
其中：

• $\mathbb{F}={\mathbb{F}}_{2^{31}-2^{27}+1}$，名为Baby Bear field。
• $\mathbb{K}$为degree $e=4$ extension of $\mathbb{F}$。
• ${\mathbf{w}}_{RAP}$为RAP witness的列数量，有${\mathbf{w}}_{RAP}={\mathbf{w}}_{control}+{\mathbf{w}}_{data}+{\mathbf{w}}_{accum}$，其中：
  • ${\mathbf{w}}_{control}$为control控制列数量
  • ${\mathbf{w}}_{data}$为data数据量数量
  • ${\mathbf{w}}_{accum}=2e\cdot {\mathbf{n}}_{{\sigma }_{mem}}+2e\cdot {\mathbf{n}}_{{\sigma }_{bytes}}$为随机化预处理阶段中生成的accumulator列数量。
• ${\mathbf{n}}_{{\sigma }_{mem}}$：表示由${\text{trace}}_{time}$到${\text{trace}}_{mem}$ permutation的witness中的重复数据列的数量。
• ${\mathbf{n}}_{{\sigma }_{mem}}$：表示PLOOKUP实现中bytes-lookup的witness中的重复列的数量。
• $2^h$：表示trace domain $H$的size（即列的长度）。
• $d$：表示rule-checking多项式的最大degree。
• $w\in \mathbb{F}$：具有multiplicative order $e\cdot 2^h$，且$\beta \in \mathbb{F}$为非零值。
  • 定义commitment domain $D$为coset $\beta D_0$，其中$D_0\in {\mathbb{F}}_p$由$w$生成。
  • 定义trace domain $H$为由$w^{\frac{1}{\rho }}$生成的集合，其中$\rho$的定义见下面。
• $I$为tapset索引集合。【tap是指trace中的一个元素，约束表示为多个taps的函数。详情见附录A.5.2。注意在ethSTARK用mask术语，而本文使用tapset术语。】
• $s$：为RAP约束的数量。

除了以上列出的RAP instance输入之外，IOP还使用如下辅助输入，表示为$\text{aux}=(D,k,{\text{aux}}_{FRI})$，其中：

• $D$为zk commitment domain（ethSTARK中称其为evaluation domain），其为multiplicative subgroup $D_0$的non-trivial coset，其中$H\subseteq D_0\subseteq \mathbb{F}$。【若直接将$D_0$作为commitment domain将引入除零问题，同时意味着query将泄漏execution trace信息问题。而coset $D$与$D_0$不相交，从而可实现zero-knowledge目的。】
• $2^k$为zk commitment domain $D$的size。将IOP rate定义为$\rho =\frac{2^h}{2^k}$
• ${\text{aux}}_{FRI}$定义为$(\vec{\mathbf{t}},{\mathbf{n}}_{queries},{\mathbf{d}}_{final})$，其中：
  • $\vec{\mathbf{t}}=(t_1,\cdots ,t_r)$为描述COMMIT阶段每轮FRI-folding factor的向量。RISC Zero系统中，对于所有的$i$，有$t_i=16$。
  • ${\mathbf{n}}_{queries}=50$，为FRI query次数。
  • ${\mathbf{d}}_{final}=256$，为结束FRI算法的degree。

3.3 IOP协议说明

透明set-up之后，IOP包含了3个元素：

• 随机化预处理步骤
• DEEP-ALI子协议
• Batched FRI子协议

3.3.1 随机化预处理步骤

随机化预处理步骤的流程为：

• 1）Prover：生成IOP witness ${\mathbf{w}}_{control}\cup {\mathbf{w}}_{data}$，并发送承诺值$Com({\mathbf{w}}_{control})$和$Com({\mathbf{w}}_{data})$。【该步骤详情见附录C.1】
• 2）Verifier：samples $\mathbb{K}$中的${\mathbf{n}}_{\sigma }={\mathbf{n}}_{{\sigma }_{mem}}+{\mathbf{n}}_{{\sigma }_{bytes}}$个元素，这些随机数会用于生成Accumulator列。
• 3）Prover：生成witness ${\mathbf{w}}_{accum}$，并发送$Com({\mathbf{w}}_{accum})$。

${\mathbf{w}}_{RAP}={\mathbf{w}}_{control}\cup {\mathbf{w}}_{data}\cup {\mathbf{w}}_{accum}$为witness，满足如下RAP instance：
$A_{RAP}=(\mathbb{F},\mathbb{K},e,{\mathbf{w}}_{RAP},{\mathbf{n}}_{{\sigma }_{mem}},{\mathbf{n}}_{{\sigma }_{bytes}},h,d,s,w,\beta ,I,C_{set})$

与 (Sat21) ethSTARK文档、Eli Ben-Sasson等人2019年论文DEEP-FRI: Sampling Outside the Box Improves Soundness、Eli Ben-Sasson等人2017年论文Fast Reed-Solomon Interactive Oracle Proofs of Proximity，类似，本协议剩余部分为：【不同之处在于，与Plonky2和[Hab22] A summary on the FRI low degree test中一样，使用单个verifier随机值来做constraint batching，以及，用单个verifier随机值来做FRI batching。】

• 使用辅助IOP参数$\text{aux}=(D,k,{\text{aux}}_{FRI})$来实现DEEP-ALI和Batched FRI。

3.3.2 DEEP-ALI子协议

DEEP-ALI子协议的流程为：

• 4）Verifier：samples ${\alpha }_{constraints}\in \mathbb{K}$，该随机值用于DEEP-ALI constraint batching。【ethSTARK对每个约束sample了2个随机参数，而RISC Zero本协议中使用了单个随机参数。详情见[Hab22] A summary on the FRI low degree test中的affine batching vs. parametric batching。】
• 5）Prover：生成${\mathbf{w}}_{validity}$，并生成$Com({\mathbf{w}}_{validity})$。这可看做是对$f_{validity}$的承诺值，$f_{validity}$定义为：
  $f_{validity}(x)=\frac{{\sum }_{i=0}^{|C_{set}|-1}{\alpha }_{constraints}^i\cdot C_i(P_0(x),\cdots ,P_{{\mathbf{w}}_{RAP}-1})}{Z(x)}$
  其中：
  • $P_j$为对${\mathbf{w}}_{RAP}$列的插值，$C_i$为约束，$Z$为vanish在trace domain $H$的最小多项式。【在RISC Zero源代码中，$f_{validity}$中称为CheckPoly。为构建$Com({\mathbf{w}}_{validity})$，Prover会将$f_{validity}$切分为4个low-degree validity多项式。本步骤详情见附录C.5.2。】
• 6）Verifier：samples $z\in \mathbb{K}\setminus (H\cup D)$，作为random evaluation point，用于DEEP-ALI的query。
• 7）Prover：使用$z,{\mathbf{w}}_{RAP},{\mathbf{w}}_{validity}$来构建${\mathbf{w}}_{batchedFRI}$。不过不为${\mathbf{w}}_{batchedFRI}$构建Merkle commitment，RISC Zero的Prover会给Verifier发送足够的信息来重现${\mathbf{w}}_{batchedFRI}$的asserted values。所谓足够的信息，也称为DEEPAnswerSequence，其包含了：
  • （7.a）${\mathbf{w}}_{RAP}$在DEEP query point $z$的所有tapset。
  • （7.b）${\mathbf{w}}_{validity}$在DEEP query point $z$的evaluation。
  • （7.c）对tapset逐列插值的系数。【在Rust源代码中，将这些系数称为$u$。每个trace列有一个$u$多项式，使用该列的taps。详情见附录C.5.5。】

3.3.3 Batched FRI子协议

• 8）Verifier：samples ${\alpha }_{FRI}\in \mathbb{K}$，该随机值用于FRI batching。
• 9）Prover和Verifier：借助辅助信息${\text{aux}}_{FRI}$应用FRI来check proximity to the code $\text{RS}[\mathbb{K},D,\rho ]$ of the function:
  $f_{FRI}(x)={\sum }_{i=0}^{{\mathbf{w}}_{RAP}+3}{\alpha }_{FRI}^i\cdot d_i(x)$
  其中$d_i$：为附录C.5.5中定义的DEEP多项式。
  该步骤中还包含几个来自Prover的额外承诺值：
  • one for batching，一种用于batching。
  • one for each commit round of FRI，一种用于FRI每个commit round。

3.3.4 验证

Receipt验证包含如下逻辑检查。若这些检查失败，则Verifier拒绝该receipt：

• 1. Verifier使用taps，$C_{set}$和${\alpha }_{constraints}$来计算$f_{validity}(z)$并检查其与seal中声称的$f_{validity}(z)$是否匹配。
• 2. Verifier检查DEEPAnswerSequence的内部一致性，使用声称的逐列插值 来 重计算 声称的tapset。
• 3. 对于每个FRI query $j$，Verifier使用$u$系数和${\alpha }_{FRI}$来计算$f_{FRI}(j)$，并检查其与seal中声称的$f_{FRI}(j)$是否匹配。
• 4. Verifier检查每个FRI query的内部，具体见附录C.6。

3.4 IOP模式的soundness分析

本文使用 Eli Ben-Sasson等人2019年论文DEEP-FRI: Sampling Outside the Box Improves Soundness 和 Eli Ben-Sasson等人2021年论文 Proximity Gaps for Reed-Solomon Codes 的结论来分析本IOP协议的soundness。使用Fiat-Shamir Heuristic将本IOP分析 转换为 非交互式协议的结论，使用HMAC-SHA-256来实例化random oracle。

本文的soundness分析遵循(Sat21) ethSTARK文档，不同之处在于：

• 随机化预处理：本协议以ethSTARK中未模拟的随机化预处理为起始步骤。随机化预处理 为PLONK-based permutation check和PLOOKUP-based range check实例化约束。使用Schwartz-Zippel Lemma来限定soundness error上线。

• Constraint batching：DEEP-ALI包含了压缩所有约束为当个“Combined Constraint”的步骤。RISC Zero采用[Hab22] A summary on the FRI low degree test中的方案，使用的是单个随机域元素的幂，而ethSTARK中使用的是一组域元素。RISC Zero采用的是 Eli Ben-Sasson等人2021年论文 Proximity Gaps for Reed-Solomon Codes 中的parametric batching技术，而ethSTARK选择的是affine batching技术。

• FRI batching：“batched FRI protocol”也是先用verifier随机数来压缩多个FRI instances为单个instance。同样，RISC Zero采用的是parametric batching技术，而ethSTARK采用的是affine batching技术。

• 对${\mathbf{w}}_{validity}$的degree reduction：ethSTARK 和 Eli Ben-Sasson等人2018年论文 Scalable, transparent, and post-quantum secure computational integrity 的构建会生成a pair of FRI assertions：

  • 一个对应trace $({\mathbf{w}}_{control}\cup {\mathbf{w}}_{data}\cup {\mathbf{w}}_{accum})$
  • 一个对应“validity多项式”。

  与[Hab22] A summary on the FRI low degree test类似，RISC Zero将validity多项式切分为4个low-degree validity多项式，从而可将其压缩为单个FRI assertion。【“split”切分函数与FRI commit rounds中的一样。详情见附录A.2.3。】${\mathbf{w}}_{validity}$的每个leaf包含这4个low-degree validity多项式的evaluation值。[Hab22] A summary on the FRI low degree test中将这样的切分技术称为“segment polynomials”。

总之，RISC Zero IOP协议的soundness上限为：
${ϵ}_{IOP}\le {ϵ}_{PLONK}+{ϵ}_{LOOKUP}+{ϵ}_{DEE{P}_{A}LI}+{ϵ}_{FRI}$
其中：${ϵ}_{PLONK},{ϵ}_{LOOKUP},{ϵ}_{DEE{P}_{A}LI},{ϵ}_{FRI}$分别为本协议PLONK argument、PLOOKUP argument、DEEP-ALI子协议、FRI子协议的soundness上限。

3.4.1 soundness分析用标记

用$\theta$来表示FRI low-degree test中的proximity参数，本节分析限定在list-decoding radius为$\theta <1-\sqrt{\rho }$，conjectured code capacity为$\theta <1-\rho$。这些soundness结论的证明遵循 Eli Ben-Sasson等人2021年论文 Proximity Gaps for Reed-Solomon Codes 中的定理1.5和8.3，以及 Eli Ben-Sasson等人2019年论文DEEP-FRI: Sampling Outside the Box Improves Soundness中的定理6.2。conjectured security遵循 Eli Ben-Sasson等人2021年论文 Proximity Gaps for Reed-Solomon Codes 中的Conjecture 8.4，以及 Eli Ben-Sasson等人2019年论文DEEP-FRI: Sampling Outside the Box Improves Soundness中的Conjecture 2.3。具体定理和Conjecture见附录D。

在后续章节中：

• $L$和$m$源自Guruswami-Sudan list-decoding算法
• $\theta =1-\rho \cdot (1+\frac{1}{2m})$，与[Hab22] A summary on the FRI low degree test一样。
• 其它变量定义见3.2节。

推荐：

• 为了解DEEP-ALI和FRI的error上限，推荐阅读[Hab22] A summary on the FRI low degree test 和 (Sat21) ethSTARK文档。
• 为了解permutation argument的error上限，推荐阅读 Plonky2: Fast Recursive Arguments with PLONK and FRI。

3.4.2 PLONK和PLOOKUP的error上限

随机化预处理阶段为2个grand-product arguments实例化了accumulators和约束。无论哪个，简单应用Schwartz-Zippel Lemma，可生成soundness error上限。

其中：

• 一个accumulator用于证明memory integrity内存完整性。对应的error上限为$\frac{e\cdot {\mathbf{n}}_{{\sigma }_{mem}}\cdot 2^h}{|\mathbb{K}|}$。
• 另一个accumulator用于证明tap完整性。对应的error上限为$\frac{e\cdot {\mathbf{n}}_{{\sigma }_{bytes}}\cdot 2^h}{|\mathbb{K}|}$。

3.4.3 DEEP-ALI的error上限

在RISC Zero的DEEP-ALI实现中，Verifier samples了单个随机值${\alpha }_{constraints}$来合并约束，然后将$z\in \mathbb{K}\setminus (H\cup D)$用作DEEP query。每个随机samplings都有一个关联的error term。
${ϵ}_{DEEP-ALI}={ϵ}_{ALI}+{ϵ}_{DEEP}$
其中：

• ${ϵ}_{ALI}$：对应为合并约束的soundness error。
• ${ϵ}_{DEEP}$：对应为DEEP query point的soundness error。

不同于ethSTARK，RISC Zero使用单个随机值的幂来合并约束。其实现与[Hab22] A summary on the FRI low degree test 与一致，不同之处在于将${ϵ}_{DEEP}$的分子由$d$改成了$d-1$，即，RISC Zero的DEEP-ALI的error上限为：
$ϵ=\frac{s\cdot L}{\mathbb{K}}$
$ϵ=\frac{L\cdot (d-1)((k+1)+(k-1))}{|\mathbb{K}|-|H|-|D|}$

3.4.4 FRI的error上限

本节在list-decoding体制下的FRI soundness结论，主要遵循 Eli Ben-Sasson等人2021年论文 Proximity Gaps for Reed-Solomon Codes 中的定理1.5和8.3。如之前所提及，本节RISC Zero的FRI soundness结论不同于 Eli Ben-Sasson等人2021年论文 Proximity Gaps for Reed-Solomon Codes 和 ethSTARK，因为RISC Zero采用单个随机域元素的幂来做FRI batching。为此，RISC Zero的FRI soundness结论 对标的是 [Hab22] A summary on the FRI low degree test （其中batch size为${\mathbf{w}}_{RAP}+d+1$）。
即RISC Zero的FRI soundness error上限为：
${ϵ}_{FRI}=(({\mathbf{w}}_{RAP}+d-1)-\frac{1}{2})\cdot \frac{(m+\frac{1}{2}{)}^7}{3{\sqrt{\rho }}^3}\cdot \frac{|D{|}^2}{|\mathbb{K}|}+\frac{(2m+1)\cdot (|D|+1)\cdot {\sum }_{i=1}^r{t}_i}{\sqrt{\rho }\cdot |\mathbb{K}|}+(1-\theta {)}^{{\mathbf{n}}_{queries}}$

参考资料

[1] RISC Zero zkVM白皮书-2023.8.11版 RISC Zero zkVM: Scalable, Transparent Arguments of RISC-V Integrity
[2] RISC Zero团队2023年3月在ETHDenver上的分享视频 If Knowledge is Power, What is Zero Knowledge? An Intro to zkVMs with Eric

RISC Zero系列博客

• RISC0：Towards a Unified Compilation Framework for Zero Knowledge
• Risc zero ZKVM：zk-STARKs + RISC-V
• 2023年 ZK Hack以及ZK Summit 亮点记