StarkWare的Recursive STARKs

Posted mutourend

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了StarkWare的Recursive STARKs相关的知识,希望对你有一定的参考价值。

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 T T
  • 验证该证明用时约为 log ⁡ ( T ) \\log (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

以上是关于StarkWare的Recursive STARKs的主要内容,如果未能解决你的问题,请参考以下文章

StarkWare何以撑起80亿美元的估值?

TritonVM——基于Recursive STARK的虚拟机

Django——stark组件

Stark组件

django 之 stark组件

使用自己的stark组件实现crm系统