以太坊的争论：我们对 Roll-ups 有多乐观？

自从 2020 年 DeFi 夏季以来，以太坊社区就扩展平台的最佳方法展开了激烈的辩论。一方认为零知识（“ZK”）rollup 是未来，而另一方则提倡乐观 Rollup（“OR”）。大同小异。本质上，两者之间的主要区别在于它们证明发生在 Layer 2 (“L2”) 链上的交易正确性的方式。

ZK rollup 使用有效性证明（也称为零知识证明 / ZKP），这需要证明方执行链并进行一系列复杂的加密操作来构建证明。这是很昂贵的，并且需要专用硬件设备或大规模并行才能大规模地进行证明。另一方面，传统的 OR 使用欺诈证明，允许节点在不发布任何证明的情况下声明执行某些交易的正确结果。其他节点可以执行相同的交易，如果他们不同意先前节点的记录，则可以发布挑战，并且整个过程由主以太坊 Layer 1 (“L1”) 上的合约管理。在大多数情况下，所有节点都会自动处理所有交易，因为各方都积极主动地提交准确的声明并对任何不正确的声明提出异议。因此，通常不需要激活证明代码。

我喜欢思考的一个原始方式类似于你计划进行银行转账时。你可以 (A.) 使用密码 + OTP（ZKP 方法）通过银行账户或钱包立即汇款，或者 (B.) 发送一张需要清算的支票（OR 方法）。在 (A.) 的情况下，银行能够根据你已提供密码以批准交易这一事实来验证你的详细信息，因此无需进一步检查你的身份。而在 (B.) 的情况下，银行可以选择进行回拨，同时采用较短的清算和争议期，以确保在正式转账之前，所汇款项（尤其是对于较大金额）已获得适当授权且在法律上是干净的。

在介绍完初学者的类比之后，OR 和 ZKP 之间的辩论有几个维度，本文将尝试逐步介绍其中的一些维度。即：成本、EVM 兼容性、无需信任的可见性、桥接速度、最终确定时间、安全假设和硬件要求。

TL;DR:

总而言之，我整理了一个快速备忘单，以供参考：

成本

在这方面，乐观 Rollup (“OR”) 比 ZK Rollup (“ZK”) 具有更大的成本优势。OR 要求节点仅执行合约执行，而 ZK 则需要生成复杂的加密证明，这需要数百甚至数千个昂贵的椭圆曲线计算，用于每个合约指令。

这意味着，当涉及到简单地执行指令时，由于需要对每个指令生成复杂的加密证明，ZK 本身就处于成本劣势。ZK 证明的构建成本也很高，这意味着完全参与 ZK 协议可能需要定制硬件和/或大规模并行，从而使网络实际上更加中心化，尤其是在扩展时。相比之下，由于构建 ZK 证明的链下成本非常高，OR 可以以较低的成本提供用户想要的属性。这意味着 ZK Rollup 通常比 OR 更昂贵，并且这种成本劣势可能会限制协议的参与。

总的来说，OR 相对于 ZK Rollup 的固有成本优势使 OR 成为希望在以太坊网络上构建可扩展的去中心化应用程序 (“dApp”) 的开发人员的更实用选择。这意味着 OR 目前 更容易访问，这可能会导致更大的去中心化和增加网络参与度。

EVM 兼容性

另一个考虑因素是以太坊虚拟机 (EVM) 兼容性。OR 与 EVM 完全兼容，这意味着为以太坊编写的任何（字节）代码都可以在 OR 上直接运行。对于某些不考虑 EVM 兼容性作为传统工具并鼓励人们学习其自定义语言的 ZK 系统来说，情况并非如此。 一些 ZK 系统正在努力开发与 EVM 兼容的版本，但很难找到任何公开代码或基准，来说明用户定义的 zkEVM 合约的证明成本是多少。

为什么 EVM 兼容性是智能合约系统开发中的一个重要考虑因素？ 加粗EVM 兼容性对于尚未编写任何代码的新项目来说是一大福音加粗，因为它允许这些项目利用围绕 EVM 存在的代码、工具和人才库。加粗这对于新项目启动其代码库来说是一个巨大的好处加粗，因为 EVM 兼容性使他们能够利用 EVM 生态系统中现有的代码库、资源和开发人员，这在效率和成本效益方面可能是一个显着的优势。

乐观 Rollup 与 EVM 完全兼容，这意味着它们具有与 EVM 相同的 RPC 接口。最好的部分是 EVM 兼容性的成本最低，使其成为开发人员的理想选择。另一方面，一些 ZK 系统要么将 EVM 兼容性视为传统，要么鼓励人们学习其自定义语言（Rust、Solidity、Move、Cairo 等）。

zkEVM 是相对较新的，并且正在开发中，具有不同程度的以太坊兼容性和性能。虽然像 Ethereum 的研究部门 这样的组织致力于实现与以太坊的近乎完美的兼容性，但这会以性能为代价，并且可能在一段时间内无法投入生产。其他公司，例如 StarkWare，已经部署了高性能的 zkEVM，例如 StarkNet，但这些 zkEVM 需要使用一种名为 Cairo 的新编程语言，这对采用提出了挑战，因为开发人员需要学习如何在新的环境中执行其智能合约代码。其他项目，例如 Polygon 的 Hermez、zkSync Era 和 Scroll，正在努力解决这些挑战，以使 zkEVM 更容易被开发人员访问。

然而，就目前而言，大多数现有的 ZK 系统都是专门构建的，并且是为特别适合 ZK 实现的特定应用而定制设计的。一个值得一看的用例是我最喜欢的建立在 StarkWare 技术之上的永续 DEX dYdX。

总而言之，这些与 EVM 的根本不兼容向我们表明，即使在最好的情况下，zkEVM 兼容性也只会渐近，并且可能永远无法与乐观 Rollup 的完全 EVM 兼容性相提并论。

此外，另一方面，现有的 OR 正在通过吸引所有区块链开发人员来进一步扩展以太坊。为了实现此目标，乐观 Rollup 解决方案 Arbitrum 最近发布的 Stylus 是一项技术发展，它将允许多种编程语言存在于单个 Arbitrum 链中，从 Rust、C 和 C++ 开始（适用于使用 javascript 进行编码的开发人员）。这种发展将为开发人员、web 2 用户和企业打开一扇空白的大门，使他们更容易在 Arbitrum 生态系统之上进行构建。

无需信任的可见性

在设计 Layer 2 链时，无需信任的可见性是另一个关键属性。OR 提供无需信任的可见性，这意味着任何人都可以看到或推导链的内容，而无需集中方的帮助。这意味着每个人都可以看到完整的链历史以及它如何发展到当前状态。另一方面，ZK Rollup 通过比 OR 更进一步地压缩数据，将临时的状态快照发布到主 ETH 链。此数据仅对 ZK 证明者可见，但会引起对问责制和可能（意外）排除重要数据的担忧。

在无需信任的进度方面，OR 允许任何节点声明正确的执行，而 ZK 则规定只有满足高硬件要求的节点才能创建和发布推进链状态所需的 ZK 证明之一。

虽然缺乏可见性可能被某些人视为缺点，但对于隐私的提供者来说，这实际上是一种福利。ZK rollup 可以通过使用零知识证明 (ZKP) 来模糊交易细节，从而提供完整的交易隐私。这意味着交易金额、参与者和其他敏感信息可以保持私密，同时仍然保持 rollup 的安全性和可扩展性优势。此外，由于 ZKP 允许在不泄露任何细节的情况下验证交易，因此它们也可以用于启用私人投票、个人身份识别以及其他保密至关重要的情况。

Bessemer Venture Partners 确定的一些新的用例证明了 ZKP 在金融到游戏等各个行业中的多功能性。ZKP 允许安全和私密的交易，同时保持网络的完整性。在 Filecoin 的案例中，ZKP 确保 用户可以检查并信任存储提供商实际上是在存储数据。在 像 Dark Forest 这样的 ZK 启用游戏中，ZK 技术使玩家能够以低廉且快速的方式探索虚拟宇宙，同时保持其隐私。在 无抵押贷款 的案例中，ZKP 提供了一种在不泄露敏感信息的情况下验证用户银行帐户余额的方式。随着 ZKP 的使用持续增长，看看会出现哪些其他创新应用将会很有趣。

来源：Bessemer Venture Partners

桥接到以太坊

ZK rollup 的一个优势是在桥接到以太坊时。由于其设计的 7 天欺诈争议窗口，乐观 rollup 会产生预计一周的延迟，才能将资金从 rollup 转移到 L1，而 ZK rollup 允许在 ZK 证明发布到 L1 后立即进行桥接。但是我们看到新的桥接解决方案，例如 Across Protocol，它有效地将乐观 L2 到 L1 的等待时间缩短到接近即时（费用较低）。基本上充当紧急桥接者和桥梁之间的保险中间人。

最终确定时间

正如我们上面所介绍的，乐观系统以最低的成本提供无需信任的可见性，以及频繁和定期的最终确定。要完成一组交易，验证者需要将序列放在 L1 链上。rollup 必须包含足够的信息，以便任何人都可以检查交易并验证它们的正确性。一个好的 rollup 应该尽可能频繁地（理想情况下每 <1 分钟）将序列发布到 L1 链上。这确保用户能够快速确认他们的交易已完成并最终确定。OR 通过将交易的排序与其执行分开来实现快速的最终确定。最终确定排序会产生一个 确定性函数，该函数验证交易的顺序。另一方面，ZK 具有高昂的 发布成本，其中链上证明的成本可能在 500,000 到 500 万 gas 之间 单位（对于不了解的人来说，这意味着很多 $$），具体取决于实现。因此，我们经常看到 ZK 证明每小时发布一次，这会将最终确定时间延长到一个小时。

安全假设

OR 和 ZKP 之间的另一个关键区别是交易处理中涉及的信任假设级别。加粗OR 假设大多数参与者会诚实行事加粗，如果存在分歧，则会有一个机制来确保正确的结果。这需要一个争议期，在此期间任何人都可以质疑交易的准确性，之后交易最终确定。另一方面，加粗ZKP 的安全性基于证明方无法作弊的假设加粗。但是，如果证明方可以访问比验证者更多的计算能力，则可能会作弊。这意味着随着 ZKP 的使用越来越广泛，每个合约指令都需要更复杂和昂贵的加密证明。从而导致更高的成本和更中心化的系统，最终得出结论，他们在硬件预算上的大量投资对于他们的安全至关重要。

有趣的是，在这一方面，负责 Arbitrum L2 扩展解决方案的团队 Offchain Labs 最近推出了一个名为 Arbitrum Nova 的新链，旨在充当传统 OR 和 ZKP 之间的混合桥梁。与最初建立在原始 OR 技术之上的原始 Arbitrum One 链不同，Arbitrum Nova 链建立在 AnyTrust 技术之上，该技术经过优化，可在极低的成本下提供强大的安全保证。

Arbitrum One 通过最少的信任假设提供交易处理，因为所有交易数据都由排序器批量处理并发布到 L1。相比之下，Arbitrum Nova 在交易数据处理过程中增加了一个最小的信任假设，该假设假设至少有两名诚实的委员会成员，从而允许任何受信任的成员推进链序列，从而确保链的活跃性。这与 Arbitrum One 的无需信任的设计不同。Arbitrum One 不断将所有交易数据放在以太坊上，而 Arbitrum Nova 利用数据可用性委员会 (DAC)，其中包括 OpenSea、Reddit 和 Consensys 等。DAC 负责签署交易批次的数据可用性证书 (DACerts)，这些证书是唯一发布到 L1 的项目。这导致基础层上的存储需求大大减少。为了保持数据可用性，该委员会运行数据可用性服务器，这些服务器提供标准化的 REST API，用于按哈希获取数据批次。

因此，由于 DAC 成员的存在，与 Arbitrum One 相比，Arbitrum Nova 上的交易具有显着降低的交易费用。虽然 Arbitrum One 声称 对于许多交易类型，比以太坊便宜高达 97%，但 Arbitrum Nova 的成本会更低。这使得 Arbitrum Nova 非常适合具有高交易量预期的项目，例如经常铸造新 NFT 或货币的游戏，或者具有许多链上交互层的社交项目。简而言之，Arbitrum Nova 的发布操作位于传统 OR 和 ZK 之间。

从广义上讲，Arbitrum One 旨在成为 DeFi 和 NFT 项目的与 EVM 兼容的 L2 解决方案，而 Arbitrum Nova 专为游戏、社交应用程序/dApp 和其他需要更低的交易成本和更高的交易量的用例而定制。

硬件要求

ZKP 需要昂贵的基于椭圆曲线的证明，这需要昂贵的专用硬件设备或大规模并行才能大规模地进行证明，因为证明成本随着合约内指令的线性增加而呈指数增长。这意味着基于 ZKP 的解决方案可能需要大量资源并且需要专用硬件，如 GPU 或 FPGA，以实现高效执行。这与 OR 形成对比，OR 仅需要节点执行合约，从而使其成本低得多。最终，与乐观 rollup 相比，ZKP 需要更专业和昂贵的硬件。因此，为了使 ZKP 长期获得广泛采用，它们必须使用任何人都可以轻松获得的硬件和软件。我看到了两条可能的前进道路：要么改进 ZK 技术以减少构建或购买奇异、专用硬件的要求，要么减少大规模并行计算。随着摩尔定律和库兹韦尔定律的实施，人们希望这只是时间问题。

尽管如此，结合先前讨论的安全考虑因素，ZK 支持者可能会将他们的高硬件预算视为安全护城河，通过创建资本密集型障碍来阻止可能试图破坏他们的证明或操纵已发布调用数据的潜在恶意行为者。

结论

总而言之，乐观 Rollup 和零知识证明之间的争论是一个复杂的问题，需要考虑几个权衡因素。OR 提供了一种经济高效、与 EVM 兼容且无需信任的最终确定解决方案（在大多数情况下），使其更易于访问且可能更去中心化。但是，它们缺乏 ZKP 的隐私保护属性，而 ZKP 更昂贵并且需要专用硬件才能有效执行。ZKP 提供不同级别的交易隐私，允许安全和私密的交易，同时保持网络的完整性。此外，它们已在从金融到游戏等各个垂直领域展示了多功能的用例。随着 ZK 采用的持续增长，看看会出现哪些其他创新应用将会很有趣。最终，开发人员必须权衡成本、安全性、隐私和其他因素之间的权衡，以确定最适合其项目要求的方法。无论哪种方式，用户都会赢。

免责声明：本文仅供参考和娱乐目的，不应被解释为财务建议或代表我所代表的公司的观点或意见。本文档中提供的信息被认为是准确和可靠的，但不对此信息的准确性、完整性或可靠性做出任何陈述或保证。你根据本文档中提供的信息采取的任何行动均完全由你自行承担风险，我们将不对可能发生的任何损失或错误承担责任。建议你在做出任何财务决定之前进行自己的研究并咨询合格的专业人士。

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