随着"zkEVM战争"的加剧，公众对不同zkEVM的优点进行了大量讨论。但也有一些错误信息，因此我们想澄清一些关于Polygon zkEVM的事实以及与其他产品的比较。

我的观点可能存在偏见，因为我在Polygon工作，但我会尽力保持比较的公平性。我将重点关注Polygon的zkEVM和zkSync Era，因为它们正在生产中，而且我对其他zkEVM项目了解不多。

EVM兼容性

Polygon zkEVM直接执行EVM字节码，根据Vitalik的分类，它是一个三型zkEVM。它应很快变成二型，目前我们还缺少四个预编译版本。Scroll也在努力实现2型zkEVM。

相比之下，zkSync Era使用不同的字节码格式，通过提供的编译器支持Solidity，这使它成为一个四型kEVM：它支持Solidity，但不支持EVM字节码本身。像Hardhat这样的工具并不是开箱即用的，尽管它可以与zkSync的插件一起使用。

zkSync认为它们的zkVM更适合于未来，也就是说，它可以更好地与Solidity以外的语言一起工作。然而，他们的虚拟机似乎继承了EVM的许多性能特征，比如它的256位字大小。像Miden这样的zkVM可能更具有未来性，因为它是为通用计算设计的，而不是专注于Solidity。

性能

性能一直是Polygon的首要任务，我们的zkEVM非常高效。在CPU上运行我们的验证器，每笔交易的成本大约是0.000084美元。

虽然我们没有找到任何针对zkSync的zkEVM的工作基准，但我们怀疑由于我们对ZK技术的选择非常不同，因此存在很大的性能差距。

场选择

在研究了几个备选方案之后，我们选择了被称为Goldilocks的字段，一个阶为2^64-2^32+1的素字段。它的小尺寸和美丽的二进制结构导致了极快的场操作，在现代CPU上，乘法运算只需不到两个周期。

zkSync采取了一种更传统的方法，采用基于alt-bn128曲线的SNARK。底层字段大约254位，字段乘法在CPU上需要大约80个周期。

为了了解这可能造成的巨大差异，我们可以看看Celer的SHA2基准。在那里，我们的STARK验证器比基于椭圆曲线的验证器快5-50倍。

alt-bn128的优点是EVM原生支持它，所以向Ethereum提交证明更简单。在Polygon，我们反而用alt-bn128上的fflonk证明来"包装"我们的最终聚合证明。我们的方法需要更多的工作，但我们认为这是非常值得的，因为它有令人难以置信的性能提升。

算术化

差异还不止于此。我们的zkEVM建立在STARK的基础上，但有一个现代的扭曲。我们有一个用于CPU的主STARK(每个周期有一行)，以及用于算术、散列等等的其他STARK。然后这些表可以被连接起来，就像我们在RapidUp中描述的那样。这类似于物理CPU，它通常有协处理器来加速密集型操作，如渲染、加密或ML推理。

以Keccak为例。由于它被EVM应用大量使用，我们为它设计了一个专用的STARK，使用了一些新的技巧，我们在这里记录了这些技巧。设计这样的自定义算术需要大量的工作，但它得到了回报，使我们能够在每秒内证明数百个Keccak的排列组合。

zkSync采取的是我称之为更传统的方法。他们使用基于PLONK的验证器，虽然它确实支持自定义门，但它们的zkEVM并没有过多地使用它们；大多数计算是通过一个名为electorOptimizedWidth4MainGateWithDNext的通用门完成的。它似乎比普通的PLONK门稍微强大一些，但它仍然局限于简单的操作，如mul-adds。

值得称赞的是，zkSync确实使用了查找参数（我们也是），这是一种更现代的技术，可以帮助提高像Keccak这样的东西的效率。不过，如果没有自定义的算术，像256位数学、Keccak等等的效率就会大打折扣。

安全

Polygon非常重视安全问题，我们的zkEVM已经通过了两次独立的审计：一次是Spearbit，另一次是Hexens。两份报告都是公开的，在这里。我们还公布了验证部署的说明。

我们不知道zkSync的zkEVM有没有进行任何公开的审计。zkSync的网站列出了对桥接合同的审计，但没有列出zkEVM本身的。

除了审计，这两个项目都有各种"训练轮"来提供后备安全层，但这是一个丰富的话题，我不会在这里讨论。

L1数据

Polygon zkEVM将所有交易数据发布到L1，有一些关于与此相关的gas成本的混淆；请参见Edu的帖子以获得正确的数字。目前，平均交易大小约为120字节，因此每个交易的成本约为120*16=1920gas。

但zkSync发布了状态差异。恶意排序器可以扣留交易数据，但zkSync认为，拥有当前状态的trie就足以保证安全。这似乎有点值得商榷，因为交易数据通常被认为是可用的，而且某些应用程序依赖于此。

看一下修正后的数据，我们的zkEVM和zkSync的每笔交易的gas成本基本上没有区别。这些数字可能会随着时间的推移而变化，基于每个链上发生的交易的混合，但到今天为止，状态差异似乎没有节省任何gas；两个系统都在向L1发送每个交易的120字节左右。

我们正计划在这里进行一些优化，但不是用状态差异。交易本身可以被压缩，减少gas成本，同时提高交易的效率。