预确认的未来保障 - 共识

即将到来的 EIP 如何影响预确认

作者：Aikaterini-Panagiota Stouka 和 Conor McMenamin，均来自 Nethermind。

感谢 PBS 基金会 的资助，本文得以完成。感谢 Lin Oshitani 和 Davide Rezzoli 提供的有益评论和意见。观点仅代表作者本人。

简介

预确认是区块提议者和构建者的一种特定承诺，它向用户保证他们的交易在提议者或构建者发布用于最终确定的完整区块之前，会被包含/执行。然而，大多数预确认协议的设计和分析都以以太坊当前的设计为基础。感谢以太坊改进提案（EIPs*），以太坊总是在变化和升级。其中一些 EIPs 直接影响预确认协议的兼容性，无论是通过设计还是作为副作用。

本文从预确认的角度考察了一些最具影响力的 EIPs，并检查这些 EIPs 将如何影响预确认，以及预确认协议可以采用哪些修正案（如果有）以在这些 EIPs 被包含在以太坊上时保持兼容。这些 EIPs 旨在修改 L1 区块提议者的选择方式，隐藏 提议者前瞻信息，在多个实体之间分配 区块提议责任，或引入有助于区块内容和抗审查的新实体。本报告根据撰写时最合理的 EIP 设计，分析了这些 EIPs 可能对预确认产生的影响。

分析总结

\ image753×629 110 KB

\ image775×853 164 KB

文章大纲

在 预备知识 部分，我们介绍：

1. 预确认的类型，基于以下方面进行分类：
2. 交易对应的层级（L1 或 L2）
3. 预确认提供的保证的性质（包含或执行）
4. 当前设计中预确认协议的关键特性：
5. 预确认者偏差时的惩罚。
6. 补偿预确认者的奖励/小费。

在 分析每个 EIP 的框架 部分，我们介绍了用于评估现有预确认设计是否以及如何受到提案和 EIPs 影响的框架。

随后，以下每个部分都会检查一个特定的 EIP。我们分析的 EIPs 包括：

1. 包含列表。具体来说：
2. 分叉选择强制执行的包含列表 (FOCIL)
3. 一种基于拍卖的包含列表设计，用于增强以太坊的抗审查性 (AUCIL)
4. 多个并发提议者 (MCP)
5. 单秘密领导者选举 (SSLE)
6. 证明者提议者分离 (APS)
7. 固化的提议者-构建者分离 (ePBS)。

预备知识

预确认的类型

根据交易发生的区块链层级以及预确认提供的保证的性质，可能存在几种类型的预确认。

基于区块链层级的预确认类型如下：

1. L1 交易的预确认；我们将它们表示为 L1 预确认。

2. 基于 L2 中的 L2 交易的预确认；L2 区块链协议，其中 L2 交易排序由 L1 决定。在此分类中，有两个重要的区别：

3. 所有 L1 提议者都是 L2 提议者。对于本文中执行的分析，这些预确认与 L1 预确认无法区分。出于这个原因，以及为了便于表示，我们将 L2 基于预确认的分析（其中所有 L1 提议者都是 L2 提议者）包含在 L1 预确认的分析中。

4. L1 提议者的一个子集是 L2 提议者。在这种设置中，L2 提议者可能拥有对多个 L1 插槽提出 L2 区块的专有权。我们将这些预确认表示为 基于 L2 的预确认。如前一点 2.a 中所述，这不包括所有 L1 提议者都是 L2 提议者的一个例外情况，为了本文的目的，该情况被归类为 L1 预确认。

5. 非基于 L2 中的 L2 交易的预确认（例如，Arbitrum，OP，Polygon Layer 2 区块链协议，其中交易排序由 rollup 控制的排序器集处理）。由于在这种类型的预确认中，交易排序不依赖于 L1 提议者，因此我们预计我们讨论的 EIPs 不会对这种类型的预确认产生有意义的影响。

基于执行保证性质的类型如下：

1. 包含预确认：这些保证交易将被包含在未来的区块中。
2. 执行预确认：这些保证交易将以特定顺序包含在特定插槽中。

注意： 我们只分析由指定的提议者提供的与确认，包括包含列表提议者/创建者（如果相关），或已被委以独家提议权的实体。我们省略对来自不控制提议权的实体的任何预确认的分析。这是为了确保对预计将在 L1 和 L2 上提供的主要形式的预确认进行重点分析。非提议者 和来自无法保证提出必须遵守的区块/包含列表的实体的概率性预确认是可能的，但超出了本文的范围。

注意： 对于包含预确认，许多指定提议者作为预确认者可能会为同一交易提供预确认。小费的兼容性和有效性将取决于如何处理竞争性的包含预确认。一般来说，包含预确认者在提供预确认时必须接受这种风险。当同一插槽有多个预确认者时（如包含列表和多个并发提议者 EIPs 中），这种风险会更高。这些风险可以通过记录所有预确认请求和响应的中介机构，或通过专门的用于支付小费的预确认平台来缓解。

在本文的剩余部分，提供预确认的实体将被称为预确认者。

当前以太坊设计中预确认的特征

为了检查各种 EIPs 可能如何影响预确认设计，我们的分析检查了两个关键的预确认协议机制可能如何受到各自 EIPs 的影响。这些是惩罚和奖励机制。正如之前的一篇 PBSF 资助文章中强调的那样，预确认在很大程度上依赖于提议者提供和最终确认预确认的激励机制。通过展示每个 EIP 对现有预确认惩罚和奖励机制的影响，我们能够识别预确认的不兼容性，或者在大多数情况下，是需要对预确认协议和/或底层区块链特性进行修改，以正确启用惩罚和奖励机制，从而启用预确认本身。

惩罚

所有预确认设计都依赖于某种形式的惩罚和/或执行机制，以阻止预确认者反悔或延迟发布预确认。为了我们的分析目的，我们将根据执行惩罚的实体对这些惩罚进行分组，灵感来自 这里介绍的框架。

1. 智能合约：在所有预确认设计中，可以使用智能合约来执行涉及纯客观行为的条件。一些例子包括安全违规，即预确认者扰乱了预确认的交易顺序，以及活性违规，即预确认者排除了预确认的交易（参见 预确认者注册表 中的 slashing 条件）。

2. 监督者（此处提议）：一个具有特殊权力来执行对预确认者的某些行为或惩罚的实体。监督者最初是为了实现预确认请求和响应的 公平交换 而引入的，但更一般地，它们可以用于执行客观和主观的预确认要求。来自监督者的惩罚可以包括：

3. Slashing。监督者可以任意对预确认者的抵押品施加 slashing 条件。

4. 列入黑名单。监督者可以维护一份所有违规预确认者的名单，并阻止他们在特定时期内担任预确认者。

5. 订单流损失。监督者可以通过以下方法之一减少或停止违规预确认者的订单流（预确认请求）：

   1. 预确认必须由预确认者和监督者共同签署，允许监督者停止签署违规预确认者的预确认。
   2. 发出信号。监督者可以发出信号表明预确认者是违规的，从而提示用户停止向该预确认者发送预确认请求。

6. 用户：用户可以停止向违规预确认者发送预确认请求，无论是针对当前插槽还是未来的插槽。这将被称为订单流损失，可以是短期或长期的。

奖励/小费

预计预确认者在发布预确认后会获得奖励。小费可以通过正常的交易费用支付给预确认者，或者由监督者或专门的智能合约管理和分配。我们的分析侧重于我们预计在每个 EIP 下小费支付机制和/或小费总额会发生怎样的变化。

分析每个 EIP 的框架

我们使用以下框架检查简介中讨论的每个 EIP：

1. 我们提供 EIP 的概述，重点关注与预确认最相关的方面。
2. 对于每种预确认类型或类型组（每个子部分一个组），我们讨论：
3. 兼容性：如果出现兼容性问题，我们会探讨潜在的修正案以确保对齐。
4. EIP 导致的惩罚和奖励有效性的变化。

对于 APS，由于存在几种候选设计，每种设计以不同的方式影响不同预确认类型的兼容性，因此我们采用了不同的框架。这在第 4 章（涵盖 APS）中会更详细地解释。

第 1 章：包含列表

我们检查的第一个 EIPs 是允许多个类似提议者的实体通过构建包含列表来为区块构建贡献输入的协议，其中一个指定的提议者负责确定交易顺序。这些协议旨在增强以太坊的抗审查性。两个突出的例子是 分叉选择强制执行的包含列表 (FOCIL)（参见 此处 的 EIP）和 一种基于拍卖的包含列表设计，用于增强以太坊的抗审查性 (AUCIL) （参见 此处 的预印本版本）。

1.1. FOCIL 和 AUCIL 概述

这两个协议都使用一个由随机选择的实体组成的委员会，称为 inclusioners（包含者），来创建交易的包含列表。

FOCIL

区块提议者创建他们的区块，如果有空间，他们必须包含来自包含列表中的所有有效交易。如果他们未能这样做，证明者可以拒绝他们的区块。在 当前设计 中，用户不向包含者支付任何费用。我们将这种核心设计称为具有 无包含者费用 的 有条件包含列表。此核心协议的关键变体包括：

• 无条件包含列表：区块提议者必须包含来自所有包含者的包含列表中的所有有效交易，即使存在拥堵（即，没有足够的空间容纳内存池中的所有交易）。交易顺序由区块提议者决定。
• 包含者费用：如果用户的交易同时包含在区块和包含列表中，则用户需要向委员会支付额外的费用（参见 此处）。

AUCIL

AUCIL 是另一种旨在通过 无条件包含列表 增强以太坊抗审查性的协议（参见 此处 第 3, 15 页）。AUCIL 的主要补充是 (i) 存在一种相关均衡方法，可以激励包含者以特定方式创建 ILs，以及 (ii) 存在一种基于拍卖的 IL 聚合：聚合器聚合 ILs 并提交投标，区块提议者选择最大的聚合列表。如果区块提议者不满足关于聚合列表中包含的包含列表数量的特定要求（此处详细介绍），则提议者的区块将被证明者拒绝。这些补充 (i) 不可知论地进行排序，并且提议者是否能够添加自己的交易 (ii) 可以允许更多的 ILs，因为我们不需要保证所有 ILs 都必须对一个聚合器可用。为了本文的目的，我们认为排序由区块提议者执行，并且区块提议者能够添加更多的交易（这与无条件 FOCIL 相同）。

1.2. 预确认分析

我们将以下分析组织成预确认类型组，这些类型组在与现有预确认设计的兼容性以及相关惩罚和奖励有效性的变化方面具有相似的特征。分组如下：

• 包含预确认。
• L1 执行预确认。
• 基于 L2 的执行预确认。

1.2.a. 包含预确认

有了包含列表，就有两个不同的参与者可能提供预确认：区块提议者和包含者。因此，我们分别讨论每个参与者的兼容性。

兼容性：区块提议者预确认

使用 FOCIL 中的有条件包含列表：

• 区块提议者仍然可以在他们的区块中包含所有预确认（因为他们只需要在有空间时才尊重包含列表）
• 区块提议者选举过程保持不变。因此，我们预计与现有预确认设计不存在任何兼容性问题。

在 FOCIL 和 AUCIL 中的无条件包含列表的情况下，如果已知组合的包含列表占用的空间小于总区块空间，我们再次预计不存在任何兼容性问题。在这种情况下，区块提议者仍然可以为剩余的区块空间发布预确认。

提议者可能会发布超出他们自己区块中可用空间的预确认，预计早期的 L1 提议者将利用可用的区块空间代表预确认者包含这些预确认。由于预计包含列表会增强抗审查性，这使得提供超出预确认者自身区块空间的预确认更可行且风险更低。

兼容性：包含者预确认

使用 FOCIL 中的无条件包含列表，包含者也可以发布包含预确认。假设 FOCIL 按预期工作（例如，2/3 的证明者是诚实的，并且区块提议者旨在生成有效的区块），来自包含者的预确认与来自区块提议者的预确认具有相同的优势。

使用 AUCIL，由包含者发布的预确认风险更高，因为正如我们已经提到的，AUCIL 允许包含列表对所有聚合器不可用的情况。为了获得与 FOCIL 相同的预确认保证，我们需要在 AUCIL 设计中，即使他们遗漏了一个 IL，也要惩罚区块提议者。

包含列表中包含交易的能力会带来一个显著的缺点：预确认占用包含列表中的空间，这些空间主要用于容易受到审查的交易。此缺点被称为“拥挤”，并且已在 此处，此处，此处 讨论过。

对于有条件的 FOCIL，我们不希望包含者发布预确认，因为当区块已满时，区块提议者可以省略 ILs，而他们的区块不会被证明者拒绝。此外，在下一个插槽中，将选出新的包含者，并且下一个插槽的区块提议者没有义务包含来自为先前区块发布的 ILs 中的交易。（对于插槽 N+1，只需要遵守在插槽 N 的第 0 秒到第 9 秒之间传播的那些 ILs。）。

惩罚和小费的有效性

有条件的包含列表不应影响惩罚机制的有效性，因为预确认者仍然是相同的实体，以相同的方式和相同的频率选出。

在使用无条件 FOCIL 和 AUCIL 的情况下，从区块提议者的角度来看，我们只期望与未来预确认小费相关的惩罚会受到影响，即列入黑名单和订单流损失的惩罚。

由于无条件包含列表必须消耗一部分区块空间，因此区块提议者可用于预确认的空间较少。这将影响预确认小费，并因此影响列入黑名单和长期订单流惩罚的有效性。在这一点上，很难预测无条件包含列表对小费的确切影响，但我们至少看到了两个关键的抵消力量：

• 无条件包含列表减少了预确认的容量，因此也减少了从预确认中收取小费的数量。
• 由于区块空间供应减少以及由此产生的对可用空间的需求增加，每次预确认的平均小费应该会增加。

在使用包含者作为预确认者的情况下，列入黑名单和订单流损失的有效性将直接关系到包含列表预确认市场的价值。与提议者预确认一样，选举频率、包含列表的大小以及预确认可以在插槽之前多久提供，都会影响包含者的预确认收入。但是，此价值的主要驱动力将来自用户需求。在没有高价值预确认市场的情况下，slashing 仍然是一种可行的惩罚机制。

正如“预确认的类型”部分中提到的，许多包含者作为同一插槽的包含预确认者会增加冲突包含预确认的风险，这可能会给预确认者带来结算和小费风险。

1.2.b. L1 执行预确认

兼容性

在这种情况下，预确认只能由插槽 N 的提议者在插槽 N 期间发布。此外，在有条件和无条件包含列表中，区块提议者都保留对区块排序的控制权。这确保一旦插槽 N-1 的区块已发布，插槽 N 的区块提议者就完全了解在发布执行预确认时必须遵守的相关 L1 或 L2 状态。因此，我们预计这些类型的预确认不存在任何兼容性问题，除了在无条件包含列表中，区块提议者应该只为包含列表未占用的区块空间发布预确认。

对于执行预确认，包含者不能充当预确认者，因为他们不控制 L1 或 L2 区块中交易的顺序。

惩罚和小费的有效性

这些预确认的惩罚和小费的有效性与区块提议者角度的包含预确认相似。

由于包含者不能提供执行预确认，因此他们的分析与本节无关。

1.2.c. 基于 L2 的执行预确认

兼容性

不存在兼容性问题。基于 L2 的执行预确认者可以在他们的预确认插槽开始时立即提供预确认，只要预确认者知道预确认前瞻信息。仅通过成为包含者，无论是有条件还是无条件，包含者都不能提供基于 L2 的执行预确认。如果包含者碰巧注册为 L2 提议者，则只有当包含者也是活跃的执行预确认者时，包含者才能提供基于 L2 的执行预确认，即，它是该包含者的预确认插槽。否则，如果是其他人的预确认插槽，则其他人拥有提出 L2 区块的专有权，因此使包含者提出的任何 L2 区块都无效。

惩罚和小费的有效性

在无条件包含列表中，预确认者的可用区块空间较少。如果此减少影响了每个插槽的预确认的预期奖励，那么列入黑名单和长期订单流也将受到影响，如第 1.2.a 节中所述。

除此之外，我们预计惩罚和小费的有效性不会发生重大变化，因为无论有无包含列表，预确认者的选举方式和频率都相同。

第 2 章：多个并发提议者 (MCP)

2.1. MCP 概述

在 MCP 中，两个或多个实体为当前插槽提出部分区块负载（我们将这些部分负载表示为子区块）。最终区块的负载是通过获取来自所有这些子区块的交易的并集形成的，并根据一些确定性排序规则进行排序。这种确切的规则尚待讨论，但 已经考虑了优先级费用排序。BRAID 是 MCP 协议的一个例子。

2.2. 预确认分析

我们根据以下内容拆分本节的预确认分析：

• 包含预确认。
• 执行预确认。

2.2.a. 包含预确认

兼容性

假设子区块的并集不大于最终区块，则提议者可以充当包含预确认者，因为最终区块包含来自所有子区块的所有交易（也在此处讨论 此处, 此处, 此处）。

惩罚和小费的有效性

如第 1 章所述，列入黑名单和长期订单流损失的有效性取决于每个 epoch 中来自预确认的预期小费。小费越高，这些惩罚就越有效。虽然与单提议者协议相比，提议者在 MCP 中应该更频繁地选出，但为了保持网络带宽利用率，子区块的大小应与提议者数量的倒数成正比。换句话说，在 MCP 和单提议者设置中，可用于预确认的总可用空间应该保持不变。如果是这种情况，我们预计 MCP 中的包含预确认小费不会发生变化。

正如“预确认的类型”部分中提到的，许多 MCP 提议者充当同一插槽的包含预确认者会增加冲突包含预确认的风险，这可能会给预确认者带来小费风险。这将取决于：

• 特定 MCP 实现如何处理重复交易。
• 当多个预确认者为同一交易提供预确认时，如何向预确认者支付小费：   - 只支付一份小费，例如，支付给其区块包含交易最终版本的提议者。   - 所有提供预确认的预确认者都会收到小费。

2.2.b. 执行预确认

兼容性

这取决于排序规则，但通常，不知道合并区块最终排序的 MCP 提议者不能提供 L1 执行预确认。在预先为子区块提供排序优先级的 MCP 实现中，第一个子区块的提议者可以提供执行预确认。也就是说，目前尚未正确考虑这种 MCP 实现，尽管它与无条件 FOCIL 非常相似，区块提议者具有构建和排序区块顶部的优先级。

对于 L2 执行预确认，如果单个 MCP 提议者拥有提出 L2 区块的专有权，则可以进行 L2 执行预确认。相反，如果多个 MCP 提议者可以提出 L2 区块，则执行预确认不兼容。

第 3 章：单秘密领导者选举

3.1. SSLE 概述

在 单秘密领导者选举 (SSLE) 的现有结构中，一个共同点是下一个 epoch 的验证者时间表是隐藏的；只有当选的验证者知道他们被分配为领导者（= 提议者）的特定插槽，每个插槽只有一个领导者。这旨在增强拒绝服务 (DoS) 保护。SSLE 协议的一个具体描述是 Whisk，如下所示。

Whisk 是对 此处 介绍的协议的修改版本，其工作原理如下。最初，在引导期间，每个 验证者都承诺一个长期随机秘密。然后，通过 RANDAO 选择一个随机的验证者子集来使用新的随机性来承诺他们的长期秘密。这些承诺随后由当前时间段的领导者进行洗牌和重新随机化。从这组洗牌后的验证者中，通过 RANDAO 选择每个插槽一个随机子集，以作为下一个时间段的插槽领导者。分配方法是这样的，只有分配给插槽的验证者（知道与插槽对应的秘密）才知道插槽分配。要证明给定插槽的领导地位，验证者必须证明拥有相应的承诺（而不泄露其长期秘密）。他们通过使用零知识证明来证明他们知道嵌入在承诺中的秘密并且该秘密与他们的长期秘密匹配来实现这一点，该秘密以密码方式绑定到他们的身份。

3.2. 预确认分析

我们根据以下内容拆分第 3 章的分析：

• 包含预确认和 L1 执行预确认。
• 基于 L2 的执行预确认。

3.2.a. 包含预确认和 L1 执行预确认

兼容性

在 SSLE 设计中，如果预确认者愿意提前泄露他们的身份，那么我们预计与现有预确认设计不存在兼容性问题。当然，这确实破坏了选举的保密性。

另一方面，如果预确认者希望在提出区块之前保持匿名，那么预确认机制的构建需要仔细调整。我们在下面提供了一个兼容的修改后的预确认协议的概要。

为了使验证者能够在保持匿名的情况下证明他们是插槽 N 的合格预确认者，验证者必须证明以下两个陈述是正确的：

• 验证者是插槽 N 的领导者。

使用零知识证明来证明此语句也已在 此处 和 此处 进行了讨论。在 Whisk 的特定情况下，验证者需要证明他们知道隐藏在与插槽 N 关联的承诺中的长期秘密。

• 如果惩罚涉及 slashing，则验证者需要证明他们当前已注册 slashing，例如在 注册表合约 中。

实现此目的的一种方法是注册表智能合约维护一个只追加的 Merkle 树，其中包含所有已注册验证者的公钥，例如今天在 通用注册表合约 中存在的公钥。然后，预确认者可以提供证明，证明他们拥有与此 Merkle 树中包含的公钥相对应的私钥（类似于 Zcash 中使用的技术）。

• 如果惩罚涉及列入黑名单，则验证者需要证明他们不属于黑名单集。

实现此目的的一种方法是监督者（或智能合约）维护一组被列入黑名单和未被列入黑名单的预确认者，并且预确认者证明他们是未被列入黑名单的集合的成员，例如使用稀疏 Merkle 树包含证明。

关于小费的兼容性，如果小费立即给予预确认者，则预确认者需要在他们的插槽之前泄露一个地址，这可能会暴露他们的身份。相反，小费可以支付给智能合约，并在插槽 N 之后发布给预确认者，但前提是没有满足 slashing 条件。插槽 N 过去后，验证者的身份将公开。因此，可以从那时起应用小费和惩罚。

在保持预确认者身份匿名的情况下，由用户施加的与声誉相关的惩罚并不容易施加。可以启用匿名声誉工具，以使预确认者能够将声誉传达给用户。但是，鉴于声誉旨在取代列入黑名单和其他与监督者相关的协议，这意味着每个预确认者的声誉都需要在每个用户的基础上维护，这非常复杂，并且可能不适合使用。

惩罚和小费的有效性

如上一节所述，没有预确认者身份泄露的 SSLE 使基于声誉的惩罚高度复杂并且可能无效。其他惩罚机制仍然有效，尽管需要按照上一节中讨论的实现方式仔细实施。

从理论上讲，SSLE 预确认下对预确认的需求应基本保持不变。但是，鉴于 SSLE 预确认产生的额外复杂性，我们预计提议者将需要更高的预确认小费才能成为预确认者。

最后，如果选举频率发生变化并改变了每个 epoch 中来自预确认的预期奖励，那么列入黑名单或订单流损失的有效性也会受到影响，如前几节中所述。

3.2.b. 基于 L2 的执行预确认

兼容性

回想一下，当预确认者的预确认插槽开始时，可以由预确认者发布这种类型的预确认，该插槽可以覆盖一个或多个 L1 插槽。回想一下，为了在他们的提议插槽之前提供执行预确认，预确认者需要知道预确认前瞻信息。为了启用预确认前瞻信息（或没有身份的预确认者的时间表）的泄露，我们需要一种机制来强制/激励所有预确认者泄露他们的插槽，类似于第 3.2.a 节中描述的方式（通过泄露他们的身份或使用零知识证明来证明他们是特定插槽的合格预确认者）。

可能的解决方案 - 监督者的利用： 在 L2 系统中，监督者可以为预确认泄露设置截止日期。这强制所有预确认者在固定的截止日期之前泄露他们的角色，例如，在由 SSLE 协议确定验证者时间表后的几秒钟。在截止日期之后，具有预确认者的插槽将变得固定，从而启用确定性的预确认者时间表。但是，这种方法引入了潜在的活跃性问题，即监督者可以拒绝及时泄露其角色的预确认者。 为了缓解这个问题并消除对 overseer 的活跃性依赖，可以将 overseer 限制为仅进行 slashing，slashing 任何未在特定截止日期前揭示其角色的 preconfer。这种替代解决方案也有其自身的缺点：前瞻不再是确定性的。如果前瞻不是确定性的，则超过一个 slot 的 preconfirmation 窗口的执行 preconfirmation 可能会被 proposer 无效，因为 proposer 在 preconfirmation 窗口中较早的 slot 中将其角色揭示为有效的 preconfer。因此，我们认为 overseer 强制执行的前瞻解决方案是基于 L2 执行 preconfirmation 的更可行的解决方案。

惩罚和 tips 的有效性

预计 tips 和惩罚的有效性与前面 SSLE 小节中讨论的相同。

第 4 节. Attester Proposer Separation (APS)

4.1. APS 概述

在 APS 中，执行 proposer 的角色与其他验证者职责（例如 attesting）分离。这种分离使得更复杂的执行 proposers 能够参与以太坊，同时减轻 incentive spillover 从 proposers 到 attesters 的影响，后者应保持高度分散的验证者集合的一部分。APS 的两个主要设计是 Execution Auctions (EA) 和 Execution Tickets (ET)。

在这两种设计中，执行 proposer 的角色都被分配给复杂的竞争实体。在 EA 中，proposers 通过拍卖确定性地选择，而在 ET 中，它们通过 lottery 随机选择，因为它们之前购买了 tickets（参见这里，这里，这里，这里）。

4.2. Preconfirmation 分析

我们围绕上述 APS 的两个关键设计方面构建以下分析：

• 何时运行 APS 拍卖。也就是说，slot N 的执行 proposer 提前多久被选出。建议包括：

  • 提前多个 slots（例如 32 个 slots）。
  • 在 slot N-1 的区块被提出后的 Dt 秒（提案见这里；该提案表示为具有随机性的提前 2 个 slots 的执行 tickets）。在这种设计中，slot N 的执行 proposer 是通过在 slot N-1 的区块提案后的 Dt 秒提取的随机性来确定的。
  • 在 slot 期间通过即时拍卖 (JIT)。
• 是否允许在协议内转售提案权， 即，当选的 proposer 是否可以转售其提案权。

对于此设计方面的每种 APS 类型，我们概述了哪些类型的 preconfirmations 兼容，哪些不兼容。最后，在最后一个小节中，我们讨论了 APS 对惩罚和 tips 有效性的预期影响。

4.2.a. 兼容性：何时运行 APS 拍卖

就兼容性而言，preconfers 将是各自 APS 拍卖或 lottery 的获胜者。这为 中心化网关（可以代表验证者提供 preconfirmations） 铺平了道路，使其可以在当前的以太坊设置中移除这个中间人，并成为 proposer 本身，以最大限度地降低成本/最大化收入。因此，我们预计在 APS 下，L1 执行 proposers 和 preconfirmers 会更加复杂，他们的选择频率与他们存入的 stake 脱钩。

正如这里所讨论的，在 RANDAO 是唯一随机性来源的 APS 设计中，在称为多 slot MEV 预防和与 preconfirmations 的兼容性的属性之间存在权衡。多 slot MEV 指的是作为多个连续 slots 的 proposer 比单独从每个 slot 中获得的 MEV 总和产生更多的 MEV 的现象（参见这里）。这里提出的结构通过防止多 slot MEV 同时仍然支持某些类型的 preconfirmations 来解决这种权衡。但是，它假设 slot N 的执行 proposer 是使用在之前 slot 的区块提案后的 Dt 秒提取的随机性来选择的。下面，我们详细阐述这些想法：

• 在执行 proposer 提前很多 slots 被选中的设计中，我们希望看到所有类型的 preconfirmations。这些设计的缺点是它们容易受到多 slot MEV 的攻击。
• 在 slot N 的执行 proposers 在 slot N-1 的区块提案后的 Dt 秒被选出的设计中（这里提出），可以防止多 slot MEV，并且仅支持在 slot 本身期间发布的 inclusion 和执行 preconfirmations。较小的 Dt 会带来更多的时间和更有价值的 preconfirmations。这些设计的缺点是它们假设在 slot N 的区块提案之后提取随机性。
• 执行 proposer 选举发生在 slot 期间的设计，例如，即时拍卖可以防止多 slot MEV，因为 slot N 的执行 proposer 在知道 slot N+1 的执行 proposer 之前提出一个 payload。但是，我们不希望这些即时选举设计支持任何类型的 proposer preconfirmations。

4.2.b. 兼容性：提案权在协议内的转售

如果执行 proposer 提前很多 slots 被选中，但允许在协议内转售其权利的设计仍然可以支持 preconfirmations，只要满足以下条件之一：

• 存在强制执行机制，使得原始执行 proposer 可以对购买提案权的 proposer 强制执行提供的任何 preconfirmations。确切的强制执行机制将非常重要：

  • 强制执行特定交易列表的 L1 区块顶部排序：所有类型的 preconfirmations 都可以由原始 proposer 提供和强制执行。
  • 仅 L1 inclusion：原始 proposer 可以提供
  • inclusion preconfirmations。

  • 基于 L2 的执行 preconfirmations，其中所有 L2 preconfirmed 交易 (1) 需要原始 proposer 的签名，并且 (2) 可以包含在单个 L1 交易中。

    但是，不支持 L1 执行 preconfirmations，因为原始 proposer 无法强制执行排序。

• Proposer 承诺保留提案权。这可以是原始 proposer，也可以是任何购买提案权的 proposer。如果/当一个理性的 proposer 认为他们通过提供 preconfirmations 而不是转售提案权来最大化他们的收入时，就会发生这种情况。关于一个理性的 proposer 在什么情况下会认为他们通过提供 preconfirmations 来最大化他们的收入的问题，已经在 这里 进行了探讨。

只要购买发生在 slot 的提案时间之前（即不是即时的），拥有特定 slot 中提案权的最终 proposer 就可以为该 slot 提供 preconfirmations。

4.2.c. 惩罚和 tips 的有效性

slashing 的有效性将取决于 preconfer 的抵押品要求。虽然这适用于所有 preconfirmation 协议，但尚未决定的关键 APS 问题之一是执行 proposers 的抵押品要求，因此也是 preconfers 的抵押品要求。如果通过 APS 强制执行抵押品要求，则该抵押品可能会被重新用于 proposer 承诺，包括 preconfirmations。无论是否在协议内强制执行对执行 proposers 的抵押品要求，都将存在某种形式的 preconfer 注册合约，以管理 preconfer 权利和 slashing。反过来，这意味着黑名单和基于声誉的 orderflow 限制也将是可能的。

由于 APS 旨在控制/隔离 proposer 中心化的影响，因此 APS 很可能会导致更频繁地选举少数几个可以在各自 APS 拍卖中竞争的 proposers。对于每个 proposer 使用一个地址，这会导致更有效的 orderflow 和黑名单激励。但是，proposers 可以选择创建多个参与 APS 选举的地址，以隔离因执行恶意行为而造成的声誉损失。目前尚不清楚这种策略是否能有效地维持执行恶意行为的 proposer 所拥有的非恶意地址的声誉。这是一个关于声誉机制的 Sybil 抵抗的问题，已经进行了详细讨论。

对此的一些缓解措施包括：

• 要求 APS proposers 维护身份绑定的公钥，用户可以审查和审计这些公钥。身份绑定的密钥是典型的抗 Sybil 措施。
• 允许 APS proposers 在可信执行环境 (TEE) 中运行其区块构建代码，如 这里 和 这里 所述。这最大限度地减少了 proposers 在执行恶意行为方面的攻击面，并可用于为 APS proposers 提供最低声誉。

第 5 节. Enshrined Proposer-Builder Separation (ePBS)

5.1. ePBS 概述

在 PBS (Proposer-Builder Separation) 中，proposer 将构建执行 payload 的权利拍卖给称为builders的复杂实体，以换取 tip。在这种设置中，信标 proposer 和 builder 之间的公平交换——即，确保 proposer 收到 tip 当且仅当他们包含 builder 的 payload 时——由称为relayer的受信任第三方来协调。

在 ePBS (enshrined Proposer-Builder Separation) 中，拍卖是在协议内进行的，从而无需协议外的 relayer 来确保公平交换。信标 proposer 直接收到来自 builders 的 bids，并包含最高 bidder 提交的执行 payload 的哈希值。随后，builder 会揭示完整的执行 payload。与当前的以太坊协议相比，ePBS 引入了额外的 attestation 轮次，其中一个验证者委员会证明 builder 是否正确揭示了 payload。

5.2. Preconfirmation 分析

我们集体检查所有类型的 preconfirmations，因为它们在兼容性以及惩罚和 tip 的有效性方面表现出相似的特征。

兼容性

影响兼容性的关键因素是：

• 通过 ePBS 拍卖 proposer 权利是否是强制性的。
• 信标 proposer 可以指定的、所有参与 ePBS 拍卖的 builders 必须纳入的可强制执行的区块约束的存在。过去曾暗示过这种强制执行机制，但尚未指定确切的设计。一种迫使 builders 遵守 proposer 指定的区块约束的可能机制是强制要求 builders 进行 stake（如 ePBS EIP-7732 中提出的），并 slashing 任何揭示不遵守区块约束的区块的 builder。

如果拍卖 proposer 权利是强制性的并且存在可强制执行的区块约束，则信标 proposers 可以提供所有形式的 preconfirmations（有关哪些类型的强制执行机制能够实现所有类型的 preconfirmations 的具体细分，请参见第 4.2.b 节）。正如第 1 节中提到的，我们不考虑 ePBS builder preconfirmations，因为 builders 不控制独有的提案权。

如果拍卖 proposer 权利是强制性的并且不存在可强制执行的区块约束，则 preconfirmations 不兼容。具体来说，信标 proposer 无法安全地发布 preconfirmations，因为最终赢得拍卖的 builder 没有义务遵守它们。

如果拍卖是可选的，则信标 proposer 保留发布所有类型 preconfirmations 的能力。如果存在可强制执行的区块约束，则 proposer 可以选择构建自己的区块或拍卖构建的权利。如果不存在可强制执行的区块约束，则 proposer 必须构建自己的区块。

惩罚和 tips 的有效性

当拍卖是可选的时，我们预计惩罚和 tips 的有效性与原始以太坊设计中的 preconfirmations 相同。这是因为 preconfers 的选择遵循相同的过程，并且它们具有相同的可用空间来发布 preconfirmations。

在可强制执行的区块约束的情况下，我们还预计兼容的 preconfirmation 设计与原始以太坊设计中的 preconfirmations 具有相似的惩罚和 tips 有效性。关键区别在于可用区块空间量。正如前面章节讨论的那样，减少的区块空间可能会影响每个 slot 中 preconfirmations 的预期奖励，这反过来会影响诸如 orderflow 损失或黑名单之类的惩罚机制的有效性。预期奖励是增加还是减少取决于 tips 是否充分上涨以抵消减少的区块空间。

来源

1. https://www.youtube.com/watch?v=fbyy_IHo-lI&list=PLJqWcTqh_zKHDFarAcF29QfdMlUpReZrR&index=8.
2. https://taiko.xyz/.
3. https://www.surge.wtf/.
4. https://eth-fabric.github.io/website/development/l1-components/urc.
5. https://arbitrum.io/rollup.
6. https://docs.primev.xyz/v1.1.0/concepts/what-is-mev-commit.
7. https://learnblockchain.cn/article/19458.
8. https://www.cs.utexas.edu/~shmat/courses/cs395t_fall04/pagnia.pdf.
9. https://ethresear.ch/t/fork-choice-enforced-inclusion-lists-focil-a-simple-committee-based-inclusion-list-proposal/19870.
10. https://ethresear.ch/t/aucil-an-auction-based-inclusion-list-design-for-enhanced-censorship-resistance-on-ethereum/20422.
11. https://eprint.iacr.org/2025/194.
12. https://learnblockchain.cn/docs/eips/EIPS/eip-7805.
13. https://arxiv.org/abs/2505.13751.
14. https://ethresear.ch/t/uncrowdable-inclusion-lists-the-tension-between-chain-neutrality-preconfirmations-and-proposer-commitments/19372.
15. https://learnblockchain.cn/article/19456/.
16. https://www.youtube.com/watch?v=mJLERWmQ2uw.
17. https://publish.obsidian.md/netbound/Multiple+Concurrent+Proposers%2C+FOCIL+and+Preconfirmations.
18. https://learnblockchain.cn/article/19455.
19. https://lu-ban.notion.site/Multiple-Concurrent-Proposers-IS-Preconfirmation-5ae079060efd4a3395f86a3af53c0572.
20. https://eprint.iacr.org/2020/025.pdf.
21. https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763.
22. https://ethresear.ch/t/based-preconfirmations/17353.
23. https://github.com/ethereum/consensus-specs/pull/4190#issuecomment-2752067885.
24. https://link.springer.com/chapter/10.1007/978-3-642-14577-3_35.
25. https://blog.thirdweb.com/nonce-ethereum/.
26. https://docs.google.com/presentation/d/1C4Iykpf-zNqCE1TyWxDzzw_A7n52GaUJz01Hw5v-NPo/edit?usp=sharing.
27. https://ethresear.ch/t/on-block-space-distribution-mechanisms/19764.
28. https://arxiv.org/pdf/2408.03116.
29. https://arxiv.org/pdf/2408.11255.
30. https://www.youtube.com/watch?v=5OOzMqCOoKM.
31. https://arxiv.org/pdf/2408.03116.
32. https://learnblockchain.cn/article/19457.
33. https://learnblockchain.cn/docs/eips/EIPS/eip-7732.
34. https://ethresear.ch/t/concurrent-block-proposers-in-ethereum/18777.
35. https://ethereum.org/en/roadmap/pbs/.
36. https://ethresear.ch/t/proposers-do-play-dice-introducing-random-execution-auctions-randeas/20938.
37. https://ethresear.ch/t/execution-tickets/17944.

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