EOF(EVM对象格式)带来零知识证明的优势

  • Succinct
  • 发布于 2024-11-05 13:19
  • 阅读 397

本文介绍了EVM Object Format (EOF)升级,它是以太坊虚拟机(EVM)的一个重要更新,旨在提升智能合约的效率和ZK友好的特性。EOF通过静态跳转替代动态跳转,简化了控制流,并引入了SWAPN和DUPN等新指令,从而降低了gas成本,提高了ZK证明的效率。实验结果表明,EOF合约在周期数和运行速度方面都有显著提升,同时减小了STARK证明的大小。

By Cairo / Succinct Residency 2024

以太坊虚拟机(EVM)是以太坊的计算核心。它使开发者能够构建任何人都可以访问的去中心化应用程序。即将到来的EVM更新之一是变革性的:EVM对象格式(EOF)升级引入了一系列对堆栈、控制流和可观察性的改进。

EOF合约交易不仅更便宜,即它们消耗更少的gas,而且它们对ZK非常友好。根据我们的基准测试,与当前EVM版本相比,EOF合约的ZK证明在周期方面效率提高了3倍,运行速度提高了2.69倍。这意味着使用像RSPOP-Succinct这样的库将变得更加经济实惠。

最重要的是,在大多数情况下,开发者可以通过升级到启用EOF的编译器版本(在本例中为solc)来享受这些性能提升,而无需修改他们的代码库。1

背景

目前,EVM使用动态跳转运行,跳转的目标是堆栈上的一个参数。虽然确定跳转目标通常很简单(例如,当它在跳转之前立即被推入堆栈时),但它也可能在计算上不可行(例如,当目标地址从存储中检索时)。此外,可能的执行路径数量随跳转次数和潜在目标呈组合式增长。因此,动态跳转混淆了程序的控制流,并显着阻碍了静态分析技术,如控制流和数据流分析。

为了解决这个问题,EOF启用了带有立即参数的指令(EIP-3670),用它们的静态等价物替换了动态分支指令(EIP-4200),并引入了用于调用子程序的指令。

当前EVM的另一个限制是,操纵堆栈的指令(如SWAP和DUP)只能达到16项的深度,而EVM的最大堆栈深度为1024。由于EOF启用了立即参数,因此期待已久的EIP-663可以通过引入SWAPN和DUPN来缓解这个问题,其中N是一个立即参数,其值在1到256之间。

在EOF中引入新的操作码可以实现更精简、更高效的合约,从而降低用户的交易gas成本。此外,验证可以在部署时执行一次,而不是在每次运行时执行,从而降低了合约交易的总体开销。除了这些改进之外,线性时间静态分析加速了工具链的每个部分,并解锁了新的工具。例如,更快的控制流分析可以加快编译器(包括JIT)和客户端的速度,改进数据流分析,并提供更强大的安全工具。

用EOF进行证明

为了具体地对EOF进行基准测试,我们实现了一个Solidity智能合约,该合约公开了一个函数,该函数接受一个整数输入n,并计算第n个斐波那契数模7919。然后,我们使用两个版本的Solidity的solc编译器编译了该智能合约:最新的稳定版本和EOF实验版本。从每次编译中,我们获得了相应的运行时字节码。

由于Revm的解释器支持EOF,我们实现了两个类似的Rust程序,它们设置并使用此解释器来部署每个相应的运行时字节码,并使用固定的输入调用斐波那契函数。然后,这些程序被编译为RISC-V ISA,并生成它们的RISC-V ELF文件。

为了生成证明,我们实现了一个SP1程序,该程序使用来自每个Rust程序的ELF文件,并证明它们的正确执行,从而为每个程序生成单独的STARK证明。然后验证反序列化的证明和公共值,以确保正确性。

性能优势

降低证明成本

为了确保准确的基准测试,我们利用SP1的周期跟踪来测量程序每个阶段花费的周期数。此外,对于两个版本,我们测量了端到端(E2E)执行时间、实现的kHz以及STARK证明大小。

如上所示,EOF程序在所有指标上都表现得更好。具体来说,EOF程序在解释器和总阶段的周期方面效率大约提高了3倍,同时运行速度提高了2.69倍。此外,生成的STARK证明大小是其对应证明大小的一半,这使得压缩时间更快。

当查看来自SP1的zkVM的操作码使用情况时,我们注意到EOF通常需要一半的操作码——BEQ、OR、BLTU和SRL操作码的节省非常明显。特别是最后一个操作码SRL,EOF使用了1570次,而当前的EVM程序使用了46,680次减少了96.64%

降低交易成本

当查看EVM的优势时,EOF版本展示了几个关键的改进。首先,与当前的EVM版本相比,EOF版本在调用斐波那契函数时需要减少16.08%的gas。此外,EOF字节码的大小明显更小,为327字节,而当前的EVM字节码为595字节,大小减少了45.04%。在性能测试方面,单独缓存的Foundry测试突出了效率的显着提高。EOF版本在0.602秒内完成了测试,而当前的EVM版本花费了更长的时间,为1.857秒

EOF如何推动性能改进

这些令人印象深刻的结果可归因于EOF升级引入的几项关键改进,这些改进共同提高了SP1中智能合约执行和证明生成的效率。

从解释器的角度来看,当前的EVM增加了大量的开销,无论是在操作码执行还是周期消耗方面,这都是由于对动态跳转的依赖及其带来的复杂性。另一方面,EOF的静态跳转消除了运行时计算跳转目标的需求。这不仅减少了执行的操作码数量,而且简化了控制流,从而实现了更高效的解释和执行。在严重依赖循环和条件分支的斐波那契合约的上下文中,使用静态跳转显着降低了与分支相关的成本。BEQ(如果相等则分支)、OR和BLTU(如果小于无符号数则分支)的操作码数量减少证明了这种效率。

此外,Solidity为避免堆栈限制而采取的变通方法涉及额外的操作码和复杂的堆栈混洗。例如,访问更深的堆栈元素可能需要多个SWAP和DUP操作,甚至需要按位移位(SRL),从而增加了操作码的使用量。在执行迭代计算并需要频繁访问各种堆栈深度的斐波那契合约中,这种增强减少了对其他堆栈操作逻辑的需求,从而大大减少了opcodes(如SRL)的使用,因为编译器不再需要通过低效的方式来模拟更深的堆栈访问。

上述改进的累积效应转化为更快的证明生成时间和更小的STARK证明。

新的解锁

除了增强的性能之外,我们对EOF特别感到兴奋,因为它解锁了SP1内部和外部的新功能。

EOF的结构化字节码和静态控制流使执行路径可预测且可线性分析,从而可以跨多个事务并行化SP1证明的生成,从而显着减少了总证明时间。这也意味着可以将事务轻松地划分为独立的段,而没有状态冲突或依赖的风险,这对于有效的访问列表至关重要。此外,由于EOF将数据和代码分成不同的部分,因此它可以在使无状态客户端更加实用和高效方面发挥关键作用。已经利用SP1的现有产品(如SP1 Reth和OP Succinct)可以通过集成EOF来利用这些改进。此外,通过EOF的堆栈改进,可以优化链上SP1验证器以更有效地管理堆栈,从而降低用户链上证明验证的成本。

包含方法和结果的存储库可以在这里找到。如果你对EOF及其与SP1的交叉感兴趣,我们鼓励你与我们联系。你可以在@cairoeth@SuccinctLabs找到我们。

脚注

  1. 如果代码库使用EOF中已弃用的操作码,则必须手动将其更新为等效的EOF操作码。此外,在确定另一个地址是否为合约方面存在限制,因为EOF不支持EXTCODESIZE(EIP-7761旨在解决此问题)。
  • 原文链接: blog.succinct.xyz/eofben...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
Succinct
Succinct
Building towards a proof-based future.