以太坊二层解决方案中的欺诈证明现状

1. 介绍

1.1. 乐观 Rollup的未来在哪里？

在2024年9月，Vitalik 发表了强有力的声明 关于提升Rollup的标准：

我对此非常认真。从明年开始，我计划只在公开场合（如博客、演讲等）提到安全性达到阶段1+的L2，可能会有一个短暂的宽限期，用于新的真实有趣项目。无论我是否投资，或你是否是我的朋友；阶段1或没戏。

Rollup的阶段系统是一个用来大致评估Rollup安全级别的框架，涵盖从阶段0到阶段2。如今的主要Rollup中，只有Arbitrum和Optimism达到了阶段1。大多数其他乐观 Rollup目前处于阶段0。

鉴于这种情况，产生了一些问题：

• 自从引入乐观 Rollup已经过去3年，为什么没有人达到最高级别，阶段2？
• 我们什么时候可以期待乐观 Rollup达到阶段2？

本文旨在通过分析乐观 Rollup的欺诈证明和挑战机制来回答这些问题，以及每种机制如何朝着实现阶段2的目标发展。此外，还探索了乐观 Rollup和欺诈证明系统的未来。

1.2. 乐观 Rollup与ZKRollup

大家都知道，以太坊的速度慢且费用高。以太坊社区的研究人员和开发人员不断致力于解决这个问题。在探索了分片和 plasma 等多种解决方案后，社区一致同意将Rollup视为实现可扩展性的主要解决方案。因此，像Arbitrum、Optimism和zkSync这样的许多Rollup应运而生。根据L2Beat，目前大约有40个Rollup，还有像Validium和Optimium等额外解决方案使用alt-DA解决方案以实现更高的可扩展性，总共约为41。此外，预计还会有约80个新的Rollup链推出。

（L2的当前状况 | 来源：L2Beat)

Rollup的核心概念是在链外执行交易，然后仅将交易数据和结果状态根提交给以太坊，从而实现可扩展性。用户可以将资金存入以太坊的特定桥接合约中，将资金转入Rollup并在Rollup内进行交易。由于交易数据被提交到以太坊，并且一旦最终确认，就无法更改而不牺牲以太坊的安全性，因此Rollup被认为是“继承以太坊的安全性。”

但这真的成立吗？如果处理Rollup交易的提议者是恶意的呢？恶意的提议者可以操控Alice的余额，将其转移到自己的账户，然后提取到以太坊，有效地窃取Alice的资金。

为了防止这种情况，提取资金从Rollup到以太坊时需要一个额外的安全机制。通过向以太坊桥接合约提供证据来证明提款交易是正确处理并包含在L2链中的，可以完成提款。

每个Rollup选择的最简单方法是比较提款交易的哈希与Rollup的状态根，以证明提款交易正确地包含在Rollup的状态中。这需要将提款交易和状态根同时提交到以太坊的桥接合约中。用户提交他们的提款交易，而验证者计算并提交状态根。

然而，如果提交状态根的验证者行为恶意并提交了错误的根，这可能会危及用户资金的安全。为了减少这种风险，提出了两种主要机制，导致了乐观 Rollup和ZKRollup之间的区别。

1. ZK Rollup ZKRollup不仅要求验证者提交状态根，还要求提供ZK证明来验证状态根计算的正确性。如果验证者提交了错误的状态根，则ZK证明将无法通过L1验证者合约的验证，从而防止恶意状态根的提交。
2. 乐观 Rollup 乐观 Rollup允许指定的验证者在没有额外保障的情况下提交状态根，依赖于假设提交是诚实的。然而，如果提交的根是错误的，任何人都可以对此提出挑战，并使人们无法在提款过程中使用它。挑战者必须向以太坊提交证据，证明该根是错误的，这被称为欺诈证明。为了确保从像L1审查这种攻击的安全解决方案，在乐观 Rollup中有约一周的提款延迟。

1.3. 我们为什么需要欺诈证明？

与ZKRollup不同，乐观 Rollup在验证者可以提交错误的状态根并试图操控提款的情况下运行。欺诈证明有效地防止这种情况，确保桥接合约中的资金安全。

没有强大的欺诈证明机制，乐观 Rollup就无法完全继承以太坊的安全性。例如，在当前的Arbitrum许可验证者系统中，如果所有验证者勾结，他们可能会窃取桥接合约中的所有资金。同样，在OP Stack的Rollup如Base中，仍未在主网实施无权限故障证明，单个恶意验证者可能会窃取资金。

因此，欺诈证明在乐观 Rollup的安全性中发挥了关键作用，任何缺乏良好实施欺诈证明机制的系统都会对用户资产构成风险。

本文评估了与各种乐观 Rollup相关的风险，并检查了其欺诈证明机制的实施、优势和劣势。

1.4. 朝着阶段2：去掉辅助轮

欺诈证明系统在帮助乐观 Rollup实现“阶段2”方面起着关键作用。Vitalik提出的阶段框架，目前由L2Beat运营，旨在评估Rollup的安全级别。

在以太坊生态系统中，这一阶段框架通常被比作学习骑自行车。阶段0的Rollup，依赖于最多的信任假设，被比作带辅助轮的三轮车，而阶段2的Rollup，完全继承了以太坊的安全性，被比作去掉辅助轮的两轮自行车。

以下是从阶段0到阶段2的更详细的标准：

标准	阶段0	阶段1	阶段2
存在证明系统	不存在	完整和功能性证明系统
证明提交白名单	不适用	至少5个外部参与者可以提交证明	无权限，任何人都可以提交证明
能够单方面退出	不适用	用户必须能够单方面退出
退出窗口	不适用	至少7天	至少30天
安全委员会设置及操作范围	不适用	作为在证明系统出现问题时的保护。全面控制。8个参与者的多重签名设置，超过75%的共识阈值。参与者必须是公开已知的。	极其有限。只能够应对链上可证明的漏洞。

如上所述，实现适当的欺诈证明和挑战机制对于乐观 Rollup达到阶段1或2至关重要。考虑到标准，满足阶段2标准的欺诈证明系统应该具备以下特征：

• 应该运行良好且没有已知缺陷，具备1-of-N特性。
• 必须是无权限系统，任何人都可以提交证明。
• 如果证明系统有漏洞，应该能够在链上被证明。

在文章的后半部分，我们将探讨各种协议如何尝试实施这些特性。

2. 欺诈证明 - 概念与误解

2.1. 如何实施欺诈证明？

欺诈证明提供了链上可验证的证据，表明提交的状态根是错误的，这表示L2中的特定状态转移函数未正确执行。一个简单的方法是生成从最后确认的状态根到当前状态根执行所有L2区块的证明，以证明状态根是错误的。然而，这种方法成本高昂且耗时。

因此，有效的欺诈证明生成会在生成该片段的证明之前缩小特定错误的状态转移范围。大多数欺诈证明协议均遵循这一方法。

欺诈证明和挑战协议通常遵循以下步骤：

1. 验证者（主张者）定期向以太坊提交包含L2状态根的输出（或声明）。
2. 如果验证者（挑战者）不同意输出，则他们发起挑战。
3. 主张者和挑战者通过称为二分或解剖的过程识别不同意的片段，将片段缩减到指令级或区块级（与ZK一起）。
4. 挑战者提交链上的欺诈证明以展示错误片段。通常像Arbitrum和Optimism这样的协议在链上执行可疑的指令进行验证。
5. 如果欺诈证明被验证，则会删除或替换错误的输出。根据挑战协议，主张者将被削减，挑战者将获得奖励。

2.2. 常见误解：欺诈证明和挑战不回滚链

一个重要的观点是，即使发生欺诈证明和挑战，链也不会回滚。欺诈证明所保证的是“存储在存入的桥接合约中的资金不能被恶意提取”，并且不会回滚错误的状态转移。

不回滚的主要原因是没有必要。从根本上讲，当Rollup中发生错误状态转移时，问题在于恶意行为者可能窃取用户的桥接资金。为了防止这种情况，确保提交到L1的状态根保持正确就足够了。这与链回滚无关，只要防止恶意状态根的最终确认，欺诈证明和挑战机制就是足够的。

此外，如果发布状态根的提议者和为L2链生成区块的序列化者是不同的实体，则无需回滚机制。

因此，即使在挑战成功解决的情况下，L2链也不会回滚；只有提交到L1的状态根（输出或声明）会被删除或替换。如果欺诈证明和挑战机制工作正常，则确保了桥接中用户的资金安全。

2.3. 实例：2024年4月Kroma的挑战

通过实际挑战案例，你将能够看到并不是对整个Rollup链进行回滚，而是只替换或删除输出根。到目前为止，在主网上已知的唯一成功挑战案例发生在2024年4月的Kroma中，这是一种基于OP Stack的混合Rollup，采用ZK故障证明。

Kroma是一个基于OP Stack的Rollup，具有自己的ZK故障证明和无权限验证者系统。在2024年4月1日，Kroma序列化者的L1来源出现问题，导致序列化者生成错误的区块。此外，观察此情况的验证者还提交了一个错误的输出根。在提交输出根后，总共12个挑战者对该输出提出了挑战。

其中一位挑战者成功调用了proveFault函数，删除了错误的输出。

（挑战者成功执行proveFault函数 | 来源：etherscan)

这是以太坊Rollup历史上在主网上的第一个成功挑战案例。在2021年5月首个乐观 RollupArbitrum上线约三年后，这是首个成功验证和挑战主网环境下的故障证明。关于此挑战的详细概述可以在Kroma的文章中找到。

在这个案例中，Kroma链没有经历回滚，而只是删除了错误的输出根。

免责声明：是欺诈证明还是故障证明？

欺诈证明也被称为故障证明。特别是在Optimism和OP Stack链中，使用“故障证明”这个术语，而在Arbitrum、Cartesi、L2Beat等则使用“欺诈证明”这个术语。

考虑到上述Kroma挑战案例，可以推断出挑战通常是由“错误”引起的，而不是出于恶意企图仍然提款。在上述案例中，主要原因是Kroma验证者观察到的L1客户端异常。换句话说，挑战的产生可能仅由于验证者错误或错误补丁造成。在这种情况下，“故障证明”这个术语可能更为贴切。

然而，更好地反映目的本身的术语是“欺诈证明”。到目前为止引入的所有机制，以及未来将引入的那些，旨在验证试图通过恶意输出窃取桥中特定资金的“欺诈行为”。

关键是，目的是防止欺诈，但实际上可能由于错误而发生。在这篇文章中，我将使用在生态系统中更普遍的“欺诈证明”一词。

3. 破解！ - 利用欺诈证明机制

3.1. 设计经济争议协议

乐观 Rollup已各自实施了自己的欺诈证明和挑战机制，以保护用户资金。这些机制共同追求的理念是“只要至少有一个诚实的参与者，协议就可以保持安全。” 欺诈证明是描述某个预定状态转移函数执行正确的证明，通过验证过程，必然会导致诚实参与者胜出的结果。

然而，这并不总是成立，实际上，可能会出现即使存在诚实参与者协议仍处于危险的情况。例如，意外的bug可能由于欺诈证明的复杂性而发生，而且由于激励不匹配，恶意参与者可能会发现自己在经济上比诚实参与者更有优势，导致用户提款显著延迟或资金被窃取。

基于这些原因，设计欺诈证明和挑战机制是很困难的任务。特别是，要成为一个阶段2的Rollup，挑战机制必须完美，并且必须针对各种攻击向量和漏洞制定对策。

换句话说，每个欺诈证明和挑战机制都包含了如何响应攻击向量的考量。如果你无法理解每个攻击向量，就无法理解为何他们的协议必须以这种方式设计。

因此，在本节中，我们将首先检查以下攻击向量，并探索每个协议如何做出响应。

• 争议游戏中脆弱性产生的攻击向量：
  • 延迟攻击：将用户的提款延迟超过7天。
  • Sybil攻击：耗尽诚实参与者的资金和资源。
• 由于L1验证者的审查造成的攻击。
• 利用欺诈证明虚拟机中的漏洞进行攻击。

注意：以下讨论的攻击向量都是公开已知的，并不影响任何主网的安全性。

接下来将研究的协议及其各自特点如下：

名称	特点
Arbitrum BoLD	- 所有参与者之间的并发挑战机制。 - 通过使用历史承诺和高债券金额，防止二分滥用和Sybil攻击。
Cartesi Dave	- 采用锦标赛结构的1对1顺序挑战机制。 - 通过使用历史承诺和锦标赛结构，防止二分滥用和Sybil攻击。
Optimism Fault Proof**（OPFP）**	- 利用博弈树的所有参与者之间的并发挑战机制。 - 通过指数提高债券金额来减少延迟攻击的激励。 - 实现基于模块化的自定义争议游戏。
Kroma ZK Fault Proof**（Kroma ZKFP）**	- 1对1类型的并发挑战机制。 - 通过使用ZK和解剖减少交互计数。 - 无权限验证者系统，基于激励的去中心化。

3.2. 攻击向量#1：利用经济争议游戏

大多数实施欺诈证明机制的乐观 Rollup都需要通过二分来找出第一个不同意见点。协议需要提供激励来鼓励参与者诚实地行事。

实现这一点的最简单方法之一是要求参与者在采取行动时抵押一定数量的资金（债券），并在被判定为恶意行为时削减债券。

考虑博弈论，协议必须确保恶意参与者进行攻击所消耗的资金大于诚实参与者进行防御所消耗的资金。然而，这是很难做到的。

这里的关键原因是，在游戏上下文中，不可能事先知道谁是恶意参与者，除非挑战执行完成。换句话说，提交输出的主张者可能是恶意的，而挑战输出的挑战者也可能是恶意的。因此，协议必须在假设任何一方可能是恶意的前提下进行设计。此外，由于可能存在各种攻击向量，设计协议将变得异常复杂。

另外，由于每个协议采用不同的机制，因此必须定义对应于每种方法的攻击向量和攻击者的激励模型。此外，必须设计一种经济安全模型，以确保在这些模型组合时仍然安全。

这仍然是一个持续讨论的话题。在本节中，我们将分析可能发生的一般攻击向量以及参与者在这些场景中的激励。此外，我们还将探讨每个协议如何应对这些攻击，以及它们在多大程度上有效地限制这些激励。

3.2.1 攻击向量#1-1：延迟攻击

延迟攻击是指一种攻击，其中恶意实体并非旨在窃取Rollup资金，而是阻止或延迟输出在L1上的确认。这是一种可能发生在目前大多数乐观 Rollup上的攻击，会将用户提款的额外延迟造成超过一周以上。

这与由于L1验证者的审查所造成的攻击略有不同，后者将会在稍后讨论。审查会防止诚实参与者在以太坊上采取任何行动，使恶意状态根得以最终确认。另一方面，延迟攻击可以在诚实参与者积极参与的情况下延迟状态根的最终确认。在这种情况下，不仅用户的提款可能会被延迟，但如果攻击者的资金超过防御者，恶意状态根可能会过于最终确认，导致用户的资金被窃取。

防止延迟攻击的一个简单方法是要求参与者在挑战系统中抵押一定数量的资金或债券，如果造成延迟，就可以削减该债券。

但是，有一些考虑要注意。如果攻击者愿意承担赌注并仍然尝试进行延迟攻击，那会怎么呢？

这个攻击向量在处理时相当棘手。这也是Arbitrum的欺诈证明系统目前在权限结构中运行的原因之一。

实施于Arbitrum One、Arbitrum Classic上的欺诈证明机制采用了分支模型。参与者不仅仅允许对不正确的声明进行挑战，每个参与者提交他们认为是正确声明的内容以及一定数量的资金，将这些视为“链的分枝。”声明也可以被视为链状态的检查点。

（Arbitrum的分支模型）

在Arbitrum Classic中，参与者会提交他们认为是正确的声明和链分支，通过挑战逐步移除不正确的链分支，最终确认正确的声明。

然而，单个挑战不能确定谁是正确的。两个恶意参与者可能会以错误的方式进行二分，将不相关的点定义为不同意见点，从而消除正确的声明。因此，Arbitrum确保持续进行挑战，直到对特定声明没有参与者抵押资金为止，确保如果有一个诚实的参与者，就能成功解决挑战。

这可能被利用进行延迟攻击。假设有诚实的参与者和N-1个恶意攻击者对正确的声明抵押资金，而一个攻击者对错误的声明抵押资金。如果攻击者总能在诚实参与者之前包含其交易，则他们可以先进行挑战。在最糟糕的情况下，如果他们以错误的方式进行二分，二分他们一致同意的部分而不是争议的部分，他们可以在错误的部分提交欺诈证明。显然，这将通过，导致抵押在正确声明上的资金的一方损失。

由于每个挑战可能需要不少于7天，攻击者可以将协议的延迟最多延至7 * (N-1)天。

（Arbitrum Classic的延迟攻击 | 来源：L2Beat Medium)

这个机制的问题在于，延迟攻击的成本线性增长与协议被延迟的时间。如果攻击者认为该攻击会带来收益，他们将希望尽可能长时间地延迟协议，总延迟时间将与攻击者的总资金成正比，这可能导致用户提款的非常长的延迟。

总之，能够有效防御延迟攻击的欺诈证明协议必须设计成最大延迟时间被限制在某个时间量，或者进行延迟的成本随时间呈指数增加，这使得执行攻击的费用大于因此产生的收益。

3.2.2 攻击向量#1-2：Sybil攻击（耗尽攻击）

另一个攻击向量是Sybil攻击（耗尽攻击，鲸鱼攻击）。当攻击者比防御者拥有更多资金或计算资源时，这种攻击可能发生。攻击者可以不断提交错误的输出根或创建无意义的挑战，从而耗尽防御者的资金或计算资源。在某个时刻，防御者会用完资金或空闲计算资源，使得他们无法进行防御，从而攻击者最终确认错误的输出根并窃取资金。

通常，以上攻击向量可能在以下两种方式中发生于一个无权限的系统：

1. 持续提交错误输出。假设攻击者Bob拥有比诚实参与者（防御者）Alice、Charlie和David的资金总和还多的资金。在这种情况下，Bob会不断提交错误的输出根。诚实参与者Alice、Charlie和David将回应支付交易费用和债券，在达到某一阈值时，诚实参与者的资金会在Bob的资金之前用尽。此时，Bob提交另一个错误的输出，而由于网络中再没有诚实参与者的余留资金，通过将该输出确认为正确输出，Bob便可从乐观 Rollup中窃取资金。
2. 向诚实输出提交多次挑战。相反，恶意参与者可以通过提交多次挑战攻击诚实参与者。类似地，攻击会继续，直到诚实参与者耗尽所有用于交易费用和债券的资金，然后恶意攻击者便会提交错误的输出，从而从桥中窃取用户的资金。

为了防止这种攻击，防御者对攻击者的优势必须设计得当。在所有情况下，防御者必须相对于攻击者处于足够的优势。实现这种方法的一种方法是精心设计债券；由于Sybil攻击与参与者可用资金的总量相关，因此如果债券设计得当，将可以确定“在攻击者的资金额为防御者总资金N倍时，系统安全。”防止Sybil攻击的另一已知方法是实施反Sybil的争议协议。稍后将通过展示Cartesi Dave进一步解释这一点。

让我们看看各个协议如何通过各自设计来应对这些延迟和Sybil攻击。

3.3. 解决方案#1：经济合理的争议游戏

1）Arbitrum BoLD

BoLD在原始Arbitrum Classic的分支模型基础上，引入以下三个要素以防止延迟攻击的脆弱性：

• 所有参与者之间的挑战机制。在BoLD中，挑战不再是1对1进行，而是采用一种并发的所有对所有类型的系统，所有参与者都可以在他们赞同的分支上抵押自己的债券。这防止了从之前的1对1挑战机制中衍生出的延迟攻击向量，并确保不可发生此单一争议的多个、独立挑战。
• 通过正确状态计算的证明（历史承诺）防止恶意二分。在Arbitrum Classic中，恶意参与者可以通过将非争议部分标记为争议点，从而故意造成延迟。为防止这种情况，BoLD要求提交证明与状态根同时提供，以验证状态根在二分过程中是正确计算的，确保没有恶意二分发生。在BoLD中，参与者必须在二分期间提交证明以及状态根。该证明验证当前状态根根据先前声明中提交的状态根是否正确计算。假设恶意参与者在二分期间试图提交与上次提交的状态根无关的任意根，则证明验证将失败，使得二分交易也失败。这有效地确保每个声明只有一种可能的二分。因此，如果攻击者想针对BoLD中的诚实声明进行多个二分，他们必须提交多个声明。然而，生成此证明要求验证者使用相当多的计算资源。在内部，生成此证明需要为所有二分中的状态生成哈希，通常估计为Arbitrum中的270个哈希（约为1.18 x 10^21）。为此，BoLD将挑战分成三个级别，将必须计算的哈希数量减少到226个（约为6.71 x 10^7）。

（该图假设总共269条指令，实际数字可能会有所不同）

• 限制争议的总持续时间。在之前的Arbitrum Classic中，每次挑战都有自己的棋钟，但没有时间限制，争议链的持续时间可以拓展，允许恶意参与者通过创造多个挑战，只要他们有足够资金就可无限期拖延协议。BoLD通过有效限制争议的持续时间来防止延迟攻击。假设有两个参与者提交不同的声明。每个声明都有一个计时器（棋钟），计时6.4天。当是某参与者提交二分或证明的回合时，该计时器开始倒计时，并在参与者完成任务后停止。由于每个参与者具有6.4天的时间，因此一个参与者可以延迟协议的最长时间为6.4天。因此，在BoLD中，挑战的最长时间最大为12.8天（在某些情况下，安全委员会介入时额外增加2天）。

通过这些机制，Arbitrum BoLD有效地限制了因挑战而导致的延迟。挑战的最大持续时间为两周，用户可能经历的最大额外延迟约为一周。

然而，这仍可能被利用于延迟攻击。恶意参与者可以创建挑战，并与L1验证者合谋审查Arbitrum的诚实验证者，从而可能会延迟Arbitrum用户的提款长达一周。在这种情况下，要求在此时间内提款的用户可能会因资金被锁定延迟而承担机会成本。虽然这不是一种攻击，攻击者直接从中获得收益，但仍然应该予以防止，因为它会对用户带来机会成本。Arbitrum BoLD通过设定足够高的创建挑战所需债券金额来解决此问题。

Arbitrum根据 BoLD经济文档计算该金额。协议延迟的主要原因是L1验证者的审查。在延迟攻击情况下，情景将如下展开：

1. 攻击者在Arbitrum上对已存在的声明N提交了一个不同的声明N'，此举会影响N的最后确认。
2. 防御者试图发送二分交易，但由于L1验证者在审查来自防御者的挑战交易而失败。
3. 由于BoLD假设审查不会持续超过7天，因此这会将N的最后确认延长最多到一周。

攻击者的利润来自于要求提取由已挑战输出推迟所造成的用户机会成本。最糟糕的情况是，在一个输出请求下，Arbitrum中所有资金被请求提取，在这种情况下，用户遭受的机会成本计算如下，假设Arbitrum One的TVL为154亿美元，APY为5%。

costopp = 15,400,000 x (1.051/52 - 1) = $14,722,400

因为提交错误申明可能会造成如此高的机会成本，所以BoLD中声明提交者需要提交相同规模的债券。目前，在BoLD中提交声明所需的债券被设定为3600 ETH，约合940万美元。

这是为了预防攻击者因延迟给系统带来的巨大损失。由于攻击者在挑战中将损失其债券，他们可能会造成高达1472.2万美元的机会成本，但同时将失去约940万美元的资金。因此，BoLD通过要求与最坏机会成本相当的债券大小，使延迟攻击不划算。

然而，3600 ETH的债券大小不仅仅是由于延迟攻击。防范Sybil攻击，Arbitrum BoLD设计旨在确保系统在攻击者的总资金为防御者的总资金6.5倍之前保持安全，这就是3600 ETH债券金额的计算方式。

在Sybil攻击的荷举，以下攻击场景可能发生在Arbitrum BoLD中。BoLD的挑战系统包含三个级别，用户必须抵押资金以提交他们认为是正确的声明。

假设诚实参与者Alice以X ETH提交了一个有效的声明。恶意参与者Bob拥有3600 ETH，可能会生成多个恶意声明。此时，Alice需要在较低水平为每个声明为它们抵押Y ETH，以对抗它们。

在Arbitrum的分支模型中，抵押资金意味着同意从创始链到当前声明的链状态。这一特性使得参与者可以将其抵押资金从声明A转移到其子声明A'和A''中。因此，Alice将把她最初抵押的X ETH转移到较低水平，并为Bob的每个恶意主张抵押Y ETH。

如果Bob比Alice有显着多的资金，会发生什么？Bob可以生成无数个恶意声明，直到Alice资金用尽为止。在这一时刻，Alice将无法继续进行二分，使Bob可确认错误的申明。

最终，这个问题归结为，在游戏中，防御者该拥有多少优于攻击者的优势。

Arbitrum将这一标准指标表示为资源比率。该比率指示诚实的参与者与恶意参与者的相对优势，表示为每个参与者所需支付的费用（G）与抵押金额（S）的比率，如下所示：

BoLD的挑战系统分为三个层级，通过在每个层级保持这种资源比率，它确保在整个系统中，防御者始终比攻击者有N倍的优势。Arbitrum基于这一资源比率计算了最高层级所需的保证金规模，并创建了一个图表graph。

（Arbitrum BoLD中的顶层争议保证金成本与资源比率 | 来源：Desmos)

根据该图，当资源比率为100倍时，顶层所需的保证金超过1百万ETH（超过4万亿美元）。尽管更高的资源比率使系统在抵御sybil攻击方面更为安全，但保证金的金额变得如此庞大，以至于几乎无人能参与系统，使其和只有一个验证者提交索赔的中心化系统无异。

因此，在BoLD中，资源比率设定为6.5倍，使顶层保证金为3600 ETH，而1级和2级的保证金分别设定为555 ETH和79 ETH。

总而言之，BoLD通过计算资源比率并设置保证金金额，确保防御者在攻击者面前有6.5倍的优势，从而有效防范sybil攻击。

2) Cartesi Dave

Cartesi的Dave首次在2022年12月发表的论文Permissionless Refereed Tournaments中提出，早于BoLD的第一版白皮书。它旨在确保诚实参与者的计算资源和资金相较于攻击者具有优势。Dave的结构与BoLD类似，并具有两个关键特性：

• 通过正确状态计算证明（历史承诺）防止恶意细分。 像BoLD一样，Dave要求参与者在细分过程中的生成证明，以证明他们正确地进行了计算，防止恶意形式的细分。因此，Dave的挑战系统也分为多个层级，以节省验证者的资源。

在比赛结构中的1对1顺序挑战机制。 Dave的挑战不会全部同时进行，而是以比赛的格式进行，如下图所示。

上图展示了当恶意攻击者对网络提交七个错误索赔时，挑战是如何进行的。由于历史承诺的属性，认可正确索赔的诚实参与者（以绿色显示）被归为一队。在Dave中，他们被分组成比赛的格式，如图所示，各参与者参与1对1挑战。同一阶段的挑战是并行进行的，一周后，挑战结束，获胜者进入下一阶段。在图中，诚实参与者的团队必须经历三轮挑战才能赢得比赛。

这一特性在预防sybil攻击方面非常有效。首先，攻击者必须创建多个索赔来执行sybil攻击，每一个索赔都会消耗攻击者的计算资源和资金。

Cartesi的论文证明在任何情况下，防御者总是保持相对于攻击者的指数优势。换句话说，Dave确保对sybil攻击只需相对较少的资源即可有效防御。这使得在Dave中执行sybil攻击非常困难，因此Dave的保证金规模被设定为最低的1 ETH，远低于BoLD。

然而，Dave对延迟攻击是脆弱的。比赛的每个阶段消耗一单位的挑战时间（一个星期），因此，恶意索赔越多，协议的延迟则越长。在Dave中完整解决一个挑战所需的时间可以用以下公式表示，

Td = 7 x log2(1 + NA)(days)

其中NA表示恶意索赔的数量。然而，Dave的挑战可以由多个层级组成以有效生成历史承诺。在这里，恶意参与者可以在挑战的每一层级生成NA恶意索赔，从而增加总的延迟时间，如下所示：

Td = 7 x [log2(1 + NA)]L(days)

其中L表示每个挑战中的层级数量。如果如上图所示，有七个恶意索赔且L为2，则挑战的完整解决时间可能长达9个星期，用户将经历2个月的额外提现延迟。如果层级数量增加或恶意索赔数量增加，延迟可能延长到几个月。

Cartesi旨在通过ZK解决此问题，相关细节将在第4节中讨论。可能的改进。

3) Optimism Fault Proof (OPFP)

OPFP是一个目前在OP主网应用的无许可挑战协议，具有以下特点：

• 使用游戏树的全对全并行挑战机制 OPFP允许任何人随时提交输出（根索赔）。不同意提交输出的验证者可以通过挑战开始细分过程。

（OPFP游戏树和细分过程架构 | 来源：Optimism docs)

细分过程在如上图所示的游戏树上并行进行。树的叶子代表L2的状态，每个节点对应L2的一个状态，最右侧的叶子表示最新的L2状态。例如，在节点1提交索赔等同于在节点3提交状态。该结构允许细分的表达。例如，如果验证者不同意根索赔（节点1），他们将提交在节点2的索赔，该节点对应树中的节点3，因为它在节点4和5之间。节点1的提交者则检查节点3处的L2状态，如果同意则提交节点4（节点5），否则提交节点2（节点3），并继续此过程直至找到分歧。即便在某一游戏中存在多个细分方向，它们均可同时继续，任何人都可以参与细分过程，而不仅限于输出提交者。

（OPFP游戏树的完整架构 | 来源：Optimism docs)

OPFP中使用的游戏树是嵌套的，上层树处理块级细分，下方子树处理指令级细分。与BoLD或Dave不同，OPFP不通过历史承诺来强制正确细分，因为生成和提交此类承诺的链下/链上的成本将很高。

• 基于模块化的可定制争议游戏 目前在OP主网上仅有两种类型的争议游戏（无许可/有许可）可用。Optimism的目标是最终引入多种类型的争议游戏，并已实现支持此功能的最小接口。通过遵循指定的函数名称和参数，任何人都可以创建自定义争议游戏。
• 通过棋钟限制挑战时间 在OPFP中，当发生挑战时，陈述者和挑战者都会收到一个时钟，分配用于细分的时间。每当提出索赔时，时钟开始运转至对方。Optimism称之为“继承祖父的时钟”。有趣的是，每个参与者被分配3.5天，而不是7天，这意味着如果没有人挑战输出，该输出将在3.5天内被完成。然而，这并不允许立即提现。在输出被确定后，OPFP有一个3.5天的监护期，在此期间，安全委员会可以干预，必要时废除不正确的输出。

（用户在正常情况下的提现流程 | 来源：OP Labs Blog)

基于这些机制，像其他乐观 Rollup一样，OPFP保证提现可以在提交后至少7天后进行。然而，如果发生挑战，用户通过该输出进行提现可能需要超过7天的时间。OPFP的棋钟模型限制了每个参与者在细分过程中花费的时间，但并不严格限制挑战解决之前的总时间。

这引发了一个问题：如果在OPFP上发生挑战，用户的提现是否可能会被延迟超过一周，类似于BoLD的情况？答案是“是”。与BoLD或Dave不同，Optimism根据协议的独特特性提供了让用户处理挑战发生时情况的选项。

OPFP假设“提交不正确索赔的参与者会失去其保证金”。然而，在OPFP中有一个特殊情况会破坏这一假设，称为“搭便车索赔”。这可能发生在以下情况下：

1. Alice提交一个有效的状态根索赔。
2. Bob提交对抗索赔，Alice进行反抗。
3. Bob等待直到他的时钟几乎跑完（3.5天），然后挑战自己的索赔。

此时，Alice应回应并索取Bob的保证金，但她继承Bob时钟上剩余的时间，这可能不足以使她反击他的索赔。因此，Bob可能通过提交“搭便车索赔”避开失去他的保证金的后果。

（OPFP中的搭便车索赔 | 来源：L2Beat)

虽然这并不妨碍挑战的正确解决，但确实代表了一种“在没有保证金被削减的情况下提交不正确的索赔”的情况，从激励的角度应该加以防范。

因此，OPFP通过重置时钟为3小时来应对这种情况，如果陈述者或挑战者的剩余时间低于3小时。这确保有足够的时间来反击搭便车索赔。然而，如果下一个细分周期经过超过3小时而没有动作，挑战便结束。

我们可以想象一个场景，该机制被恶意利用进行延迟攻击。假设诚实参与者Alice提交了一个正确的输出，从Alice提交的那一刻起，时间开始跑在挑战者的时钟上。恶意参与者Bob等待至挑战者时钟过期前1秒，然后提交一个错误的输出。此时，OPFP的规则将为Bob延长3小时。Alice会做出响应，而Bob将继续利用在每次细分中提供的额外3小时。

这可能会延迟挑战的解决。Bob的最大延迟时间为3.5天 + 3小时 最大的细分数。OPFP的最大游戏深度为73，这意味着Bob所能延迟的最长时间为3.5天 + 3小时 36 = 8天。如果Alice类似地采取行动延迟挑战，细分过程可能需要16天。

这是否意味着用户无法在16天内提款？在实践中并不是这样，因为Optimism的提现逻辑。

与Arbitrum不同，Arbitrum要求提现须证明包含在特定的L2区块中，OP Stack使用存储证明机制，其提现请求记录在L2的L2ToL1MessagePasser合约中。这意味着即使某个特定输出出现长时间的挑战，用户可以等待下一个输出确认并根据该输出中包含的合约存储状态进行提现。因此，即便用户请求提现的区块被挑战，也不必强迫经历长时间的延迟，因为他们可以借用下一个输出。

然而，这仅在用户快速行动的情况下成立。在大多数情况下，用户仍可能经历几天的延迟。这可以归因于OP Stack的提现流程，涉及以下三个步骤：

1. 在L2上发起提现（initiateWithdrawal）。
2. 在L1上证明提现（proveWithdrawalTransaction）以获取包括提现的输出。
3. 在确认提现（finalizeWithdrawalTransaction）之前等待一周的证明成熟延迟。

关键是用户必须在证明提现和确认之间等待一周的时间。如果Alice在输出B上证明了她的提现，并且发生挑战，她可以发送另一个证明以输出C并在一周后确认提现。在这种情况下，Alice仅经历了输出B到C之间的延迟。

因此，对挑战的无知或响应迟缓的用户可能会体验到最多9天的额外提现延迟。

此外，在OPFP中还有一个额外的延迟攻击向量，所有输出被连续挑战。在这种情况下，用户无法通过在下一个输出上证明来绕过延迟，导致整个协议被延迟。OPFP通过要求参与者在每个细分层级抵押保证金来应对此问题，保证金金额呈指数增加，正如下图所示。

（OPFP保证金的数量 | 来源：Optimismdocs)

换句话说，攻击者在OPFP中试图延迟挑战解决的时间越长，所需的费用就越高，因为保证金要求以指数形式增加，从而降低了延迟攻击的激励。此外，由于在OPFP中可以随时提交输出，攻击者很难估计进行延迟攻击所需的资源。初始保证金设定为0.08 ETH，而完整挑战时必须提交的全部保证金可达约700 ETH。

总之，在单次挑战的情况下，OPFP将延迟的长度留给用户的反应，且指数保证金要求则用于对抗因连续挑战而导致的延迟攻击。

然而，OPFP对sybil攻击是脆弱的。在OPFP中，如果攻击者拥有的资金超过了防御者，则可能发生sybil攻击。

在OPFP中可能存在以下sybil攻击向量，这两种情况都可能导致用户资金的盗取：

1. 攻击者创建多个挑战，导致防御者将所有资金用于保证金和Gas费。
2. 攻击者不断提交错误输出，迫使防御者持续反应，直至用尽其保证金和Gas费。

这在OPFP中是可能的，因为在挑战过程中，攻击者和防御者的总保证金要求几乎相同，且防御者的资源消耗（例如Gas费或计算能力）并没有显著少于攻击者。

然而，这并不意味着当前OP主网上的用户资金处于风险之中。OPFP仍处于第一阶段，安全委员会有权纠正任何不当结果。因此，即使发生此类攻击，安全委员会也可以介入以保护OP主网上用户的资金。

不过，要将OPFP提升到第二阶段，Optimism必须修改机制，以确保防御者相较于攻击者享有更大的优势。Optimism正在准备争议游戏V2来解决这一问题，更多细节将在第4节中说明。可能的改进。

4) Kroma ZK Fault Proof (Kroma ZKFP)

Kroma是基于OP Stack的L2，在OPFP推出之前，于2023年9月在其主网上推出了一个无许可的ZK Fault Proof系统。Kroma ZKFP与OPFP具有相似特性，但其突出之处在于它使用ZK生成块级证明，并利用切分而非细分，显著减少了挑战过程中的互动次数。Kroma ZKFP的关键特性总结如下：

• 通过激励机制实现验证者的去中心化 BoLD和OPFP均为挑战获胜者提供激励，但不提供输出提交者的特定激励；实际上，任何想要提现的人都可以提交输出并成为验证者。然而，对希望提现的用户而言，自行运行验证者客户端是不切实际的，因此必须有某些人定期提交输出以维持活性。因为这是一项消耗资源的任务，需要支付Gas费和验证者客户端的运营成本，若没有适当的激励，仅有少数人可能参与作为验证者，导致中心化和在出现故障场景时响应不足。为防止这种情况，Kroma修改了OP Stack，将产生的链上Gas费的一半分配给提交输出的验证者。此外，Kroma计划在TGE之后将这一奖励机制转变为其原生代币KRO，并计划引入类DPoS的验证者系统，允许普通用户在不运行自己的客户端的情况下为链的安全性和活性做出贡献。Kroma中的保证金金额目前设定为0.2 ETH，以确保其大于生成ZK证明和进行细分的成本。该保证金也将转变为在未来的验证者系统中质押KRO。
• 并行的1对1挑战系统 为确保激励的公平和统一分配，Kroma将输出提交间隔固定为1小时，并从预注册的集合中随机选择验证者作为陈述者。这防止了可能造成浪费的过度竞争，并避免了拥有交易排序权的区块构建者垄断奖励的情况。基于这一机制，Kroma ZKFP运行并行的1对1挑战系统。当随机选择的验证者提交输出时，任何人都可以发起挑战，而细分只发生在输出提交者和挑战者之间。多个挑战可以同时进行，第一位成功提交有效ZK证明的挑战者获胜。

通过ZK和切分减少互动 Kroma ZKFP允许参与者在四次互动中找到分歧点。当发起挑战时，Kroma ZKFP在1800个区块之间处理挑战，从上一个输出到当前输出。与细分不同，陈述者和挑战者使用切分将范围划分为N个部分，过程如下所示：

每个参与者提交两笔交易后，便能识别出他们 disagree 的区块，然后挑战者可以生成ZK故障证明，来证明陈述者的索赔是不正确的。在Kroma ZKFP中，细分超时设置为1小时，ZK证明生成的超时为8小时。

严格设定的超时意味着即使是恶意挑战者试图进行延迟攻击，也必须在10小时内完成所有细分和证明生成。此外，由于挑战者被迫在6天内完成所有操作（不包括1天的监护期），在Kroma中进行典型延迟攻击是不可能的。

然而，Kroma ZKFP仍可能对sybil攻击脆弱，类似于OPFP，如果攻击者的资金超过了防御者。Kroma ZKFP中的sybil攻击场景可能如下所示：

• 攻击者持续性地对有效输出发起挑战，直到输出提交者的资金耗尽，此后攻击者提交ZK证明确保获得挑战胜利。

与OPFP一样，Kroma ZKFP的模型是，成功的挑战将导致相应输出的删除。因此，如果发生此类攻击，将导致输出被删除，延迟用户提现1小时。如果攻击持续，所有诚实的验证者可能会耗尽资金，导致不正确的输出最终被确认，从而使攻击者盗取用户资金。

此外，Kroma ZKFP仍处于第0阶段，因为其证明系统尚不完善，具体原因如下：

1. 切分的起始点基于最后提交的输出，而非最后确认的输出。 在OPFP中，细分的起始点通常是大约一周前最后确认的输出。然而，在Kroma ZKFP中，起始点是最后提交的输出（大约早于1小时），而切分过程在1800个区块中执行。这可能允许挑战者若前一个输出因挑战被删除则赢得挑战。在这种情况下，切分将基于挑战者提交的前一个输出信息进行，如果挑战者恶意操纵前一个输出信息，他们可能赢得挑战。
2. 没有验证每个验证者使用正确批数据进行挑战。 虽然Kroma ZKFP的ZK确保如果ZK电路没有错误，不可能最终确定一个错误状态转移，但Kroma ZKFP并未验证ZK证明生成是否基于正确的批数据。这意味着即使某些交易被排除或错误的交易被包含在批中，ZK证明也有可能通过验证。因此，有可能通过基于不正确数据的ZK证明赢得挑战，如果用户的提现交易被排除在批外，他们的提现可能会被延迟。

然而，在实践中，安全委员会可以介入，以撤销不正确挑战的结果或删除无效输出，因此这些攻击向量不会影响Kroma主网上用户的资金。要达到第2阶段，Kroma ZKFP必须实施防御机制，以应对这些脆弱性。Kroma已提出改进方案以解决这些问题，详细内容将在第4节中说明。可能的改进。

3.4. 攻击向量#2: L1审查

早前，我们提到Rollup继承了以太坊的安全性。这意味着如果以太坊的安全性受到威胁，Rollup也将受到影响。

以太坊的情况可能会妨碍Rollup安全的有两种情况：

1. 以太坊验证者对Rollup欺诈证明交易实施审查 如果以太坊验证者或构建者勾结，在一个乐观 Rollup中提交恶意输出根，同时对与欺诈证明相关的所有交易实施审查，会发生什么？挑战无法在指定期间内解决，输出将被确认，用户的资金可能面临风险。这被称为弱审查。在乐观 Rollup中，如果这种审查持续超过定义的期限，通常是7天，用户的资金可能会面临风险。

2. 以太坊经历51%攻击，导致所有欺诈证明交易遭到审查 该情况涉及两条潜在的攻击路径：

   • 首先，一个实体可以获得超过2/3的以太坊总质押，让他们可以随心所欲的完成区块确认。在此情形下，攻击者可以审查欺诈证明交易，或者甚至随意生成这些交易。
   • 第二种方法涉及收购超过1/3的以太坊总质押的参与者实施“隐蔽”攻击。具体描述见研究：基于欺诈证明的Layer2协议上的无指向性审查攻击。在这种情况下，拥有1/3以太坊质押的攻击者可以妨碍他们不喜欢的任何块的确认。如果攻击者持续对常规块投票，同时拒绝对包含欺诈证明的块投票，他们便可以确认恶意的输出根，从而从乐观 Rollup中盗取资金。这被称为对基于欺诈证明的L2实施无指向性审查攻击。这比仅仅获得超过2/3的质押控制所有以太坊块更难检测。

这些基于审查的攻击在Rollup层面很难抵御，因为它们发生在以太坊协议层，并且需要对以太坊本身进行改进。然而，Rollup在此期间可以采取一些策略。

3.5. 解决方案#2: 7天提现延迟和半自动化的51%攻击恢复

为应对这些攻击向量，乐观 Rollup目前实施了7天的提现延迟。7天的期限最初是由Vitalik提出的，基于7天“足够”应对审查攻击的想法。

让我们来看看在乐观 Rollup中，7天的挑战时限是否足以抵御审查攻击，考虑两种类型的审查：弱审查和强审查攻击。

对于弱审查任务，我们可以使用概率计算来看看7天的期限是否给予乐观 Rollup抵抗审查攻击的能力。这涉及计算在某些验证者审查Rollup的挑战交易时，成功挑战欺诈的概率。

这里需要考虑两个方面：

1. 必须成功通过多次交易以使挑战在7天内成功。 在大多数协议中，要想挑战成功，如果在这一周内只有一笔来自诚实参与者的交易被包含则不会成功。因此，我们需要计算在7天内提交欺诈证明所需的所有交易被包含的概率。
2. 必须对参与审查的验证者占比做出合理假设。 目前，大多数已知中心化的以太坊区块构建者并没有实施审查，考虑到以太坊上独立质押者所占比例，大部分验证者（例如99.9%）共谋进行审查的机会几乎为零。

（主要以太坊区块构建者的审查 | 来源：Justin的推文 Drake)

考虑到这两点，如果我们假设99.5%的验证者（仍然过于极端的假设）进行审查，并计算诚实参与者成功发送30到40笔交易的概率以进行像BoLD或OPFP这样的挑战协议，那么成功的概率在所有情况下几乎接近100%。此外，抵抗审查的能力还可以通过未来解决方案（如包含列表或多个并发提议者，例如BRAID、APS + FOCIL）进一步提高，降低乐观 Rollup因弱审查而失去用户资金的风险。

那么在强审查的情况下7天会足够吗？先前提到的51%攻击只能通过社会分叉解决。无指向性审查攻击尤其具有挑战性且无法借助用于弱审查的解决方案（如包含列表）来阻止。

有一个提议在客户端软件中开发半自动化的51%攻击恢复工具，基于一个Vitalik提出的结构。该审查检测解决方案进一步完善，包含以下两个步骤：

1. 轻客户端监控内存池，并检测某些交易在长时间内未包含在区块中的情况。
2. 如果特定交易在内存池中停留一天未被包含在区块中，“你是否同意进行社会分叉？”按钮被激活，让社区发起硬分叉，以基于这一共识。

假设该工具侦测到61%攻击，接下来的步骤是通过社会分叉转移到新链，废除攻击者的资金。在这种情况下，受 51% 攻击影响的资金必须保持锁定，直到社交分叉执行。类似的情况发生在 The DAO 硬分叉期间，黑客的资金在一个子 DAO 中被锁定了 27 天，才得以提取。以太坊社区能够在此期间进行硬分叉，防止黑客兑现资金（更多细节请见 Vitalik 的 Reddit 帖子)。

换句话说，即使发生 51% 攻击，资金也需要保持锁定，直到可以进行社交分叉。在这个背景下，乐观 Rollup中的 7 天提款期作为缓冲。如果在一周内没有进行社交分叉，乐观 Rollup中的用户资金可能会被盗取、在中心化交易所兑现或通过 Tornado Cash 混合，即使执行社交分叉，也几乎不可能将资金返还给用户。

总的来说，虽然乐观 Rollup中的 7 天提款期最初是为了应对弱审查而提出，但实际上，发生弱审查的可能性较小，而 7 天的时间在发生强审查并需要进行社交分叉时可以作为缓冲。

从这个角度来看，有人批评 OPFP 将这一时期缩短至 3.5 天使其在强审查时更易受到攻击。然而，这种批评并没有依据。由于 Optimism 仍处于第 1 阶段，守护者有缓冲时间来验证状态根的正确性，提款只能在额外的 3.5 天守护者期间结束之后进行。因此，即便发生强审查攻击，攻击者仍然需要等待 7 天才能提款。此外，攻击者还必须在整整一周内禁止所有与挑战相关的交易，以确保成功，因为守护者也需要被审查以防止他们停止确认恶意输出。

然而，关键点仍然是以太坊必须确保能够在 7 天期限内处理社交分叉。这意味着必须准备好检测 51% 攻击的工具，并且有足够的研究和模拟以确定是否可以在 7 天内实施社交分叉。只有这样，乐观 Rollup中的 7 天提款延迟才能被视为有效的保护措施。

3.6. 攻击向量 #3：利用欺诈证明系统中的漏洞

大多数挑战协议通过让参与者找到一个特定的点（指令或区块）在此确认意见不合，然后生成证明以显示另一个参与者的声明不正确来工作。用于生成此证明的虚拟机称为欺诈证明 VM，而在该 VM 之上用于证明生成的软件称为程序。每个协议使用不同的欺诈证明 VM 和程序，如下所示：

协议名称	欺诈证明系统
Arbitrum BoLD	WAVM (Wasm VM)
Optimism Fault Proof	Cannon + op-program
Cartesi Dave	Cartesi Machine (Risc-V VM)
Kroma ZK Fault Proof	Halo2 zkEVM w/ Tachyon

每个欺诈证明系统的目标是证明 EVM 中某个具体执行结果在链上是正确的。可是一旦这一系统（无论是 VM 还是程序）出错怎么办呢？

这一问题可以通过 Yoav Weiss 在 OVM 中发现的攻击向量来探讨。由于 OVM 的回滚功能存在漏洞，此攻击得以实现，但创造“欺诈交易”的前提对实施该攻击至关重要。欺诈交易指的是在Rollup中正常处理时执行，但在利用欺诈证明 VM 和程序的挑战过程中产生不同结果的交易。由于欺诈证明系统应该产生与 EVM 相同的结果，因此能够创造欺诈交易意味着欺诈证明系统中存在漏洞。

Yoav 在 OVM 的欺诈证明系统中发现了多个漏洞，并能够通过生成欺诈交易来模拟此攻击。

他所发现攻击的一个简单例子是：在 OVM 的 StateManager 中，指令 SSTORE 和 SLOAD（用于存储和读取状态）的汽油成本被错误记录。这意味着任何在合约中存储或读取值的交易（几乎每笔交易，除了简单的 ETH 转账）在挑战过程中都会被识别为欺诈交易，尽管它在Rollup中执行正确。

简而言之，如果系统中存在漏洞，以前正确执行的状态更改在挑战过程中可能会错误标记为无效，从而导致诚实参与者提交的输出被标记为错误。

这也是 OP Mainnet 最近将其错误证明系统从无权限模型转变为只有授权参与者才能加入的原因之一。在 OPFP 应用于主网后，安全审计揭示了欺诈证明系统（Cannon 和 op-program）及争议游戏挑战协议中的多个漏洞。为防止系统被利用，Optimism 于 8 月 17 日宣布将切换到有权限系统。

当然，利用 VM 漏洞可能对第 0 阶段或第 1 阶段的Rollup没有重大影响，因为安全理事会可以随时干预以纠正挑战的结果。

这是 OP Labs 之前提出的观点。实际上，OP Labs 在 Optimism Forum 分享了它的审计框架，概述了何时需要进行外部审核的标准。

（OP Labs 审计框架 | 来源：Optimism Forum)

在该框架中，最近的情况属于第四象限：“带培训轮的故障证明”。尽管这些情况与链安全性相关，但它们不会直接影响用户资金，因此未被纳入审核范围。这意味着即使漏洞被利用，安全理事会也能纠正结果。

然而，由于已识别出漏洞，需要加以解决。Optimism 在其 Granite 网络升级中修复了这些问题，使 OP Mainnet 重新回到第 1 阶段。

另一方面，系统中的漏洞在第 2 阶段Rollup中可能是关键。在第 2 阶段，安全理事会只能在链上可证明的漏洞情况下干预。由于在链上证明“挑战结果是因系统漏洞而错误"几乎不可能，如果在第 2 阶段Rollup中发生漏洞，用户的资金可能面临风险。

3.7. 解决方案 #3：多种证明

为防止此类问题，在代码进入生产环境之前进行彻底的审计至关重要。然而，欺诈证明 VM 和程序是复杂的软件系统，系统越复杂，发生漏洞的可能性就越大。因此，即使进行严格审核，漏洞仍然可能出现。我们需要探索超出审计的其他策略。

一种方法是在同一系统中使用多种证明系统。系统在挑战过程中可以同时使用不同的 VM 和程序生成多个欺诈证明，从而比较结果。这将创建一个即使在发生漏洞的情况下也能保持安全的系统。

例如，想象一个同时使用 Optimism 的 Cannon 和 asterisc ZK Fault Proof VM（利用 Risc-V）的多证明系统。在挑战的情况下，以下情况将发生：

1. 如果检测到错误输出，挑战者生成挑战并启动分割。
2. 一旦通过分割找到一致性的区块，两个子游戏同时进行：
   1. 使用传统 OPFP 方法的 Cannon 的子游戏。
   2. 使用 asterisc 生成 ZK Fault Proof 的子游戏。
3. 完成两个游戏后，验证两个不同的欺诈证明。

如果两个证明均通过验证，挑战者胜利；如果两个证明均失败，挑战者失败。然而，如果一个证明通过而另一个证明失败，则表明在证明生成过程中，某个 VM 或程序发生了意想不到的漏洞。

在这种情况下，像安全理事会这样的实体将介入以调整挑战结果。这确保系统即使Free of bugs也不会违反 “安全理事会只在可链上证明的漏洞情况下干预”的条件。

这是 Optimism 进行第 2 阶段的持续努力之一。为了支持这一点， OPFP 的争议游戏被设计为模块化，允许多种欺诈证明系统自由实现，同时定义一个最小接口来支持这一点。

4. 改进的可能性

在前面的章节中，我们探讨了乐观 Rollup协议的设计以及它们在挑战和欺诈证明验证过程中可能出现的漏洞。本节讨论每个协议的问题及解决方案，以及欺诈证明系统和乐观 Rollup的未来前景。

4.1. 各协议改进空间

1) Arbitrum BoLD

BoLD 有一个合理的经济挑战协议，因为它将协议的最大延迟限制为一周，并确保在攻击者的资金超过防守者的 6.5 倍时防止 Sybil 攻击。然而，BoLD 提出两个显著问题：

1. 6.5 倍的资源比给予防守者的优势过少。
2. 提交根声索的担保金为 3600 ETH，金额过于庞大。

第一个问题可以使用 ZK 技术来解决。BoLD 将挑战拆分为多个级别，以减少历史承诺计算所需的资源。利用 ZK，这可以简化为单一层级。

这一概念类似于来自 Cartesi 的 Gabriel 提出的 BoLD++ 建议。当挑战多层级时，增加资源比率将导致顶级中担保金规模的呈指数上升。然而，使用单一层级时，资源比率可以更容易增加，从而使协议对 Sybil 攻击的抵抗力更强。

第二个问题，3600 ETH 的担保金，则更为棘手。BoLD 的担保金规模不仅是为了解决 Sybil 攻击，也是为了遏制延迟攻击。担保金额是 TVL 的函数，即使使用 ZK，也无法显著压低。为此，BoLD 正在实施一种池化担保机制，允许多个参与者共同为担保金出资。

2) Cartesi Dave

Dave 有效地通过其锦标赛结构应对 Sybil 攻击，但如前所述，它易受到延迟攻击。最大延迟时间作为恶意声索的数量 NA 和挑战层数 L 的函数为：

Td = 7 x [log2(1 + NA)]L（天数）

如果 NA = 7 且 L = 3，则该协议可能经历长达四个月的延迟，给用户带来重大不便和损失，因为提款被延迟。

ZK 可以帮助减轻这一问题。通过将层数 L 固定为 1（如 BoLD++），最大延迟时间可减少为：

Td = 7 x log2(1 + NA)（天数）

据报告，Cartesi 正在使用 RISC Zero 的 ZK 技术进行这项改进。然而，仍然存在关于这是否足以完全阻止延迟攻击的担忧。如果 NA = 7，则协议仍可能面临长达 2 周的额外延迟，而攻击者 的成本仅为7 ETH 的担保金以及汽油费和链下历史承诺成本。对于 TVL 较高的链而言，这一惩罚可能不足以阻止延迟攻击。

（使用 BoLD 风格的交叉挑战的 Dave | 来源：L2BeatMedium)

有建议称，Dave 应采用 BoLD 风格的挑战，每轮有 8 名参与者，而不是每轮进行 1 对 1 的比赛，类似传统锦标赛。在这种情况下，延迟时间的计算方式如下：

Td = 7 x log8(1 + NA)（天数）

在这种结构下，攻击者至少需要提供 64 倍的担保，才能将挑战延迟到两周以上，相当于需要总共 64 ETH 的担保金，以及大量的链上和链下成本。

然而，这种方法有削弱防守者在 Sybil 攻击中的优势的缺点。虽然 BoLD 提供了一个让防守者相比攻击者有 N 倍更有优势的结构，但 Dave 剦造了一种防守者在 Sybil 攻击面前具有指数级的更大优势的局面。

总的来说，Dave可以透过使用ZK Fraud Proofs 有效限制延迟攻击的制定途径。虽然施加像 BoLD 这样的结构可能会提高抵抗延迟攻击的效果，但这可能会导致防守者在面对 Sybil 攻击时的优势下降的权衡。

3) Optimism Fault Proof (OPFP)

OPFP 的缺陷是因为攻击者和防守者所产生的成本相等，因此它易受 Sybil 攻击。OP Labs 提出了一项解决此问题的提议，以及 Dispute Game V2。

与每次分割都提交担保金的原 OPFP 相比， Dispute Game V2 仅要求参与者在分割开始时提交担保金。此外， Dispute Game V2 引入了分解机制，允许参与者在分支点同时提交多个声索，从而在大多数情况下减少交互的数量。

（Dispute Game V2 的分支声索 | 来源：Optimism Specs GitHub)

在之前的 OPFP 中，Sybil 攻击的向量有：

1. 创建大量挑战，耗尽防守者在担保金和汽油费上的资金。
2. 不断提交欺诈性输出，迫使防守者反应并消耗资源。

分支声索的引入分别解决了这两个向量。首先，诚实参与者在地裂时不需额外提交担保金，而恶意挑战者在每次创建新的挑战时必须提交担保金。因此, 如果担保金额合理设置，恶意挑战者大量创造挑战将变得不可持续。

其次，由于 Dispute Game V2 中较高层的担保金更大，持续提交欺诈性输出对攻击者来说的成本变得比防守者高。

因此，OPFP 可以通过在 Dispute Game V2 中引入的分支声索有效对抗 Sybil 攻击。

4) Kroma ZK Fault Proof (Kroma ZKFP)

Kroma ZKFP 面临着双重挑战，即对 Sybil 攻击的脆弱性以及不完善的证明系统。Kroma ZKFP 进展到第 1 阶段必须解决以下两个问题：

1. 分解起始点是基于最后提交的输出，而不是最后确定的输出。
2. 验证者未经审查挑战是否基于正确的批数据。

Kroma 计划从 Scroll 的 Halo2 zkEVM 切换到 Succinct SP1 zkVM，以解决这两个问题并推进至第 1 阶段。

Kroma 预计会修改其挑战过程以与 Optimism 的 Dispute Game 接口对齐。具体的调整详见 [Kroma 的规范](https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://specs.kroma.network/experimental/zk-fault-dipute-game/overview.html%26amp;sa%3DD%26amp;source%3Deditors%26amp;ust%3D1727947116392030%26amp;usg%3DAOvVaw3yFkPG0puzBnDnGov_KV4g&sa=D&source=docs&ust=1727947116478565&usg=AOvVaw3aj20R1G7e9fKSkW9W3awP），这将使分解起starting point 往回移动至一周前的最后确定输出，以解决第一个问题。

对于第二个问题，Kroma 将利用基于 ZK 的 信任推导。以下是它的工作原理：

（使用 ZK 的无信任推导 | 来源：Lightscale Notion)

想象一下，我们想证明特定的 L2 区块 T 是否正确执行。在生成 ZK 证明之前，我们必须验证区块 T 的交易数据是否基于 L1 批数据正确构造。

在这里，Kroma 打算通过 ZK 验证批数据是否已正确从 L1 获取。如果数据仅通过受信 RPC 从 ZK 程序外获取，则无法确认批数据是否已被篡改。可以通过生成区块哈希从 O 区块（L1 中 L2 区块 T 的来源）到 C 区块（挑战创建时的 L1 区块）的连接性 ZK 证明，验证程序是否访问了正确区块并获取了批数据。如果挑战者根据错误批数据构建 L2 区块 T，挑战者引用的 L1 区块哈希将与实际包含包括 T1 的批数据的 L1 区块哈希不同，它还将与 C 区块不连接。因此，只要没有哈希碰撞，就可以通过 ZK 验证 L1 区块的连接性来证明挑战者是根据正确的批数据构建 L2 区块的。

Kroma 计划利用 ZK 验证批数据的准确性，但可以检查 L1 区块 O 到 C 的区块哈希的连接性。如果挑战者根据错误的批数据构建 L2 区块 T，则他们引用的 L1 区块哈希将与包含正确批数据的区块不同，并且与 C 区块不连接。由于不存在哈希碰撞，因此可以通过这一方法验证正确的批数据在挑战过程中。

通过这些改进，Kroma ZKFP 可以可能转向第 1 阶段。然而，要达到第 2 阶段，Kroma 需要额外的解决方案来防范 Sybil 攻击，包括将挑战协议更改为 All-vs-All 以及重新设计担保机制。

4.2. 总结

Arbitrum BoLD	Cartesi Dave	Optimism FP	Kroma ZKFP
挑战类型	All-vs-All 并发挑战	1 对 1 顺序挑战	All-vs-All 并发挑战	1 对 1 并发挑战
额外延迟	最大 1 周	数周至数月	根据用户行动最多可达9天	无
Sybil 攻击脆弱性	易受 91% 攻击	安全	易受 51% 攻击	易受 51% 攻击
担保金额	3600 ETH	1 ETH	0.08 ETH（挑战期间最高可达 ~700 ETH)	0.2 ETH
缺点	高担保金成本 & 低资源比	易受延迟攻击	易受 Sybil 攻击	易受 Sybil 攻击 + 不完整的证明系统
改进	BoLD++（ZK 实现）	ZK 实现	Dispute Game V2	Dispute Game + 无信任推导

5. 欺诈证明的未来

5.1. 第 2 阶段Rollup - 你的资金是安全的

如上所述，乐观 Rollup正在向第 2 阶段发展。Arbitrum 目标是基于 BoLD 实现第 2 阶段。BoLD 的实施已在 治理论坛 上发布并获得广泛支持，其实施目前已在测试网上进行。如果没有发现重大安全问题，Arbitrum 很可能会在今年年底前通过 BoLD 达到第 2 阶段。

Optimism 也在努力实现第 2 阶段。为了使 OP Mainnet 达到第 2 阶段，Dispute Game V2 必须完成，并且需要多种证明机制以实现多重证明。尽管规范仍在进行中，但 Dispute Game V2 有效解决了现有 OPFP 的弱点，通过提供对 Sybil 攻击的强保护，使其更接近第 2 阶段。此外，多个证明也在积极开发中，各个团队包括 OP Labs、Succinct、Kroma 和 Kakarot 致力于致力于创建多样的证明 OP Stack 的方法。因此，预计 Optimism 在明年上半年也将朝着第 2 阶段迈进，前提是没有重大问题。

这两种Rollup向第 2 阶段的过渡可能对Rollup生态系统产生重大影响。Arbitrum 和 Optimism 各自有自己的Rollup框架，分别为 Arbitrum Orbit 和 OP Stack。它们向第 2 阶段的转变意味着使用这些框架的所有Rollup也将转向第 2 阶段。

因此，从今年年底到明年，预计具有大量用户基础的主要Rollup，例如 Arbitrum、OP Mainnet 和 Base，将过渡到第 2 阶段，从而继承以太坊的完整安全性。这将可能让 “Rollup只是多重签名” 或 “Rollup随时可能夺走你的资产” 等批评声沉默。

5.2. ZK 欺诈证明是未来

大多数讨论的协议都将受益于 ZK 欺诈证明的实施。例如，将 ZK 应用于 Arbitrum BoLD 可能会提高资源比率，增强其对 Sybil 攻击的抵抗力，而 Cartesi Dave 则可以降低对延迟攻击的脆弱性。OPFP 也正在投入研发 ZK 多重证明系统，这可能会降低担保金额并改善协议安全性。

值得注意的是，ZK 欺诈证明不仅可以减少验证者之间的交互数量。更少的交互意味着验证者所需的资源大幅减少，从而允许降低担保金额，使得更多参与者能够参与该协议。此外，这减少了最大可能的延迟，提高了整体协议的安全性。

通过这种方式，ZK 欺诈证明在乐观 Rollup的安全性和去中心化方面发挥至关重要的作用。

5.3. ZK Rollup结局又如何？欺诈证明是否会减弱？

在此阶段，一些读者可能会问：

如果欺诈证明和挑战机制如此复杂，ZK Rollup会不会是更好的选择呢？

在某种程度上，这是对的。在 ZK Rollup中，达到第 2 阶段并不需要复杂的经济考虑，用户的资金在 L1 审查发生时没有被盗的风险，用户可以在数小时内提款。

从乐观 Rollup转向 ZK Rollup的过渡可能会比预期的更快。这是因为 ZK Rollup的主要缺点——高证明生成成本和时间——正在迅速改善。最近，Succinct Labs 推出了 OP Succinct，这是一种基于 OP Stack 的 ZK 版本，提供了一个轻松启动 ZK Rollup的框架。

（推出 OP Succinct | 来源：Succinct Blog)

不过，仍有一些考虑因素。第一个是成本。在 OP Succinct 中生成一个区块证明的成本已知在 $0.005-$0.01之间，运行证明者的每月成本估计在 $6,480 到 $12,960 之间。如果链的 TPS 很高，这些成本可能会进一步增加。

（在各种网络中证明成本的基准 | 来源：Succinct Blog)

例如，在 OP Succinct 的 Base 上生成每个块的平均证明成本约为 $0.62。基于此计算的每月成本达到 $803,520。这是相对于乐观 Rollup所增加的额外成本，即使 ZK 成本下降，ZK Rollup的运营成本始终高于乐观 Rollup。

第二个考虑因素是它对去中心化的影响。ZK Rollup中的验证者需要运行证明者，这比在乐观 Rollup中运行欺诈证明程序更困难且成本更高。此外，由于 ZK 系统中的证明生成速度较慢，用户无法实时验证交易。虽然更高的硬件规范可以提高证明生成速度以与交易执行相匹配，但这意味着运行证明者需要高规范的计算环境。理想情况下，任何人都应该能够运行一个节点以确保链的安全，但 ZK 仍未达到这种水平。最后，ZK rollups 基于高度复杂的数学和密码学，这种复杂性超过了欺诈证明和挑战协议。因此，ZK 系统在可以安全使用于生产环境之前，需要广泛的测试。

Arbitrum 正在追求一种混合协议，将 ZK 和乐观方法结合在一起，作为其终极目标。该协议将主要作为乐观 rollup 运行，仅在快速提取资金时生成 ZK 证明。这在需要在链之间快速重新平衡资金的场景中非常有用，例如交易所或桥接，或者用于实现链之间的互操作性。

总之，乐观 rollup 方法现阶段似乎是有效的，同时也将 ZK 视为混合方法。但是，随着 ZK 证明生成成本和速度的持续改善，更多的乐观 rollups 可能会认真考虑在未来转向 ZK。

5.4. 欺诈证明仅适用于 Rollups 吗？

我们已经研究了以太坊的乐观 rollups 及其欺诈证明机制。还有哪些其他的欺诈证明使用案例？

1. 重新质押协议

欺诈证明可以在重新质押协议中积极利用。让我们通过以太坊上的代表性重新质押服务 Eigenlayer 来深入探讨这个问题。

Eigenlayer 是一项允许以太坊安全性通过重新质押而出租的服务。Eigenlayer 的运营者可以根据在 Eigenlayer 内的委托合约存入用户的 ETH 或 LST，并通过选择多个 AVS（主动验证服务）参与验证。通过 Eigenlayer，协议可以轻松构建 AVS，并减少启动初始验证者的成本。

与任何其他区块链类似，AVS 会奖励成功验证的运营者，并在他们采取恶意行为时对其进行惩罚。这就是欺诈证明可以在惩罚过程中使用的地方。

（AVS 的惩罚示例 | 来源: Eigenlayer GitHub)

例如，考虑一个桥接 AVS。桥接 AVS 的前提是必须正确地将用户的资金转移到目标链，任何恶意操纵交易的运营者都应该受到惩罚。如果发生这种操纵，发现不当行为的挑战者可以在争议解决合约中创建一个欺诈证明，主张运营者错误地执行了桥接。如果欺诈证明被认为有效，AVS 可以调用 Eigenlayer 中的惩罚合约，停止对该运营者的任何奖励。

虽然这项惩罚功能尚未在 Eigenlayer 中实现，但他们最近宣布了共享安全模型，将在下一个版本中包括惩罚。这将使欺诈证明的使用成为可能。

2. 数据可用性层

欺诈证明也可以在数据可用性（DA）层使用。这个领域的一个代表性例子是 Celestia 提出的并实施的欺诈证明。Celestia 拥有一种技术，允许轻节点基于数据可用性抽样验证数据是否存储正确。让我们来详细了解一下这个概念。

轻客户端应该能够验证一个区块是否得到了大多数（超过 67%）验证者的同意，而无需下载整个区块链的所有数据。然而，轻客户端很难验证每个区块的所有验证者签名，随着验证者数量的增加，这几乎变得不可能。

这就是 Celestia 提出有趣概念的地方。在 Celestia，即使大多数验证者是恶意的，它也提出了一种方法，单个诚实的全节点能够告诉轻客户端拒绝一个错误的区块。这个单个诚实的全节点可以使用欺诈证明来保证其“诚实性”。

Celestia 中有两种类型的欺诈证明：

• 数据的欺诈证明
• 状态转换的欺诈证明

首先，数据的欺诈证明工作如下：Celestia 允许轻节点在不直接下载整个区块内所有数据的情况下验证验证者持有的数据是否正确。为了实现这一点，Celestia 使用了一种称为数据可用性抽样（Data Availability Sampling, DAS）的技术。

（Celestia 的数据可用性抽样 | Celestia Docs)

Celestia 的验证者将交易数据结构化为一个 k x k 矩阵，然后使用称为二维 Reed-Solomon 编码的技术将其扩展为 2k x 2k 矩阵。他们会计算每行和每列总共 4k 个 Merkle 根，并将进一步哈希这些 Merkle 根后的结果包含在区块头中并传播。

仅凭区块头中的 Merkle 根信息，轻节点就可以验证 Celestia 的验证者是否持有正确的数据。轻节点从 2k x 2k 矩阵中随机点请求数据，并从验证者那里获取相应行和列的 Merkle 根。如果这些数据能够验证与区块头中的值一致，则可以信任这些验证者持有正确的数据。

然而，一个重要的考虑因素是：如果验证者恶意地执行 Reed-Solomon 编码怎么办？Celestia 通过实现一种称为“不良编码欺诈证明”的机制来解决这个问题。

如果 Celestia 的全节点在区块恢复过程中发现编码存在错误，它会生成一个欺诈证明，包含区块高度、错误编码的部分以及错误证据，然后将其传播给轻节点。轻节点验证该证明以确认数据确实编码错误，使它们能够停止使用错误数据。

此外，Celestia 还提出了状态转换的欺诈证明机制。

（Celestia 中的区块架构 | 来源: Contribution DAO Blog)

Celestia 的区块结构包括不同间隔的交易跟踪数据。这使得全节点可以轻松构建欺诈证明，轻节点能够在不执行整个区块的情况下检测到错误的状态转换。然而，由于复杂性问题，该机制尚未在 Celestia 的主网实施。

总之，DA 层中的欺诈证明可以在不依赖共识的情况下起到过滤不正确数据和状态转换的作用。

3. 机器学习

人工智能和区块链在 2024 年是热门话题，并在这一领域进行了大量研发。其中一个最突出的方面是区块链与机器学习的结合。

将机器学习应用于区块链的主要原因如下：

• 数据可靠性： 区块链以去中心化的方式管理数据，所有交易公开透明地记录。如果机器学习模型从区块链数据中学习，这些数据来自可靠来源，从而减少了篡改的可能性。
• 模型的透明性和可验证性： 当机器学习模型在区块链上执行时，模型的更新和结果会在链上记录，使其可验证。这防止了在中心化环境中可能发生的结果操控或偏见。

这里的关键因素是验证机器学习模型是否得到正确训练。然而，机器学习计算密集型极高，几乎不可能在区块链运行时环境中完全执行它们。因此，像 opML 和 zkML 这样的框架应运而生，以便在区块链环境中有效验证机器学习模型的训练。opML 采用乐观的方法进行模型训练，将结果记录在区块链上，并通过挑战机制纠正错误。

让我们更详细地看看 ORA 提出的解决方案，ORA 是一个为区块链提供人工智能基础设施的项目。opML 挑战过程与 rollup 挑战非常相似，包含以下三个关键组件：

• 欺诈证明虚拟机（Fraud Proof VM）： 该虚拟机执行机器学习推断，功能类似于 Arbitrum 的 WAVM 或 Optimism 的 Cannon。
• opML 智能合约： 此合约验证欺诈证明，起到类似于 Optimism 的 MIPS.sol 合约的作用。
• 验证游戏： 发行挑战的验证者通过二分法与服务器互动，识别虚拟机中的单个错误步骤，然后为该步骤生成欺诈证明并提交给 opML 合约。

（ORA opML 中的验证游戏 | 来源: ORA Docs)

通过这一欺诈证明机制，opML 利用区块链的安全性和可信性，同时提供一个经济高效的机器学习模型训练和验证环境。

6. 结论

乐观 rollups 正在投入巨大的精力改善欺诈证明和挑战协议，以继承更多以太坊的安全性并创建一个更多信任最小的链。预计 Arbitrum 将通过 BoLD 在今年年底达到第二阶段，Optimism 也在努力朝着第二阶段发展，依靠争议游戏 V2 和多重证明机制。到明年，乐观 rollups 的用户将能够以更高的安全性与网络进行交互，而不必担心“rollup 可能会窃取他们的资金”。此外，Vitalik 在其博客中提到的第一阶段以上的 rollups 数量预计将会增加。

然而，各个协议仍有改进空间，这其中很多可以通过 ZK 欺诈证明来加强。Kroma 已经在此基础上推进其协议，而其他协议，如 Arbitrum、Optimism 和 Cartesi 可以通过 ZK 欺诈证明保持更安全和更去中心化的方法。

欺诈证明是一个不仅仅是 rollups 还包括其他协议投入大量研发资源的领域。基于“仅需要一个诚实的参与者”的前提，欺诈证明与 ZK 相结合，可以为整个区块链构建一个 信任最小化 的架构，它们的影响将逐渐成为我们可以亲身体验的事物。

7. 参考文献

L2Beat

Fraud Proof Wars | Luca Donnoh at L2Beat

Arbitrum Docs

Optimism Docs

Optimism Specs

Permissionless Refereed Tournaments | Cartesi

Kroma Specs

BoLD: Fast and Cheap Dispute Resolution

Economics of BoLD

Why is the Optimistic Rollup challenge period 7 days? | Kelvin Fichter at OP Labs

Fraud Proofs Are Broken | Gabriel Coutinho de Paula at Cartesi

Optimistic Time Travel | Yoav Weiss

About the First Successful Challenge on Kroma Mainnet

Unpacking progress in baseline decentralization | OP Labs

Non-attributable censorship attack on fraud-proof-based Layer2 protocols

OP Labs Audit Framework

Trustless Derivation | Kroma

Introducing OP Succinct: Full Validity Proving on the OP Stack | Succinct

Eigenlayer GitHub

Celestia Docs

Contribution DAO Blog

ORA Docs

• 原文链接： research.2077.xyz/the-st...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～