epbs/DAS/FOCIL 一体化分叉选择

这是一个关于如何以兼容 epbs、FOCIL 和 PeerDAS 的目标和约束的方式来构建分叉选择的提议。

总的来说，这个 slot 仍然非常类似于来自 PTC 提议 的 epbs slot，自那以后已经迭代了很多次，并且是 EIP-7732 的基础。 特别是，我们仍然有 epbs slot 的主要阶段：信标块提议、证明（到目前为止就像今天的 slot 一样）、payload 发布，最后由委员会对 payload 进行投票。 这个委员会，以前被称为 payload 及时性委员会 (PTC)，现在更名为可用性委员会 (AC)，因为它现在不仅有责任对 payload 的及时性进行投票（这本身也可以被认为是投票时 payload 的可用性），而且还要对与 payload 相关的 blob 数据的可用性进行投票（PeerDAS 中的列）。

除了现有 epbs 提案中的这些阶段外，我们还有一个类似于 FOCIL 中的“冻结”截止日期（通常受到 view-merge 概念的启发），它既用于确保下一个提议者有足够的时间来满足所有最终被证明者强制执行的 IL，又用于确保其对 AC 投票的看法与证明者的看法一致。 这些都是为了确保诚实的提议者可以确定做正确的事情，即扩展正确的链，以便其提议得到证明并成为规范链的一部分。


管道中有几个参与者，所以让我们分别分解每个参与者在做什么，以及他们的行为如何协同工作。 我们专注于一个 slot N，其中提出了一个信标块 $B$，它提交给一个 payload $P$，然后看看在结果中起作用的整个行动链，包括 slot $N+1$ 的提议和证明。 我们假设链在此之前是完全稳定的。

Builder

Payload 构建

首先，一个 builder，包括本地的区块 builder，必须制作一个 payload，并增加了满足 IL 的约束。与没有 epbs 的普通 FOCIL 相比，IL 的执行最初是由 AC 成员而不是证明者完成的。 这样做的原因是下一个提议者（slot N+1）需要知道当前的 payload 是否“通过了 IL 检查”（这取决于时间，因此不是客观的），以及是否应该在下一轮证明发生之前扩展它。 与 FOCIL 中一样，验证者将强制执行他们在冻结截止日期（上面 slot 结构中是 10 秒，但可以更早）之前看到的 IL，并且 builder 可以通过考虑所有他们看到的 IL 来确保他们满足所有这些 IL，直到 slot 的稍后时间，直到构建 payload。

但是，epbs 的目标之一是不要求 AC 成员在投票之前执行 payload，以便我们放宽 payload 执行的时间限制。 在不执行的情况下，AC 成员无法自行检查 payload 是否实际满足 IL：某个 IL 交易可能未包含，但只是因为它在 payload 执行期间失效了，而 EIP-7702 之后，即使没有来自同一发送者的交易在区块中，也可能发生这种情况。 为了帮助 AC 成员履行他们的执行角色，payload 包含一个 bitfield，用于指定 builder 从哪些 IL 提议者那里收到了 IL。 我们稍后将解释这如何在执行中使用。

Payload 交换 (epbs)


默认的 builder 行为非常简单：

1. 一旦它看到 $B$，一个信标块致力于 builder 竞标的 payload $P$，它就会传播与其 payload 相关的 blob 数据，特别是 PeerDAS 中的列。 它可以这样做，因为它现在有一个已签名的 header，可以用来验证列。 此时，builder 可能对 $B$ 成为规范的保证很少，因为它如果没有获得足够的证明权重可能会被 reorg，因此它不想透露执行 payload，但无论如何它应该可以发布这些列。 这通常会给这些列近 7 秒的时间来传播，并且至少 ~4 秒。
2. 如果 builder 观察到 $B$ 有 40% (*proposer boost*) 的证明，*并且它没有观察到提议者的任何 双重提议*（一个有冲突的区块），它就会发布 payload。 这样做的确切时间是灵活的，并且取决于 builder 传播 payload 的速度。 原则上，它甚至可以在接近 7 秒的时候发布它，即可用性委员会对其进行投票的时间，但更谨慎的 builder 可能会决定只有在它在较早的截止日期之前看到至少 40% 的证明时才发布它。 例如，在 5 秒时，给它 2 秒的时间来观察证明，2 秒的时间来传播 payload。

支付处理

虽然这不是 builder 行为的一部分，但指定一个支付处理规则至关重要。 在 $P$ 被释放并成为规范这种好情况下，支付会立即处理，否则支付会被延迟一段时间，以试图确定交易无效的责任方：

• 好情况：payload 是规范的。 支付会立即作为处理 $P$ 的一部分进行处理（例如，在扩展“带有 $P$ 的 $B$”的第一个信标块的状态转换中）。 提议者显然履行了承诺，因此可以立即释放付款。 请注意，此规则与 $P$ 是否在某个时刻被 reorg，或者通常它在分叉选择中的稳定性无关。 如果你在一个 $P$ 存在的链上，支付会立即处理。 如果你切换到另一个 $P$ 丢失的分支，你也会切换到信标状态，其中支付可能尚未处理。
• 坏情况：payload 不是规范的。 如果你在一个 $P$ 丢失的分支上，*只有当 $B$ 从其委员会收到至少 60% 的证明，并且在下一个 epoch 结束时（即从 epoch E+1 到 E+2 的转换中，其中 E = epoch(slot(N))）没有检测到提议者的任何 双重提议，才会触发从 builder 到提议者的支付。

builder 的属性

我们将论证，假设 builder 具有足够的网络同步性和连通性，该协议实现了以下属性：

1. 诚实 builder 的支付安全性：如果诚实 builder 的支付被处理，他们的 payload 就会成为规范的。 这在高达 20% 的攻击者面前仍然成立。
2. 诚实 builder 的 payload 安全性：如果诚实的 builder 发布了一个 payload，它就会成为规范的。 这只需要诚实的多数。

builder 使用的默认发布规则的基本原理很简单，并且立即为我们提供了这些属性：

• 及时、得到充分证明的信标块：如果 $B$ 获得至少 40% 的证明，它就不会被下一个提议者 reorg，因为 40% 正好是 proposer boost 值。 准确地说，这是 *除非在 slot N 中提出了一个有冲突的信标块*，因为这也可能累积一些自己的证明权重，并且在 $B$ 的 40% 之内，从而有可能通过 proposer boost 进行 reorg。 然后有两种情况：
  • *未检测到 双重提议*：builder 发布，$B$ 确实成为规范的，因为如果存在 双重提议，它会非常晚，并且不会累积任何权重。 如果及时发布，$P$ 也会成为规范的。 原因是，如果在此时未检测到 双重提议，所有 AC 成员都将“[headlocked](https://ethresear.ch/t/equivocation-attacks-in-mev-boost-and-epbs/15338)”在 $B$ 上，因此将投票支持 $P$（请参阅 AC 成员部分），这确保了它成为规范的（我们在证明逻辑中会看到原因）。 对于每个人来说都是最好的情况。
  • *检测到 双重提议*：builder 不发布，并且有一个完整的 epoch 可以在链上对提议者进行 slashing，这将阻止支付。
• 延迟或证明不佳的信标块：如果 builder 在它考虑发布 $P$ 的最晚时间之前没有看到至少 40% 的证明，并且我们假设 builder 有足够的连接，那么 $B$ 只有在有超过 20% 的非常晚的证明的情况下才能超过支付发布的 60% 阈值，我们假设情况并非如此（按时证明是诚实行为的一部分）。

提议者


关于提议者的行为几乎没有变化。 在这里，我们专注于 slot N+1 的提议者，以继续我们对在 slot N 开始的流程的分析。 首先，提议者运行分叉选择，就像今天一样，除了有和没有 payload 的区块是单独且竞争的分叉选择对象。 如果链的头部不是在 slot N 中提出的信标块，它就像平常一样扩展它。 如果相反，它是来自 slot N 的信标块 $B$，并且不受 proposer boost reorg 的影响，它必须确定是扩展 $B$ 还是扩展其 payload $P$（更准确地说，是“带有 payload 的 $B$”对象）。 此时，它不能基于来自 slot $N$ 的证明来做到这一点，因为 slot $N$ 中的证明者还没有机会证明 $P$。 相反，它使用可用性委员会来做出这个决定，通过使用相对多数阈值：如果*它收到的* AC 投票的大多数（不一定是所有可能投票）是正面的，它就扩展 $P$，否则扩展 $B$（没有 payload）。 正如我们将在即将进行的关于证明者的部分中看到的那样，这与他们用来决定证明什么的criterion相同。

为了防止 AC 大致平均分配，并且一些战略性地发布的敌对投票可以影响证明者反对提议者选择的情况，我们使用了一个轻量级的 view-merge，仅应用于前一个 slot 的 AC 投票：

1. 提议者在其信标块中包含它所知道的所有 AC 投票
2. 在收到信标块后，证明者会考虑*在 $t=10s$ 之前收到的所有 AC 投票以及信标块中包含的所有 AC 投票*

像往常一样，一个需要澄清的是如何处理 双重提议 的 AC 投票。 幸运的是，在这种情况下，我们有一个非常简单的方法来处理它们：

1. 只考虑和传播你看到的第一个投票
2. 当收到一个包含与你已有的投票相冲突的投票的信标块时，使用前一个

有了这个，假设有足够的网络同步性，slot N+1 中证明者使用的 AC 投票将与提议者使用的 AC 投票完全一致。 理由很简单：提议者看到的投票集是任何证明者看到的投票集的超集，*除非在 双重提议 的情况下*，并且在 双重提议 的情况下，证明者只会默认同意提议者。 更明确地说：

• 如果一个证明者在 $t=10s$ 之前看到了来自验证者 i 的投票 $v_i$，那么提议者也看到了 $v_i$ *或者来自同一个验证者的一个有冲突的投票 $v'_i$*。 无论哪种方式，这样的投票都会显示在信标块中。 在前一种情况下，证明者和提议者都将使用验证者 $i$ 的投票 $v_i$，而在后一种情况下，他们都将使用 $v'_i$，因为在 双重提议 的情况下，证明者将按照提议者的选择行事。
• 如果一个证明者没有看到来自验证者 $i$ 的投票，但提议者看到了，提议者会在其信标块中包含该投票，并且证明者会使用它。
• 如果证明者和提议者都没有看到来自验证者 $i$ 的投票，他们都不会使用这样的投票。

AC 投票者


可用性委员会有三个目的：

1. 像 PTC 一样，它对 payload 的及时性/可用性进行投票，以确保下一个状态在 slot 结束前的一段时间内公开已知
2. 它对与 payload 相关的数据的可用性进行投票，以便在下一个提议者没有订阅所有列子网（它没有下载所有 blob 数据）的情况下，向下一个提议者提供一个可用性信号。
3. 它对 IL 满意度进行初步的、非常有限的确定，这*不需要执行 payload*。

AC 成员在整个 slot N 中的行为如下：

1. 一旦它看到了来自 slot N 的提议者发布的一个信标块 $B$，它就会“锁定在它上面”（参见 [headlock](https://ethresear.ch/t/equivocation-attacks-in-mev-boost-and-epbs/15338)），这意味着作为 AC 成员，它将投票赞成或反对 $B$ 提交的 payload $P$。 这是为了防止提议者的 双重提议 影响到 builder：如果 builder 没有检测到 双重提议 并发布了 $P$，那么所有 AC 成员都应该已经 headlocked 在 $B$ 上，并将投票支持 $P$，即使他们后来看到了另一个有冲突的信标块和 payload。
2. 在 7 秒时，如果它看到一个符合其“headlock”的 payload，它会投票支持，并且：
   • *DA 检查已满足*：其所有托管列都可用
   • *乐观的 IL 满意度*：如果一个 IL 发送者在 slot N-1（10 秒）的冻结截止日期之前看到了一个 IL，则包含在 payload 中的 bitfield 对于所有这些 IL 发送者都为 1 。

正如我们已经讨论过的那样，slot N+1 的提议者和证明者要求 payload 获得大多数 AC 投票。 假设 AC 是多数诚实的（或者在 DA 检查的情况下更多一点，以解释由部分可用性视图引起的错误），这意味着 AC 可以成功地强制执行 payload 是否按时发布，并使用一个 bitfield 来提交以满足所有及时发送的 IL。

DA 检查与其他检查有所不同，因为下一个 slot 中的证明者将再次进行他们自己的 DA 检查，未来的 slot 中的证明者也会这样做：没有人会证明不可用的东西，即使出于任何原因以前的 slot 中发生了这种情况。 正如在一开始提到的那样，AC 并不是在强制执行 DA，而是向下一个提议者提供关于 DA 的早期信号，以防它自己无法做出完整的可用性判断。

IL 执行

虽然及时性和 DA 执行很简单，但 IL 执行并非如此，所以让我们更详细地讨论一下。 下一个 slot 的提议者使用该 bitfield 来决定是否扩展 payload，通过检查它隐含引用的 IL 的满意度，并且下一个 slot 的证明者也将以同样的方式使用它来决定是否投票支持该 payload（或者一个扩展它的区块）。 换句话说，IL 的执行分为两个部分：

1. 该 bitfield 隐含地建立了一组 payload 承诺满足的 IL，AC 只是强制执行该 bitfield 具有足够的包容性，也就是说，payload 承诺根据 AC 成员自己的看法满足它应该满足的所有 IL。
2. 鉴于一个 payload 已经通过了 AC 的 bitfield 检查，通过收到 50% 的 AC 投票，slot N+1 的证明者实际上会检查该 payload 与它承诺满足的 IL 的合规性，这需要执行该 payload（至少使用 EIP-7702）

这里的一个小警告是，在 IL 提议者 双重提议 的情况下，IL 提议者的 bitfield 并不能唯一地指定一个 IL，在这种情况下，builder 可能已经看到并满足了一个 IL，但其他节点可能希望满足另一个 IL。 但是，我们 IL 的传播规则规定每个 IL 提议者最多传播两个 IL，以便 双重提议 的证据默认传播。 然后，slot N+1 的证明者将简单地忽略来自 双重提议 IL 提议者的任何 IL：即使该 bitfield 对于某个 双重提议 IL 提议者有一个 1，证明者也会将其视为 0，因此他们不会基于该提议者发送的 IL 对 payload 施加任何额外的约束。

证明者

最后，我们即将到达我们的流程中的最后一个actor，所有我们讨论过的东西的最终执行者，因为他们负责将临时的本地决策和 AC 投票巩固到分叉选择中。

分叉选择

让我们首先讨论一下分叉选择在这种情况下是如何工作的。 区块树现在有两种对象，而不仅仅是信标块：空的和完整的信标块，或者换句话说，没有和有 payload 的信标块。 对于给定的提交给 payload $P$ 的信标块 $B$，“带有 $P$ 的 $B$”和“没有 $P$ 的 $B$”，或者 $B$ 空的和 $B$ 完整的，在分叉选择树中具有相同的父节点，即 $B$ 的父节点（它本身可以是一个空区块或一个完整区块）。 对于分叉选择树中具有相同父节点的对象，与往常一样，$B$ 空的与 $B$ 完整的竞争，这意味着在运行分叉选择时，只能选择两个分支中的一个。

选择分支是通过选择具有最多证明权重的子树来完成的，与往常一样，但有一个小的警告：来自 $slot(B)$ 的$B$ 空的的投票*既计入 $B$ 空的，也计入 $B$ 完整的*，而来自$slot(B)$ 的投票只能落入两个子树中的一个。 这么做有一个简单的原因：在 $slot(B)$ 中的证明者只能证明 $B$ 空的，因为在那个时候 payload 还没有被发布。 $B$ 空的和 $B$ 完整的之间的决定最初是由 AC 做出的，然后由 $slot(B)+1$ 轮的证明来巩固，正如我们在下一节中讨论的那样。 在那个时候，那些证明是唯一区分 $B$ 空的和 $B$ 完整的分叉选择权重，因为来自 $slot(B)$ 的证明对两者都有效，因此它们完全决定了它们之间的最终决定。


合成证明行为


在 slot N+1 中的证明者运行分叉选择，并确定链的头部是什么。 根据是否达到来自 slot $N$ 的信标块，有两种情况：

• *链的头部来自 slot < N*：在这种情况下，来自 slot $N$ 的 AC 投票是不相关的，因为链的头部是有 payload 还是没有 payload 的信标块的确定，完全基于之前的证明。 例如，假设链的头部是来自 slot $N-1$ 的信标块 $A$。 然后，slot $N$ 的证明者已经有机会对 $A$ 空的和 $A$ 完整的进行投票，并且它们之间的最终决定取决于他们的投票。 在这种情况下，如果有新的信标块来扩展头部，则证明者会投票给链的头部或该区块。
• *链的头部来自 slot $N$*：在这种情况下，他们现在必须根据 AC 投票来判定是否要投票支持 payload 的存在。 这有两个步骤：
  1. 他们首先以我们在proposer的部分中描述的方式，将他们对 AC 投票的看法与当前proposer的看法合并（如果当前的信标块有一个与你冻结的看法中冲突的 AC 投票，请使用该投票来代替你的）
  2. *如果 payload 满足他们现在正在考虑的 AC 投票中 50% 的阈值，所有托管列都可用，并且所有由 bitfield 引用的 IL 都得到满足*，他们会投票支持该 payload ($P$) 或扩展它的一个新信标块（如果有的话）。 如果 payload 没有满足 50% 的阈值，他们会投票反对该 payload，这意味着投票给来自 slot $N$ 的信标块 ($B$) 或扩展它的一个新信标块。

正如在可用性委员会的部分中已经提到的那样，“由 bitfield 引用的 IL”是指“所有由 bitfield 中有 1 的 IL 提议者发送的 IL，仅排除 双重提议 者”。

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