原文作者：@kelvinfichter
原文编译：Jaleel，BlockBeats
我最近非常确信以太坊 Rollup 的未来实际上 ZK 和 Optimistic 这两种主要方法的混合。在这篇文章中，我将尝试阐述我想象中的这个架构的基本要点，以及为什么我相信这是我们应该前进的方向。请注意，我大部分时间都在研究 Optimism，也就是 Optimistic Rollup，但我并非 ZK 专家。如果我在谈论 ZK 方面有任何错误，请随时联系我指出，我会更正。
我并不打算在这篇文章里详细叙述 ZK 和 Optimistic Rollups 的运作原理，如果我要花时间去解释 Rollups 的本质，那么这篇文章将会过于冗长。所以这篇文章是基于你已经对这些技术有一定的了解，当然你不需要是专家，但至少应该知道 ZK 和 Optimistic Rollups 是什么以及他们大概的运作机制。无论如何，请尽情享受阅读本文。
和所有优秀的 Rollup 一样，Optimism 从以太坊中提取区块/交易数据，然后在共识客户端中以某种确定的方式对这些数据进行排序，并将这些数据馈送到 L2 执行客户端进行执行。这种架构解决了"理想的 Rollup"谜题的前半部分，并为我们提供了一个等效于 EVM 的 L2。
当然，我们现在还需要解决的问题是：以可验证的方式将 Optimism 内部发生的事情告诉以太坊。如果这个问题没有解决，智能合约就无法根据 Optimism 的状态来做决定。这将意味着用户可以向 Optimism 存款，但无法提取他们的资产。虽然某些情况下单向 Rollup 是可以实现的，但在大部分情况下，双向 Rollup 更为有效。
通过提供对该状态的某种承诺，以及证明该承诺是正确的证据，我们就可以将所有 Rollup 的状态告知给以太坊。换句话说，我们正在证明「Rollup 程序」被正确执行。ZK 和 Optimistic Rollups 之间的唯一实质性区别就是这个证明的形式。在 ZK Rollup 中，你需要提供一个明确的零知识证明来证明程序的正确执行。而在 Optimistic Rollup 中，不提供明确的证据就可以对承诺做出声明，通过挑战和质疑你的声明，其他用户可以强制你参与一场来回推敲和挑战的「游戏」，以此确定最终谁是对的。
我并不打算详细讲述 Optimistic Rollup 的挑战部分。值得注意的是，这个环节的最新技术是将你的程序（在 Optimism 的情况下是 Geth EVM 一些边缘的部分）编译成一些简单的机器架构，如MIPS。我们这样做是因为我们需要在链上建立一个程序的解释器，而建立一个 MIPS 解释器比建立一个 EVM 解释器要容易得多。EVM 也是一个不断变化的目标（我们有定期的升级分叉），而且且并不能完全包含我们想要证明的程序（里面也有一些非 EVM 的东西）。
一旦你为你的简单机器架构构建了一个链上的解释器，并且创建了一些离线工具，你就应该有一个完全功能的 Optimistic Rollup。
总的来说，我坚信 Optimistic Rollups 将在接下来的几年中占据主导地位。有人认为 ZK Rollups 最终会超越 Optimistic Rollups，但我并不同意这种看法。我觉得 Optimistic Rollups 当前的相对简单性和灵活性意味着它们可以逐渐转变为 ZK Rollups。如果我们能找到一种模式来实现这种转变，那么就没必要费力去建立一个更不灵活、更脆弱的 ZK 生态系统，我们可以简单地部署到一个已经存在的 Optimistic Rollup 生态系统中。
因此，我的目标是创建一种架构和迁移路径，使现有的现代 OP 生态系统（比如 Bedrock）能够无缝地转变为 ZK 生态系统。我相信这不仅是可行的，而且是一种超越当前 zkEVM 方法的方式。
我们首先从我前文中描述的 Bedrock 架构开始。请注意，我已经（简短地）解释过，Bedrock 设有一个挑战游戏，可以验证 L2 程序（运行 EVM 一些额外内容的 MIPS 程序）某些执行的有效性。这种方法的一个主要缺点是，我们需要预留一段时间，让用户有机会检测到并成功挑战一个错误的程序结果提案。这会在资产提取过程中增加相当多的时间（在当前的 Optimism 主网上是 7 天）。
然而，我们的 L2 只不过是一个在简单机器（比如 MIPS）上运行的程序。我们完全有可能为这种简单的机制构建一个 ZK 电路。然后，我们可以利用这个电路来明确地证明 L2 程序的正确执行。在不对当前的 Bedrock 代码库做任何修改的情况下，你就可以开始为 Optimism 发布有效性证明了。实际操作起来就是这么简单。
零知识证明的时间沿着两个轴度进行扩展：约束的数量和电路的大小。通过专注于像 MIPS 这样的简单机器的电路（而不是像 EVM 这样的更复杂的机器），我们能够显著减少电路的大小和复杂度。然而，约束的数量取决于执行的机器指令的数量。每个 EVM 操作码都被分解成多个 MIPS 操作码，这意味着约束的数量显著增加，你的总体证明时间也显著增加。
然而，减少证明时间也是一个深植于 Web2 领域的问题。考虑到 MIPS 机器架构短期内不太可能改变，我们可以高度优化电路和证明器，而不必考虑 EVM 的未来变化。我对雇佣一位资深硬件工程师来优化一个明确定义的问题感到非常自信，这样的工程师的数量可能是构建和审核一个不断变化的 zkEVM 目标的工程师数量的十倍甚至百倍。诸如 Netflix 这样的公司可能有大量的硬件工程师在优化转码芯片，他们很可能愿意用一堆风险投资基金来迎接这个有趣的 ZK 挑战。
像这样的电路的初始证明时间可能超过了 7 天的 Optimistic Rollup 提款期。随着时间的推移，这个证明时间只会减少。通过引入 ASIC 和 FPGA，我们可以显著加快证明时间。有了一个静态的目标，我们可以构建更优化的证明器。
最终，这个电路的证明时间会低于当前的 7 天 Optimism 提款期，我们可以开始考虑移除 Optimism 的挑战过程。运行一个证明器 7 天可能仍然过于昂贵，所以我们可能会希望再等一段时间，但是这一点是站得住脚的。你甚至可以同时运行两种证明系统，这样我们可以尽快开始使用 ZK 证明，并在证明器出于任何原因失败时回到 Optimism 证明。准备好的时候，可以以完全透明于应用程序的方式去除 Optimism 证明，于是，你的 Optimistic Rollup 就变成了 ZK Rollup。
运行一个区块链是一个复杂的问题，它不仅仅涉及到编写大量的后端代码。在 Optimism，我们的许多工作都集中在通过提供有用的客户端工具来提高用户和开发者的体验。我们也在「软性」问题上投入了大量的时间和精力：与项目进行对话，理解他们的痛点，设计激励机制。你在链软件上投入的时间越多，就越没有时间去处理这些其他事情。虽然你总可以试图雇佣更多的人，但组织并不是线性扩展的，每一个新的雇员都会增加内部的沟通成本。
由于零知识电路的工作可以直接应用在已经运行的链上，你可以同时进行核心平台的构建和证明软件的开发。由于客户端可以在不改变电路的情况下进行修改，你可以解耦你的客户端和证明团队。采用这种方式的 Optimistic Rollup 可能在实际链上的活动方面比零知识竞争者领先多年。
