由 Kev 和 Julian 撰写。感谢 Toni 和 Francesco 的反馈。最后更新：2025 年 7 月 7 日。
延迟执行 是一项针对以太坊的拟议升级，旨在帮助提高 gas 上限。与需要在证明之前执行区块不同，通过延迟执行，证明者对区块执行简单检查，**并在执行交易之前对其进行投票。使用 zkVM 更改当前的 EVM 是另一项旨在提高 gas 上限的以太坊拟议升级。有了 zkVM，证明者只需要验证一个简洁的证明，证明该区块已被有效执行。这篇文章探讨了延迟执行和 zkVM 之间的交互。请注意，延迟执行的主要目标之一是促进以太坊 L1 上的 zkVM 证明。
我们建议将证明区块 n 正确执行的责任分配给该区块的构建者，但允许该构建者强制将证明包含在槽 n+1 的区块中。
该提案改进了证明的激励对齐，特别是对于所谓的“ prover killers”。Prover killers 是专门构建的，证明成本很高，但创建成本相对较低的区块。它们利用了以太坊协议对操作收取的 gas 单位与证明者产生的实际成本之间的不对称性。如果槽 n+1 的构建者负责证明区块 n，则槽 n 的构建者可能会创建一个 prover killer 来损害槽 n+1 的构建者。该提案通过将证明区块 n 的责任分配给槽 n 的构建者来消除这种激励不兼容性。
改进激励对齐的一个有用的特殊情况是存在构建者活跃性问题时。假设有一个非常强大的构建者创建了一个大型区块，然后离线了（或者一个表现得像这个构建者的构建者卡特尔）。在这种情况下，对于较小的备份构建者来说，为前一个区块创建证明可能不可行。这种知识可能允许（卡特尔化的）构建者“挟持以太坊”并榨取租金。如果槽 n 的构建者负责槽 n 的证明，则这种现象就会消失。如果构建者离线，则会跳过区块内容（如下所述），并且下一个槽的构建者可以构建一个可以自我证明的区块。因此，该提案有助于 将吞吐量与本地构建分离，因为它有利于区块生产的活跃性。
同槽证明提案
-
槽 n，t=0：槽 n 的构建者传播信标区块。执行负载被打包到一个 blob 中并进行 gossip。
-
槽 n，t=X (比如 t = 2): 证明者静态验证信标区块，如延迟执行 EIP 中所述。
-
槽 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 相同。这种机制确保了证明和负载数据都可用，从而保证了安全性和活跃性。正如 Toni 和 Francesco 在 这里 所说的那样，将区块视为无操作不会暴露免费的数据可用性，因为区块生产者放弃了执行奖励以获得“免费”的数据可用性。
请注意，槽 n 的证明者也会完全验证区块 n-1，并且槽 n+1 的证明者也会静态验证区块 n+1。完全验证包括验证证明的正确性和及时性，如上所述。
证明 Gas
这种提议的设计降低了防止 prover killers 的必要性，但是，由于几个原因，按证明成本定价操作码可能仍然是可取的。在本节中，我们将证明 gas 视为一个新的 gas 维度，用于衡量与每个交易相关的证明成本。我们将证明 gas 和执行 gas 分开，因为它们有不同的用途。执行 gas 上限确保感兴趣的各方可以跟上链的顶端，而证明 gas 确保协议知道证明特定交易的成本。
首先，对操作码的证明 gas 成本进行基准测试可以简化定价，从而改善用户体验。无需构建者-证明者评估交易成本并向用户收费，协议会向构建者和用户提供公平的价格。
其次，证明 gas 提高了抗审查性。如果协议知道诚实的证明者，甚至是较小的证明者，可以证明一定数量的证明 gas 的区块，则它可以强制所有证明者在其区块中至少包含那么多证明 gas。例如，FOCIL 可以在区块被认为是完整之前强制包含高达 3600 万个证明 gas（今天的 gas 上限）。如果没有证明 gas，则必须使用执行 gas 保守地估算该数字。
尽管协议应限制可以通过 FOCIL 强制包含的交易的证明 gas 量，但只要满足诸如执行 gas 上限之类的其他约束，证明者可以自由地包含消耗更多证明 gas 的交易。与构建者证明其前任的区块相比，这是此设计的一个优势。在这种情况下，区块中的证明 gas 量必须有一个硬性上限。
槽结构
以太坊槽分为几个部分，用于不同的协议任务，即：传播、执行和共识。有了 zkVM，还需要时间来证明一个区块。
根据此提案，构建者可以在将区块传播到网络的同时开始证明其区块。如果构建者必须证明其前任的区块，则协议需要预算时间让构建者这样做，这必须在之前的区块必须已交付之后。相反，此提案将证明时间与传播时间并行化，而在另一个提案中，证明时间必须在传播时间之后。
与顺序传播和证明时间相比，并行传播和证明时间可以允许更多的 blob 和更大的区块。我们可能仍然需要在槽中花费一些执行时间，以允许其他人跟上链的顶端并构建下一个区块。
额外考虑
同槽证明架构依赖于视图合并，这是一种由 Francesco 在这篇 文章 中描述的分叉选择工具。视图合并假设网络延迟低于某个常数 Δ。证明观察截止日期应最迟设置为 t = 12 - Δ。如果网络延迟小于 Δ，则构建者的视图是证明者冻结视图的超集，这意味着证明者不会强制构建者包含在证明观察截止日期之后传播的证明，从而防止拆分视图攻击。视图合并是支撑 MEV-Burn 和 FOCIL 等设计的相同分叉选择工具。
最后，请注意，同槽证明架构不依赖于是否有一个或多个 zkVM 被原生支持。如果需要多个 zkVM 证明，则完全验证区块的证明者应检查该区块中是否包含多个正确的证明（如果需要），具体取决于其本地视图。同槽证明架构也不需要在链上进行证明。正如 Vitalik 在 这里 和 Justin 在 这里 中探讨的那样，证明可以脱链存储。正如上面提议的那样，不必在链上存储证明，而必须在链上设置一个标志，用于存储必要的证明是否在观察截止日期之前可用（感谢 Dankrad）。
