ePBS 与 FOCIL 兼容性

作者：Thomas Thiery，2025年7月10日

感谢 Julian, Terence, Anders, Caspar 和 Potuz 对本文的反馈和评论。

机制概述

在这篇简短的笔记中，我们证明了 ePBS ( EIP-7732) 和 FOCIL ( EIP-7805) 可以集成而不会发生冲突。我们重点介绍了确保它们在实践中兼容的关键设计考虑因素。

简要提醒。

• ePBS 实现了 slot 管线化，有效地增加了专用于在任何给定 slot 中执行和传播执行负载和 blob 的时间。
• FOCIL 通过允许多个验证者强制在每个区块中包含特定交易，从而提高了抗审查性。

虽然这两个提案都对 slot 结构进行了重大更改，但我们表明，只要 IL（inclusion lists，包含列表）不必基于最新的 head 构建才能被认为是有效的，它们的交互就不会出现冲突。

下图展示了后 ePBS FOCIL 的 slot 结构。

Slot N-1:

• Includers 在共识层 (CL) p2p 网络上构建和广播 IL。在 slot 结束时，slot N 的 attesters 冻结他们的视图并停止存储新的 IL。
• 几秒钟后，builder 也停止存储新的 IL，并更新其执行负载以确保其满足 IL 条件（即，所有 IL 中的交易的并集都包含在负载中，除非区块已满）。

Slot N:

• Proposer 运行其分叉选择规则以确定要构建的有效父区块，该规则包含 slot N-1 负载的 PTC 投票结果。然后，它根据以下因素从 builder 中选择并广播信标区块：

  • PayloadHeader 中指定的值（builder 的 bid）。
  • IL bitlist 是否包含 proposer 在其 IL 冻结截止日期之前看到的所有 IL。

• 只有满足以下所有条件，Attesters 才会投票支持信标区块 N：

  • 该区块基于根据 attester 对分叉选择规则的看法而定的有效 head 构建。该规则包含来自 slot N-1 的 Payload Timeliness Committee (PTC) 投票，该投票确定了负载 N-1 是否及时可用。
  • slot N-1 的负载满足其自身的 IL 条件。如果来自 slot N-1 的负载不符合（例如，未在其区块中包含有效的 IL 交易），则 slot N 的 attester 将不会投票支持区块 N，以重新组织不符合的负载 N-1。
  • 区块中的 IL bitlist 包含 attester 在其自身的 IL 冻结截止日期之前知道的所有 IL（此检查可以由 PTC 完成，请参阅下面的拆分强制执行部分中的更多内容）。
• Builder 公布其完整的 Payload N（例如，builder 可以选择在看到足够多的对其 PayloadHeader 的信标区块的 attestation 后公布）。
• 如果 Builder 及时提供了负载 N，则 PTC 会投票支持它。

ePBS 和 FOCIL 职责之间的重叠

现在，让我们看看协议职责如何在今天已经存在的职责（即使它们的时机或确切性质有所修改）、ePBS 引入的职责和 FOCIL 引入的职责之间重叠。

顺序无关性

首先，最重要的一点是，FOCIL 和 ePBS 职责的确切顺序并不重要。这主要是因为我们不要求 IL 基于链的规范最新 head 构建才能被认为是可强制执行的。换句话说，即使 includer 使用过时或不正确的 head 构建其 IL，builder 仍然必须考虑包含 IL 交易。因此，如果这导致某些 IL 交易由于先前已包含而变得无效，那也没关系。当然，我们仍然应该努力优化 includer 看到最新负载的情况，以便他们可以使用最新的相关交易构建 IL。

最有可能发生的是，本地 IL 冻结截止日期将在 builder 发布其负载之后，但在 PTC 投票之前发生。如果确实如此，则应通过优先考虑根据其本地视图在最新可用负载中未看到的交易来构建 IL。否则，includer 应只运行 get_head 并基于节点的本地 head 构建和发布其 IL。

拆分 IL 强制执行

另一个重要的考虑因素是确定谁应该强制执行 IL 条件得到满足。

简要回顾一下 FOCIL 在没有 ePBS 的情况下如何实现这一点：Slot N+1 的 Attester 验证其存储的 IL 中的所有交易是否包含在 proposer 的执行负载中，但发送者已经前后矛盾的 IL 除外。根据他们从前一个 slot 中冻结的 IL 视图，Attester 检查执行负载是否满足 IL 条件。他们通过确认所有交易都存在或确定如果将任何缺失的交易附加到负载末尾是否会失效来做到这一点。

相反，我们可以要求 builder 在其区块中包含并提交一个 IL bitlist，明确指出在构建其负载时考虑了哪些 IL。这允许 proposer 基于 IL bitlist 的包含性（即，builder 的 IL bitlist 是否涵盖了 proposer 在冻结截止日期之前存储的所有 IL）来选择区块。

有趣的是，slot N 的 attesters 或 PTC 也可以将其投票建立在 IL bitlist 的包含性之上。他们的投票为 proposer 提供了一个早期信号，表明 builder 的负载是否考虑了截止日期之前已知的所有 IL。

1. 使用 slot N 的 attester：

Attester 在 attesting 之前验证 IL bitlist 是否与其本地冻结视图匹配。主要的优点是它利用了整个信标委员会，但这意味着信标区块可能会因为未能满足 IL bitlist 包含性检查而被重新组织。

2. 使用 slot N 的 PTC：

或者，PTC 可以执行 IL bitlist 包含性检查。这种方法通过保护信标链免受由于 IL 相关条件而重新组织来创建一个更清晰的抽象。

通过这种设计，信标区块将不再仅仅因为包含对包含性不足的 IL bitlist 的负载的承诺而被拒绝。相反，如果 builder 的最终负载未通过确定性的后检查，则只会重新组织负载。信标区块本身仍然是规范的，下一个 proposer 只需在其上构建一个新的有效负载。

主要的权衡是，这种初始的包含性信号依赖于 PTC 中较小的验证者集合，而不是整个 attester 委员会。

两种选择都是可以接受的，更多的问题是关于我们是希望更多的 attester 提供更早，更强大的信号，还是希望 PTC 提供 IL bitlist 包含性信号，因此 IL bitlist 检查不会导致信标链重新组织。

最后，值得注意的是，拆分 IL 强制执行设计与 区块和 slot 拍卖 兼容 (h/t Potuz)。即使 builder 没有承诺特定的 PayloadHash，它仍然可以承诺一个 IL bitlist，然后它将被迫满足。

缺少负载时的 IL 满足度

在以前的 IL 设计（如 EIP-7547）中，在 slot N – 1 中发布的 IL 仍然是可强制执行的，直到它完全满足为止。如果 slot N 的执行负载永远不会出现，则 IL(N – 1) 和 IL(N) 会一起向前滚动，因此每个后续负载都必须先清除不断增长的积压，然后才能考虑更新的 IL。

使用 FOCIL 和 ePBS，规则更简单，并且对活跃性更加友好。即使连续丢失了多个负载，也可以继续提出信标区块，因为每个空区块的 IL bitlist 都被视为临时的。当负载最终到达时，它必须只满足最新包含丢失负载的区块的 IL bitlist；并且较旧的 IL bitlist 会被简单地忽略/丢弃。这避免了无界的 IL 累积，同时仍然强制执行最新、最更新的 IL。

ePBS 和 FOCIL 的协同作用

FOCIL 和 ePBS 之间的关键协同作用围绕着信标区块和执行负载的分离。这种分离使得可以通过拒绝不符合要求的负载来强制执行 IL 条件，而不会影响信标链的稳定性。这比其他提案（例如，延迟执行 EIP-7886）有了显着改进，在延迟执行中，区块和执行负载是组合在一起的。

具体来说，在 ePBS 中，信标区块和执行负载是分开验证的。信标区块通过 attester 投票在链中变为规范。如果负载后来被证明不满足 IL 条件，它将不会获得任何支持（例如，来自 PTC），并且可以被下一个 proposer 干净地丢弃。

如果没有这种分离，不符合要求的区块最初将在 slot N 中获得完全支持。一旦发现不符合要求，下一个 proposer (slot N+1) 会尝试使用竞争区块重新组织此区块。这会导致两个区块（原始的不符合要求的区块和竞争的符合要求的区块）具有相等的完全权重，从而导致链不稳定。

干净地将信标区块与执行负载分离的另一个优点是，attester 不再需要具有后状态值的静态检查（例如，要求诸如区块级别访问列表 EIP-7928）之类的对象才能确信下一个负载将满足 IL 条件。在 ePBS 下，稍后证明不符合要求的负载将被简单地丢弃，而信标区块仍然是规范的。

• FOCIL Breakout #16, July 29th, 2025, 14:00 UTC
• Soliciting stakeholder feedback on Glamsterdam headliners

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