Prover Killers Killer：你构建，你证明 - 执行层研究

作者：Kev 和 Julian。感谢 Toni 和 Francesco 提供的反馈。更新于 2025 年 6 月 27 日。

延迟执行 是以太坊的一项拟议升级，旨在帮助提高 gas 上限。相比于在证明之前需要执行区块，通过延迟执行，证明者对区块执行简单的检查**并在执行交易之前对其进行投票。使用 zkVM 改变当前的 EVM 是另一项拟议的以太坊升级，旨在提高 gas 上限。使用 zkVM，证明者只需要验证一个简洁的证明，证明区块被有效地执行。这篇文章探讨了延迟执行和 zkVM 之间的相互作用。请注意，延迟执行的主要目标之一是促进以太坊 L1 上的 zkVM 证明。

我们建议将证明区块 n 正确执行的责任分配给该区块的构建者，但允许该构建者强制将证明包含在插槽 n+1 的区块中。

这个提案改进了证明的激励对齐，特别是对于所谓的“证明者杀手”。证明者杀手是指专门构建的区块，证明成本很高，但创建成本相对较低。它们利用了以太坊协议对 operations 收取的 gas 单位与证明者产生的实际成本之间的不对称性。如果插槽 n+1 的构建者负责证明区块 n，那么插槽 n 的构建者可能会创建一个这样的证明者杀手来恶意攻击插槽 n+1 的构建者。这个提案通过将证明区块 n 的责任分配给插槽 n 的构建者来消除这种激励不兼容性。

改进激励对齐的一个有用的特殊情况是，如果存在构建者活跃度问题。假设有一个非常强大的构建者创建了一个大型区块，然后离线了（或者一个像这个构建者一样行事的构建者联盟）。在这种情况下，较小的备份构建者可能无法为前一个区块创建证明。这种知识可能允许这 (一联盟) 构建者“挟持以太坊”，并榨取租金。如果插槽 n 的构建者负责插槽 n 的证明，这种现象就会消失。如果一个构建者离线，区块内容将被跳过（如下所述），下一个插槽的构建者可以构建一个可以自我证明的区块。因此，这个提案有助于将吞吐量与本地构建分离，因为它有利于区块生产的活跃度。

同插槽证明提案

• 插槽 n，t=0：插槽 n 的构建者传播信标区块。执行 payload 被打包成 blob 并进行传播。

• 插槽 n，t=X（比如 t = 2）：证明者按照延迟执行 EIP 中的 outline，静态地验证信标区块。

• 插槽 n，t=Y（比如 t = 9）（证明观察截止时间）：证明者冻结他们对是否存在可用证明的看法，该证明的输入是 pre-state root 和一个指向 blob 的 kzg 承诺，输出是 post-state root。

• 插槽 n+1，t=0：插槽 n+1 的构建者包含前一个区块的正确执行证明（如果可用）。

• 插槽 n+1，t=X：证明者完全验证区块 n。每个证明者都通过针对其本地视图运行以下检查来实现这一点。

  • 区块 n 的证明是否在证明观察截止时间可用？
  • 如果是，证明是否正确？
  • 如果是，与 blob 的 kzg 承诺相对应的 blob 是否可用。

如果证明者对所有问题都回答“是”，则它会在区块 n+1 包含区块 n 的证明的情况下，投票支持区块 n+1。如果证明者对第一个问题回答“否”，则它会在以下两种情况之一成立时，投票支持该区块：

• 区块中没有包含证明。
• 包含了一个正确的证明，并且该证明带有一个与可用 blob 相对应的 kzg 承诺。

如果区块 n+1 中没有包含区块 n 的证明，或者与证明相对应的 blob 数据不可用，则区块 n+1 应该将区块 n 的执行视为一个无操作，这意味着区块 n+1 的 pre-state 与区块 n 的 pre-state 相同。这个机制确保了证明和 payload 数据都可用，从而保证了安全性和活跃度。正如 Toni 和 Francesco 在这里 所论证的，将区块视为无操作不会暴露免费的数据可用性，因为区块生产者放弃了执行奖励来获得“免费的”数据可用性。

请注意，插槽 n 的证明者也完全验证区块 n-1，插槽 n+1 的证明者也静态验证区块 n+1。完全验证包括验证证明的正确性和及时性，如上所述。

证明 Gas

这个 proposed 的设计使得防止证明者杀手变得不那么必要，但是，出于几个原因，仍然可能需要根据证明成本来定价操作码。在本节中，我们将 proving gas 视为一个新的 gas 维度，它衡量与每个交易相关的证明成本。我们将 proving gas 和 execution gas 分开，是因为它们有不同的用途。execution gas 上限确保了相关方能够跟上链的 tip，而 proving gas 确保了协议知道证明特定交易有多昂贵。

首先，对操作码的 proving gas 成本进行基准测试可以使定价更容易，从而改善用户体验。协议可以直接向构建者和用户报价一个合理的价格，而不是让构建者-证明者评估交易的成本并向用户收费。

其次，proving gas 提高了审查阻力。如果协议知道诚实的证明者（即使是较小的证明者）可以证明具有一定数量 proving gas 的区块，它可以强制所有证明者在其区块中至少包含达到该数量的 proving gas。例如，FOCIL 可以在区块被认为是满的之前，强制包含最多 3600 万 proving gas（今天的 gas 上限）。如果没有 proving gas，这个数字将不得不使用 execution gas 进行保守的估算。

虽然协议应该限制可以通过 FOCIL 强制包含的 proving gas 交易的数量，但证明者可以自由地包含消耗更多 proving gas 的交易，只要满足其他约束条件（如 execution gas 上限）即可。这是这个设计相对于构建者证明其前任区块的一个优势。在后一种情况下，区块中的 proving gas 数量必须有一个硬性上限。

插槽结构

以太坊插槽分为几个部分，用于不同的协议任务，即：传播、执行和共识。使用 zkVM，还需要时间来证明一个区块。

有了这个提案，构建者可以在将区块传播到网络的同时开始证明他们的区块。如果构建者必须证明其前任区块，协议需要预算时间让构建者这样做，这必须在先前的区块必须被交付之后。相反，这个提案将证明时间与传播时间并行化，而在另一个提案中，证明时间必须在传播时间之后。

与顺序传播和证明时间相比，并行传播和证明时间可能允许更多的 blob 和更大的区块。我们可能仍然需要在插槽中留出一些执行时间，以便让其他人能够跟上链的 tip 并构建下一个区块。

额外考虑

同插槽证明架构依赖于 view-merge，这是一种由 Francesco 在这篇帖子 中描述的分叉选择工具。View-merge 假设网络延迟低于某个常数 Δ。证明观察截止时间应最迟设置为 t = 12 - Δ。如果网络延迟小于 Δ，则构建者的视图是证明者冻结视图的超集，这意味着证明者不会强迫构建者包含在证明观察截止时间之后传播的证明，从而防止 split-view 攻击。View-merge 是支撑诸如 MEV-Burn 和 FOCIL 等设计的 same 分叉选择工具。

最后，请注意，同插槽证明架构不依赖于是否 enshrined 一个或多个 zkVM。如果需要多个 zkVM 证明的证明，则完全验证区块的证明者应根据其本地视图检查区块中是否包含了多个正确的证明（如有必要）。

• 原文链接： ethresear.ch/t/prover-ki...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～