由 Kev 和 Julian 撰写。感谢 Toni 和 Francesco 提供的反馈。
延迟执行是以太坊的一项拟议升级，旨在提高 gas 限制。与需要在证明前执行区块不同，延迟执行中，证明者对区块进行简单检查并在执行交易前投票。用 zkVM 替换当前的 EVM是另一项拟议的以太坊升级，以提高 gas 限制。使用 zkVM 时，证明者只需验证区块已被有效执行的简洁证明。本文探讨了延迟执行和 zkVM 之间的交互。请注意，延迟执行的主要目标之一是促进以太坊 L1 上的 zkVM 证明。
我们建议将证明区块 n 正确执行的责任分配给该区块的构建者，但允许该构建者在下一个插槽 n+1 的区块中强制包含证明。
这项提案改善了证明的激励机制对齐，特别是针对所谓的"证明者杀手"。证明者杀手是专门构建的区块，其证明成本高昂，但创建成本相对较低。它们利用以太坊协议在 gas 单位上收取的操作费用与证明者实际产生的成本之间的不对称性。如果插槽 n+1 的构建者负责证明插槽 n 的区块，那么插槽 n 的构建者可能会创建这样一个证明者杀手来损害插槽 n+1 的构建者。这项提案通过将插槽 n 区块的证明责任分配给插槽 n 的构建者，消除了这种激励不兼容性。
在构建者活跃性出现问题时，改善的激励机制对齐尤其有帮助。假设有一个极其强大的构建者创建了一个大型区块后离线（或者一个表现得像这个构建者的构建者卡特尔）。在这种情况下，较小的备用构建者可能无法为前一个区块创建证明。这种情况可能使（构建者）卡特尔能够"勒索以太坊"并提取租金。如果插槽 n 的构建者负责插槽 n 的证明，这种现象就会消失。如果构建者离线，区块内容将被跳过（如下所述），下一个插槽的构建者可以构建一个可以自我证明的区块。因此，这项提案有助于将吞吐量与本地构建解耦，因为它有利于区块生产的活跃性。
同插槽证明提案
插槽
n，t=0：插槽n的构建者传播信标区块。执行载荷被打包成 blob 并传播。插槽
n，t=X（假设 t = 2）：证明者静态验证信标区块，如延迟执行 EIP 中概述的。插槽
n，t=Y（假设 t = 9）（证明观察截止时间）：证明者冻结他们对是否有可用证明的看法，该证明以预状态根和 kzg 承诺为输入，输出后状态根。插槽
n+1，t=0：插槽n+1的构建者在可用时包含前一个区块正确执行的证明。插槽
n+1，t=X：证明者完全验证区块n。每个证明者根据其本地视图执行以下检查。- 在证明观察截止时间，区块
n的证明是否可用？ - 如果是，证明是否正确？
- 如果是，与 kzg 承诺对应的 blob 是否可用。
如果证明者对所有问题都回答"是"，它将为包含区块
n证明的插槽n+1投票。如果证明者对第一个问题回答"否"，它将在以下两个条件之一成立时为区块投票：- 区块中未包含证明。
- 包含了正确的证明，且 kzg 承诺对应一个可用的 blob。
- 在证明观察截止时间，区块
如果区块 n+1 中未包含区块 n 的证明，或者与证明对应的 blob 数据不可用，区块 n+1 应将区块 n 的执行视为无操作，即区块 n+1 的预状态与区块 n 的预状态相同。这种机制确保了证明和载荷数据都可用，保证了安全性和活跃性。正如 Toni 和 Francesco 所argue 的那样，将区块视为无操作并不会暴露免费的数据可用性，因为区块生产者放弃执行奖励以获得"免费"的数据可用性。
请注意，插槽 n 的证明者还会完全验证区块 n-1，插槽 n+1 的证明者还会静态验证区块 n+1。完全验证包括验证证明的正确性和及时性，如上所述。
额外考虑
同插槽证明架构依赖于视图合并（view-merge），这是 Francesco 在这篇文章中描述的一个分叉选择小工具。视图合并假设网络延迟低于某个常数 Δ。证明观察截止时间应最晚设置在 t = 12 - Δ。如果网络延迟小于 Δ，构建者的视图是证明者冻结视图的超集，这意味着证明者不会强制构建者包含在证明观察截止时间后传播的证明，从而防止分裂视图攻击。视图合并是支持 MEV-Burn 和 FOCIL 等设计的相同分叉选择小工具。
最后，请注意，同插槽证明架构不依赖于是否有一个或多个 zkVM 被内置。如果需要多个 zkVM 证明，完全验证区块的证明者应根据其本地视图检查区块中是否包含了必要的多个正确证明。
