干货 | zkEVM：设计挑战与解决思路

正文

请到「今天看啥」查看全文

add 的结果是正确的，你依然需要负担整个 EVM 电路的成本。如果你的执行追踪中有上千个操作，证明者就要负担 1000 倍的 EVM 电路成本 ³ 。

最近，有很多研究致力于利用这两种方法来优化零知识证明，包括（i）提议新的零知识证明友好型原语 Poseidon 哈希（Poseidon 哈希 在电路中的效率是 SHA256 的 100 倍）；（ii）持续提高通用可验证虚拟机的效率，就像 TinyRAM 那样；（iii）越来越多的通用优化技巧，如 Plookup，以及运行速度更快的密码学库。

在我们 之前的文章 中，我们提议为每个 dApp 设计 “ASIC” 电路，并让它们通过密码学承诺进行通信。然而，根据社区的反馈，我们改变了研究重点，将聚焦于使用第二种方式构建通用 EVM 电路（所谓的 “zkEVM”）。zkEVM 将带来与 Layer 1 完全相同的开发体验。我们不会把设计复杂性留给开发者，而是利用自定义 EVM 电路设计取而代之，解决效率问题。

zkEVM 的设计挑战

zkEVM 构建起来很难。尽管多年来这种直觉都很清晰，但是至今还没有人成功构建出原生 EVM 电路。不同于 TinyRAM，zkEVM 在设计和实现上更具挑战性，具体原因如下：

• 第一，EVM 对椭圆曲线的支持有限 。目前，EVM 只支持 BN254 配对。由于不直接支持 循环椭圆曲线 ，EVM 很难实现证明递归。在这种设置下，我们也很难使用其它专用协议。验证算法必须是 EVM 友好型的。
• 第二，EVM 的 word 大小是 256 位 。EVM 基于 256 位整数运行（就像大多数基于 32～64 位整数运行的普通虚拟机那样），零知识证明则 “天然” 基于素域运行。在电路中进行 “错配域算术” 需要范围证明，进而给每个 EVM 操作增加大约 100 个约束。这会将 EVM 电路大小增加两个数量级。
• 第三，EVM 有许多特殊的操作码 。不同于传统虚拟机，EVM 有很多特殊的操作码，如 CALL ，以及与执行环境和 gas 相关的错误类型。这会给电路设计带来新的挑战。
• 第四，EVM 是基于堆栈的虚拟机 。 SyncVM （zksync）和 Cario （starkware）架构在基于寄存器的模型中定义自己的 IR/AIR。它们构建了一个专门的编译器来将智能合约代码编译成一个新的零知识证明友好型 IR。该方法是语言兼容的，而非原生 EVM 兼容的。无论是证明基于堆栈的模型，还是直接支持原生工具链，都会变得更加困难。
• 第五，以太坊存储布局带来了高昂的成本 。以太坊存储布局高度依赖 Keccak 和一个巨型 MPT ⁴ 。二者都不是零知识证明友好型的，而且会产生高昂的证明成本。例如，Keccak 哈希的电路大小是 Poseidon 哈希的 1000 倍。但是，如果你将 Keccak 哈希替换成另一种哈希，就会给现有的以太坊基础设施带来一些兼容问题。
• 第六，基于机器的证明带来了高昂的成本 。即使你可以妥善处理上述所有问题，你依然需要找到一种有效的方法来将它们组合起来得到一个完整的 EVM 电路。正如我在上一节中提到的，即使像 add 这样简单的操作码也有可能需要你负担整个 EVM 电路的成本。

为何 zkEVM 在当下有可能实现

得益于研究者取得的重大进展，过去两年里越来越多效率问题得到了解决，zkEVM 的证明成本终于不再是障碍！最主要的技术进展体现在以下几个方面：

• 多项式承诺（polynomial commitment）的使用 。过去几年来，大多数简洁零知识证明协议都使用 R1CS，PCP 查询被编码到了特定于应用的受信任起步设置（trusted setup）中。这往往会增加电路的大小，导致很多自定义优化都无法实现，因为每个约束的度必须是 2（ 双线性配对 （ bilinear pairing ）只允许进行一次指数乘法计算）。有了 多项式承诺方案 ，你可以通过通用设置（universal setup）乃至透明设置（transparent setup）将你的约束提高到任何阶，大幅提高了后端选择的灵活性。
• 查找表参数和自定义小工具的出现 。另一个重要优化是查找表的使用。这个优化首次提议于 Arya，然后在

请到「今天看啥」查看全文