2022 年 8 月，我写了一篇关于 zkEVM 现状的博客：Ground Up Guide to zkEVM, EVM Compatibility and Rollups。同一周，Vitalik 发表了自己的关于不同类型的 zkEVM 的博客文章，其中建立了 1 类、2 类分类法，现在通常用于描述 zkEVM——激烈的竞争！
在那篇博客中，我做了一个预测：
……对智能合约汇总当前的准备情况保持清醒也是适当的。每个团队都有强烈的动机将自己推销为“即将接管世界”——但以太坊上最早要到 2022 年底才会出现“生产级”智能合约汇总，而且其中许多团队将直到 2023 年才准备好。
好吧，我们现在已经“进入 2023 年了”——zkEVM 的开发和采用状况如何？对于 zkEVM 在许多方面来说，今年都是重要的一年：
- Polygon zkEVM、Linea 和 Scroll 全部推出！
- Immutable 宣布我们的下一个 rollup 将是 Immutable zkEVM
- Polygon 宣布计划将 Polygon PoS 升级到 zkEVM Validium
- 乐观表明他们打算支持将 OP Stack 链作为 zkEVM 运行
然而，数字不言而喻：
TVL 是一种不完美但相关的牵引力衡量标准。数据来自 CoinGecko。
简而言之，zkEVM 的开发正在取得进展，但与现有区块链相比，目前 zkEVM 还没有得到广泛采用。本博客的目的是回答一个显而易见的问题 – 各个 zkEVM 项目进展如何，以及如何才能产生我们希望看到的吸引力？
首先，让我们快速回顾一下 Vitalik 的“zkEVM 类型”，这有助于描述 zkEVM 项目：
这看起来很复杂，但实际上很容易理解。每个人对 zkEVM 的初始思维模型只是采用现有的以太坊执行客户端（例如 Geth、Nethermind、Erigon），生成其执行跟踪的 zk 证明，并使用这些证明来保护 L1 <> L2 消息桥。然而，EVM 的设计并没有考虑到 zk 证明，而且这种方法效率非常低（例如，以太坊的 keccak 哈希函数非常昂贵）。
- 类型 1 – 处理它，我的用户/我将付费。这里有两个主要优点：您可以将类型 1 证明者与现有区块链一起使用，并且您不需要维护自己的以太坊客户端（开发成本可能与证明成本一样昂贵），尽管您必须保持执行客户已更新。
- 类型 2 – 不触及 “应用层”（例如，不改变操作码的成本/实现），但修改链上的节点，使其具有对验证者更友好的内部结构（例如，对状态使用稀疏梅克尔树）。这种方法的最大缺点是，你需要维护一个永久分叉的以太坊客户端。鉴于以太坊已经在努力维护多个生产级客户端，这是一项非同小可的任务，需要一个专业的区块链工程师团队。
- 类型 3 – 执行类型 2 中的所有操作，同时修改 EVM，删除最难证明的部分（例如一些很少使用的预编译），并可能增加证明者密集型操作的操作码成本。 这是将证明器推向市场的最快方法，但您需要对客户端进行上述所有修改，并且会遇到与现有以太坊应用程序和工具不兼容的地方（例如，任何使用这些预编译的合约都会被破解）。
- 类型 4 – 创建一个专门用于高效 zk 证明的自定义虚拟机，并创建一个用于运行该虚拟机的自定义客户端。这将大大降低证明成本，但您需要建立一个庞大的工具和基础设施生态系统，以支持您的定制虚拟机/客户端。您或许可以提供某种形式的 Solidity 代码转换，但开发人员可能需要对现有合同和工具进行重大修改，才能在您的链上部署。在我看来，大多数第 4 类卷积并不是真正的 zkEVM–“智能合约 zk-卷积 “可能是更准确的描述。
以表格的形式可能更容易理解：
到 2023 年底，几乎每个实时项目都是类型 3 或类型 4 的 rollup，原因非常简单：它们的构建速度要快得多（以兼容性和增加的维护开销为代价）！有趣的是，几乎每个当前属于类型 3 的项目都旨在最终成为类型 2 或类型 1 的 rollup，以提高其与以太坊的兼容性，并有可能消除开发自己的客户端软件的需要。
在去年的博客中，我主要关注每个 zkEVM 团队如何设计他们的证明器。今年，我想介绍每个项目方法的其他重要方面，包括绝对没有足够频繁讨论的事情（例如每个 zkEVM 执行客户端的计划）。例如，许多人认为 L2 是“排序器”和“证明器”，而标准 zkEVM 设计实际上看起来更像是这样！
还有替代的排序器设计（我们将在稍后讨论），但大多数 zkEVM 目前计划运行一个单独的区块链作为 L2排序器，拥有自己执行客户端（接收和执行交易）和共识客户端（就所有 L2 节点的交易顺序达成共识）。
重要的是，修改标准以太坊客户端来创建自定义链是有代价的。每个以太坊客户端变更（尤其是每个硬分叉）都将成为所有 zKEVM 团队的治理决策点。定制的越多，采用上游更改就越困难。随着时间的推移，这很容易导致漂移——在某个时间点与以太坊匹配的 zkEVM 将迅速变得不同步。
zkEVM 项目的现状
那么我们去年报道的项目在哪里呢？
Polygon zkEVM（和基于 Polygon CDK 的链）
Polygon zkEVM 于 2023 年 3 月在主网上推出，迄今已处理了近 1000 万笔交易。它目前是第 3 类（参见以太坊差异），目标是在 2024 年的某个时候成为第 2 类。
当然，作为 Type 2/3，Polygon zkEVM 需要自己的定制客户端实现。Polygon 选择从头开始构建自己的客户端（zkevm-node）以实现兼容性，但这个客户端是新的，曾遭遇过中断，而且缺少标准以太坊客户端中的许多功能。
为了弥补这一缺陷，Polygon 与 gateway.fm 合作修改了 Erigon（原 turbo-geth），以支持 2/3 型验证器所需的更改。这将为 Polygon zkEVM 提供更稳定的基础层和更高的性能，但保持与上游 Erigon 的兼容性仍将是一个持续的挑战。
许多团队也宣布将使用 Polygon Chain Development Kit（CDK）构建 zkEVM，其中包括 Astar、OKX 和 Palm Network。Polygon CDK 的愿景是允许开发人员根据自己的需求，通过组合不同的客户端、证明器和数据可用性解决方案（即自建 zkevm 工具包）来构建自己的定制链。目前，CDK 支持一种客户端实现（zkevm-node）和一种证明器（Polygon zkEVM）。未来，Polygon 团队计划为 CDK 添加更多客户端实现（如 Type-2-Erigon ）和证明器（如 Polygon Zero）。
这意味着您今天就可以部署自己的 Polygon zkEVM 版本！但是，任何使用 zkevm-node 进行部署的团队将来都可能需要迁移到另一个客户端，因此您可能需要推迟到准备就绪为止。
我们还应该注意到，Polygon 正计划将 Polygon PoS（世界上最大、最成功的区块链之一）升级为带有链外数据的 zkEVM，但时间表尚未锁定。
Scroll
2023 年，两个 Scroll 测试网和一个主网（10 月份）相继启动，这是大规模建设的一年！Scroll 目前是一个 Type 3 zkEVM，他们曾表示有意在未来转为 Type 1/2，但时间表尚不明确。他们列出了与以太坊的不同之处，包括几个未实现的预编译和一些小的状态修改。Scroll 的客户端是 Geth v1.10.13 的一个分叉，目前以单序列器模式运行。值得注意的是，Scroll 执行客户端的某些部分已经落后于以太坊上游两年（尽管他们已经挑选了上海执行客户端的 EIP，以减少应用层偏差）。这不会立即对以太坊链造成任何干扰，但却表明了许多项目在确定如何长期保持与上游以太坊的紧密联系，以及需要付出多少工程努力才能不断缩小这一差距时，将面临的治理挑战。
Immutable zkEVM
免责声明：我是 Immutable 的联合创始人/首席技术官。
Immutable zkEVM 自七月起开始公开测试网络，并计划在一月推出主网络。Immutable zkEVM 使用的是为我们的核心领域（游戏）定制的标准 go-ethereum 客户端版本。有趣的是，Immutable zkEVM 是目前这份名单上唯一针对特定领域的 zkEVM，尽管 L2 能够在保留以太坊安全性的同时根据特定领域的要求进行定制是其主要吸引力之一。例如，Immutable zkEVM 满足于使用 validium 数据可用性来降低成本，并选择了单块终结 PoSBFT 设计来提供近乎即时的确认，而这些决定可能并不适合通用链。此外，如果大量游戏和游戏用户涌入这条链，可能会产生网络效应–我们预计未来会看到更多特定领域的 L2。
不过，该链将在没有证明者支持的情况下启动。这是因为Immutable zkEVM计划在Type 1 Polygon Zero求证器可用且具有成本效益时采用它。Immutable推出Type 3的唯一方法是对客户端进行大量修改，但考虑到客户端逐渐远离以太坊的影响，我们不愿意这样做。目前，Polygon Zero 基于 Plonky-2，Plonky-3 正在积极开发中，预计在 2024 年中后期达到生产级时，性能将提高约一个数量级。这将为 Polygon 提供两个独立的证明器（Polygon Zero 和 Polygon zkEVM），开发人员可以在其基于 CDK 的链中选择使用这两个证明器。
Linea
Linea 早在 8 月份就推出了自己的主网，其发展路径与 Polygon/Scroll 类似：从 3 类卷积开始，随着时间的推移逐渐过渡到 1 类或 2 类。Linea 目前与 Ethereum London 仅有几处不同之处，详见本表。
Linea 正在使用他们自己修改过的 Geth 版本，并将其命名为 “zkGeth”。令人担忧的是，这个客户端的源代码没有公开，证明器也没有公开–用户无法验证两者的性能是否符合预期。他们正计划开源所有这些组件，这也是他们记录详实的去中心化路线图的一部分。Linea的文档显示，他们计划从 “zkGeth “转向linea-besu，后者是对Consensys开发的Besu客户端的修改。从中期来看，Linea 团队计划将 linea-besu 与普通 besu 合并，并依靠 Besu 的插件系统（如 https://github.com/Consensys/besu-shomei-plugin）进行必要的状态修改，以成为 Type 2 zkEVM。
Taiko
Taiko 已经是第五个测试网了，计划明年在主网上上线。Taiko 正在基于 PSE 实现（类似于 Scroll）开发自己的 zk 校验器。有趣的是，Taiko 是本文中唯一一个目前正在考虑采用其他设计的团队，而不是逐步去中心化为 L2 区块链的单一序列器。Taiko 的设计基于贾斯汀-德雷克（Justin Drake）所描述的 Based Rollup 概念，即任何人都可以向以太坊 L1 提交批次和证明，而不是拥有一个经过许可的验证器集。这种实现方式意味着卷积可以有效地将排序完全委托给以太坊 L1，使其自动继承以太坊 L1 的有效性和去中心化。然而，它也有一个重要的缺点：L2 排序器不会提供 “快速终结 “确认，这意味着用户可以预期每笔交易的确认时间会更长。贾斯汀-德雷克（Justin Drake）提出了 “基于预确认”（Based preconfirmations）的方案，以提供延迟时间仅为 100 毫秒的概率确认，不过该方案尚未接近量产，而且引入单独的 “预确认承诺 “和 “预确认提示 “系统可能会对现有的以太坊工具产生影响。这是一个活跃的研究领域！
从一开始，Taiko 就表明了成为 1 类 zkEVM 的意图。他们认为，其他 zkEVM 带来的兼容性差异比更高的证明生成成本要糟糕得多，而随着技术的改进，这种差异会逐渐降低。Taiko 的客户端实现非常有趣–核心 “执行客户端 “是经过修改的 Geth v1.13 (taiko-geth)。不过，他们也在维护自己的 “共识客户端”（taiko-client），该客户端负责处理与 L1 的通信并监控基于排序的过程。通过将 L1 通信逻辑分离到共识客户端中，他们可以保持与上游以太坊执行客户端的紧密联系。
zkSync Era
zkSync Era 于 2023 年 3 月推出，迄今为止一直很成功，有关即将空投的传言将其 TVL 推高至 5 亿美元以上。zkSync 是 4 类 zkEVM，因为他们正在证明自己的定制虚拟机（eraVM），而不是直接尝试修改 EVM。他们的目标是与以太坊实现 “语言级兼容”，并提供了从 Solidity 代码到其定制虚拟机的直接编译器。他们对许多关键 EVM 操作码的实现进行了大量修改，并对编译过程进行了若干修改，这意味着开发人员通常需要修改他们的合约或部署脚本，以便在 zkSync Era 上进行部署。
zkSync Era 拥有自己的定制客户端，允许他们实现非 EVM 功能，如本地账户抽象。2023 年 7 月，他们将证明器升级为 “Boojum”，这是一个 STARK 证明系统，然后用 SNARK 封装，用于链上验证，类似于 Polygon zkEVM。zkSync Era 需要完全的链上数据，但他们计划在未来推出 “zkPorter”，允许用户在不同价位选择不同的数据可用性模式，类似于 StarkWare 提出的 Volition 模式。
StarkNet
StarkNet 是以太坊生态系统中最雄心勃勃的项目之一：他们正在从零开始构建一个 Type 4 版本和生态系统，包括一个新的虚拟机（CairoVM）、一种新的编程语言（Cairo）、一个新的验证器（Stone）和新的客户端（Pathfinder、Papyrus、Juno）。StarkNet 在 2021 年和 2022 年逐步开放，现在的 TVL 已超过 1.5 亿美元，每月处理的交易超过 1000 万笔。
从零开始建立这一新的生态系统极具挑战性，但却为在 EVM 一直苦苦挣扎的领域进行根本性创新（如本地账户抽象）和大幅提高性能提供了机会。该工具链的大部分内容已通过基于 StarkEx 的项目（如 Immutable X、dydx v3 和 Sorare）进行了广泛测试，这些项目自 2020 年起就已上线并被广泛采用。
最初，StarkNet 生态系统通过我去年提到的 Warp Solidity → Cairo 转译器等项目探索语言级兼容性。然而，Warp 现在已经日落西山，StarkNet 生态系统转而决心完全致力于新的 CAIRO 工具集，而不是追求任何类型的 Solidity 向后兼容性。现在，他们面临着与 Solana 或 Sui 等非 EVM 生态系统相同的挑战——你能否让足够数量的开发人员采用你的新工具，还是 EVM 的普遍性会让他们胜出？
但 Kakarot 团队的工作是个例外，他们正在 CAIRO 构建 2.5 型 EVM，它将作为 StarkNet 上的一组合约存在。通过 Kakarot，用户将能够部署并与在 StarkNet 上拥有代码/状态的 EVM 合同进行交互，从而使用户能够从 StarkNet 的性能中获益，同时保持 EVM 的兼容性。由于底层执行环境仍将是 StarkNet，这将牺牲以太坊工具的兼容性，但对于某些项目来说，这可能是一个可以接受的权衡。Kakarot 还不是生产级的，这种分层方法对性能和工具兼容性的影响尚不明确，但这是弥合各种 zkEVM 类型之间差距的一次令人兴奋的尝试，也表明我们在探索设计空间方面还处于起步阶段。
奖励：Optimism
由于显而易见的原因，乐观主义通常被认为是一个只关注乐观向上的团队。不过，他们一再表示有意在未来支持 zk-proving，并与多个提供贡献的团队进行了积极讨论。像 zeth 这样令人兴奋的 zk 生态系统项目现在也支持乐观主义区块。不过，我们还没有看到任何正式的时间表或设计——也许明年的 zkEVM 评审会有令人兴奋的更新！
正如您所看到的，不同的 zkEVM 团队采用的方法大相径庭。即使是共享一种类型的 rollup，其证明器、客户端和排序机制也往往采用了根本不同的设计。
比较这些新生的 zkEVM 还有一个非常重要的方法——它们的实际配置！一般来说，每个链的客户端和验证器的架构更值得分析，因为这关系到基本的设计决策，而不是可以轻易更改的应用级配置。不过，如果您是应用程序开发人员，配置细节绝对重要，因此请务必研究每个 zkEVM 的区块时间、区块气体限制、证明发布频率、排序器共识机制以及其他可能影响应用程序用户体验的因素！
综上所述：在 2023 年，不同的团队进行了大量的开发工作。那么，如果开发正在进行，我们是否只需要等待？我们还需要解决哪些问题，才能让 zkEVM 获得实质性的发展？
zkEVM开发中还有哪些未解决的问题？
首先，客户端和证明器之间没有标准化接口。目前，每个证明器只能与它们最初构建的客户端兼容。您无法将 Polygon zkEVM 的证明器用于任何其他 2/3 型客户端。理想情况下，任何新的验证器或客户端都应尽可能与现有的验证器/客户端兼容。一个鼓励不同 zkEVM 团队遵从单一接口的 EIP（例如这里提出的草案）是未来的重要一步。
可以理解的是，大多数团队目前都在优先改进自己的实现，而不是寻求与其他团队的兼容。这在目前也许是可以接受的，但最终我们希望 L2 序列的 zkEVM 尤其能使用多客户端/验证器设置，以降低出现重大错误的风险。此外，“经典”第 2 类特征（如稀疏梅克尔树、波塞冬哈希函数而非 keccak）的标准化实现可能有助于多个证明者使用相同或相似的客户端。减少“几乎是 geth”的客户端数量将是生态系统的巨大胜利！有人提出了一项名为“RollCall”的标准化倡议，同时还提出了一系列“Rollup Improvement Proposals”（RIPs 💀），但目前还不清楚其影响力有多大。
其次，这些 zkEVM 几乎都是单序列器，这给这些 rollup 的分散性和安全性带来了挑战。值得注意的是，验证器的作用只是确保 L1 <> L2 桥接的安全性。任何依赖 L2 预确认的外部系统（如 CEX）都会因完全依赖单排序器而将大量资金置于风险之中——对于目前的许多 L2 来说，破坏性的黑客攻击只需要一个受损的排序器密钥。然而，一旦将排序器去中心化，就会出现另一系列挑战（如上文对太鼓的描述所示！）。你是否需要提供 zk 证明来证明 L1 达成了 L2 共识？有效性问题怎么办？MEV 又是怎么回事？出于品牌/声誉/链信心的考虑，大多数单排序器 rollup 目前都没有利用 MEV，但这在未来可能会改变。
第三，目前还没有衡量 zkEVM 性能和成本的标准框架。本文的很多内容都集中在比较各种 zkEVM 设计对性能的潜在影响，但目前很少有 zkEVM 团队公布任何实际的性能规格或测试。zkEVM 成本 “有几个独立的组成部分：
- 生成证明的云计算成本（受电路效率影响）
- 证明验证的 L1 成本
- 数据可用性成本
- 从 Lx <> Ly 发送信息的成本
我应该能够为这些领域创建标准化测试，并将结果列表，以帮助构建者做出更明智的决定–目前这是不可能的。这里有一些细微差别：在某些类型的事务中，有些验证器实现会比其他验证器更好，有些成本取决于使用情况，因为可以在批次中摊销事务成本。如何向用户公布这些成本也是一个很大的不确定因素（例如，Immutable zkEVM 计划在大多数情况下为用户支付发布成本，而 Scroll 则有一个复杂的 L1 + L2 费用设置，以确保每笔交易都有单位利润）。此外，许多 zkEVM 都可能会遇到与状态增长相关的性能问题——以太坊区块空间的扩展并不是免费的！上述所有问题都需要比现在更加可衡量/可比较。
第四，对于大多数智能合约卷来说，退出游戏的理解和定义仍然很模糊。自我保管在特定于应用程序的卷积（如不可变 X）中有明确的定义——即使序列器完全离线或完全恶意，你存入 L1 桥的任何资产都应该是可检索的。这通常被称为 “逃生舱门”。 但在智能合约卷积的情况下，这意味着什么呢？如果你的 ETH 押在合约中，无论如何都不应该可用，那该怎么办？这一切是否都与抵制审查有关–我们是否需要保证强制交易的能力？对于用于不同目的的 zkEVM（例如游戏资产与 DeFi）来说，什么程度的数据可用性是可以接受的？我们需要一致的框架来向用户传达实际的故障情况–L2 Beat 在这方面已经有了一个良好的开端！
第五，zkEVM 与以太坊 L1 之间的关系仍不明确。在这篇文章的初稿和最终发布之间，Vitalik 又发布了一篇反映 “enshrined zkEVMs “的博文。简而言之，以太坊客户端层可以有 “enshrined “zk 校验器实现，用于验证从其他来源（如 L2）提交的 EVM 区块的执行。这可以避免每个 L2 zkEVM 都必须不断更新自己的 zkEVM 校验器（大赢家！）——当完全 SNARK 化的以太坊成为现实时，他们可以借助其他团队的工作，包括核心以太坊客户端团队。那么，我是否应该将 “enshrined zkEVMs “的提议理解为偏离以太坊以 L2 为中心的扩展路线图，将 L2 捕获的价值带回母船呢？
其实不然。L2 仍需要自己的序列器来提供快速确认（在游戏等领域至关重要），而 Vitalik 提议的设计将仅支持完全链上数据的 zkEVM。大多数 L2 几乎肯定希望出于货币化原因保持独立性，这表明以太坊生态系统需要做出重要权衡。L2 对于扩展以太坊区块空间至关重要，但其激励机制（和 BD 团队）可能并不总是与以太坊保持一致。
最后，多个 zkEVM 将继续造成用户和流动性的分散，带来糟糕的用户体验。如今，每增加一个以太坊 L2，都会继续分裂状态和流动性–如果你在 Arbitrum 上有 2 个 ETH，那么在任何其他 L2 上访问这些 ETH 都很困难。在我看来，这是迄今为止支持单体区块链的最好理由，因为单体区块链的可组合性得到了极大改善，用户不必在多个链上玩弄余额。随着目前 “L2 工具包”（如 Polygon CDK、Arbitrum Orbit、OP Stack）的大量涌现，创建链变得前所未有的容易，但这是以更大的碎片化为代价的。
要想让这种多 L2 模型取得长期成功，我们需要在大多数情况下将单个链和平衡从用户中抽象出来。这是有效性证明优于欺诈证明的最有力论据之一——即时证明验证可在链之间快速桥接。然而，即使有了强大的桥接/互操作性框架，仍有大量的用户体验挑战需要解决。在Immutable，我们的计划是通过垂直整合和钱包层的Immutable Passport来解决这个问题。有关这方面的更多信息，敬请期待！
概括
2023 年对于 zkEVMs 来说，既是取得开发进展的一年，也是为实际应用做准备的一年。2024 年将是第 1 类和第 2 类 zkEVM 正式投入生产使用的第一年，但实际上我们最早也要到第 3 季度/第 4 季度才能用上它们，而且我们还需要解决许多性能问题才能实现这一目标！
我想明确指出，zkEVM 在 2024 年要解决的主要问题不是技术问题（尽管我们显然还存在一些问题），而是价值问题–我们能否在下一代 L2 上为用户创造令人兴奋的应用？我们既需要出色的协议开发人员，也需要出色的应用开发人员！
如果您想在zkEVM技术的未来发展和通过帮助开发者构建主流Web3游戏来推动应用普及这两者之间的交叉点上工作，我们Immutable公司正在招聘！
微信扫一扫 
