ZK/Optimistic 混合 Rollup 探讨

作者：kelvinfichter；编译：Marit，MK

我最近深信，以太坊 Rollup 的未来实际上是两种主要方法（ZK 和 Optimistic）的混合体。在这篇文章中，我会尝试解释我所想象的基本架构，并解释为什么我认为这是**的前进道路。

我不打算花太多时间讨论 ZK 或 Optimistic Rollups 的本质。这篇文章假设你已经对这些东西的工作原理有了不错的理解。你不需要是专家，但你至少应该知道它们是什么，以及它们在高层次上是如何工作的。如果我试图向你解释 Rollups，这篇文章将会非常、非常长。总之，请享受阅读吧！

从 Optimistic Rollup 开始

混合 ZK/Optimistic Rollup 以 Optimistic Rollup 的形式开始，这种 Rollup 与 Optimi 的 Bedrock 架构非常相似。Bedrock 旨在与以太坊（“EVM Equivalent”）达到****的兼容，并通过运行几乎与普通以太坊客户端相同的执行客户端来实现这一目标。Bedrock 使用以太坊即将出现的共识/执行客户端分离模型，显著降低了对 EVM 的差异（总是需要进行一些改变，但我们可以管理这一点）。在我写这篇文章时，Bedrock Geth 的差异是一个+388 -30的提交。

像任何**的 Rollup 一样，Optimi 从以太坊获取区块/交易数据，在共识客户端内以某种确定的方式对这些数据进行排序，然后将这些数据输入到 L2 执行客户端以供执行。这种架构解决了“理想 Rollup”谜题的前半部分，为我们提供了一个 EVM Equivalent 的 L2。

当然，我们现在也需要解决如何以可证明的方式告诉以太坊 Optimi 内部正在发生什么的问题。如果没有这个特性，合约就无法根据 Optimi 的状态做出决策。这将意味着，用户可以存入 Optimi，但永远无法取出他们的资产。虽然在某些情况下，单向 Rollup 可能实际上是有用的，但在一般情况下，双向 Rollup 更有用。

我们可以通过给出对该状态的承诺以及证明该承诺正确生成的证据，告诉以太坊任何 Rollup 的状态。另一种说法是，我们正在证明“Rollup程序”被正确执行。ZK 和 Optimistic Rollups 之间的唯一真正的区别是这个证明的形式。在 ZK Rollup 中，你需要给出明确的 ZK 证明，证明程序被正确执行。在 Optimistic Rollup 中，你对承诺提出声明，但没有明确的证明。其他用户可以挑战你的声明，并迫使你进行一场反复的游戏，最终你会弄清楚谁是正确的。

我不会过多地详述 Optimistic Rollup 挑战游戏的细节。值得注意的是，这个游戏的**技术是将你的程序（在 Optimi 的情况下是 Geth EVM +一些边缘部分）编译成一些简单的机器架构，比如 MIPS。我们这样做是因为我们需要在链上为我们的程序构建一个解释器，构建 MIPS 解释器比构建 EVM 解释器要容易得多。EVM 也是一个不断变化的目标（我们有定期的升级分叉），并且并未完全包含我们想要证明的程序（里面也有一些非 EVM 的东西）。

一旦你为你的简单机器架构构建了一个链上的解释器，并且创建了一些链下的工具，你应该就拥有了一个功能完全的 Optimistic Rollup。

转化为 ZK Rollup

总的来说，我认为至少在接下来的几年里，Optimistic Rollups 将占据主导地位。有些人认为 ZK Rollups 最终会超越 Optimistic Rollups，但我认为这可能是错误的。我认为 Optimistic Rollups 今天的相对简单性和灵活性意味着它们可以随着时间的推移转变为 ZK Rollups。如果我们能够找出一个使之实现的模型，那么当你可以简单地部署到现有的 Optimistic 系统并称之为一天的工作时，真的没有强烈的动力去部署一个不太灵活、更脆弱的 ZK 系统。

因此，我的目标是创建一个架构和迁移路径，使现有的现代 Optimistic 系统（比如 Bedrock）可以无缝地转变为 ZK 系统。以下是我认为这不仅可以实现，而且可以以一种超越当前 zkEVM 方法的方式实现的方法。

我们从我上面描述的 Bedrock 风格的架构开始。注意，我（简单地）解释了 Bedrock 如何有一个挑战游戏，可以断言 L2 程序（运行 EVM +一些额外东将其转化为 ZK Rollup

总的来说，我认为在未来几年内，Optimistic Rollup将会占主导地位。有一种观点认为ZK Rollup最终会超越Optimistic Rollup，但我认为这可能是错误的。我认为Optimistic Rollup的相对简单性和灵活性意味着它们可以随着时间的推移转变为ZK Rollup。如果我们能找出一种让这种转变发生的模型，那么在你可以简单地部署到现有的Optimistic系统并结束一天的工作时，就真的没有强烈的动力去部署到一个较不灵活且更易出问题的ZK系统了。

因此，我的目标是创建一种架构和迁移路径，允许现有的现代Optimistic系统（如Bedrock）无缝转变为ZK系统。我相信，以下是一种不仅可以使这种转变发生，而且可以以一种超越当今的zkEVM方法的方式进行转变的方法。

我们从我之前描述的Bedrock风格的架构开始。注意，我（简要地）解释了Bedrock是如何拥有一个可以断言L2程序（运行EVM+一些额外内容的MIPS程序）执行的有效性的挑战游戏的。这种方法的主要缺点之一是，我们需要预留一段时间让用户能够检测到并成功挑战一个错误的程序结果提议。这使得资产提现过程增加了相当多的时间（当前Optimi主网上为7天）。

然而，我们的L2只是在一个简单的机器（MIPS）上运行的一个程序。完全有可能为这种简单的机器构建一个ZK电路。然后我们可以使用这个电路来明确地证明L2程序的正确执行。而无需对当前的Bedrock代码库做任何改动，你就可以开始为Optimi发布有效性证明。这真的就是这么简单。

为什么这种方法如此好

快速说明：在本节中，我提到了”zkMIPS”，但实际上我是用它来代指任何通用的”简单”zkVM。

zkMIPS比zkEVM更简单

构建一个zkMIPS（或者zk[插入其他机器名]）而不是zkEVM的一个巨大的好处是，目标机器的架构是简单且静态的。EVM的变化频繁。Gas价格会改变，操作码会被调整，有些东西会被添加或删除。而MIPS-V自1996年以来一直没有改变。通过目标zkMIPS，你在一个固定的问题空间上工作。每次EVM更新，你不需要改变并可能重新审核你的电路。

zkMIPS比zkEVM更灵活

另一个关键的争论点是，zkMIPS比zkEVM更灵活。使用zkMIPS，你有更多的灵活性来随意修改客户端代码，以实现各种优化或用户体验改进。客户端更新不再需要随着电路更新而来。你还可以创建一个核心组件，可以用来将任何区块链转变为ZK Rollup，而不仅仅是以太坊。

你的问题转变为证明时间

ZK证明时间沿着两个轴进行扩展：约束数量和电路大小。通过关注像MIPS这样的简单机器的电路（而不是像EVM这样的更复杂的机器），我们能够显著减少电路的大小和复杂性。然而，约束的数量取决于执行的机器指令的数量。每个EVM操作码都被分解为多个MIPS操作码，这意味着约束的数量显著增加，总体的证明时间也显著增加。

但减少证明时间是一个坚固地根植于Web2空间的问题。鉴于MIPS机器架构在不久的将来不会有任何改变，我们可以高度优化我们的电路和证明程序，而不必担心EVM在后期的变化。我非常确信，能够优化一个明确定义的程序的硬件工程师的**池至少是构建和审计一个不断变化的zkEVM目标的**池的10倍（如果不是100倍）。像Netflix这样的公司可能有很多硬件工程师在优化转码芯片上工作，他们很乐意接受一堆风险投资的钱，来应对一个有趣的ZK挑战。

这种电路的最初证明时间可能超过7天的Optimistic Rollup提款期。随着时间的推移，这个证明时间只会减少。通过引入ASIC和FPGA，我们可以大大加快证明时间。有了一个静态目标，我们可以构建更优化的证明器。

最终，这个电路的证明时间将低于当前的7天Optimistic Rollup提款期，我们可以开始考虑取消Optimistic的挑战过程。运行一个证明程序7天可能仍然过于昂贵，因此我们可能还想再等一段时间，但是这个观点依然成立。你甚至可以同时运行两个证明系统，这样我们就可以立即开始使用ZK证明，并且如果出于某种原因证明程序失败，我们可以回到Optimistic证明。当准备好的时候，很容易以对应用完全透明的方式转向ZK证明。没有其他的系统可以提供这种灵活性和平滑的迁移路径。

你可以关注其他重要的问题

运行一个区块链是一项困难的任务，它不仅涉及编写大量的后端代码。我们在Optimi所做的大部分工作都集中在通过有用的客户端工具改善用户和开发者体验上。我们也花费了大量的时间和精力处理”软”性方面的事情：与项目对话，理解痛点，设计激励。你在链软件上花费的时间越多，就越少时间去考虑这些其他的事情。你总是可以尝试雇佣更多的人，但是组织并不是线性扩展的，每增加一个新的雇员都会增加内部通信的负担。

由于ZK电路工作可以被添加到现有的运行链上，你可以并行地开展核心平台和证明软件的构建工作。而且，由于客户端可以在不更改电路的情况下被修改，你就可以分离你的客户端和证明团队。采取这种方法的Optimistic Rollup可能会在实际的链上活动方面领先ZK竞争者很多年。

一些结论

完全坦率地说，我无法看到这种方法在假设zkMIPS证明者可以随着时间大幅度优化的情况下有任何显著的缺点。我认为对应用的唯一实际影响是，可能需要调整不同操作码的气体费用，以反映这些操作码添加的证明时间。如果真的无法将这个证明者优化到一个合理的水平，那么我就承认失败。如果实际上可能优化这个证明者，那么zkMIPS/zkVM的方法似乎比当前的zkEVM的方法要好得多，以至于可能完全使后者过时。这可能看起来像是一个激进的声明，但是不久前，单步的Optimistic故障证明被多步证明完全取代。