EIP-7732：链上提案者-构建者分离

EIP-7732: 写入式提议者-构造者分离

EIP-7732 或 ePBS 的工作概念验证的实现。

动机

目前在以太坊中，提议者-构造者分离或 PBS 由诸如 mev-boost 之类的第三方软件和链下中继网络来处理。提议者-构造者分离（PBS） 的引入是为了将区块提议与区块构造分离。PBS 通过允许区块提议者出售其构造区块的权利来实现 MEV 的民主化，从而为区块构造者创造市场。mev-boost 是由 Flashbots 构建的 PBS 的链下实现，已被广泛采用，约占 90% 的以太坊区块的生产。

理想情况下，提议者希望他们承诺的交易捆绑包能够安全地交付并获得报酬，而构造者希望他们的捆绑包能够避免抢跑交易。中继位于提议者和构造者之间，充当双方信任的拍卖人。由于缺乏足够的激励来运行中继，我们正在见证另一种中心化力量。在过去的两周里，只有五个中继产生了大约〜94% 的已提议的总区块。

为什么要写入 PBS

参考 potuz 的这篇 文档，以太坊中当前 PBS 实现的主要问题如下：

1. 想要出售其构建 payload 权利的提议者必须信任中介。
2. 想要购买构建 payload 权利的构造者必须信任中介。

这个问题至关重要，因为依赖中介会带来多种风险。信任中介可能导致审查、垄断和单点故障。通过消除对这些受信任中介的需求，我们可以增强抗审查性，确保没有任何单一实体可以控制或影响哪些交易包含在区块中。此外，它还促进了去中心化，这是区块链的核心原则。请注意，EIP-7732 纯粹侧重于共识层的更改，并结合了用于 ePBS 的区块拍卖设计。

原始项目提案

ePBS 的实现从根本上说是为了解决信任问题，而不是关于交易排序或 MEV（最大可提取价值）。MEV 方面的考虑，例如 MEV 窃取和分叉选择攻击，并不是这里问题的核心。

目前，以太坊中的大多数信标区块提议者都依赖第三方构造者来为其区块构造执行 payload。他们从构造者那里请求一个 哈希树根 (HTR)，并将一个 SignedBlindedBeaconBlock 提交给一个受信任的方，然后该方在广播之前将 HTR 替换为完整的执行 payload。此过程需要信任中介。

EIP-7732 引入了一种无需信任的方法来进行这种交换，确保诚实的提议者获得报酬，并且诚实的构造者的 payload 成为链的规范头部，而不管对方的行为如何。

验证者有一个短暂的时间窗口（以太坊主网上为 4 秒）来验证共识和执行状态转换，检查 blob 数据的可用性，并评估区块链的新头部。通过分离验证任务，验证者只需要立即执行共识状态的转换，将执行和数据可用性验证推迟到以后。

此更改通过从共识区块中删除执行 payload 来加快网络传播。它降低了由 blob 交易引起的重组风险，并防止验证者错过证明。此外，它消除了区块构造委托中对受信任中间件的需求。

<figure>

<figcaption>

potuz 演讲中的 ePBS Slot

</figcaption> </figure>

规范

该实现将遵循 EIP-7732 中提到的规范。

该规范引入了一个新的质押参与者，称为 构造者，以及新的诚实验证者职责，称为 payload 及时性证明。

以太坊协议中的Slot分为四个间隔：

• 诚实验证者将从构造者那里收集签名投标 (SignedExecutionPayloadHeader)，并提交带有这些投标的共识区块 (SignedBeaconBlock)。
• 对于第二部分，诚实验证者提交证明，类似于当前的过程。
• 对于第 3 个间隔，聚合器聚合这些证明，构造者广播完整的 payload 或一条指示他们正在保留它的消息 (SignedExecutionPayloadEnvelope)。
• 对于第 4 个间隔，一些被选为新的 Payload Timeliness Committee (PTC) 的验证者证明构造者的 payload 的存在和及时性。

在任何给定的Slot，区块链的头部状态可以是：

• 如果当前Slot的提议者未提交区块，则为前一个Slot的区块。
• 如果提议者提交了区块但构造者未及时显示 payload，则为当前Slot的空区块。
• 如果提议者和构造者都及时显示了，则为当前Slot的完整区块。

有各种各样的软件包，需要进行重大更改，包括但不限于 sync、core、beacon-apis for builder、forkchoice、engine api 和 blockchain 等。此外，还有许多辅助函数，一旦实现了可用的 PoC，我们将转向网络软件包，以进行实际的 p2p 拍卖和投标的 gossiping。

在队列的最后，francesco 提出了一个新的简化的分叉选择设计。有关该设计的更多详细信息，请参阅 此处 的文章。

路线图

7 月：我们将花费前几周的时间直接实现辅助函数，这将有助于我们开始并使用 Prysm 代码库。 这也将帮助我们避免仅为了开始并理解流程而研究大型软件包的代码库。

8 月（4 周）：遵循并实现规范中提到的软件包。我们将专注于信标链软件包，以测试提议者-构造者分离是否适用于单个验证者。 此期间旨在构建 MVP 或可用的 PoC，以了解根据 ePBS 的区块拍卖设计，及时性将如何工作。

9 月（4 周）：PoC 实现的 2 周缓冲区，以及 PoC 功能测试的 2 周。

10 月（4 周）：一旦我们有了可用的 PoC，我们就可以专注于实现 ePBS 的网络部分，这将包括为 PTC 和构造者编写新的主题，如果需要，实现构造者软件包，测试我们已实现的任何部分。

11 月（2 周）：最终清理和 devcon 的演示准备

注意：时间表是暂定的，可能会根据完成的工作而变化。 此外，我们还在研究员之间举行每周会议以跟踪进度，并在需要时与导师一起举行。 该项目的方法将更多地是弄清楚事情，实现，异步交流和参与代码审查。

可能的挑战

• 我认为有效分配任务以及与其他研究员的协调将具有挑战性。 将需要积极的沟通，以避免在单个问题上进行双重工作。

项目目标

该项目的目标是在 devcon 之前为 ePBS 实现一个功能齐全且可用的 PoC，这将包括对于单个验证者：

• 提议者可以从构造者那里请求 payload 的投标。
• 构造者可以执行各种职责，例如提供 signedExecutionPayloadHeader 或指示保留 payload 等的消息。
• 对我个人而言，体验开发过程并在核心开发人员的指导下学习，并观察 EIP 实现的生命周期。

合作者

研究员

• Caleb
• Kira
• Amaan
• Jihoon

导师

• Potuz
• Terence

资源

• EIP-7732
• ePBS Spec
• ePBS design constraints
• WIP ePBS PR in the Prysm repo
• ePBS specification notes
• ePBS Forkchoice annotated spec
• ePBS Annotated Validator Spec
• Payload boosts in ePBS
• All-in-one fork-choice rule

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