AMM:入门指南：zkEVM、EVM 兼容性和 Rollup 最全解读_sudo币价格

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

ZKRollup到底是什么？

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

什么是zk-EVMRollup？像EVM等效和EVM兼容这样的术语实际上是什么意思，它们如何应用于Rollup？

ZKRollup生态系统的现状如何，这对生态项目意味着什么？

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

ZKRollup

ZKRollups可以通过一个简单的观察来实现：像STARK或SNARK这样的证明系统允许使用亚线性处理来验证线性数量的语句。我们可以使用此属性来创建可大规模扩展的区块链交易处理，如下所示：

用户将他们的资产锁定在L1上的ZKRollup智能合约中

用户将涉及这些资产的交易提交给L2排序器，后者将它们收集到有序批次中，并为每个批次生成有效性证明和聚合状态更新

这个状态更新和证明被提交到我们的L1ZKRollup智能合约并被验证，并用于更新我们的L1状态

用户可以使用这种L1状态来检索他们的资产，从而实现完全的自我托管和“以太坊安全”

简化的ZKRollup架构

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

特定于应用程序的Rollup

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

Loopring—支付和Swap

Immutable—NFT铸币和交易、游戏

dydx—永续交易

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

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

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

StarkNet目前已经在主网上运行

3个独立的项目都在ETHCC2022上宣布它们将成为第一个进入主网的“zkEVM”

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

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

了解EVM

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

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

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

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

堆栈操作-PUSH1

算术运算-ADD，SUBTRACT

状态操作——SSTORE，SLOAD

交易操作——CALLDATA、BLOCKNUMBER

一个EVM程序只是一系列这些操作码和参数。当这些程序被表示为一个连续的代码块时，我们将结果称为“字节码”。

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

每个操作都必须有“成本”以防止滥用

每个操作都必须是确定性的

我们需要特定于区块链的概念

一些复杂的操作必须是原语

交易必须是在沙盒里的，没有I/O或外部状态访问

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

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

以太坊兼容性

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

Solidity

以太坊的JSON-RPC客户端API

ERC20/ERC721

ethers.JS

以太坊的密码学

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

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

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

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

ZK-EVM

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

将现有的以太坊合约迁移到他们的rollup中

受到现有EVM工具的支持

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

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

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

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

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

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

创建自定义VM，将Solidity转换为自定义VM的字节码，并在自定义环境中进行验证

选项1：证明EVM执行痕迹

Scroll

让我们从最直观的开始：证明EVM执行痕迹本身，这是Scroll团队目前正在研究的一种方法。为了完成这项工作，我们需要：

为一些密码积累器设计一个电路

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

为每个操作码设计一个电路

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

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

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

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

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

Polygon

一个专注于这种方法的团队是PolygonHermez。Polygon的方法是构建一个zkEVM是“操作码级别的等效性”，这听起来最初类似于Scroll采用的方法。然而，与Scroll不同的是，Polygon的替代runtime运行定制的“zkASM”操作码而不是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为ZKRollups工作”方面投入了大量的开发时间，将兼容性优先于长期性能和可扩展性。还有另一种选择：创建一个全新的、专门构建的VM，然后添加对以太坊工具的支持作为顶部的附加层。

StarkNet

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

然而，Nethermind团队创建了Warp转译器，它能够将任意Solidity代码转换为CairoVM字节码。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的先发优势，并使用第一个针对ZKRollups优化的智能合约VM。

zkSync

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

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

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

Vitalik的zkEVM类型

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

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

智能合约Rollup的现状

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

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

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

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

其他Rollup因素

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

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

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

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

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

概括

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

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

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

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

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

此rollup将对其他以太坊接口进行多少更改，这是否将破坏以太坊工具？

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

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

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

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

标签：UDONFTAMMSWAPsudo币价格SQGL Vault (NFTX)AmmbrSWAPTC币

火星币热门资讯