以太坊插槽重构：设计考虑与权衡

非常感谢 Francesco, Mark, Max, Julian, Caspar, Terence, Vitalik, Ansgar, Dankrad, Anders 和 Barnabé 在这个话题上提供的反馈和讨论！

要点总结

• 为 Glamsterdam 选择 EIP‑7886： 它的 EL 端版本在没有 ePBS 额外移动部件的情况下，提供了约 80% 的 ePBS 的 slot 管道吞吐量。
• 保持简单： 没有信标/payload 分割，没有 PTC 委员会，并且零分叉选择更改。
• 大胜，低风险： 我们仍然解锁了主要的 L1 扩展空间，并保持了今天的 MEV-Boost 流程不变。
• 面向未来： 如果我们将来需要最后 20% 的管道（或无需信任的支付），我们可以干净地在上面分层完整的 ePBS。

ePBS：设计权衡

最近关于 EIP-7732（Enshrined Payload-Block Separation，或 ePBS）作为 Glamsterdam 分叉潜在的头条功能的讨论，提出了关于以太坊未来 slot 结构的重要问题。

虽然该提案提供了一些不错的好处，尤其是在 slot 管道方面，但我相信有一个更好的替代方案：一个精简版的 ePBS，以更低的复杂性获得类似的好处。我还想提出一个建议的时间表，包括首先进行延迟执行——它的复杂性较低，并且仍然可以为我们提供所需的功能。

让我们首先承认 ePBS 将为我们提供什么：

1. 管道化

• 通过 ePBS，小的信标块可以迅速传播，允许证明者在 slot 的早期开始证明。同时，EL payload 和 blobs 获得更多的时间来独立传播（和执行）。为了最大化 slot 管道化，ePBS 使用一个新的委员会，PTC，来确定 payload + blobs 的可用性。

2. Payload-区块分离

• 通过将 EL payload 从共识层信标块中分离出来，即使 EL 只产生无效的 payloads，CL 也可以继续推进区块。与其将信标块视为单个节点，现在有两个节点，一个有 payload 的信标块与一个没有 payload 的信标块。这种分离引入了对分叉选择的更改，但大多数人认为从工程角度来看，这些更改是可管理的。
• 它还将聚合从关键路径中移除。由于证明截止日期可以保持不变（甚至稍微提前），因此有更多的时间用于证明聚合。

3. 无需信任的 MEV-Boost 支付

• ePBS 实现了无条件支付，这意味着提议者可以使用 MEV-Boost 并以无需信任的方式收到付款，这与今天 relay 持有支付的托管权不同。

所有 3 个功能都可以单独发布。 今天的 ePBS 只是支持所有这些功能的设计。

延迟执行（EIP-7886）设计 实现了几乎相当形式的管道化，而不需要将信标块与 EL payload 或无条件支付机制分离。

无需信任的支付是有代价的

无条件支付的好处不是免费的。实现提议者和 builder 之间的无需信任的支付会引入额外的复杂性。

• 提议者 必须将 builder 列入白名单并从他们那里提取 bid。后备方案——本地构建——仍然存在。
• Builders，如果提议者想要使用无需信任的支付选项，builder 可以监视信标块的 equivocation 以及对信标块的足够证明，并承诺其 EL payload。一旦他们看到足够的证明确认了提交给其 payload 的信标块，他们就可以安全地发布 payload 而不会有被解绑的风险。如今，relays 有助于传播，并且通常首先使用受信任的 p2p 连接在全球范围内分发区块，然后同时从多个位置发布 payload。这已被证明足以防止解绑，因此可能不需要这种新机制。

在最好的情况下，无需信任的支付方法使 builder 处于与今天使用 MEV-Boost 相同的位置：

• 为了使用无需信任的支付选项，builder 可以等到他们看到信标块的充分证明，然后再发布 payload，以避免被解绑。“充分”由 builder 自己定义。
• 等待证明意味着 builder 用于传播 + 执行的时间更少。

在 ePBS 下——使用无条件支付机制——信标块在 slot 的最初几秒钟内被传播并证明。一旦 builder 看到充分的证明，它就可以释放 payload，从而开始实际的 payload 传播时间。

当不使用这种“无条件支付”逻辑（=而是使用 mevboost）时，提议者/builder 通过提前传播 EL payload，在 slot 开始时获得了宝贵的传播时间。

提议者会希望他们的 builder 提供尽可能最佳的执行（利润最大化）。有人可能会说，保证无条件，协议强制执行的付款是一个不错的功能，但是，这是一种权衡。它带来了复杂性，例如 staked builders、通过 withdrawals 从 builder 的 stake 到提议者费用接收者的 CL 支付、围绕 40% 证明与 60% 和/或 epoch 转换的有条件的无条件支付逻辑等。

在每个人都忽略无条件支付机制（=将其设置为 0）而改为通过 MEV-Boost 的情况下，它所带来的复杂性（staked builders、CL 上的支付、在 epoch 边界以 60% 证明无条件释放付款等）可能不值得。实际上，本地构建仍然是真正的后备方案，MEV-Boost 是默认的 builder 选择流程。因此，为无需信任的支付设计后备逻辑可能是没有必要的。

Builder 会浪费宝贵的时间吗？

虽然无条件支付很有吸引力，但权衡可能并不值得。**

ePBS 建议建立一个观察窗口，而不是同时广播信标块和 EL payload，在此期间，builder 必须等待足够的证明才能显示其 payload。最后，由 builder 决定何时发布 payload 才足够安全。

如今，relays 通过仅在提议者篡改 payload 为时已晚之后才释放 EL payload，来保护 builder 免受解绑的影响。尝试移除 relay，同时保留该保护措施可以带来实际的好处。Builder（而不是 relays）将需要订阅子网并计算对信标块的证明，并承诺其 EL payload。当他们看到足够数量的证明时，他们就可以释放 payload，从而避免被解绑。

因此，与块-payload 分离相结合，此机制为 builder 提供了一种更好的保护自己免受解绑的方法。 但是，这是一个从未被问过的问题的答案。 对于今天的解绑保护，builder 似乎很好，并且为了换取一些额外的解绑安全性，在一个每毫秒都很重要的环境中，可能根本不值得浪费时间。

PTC 的权衡：ePBS、预确认和 Builder 信息垄断

预确认取决于后状态知识：在不知道状态的情况下，builder 无法保证包含未来的交易（=预确认）。 前一个区块 (block) 的 builder 自然首先拥有此后状态。 如今，这种优势很小——bidding 和 payload 发布几乎同时发生。

但是 ePBS 改变了这种动态。 在bid 选择（当一个 builder 知道后状态时）和payload 显示（当所有 builder 知道它时）之间，现在可能过去了数秒。 Builder 可以延迟 payload 的显示，以保持对后状态知识的垄断并提取更多的预确认收入。 可以公平地假设，来自预确认的收入在整个 slot 中大致呈线性增长。

这是基本的权衡：

• 对于管道化，协议希望 PTC 在 slot 中尽可能晚。 由于它只有 512 个成员并且不需要聚合，因此这是可行的。
• 为了最大程度地减少后状态垄断，协议希望 PTC 尽可能的早，以限制 builder 利用延迟 payload 显示的能力。

这些目标直接冲突。

弄清楚放置 PTC 的最佳位置并非易事，如果最终我们将 PTC 在 slot 内的时间提前，我们将同时失去一些管道化优势。

Builder 可能希望延迟 payload 显示的另一个原因是，这使他们可以选择取消其 payload 以进行执行。 Builder 仍然需要支付无条件付款，但是，例如，如果价格对 builder 不利，他们仍然可以选择“退后”。

当然，这假设提议者实际上会使用 ePBS 附带的无需信任的支付机制。对于提议者来说，经济上的理性选择是使用 MEV-Boost，就像今天的工作方式一样。Relays 可能会仍然存在，就像今天一样，提供 builder 解绑安全性，同时 payload 的传播时间可以早于“看到足够的证明”截止日期。

然后，画面将如下所示：

摆脱 PTC：解绑 ePBS

我们可以通过略有不同的方法来解决 ePBS 的缺点，同时保留其优点：

1. 在 slot 开始时，提议者将信标块和 EL payload 作为单独的对象发布（=我们将保留块-payload 分离）。 信标块提交给 payload。
2. MEV-Boost 管道保持不变，relay 仍然可以防止解绑。
3. 证明截止日期移动到 slot 中的第 8 秒。

4. 在第 3 秒引入信标观察截止日期：

   • 证明者检查是否已看到有效的信标块。

5. 在第 8 秒，证明者仅在以下情况下才对信标块进行投票：

   • 在第 3 秒时看到了 和
   • EL payload 在那时可用（不一定是有效的）。

此设置使下一个提议者有足够的数据来做出安全的分叉选择决策：

在这种 ePBS 变体中，证明者成为可用性预言机，而不是 PTC。

此设计不会使聚合脱离关键路径，但是，我们获得了大约 7-9 秒的完整传播时间。 这大致相当于 ePBS 与无需信任的 builder 支付所能实现的。

那么 EIP-7886：延迟执行呢？

EIP-7886 比 EIP-7732 复杂度低，并且几乎实现了相同的 slot 管道化。 通过在 payload 无效的情况下恢复状态，EIP-7886 没有棘手的分叉选择更改。

在 EIP-7886 下，我们无法像在 ePBS 下放置 PTC 那样早地移动证明截止日期，因为我们仍然需要聚合。 作为回报，我们降低了复杂性，同时仍然能够在以后进行全管道化（PTC）：

即使我们可能会因为拥有 PTC 而获得额外的一秒钟，但我认为这不值得付出代价。 即使 PTC 为我们提供了更多的传播时间，但使用这些设计，可用于传播+执行的时间仍然相同。

最小化复杂性，最大化未来兼容性：务实的未来之路

我对核心开发人员的务实建议是，独立地看待 ePBS 的出色功能，并重新审视我们为什么在这里：

为了扩展 L1（执行的更多时间和证明的完整 slot），以太坊需要某种形式的 slot 管道化。

延迟执行 EIP-7886 是到达那里的最短且最不复杂的路径。

ePBS 的信标块-payload 分离听起来不错，但引入了额外的复杂性（3 选 1 的分叉选择、用于投票的 payload 可用性位等）。 无条件支付机制也是如此，它引入了不必要的复杂性，并且不太可能被广泛采用（stakes builders、通过 withdrawals 付款、builder 安全性会浪费时间等）。

因此，我们仍然面临着扩展 L1 的目标，并且同意管道化是这里的正确方法。

那么问题是，我们是否需要来自 ePBS 的最大管道化，或者在中期延迟执行的 80% 管道化是否足够。 延迟执行比 ePBS 复杂度低（CL 变体本质上是 ePBS 的子集——只是没有 PTC、无条件付款和块分离，并且 EL 变体比 CL 变体更简单）。 ePBS 全力以赴，旨在最大化管道化，而不管增加的复杂性如何。

作为第一步，在 glamsterdam 中，以太坊应该以最简单的形式发布延迟执行。

这将使我们得到以下图片：

引入信标观察截止日期以防止 builder 使用额外的时间进行计时游戏将是一个相对简单的更改。

如果需要进一步的管道化，我们仍然可以引入 PTC，从 slot 中再挤出 1-2 秒的传播时间（不用于执行），并将证明截止日期提前到 slot 中。

如果有人感兴趣，我们还可以将信标块与 payload 分离开来，并同时实施无条件支付机制——尽管这些更改都不一定会促进扩展。

即使有可能（并且有意义）在不分离块和 payload 的情况下引入 PTC。 在这种情况下，证明者将在 slot 的早期乐观地证明信标块的有效性和 payload 标头的可用性，而 PTC 稍后将发出 payload 可用性的信号。

可以采取较小的，顺序的步骤来实现完整的 ePBS，从而降低其风险。 我们通过侵入性较小的更改获得了 80% 的扩展优势，这些更改不需要块-payload 分离或无条件付款。 当实际上只需要其中一项功能时，以非绑定的方式推出 ePBS（本质上是三合一功能）这样的重大更改将是不必要的并且过于复杂。

我们应该首先部署能够显着改善 L1 可扩展性的最简单的 slot 重组更改，而不是全力以赴采用高复杂度设计。 延迟执行就是这种改变。

附录

EIP-7886 和 EIP-7732 在 6 秒 slot 下相比如何？

延迟执行和 ePBS 这两个提案都与较短的 slot 时间兼容。

对于延迟执行，slot 将如下图所示：

• 整个 slot 从 payload 显示开始供执行
• 传播时间以证明截止日期结束
• 无块-payload 分离 → 无分叉选择更改。
• 聚合时间仍处于关键路径中
• 没有后状态垄断

对于 ePBS，slot 将如下图所示：

• 整个 slot 从 payload 显示开始供执行
• 传播时间以 PTC 截止日期结束
• 更多管道，但有额外的委员会
• 聚合时间在关键路径之外
• 整个 slot 的 75% 可能会被后状态垄断捕获。
  • Builder 看到信标块并承诺其 payload，然后将 payload 的显示延迟到非常接近 PTC 截止日期为止。 在信标块传播和实际的 payload 发布之间，builder 可以利用此信息垄断，该垄断最多可以持续 4.5 秒（假设信标块在 0.5 秒时发布）。

在延迟执行下，承诺和 payload 显示之间没有延迟，因为信标块和 payload 没有分离。 一切都将保持今天的状态：获胜的 builder 首先具有后状态，而所有其他 builder 通常在证明截止日期之前很久就看到了该块，然后也可以获得后状态。

这种情况下的后状态垄断将如下图所示：

刚好在 PTC 截止日期之前等待的 Builder 可能会选择使用较小的 EL payloads，仅专注于将实际有价值的交易保留在区块中。 这样做是为了确保 EL payload 小且传播速度快。

利用后期 PTC 可用性检查的 Builder 可以在整个 slot 中建立对该状态的 75-83% 的垄断。

• Glamsterdam 公式

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