EIP-8025：为Hegotá分叉引入可选执行证明

Hegotá（计划在 Glamsterdam 之后进行的分叉）的非头条提案窗口现已开放，L1-zkEVM 工作正在将 EIP-8025（可选执行证明）提交纳入，并可能附带两个相关的 EIP。

如果该提案落地，这将是迈向以太坊路线图中更重要的架构转变之一的第一步：通过验证证明而不是重新执行来验证区块。本文介绍提案内容、为何现在提出以及研发进展状况。

执行证明改变了什么

如今，每个全节点通过重新执行区块中的每一笔交易来验证每个区块。其成本随区块消耗的 Gas 线性增长，并且每个验证节点都必须持有 EL 状态才能完成工作。

这两者都将节点需求与吞吐量耦合：提高 Gas 上限会提高运行节点的门槛。

zkEVM 证明（正确执行证明）提供了一种替代方案。节点无需重放交易，而是下载一个小的证明并验证它。

验证是无状态的（不需要 EL 状态），关键在于，检查证明的成本在区块大小上大致是恒定的：一个 60M Gas 的区块和一个 600M Gas 的区块验证时间大致相同。

zkEVM 证明的这一特性使得 Gas 上限可以在不提高运行验证节点门槛的情况下提升（另请参阅此入门指南，了解如何使用 zkEVM 证明扩展以太坊）。

EIP-8025 包含什么？

提交纳入 Hegotá 的核心提案是 EIP-8025：可选执行证明。它引入了一种共识层机制，通过该机制，信标节点可以使用通过 P2P 网络接收的 zkEVM 证明来验证执行负载的有效性，而不是纯粹在本地重新执行。

该 EIP 定义了两个新的可选节点角色，在规范中表示为节点可以独立或同时启用的模式：

• 证明者（证明生成模式）以利他方式为每个区块的执行生成 zkEVM 证明并进行广播。
• zkAttesters，也称为无状态证明者（证明验证模式），通过检查接收到的 zkEVM 证明来验证区块，并在此基础上进行证明。

EIP-8025 主要位于共识层，但它也引入了一个执行层产物：来宾程序，即在 zkVM 内部运行并构成证明者所证明的计算的区块执行逻辑。

EVM 本身未被修改；现有的 EL 客户端继续像以前一样生成负载。

重要的是，未选择加入的验证者不会看到任何变化。

为什么首先保持可选？

L1-zkEVM 是以太坊上区块验证方式的重大转变，其影响范围涉及协议栈的许多部分：执行层、共识层、密码学、网络、经济学和治理。

使 EIP-8025 成为非共识关键性，可以让网络在主网条件下测试实时的 zkEVM 证明生成与验证，且只有一部分证明者选择加入。

在此可选阶段，证明职责仍由 EL 客户端对负载的重新执行驱动，证明仅作为补充检查而非唯一有效性来源。已选择加入但未及时收到足够有效证明的节点，将像今天一样进行证明。

如果证明延迟、缺失或存在 Bug，这保留了稳健的备用方案，并且对于单个 zkAttester 来说，这是理性的立场：在可选阶段，证明生成是利他行为，而错过或延迟的证明将转化为错失的及时性奖励。

为何现在提出？

ZK 技术已经显著成熟。证明栈已在 L2/汇总中生产运行多年。作为以 Rollup 为中心路线的逻辑延续，想法是让 L1 本身成为一个汇总——一直以来都是如此 🧑‍🚀🔫🧑‍🚀

此外，EIP-8025 的 CL 和 EL 规范已基本确定，并且两者都已拥有可运行的客户端实现。作为完全可选的更改，纳入 Hegotá 风险较低：未启用任何模式的验证者不会看到行为、带宽或证明职责的任何变化。

同样重要的是，现在提出 EIP 可以将工作锚定在协议升级流程中，而它本应在此处。非常实际地说，客户端团队、zkVM 团队、工具维护者和规范编写者应该感到有权力分配持续的资源来研究 zkVM、来宾程序、执行见证生成以及相关的测试基础设施。

证明是否以及何时最终成为协议原生的和强制性的，是后续 EIP 和后续分叉的单独决定。届时，证明者将不再需要运行有状态的 EL 客户端——从而大幅降低运行验证节点的成本。

还有哪些提案同时提出？

除了 EIP-8025，更广泛的 L1-zkEVM 部署还需要进一步的 EL 适配，这就是为什么在 EIP-8025 之外还提交了两个 EL 侧提案：

• EIP-7709：将 BLOCKHASH 操作码重新路由，以从 EIP-2935 历史系统合约中读取，而不是依赖客户端对近期区块的本地视图。这移除了 EVM 中最后一个隐式假设有状态的操作码，并相应调整 Gas 价格以反映底层存储读取成本。
• EIP-8200（EVM 化）：将一组有限的使用率低的预编译替换为等效的 EVM 字节码，这将显著减少最坏情况下的证明时间。如果攻击者可以构造一个需要几分钟才能证明的区块，那么平均个位数秒的证明价值有限。

这两个提案可能会在 Hegotá 或之后落地。EIP-8025 的规范不依赖它们中的任何一个即可工作；伴随的 EIP 使后续步骤更清晰，但它们不是前置条件。

同时正在进行哪些工作？

一个运行 EIP-8025 的多客户端初始 Devnet（基于 Lighthouse 和 Prysm）将在未来几周内启动，作为首个集成目标。EF 的 zkEVM 团队与 EL 和 CL 客户端团队以及 zkVM 团队密切合作，已经进行了数月的联合准备。

与此同时，EF 正在委托建立一个本地 GPU 证明集群，用于基准测试和持续的证明工作，这将为标准化和证明基础设施工作流提供一个稳定的开发目标。

一旦 Glamsterdam 规范稳定下来，预计后续 Devnet 将基于 Glamsterdam 的两个功能进行适配：区块级访问列表（BAL），允许证明者获取状态并并行化证明工作；以及 ePBS（内置提议者-构建者分离），它重新构建了时段，为证明者在区块可用性和证明截止时间之间提供更宽松的时间窗口。

如何参与

• 计划在 5 月 14 日的下一次 AllCoreDevs 共识会议上提议将 EIP-8025 纳入 Hegotá。收听完整介绍。
• EIP 讨论可能会在 ethmagicians 帖子中进行。
• 还有每月一次的 L1-zkEVM 分组电话会议（安排在协议日历上）。
• 异步讨论在 Eth R&D Discord 上进行，其中 #l1-zkevm-protocol 专用于协议相关讨论，#l1-zkevm 专用于 zkVM 相关讨论。
• 另外，请务必查看 zkEVM 团队网站。

关键要点：EIP-8025 让执行证明可以在以太坊主网上运行，而不将其置于共识关键路径上。这是一个最小可行的步骤，有意义地将 L1-zkEVM 工作向协议推进了一步——并且是 Hegotá 的合理选择。

• 原文链接： x.com/ladislaus0x/status...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～