原文作者：StarkWare核心工程主管GidiKaempfer
TL;DR
?递归证明已在主网上线，通过单一证明就可扩展到StarkEx或StarkNet
?STARK将会显著提高网络容量、降低网络延迟和交易成本
?为L3和其他应用奠定基础
扩大规模！
由Cairo提供支持的递归证明现已正式投入运营。这标志着STARK对L2扩展能力的重大提升，它能通过单一证明实现以太坊的交易笔数数倍的增长。
目前，STARK的扩展是通过将几万甚至几十万笔交易"rollingup(汇总)"到一个证明中来实现的，这个证明会最终被写入以太坊L1，通过递归，类似这样的证明都可以被"rollingup"到一个单一的证明中去。
这种方法现在已经用于众多基于Cairo的构建的应用程序中，比如：运行在StarkEx和StarkNet上的应用程序。
STARK的发展历程
自2020年3月在Mainnet上完成第一次STARK证明以来，下述事件共同发展塑造了STARKs的发展。
基于STARK的扩展性
2020年6月，首个基于StarkEx的扩展解决方案部署在以太坊主网上。StarkEx拥有一个支持在链下执行计算并生成STARK-proof的验证器，以及一个在链上来验证此证明的验证器，由于第一次部署的完全由StarkWare的工程师“手动”完成，因此也极大地限制了StarkEx的运行速度，最终我们意识到，我需要一种编程语言来支持一般计算的证明，于是Cairo诞生了。
Cairo
2020年夏天，Cairo第一次出现在以太坊主网之上。Cairo是CPUAlgebraicIntermediateRepresentation的缩写），并包含单个AIR来验证这个“CPU”的指令集。Cairo为更复杂的商业逻辑、更多样化计算语句打开了大门，并以一种更快、更安全的方式进行编码验证。Cairo程序可以证明单个应用程序执行的逻辑，而且一个Cairo程序也可以是多个此类应用程序的串联——即SHARP。
SHARP
SHARP是一个共享验证程序，它可以从几个独立的应用程序中提取相关交易数据，并在一个STARK-proof软件中进行验证。不同应用程序可以合并它们的交易批次，以更快地填满了stark-proof池，这样会提高交易的速度。所以下一个前沿领域是:递归证明，它不仅适用某些写死的编码逻辑，而且也是针对一般性的计算。
要了解递归证明的全部好处，我们首先要了解SHARP是如何执行证明的。下图描绘了一个典型的非递归流程：
一个典型的非递归证明流程
在这里，状态说明会随着时间汇总，当达到容量(或时间)阈值时，将生成一个大的组合状态说明(也称为Train)，只有在收到所有单独的状态说明后，才会验证这个组合状态说明，而这个证明需要很长的时间来进行验证(是单独证明每个状态说明所需时间的总和)。
验证非常大的状态说明最终会受到可用计算资源(如内存)的限制。在递归之前，这实际上是STARK证明中限制可扩展性的阻碍。
什么是递归证明
使用STARK证明，证明一个状态所花费的时间与执行该状态所花费的时间大致呈线性关系。如果执行一个状态需要花费T时间，那么验证证明大约需要log(T)时间，这被称为“对数压缩”。换句话说，使用STARKs，你花在验证状态上的时间要比计算执行状态的时间少得多。
Cairo支持通用的计算状态，这些状态可以由STARK验证，也可以由相应的STARK验证器验证。
这就是执行递归的优势所在:我们可以用同样的方式编写一个Cairo程序来证明数千个交易的正确性，我们也可以编写一个Cairo程序来验证多个STARK证明。我们可以生成一个证明来证明多个“上游”证明的有效性，这就是我们所说的递归证明。
由于对数压缩和大致线性的关系，STARK的验证需要相对较短的时间(预计在不久的将来只需要几分钟)。
在实现递归时，SHARP可以在状态数据到达时就对其进行证明，它们的证明可以在各种模式中一次又一次地合并成为递归证明，直到在某个时间节点上，将产生的最终递归证明提交给L1链上验证者。下图描述了一个典型这样的流程:
一个典型的递归证明流程
在这个例子中，四个状态声明被发送到SHARP,这些状态声明都是平行证明的，然后，每对证明都由递归验证器进行验证，并为此生成下一个证明，而这个证明说明了前两个证明已被证实。接下来，通过递归验证器语句再次合并两个证明，最终生成了一个证明了四个原始状态的证明--Proof123。然后，该证明在主链上提交，并由Solidity验证者智能合约进行验证。
递归证明的好处
降低链上成本
当我们实现了将多个证明"压缩"为一个，这意味着每个交易的链上验证成本降低。
使用递归证明，可以消除限制证明的计算资源障碍(例如内存)，让每个有限规模的状态声明都可以被单独证明。因此，当使用递归时，递归的组合状态可以不受限，让每笔交易的成本减少几个数量级。
在实践过程中，减少的成本还取决于你可接受的延迟。此外，由于每个证明通常还伴随着一些输出，如链上数据，因此，与单个证明一起写入链上的数据量是有限的。尽管如此，将成本降低一个数量级完全是可以实现的。
降低交易延迟
递归证明模式减少了证明大量状态数据的延迟，这主要是以下两个因素的结果：
传入的状态数据可以并行证明处理。
无需等到组合状态数据池中的最后一条的到达，即可开始证明，这意味着加入组合状态池的最后一条数据的延迟大致是证明最后一条状态所需的时间加上证明最终的递归验证时间之和。
目前，我们正在积极地开发和优化证明递归验证的延迟。我们希望在几个月内能达到几分钟这个量级。因此，一个高效的SHARP可以提供从几分钟到几个小时的不等延迟，这主要取决于每笔交易与链上成本的权衡，这也表明SHARP的延迟得到了很大意义的改善。
促进L3发展
Cairo中的递归验证器也向StarkNet的提交证明提供了应用可能，因为该声明可以被嵌入到StarkNet智能合约中，这就允许在公共的StarkNet(一个L2网络)上实现L3的部署。
递归模式非常适用于L3的证明的聚合，即通过L2上的一个证明来验证即可，因此这也实现了某种意义上的以太坊性能超扩展。
其他好处
应用型递归
递归证明为希望进一步想要降低成本和提升性能的平台与应用程序提供了更多契机。
每个STARK都证明了应用于某种输入声明的正确性，这种输入被称为"公共输入"。从概念上讲，STARK递归将两个输入的证明压缩为一个，虽然证明的数量减少了，但源头的数量是保持不变，而这些输入通常被用于应用程序或者L1上的状态更新。
如果允许递归声明是应用感知的，即识别应用程序本身的一些语义，那它既可以将两个证明压缩为一个，也可以将两个输入合并为一个，结果语句可以根据应用程序的语义验证输入组合的有效性，因此命名为应用递归，这能大幅降低链上验证器的复杂性。
应用递归示例
首先，声明1证明了从A到B的状态更新，声明2证明了从B到C的进一步更新。声明1和声明2的证明可以合并成第三个声明，它直接证明了从A到C的状态更新。通过类似的逻辑，人们可以显著地减少状态更新的成本。
应用性递归的另一个重要例子是压缩多个证明的汇总数据。例如，对于想StarkNet这样的ValidityRollup，L2上的每个存储更新也作为L1上的传输数据包含在内，以确保数据可用性。其实，我们没有必要在同一个存储元素发送多个更新，因为数据可用性只需要那些经过了验证交易的最终值。这种优化已经在单个StarkNet区块内实现。通过为每个区块生成证明，应用递归可以跨多个L2的区块汇总压缩此数据，这可以显着降低成本，使L2上的块间隔更短，还不牺牲L1可扩展性。
值得注意的是，应用性递归可以与前面描述非应用性递归相结合，这两个优化是彼此独立的。
降低链上验证者复杂度
STARK验证器的复杂性取决于它被设计来验证的语句种类。特别是对于Cairo语句，验证器的复杂度取决于Cairo语言中允许的特定元素，更具体地说，取决于支持的内建程序。
Cairo语言不断发展，提供越来越多有用的内置程序，而递归验证器只需要使用这些内置插件的一部分，通过在递归验证器中支持的完整语言，递归SHARP可以成功地支持Cairo中的任何语句。
L1solididity验证器只需要验证递归证明，而不需要最新的内置代码，换句话说，我们把不断升级的复杂语句的验证被下放到L2，只是让L1验证器来验证更简单、更稳定的状态数据。
减少计算足迹
在没有递归之前，将多个状态数据汇总到一个证明中的计算能力受限于可用计算实体的计算能力。
有了递归，就不再需要证明这种极其庞大的组合证明，因此，可以使用更小、更便宜和更多的计算实体。这使得可以在更多的物理和虚拟环境中部署验证器成为可能。
总结
通用计算的递归证明现在正在服务多个生产系统，包括StarkNet。
在持续的优化之下，递归证明将会提供更高吞吐量、更低GAS费、更低延迟性，并为L3和应用递归带来新的机会。目前，递归验证器还在进一步优化中，随着时间的推移将会提供更好的性能和成本效益。
中文推特：https://twitter.com/8BTC_OFFICIAL英文推特：https://twitter.com/btcinchinaDiscord社区：https://discord.gg/defidao电报频道：https://t.me/Mute_8btc电报社区：https://t.me/news_8btc
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。