StarkWare的Recursive STARKs

Posted 2023-01-09 mutourend

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的延迟为数分钟到数小时，具体取决于单笔交易的链上开销。

4. 递归证明的其它效益

递归证明可带来其它微妙效益：

• 1）应用层递归：为平台和应用进一步降低开销提升性能提供了可能。
  每个STARK证明可保证某“public input”（在Cairo中称为“program output”）的statement的有效性。理论上，STARK递归是将具有2个input的2个证明 压缩为 具有2个input的1个证明。即，证明的数量减少了，但是input数量仍保持不变。应用通常会根据这些input来更新L1上的状态（如，更新state root 或 在链上取款）。
  若recursive statement是application-aware的，即，可识别application本身的语义，则可在将2个证明压缩为1个的同时，将2个input也合并为1个combination input。获得的resulting statement可保证基于application语义的combination input的有效性，从而实现Applicative Recursion（应用层递归）：
  
  此时，Statement1可证明状态由A到B的更新，Statement2可证明状态由B到C的更新。Statement1和Statement2的证明可合并为第3个statement——用于直接证明状态由A到C的更新。递归调用以上逻辑，可将state的更新开销大幅降低的同时，满足指定的最终延迟要求。
  另一个应用层递归的重要例子是：将多个证明的rollup数据进行压缩。如，类似StarkNet这样的Validity Rollup，为确保数据可用性，每个L2的storage update，都会包含在L1的transmission data中。 不过，没必要发送同一storage element的多个更新，因仅证明的交易最终值才需用于数据可用性。已在单个StarkNet block中做了该优化。但是，为每个block生成一个证明，应用递归可压缩多个L2区块的rollup data。这将有效降低开销，支持L2上更短的区块间隔，同时也不牺牲L1 updates的扩展性。
  需注意的是：应用层递归可与上面的（与应用层无关的）递归证明结合使用，这2种优化是相互独立的。

• 2）降低链上Verifier的复杂性：STARK verifier的复杂性取决于其要验证的statement种类。如，对于Cairo statements，Verifier复杂性依赖于Cairo语言中的特定元素，即built-ins（如将Cairo比作CPU，则built-ins可等价为CPU中的微电路：当频繁计算时，微电路计算自身也需要优化）。
  Cairo语言在持续进化，并在逐渐提供更多实用的built-ins。换句话说，Recursive Verifier仅需要使用这些built-ins的一个小子集。当前recursive SHARP支持Cairo中的任何statement，从而在recursive Verifier中可支持所有语法。特别的，L1 Solidity Verifier仅需验证递归证明，从而可延至为支持Cairo语言中都某一个更稳定的子集：
  L1 Verifier无需跟进最新最强的built-ins。换句话说，持续进化的复杂statement的验证仅分配给L2，而L1 Verifier的验证将验证相对更简单更稳定的statement。

• 3）降低计算开销：在递归之前，将多个statement聚合为1个证明的瓶颈 受限于当前计算资源所支持的最大statement size（以及生成该证明所需的时间）。
  借助递归证明，无需再为特别大的statement生成证明，可采用更便宜更可用的计算资源。从而降低Prover的运行门槛。

参考资料

[1] StarkWare 2022年8月博客 Recursive STARKs
[3] 2020年视频 STARK@Home 16: Recursive STARKs