1. 引言

StarkWare的Recursive STARKs 为首个在以太坊主网上线的，针对通用计算的recursive stark proof方案：

递归证明目前已在以太坊主网上线：
- 扩容StarkEx app
- 扩容StarkNet
- 用于StarkWare的SaaS scaling engine
- 用于permissionless rollup
节约了gas开销并降低延迟（同时实现开销节约和延迟降低这2点，而不是在二者间取舍平衡）
为未来L3做准备：向StarkNet提交证明，因以Cairo语言编写的Recursive Verifier statement 可作为StarkNet的一个智能合约。详细可参看L3 deployments on top of the public StarkNet。即将L3的单个聚合证明提交到L2上验证，从而实现超级扩容。

借助递归证明，当前STARK可将数万个甚至数十万笔交易“roll up”为单个证明，提交到以太坊上。

1.1 Cairo

2020年6月，首个基于STARK的扩容方案——StarkEx，部署在以太坊主网。StarkEx：

Prover：负责做大量链下计算，并为这些计算的正确性生成一个STARK-proof。
Verifier：在链上验证该proof。

首个部署的约束由StarkWare的工程师手写的，后续引入了Cairo编程语言来支持证明通用计算。Cairo全称为CPU Algebraic Intermediate Representation (AIR)，包含了单个AIR来验证“CPU”的指令集。从而开创了以更快更安全方式为更复杂商业逻辑——任意计算statement——编写程序的先河。

1.2 SHARP

SHARP，为SHARed Prover，以源自多个不同apps的交易为输入，为这些交易生成单个STARK-proof。Apps会combine their batches of transactions，filling up the capacity of a STARK-proofs faster。交易处理的速度和延迟都得到了改善。
接下来需要的是：

递归证明，不仅是对某些hard-coded logic的递归证明，而是对通用计算的递归证明。

在理解递归证明的所有优势之前，需先了解当前SHARP采用的非递归证明方案：
在这里插入图片描述
不断会有statement到来。当达到某特定容量（或某时间）阈值，会生成一个大的combined statement（又名Train）。仅当收到所有独立statement之后，才会为combined statement生成证明——生成证明的事件将很长（约为为每个statement独立生成证明的时间之和）。
为特别大的statement生成证明将受限于可用的计算资源，如内存。在递归证明方案之前，这为限制STARK证明扩容的主要瓶颈。

2. 何为递归证明？

STARK方案中：

证明某statement用时与执行该statement用时约成线性关系。如证明用时为 $T$ 。
验证该证明用时约为 $\log (T)$ ，这通常称为“对数压缩”。

换句话说，验证某statement证明的用时要远低于直接计算该statement用时。

Cairo用于表示通用计算statement，可由Prover用于生成STARK证明，也可由Verifier用于验证STARK证明。

递归证明的点在于：

可编写某Cairo程序，来证明数千笔交易的正确性
再编写另一Cairo程序，来验证多个STARK证明
然后为多个“up-stream” 证明的有效性生成单个证明。

由于对数压缩和约为线性的证明时间，为验证某STARK证明生成证明用时将相对较短（未来将仅需数分钟）。

当实现了递归证明之后，当statement到来，无需等待，SHARP即可开始为其生成证明，这些证明将以多种模式不断合并为递归证明，直到某个点，最终的证明将提交到链上verifier contract：
在这里插入图片描述
如上图中，（可能源自4个不同来源的）4个statement发送给SHARP：

这些statement可并行证明
然后每组proof经Recursive Verifier statement（为某验证STARK proof的Cairo程序）验证后，合并生成为一个证明。Recursive Verifier statement可确保其所验证的2个证明是正确的。
证明再进一步由Recursive Verifier statement合并生成一个证明。该单个证明可确保4个原始statement的正确性，该证明将最终提交上链，由某Solidity verifier合约验证。

3. 递归证明的即时效益

递归证明的即时效益有：

1）降低链上开销：可将多个证明压缩为单个，意味着链上验证单笔交易的开销将降低（每个statement可包含多笔交易）。
借助递归证明，计算资源瓶颈（如内存）将移除，因每个有限大小的statement可分开证明。因此，当使用递归证明时，Train size将几乎不受限，单笔交易的开销将以数量级降低。
实际上，reduction取决于可接受的延迟（以及交易到达的速度）。此外，每个证明通常还伴随有某些作为on-chain data的output，这将限制伴随单个proof提交上链的数据量。
2）降低延迟：递归证明模式的延迟低于为large Train statement生成证明的延迟，主要有2方面原因：
- 输入的statement可并行证明（而不是为单个巨大的combined statement生成证明）
- 无需等待Train中最后一个statement到达才开始生成证明。proof可与新到达的证明一起进行combine。这就意味着最后一个到达Train的statement的延迟，取决于证明该最后statement用时 + 为某（证明所有之前已在该Train中各statement有效性的）Recursive Verifier statement生成证明用时。

目前，StarkWare在积极开发和优化证明Recursive Verifier statement的延迟，未来几个月该延迟将降低为数分钟。
当前SHARP的延迟为数分钟到数小时，具体取决于单笔交易的链上开销。