感谢Justin Drake、Elias Tazartes、Clément Walter和Rami Khalil的审阅和反馈。

TL;DR

在实现实时区块证明的道路上,本文提出了一种统一的数据格式,作为ZK-EVM证明引擎应该接受的输入,以证明以太坊执行层(或EVM)的区块(参见Vitalik的文章了解有关EVM执行的有效性证明的背景)。

注意: 本文仅关注ZK-EVM生成执行层证明的输入,不涉及共识层,这被视为一个独立的问题。

动机

ZK-EVM区块证明生态系统正在快速扩展,各个团队都在实现自己的ZK-EVM引擎,如Kakarot的Keth (Cairo)、RiscZero的Zeth (RiscV)和Succinct的RSP (RiscV)。

虽然所有这些ZK-EVM都旨在证明相同的EVM区块,但它们目前都接受独特的、供应商特定的输入。这阻碍了需要与多个供应商合作的操作员,也无法实现实时区块证明的中性和开放供应链。

本文提出了一种标准化的EVM数据格式,用于ZK-EVM证明输入,它:

• EL客户端可以为每个区块生成。
• ZK-EVM证明者接受以生成EL证明。

证明输入格式旨在通过以下方式促进实时区块证明的中性供应链的创建:

• 促进多证明证明基础设施: 允许操作员无缝地与多个ZK-EVM证明供应商合作,始终向每个ZK-EVM证明引擎传递相同的输入。
• 实现标准接口的创建: 在EL客户端(执行层完整客户端执行区块)和运行ZK-EVM(s)证明者(证明区块)的多个证明基础设施之间。

ZK-EVM证明输入

工作流程

ZK-EVM证明输入 2363×379 16.3 KB

在处理ZK-EVM时,我们可以大致区分三种用于生成区块证明的数据:

1. 证明输入: ZK-EVM引擎执行区块并生成执行跟踪所需的EVM数据。这是供应商无关的。
2. 执行跟踪: ZK-EVM引擎为每个区块生成的中间输入,证明引擎需要它来生成最终证明。这是供应商特定的。
3. 证明: 证明者的最终输出,执行和状态转换的证明。这是供应商特定的。

无状态性

在证明一个区块时,ZK-EVM证明引擎在没有直接访问完整节点的无状态环境中运行。因此,证明输入必须包含区块见证,即执行EVM区块所需的最小状态和链数据(执行该区块的所有交易,应用费用奖励,并推导出后状态根)。

证明输入数据

我们提出以下格式的证明输入数据:

注意: 这不包括截至父区块的累积难度,这在合并前上下文中对于分叉选择是必要的。假设不绝对需要证明合并前的区块,我们将这个问题留待讨论。

以JSON格式表示如下:

  
    
    
    
    

   
     
     
     
     
   
     
     
     
     
  
    
    
    
    
{"version": "...","blocks": [{"header": {...},"transactions": ["0x...",...]}],"witness": {"state": ["0x....",...],"codes": ["0x....",...],"ancestors": [{...},...]},"chainConfig": {"chainId": ...,"homesteadBlock": ...,"daoForkBlock": ...,"daoForkSupport": ...,"eip150Block": ...,...}}

证明输入格式

我们目前正在评估各种证明输入格式(如Protobuf、SSZ、RLP)和压缩(如gzip)选项。主要目标是:

• 减小证明输入大小: 加快网络通信,这对于实时区块证明至关重要。
• 确保兼容性: 支持所有主要编程语言和现有的区块链工具。

在单个证明输入中批量区块

为了实现批处理并优化证明成本,我们提出一个包含多个区块列表的证明输入(而不是单个区块)。

这允许一次性设置所有区块的见证,因此当多个区块访问相同的帐户、存储、头部或代码时,不会出现重复。

在需要每个区块都有证明的实时区块证明的背景下,证明输入将只包含一个区块,但其他用例可能会从列表中获益。

存储证明输入

除了将证明输入发布到实时区块证明的证明基础设施之外,证明输入还可以被重复使用于其他用例中。我们正在考虑将证明输入存储在以下位置:

• 数据可用性层(如Avail、Celestia): 理想地临时提供输入,允许所有证明者生成证明,然后删除数据。
• 共享数据存储桶(如S3): 公开读取,并制定政策冻结较旧的数据。

扩展到其他EVM链

证明输入格式可以通过使用特定版本轻松扩展到其他EVM链。例如,在Optimism的情况下,OP特定的链配置字段也将被包括在内。