ZK Rollups 长期以来一直被认为是以太坊扩容的终极目标。然而，尽管它们对以太坊扩展路线图很重要，但几个关键点仍然存在广泛的不确定性：

如果您是一名希望了解以太坊扩展的下一阶段的开发人员，本文将（希望）有所帮助。

ZK Rollups 可以通过一个简单的观察来实现：像 STARK 或 SNARK 这样的证明系统允许使用亚线性处理来验证线性数量的语句（例如，1000 条语句 → 10 次验证者检查，10,000 条语句 → 11 次验证者检查）。我们可以使用此属性来创建可大规模扩展的区块链交易处理，如下所示：

简化的 ZK Rollup 架构

验证证明的 gas 成本与被证明的交易数量呈次线性关系，与直接使用 L1 相比，可以实现更大的规模。为了更详细地了解这个过程，我推荐 Vitalik 的《不完全 Rollup 指南》或 Delphi 新发布的《完整 Rollup 指南》。

特定于应用程序的 Rollup

到目前为止，所有生产级 ZK Rollup 都是我们所说的“特定于应用程序的 Rollup”。在特定于应用程序的 Rollup 中，Rollup 支持由 Rollup 运营方定义的固定数量的“状态转换”（例如交易）。这对于超优化常见用例非常有用，例如：

Loopring—支付和 Swap

Immutable—NFT 铸币和交易、游戏

dydx—永续交易

特定于应用程序的 Rollup 非常适合扩展特定的、易于理解的问题。如果您作为项目的需求可以通过特定于应用程序的 Rollup 来满足，那么您可能会为您的用例获得更好的性能、更好的用户体验和更好的定价，因为它们缺乏泛化性是一个巨大的优势。例如，在 Immutable，我们能够通过补贴免费的 NFT 铸造和通过 NFT 交易收费的转账来消除 gas 费用——这种权衡只有在 rollup 状态转换的可预测性质下才有可能。

但是，许多项目希望能够创建自己的自定义逻辑和智能合约，独立于 rollup 运营方，这在特定于应用程序的 rollup 中是不可能的。此外，许多 DeFi 项目需要“可组合性”，或与其他项目进行原子交互的能力（例如，许多 DeFi 项目使用 Uniswap 作为价格预言机）。只有当您的 rollup 不仅支持自定义代码，而且支持任何用户可以部署的本机智能合约时，组合性才是可能的。为了实现这一点，我们需要修改 ZK Rollup 的架构以概括我们的每个组件。

这种增加的灵活性有几个妥协：性能大大降低，rollup 参数的可定制性降低以及费用更高。然而，最大的妥协是根本没有通用 ZK Rollups 的实现，当然也没有能够生产级的实现。但这种情况开始改变：

这些最新的公告值得深入研究，因为这些团队不仅宣布了通用 Rollup，他们还宣布了“zkEVM”。随之而来的是推特上许多围绕“EVM 兼容性”、“EVM 等效性”、“真正的 zkEVM”以及哪种方法更好的争论。对于应用开发人员来说，这些对话通常是噪音——因此本博客的目的是分解这些术语、设计决策和理念，并解释它们对开发人员的实际影响。

让我们从头开始：什么是 EVM？

以太坊虚拟机（EVM）是执行以太坊交易的运行时环境，最初在以太坊黄皮书中定义，后来被一系列以太坊改进提案（EIP）修改。它由以下部分组成：

用于执行程序的标准“机器”，每个交易具有易失性“内存”，交易可以写入的持久“存储”和操作“堆栈”

在这台机器中执行状态转换的约 140 个定价“操作码”

我们的虚拟机的一些示例操作码：

一个 EVM 程序只是一系列这些操作码和参数。当这些程序被表示为一个连续的代码块时，我们将结果称为“字节码”（通常表示为一个长的十六进制字符串）。

通过将大量这些操作码组合成一个执行序列，我们可以创建任意程序。以太坊使用自定义虚拟机，而不是调整现有的 VM，因为它有独特的需求：

EVM 是第一个图灵完备的区块链 VM，于 2015 年发布。它有一些设计限制，但其巨大的先发优势和随后的广泛采用为以太坊创造了巨大的差异化——它是迄今为止最久经考验的区块链虚拟机。它是整个领域的智能合约基础设施。

由于以太坊的主导地位，很多后来的区块链都直接采用了这种运行时环境。例如，Polygon 和 BNBChain 是以太坊的直接分叉，因此使用 EVM。值得注意的是，EVM 并非一成不变，并且在 EIP1559 等升级中经常被修改。由于其他区块链需要时间进行更新，或者在多个地方与以太坊有所不同，它们通常运行着稍微过时的 EVM 版本，并且难以跟上变化的步伐——这一事实可能会让以太坊的核心开发人员感到沮丧。

然而，人们所说的“EVM 链”通常不仅仅只是镜像这个运行时环境。有几个主要规范始于以太坊并已成为事实上的全球标准：

从技术上讲，您的链可以具有一个 EVM 运行时但不支持上述部分或全部标准。然而，遵守这些标准使得在你的新链上使用以太坊工具变得更加容易。一个很好的例子是 Polygon，它除了使用上述所有工具外，还能够运行 Etherscan (Polygonscan) 的分叉版本，使用 Hardhat 等以太坊开发工具，并支持 Metamask 等钱包。Nansen 和 Dune 等工具最初都针对以太坊，因此添加对新 EVM 区块链的支持。新钱包，新 NFT 市场——如果以太坊界面和你的链界面之间的唯一区别是链 ID，那么你可能是第一个也是最容易添加的。话虽如此，这些工具是为以太坊构建的——一旦你开始修改你的区块链（例如更大的区块，更快的区块时间），你就有破坏它们的风险。没有完美的兼容性。

尽管如此，针对以太坊规范的工具和应用程序的数量为新的区块链仅反映以太坊标准创造了巨大的动力。任何不支持上述规范的区块链在开发人员工具方面都会自动落后，并且随着 EVM 生态系统的发展，有进一步落后的风险。

我的信念是，“EVM 兼容”一词实际上不足以描述这里描述的网络效应——我们实际描述的是“以太坊兼容性”，并且远远超出了智能合约执行环境，延伸到了整个以太坊生态系统和工具集。

为了解决这个问题，像 Solana 这样的非 EVM 区块链必须创建完全平行的生态系统，这会降低它们的速度，并且更难吸引现有的开发人员。然而，不需要遵守这些标准确实使非 EVM 区块链能够对以太坊工具集进行更根本的更改，从而更积极地与以太坊区分开来。创建 EVM 区块链非常简单——但为什么有人会使用你的区块链而不是数百个其他“快速 EVM 区块链”之一。如果你能克服需要建立一个成功的平行链和生态系统的困难，Solana 已经证明：a）你可以吸引出色的原生应用程序（例如 MagicEden、Phantom）和 b）如果商业激励足够，源自 EVM 的项目仍将支持您（例如 Opensea 添加 Solana 支持）。

公共通用 rollup 都有一个共同目标：让开发人员和用户尽快生成网络效应。这需要结合创造最高性能的 rollup 技术、拥有最好的 BD 团队以及进行最早或最有效的营销。但是，所有 rollup 团队（出于上述原因）都非常关注：

将现有的以太坊合约（和开发人员）迁移到他们的 rollup 中

受到现有 EVM 工具（例如库、钱包、市场等）的支持

实现这两个目标的最简单方法是创建一个“zkEVM”：一个通用 rollup，将 EVM 作为其智能合约引擎运行，并保持与以太坊生态系统通用接口的兼容性，如上所述。

然而，这并不像分叉 Geth 那样容易，就像我们从头开始创建新的 L1 区块链时那样容易。我们的目标是运行 EVM 字节码——但 ZK 证明要求将它们证明的所有计算语句转换为一种非常特定的格式——一种“代数电路”，然后可以将其编译成 STARK 或 SNARK。为了快速了解“电路（circuit）”，这里有一个例子（使用更直观的布尔电路作为算术电路的特例）。在基于这个简单电路的 zkSNARK 系统中，我们的证明者希望让验证者相信他们知道输入（??1 = 1，??2 = 1，??3= 0），这些输入会产生真实的输出。这是一个非常简单的电路，具有有限数量的逻辑门——我相信你可以想象需要多少门来编码一个证明复杂智能合约交互的电路，尤其是那些涉及密码学的！

为了理解这个编译过程的每一步，我推荐你阅读 Vitalik 的《从入门到精通 SNARKs》，以及 Eli Ben-Sasson 对不同证明系统的讨论。然而，对于我们的目的来说，这种更深入的理解并不是必需的——请记住，为了支持 EVM 计算，我们必须将所有 EVM 程序转换为这些电路，以便以后可以证明它们。

从广义上讲，有几种方法可以做到这一点：

通过将其转换为可验证的电路来直接证明 EVM 执行痕迹

创建一个自定义 VM，将 EVM 操作码映射到该 VM 的操作码，然后证明该自定义环境中跟踪的正确性

创建自定义 VM，将 Solidity 转换为自定义 VM 的字节码（直接或通过自定义高级语言），并在自定义环境中进行验证

让我们从最直观的开始：证明 EVM 执行痕迹本身，这是 Scroll 团队（与以太坊基金会的隐私扩展团队一起）目前正在研究的一种方法。为了完成这项工作，我们需要：

为一些密码积累器设计一个电路（允许我们验证我们正在准确地读取存储并加载正确的字节码）

设计一个电路来链接字节码和真实的执行痕迹

为每个操作码设计一个电路（允许我们证明每个操作码的读取、写入和计算的正确性）

直接在电路中实现每个 EVM 操作码具有挑战性，但由于这种方法准确地反映了 EVM，因此它在可维护性和工具支持方面具有显着优势。下图显示了 Scroll 和以太坊之间唯一的理论区别是实际的运行环境。然而，值得注意的是，Scroll 目前并不通过这种机制支持所有 EVM 操作码，尽管他们打算随着时间的推移达到对等。

Optimism 团队对此进行了精彩的讨论，尽管是在 Optimistic Rollup 的背景下进行的。Optimism 最初创建了一个自定义的 Optimistic Virtual Machine (OVM) 作为其 Rollup 的执行环境。OVM 是“与以太坊兼容的”，这意味着它可以运行修改后的 Solidity 代码，但几个低级不匹配的领域意味着以太坊工具和复杂的代码经常需要重写。因此，Optimism 切换到“EVM 等效”，直接使用确切的 EVM 规范，并正在开发第一个等效于 EVM 的欺诈证明系统。然而，Optimistic Rollup 不需要担心电路或证明者的效率——Optimism 的正确选择可能不是我们 Rollup 的正确选择。

不幸的是，EVM 的核心基础设施并不适合 ZK Rollups。Rollup 性能的核心衡量标准是我们需要将特定计算编码到电路中的“约束”的数量。在许多情况下，镜像 EVM 会直接引入大量开销。例如，EVM 使用 256 位整数，而 zk 证明在素数域上最自然地工作。引入范围检查以对抗不匹配的字段算术为每个 EVM 步骤增加了约 100 个约束。以太坊的存储布局严重依赖 keccak256，其电路形式比 STARK 友好的哈希函数（例如 Poseidon、Pedersen）大 1000 倍——但替换 keccak 将对现有的以太坊基础设施造成巨大的兼容性问题。此外，与 SNARK/STARK 友好的椭圆曲线相比，标准以太坊椭圆曲线上的签名在证明和验证方面非常昂贵。简而言之，直接证明 EVM 会带来巨大的计算开销。虽然这里有一些最近的进展（例如多项式承诺、递归证明、硬件加速），但证明 EVM 痕迹总是比在定制设计的 VM 中证明效率低得多，至少在 EVM 本身做出改变以变得更高效之前对 SNARK 友好（可能需要几年时间）。

选项 2：自定义 VM + 操作码支持

这种认识促使团队采用上述“与 EVM 兼容”的方法：创建具有优化性能的自定义 VM，然后将 EVM 字节码直接转换为 VM 的字节码。

Polygon

一个专注于这种方法的团队是 Polygon Hermez（最近更名为 Polygon zkEVM）。Polygon 的方法是构建一个 zkEVM 是“操作码级别的等效性”，这听起来最初类似于 Scroll 采用的方法。然而，与 Scroll 不同的是，Polygon 的替代 runtime（“zkExecutor”）运行定制的“zkASM”操作码而不是 EVM 操作码来优化 EVM 解释（即减少约束的数量与直接证明 EVM）。Hermez 团队将此描述为“基于操作码的方法”，因为核心挑战是在他们的自定义 VM 中重新创建每个 EVM 操作码（您可以在此处查看代码），以便他们可以快速从 EVM 字节码转换为可验证的格式。

这些中间步骤增加了用于维护和潜在错误的表面积，但对于启用性能证明是必要的。最终，重要的是要清楚，您的程序不是在反映电路中 EVM 的 zkEVM 中运行，而是在替代的“zkExecutor”运行时中运行，这与 EVM 本身相似但不同。令人困惑的是，该团队将其作为“zkEVM”和“EVM 等效”进行营销——然而，由于这个自定义的 zkASM 解释器，根据上面的 Optimism 定义，这个 Rollup 实际上是“EVM 兼容”。

因此，尽管大多数 Solidity 代码可能能够按原样运行，但可能与在该系统上运行的现有 L1 应用程序和工具存在一些不兼容。Polygon 已声明“与 100% 的现有以太坊工具”兼容，并致力于 JSON-RPC 合规性，他们在文档中引用并在此处提供了实现。在实践中，这种说法可能是有抱负的，并且依赖于以太坊本身的东西变得对 SNARK 更加友好。

Polygon 的方法产生了比 Scroll 更高性能的 Rollup（肯定是在短期内），但具有：

大量自定义代码，因为我们需要创建 zkASM

开发人员可能需要修改其 L1 代码或工具框架

随着时间的推移，与以太坊的偏离可能会增加

选项 3：自定义 VM + 转译器

上述解决方案在“使 EVM 为 ZK Rollups 工作”方面投入了大量的开发时间，将兼容性优先于长期性能和可扩展性。还有另一种选择：创建一个全新的、专门构建的 VM，然后添加对以太坊工具的支持作为顶部的附加层。

StarkNet

这是 StarkWare 对 StarkNet 采用的方法，这是目前最先进的通用 rollup。StarkNet 使用自己的低级语言 (Cairo) 运行自定义智能合约 VM (Cairo VM)，两者都是为智能合约 rollup 而构建的。这意味着 StarkNet 没有开箱即用以太坊兼容性——正如我们之前看到的，即使是操作码级别的 VM 级别的兼容性也是对 Rollup 性能的潜在限制。

然而，Nethermind 团队（与 StarkWare 合作）创建了 Warp 转译器，它能够将任意 Solidity 代码转换为 Cairo VM 字节码。Warp 的目标是使常见的 Solidity 合约可移植到 StarkNet——实现许多以太坊开发人员在“EVM 兼容性”方面的主要目标。然而，在实践中，Warp 不支持一些 Solidity 功能，包括低级调用（可以在此处找到完整列表）。

这种构建智能合约 Rollup 的方法是保持“Solidity 兼容性”：你不是在 EVM 内执行程序，也不是保持与任何其他以太坊接口的兼容性，但 Solidity 开发人员将能够编写可用于你的 Rollup 的代码。因此，您可以保持与以太坊类似的开发人员体验，而不必损害 Rollup 的基本层。

然而，这种方法还有一些额外的妥协。首先是构建自己的 VM 具有挑战性——以太坊团队已经花了超过五年的时间来解决 EVM 的问题，并且仍然经常进行升级和修复。更自定义的 Rollup 将带来更好的性能，但您将失去所有其他链和 Rollup 对 EVM 所做的集体改进的好处。

接下来，通过转译器支持 Solidity 可能会导致可组合性的损失——如果开发人员同时在 CAIRO 和 Solidity 中编写合约，那么支持两者之间接口的工具很可能会很脆弱。到目前为止，绝大多数 StarkNet 项目都直接使用了 CAIRO，它们可能不容易与未来的 Solidity 项目组合。最后，可能也是最重要的一点，StarkNet 团队目前的目标不是与其他以太坊组件兼容——他们正在推出自己的客户端 API、JavaScript 库和钱包系统，这将迫使与以太坊兼容的工具手动添加对 StarkNet 的支持。这是极具挑战性的，但并非不可能——如上所述，Solana 已经足够成功，其自定义标准得到了一些以太坊工具的尊重，但将依赖 StarkWare 团队吸引不介意重建的开发人员的能力。

然而，如果他们能够成功地做到这一点，StarkWare 团队将寻求复制 EVM 的先发优势，并使用第一个针对 ZK Rollups 优化的智能合约 VM。

zkSync

另一个采用这种策略的团队是 zkSync。zkSync 创建了自己的 VM (SyncVM)，它基于寄存器并定义了自己的代数中间表示 (AIR)。然后他们构建了一个专门的编译器来将 Yul（一种中间语言，可以编译为不同 EVM 版本的字节码，认为是较低级别的 Solidity）编译成 LLVM-IR，然后他们将其编译成自定义 VM 的指令。这类似于 StarkWare 采用的方法，但理论上提供了围绕基础语言的更大灵活性（尽管目前仅支持 Solidity 0.8.x）。zkSync 团队最初创建了他们自己的类 CAIRO 语言 (Zinc)，但他们将大部分精力集中在 Solidity 编译器上，以便为 L1 开发人员提供更简单的迁移。一般来说，他们的策略是重用以太坊工具集而不是 StarkNet——我希望他们的客户端 API 等也更加“与以太坊兼容”。

zkSync 利用这个自定义 VM 来提供非 EVM 兼容的功能，例如账户抽象，这一直是核心以太坊协议的目标。这是自定义 VM 提供的好处的一个很好的例子——你不必等待以太坊构建新功能！

将所有内容放在一起，您可以清楚地看到每个团队遵循的不同策略：

Vitalik 的 zkEVM 类型

Vitalik Buterin 关于 zkEVM 的博客强调了 Rollup 团队目前面临的基本困境：EVM 不是为“可验证”程序构建的。事实上，正如我们通过上面的分析所表明的那样，你寻求与以太坊的兼容性越强，你的“可验证格式”程序的性能就会越差。Vitalik 根据与现有 EVM 基础架构的兼容性程度，确定了通用 Rollup 的几个大类：

我对他的论文的唯一扩展是指出，即使在每个“类型”中也存在很大程度的可变性——我们正在处理一个范围，而不是完全细分的类别。从开发人员体验的角度来看，对应用程序层进行单一、小的更改的 Type 3 rollup 比 Type 3 rollup 更常见，后者对应用程序层进行了大规模更改，但在技术上没有引入新的 VM 并成为 Type 4。

智能合约 Rollup 的现状

鉴于理解上述内容所需的细节，难怪我们围绕以太坊兼容性发明了一堆令人困惑的语言。事实上，没有 zk-rollup 在所有情况下都完美地反映了 EVM 的行为——这只是程度问题，每个团队做出的详细选择最终将最重要的是可维护性和性能，而不是仅兼容性。我的观点是以下定义是最清晰和最一致的：

至关重要的是要理解，上述方法都不是天生优越的——它是一种分类，而不是等级。它们都做出了不同的妥协：更容易构建、维护和升级，更高效，更容易与现有工具兼容。最终，领先的 Rollup 也将取决于更好的分销和营销，而不是纯粹的技术能力。话虽如此，做出正确的基本技术决策无疑具有重大优势。Scroll 对 EVM 规范的热心承诺是否能让他们轻松响应任何 EVM 升级？另一个团队更务实的方**帮助他们更快地进入市场吗？StarkWare 的定制 VM + 转译器方法是否会为长期扩展提供更坚实的基础？另一支玩家最终会从这个领域的先行者无疑会犯的错误中吸取教训并击败他们吗？归根结底，以太坊开发当前时刻的美妙之处在于，我们有不同的团队以截然不同的方法朝着一个共同的目标前进。

但在我们得意忘形之前，对当前智能合约 Rollup 的准备情况保持清醒也是适当的。每个团队都有强烈的动机将自己推销为“即将接管世界”——但最早要到 2022 年底，以太坊上才会有“生产级”智能合约汇总，其中许多团队将直到 2023 年才准备好。根据 StarkNet 的发展历程，我们应该预计从 rollup 到达测试网开始至少需要一年的迭代，然后 rollup 才能准备好支持主网上一致的生产级数量。

由于这种不成熟的状态，对于需要在不影响以太坊安全性的情况下进行扩展的开发人员来说，特定于应用程序的 Rollup 仍然是最强大的选择。事实上，即使通用 Rollup 可用并得到更广泛的集成，我预计在可预见的未来，应用特定 Rollup 的性能、定制和可靠性对于某些用例（例如交易所、NFT 铸造/交易）仍将保持优势。

其他 Rollup 因素

尽管本文的主要关注点，但这并不是关于以太坊生态系统兼容性与性能的全部内容！还有许多其他因素会影响您是否应该在特定的通用 Rollup 上进行构建。我将建议几个主要的附加标准：

费用：这些 Rollup 是否会以原生dai币、ETH 或两者的某种复杂组合收取费用？费用结构对用户和开发人员的体验有巨大的影响，因为 Rollup 通常需要拥有费用dai币来支付计算费用。

证明和排序：所有 Rollup 都需要一个实体，该实体负责对交易进行排序和生成证明。今天大多数特定于应用程序的 Rollup 都是“单排序器”，它以弹性为代价产生更高的吞吐量。大多数通用 Rollup 最初是作为单个排序器 Rollup 开始的，但他们通常计划随着时间的推移分散这个排序器。

自托管：ZK Rollup 的核心承诺是能够在保持以太坊安全的同时解锁扩展。然而，许多通用 Rollup 目前没有明确的机制来在发生恶意或不可用的排序器时恢复用户资产。

数据可用性：如介绍中所述，自托管保证取决于故障情况下状态数据的可用性。然而，完整的数据可用性为用户带来了额外的成本，从而导致了一系列数据可用性模式。这已经在特定于应用程序的 Rollup 世界（例如 Validiums、Volitions）中广泛使用，但是每个通用 Rollup 都需要单独添加此功能。

概括

智能合约 Rollup 是以太坊扩展路线图中令人难以置信的部分。这些 Rollup 在与现有以太坊工具集的关系中做出的不同妥协是对以太坊开发者生态系统多样性的惊人证明。

然而，目前关于 EVM 兼容性的讨论通常没有抓住重点。从开发人员的角度来看，所有这些 Rollup 都将支持 Solidity 代码。真正的以太坊兼容性是一个更大的挑战，但实际上需要权衡取舍，开发人员在进行 Rollup 之前应该意识到这一点。目前，大多数 Rollup 项目都是大规模的“超前销售”——销售其能力的 3 年以上愿景，而不是今天（甚至 12 个月内）可能实现的目标，这可能会使情况变得非常混乱。

为了透明起见，我希望每个主要的 Rollup 团队都能对以下问题提供更清晰的答案：

L1 和 L2 在 runtime 的确切差异是什么？L2 将修改哪些操作码？与 L1 相比，其他任何 VM 特征（例如费用结构）是否会有所不同？

您的自定义 VM 的正式规范在哪里，它在哪里比其他选项性能更高/性能更低？

此 rollup 将对其他以太坊接口（例如客户端 API、库）进行多少更改，这是否将破坏以太坊工具？

此 rollup 何时在测试网上上线？在主网上？能够支持 1000+ 定制合约 tps 的持续生产吞吐量吗？

您预计何时支持对用户资产的完全自我托管，在通用 rollup 的背景下会是什么样子？

一旦这些 rollup 在测试网上发布，这些问题应该更容易回答。在那之前，我很乐意看到团队继续发布更多关于他们的解决方案将做出的确切权衡的技术细节，以及这将如何影响智能合约和工具开发人员等。

随着合并即将到来，经过实战考验的特定应用程序 rollup 在生产中，以及通用 rollup 在明年进入主网，以太坊扩展的未来就是现在。