基础指南：什么是 zkEVM、EVM 兼容性和 Rollup？

译者：Hakeen，校对：Evelyn

长期以来，ZK-Rollup 一直被视为以太坊可扩展性的终极目标。 然而，尽管它们对以太坊的扩张路径很重要，但在几个关键点上仍然存在一些不确定性：

zk-Rollup 到底是什么？

应用优化 Rollup 和通用 Rollup 有什么区别？

什么是 zk-EVM Rollup？ EVM 等效性和 EVM 兼容性等术语到底是什么意思，它们如何应用于汇总？

Zk-Rollup 生态系统的当前状态如何，这对我的项目意味着什么？

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

什么是 zk-Rollup？

Zk-Rollup的主要实现是：STARKs/sSNARKs等证明系统，使用次线性处理流程来验证线性数量的语句（例如，1000条语句→10个验证者确认，而10000条语句只需要11个验证者确认），此功能使我们能够处理大量的区块链交易流程：

用户将资产抵押在 L1 的 zk-Rollup 智能合约上

用户将包含这些资产的交易提交给L2排序器（sequencer），排序器将交易收集成有序的批次，并生成有效性证明，如stark/snark，最后更新状态。

此状态更新和证明已提交给我们的 L1 zk-Rollup 智能合约并由其验证，以更新我们的 L1 状态

用户可以使用这种 L1 状态（取决于不同的数据可用性机制）来取回他们的资产，实现完全的自我托管和“以太坊安全”

（简化的 ZK-Rollup 架构）

在这里，只要我们验证验证的 gas 成本与交易大小呈亚线性关系，那么就可以验证更大的交易。 要更详细地了解这个过程，我推荐 Vitalik 的 Rollups 不完整指南或 Delphi 新发布的 Complete Guide to Rollups。

应用程序优化汇总和通用汇总之间有什么区别？

在特定于应用程序的 Rollups 中，Rollups 支持由 Rollup operators 定义的固定数量的状态更改。 这可以优化某些应用程序，例如：

特定于应用程序的汇总非常适合解决特定的、易于理解的问题。 如果您作为一个项目的需求可以通过特定于应用程序的汇总来满足，您可能会获得更好的性能、更好的用户体验和更优惠的用例定价，因为它们缺乏通用性是一个巨大的优势。 例如，在 Immutable，我们能够通过补贴免费的 NFT 铸币厂和对 NFT 交易的转账收取费用来消除汽油费——只有在 Rollup 状态转换的可预测性质下才能进行权衡。

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

这种增加的灵活性带来了几个成本：性能大大降低、Rollup 参数的可定制性降低以及更高的费用。 然而，最大的代价是根本没有实现一个通用的 zk-Rollup，当然也不足以实现一个量产的 zk-Rollup。 但这种情况开始改变。

这些最后的公告值得深入研究，因为这些团队不仅宣布了通用 Rollup，他们还宣布了“zkEVM”。 随之而来的是围绕“EVM 兼容性”、“EVM 等效性”、“真正的 zkEVM”以及哪种方法更好的大量 Twitter 辩论。

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

了解 EVM（以太坊虚拟机）

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

图片来源：

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

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

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

EVM 是第一个图灵完备（和准图灵完备）区块链虚拟机，于 2015 年发布。它有一些设计限制，但其巨大的先发优势和随后的广泛采用为以太坊创造了巨大的差异化因素——到目前为止整个领域中最成熟的智能合约基础设施。

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

以太坊兼容性

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

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

尽管如此，针对以太坊规范的工具和应用程序的数量已经为新区块链单独镜像以太坊标准创造了巨大的动力。 任何不支持上述规范的区块链在开发者工具方面都会自动落后，并且随着 EVM 生态系统的发展可能会进一步落后。

我的看法是，术语“EVM 兼容”并不能真正充分描述此处描述的网络效应——我们真正描述的是“以太坊兼容”，并且远远超出智能合约执行环境，延伸到整个以太坊 Workshop 生态系统和工具集.

为了解决这个问题，像 Solana 这样的非 EVM 区块链必须创建完全并行的生态系统，这会减慢它们的速度并使其更难吸引现有的开发人员。 然而，不需要遵守这些标准确实允许非 EVM 区块链对以太坊的工具集进行更根本的改变，从而更积极地与以太坊区分开来。 创建 EVM 区块链很容易——但为什么有人会使用你的而不是其他数百个“快速 EVM 区块链”之一。 如果可以克服构建成功的平行链及其周围生态系统的困难，Solana 已经证明：a) 你可以吸引优秀的本地应用程序（例如 MagicEden、Phantom）和 b）如果商业激励足够（例如 Opensea 添加了 Solana 支持).

（为什么 Medium 不支持表格？）

ZK-EVM

Universal Rollups 都有一个共同的目标：让开发者和用户尽快产生网络效应。 这需要结合创建最高性能的 Rollup 技术、拥有最好的 BD 团队以及进行最早或最有效的营销。 然而，所有rullup团队（由于上述原因）都非常关心：

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

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

（为什么 Medium 不支持表格？）

要了解此编译过程的每个步骤，我推荐 Vitalik 的 SNARKs 零到英雄指南，以及 Eli Ben-Sasson 对不同证明系统的讨论。 然而，就我们的目的而言，这种更深入的理解是不必要的 - 请记住，为了支持 EVM 计算，我们必须将所有 EVM 程序转换为这些电路，以便以后可以证明它们。

从广义上讲，有几种方法可以做到这一点（归结为如何解决与底层电路和 evm 本身的兼容性问题）：

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

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

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

与以太坊的兼容性是自上而下的。

选项一：证明 EVM 执行轨迹

滚动

让我们从最直观的开始：证明 EVM 执行轨迹本身，这是 Scroll 团队（以及以太坊基金会的 Privacy Scaling 小组）目前正在研究的一种方法。 为了让它起作用，我们需要：

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

设计一个连接字节码和正确执行路径的电路

为每个操作码设计一个电路（让我们证明读写计算都是正确的）

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

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

不幸的是，EVM 的核心基础设施并不适合 zk-Rollups。 Rollup 性能的核心衡量标准是我们需要将特定计算编码到电路中的“约束”数量。 在许多情况下，直接镜像 EVM 会导致大量过载。 例如，EVM 使用 256 位整数，而 zk 证明自然地在有限的素数域中工作。 引入范围检查来对抗不匹配的域算法，每个 EVM 步骤添加大约 100 个约束。 以太坊的存储布局严重依赖 keccak256，其电路形式比 STARK 友好的哈希函数（如 Poseidon、Pedersen）大 1,000 倍——但替换 keccak 将导致与现有以太坊基础设施的巨大兼容性问题。 此外，与 SNARK/STARK 友好的椭圆曲线相比，标准以太坊椭圆曲线上签名的证明和验证非常昂贵。 （这些难编码的电路主要是因为以太坊标准的加密算法很难对zk实现。） 总之，直接证明EVM会导致大量的计算负荷。 然而，这里有很多好处（例如多项式承诺、递归证明、验证加速）证明 EVM 执行路径总是比在定制设计的 VM 中证明效率低得多，至少对 EVM 本身进行更改以使其更 SNARK之前友好（可能需要数年）。

选项二：自定义虚拟机 + 操作码支持

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

多边形

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

这些中间步骤为维护和潜在错误创造了更大的表面积，但对于实现高性能演示是必要的。 最后，重要的是要清楚您的程序不是在 zkEVM 中运行，它在电路中镜像 EVM，而是在替代的“zkExecutor”运行时中运行，它类似于但不同于 EVM 本身。 令人困惑的是，该团队将其称为“zkEVM”和“EVM 等效”——然而，由于这个自定义 zkASM 解释器，根据上述 Optimism 定义，这个 Rollup 程序实际上是“EVM 兼容的”。

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

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

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

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

斯塔克网

这是 StarkWare 对 StarkNet 采取的方法，StarkNet 是可用的最先进的通用 Rollup。 StarkNet 使用自己的低级语言（Cairo）来运行自定义智能合约 VM（Cairo VM），两者都是为智能合约 Rollups 构建的。 这意味着 StarkNet 没有开箱即用的以太坊兼容性——正如我们之前所见，即使是操作码级别的 VM 级兼容性也是 Rollup 性能的潜在障碍。

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

这种构建智能合约 Rollups 的方法保持了“Solidity-compatibility”：你不是在 EVM 内执行程序，也不是保持与任何其他以太坊接口的兼容性，但 Solidity 开发人员将能够编写与你一起工作的 Rollups。 因此，您可以在不损害 Rollup 的基础层的情况下保持与以太坊类似的开发人员体验 - 吃蛋糕就吃。

然而，这种方法有几个额外的权衡。 首先是构建您自己的 VM 具有挑战性——以太坊团队已经在 EVM 问题上工作了五年多，并且仍然经常进行升级和修复。 定制化程度更高的 Rollup 会带来更好的性能，但您将失去其他链和 Rollup 对 EVM 所做的所有集体改进的好处。

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

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

零同步

另一个采用这种策略的团队是 zkSync。 zkSync 创建了他们自己的基于寄存器的 VM (SyncVM)，并定义了自己的 Algebraic Intermediate Representation (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 2.5 Rollups 对应用程序层进行单一的小改动，比 Type 3 Rollups 更常见，Type 3 Rollups 对应用程序层进行大规模更改但不引入新的技术更改。 VM 并成为 Type 4。

智能合约 Rollup 现状

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

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

但在我们得意忘形之前，了解智能合约汇总的当前准备状态也是适当的。 每个团队都有强烈的动机将自己推销为“即将接管世界”的团队——但最早要到 2022 年底，以太坊上才会有“生产级”智能合约 Rollup，而且许多团队他们要到 2023 年才会出现。做好准备。 根据 StarkNet 的历史，在 Rollup 准备好支持主网上一致的生产级卷之前，我们应该期望从 Rollup 到达测试网起至少经过一年的迭代。

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

其他汇总因素

尽管本文的主要重点是以太坊生态系统的兼容性和性能，但它并不仅仅是关于以太坊生态系统的兼容性和性能！ 还有许多其他因素会影响您是否应该在特定的通用 Rollup 上构建。 我将建议一些主要的附加标准：

总结

Smart Contract Rollups 是 Ethereum 扩展路线图的重要组成部分。 这些 Rollups 相对于现有以太坊工具集所做的不同权衡是对以太坊开发者生态系统多样性的惊人证明。

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

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

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

随着合并指日可待，生产中经过实战检验的特定应用 Rollup，以及通用 Rollup 将于明年登陆主网，以太坊扩容的未来就在眼前。

原文链接：