乐观 Rollup：以太坊扩展的现在与未来

乐观 Rollup：以太坊扩展的现在与未来

我们听到很多关于 ZK Rollup（ZK rollups）被认为是通用智能合约系统未来的讨论。我们并不赞同——这篇文章解释了原因。它汲取了我们在运营一个开放、安全、与EVM兼容的第二层（L2）链，其中有数百个去中心化应用（dapps）、数十万用户和数百万交易中所获得的实践经验。

我们构建 Arbitrum 作为乐观 Rollup（Optimistic Rollup，OR），因为我们相信 OR 是满足用户对安全、无信任、与EVM兼容的 L2 的最佳方式。我们选择乐观而非 ZK 是因为乐观系统固有的可扩展性和成本优势；即使到今天，我们仍会做出相同的选择。想知道原因，请继续阅读。

（By Michael Johnson — 最初发布于 Flickr，标题为 Apples & Oranges — They Don’t Compare, CC BY 2.0，https://commons.wikimedia.org/w/index.php?curid=4289506）

等等！这篇文章有多长？

是的，这篇文章很长，并且有些地方比较技术性。人们对他们的区块链所希望的东西很简单，但谈论提供这些优势所需的技术时，我们需要进入一些细节。我们希望技术社区能够理解我们的观点。

如果你不想全部阅读（我们不怪你！），这是一个快速的摘要。

• 人们希望一个链在无信任的情况下提供安全、保证进度、可见性和快速的最终确定——并且希望以低成本和与现有工具兼容的方式提供。
• 我们深入探讨了如何使用乐观 Rollup与 ZK Rollup来提供这些属性的细节。
• 乐观 Rollup可以以更低的成本提供用户所需的属性，这与构造 ZK 证明的极高链下成本有关。
• 由于ZK证明成本高昂，全体参与 ZK 协议可能需要特殊硬件和/或大规模并行计算，从而使网络有效地更加集中。
• ZK 声称的优势要么也可以得益于乐观系统，要么需要牺牲重要的安全性或可用性特征。
• 乐观 Rollup在操作成本方面占据很大优势，因为执行代码的成本远低于计算其复杂密码学证明的成本。

让我们从头开始

让我们从以太坊开始。一位以太坊用户创建交易以部署或与智能合约交互。你可以将以太坊交易看作几种不同的方式。从一个角度看，你可以把它视为一个不透明的数据块。但是如果你查看其内容，交易当然不仅仅是这样；它是一个请求，要求智能合约执行某个操作：记录一些信息、移动某些资产等。

当一个交易在以太坊上发布时，会发生两件重要的事情。首先，它被包含进来，以太坊就达到了一组有序交易的共识。第二，以太坊执行这些交易并计算最终的状态更新。

汇总：我们共同拥有的内容

让每个以太坊节点执行每个交易是非常昂贵的，而汇总是显著减轻这一负担的一类扩展解决方案。实际的交易执行不会在以太坊上进行，而是转移到第二层（“L2”）领域。

但是等一下——汇总应该由以太坊进行安全保障。这意味着我们需要以太坊以某种方式为交易执行的正确性做保证，即使它发生在 L2 领域。那么，怎样才能让以太坊为汇总状态盖章呢？

简单地说，答案是：证明。汇总使用专门的证明向以太坊证明其正确性，允许以太坊在不实际执行交易的情况下验证正确性。

汇总：乐观 Rollup和 ZK 的区别

这些证明看起来相当神奇：允许以太坊在不实际进行执行的情况下验证汇总状态。你可能想知道这些证明是什么样的，以及它们在实践中如何实施。这就是各种汇总的不同之处。

ZK Rollup使用 有效性证明（validity proofs）。ZK 依赖于某个方发布一个简洁的密码学证明，证明该方知道一个以特定状态结尾的有效链。这要求证明方执行该链，以知道如何构造证明，然后通过执行一系列复杂的密码学操作来构造证明。证明由链上的 L1 合约进行检查。ZK 证明简洁，验证的成本足够低，可以通过以太坊交易执行。

乐观 Rollup使用不同类型的证明：欺诈证明（fraud proofs）。如其名所示，乐观 Rollup在向以太坊发布更新状态时，并不发布任何证明。任何人都可以发布一个汇总块，包含关于执行某些交易的正确结果的声明。其他节点执行相同交易，如果不同意第一个节点的声明，可以发布挑战。一个高效的争议协议解决任何分歧，确保正确的当事方将赢得挑战。各方强烈倾向于仅发布正确的声明，并挑战不正确的声明，因此在常见情况下，所有节点都简单执行所有交易，而证明代码从未被调用。整个过程由 L1 合约管理。

那么，哪种类型的汇总更好呢？在本文的其余部分，我们将比较 ZK 和乐观 Rollup在几个维度上的表现，并解释为什么我们相信未来是乐观的，且像 Arbitrum 这样的乐观 Rollup本质上更加可扩展。

乐观 vs ZK：成本

乐观 Rollup和 ZK 之间或许最关键的区别是成本。

乐观 Rollup要求节点简单地执行合约。例如，如果一个合约执行加法操作，节点就执行那个加法操作。

ZK 另一方面，需要生成一个复杂的密码学证明，这需要数百或数千次昂贵的椭圆曲线操作才能将那个加法操作包含在证明中。ZK 每条合约中的每条指令都要承担这种费用。在每条指令上生成一个复杂的密码学证明，而不是简单执行指令，这成为 ZK 的一项固有成本劣势——而且是巨大的。

ZK 支持者有时会争辩说，只有一个方需要创建证明，而乐观 Rollup则需要系统中有许多节点。但如果你正在运行一个大规模链，无论你使用哪种证明系统，它都将拥有许多节点。真实的链需要许多节点来服务于非变更调用、搜索事件日志、向用户展示交易数据、提供用户从 L1 提取资金所需的数据等等。乐观链的安全性依赖于这些节点执行它们已经需要做的工作——执行交易并跟踪链的正确状态。

另一方面，由于构建昂贵的基于椭圆曲线的证明是一项非常大的 附加 成本。要想对 ZK 证明规模化有任何希望，你将需要特殊的硬件设备或大规模的并行计算——或两者兼备。这是非常昂贵的。

裁决：乐观系统具有内在且巨大的成本优势。

乐观 vs ZK：与 EVM 兼容性

在我们构建 Arbitrum 时，EVM 兼容性是一个重要考虑因素。Arbitrum 完全与 EVM 兼容；它具有相同的 RPC 接口，并接受与 EVM 相同的字节码。这在实践中的意义是，任何为以太坊编写的代码在 Arbitrum 上都可以直接使用。

我们已运行开放的、与 EVM 兼容的链（包括测试网）超过一年，我们了解到真正兼容可能有多具挑战性。前95%的兼容性并不是太困难，但这在实际上并不够好，要做到更好需要大量的努力和一个不妨碍的产品架构。

ZK 系统在兼容性方面差别很大。一些系统忽略它，视其为遗留工具，并鼓励人们学习其自定义语言。

一些 ZK 系统并不努力实现兼容性。 对于不关心兼容性的开发人员和用户来说，这是可以的。

我们并不是在争辩说，在清晰的情况下，EVM 是最好的东西。我们争辩的是，考虑到与 EVM 相关的开发者数量、代码和开发工具链，EVM 带来的各种实际优势是非常显著的。假设一个在以太坊上部署的项目希望扩展到汇总。不得不用新语言重写代码，委托新的安全审计，并维护多个代码库是繁琐且容易出错的。但即使对于尚未编写任何代码的新项目，EVM 兼容性也是一个巨大的优势，因为它允许这些项目利用现存的代码、工具和人才库。

一些 ZK 项目正在朝着与 EVM 兼容的版本努力，但尽管有模糊的声明，我们尚未听说有任何代码被发布可以在 ZK Rollup上运行 EVM 合约。现有的初步系统具有显著的不兼容性。例如，一个声称兼容 EVM 的 ZK 系统 未能实现 ADDMOD、SMOD、MULMOD、EXP、SELFDESTRUCT 和 CREATE2 操作码；正在考虑移除对 XOR、AND 和 OR 的支持；不支持标准交易格式；不支持任何预编译合约；并且可能会限制交易中的合约调用次数。对于 ZK 模型，似乎存在根本性**的不兼容性，保证即使在最好的情况下，ZK EVM 兼容性也将伴随着大量细则，且不会支持乐观 Rollup所能实现的完全兼容性。

值得澄清的是，今天存在几个应用专用的 ZK 系统（例如 Zcash、ZKSync 1.0、Loopring）。实际上，其中一些系统运行良好。核心区别在于这些系统是经过精细调整和特别优化以适合 ZK 实现的特定应用。今天不存在的是一个通用编译器，它能够以兼容的方式将代码从 EVM 转换为 ZK 电路。尽管一些团队声称在致力于此，但尚无公开代码可以使用，或对用户定义的 ZK-EVM 合约的证明成本进行的基准测试。根据我们的知识和所有公开可用的数据，我们相信这些成本将是不可承受的。

裁决：只有乐观系统支持完全的 EVM 兼容，并且成本极低。

乐观 vs ZK：无信任可见性与压缩

在设计 Arbitrum 时，我们的一个关键属性是 无信任可见性。简单来说，无信任可见性意味着任何人都可以在不依赖于中央方的情况下，查看或推导链的内容。重要的是，这不仅意味着每个人都会看到偶尔的状态快照——还意味着每个人可以查看链的完整历史——它是如何达到当前状态的。一个实用的链使得任何人都能运行一个支持非变更调用的节点，搜索事件历史，并查看每个交易——而不需要依赖中心化的数据提供者。无信任可见性使这一切成为可能。

坦率地说，一些现有的 ZK 系统在可见性方面有所妥协，并试图对其不提供完整区块链功能的事实进行推脱。当你听到对“压缩”的讨论时，请仔细倾听。他们是在说他们以更高效的方式编码链的内容（这是 Arbitrum 所做的，并且在我们的 Nitro 发布中会做得更好）？还是在说链的某些历史部分根本不公开，除非中央数据提供者愿意稍后将其分享给你？

请记住，ZK 证明只能证明 证明者知道 一条有效链。该证明并未告诉 你 那条链是什么，甚至如果你拥有足够的数据来验证证明，你可能没有足够的数据来重建这条链的历史。

例如，假设Alice提交了一笔支付Bob 1 ETH 的交易，Bob紧接着提交了一笔支付查理 1 ETH 的交易。稍后你验证了一个证明，证明Alice的余额比之前少了 1 ETH，Bob的余额没有变化，而查理的余额比之前多了 1 ETH。

但是发生了什么？Alice支付了Bob吗？Bob支付了查理吗？也许Alice直接支付了查理。也许Alice烧毁了一ETH，而查理是由其他人支付的。也许戴安娜是中介，而不是Bob。Bob查看区块链以寻找证据，但使用一些不提供链可见性的 ZK Rollup，他无法判断。

许多智能合约应用不仅需要知道偶尔的检查点。他们需要了解链——了解 发生了什么 和如何达成最终状态。ZK Rollup有时声称比乐观 Rollup提供更好的“压缩”，但隐藏链的数据，使得只有证明者知道，这不是压缩；这实际上是删除了重要数据。如果一个 ZK 提供者说他们“都不需要”发布链的历史，实际上他们在说的是，他们不能保证链的可见性。放弃链可见性的保证不是我们愿意做出的妥协。

裁决：乐观系统以低廉的成本提供无信任可见性。

乐观 vs ZK：无信任、及时的最终确定

考虑汇总时，一个关键要求是它是否提供无信任、及时的最终确定。简单来说，这意味着在你提交一个交易后，该交易的结果应该很快且确定地为你和其他人所知，没有人能够更改或撤销它。

在我们看来，实现及时最终确定的最佳方式是将交易的排序与其执行分开。排序生成一系列最终的提议交易，而执行尝试按顺序执行这些交易。如果交易的执行是确定的，如在 Arbitrum 中那样，那么确定交易序列的最终确定就足够了，因为结果是交易序列的一个确定函数。如果每个人都知道交易的序列，那么每个人都可以轻松确定结果。

确定序列的最终确定需要将序列发布到 L1 链上，并包含足够的信息，以允许任何人自己执行交易，从而以无信任的方式确定结果。理想的汇总是尽可能频繁地将已排序的交易数据发布到 L1 链上。

在乐观系统中，发布到 L1 链的开销很小，实际上，Arbitrum 通常每分钟左右将已排序的交易数据发布到 L1 链，提供给用户快速的最终确定，并保证没有人能够撤回他们的交易。每小时左右会进行一次新的乐观 结果 断言，但由于序列已经得到最终确定且执行是确定的，因此这不会减慢最终确定的速度。

原则上，ZK 系统可以以类似的方式运行；即，将交易的排序—可以频繁地发布到 L1—与它们的验证分开，而验证则在后续进行，偶尔提供有效性证明。然而，以这种方式操作的 ZK Rollup需要将基本上与乐观系统发布的相同数据也发布到 L1 链；上述所谓的“压缩”技术将没有可用性。为了解决“压缩”技术的有效性，必须在每次批量发布 L2 交易时，在同一个 L1 交易中实时证明一系列 L2 交易的有效性。

因此，试图采用所宣扬的“压缩”技术的 ZK Rollup则面临两个选择：

1) 每分钟左右发布已排序的交易以及执行的证明：这保持快速的最终确定，但需要每分钟生成一个离线 ZK 证明并在 L1 链上进行验证。在线发布 ZK 证明的费用估计在 50 万到 500 万 gas 之间，具体取决于实现。

2) 每小时发布已排序的交易以及证明：这使 ZK 证明检验的成本保持合理，但将最终确定的时间延长至一个小时。在用户将交易提交给 ZK 操作员后到其发布到链上的这一小时内，用户没有保障自己交易将被包含，只能信任操作员的说法。

如果我们正在构建一个 ZK 系统，我们会发现这两种选择都不可接受——第一种选择成本太高，第二种选择未能提供及时的最终确定。我们最终可能会使用同样类型的排序者，并将在 ZK 版本的 Arbitrum 中在线发布基本相同的数据。

如果你听到有人夸口说 ZK 可以将数小时的数据压缩成一个点，请保持警惕。如果他们只是发布在长期内的单个数据点，那么这意味着他们在该期间内并未提供最终确定。

裁决：实际考虑迫使乐观和 ZK 系统以相同方式处理及时最终确定。

乐观 vs ZK：无信任生存能力

无信任生存能力意味着任何人都可以强制系统向前发展。（无信任安全性属性确保该进展将是正确的。）

乐观 Rollup允许任何节点声明正确的执行。提出该声明只需让节点执行链的交易，然后存入一个可以在声明被协议确认后予以退款的押金。

在 ZK 系统中，进展要求任何节点能够创建和发布所需的 ZK 证明，以推进链的状态。这必须能够使用任何人随时可用的硬件和软件。因此，它不应要求构建或购买特殊用途的异国硬件，也不应进行大规模并行计算。必须要有在普通设备上构建适用的 ZK 证明的路径。一个未提供此类保证之供者，或者尚未发布用于为其系统生成证明的代码的 ZK 提供者，不提供无信任的进展，其系统没有生存能力保证。他们的系统是中心化的，因为只有具备特殊设备的方能够强制推进。当今主要的 ZK Rollup提供者是否会使证明对普通用户变得可行尚不明确。

裁决：在乐观系统中提供无信任进展更为容易。

ZK vs. 乐观：桥接

ZK Rollup在桥接到以太坊时确实有一个优势。乐观 Rollup在将资金从汇总转移到 L1 时预计需要一周的延迟，而 ZK Rollup只需立即在 L1 上发布 ZK 证明即可进行桥接。在实践中，这并不是一个很大的差异，因为乐观 Rollup用户可以利用快速桥接服务，这些服务会以低延迟将 L2 资金互换为 L1 资金。因此，ZK 的优势主要在于其用户可以避免支付桥接服务收取的小额费用（这些服务在价格上竞争）。这并不是理论上的：如今，许多实时快速桥接服务已经提供从 Arbitrum 进行即时提取。

重要的是要强调，ZK Rollup的桥接优势相当窄：它仅适用于从 L2 返回以太坊。曾经（2019 年左右）很多人相信汇总将提供缓慢的推广，并且只有一两个实时去中心化应用。在这种情况下，汇总用户将不断在 L1 和 L2 之间进行桥接。但这不是我们所处的世界。Arbitrum 拥有繁荣的生态系统，数百个跨越 DeFi 各个角落的去中心化应用，许多用户正在桥接到 Arbitrum，并长期停留在那里。此外，在用户在多个链之间跳转的情况下，他们不会仅仅跳到以太坊。它们还会转向其他 L1 和侧链，对于这种直接桥接，ZK Rollup对乐观 Rollup没有优势。

裁决：ZK 系统在桥接到 L1 时有轻微优势，但在实践中由于快速桥接和多链使用模式，这种优势大部分被抵消。

结论

比较乐观和 ZK 系统，我们认为乐观系统是明确的赢家。乐观的成本更低，享有与 EVM 和现有工具的完全兼容性，唯一实质性的劣势是在没有快速桥接服务的情况下，L1 桥接速度更慢。其他所谓的 ZK 优势往往要牺牲链的可见性或最终确定时间，而我们认为用户并不希望这样妥协。

这一切可能都不会改变。对 EVM 兼容合约执行进行 ZK 证明将始终比乐观执行更昂贵，并且实现保证进展、链可见性和去中心化的要求将保持不变。虽然我们始终对将 Arbitrum 转换为基于 ZK 的执行持开放态度，但我们认为这不会发生。

我们最后要指出一个警告。人们倾向于将 Arbitrum 当前所提供与 ZK 系统所声称的未来提供进行比较。但这种比较几乎没有意义。如果我们比较当前存在的系统，如乐观 Rollup（如 Arbitrum）是在唯一可开放部署的通用智能合约的。或者，如果我们在比较未来系统，那么我们也应该比较 Arbitrum 的未来与未来的 ZK 系统。我们正在不断改进 Arbitrum——例如我们即将推出的 Nitro 发布包括更低的成本和更加优化的 无损 数据压缩。我们在努力不懈地改进 Arbitrum，并将成本降至理论限度。正如我们在这篇文章中所展示的，我们相信在考虑当前存在的系统以及其各自理论限制时，乐观 Rollup是明确的赢家。

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