以太坊L1 zkEVM证明集成路线图

eth-act 发布于 2026-07-08 阅读 10

本文详细描述了以太坊L1支持zkEVM证明作为重执行替代方案所需的里程碑与子项目。涵盖从执行见证生成、zkEVM访客程序、zkVM-访客API标准化、共识层集成、证明基础设施到基准测试、安全性和ePBS的完整流程。每个项目都明确了目标、产出、依赖关系和工作组,展示了以太坊向零知识证明验证过渡的统筹规划。

===== 目录 =====

高层端到端流程

从高层来看,将证明发送到测试 attester 的流水线如下所示:

EL 客户端(有状态)
    
    ↓ 产生

ExecutionWitness(无状态输入)

    ↓ 被消费

zkEVM Guest 程序(无状态验证)

    ↓ 在以下环境中执行

zkVM(RISC-V 或其他目标)

    ↓ 产生

zkEVM 执行证明

    ↓ 被消费

CL 客户端(attester / 验证者)

下面我们描述实现上述工作流的子项目。

项目 1:ExecutionWitness

目标: 生成执行见证(ExecutionWitness),这是一个按区块生成的数据结构,包含验证该区块所需的所有数据。

负责人: EL 客户端

产出物:

  • execution-specs 中描述并附带测试的 ExecutionWitness 格式。
    • 这意味着需要在执行规范中提供生成该数据结构的方法,以便其他客户端检查是否符合规范。
  • execution-apis 中描述的 RPC 端点。
    • 目前我们使用 debug_executionWitness。初步来看,创建一个针对 zk 优化的新端点是最佳选择。该端点目前已在 Optimism 的 Kona 中投入生产。
  • 为 guest 程序优化 ExecutionWitness。
  • RPC 兼容性测试。
  • 在 EL 客户端中实现。
    • 客户端应能够为最近 $N$ 个区块生成 ExecutionWitness。这里的 $N$ 与 EL 对重组的容忍程度有关。
    • 客户端应符合上述规范。

里程碑: https://hackmd.io/i4z1eOYATKq3Ang-9Zw5hQ

依赖关系:

  • 上游:execution-specs
    • 具体而言,这受限于执行规范跟踪区块中访问了哪些状态的能力。这通过区块级访问列表(BALs)来实现。截至 2025 年 11 月,我们已告知 STEEL 团队,此优先级不够高,不足以让他们从 BALs PR 中提取出来并应用于之前的硬分叉。参见跟踪问题 这里
  • 下游:Guest 程序
    • 这是需要被证明的程序的非平凡输入。虽然我们有可选的证明,但这将主要通过 RPC 调用。

工作组:

  • Somnath (Erigon)
  • Pawel (Erigon)
  • Ignacio (EF zkEVM)
  • Peter (EF STEEL)
  • Ben (Nimbus)
  • Felix (Geth)
  • Guillaume (Geth)
  • Tanishq/Ruben (Nethermind)
  • Matt (Reth)
  • Karim (Besu)

项目 2:zkEVM Guest 程序

目标: 定义无状态验证逻辑,该逻辑消费一个 EL 区块 + ExecutionWitness,并确定是否存在有效的状态转换函数。

负责人: EL 客户端

产出物:

  • execution-specs 中描述并附带测试的无状态程序。
  • 可重现的编译工作流。
  • 编译为标准化的目标。
    • 该过程明确说明了有多少个目标以及我们对它们所做的假设。

里程碑: https://hackmd.io/i4z1eOYATKq3Ang-9Zw5hQ

依赖关系:

  • 上游: ExecutionWitness 稳定性(项目 1)
  • 下游: zkVM

工作组:

  • Somnath (Erigon)
  • Pawel (Erigon)
  • Ignacio (EF zkEVM)
  • Peter (EF STEEL)
  • Ben (Nimbus)
  • Kim (Nimbus)
  • Guillaume (Geth)
  • Felix (Geth)
  • Tanish (Nethermind)
  • Matt (Reth)
  • Gary (Besu)
  • Karim (Besu)
  • Jonathan (Axiom)

项目 3:zkVM-guest API 标准化

目标: 标准化 zkVM 与 guest 程序之间的接口。

负责人: EL 和 zkVM 团队

产出物:

  • 标准化目标列表。
  • 访问 zkVM 预编译的标准化接口。
  • 访问 IO 的标准化接口。
  • 明确假设条件;例如,对齐假设、内存布局假设、陷阱语义、bootloader、ELF 是否可以在代码中包含数据等。

里程碑:

  • 标准化最小硬件目标:
    • 每个 EL 可以编译到的目标。
    • 每个 zkVM 将针对的目标。
  • 通过 C 头文件标准化可用的 zkVM 预编译。
  • 通过 C 头文件标准化访问 IO 的接口。
  • 标准化关于 ELF 以及 zkVM 处理 ELF 方式的假设。

依赖关系:

工作组:

  • Somnath (Erigon)
  • Marcin (Lita)
  • Kev (EF zkEVM)
  • Alex Hicks (EF zkEVM)
  • Guillaume (Geth)
  • Maxim Menshikov (Nethermind)
  • Jordi (Zisk)
  • Alex Vlasov (Airbender)
  • Tamir (Succinct)
  • Jonathan (Axiom)
  • Stephen (Ziren)
  • Jeremy (RISC0)
  • Michael (Jolt)
  • Alan (Brevis)

项目 4:共识层集成

目标: 允许 CL 客户端将 zkEVM 证明作为信标区块验证的一部分进行验证。

产出物:

  • 关于如何修改 CL 以容纳证明的通用文档。
  • 稳定的 consensus-specs 版本。
  • 关于不同设计策略(例如 blob 中的区块)的文档和 EIP。
  • 针对 attester 和全节点可能对 EIP-7870 的变更文档。

里程碑:

  • 根据参考规范实现修改。
  • 在 consensus-specs 中移植修改。
  • 所有客户端应使用 consensus-specs 并确保通过相关测试向量。
  • EF 内部推广与接入计划

依赖关系:

  • 上游:依赖所有其他组件。

工作组:

  • Kev (EF zkEVM on Lighthouse)
  • Pari (EF PandaOps)
  • George (EF Cryptography research on proof size)
  • Barnabas (EF PandaOps)
  • Raul (EF Networking on proof sizes)
  • Manu (Prysm)
  • Jun Song + Uche (EPF on Prysm)
  • Gabriel (Teku)
  • Lucas (Teku)
  • Dapplion (Lighhouse)
  • Saulius (Grandine)
  • Kim (Nimbus)
  • Twoeth (Lodestar)

项目 5:证明者基础设施

目标: 创建必要的基础设施和接口,以便本地生成证明,并且 attester 客户端能够验证证明。

负责人: EF 和各证明团队

里程碑:

  • 将 zkVM 集成到 Ethproofs 中。
  • 确保 GPU 实现是开源的。
  • 将 zkVM 集成到 Ere 中。
  • 先在单 GPU 上,然后在多 GPU 上孤立测试 zkboost。
    • 这不需要使用无状态 guest 程序,因为我们主要关心的是测试基础设施,而不一定是无状态验证程序。
  • 跟踪证明者可靠性和流水线低效的指标。
  • 允许 attester 使用该基础设施来验证证明。

工作组:

  • Han (EF zkEVM)
  • Pari (EF PandaOps)
  • Stefan (EF PandaOps)
  • Barnabas (EF PandaOps)
  • Markus (EF Devops)
  • Fara (EF Ethproofs)
  • Kev (EF zkEVM)
  • zkVM 团队(就 GPU 编排和集成提供协助)

项目 6:基准测试与指标

这是一个长期项目。

目标: 实现健壮的基准测试机制,可用于未来的网络分析和 Gas 重定价。

负责人: EF

成果:

  • 解释我们希望针对以下项目进行基准测试/收集指标的文档:
    • Guest 程序:例如使用的操作码、原生循环计数及其与证明时间的关系。
    • CL:例如证明传播时间。
    • EL:例如见证生成时间。
    • zkVM:例如证明生成和验证时间、GPU 数量与证明时间的关系。
  • 针对 zk 的预计操作码重定价。
    • 包括调整某些操作码价格的 EIP 草案。
  • 定义证明者硬件要求。
    • 这是针对特定 Gas 上限的。
  • 使用 EIP-7870 对验证时间进行基准测试并记录。

里程碑:

  • 在本地(单 GPU 然后多 GPU)对所有可用的 zkVM 基准测试所有可用的 guest 程序。
  • 将指标集成到 pandaOps 实验室中。

工作组:

  • Ignacio (EF zkEVM)
  • Han (EF zkEVM)
  • Jochem (EF Prototyping)
  • Fara (EF Ethproofs)
  • Marius (EF Geth)
  • Maria (EF RIG)
  • Pawel (Erigon)
  • Pari (EF PandaOps)
  • Barnabas (EF PandaOps)

项目 7:安全

这是一个长期项目。

目标: 为所有不同组件(guest 程序、zkVM、GPU 编排、共识层客户端)建立安全指标。建立对这些指标的监控,并推动强化计划。

负责人: EL、CL、zkVM 团队、EF

产出物:

  • 相关证明系统组件的规范。
  • 遵循 EF 密码学研究博文(TODO:发布后插入链接)中安全指南和证明大小的 zkVM。
    • 这将要求具备可证明的安全性。
  • 创建分叉就绪审查文档。
    • 包括决定是否需要对可选证明进行漏洞赏金和审计。
  • 形式化验证:
    • 说明哪些组件我们希望针对可选证明进行形式化验证的文档。
    • 跟踪哪些 zkVM/EL 已进行形式化验证。
  • 持续威胁建模。
  • 关于证明者激励以及是否需要将其纳入协议内的决策树文档。
  • 用于监控测试覆盖率、审计、模糊测试和形式化验证的仪表板。
  • 记录每个组件(guest 程序、zkVM、证明者基础设施、CL/EL、递归)以及整个系统的安全模型和信任假设。
  • 供应链安全要求:
    • guest 程序、zkVM 和证明关键二进制文件的可重现构建和工件签名。
  • 与证明相关事件的应急响应和回滚手册。
  • zkVM 和 guest 程序的差异测试与模糊测试计划。
  • GPU 安全要求(侧信道、隔离、驱动风险、多租户约束)。

里程碑:

  • 就证明大小、安全制度和时间表达成一致。
  • 确定哪些证明系统组件需要规范。
    • 每个 zkVM 证明系统结构的规范。
    • 递归拓扑的规范。
    • 从论文到代码的算法规范。
    • 整个 SNARK 的精确安全性证明。
  • 确定规范的终极目标是什么,以及团队在短期内编写规范的价值是什么。
  • 确定每个组件的保证;例如:
    • guest 程序在无效输入时是否会 panic?
    • 验证者在收到无效证明时是否会 panic?
    • 程序是否被视为可信?
  • 建立用于推荐使用 ZKEVM 进行扩展的最低 go/no-go 框架。一些可能的指标:
    • 测试覆盖率
    • 审计覆盖率
    • 漏洞赏金
    • 稳定运行特定时间的 RTP
    • 软件多样性
    • 形式化验证
    • 模糊测试
  • 为以下每个组件确定最低可接受的形式化验证要求:
    • Guest 程序
    • 目标规范
    • SNARK 证明者
    • SNARK 验证者

工作组:

  • Alex Hicks (EF snarkification)
  • George (EF cryptography research)
  • Arantxa (EF cryptography research)
  • Fredrik (EF Protocol Security)
  • Marius (EF Geth) -- 负责 guest 程序安全
  • Kev (EF zkEVM)
  • Cody (EF zkEVM)
  • Marcin (Lita)
  • 负责规范的 zkVM 团队
  • Pari (EF PandaOps)
  • Barnabas (EF PandaOps)
  • Julian (RIG)

项目 8:ePBS(外部)

目标: 增加可用于证明区块的时间。

负责人: CL 开发者、EF 安全团队

注意: 这不是我们当前正在进行的项目。然而,这是我们需要的一项优化。如果没有这个功能,证明者创建证明的时间只有 1-2 秒。有了它,时间会增加到 6-9 秒。

时间线: 这将在 Glamsterdam 中部署。Glamsterdam 预计于 2026 年中推出。

主要诉求: 我们希望了解 ePBS 何时足够稳定,以便我们开始基于它进行工作重构。

工作组:

  • Potuz (Prysm)
  • Terence (Prysm)
  • Justin Traglia (EF security)
  • Mark (Lighthouse)
  • Shane (EPF on Lighthouse)
  • Saulius (Grandine)
  • Nico (Lodestar)
  • Enrico (Teku)
  • Stefan (Teku)
  • Caleb (Nimbus)

依赖关系: 下游: 共识层集成

  • 没有这一点,共识层 attester 将始终延迟 attest。

交互常见问题

  • zkVM 团队如何获取源代码以便为特定 EL 生成证明?(目前有些使用 RSP)
    • 我建议我们在 zkevm.ethereum.org 站点上为每个 EL 添加一个链接。
  • CL 从哪里获取 ELF 文件?
    • 通常,从所选 EL 的发布页面获取。
  • EL 从哪里找到用于互操作的 zkVM C 头文件?
    • zkVM 团队需要记录其位置。我建议将其放在 zkvm-standards 仓库中,与实际的标准放在一起。
  • zkVM 团队在哪里找到每个 EL 的 ELF 文件或源文件,用于本地测试?
  • 安全团队在哪里找到 zkEVM 的规范?
    • 目前尚未创建,不过我建议也将其放在 ethproofs 和 zkevm.ethereum.org 上。
  • 如果硬分叉之间需要升级(小补丁和关键错误修复),该怎么办?
  • 如何知道哪些应该是私有输入,哪些应该是公开输入?
    • 这将在 consensus-specs 中指定。
  • 原文链接: github.com/eth-act/plann...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~

相关文章

0 条评论