......对智能合约汇总当前的准备情况保持清醒也是适当的。每个团队都有强烈的动机将自己推销为“即将接管世界”——但以太坊上最早要到 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，但时间表尚未锁定。
Scroll2023 年，两个 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 的链中选择使用这两个证明器。
LineaLinea 早在 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。
TaikoTaiko 已经是第五个测试网了，计划明年在主网上上线。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 ErazkSync 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 模式。
StarkNetStarkNet 是以太坊生态系统中最雄心勃勃的项目之一：他们正在从零开始构建一个 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 
