作者：Alex Connolly，Immutable联创兼CTO；翻译：xiaozou
2022年8月，我曾写过一篇关于zkEVM当前发展状态的博文，标题为《zkEVM、EVM兼容性及Rollup基础指南》（Ground Up Guide to zkEVM, EVM Compatibility and Rollups）。在同一周，V神发布了一篇文章，介绍了不同类型的zkEVM，确立了Type 1、Type 2分类法，现在通常用使用不同的Type分型来称呼不同的zkEVM——竞争很是激烈！
在那篇博文中，我做出了如下预测：
……还应该对智能合约rollup的当前状态有清醒认知。每个团队都有强烈的动机将自己推销为是那个“即将接管世界”的角色——但最早要到2022年底，以太坊上才会出现“生产级”的智能合约，而其中许多团队要到2023年后期才能做好准备。
我们现在已经到了“2023年结尾”了——zkEVM的开发和采用情况如何了？从zkEVM的很多方面来说，今年都是重要的一年：
·Polygon zkEVM、Linea和Scroll发布！
·Immutable宣布下一个rollup——Immutable zkEVM
·Polygon宣布计划将Polygon PoS升级至zkEVM Validium
·Optimism表明计划支持OP Stack链作为zkEVM运行
无论怎样，数据是不言自明的：
简而言之，zkEVM的开发工作正在进行中，但与现有的区块链相比，目前还没有哪个zkEVM获得了巨大采用。这篇文章的目的是回答一个显而易见的问题——各zkEVM项目进展情况如何，怎样才能产生可喜的关注度？
首先，让我们快速回顾一下V神的“zkEVM类型”，有助于理解zkEVM项目：
这看起来很复杂，但实际上很容易理解。每个人最初都在心里认为zkEVM只是采用现有的以太坊执行客户端（例如Geth、Nethermind、Erigon），生成其执行跟踪的zk（零知识）证明，并使用这些证明来确保L1-L2消息桥接。然而，EVM最初的设计考量并不包括zk证明，而且这种方法效率非常低（例如，以太坊的keccak哈希函数成本高昂）。所以，我们有几个选择：
·Type 1– 只管处理，我的用户/我将付费。这里有两个主要优势：你可以使用现有区块链的Type 1 Prover（证明程序），并且你不需要维护自己的以太坊客户端（开发成本可能与证明成本一样高），但是你必须保持执行客户端更新。
·Type 2-- 不触及“应用层”（例如，不改变操作码成本/实现），但要更改链上节点，使其具有对prover更友好的内部结构（例如，使用Sparse默克尔树来表示状态）。这种方法的一大缺点是，你需要维护一个永久分叉的以太坊客户端。考虑到以太坊已经在费力维护多个生产级客户端，这是一项非常重要的任务，需要有一个专业的区块链工程师团队。
·Type 3– 完成Type 2中的所有工作，同时修改EVM，去掉最难证明的部分（例如，一些很少使用的预编译），这可能会增加prover密集型操作的操作码成本。这是将你的prover推向市场的最快方式，但你需要进行上述所有客户端更新，并经历与现有以太坊应用和工具不兼容的情况（例如，使用这些预编译的任何合约都会中断）。
·Type 4-- 创建专为高效zk证明而设计的自定义VM，并创建运行该VM的自定义客户机。这将大大降低验证成本，但需要构建一个庞大的工具和基础设施生态系统来支持你的自定义VM/客户机。你或许能够提供某种形式的Solidity代码转换，但是开发人员可能必须对他们现有的合约和工具进行实质性的更改才能在你的链上部署。在我看来，大多数Type 4 rollup都不是真正的zkEVM——用“智能合约zk-rollup”来描述可能更准确。
用表格的形式可能更容易理解：
到2023年底，几乎每个活跃项目都是Type 3或Type 4 rollup，原因很简单：它们的构建速度要快得多（以兼容性和不断增加的维护开销为代价）！有趣的是，几乎所有目前属于Type 3的项目都计划最终成为Type 2或Type 1 rollup，以提高其与以太坊的兼容性，并有可能不再需要开发自己的客户端。
在去年的博文中，我主要关注了各zkEVM团队如何设计他们的prover。今年，我想涵盖各项目做法的其他重要方面，包括那些没有被经常讨论的事项（如各zkEVM执行客户端计划）。例如，许多人认为L2是“排序器”（sequencer）和prover，而标准的zkEVM设计实际上看起来更像是这样！
还有其他的排序器设计（我们将在后面讨论），但大多数zkEVM目前都计划运行一个单独的区块链作为L2排序器，具有自己的执行客户端（接收和执行交易）和共识客户端（就所有L2节点的交易顺序达成共识）。
重要的是，修改标准以太坊客户端来创建你自己的自定义链是有成本的。每次的以太坊客户端更改（特别是每次硬分叉）都将是所有zKEVM团队的治理决策项。自定义的部分越多，进行上游变更就越困难。随着时间的推移，很容易产生zkEVM异步——在某个点上与以太坊匹配的zkEVM将迅速失去同步。
1、zkEVM项目状态
那么，我们去年探讨的那些项目怎么样了？
（1）Polygon zkEVM（以及Polygon CDK链）
Polygon zkEVM于2023年3月在主网上线，迄今已处理了近1000万笔交易。它目前属于Type 3类型，目标是在2024年的某个时候成为Type 2。
当然，作为Type 2/3，Polygon zkEVM需要有属于自己的自定义客户端实现。Polygon选择从头开始构建自己的客户端（zkevm-node）以获取兼容性，但这个新客户端发生过停机事故，并且缺少许多标准以太坊客户端所具有的功能。
为了弥补这一点，Polygon与gateway.fm合作修改Erigon（以前的turbo-geth）以支持Type 2/3 prover所需的更改。这将为Polygon zkEVM提供一个更稳定的基础层和更优化的性能，尽管保持与上游Erigon的兼容性仍然是一个持续挑战。
许多团队也宣布将使用Polygon链开发工具包（CDK）构建zkEVM，包括Astar、OKX和Palm Network。Polygon CDK的愿景是支持开发人员按照自己的需求，通过结合使用不同的客户端、prover和数据可用性解决方案来构建自己的自定义链（即构建自己的zkEVM工具包）。如今，CDK支持一个客户端实现（zkevm-node）和一个prover（Polygon zkEVM）。未来，Polygon团队计划向CDK添加更多的客户端实现（例如Type-2-Erigon）和prover（例如Polygon Zero）。
这意味着你今天就可以部署你自己版本的Polygon zkEVM！但是，任何使用zkevm-node进行部署的团队将来都可能需要迁移到其他客户端，所以可能希望在准备好后再迁移。
我们还应该注意到，Polygon正计划将Polygon PoS（世界上最大、最成功的区块链之一）升级为一个具有链下数据的zkEVM，但具体升级时间表还未确定。
（2）Scroll
2023年Scroll上线了两个测试网和一个主网（10月）——这是大型建设之年！Scroll目前是一个Type 3 zkEVM，之前他们曾表示打算在未来转为Type 1/2，具体时间尚不明确。他们有一个与以太坊的差异列表，表里包含了一些未实现的预编译和一些微小的状态修改。Scroll的客户端是Geth v1.10.13的一个分叉，目前在单排序器模式下运行。值得注意的是，Scroll的执行客户端的某些部分已经落后于上游以太坊两年（尽管他们已经选择了上海执行客户端的EIPs来减少应用层偏差）。这不会对链造成任何直接的破坏，但却表明了许多项目将面临治理挑战，需要确定与上游以太坊长期保持多近的距离，以及需要多少工程努力才能不断缩小这一差距。
（3）Immutable zkEVM
7月份以来，Immutable zkEVM已经有了一个公共测试网，并计划在1月上线主网。Immutable zkEVM使用标准go-ethereum客户端版本，该版本已针对我们的核心领域（游戏）进行了定制。有趣的是，Immutable zkEVM是目前本文探讨的唯一一个特定域（domain specific）zkEVM，尽管L2能够根据特定领域的要求进行定制同时保持以太坊的安全性是它们的一个主要吸引力。例如，Immutable zkEVM满足于使用validium数据可用性来降低成本，并选择了单块最终性PoSBFT设计来提供近乎即时的确认，这些决策可能并不适合通用链。此外，如果大量的游戏和游戏用户涌向这条链，可能会产生网络效应——我们预计未来会出现更多的特定域L2。
然而，该链的发布不会提供prover支持。这是因为Immutable zkEVM计划在Type 1 Polygon Zero证明程序可用且具成本效益时再采用。Immutable发布Type 3的唯一方法是对客户端进行实质性更改，考虑到客户端偏离以太坊的影响，我们不愿意这样做。如今，Polygon Zero由Plonky-2提供支持，Plonky-3正在积极开发中，预计在2024年中后期达到生产级，届时性能将提高约一个数量级。这将为Polygon提供两个独立的prover（Polygon Zero和Polygon zkEVM），开发人员将能够在他们基于CDK的链中选择使用哪个prover。
（4）Linea
Linea在8月份发布了他们的主网，并采用了与Polygon/Scroll类似的方式：从Type 3 rollup开始，逐渐转为Type 1或Type 2型。Linea目前与以太坊London只有若干不同之处，如表中所示。
Linea正在使用他们自己更新的Geth版本，他们将其命名为“zkGeth”。值得注意的是，这个客户端的源代码不是开源的，prover也不是开源的——用户无法验证它们是否按预期运行。他们计划将所有这些组件开源，作为他们文档完备的去中心化路线图的一部分。Linea的文档表明，他们计划从“zkGeth”转为linea-besu，这是对Consensys开发的Besu客户端的更新版本。从中期来看，Linea团队计划合并linea-besu和常规besu，并依靠Besu的插件系统来进行必要的状态修改，以成为一个Type 2 zkEVM。
（5）Taiko
Taiko正在打磨他们的第五个测试网，计划明年上线主网。Taiko正在开发他们自己的基于PSE实现的zk prover（与Scroll类似）。有趣的是，Taiko是本文中唯一一个目前不考虑将单个排序器逐步去中心化为一个L2区块链这种设计模式的团队。Taiko的设计基于Justin Drake所描述的Based Rollup概念——而不是拥有一个经许可的validator（验证者/器）集，任何人都可以向以太坊L1提交交易包和证明。这种实现意味着rollup将排序完全委托给了以太坊L1，允许它自动继承以太坊L1的活跃度和去中心化特性。然而，它存在一个重要的缺点：L2排序器不会提供“快速最终性”确认，也就是说用户等待交易确认的时间更长。Justin Drake提出了“Based preconfirmations（预确认）”机制，以提供延迟仅为100ms的概率确认，但是还没有接近生产水平，并且引入一个单独的“preconf（预确认）承诺”和“preconf tips”系统可能会对现有的以太坊工具产生影响。这是一个活跃的研究领域！
Taiko从一开始就表示他们计划成为Type 1 zkEVM。他们认为，其他zkEVM带来的兼容性差异将比更高昂的证明生成成本还要糟，无论如何，随着技术的进步，成本终将会下降。Taiko的客户端实现很有趣——核心的“执行客户端”是经过修改的Geth v1.13 (taiko-geth)。然而，他们也在维护自己的“共识客户端”(taiko-client)，它处理与L1的通信并监控based排序过程。
（6）zkSync Era
zkSync Era于2023年3月发布，到目前为止可谓是成功的，即将进行空投的传言将其TVL推高至5亿美元以上。zkSync是Type 4 zkEVM，他们正在证明自己的自定义VM (eraVM)，而不是试图直接修改EVM。他们的目标是与以太坊进行“语言级兼容”，并提供了一个从Solidity代码到他们的自定义VM的直接编译器。他们对许多关键EVM操作码的实现进行了实质性的更改，对编译过程也进行了一些更改，所以开发人员常常需要修改他们的合约或部署脚本才能在zkSync Era上进行部署。
zkSync Era有自己的自定义客户端，允许他们实现非EVM功能，如原生帐户抽象。2023年7月，他们将prover升级为“Boojum”，这是一个STARK证明系统，然后用SNARK包装进行链上验证，类似于Polygon zkEVM。zkSync Era需要完全链上数据，但他们计划在未来引入“zkPorter”，这将允许用户在不同价位的不同数据可用性模式之间进行选择，与StarkWare提出的Volition模型类似。
（7）StarkNet
StarkNet是以太坊生态系统中最雄心勃勃的项目之一：他们正在从头开始构建一个Type 4 rollup和生态系统，其中包括一个新的VM (CairoVM)、一个新的编程语言(Cairo)、一个新的prover (Stone)和新的客户端（Pathfinder、Papyrus、Juno）。StarkNet在2021年和2022年逐步开放，现在拥有超1.5亿美元的TVL，月处理交易量超1000万笔。
从头开始构建新生态系统是极具挑战性的，但也为EVM一直在努力的领域（例如原生账户抽象）提供了根本性创新的机会，并大幅提高了性能。该工具链的大部分已经通过基于StarkEx的项目（如Immutable X、dydx v3和Sorare）完成了广泛测试，这些项目自2020年以来一直在运行，并已被广泛采用。
最初，StarkNet生态系统通过我去年提到的Warp Solidity→Cairo转译器等项目探索了语言级别的兼容性。然而，Warp现在已经过时了，而StarkNet生态系统已经决定完全致力于新的CAIRO工具集，而不再支持任何类型的Solidity向后兼容性。现在，他们面临着与Solana或Sui等非EVM生态系统相同的挑战——你能让大量开发人员采用你的新工具吗？还是普遍存在EVM会胜出？
Kakarot团队正在做的工作是唯一的一个例外，他们正在使用CAIRO语言开发一个Type 2.5 EVM，将作为运行在StarkNet上的一组合约。通过Kakarot，用户将能够部署在StarkNet上拥有代码/状态的EVM合约并与之交互，允许用户从StarkNet的性能中受益，同时保留EVM兼容性。由于底层执行环境仍将是StarkNet，这将牺牲以太坊工具的兼容性——但对于某些项目来说，这可能是一个可以接受的权衡。Kakarot还没有达到生产级别，这种分层方法的性能和工具兼容性的影响还不清楚，但这是一个令人兴奋的尝试，可以弥合各种zkEVM类型之间的差距，也表明我们在探索设计空间方面行动很早。
（8）Optimism
由于显而易见的原因，Optimism通常被认为是一个专注于optimistic rollup的团队。然而，他们一再表示计划支持zk零知识证明作为未来的一种选择，并且已经与几个积极贡献的团队进行了热烈讨论。像zeth这样令人兴奋的zk生态项目现在提供Optimism区块支持。然而，我们还没有看到任何正式的时间表或设计——也许在明年的zkEVM回顾中会有令人兴奋的变化！
正如你所见，各个kEVM团队之间的做法有很大的差异。即使是同一种类型的rollup也经常采用与其prover、客户端和排序机制截然不同的设计。
还有另一种非常重要的方法来比较这些新的zkEVM——它们的实际配置！一般来说，分析各链的客户端和prover的体系结构要更加有趣，因为涉及到根本的设计决策，而不是可以轻松更改的应用级配置。然而，如果你是一个应用程序开发人员，具体配置无疑是很重要的，所以一定要确保你研究了每个zkEVM的区块时间、区块gas限制、证明发布频率、排序器共识机制以及任何可能影响应用程序用户体验的因素！
综上所述：2023年，各种各样的团队进行了大量的开发工作。所以，如果一切正在进展中，我们是否只需要静静等待？我们还需要解决什么问题，才能看到zkEVM获得实质性的关注度？
2、zkEVM开发中还有哪些悬而未决的问题？
首先，客户端和prover之间缺少标准化接口。目前，每个prover仅与最初构建它们时所用的客户端兼容。你无法在任何其他Type 2/3客户端上使用Polygon zkEVM的prover。理想情况下，任何新的prover或客户端都应该与尽可能多的现有prover/客户端兼容。鼓励各种zkEVM团队遵循单一接口的EIP是未来发展的关键一步。
可以理解的是，大多数团队目前都在优先改进自己的部署，而不是寻求与他人的兼容性。目前这种做法可能是可以接受的，但最终我们尤其希望L2排序的zkEVM可以使用多客户端/prover设置，以减少重大bug风险。此外，标准化“经典”type 2功能的实现（例如Sparse默克尔树、Poseidon哈希函数而非keccak）可能有助于多个prover使用相同或相似的客户端。减少“geth”类客户端的数量将是该生态系统的巨大胜利！一项名为“RollCall”的标准化倡议已被提出，同时还提出了一系列Rollup优化建议（RIPs），虽然目前尚不清楚这一倡议的关注度有多高。
其次，这些zkEVM几乎全都是单一排序器，是对这些rollup的去中心化和安全性的挑战。尤其要注意，prover的行为只是为了确保L1-L2桥接是安全的。任何依赖于L2预确认的外部系统(如CEX)都将大量资金置于风险之中，因为它们完全依赖于单一排序器——对于今天的许多L2来说，极具破坏性的黑客攻击只需要盗用一个排序器密钥就可实现。然而，一旦你将排序器去中心化，就会出现不同的挑战（正如你在上述Taiko内容中所见！）。你是否需要向L1提供一个zk证明，证明已经达成了L2共识？活跃度问题呢？MEV呢？大多数单一排序器rollup出于品牌/声誉/链信任的原因目前都没有利用MEV，但这种情况可能会在未来有所改变。
第三，没有衡量zkEVM性能和成本的标准框架。本文的大部分内容都在比较各种zkEVM设计的潜在性能影响，但是目前很少有zkEVM团队发布任何真正的性能规范或测试。“zkEVM成本”由以下几部分构成：
·生成证明的云计算成本（受电路效率影响）
·验证证明的L1成本
·数据可用性成本
·从一层向另一层发送信息的成本
我应该能够为这些领域创建标准化测试，并将结果制成表格，以帮助建设者做出更明智的决策——目前这是不可能的。细微差别在这里：在某些类型的交易中，一些prover实现将比其他prover更佳，部分成本将取决于使用情况，因为能够在交易包中分摊交易成本。这些成本应该如何呈现给用户也是一个很大的不确定性（例如，Immutable zkEVM计划在大多数情况下为用户支付发布成本，而Scroll则有一个复杂的L1 + L2收费设置，以确保每笔交易都是盈利的）。此外，许多zkEVM可能会遇到与状态增长相关的性能问题——扩展以太坊区块空间不是免费的！所有这些都需要比现在更高的可衡量性/可比性。
第四，对于大多数智能合约rollup而言，退出机制仍然没有被很好地理解和定义。自我托管在特定应用rollup（如Immutable X）上被很好地定义——你存放到该L1桥中的任何资产都应该是可检索的，即使排序器完全脱机或完全是恶意的。这通常被称为“逃生舱口”。但这在智能合约rollup的情况下意味着什么呢？如果你的ETH质押在一个合约中，无论如何都不应可用呢？这一切都是关于抗审查性吗（我们需要保证强制交易的能力吗）？对于用于不同目的（例如游戏资产与DeFi）的zkEVM来说，什么程度的数据可用性是可接受的？我们需要一致的框架向用户传达实际的故障情况——L2 Beat在这方面开了个好头！
第五，zkEVM与以太坊L1之间的关系尚不明晰。在撰写本文期间，我再一次被V神发布的一篇反思“enshrined zkEVM”的博文所吸引。主要内容是以太坊客户端层可以“enshrined” zk prove实现，可用于验证其他来源（例如L2）提交的EVM区块的执行情况。这就避免了让所有L2 zkEVM都必须保持他们的zkEVM prover是最新的（重大胜利！）——他们可以依靠其他团队的工作成果，包括核心以太坊客户端团队，一个完全SNARK的以太坊已成为现实。那么，我是否应该将“enshrined zkEVM”的提议解读为偏离以太坊以L2为中心的扩展路线图，将L2捕获的价值带回？
不完全是这样。L2仍然需要自己的排序器来提供快速确认（在游戏等领域至关重要），而V神提出的设计只支持具有完全链上数据的zkEVM。出于变现等原因，大多数L2几乎都希望保持独立性，这对以太坊生态系统来说是一个重要的权衡。L2对于以太坊区块空间的扩展至关重要，但他们的动机（和BD团队）可能并不总是与以太坊对齐。
最后，多个zkEVM将继续分散用户和流动性，致使用户体验很糟。如今，每多一个以太坊L2将继续分散状态和流动性——如果你在Arbitrum上有2枚ETH，那么在任何其他L2上访问ETH都是有难度的。在我看来，这是迄今为止对单体链的最佳论证，在单体链中，可组合性得到了极大改善，用户不必在多个链之间进行平衡。随着当前“L2工具包”（例如Polygon CDK、Arbitrum Orbit、OP Stack）流行开来，启动链从未如此轻松，但代价是更大程度的碎片化问题。
为了使这种多L2模型取得长期成功，在大多数情况下，我们需要将单个链和平衡从用户中抽象出来。这是有效性证明优于欺诈证明更有力的论据之一——快速链间桥接的即时性证明验证。然而，即使有了强大的桥接/互操作性框架，仍然有大量的用户体验问题需要解决。在Immutable，我们的计划是通过钱包层的Immutable Passport和垂直整合和来解决这个问题。
3、结论
对于zkEVM来说，2023年既是开发进展的重要一年，也是准备实际采用的一年。2024年将是Type 1和Type 2 zkEVM真正准备好投入生产使用的第一年，但实际上我们最早也要到第三/四季度才能使用——想要实现这一目标，我们还需要解决很多性能问题！
我想清楚地表明，zkEVM在2024年要解决的主要问题不是技术问题（虽然我们显然还有一些技术问题需要解决），而是价值问题——我们能在下一代L2上为用户创建令人兴奋的应用程序吗？我们需要出色的协议开发人员和出色的应用程序开发人员！
