原文作者：@kelvinfichter
原文编译：Jaleel，BlockBeats
我最近非常确信以太坊 Rollup 的未来实际上 ZK 和 Optimistic 这两种主要方法的混合。在这篇文章中，我将尝试阐述我想象中的这个架构的基本要点，以及为什么我相信这是我们应该前进的方向。请注意，我大部分时间都在研究 Optimism，也就是 Optimistic Rollup，但我并非 ZK 专家。如果我在谈论 ZK 方面有任何错误，请随时联系我指出，我会更正。
我并不打算在这篇文章里详细叙述 ZK 和 Optimistic Rollups 的运作原理，如果我要花时间去解释 Rollups 的本质，那么这篇文章将会过于冗长。所以这篇文章是基于你已经对这些技术有一定的了解，当然你不需要是专家，但至少应该知道 ZK 和 Optimistic Rollups 是什么以及他们大概的运作机制。无论如何，请尽情享受阅读本文。
我们先从 Optimistic Rollup 开始谈起
混合了 ZK 和 Optimistic Rollup 的系统最初是以 Optimism 的Bedrock 架构为蓝本的 Optimistic Rollup。Bedrock 被设计成与以太坊最大程度的兼容（「EVM 等效」），这是通过运行一个几乎与以太坊客户端完全相同的执行客户端来实现的。Bedrock 利用以太坊即将到来的共识/执行客户端分离模型，显著减小了与 EVM 的差异（当然这过程中总会有一些变化，但我们可以处理）。
和所有优秀的 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。
转向 ZK 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 发布有效性证明了。实际操作起来就是这么简单。
为什么这个方法可靠？
简单澄清一下：虽然在这一部分，我提到了zkMIPS，但实际上我是把它作为代表所有通用且简化的零知识证明虚拟机（zkVM）的术语。
zkMIPS 比 zkEVM 更容易
构建一个 zkMIPS（或其他任何类型的 zk 虚拟机）相比 zkEVM 有一个重大优势：目标机器的架构简单且静态。EVM 经常发生变化，Gas 价格会调整，操作码也会改变，一些元素会被添加或移除。而 MIPS-V 自 1996 年以来就没有改变过。将焦点集中在 zkMIPS 上，你就在处理一个固定的问题空间。每当 EVM 更新时，你都无需更改甚至重新审核你的电路。
zkMIPS 比 zkEVM 更灵活
另一个关键观点是，zkMIPS 比 zkEVM 更具灵活性。通过 zkMIPS，你可以随心所欲地更改客户端代码，执行各种优化，或者改进用户体验，而无需对应的电路更新。你甚至可以创建一个核心组件，将任何区块链变为 ZK Rollup，而不仅仅是以太坊。
你的任务转变成了证明时间
零知识证明的时间沿着两个轴度进行扩展：约束的数量和电路的大小。通过专注于像 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 可能在实际链上的活动方面比零知识竞争者领先多年。
结论
非常坦白地说，我认为 zkMIPS 证明器没有任何明显的不足，除非它不能随着时间大幅优化。我认为对应用的唯一真正影响是，可能需要调整不同操作码的 gas 成本，以反映这些操作码增加的证明时间。如果真的无法将此证明器优化到合理的水平，那么我承认我失败了。但如果真的可以优化这个证明器，那么 zkMIPS/zkVM 的方法可能会完全取代现在的 zkEVM 方法。这听起来可能是一种激进的说法，但不久前，单步乐观故障证明已经完全被多步证明所取代。
