不同 zkEVM 之间的比较

随着“zkEVM 战争”的升温，公众对不同 zkEVM 的优点进行了大量的讨论。也有一些错误的信息，所以我们想澄清一些关于 Pogon zkEVM 的事实以及它与其他产品的比较。

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

zkSync 的 zkEVM 和验证器构成了超过 10 万行的代码。我尽力给出一个准确的总结，但如果有任何不准确的地方，请告诉我，我将予以纠正。

EVM 兼容性

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

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

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

性能

性能一直是 Pogon 的首要任务，我们的 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 提交证明更简单。在 Pogon，我们反而用 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 等等的效率就会大打折扣。

安全

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

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

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

L1 数据

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

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

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

我们正计划在这里进行一些优化，但不是用状态差异。交易本身可以被压缩，减少 gas 成本，同时仍然保证交易数据的可用性。更多关于这个问题的信息很快就会出现！

本站声明:网站内容来源于网络,如有侵权,请联系我们,我们将及时处理。