延迟执行 vs. ePBS：以太坊下一步升级该选谁？
近期关于 EIP-7732（Enshrined Payload-Block Separation，嵌入式有效负载与区块分离，简称 ePBS）作为 Glamsterdam 升级“主打功能”的讨论，引发了人们对以太坊未来 slot 结构的重要思考。
作者 ｜ Nero_eth
非常感谢 Francesco、Mark、Max、Julian、Caspar、Terence、Vitalik、Ansgar、Dankrad、Anders 和 Barnabé 对本主题的反馈与讨论！
🔗 原文链接：https://ethresear.ch/t/slot-restructuring-design-considerations-and-trade-offs/22687
摘要
选择 EIP-7886 作为 Glamsterdam 的实现提案：它在执行层（EL）侧的版本，能够在不引入 ePBS 额外复杂机制的前提下，提供约 80% 的 slot 流水线处理吞吐能力。
保持简洁：不引入信标块 / 有效负载（payload）拆分、不使用 PTC 委员会、不改变 fork choice（分叉选择）逻辑。
高收益、低风险：能够大幅释放 L1 扩容潜力，同时不影响现有 MEV-Boost 流程。
具备未来兼容性：如果未来我们确实需要剩下的 20% 吞吐能力（或引入无需信任的支付机制），仍可在此基础上平滑叠加完整的 ePBS。
ePBS 的设计权衡
近期关于 EIP-7732（Enshrined Payload-Block Separation，嵌入式有效负载与区块分离，简称 ePBS）作为 Glamsterdam 升级“主打功能”的讨论，引发了人们对以太坊未来 slot 结构的重要思考。
虽然该提案在 slot 流水线方面确实有一些优势，但我认为还有更优的替代方案：一个简化版本的 ePBS，能在降低复杂度的同时，获得相似的好处。同时，我也想为“优先实现延迟执行（delayed execution）”的路线提出论证——它结构更简单，但依然能够实现我们想要的目标。
首先，让我们看看 ePBS 能带来什么：
流水线处理能力（Pipelining）
ePBS 允许信标块体积很小，能够快速传播，使得 attesters 能在 slot 开始时尽早进行 attest（证明）。与此同时，执行层的 payload 和 blobs 则可以有更多时间独立传播和执行。为了最大化 pipelining，ePBS 引入了一个新的委员会 —— PTC（Payload Timeliness Committee）来判断 payload + blobs 的可用性。
有效负载与区块的解耦（Payload-Block Separation）
将执行层 payload 从共识层信标块中解耦后，即使执行层生成的是无效 payload，共识层也能继续推进区块生产。信标块将不再被看作一个整体，而是可以区分为“带 payload”与“不带 payload”的两种节点。这种拆分会对 fork choice 逻辑产生影响，但大多数人认为其工程实现是可控的。
此外，这种方式还将 aggregation（聚合）操作移出了关键路径，因为 attest 截止时间可以保持不变（甚至略微提前），这就为聚合留出了更多时间。
无需信任的 MEV-Boost 支付
ePBS 允许 proposer 无条件收款，因此他们可以无需信任地使用 MEV-Boost 并获得支付。这与目前 relay 托管支付的方式不同。
需要注意的是：以上三个特性可以单独推进。ePBS 当前的设计只是一个整合它们的整体框架。
而延迟执行（EIP-7886）的设计在不引入信标块与 payload 拆分，也不涉及无需信任支付机制的前提下，依然实现了几乎相当的流水线能力。
无需信任的支付不是免费的
虽然“无条件支付”带来了诸多好处，但要实现 proposer 与 builder 之间的无需信任支付机制，也会引入额外复杂性。
proposer 端的变化：
proposer 必须对 builder 进行白名单管理，并主动从他们那里拉取出价。与此同时，本地构建（local building）依然作为 fallback 方案存在。
builder 端的挑战：
如果 proposer 想启用无需信任的支付，builder 就需要自行监控以下内容：
信标区块是否存在“等价块冲突”（equivocation）；
是否有足够的 attestation 针对带有其 payload 承诺的信标块。
一旦 builder 看到足够数量的 attestation 确认信标块已经固定（且其 payload 被包含在其中），就可以安全地释放 payload，避免被“拆包”（unbundling）攻击。
目前，relay 系统在全球范围内通过可信 p2p 网络快速传播区块，然后从多个位置同时释放 payload，这已被证明足以抵御拆包。因此，新机制或许并非必须。
最佳情况下，无需信任的支付机制将 builder 的处境与当下 MEV-Boost 使用时相似：
builder 需要等到看到“足够的 attestations”后再释放 payload，避免被拆包。“足够”由 builder 自行定义；
等待 attestations 意味着 builder 剩余的传播与执行时间更短；
在 ePBS 下使用该机制时，信标块在 slot 初期快速传播并被 attested。一旦 attestations 达标，builder 才能释放 payload，进入 payload 的实际传播阶段；
而若继续使用当前 MEV-Boost 模式（即不使用 ePBS 的“无条件支付”逻辑），builder 可以在 slot 一开始就传播 payload，从而争取更多传播时间。
proposer 自然希望 builder 提供最优执行（最大利润）。虽然“协议层强制支付”的设定听起来很理想，但它确实存在权衡：
引入了 staking builder 的制度；
需要通过信标链将 builder 的 stake 转账至 proposer 的 fee recipient；
涉及到复杂的支付逻辑：40% vs 60% attestations 的支付门槛，epoch 边界上的状态切换等。
如果大多数参与者最终都不使用该机制（=将支付值设置为 0）而继续使用 MEV-Boost，那么围绕 staking builder、信标链支付、60% attestation 解锁等复杂设计就显得得不偿失。在实际操作中，本地构建仍是真正的 fallback，而 MEV-Boost 依旧是默认的 builder 选择路径。为无需信任支付机制设计复杂的 fallback 逻辑或许没有必要。
Builder 会浪费宝贵时间吗？
虽然“无条件支付”听起来很诱人，但它所带来的权衡可能并不划算。
在 ePBS 机制下，builder 不能像现在一样立即广播 beacon block 与 EL payload，而是需要在一个“观测窗口”中等待足够多的 attestations 后才能发布 payload。是否发布完全取决于 builder 自身对“安全”的判断。
当前，relay 通过延迟释放 payload 的方式保护 builder 不被 proposer 拆包。尝试移除 relay 并保留拆包保护机制，理论上确实能带来好处。但这意味着：
builder 需要自己订阅 subnet；
监控哪些 attestations 确认了绑定自己 payload 的 beacon block；
然后再在“足够确认”之后释放 payload，以避免被拆包。
结合 block 与 payload 的拆分机制，builder 确实获得了一种更好的自我保护方式。但问题在于，这实际上是“为一个从未提出的问题提供答案”。
builder 似乎对当前的拆包保护方式已经很满意，而在以毫秒为战场的环境中，为了略微提高的拆包安全性而牺牲传播时间，可能并不值得。
PTC 的权衡：ePBS、预确认与构建者的信息垄断
预确认依赖于后状态（post-state）的知识：如果不知道状态，构建者就无法保证未来交易的成功打包（即无法实现预确认）。而上一个区块的构建者自然最早拥有这个后状态。如今，这种优势尚小——因为竞价和交易负载（payload）的公布几乎是同步发生的。
但 ePBS（去中心化的提议-构建者分离）改变了这一动态。现在，在竞价中标（即一个构建者掌握后状态的时刻）和负载公布（即所有构建者掌握该状态的时刻）之间，可能会有数秒延迟。
构建者可以故意延迟 payload 公布，从而保持对后状态的信息垄断，并利用这段时间榨取更多预确认收入。我们可以合理假设：预确认带来的收益会在 slot 时间段内大致线性增长。
这就引出了一个根本性的权衡：
对于流水线（pipelining）处理，协议希望 PTC（Payload Timing Committee）尽可能晚地出现，因为它只有 512 个成员、且不需要聚合（aggregation），所以是可行的。
为了减少构建者的后状态垄断，协议又希望 PTC 尽可能早地出现在 slot 中，以限制构建者滥用延迟 payload 的能力。
这两个目标是直接冲突的。
找到合适的 PTC 时间点并不容易，如果我们将 PTC 提前设置（出现在 slot 时间轴更早的位置），就会牺牲部分流水线带来的性能提升。
还有一个构建者可能延迟 payload 公布的原因：这样可以给他们一个取消交易负载执行的“选择权”。尽管构建者仍需要支付无条件的手续费，但如果市场价格对其不利，他们可以选择“退出”。
当然，这一切的前提是：提议者真的使用了 ePBS 所提供的无需信任的支付机制。但对于提议者来说，最符合经济理性的选择仍然是继续使用当前的 MEV-Boost。
中继（Relays）可能仍将存在，继续提供“构建者解耦”的安全性——就像现在一样——同时，payload 也可以在“足够见证者（attestations）已提交”的截止时间之前被传播。
这将带来如下图所示的状态演进：
取消 PTC：解耦版 ePBS
我们可以通过一种略有不同的方式，在保留 ePBS 优点的同时，解决其存在的问题：
在 slot 开始时，提议者将信标区块（beacon block）和执行层负载（EL payload）作为两个独立对象发布（即继续保留区块与负载的分离），信标区块对该负载进行承诺（commit）。
MEV-Boost 的流程不变，中继继续阻止构建者解绑（unbundling）。
将见证（attestation）截止时间移动到 slot 的第 8 秒。
在 第 3 秒 引入一个新的“信标观测截止点”（beacon-observation deadline）：
见证者在此时检查是否已看到有效的信标区块。
到第 8 秒时，见证者只有在以下两个条件都满足时才对信标区块投票：
第 3 秒时已观察到该信标区块；
执行层负载已在当时可用（不要求一定有效）。
这种机制能为下一个提议者提供足够数据，从而做出安全的 fork-choice 决策：
在这个 ePBS 的变体中，PTC 不再存在，见证者成为了“可用性预言机（availability oracle）”。
这种设计虽然没有把聚合（aggregation）完全移出关键路径，但我们仍能获得完整的 7~9 秒传播时间。这大致等价于在信任最小化的构建者支付机制下的 ePBS 能实现的传播效果。
那 EIP-7886（延迟执行）怎么办？
EIP-7886 相较于 EIP-7732 更加简洁，但在 slot 的流水线能力方面效果接近。它通过在负载无效时回滚状态，避免了复杂的 fork-choice 更改。
在 EIP-7886 下，无法像 ePBS 那样提前见证截止时间，因为我们仍然需要聚合过程。但作为回报，我们降低了协议复杂性，并且仍可在未来升级为完整的流水线式设计（PTC）：
虽然启用 PTC 可能会额外争取到一秒的传播时间，但我认为这不值得我们为此承担的复杂性成本。即使 PTC 能给传播留出更多时间，但就“传播 + 执行”这两者的总时间来说，几种设计方案本质上是相同的。
最小化复杂性，最大化未来兼容性：一条务实的前进道路
我对核心开发者的务实建议是：将 ePBS 的优点逐项拆解看待，同时重新思考我们为何走到今天这一步：
为了扩展以太坊 L1（为执行提供更多时间，并为证明留出完整 slot），我们确实需要某种形式的 slot 流水线（slot pipelining）。
在当前的设计中，EIP-7886（延迟执行）是最短、最简单的通往目标的路径。
虽然 ePBS 中的“信标区块与负载分离”设计听起来不错，但它会引入额外复杂性（例如三选一的 fork-choice、投票中增加负载可用性位等）。
类似地，无条件支付机制也带来了不必要的复杂性，而且很可能难以被广泛采用（例如构建者需要抵押、通过提取路径支付费用、保障构建者安全会浪费时间等）。
所以我们回归本源——目标是 扩展 L1，而我们已基本达成共识：流水线是正确路径。
接下来的问题是：我们是否需要 ePBS 提供的“最大化流水线能力”，还是 EIP-7886 提供的“80% 流水线”已经足够满足中期需求？
延迟执行比 ePBS 简洁（其中共识层变体其实是 ePBS 的子集——只是移除了 PTC、无条件支付和区块分离；而执行层版本比共识层的还更简单）。
ePBS 是“全套解决方案”，无论复杂性如何都追求极致性能。
我的建议是：第一步，在 Glamsterdam 升级中引入最简形式的延迟执行机制，这样我们可以达到如下效果：
此外，为了防止构建者利用额外时间做时序博弈，我们可以引入一个“信标观测截止点（beacon observation deadline）”，这是一个相对简单的改动。
如果未来我们确实需要进一步的流水线性能提升，还可以引入 PTC，从 slot 中再“挤出”1–2 秒传播时间（注意：不是用于执行）。
如果有意愿，我们也可以在此基础上分离信标区块与执行负载，并实现无条件支付机制——但需要指出的是，这两者并不直接提升扩容能力。
甚至我们也可以在不分离区块与负载的情况下引入 PTC：此时，见证者可以在 slot 早期乐观地对信标区块的有效性和负载头的可用性进行见证，而由 PTC 在稍晚时刻进一步标记 payload 可用性。
总之，实现完整的 ePBS 其实可以循序渐进地分步推进，降低实施风险。我们可以先通过不涉及区块分离或无条件支付的低侵入式改动，获得 80% 的扩容收益。
将 ePBS 作为一个“打包式的三合一重大更新”同时上线，而其中可能只有一个功能是实际急需的，这种方式既不必要，也过于复杂。
因此，与其一开始就 All-in 一个高复杂度的设计，不如优先部署一个最简单、但确实能提升 L1 可扩展性的 slot 重构方案——那就是 延迟执行（Delayed Execution）。
附录
EIP-7886 与 EIP-7732 在 6 秒 slot 下的对比
无论是 EIP-7886（延迟执行）还是 EIP-7732（ePBS），这两种提案都兼容更短的 slot 时间。
对于延迟执行，slot 的结构大致如下：
从 payload 公布开始，整个 slot 都可以用于执行；
传播（propagation）时间在见证（attestation）截止点时结束；
没有 block-payload 分离 → 无需修改 fork-choice 规则；
聚合过程仍然位于关键路径中；
不会产生“后状态信息垄断”。
对于 ePBS，slot 的结构如下：
同样是从 payload 公布开始，整个 slot 可用于执行；
传播时间在 PTC 截止点时结束；
拥有更强的流水线能力，但需要额外引入一个委员会（PTC）；
聚合过程已被移出关键路径；
最多有 75% 的 slot 时间可能被构建者利用为“后状态垄断期”。
构建者会在看到信标区块（其中包含对其 payload 的承诺）后，延迟公布 payload 直至接近 PTC 截止时间。在信标区块传播完成到 payload 实际发布之间的这段时间（假设信标区块在 0.5 秒发布，这段窗口最长可达 4.5 秒），构建者独占后状态信息，可以用来获取额外利益。
而在延迟执行机制下没有这类延迟窗口，因为信标区块与 payload 并未分离。一切行为和今天类似：中标构建者最先获得后状态，其他构建者通常在见证截止前就能看到区块并追上状态。
这种“后状态信息垄断”的情况可以表示为：
部分构建者可能会在 PTC 截止点前再发布 payload，同时选择尽量精简的执行层负载（EL payload），只保留那些最有价值的交易，以加快传播速度。
这类构建者利用 PTC 的“可用性检查”延迟，可以在整个 slot 时间内建立起 75% 到 83% 的状态信息垄断，从而在 MEV 和预确认等方面获利。
欢迎关注 ETHPanda 获取更多资讯！
