入门指南：zkEVM、EVM 兼容性和 Rollup 最全解读

ZK Rollups 长时间以来一向被认为是以太坊扩容的终极方针。但是，虽然它们对以太坊扩展路线图很重要，但几个关键点依然存在广泛的不确定性：

1. ZK Rollup 到底是什么？

2. 特定于运用程序的 Rollup 和通用 Rollup 之间有什么区别？

3. 什么是 zk-EVM Rollup？像 EVM 等效和 EVM 兼容这样的术语实践上是什么意思，它们怎么运用于 Rollup？

4. ZK Rollup 生态体系的现状怎么，这对生态项目意味着什么？

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

ZK Rollup

ZK Rollups 可以通过一个简略的调查来完结：像 STARK 或 SNARK 这样的证明体系答应运用亚线性处理来验证线性数量的句子（例如，1000 条句子 → 10 次验证者检查，10,000 条句子 → 11 次验证者检查）。咱们可以运用此特点来创立可大规划扩展的区块链买卖处理，如下所示：

1. 用户将他们的财物锁定在 L1 上的 ZK Rollup 智能合约中

2. 用户将触及这些财物的买卖提交给 L2 排序器，后者将它们收集到有序批次中，并为每个批次生成有效性证明（例如 STARK/SNARK）和聚合状况更新

3. 这个状况更新和证明被提交到咱们的 L1 ZK Rollup 智能合约并被验证，并用于更新咱们的 L1 状况

4. 用户可以运用这种 L1 状况（取决于不同的数据可用性机制）来检索他们的财物，然后完结彻底的自我保管和“以太坊安全”

简化的 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 的完结，当然也没有可以出产级的完结。但这种状况开端改变：

• StarkNet 现在已经在主网上运转（虽然处于有限的 Alpha 阶段）

• 3 个独立的项目（zkSync、Polygon Hermez/zkEVM 和 Scroll）都在 ETH CC 2022 上宣布它们将成为第一个进入主网的“zkEVM”

这些最新的公告值得深化研讨，因为这些团队不只宣布了通用 Rollup，他们还宣布了“zkEVM”。随之而来的是推特上许多环绕“EVM 兼容性”、“EVM 等效性”、“实在的 zkEVM”以及哪种办法更好的争辩。关于运用开发人员来说，这些对话一般是噪音——因而本博客的意图是分化这些术语、规划决议计划和理念，并解说它们对开发人员的实践影响。

让咱们从头开端：什么是 EVM？

了解 EVM

以太坊虚拟机（EVM）是履行以太坊买卖的运转时环境，开端在以太坊黄皮书中定义，后来被一系列以太坊改进提案（EIP）修正。它由以下部分组成：

• 用于履行程序的标准“机器”，每个买卖具有易失性“内存”，买卖可以写入的耐久“存储”和操作“仓库”

• 在这台机器中履行状况转化的约 140 个定价“操作码”

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

• 仓库操作 - PUSH1（向仓库增加一些内容）

• 算术运算 - ADD（加数字），SUBTRACT

• 状况操作——SSTORE（存储数据），SLOAD（加载数据）

• 买卖操作——CALLDATA、BLOCKNUMBER（返回有关当时履行业务的信息）

一个 EVM 程序仅仅一系列这些操作码和参数。当这些程序被表明为一个接连的代码块时，咱们将结果称为“字节码”（一般表明为一个长的十六进制字符串）。

通过将很多这些操作码组合成一个履行序列，咱们可以创立恣意程序。以太坊运用自定义虚拟机，而不是调整现有的 VM，因为它有独特的需求：

• 每个操作都有必要有“本钱”以避免乱用（因为一切节点都运转一切买卖）

• 每个操作都有必要是确定性的（因为一切节点有必要在买卖履行后就状况达到一起）

• 咱们需求特定于区块链的概念（例如智能合约、买卖）

• 一些杂乱的操作有必要是原语（例如暗码学）

• 买卖有必要是在沙盒里的，没有 I/O 或外部状况访问

EVM 是第一个图灵完备的区块链 VM，于 2015 年发布。它有一些规划束缚，但其巨大的先发优势和随后的广泛选用为以太坊发明了巨大的差异化——它是迄今为止最久经检测的区块链虚拟机。它是整个领域的智能合约根底设施。

因为以太坊的主导地位，许多后来的区块链都直接选用了这种运转时环境。例如，Polygon 和 BNBChain 是以太坊的直接分叉，因而运用 EVM。值得注意的是，EVM 并非原封不动，而且在 EIP1559 等晋级中常常被修正。因为其他区块链需求时刻进行更新，或许在多个地方与以太坊有所不同，它们一般运转着稍微过期的 EVM 版别，而且难以跟上变化的脚步——这一现实或许会让以太坊的中心开发人员感到懊丧。

以太坊兼容性

但是，人们所说的“EVM 链”一般不只仅仅仅镜像这个运转时环境。有几个首要标准始于以太坊并已成为现实上的全球标准：

• Solidity（一种编译成 EVM 字节码的高档言语）

• 以太坊的 JSON-RPC 客户端 API（与以太坊节点交互的标准）

• ERC20/ERC721（以太坊代币标准）

• ethers.JS（一个与以太坊接口的网络库）

• 以太坊的暗码学（例如 keccak256 作为哈希函数，对 secp256 k1 的 ECDSA 签名）

从技能上讲，您的链可以具有一个 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 支撑）。

ZK-EVM

公共通用 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 程序转化为这些电路，以便以后可以证明它们。

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

1. 通过将其转化为可验证的电路来直接证明 EVM 履行痕迹

2. 创立一个自定义 VM，将 EVM 操作码映射到该 VM 的操作码，然后证明该自定义环境中盯梢的正确性

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

选项 1：证明 EVM 履行痕迹

Scroll

让咱们从最直观的开端：证明 EVM 履行痕迹自身，这是 Scroll 团队（与以太坊基金会的隐私扩展团队一起）现在正在研讨的一种办法。为了完结这项工作，咱们需求：

1. 为一些暗码堆集器规划一个电路（答应咱们验证咱们正在准确地读取存储并加载正确的字节码）

2. 规划一个电路来链接字节码和实在的履行痕迹

3. 为每个操作码规划一个电路（答应咱们证明每个操作码的读取、写入和核算的正确性）

直接在电路中完结每个 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 是否会以原生代币、ETH 或两者的某种杂乱组合收取费用？费用结构对用户和开发人员的体会有巨大的影响，因为 Rollup 一般需求具有费用代币来付出核算费用。

• 证明和排序：一切 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 在下一年进入主网，以太坊扩展的未来就是现在。