迈向链上PBS——一个乐观的路线图

迈向固化的 PBS — 一份乐观的路线图

####### “这是一次延迟的觉醒” - Justin Drake (2023年3月1日)

目的

通过一系列对现有 mev-boost 中继的修改，提出一条迈向固化 PBS (ePBS) 的路线图。通过逐步移除中继的职责，并修剪区块构建pipeline的关键路径，我们的目标是收敛到一个与现有 提议非常相似的ePBS系统。

理由

1. 敏捷性 — 我们的目标是按照 Justin 在 SBC 审查小组 中提出的建议来推进这个协议升级。为了预先进行 R&D工作，我们可以通过试验一部分现有的中继、构建者和验证者来快速迭代，以减少围绕完整 ePBS 的不确定性和风险。 正如 Barnabé 在 Devconnect 和 关于 PBS 的笔记 中强调的那样，ePBS 和 mev-boost 之间存在权衡。该路线图探索了 这两个极端之间的设计空间。
2. 必然性 — 在 Devconnect 上，Vitalik 指出，有了 Danksharding，一些构建者分离变得强制性，因为大型（32 MB）区块的带宽 需求超出了家庭质押者的能力范围。该路线图 使我们能够通过检查不同的机制在实践中如何运作来推进研究讨论。
3. 可访问性 — 通过公开呈现中继数据并设计乐观架构，我们提高了对 现有区块构建市场的可见性。这有助于回答研究问题（例如，来自 Barnabé 和 Caspar 的 ROP-0），并允许独立的中继与垂直整合的构建者-中继保持竞争力。 此外，乐观中继降低了中继保持竞争力所需的硬件和网络 资源，降低了准入门槛。从构建者的角度来看， 乐观构建需要抵押品，但它消除了他们处于 每个连接的中继的高优先级队列中的需求。

我们将“关键路径”定义为构成区块生产pipeline的一组操作和消息，从构建者提交竞价开始。 我们提出了 3 个中继修改的进展，每个修改都减少了与关键路径相关的延迟。

延迟是竞争性区块构建市场中的一种中心化力量。由于 MEV 不断产生和提取，理性的构建者有动力与中继共址，与中继形成信任连接，甚至运行 自己的中继基础设施，以最小化（低至 $\mu s$ 或 $ns$）他们构建区块的时间与该header成为拍卖的一部分的时间。我们相信，通过简化pipeline，我们可以维持一个有竞争力和开放的构建者生态系统，同时努力逐步淘汰所有中继。

今天的区块生产

下图示意了现有 mev-boost 架构下的关键路径。 <table><tr><td> <img width="600" alt="非乐观" src="img/nonopt.png">

1. 构建者向中继提交包含区块完整执行主体的竞价。
2. 中继模拟区块；模拟必须在竞价赢得拍卖之前完成。
3. 提议者将签名header发回中继，中继发布完整区块。 </td></tr></table>

什么是关键路径？

关键路径通过中继运行，中继的任务是

• 通过网络从构建者接收完整区块（这可能是几 MB 的数据，并且会随着 4844 的增加而增加），
• 在将获胜header传达给提议者之前，在内部针对执行节点验证区块，以及
• 接收来自提议者的签名header并发布*区块。

实际上，即使在高性能硬件和良好的网络连接下运行，整个过程也可能需要数百毫秒。

* 请注意，获胜区块会返回给提议者，因此即使中继不发布区块，提议者也应该这样做并有动力这样做。

乐观中继 v1 — “异步区块验证”

下图表示乐观中继 v1 下的关键路径。 这个想法是 提出 和 实施 的；它 也在 MEV 社区电话会议 #0 中讨论过。

<table><tr><td> <img width="600" alt="非乐观" src="img/v1.png">

1. 构建者向中继提交包含区块完整执行主体的竞价。
2. 中继立即将竞价标记为有资格赢得拍卖。
3. 提议者将签名header发回中继，中继发布完整区块。 </td></tr></table>

什么是关键路径？

此流程与之前的流程略有不同；中继不会立即 验证从构建者发送的区块。这导致 构建者向中继提交竞价到该竞价 有资格赢得拍卖之间的时间延迟减少。这有利于构建者和 提议者，因为它允许竞价在slot中稍后到达，从而为双方捕获更多 MEV。在这种设计下，构建者可以不诚实地提交无效区块的高竞价， 最终赢得拍卖，这会导致错失slot（因为提议者 签署了无效header）。或者，EVM 有效区块可以被提议和包含，但不向提议者支付 竞价的价值。我们通过要求构建者向 中继提供抵押品来解决这个问题，如果slot或付款丢失，抵押品将用于退还提议者。有关更多详细信息，请参阅提案、实施和社区电话会议。 此提案应降低运行中继的硬件和网络要求，因为现在无需在slot结束时进行大量突发计算和带宽。

slot的结束非常拥挤，因为所有最高的竞价都在提议者调用getHeader之前的最后几毫秒到达。如果模拟延迟进一步 有利于与中继垂直整合的构建者，则会加剧这个问题。

除了上面提到的实际好处之外，我们还修改了关键路径。现在，中继负责

• 通过网络从构建者接收完整区块（这可能是几 MB 的数据，并且会随着 4844 的增加而增加），
• 将获胜header传达给提议者，以及
• 接收来自提议者的签名header并发布区块。

中继仍然验证它收到的每个区块，但此验证是异步发生的，因此 不再是关键路径的一部分。这展示了本路线图的主要目标 — “减少中继的职责 和关键路径的延迟”。

乐观中继 v2 —“仅header解析”

下图演示了乐观中继 v2 下的关键路径。

<table><tr><td> <img width="600" alt="非乐观" src="img/v2.png">

1. 构建者向中继提交竞价。
2. 中继仅解析传入消息以获取竞价详细信息，然后将竞价标记为有资格赢得拍卖。
3. 提议者将签名header发回中继，中继发布完整区块。 </td></tr></table>

什么是关键路径？

关键路径仍然通过中继运行，中继的任务是

• 仅解析来自构建者的传入消息以获取竞价详细信息（这是几百个字节），
• 将获胜header传达给提议者，以及
• 接收来自提议者的签名header并发布区块。

在这里，我们消除了等待整个区块执行主体 下载到中继的额外延迟（这将随着完整的 Danksharding 变得更加重要）。 这可能会导致来自构建者的无效或丢失区块， 在这种情况下，提议者退款的处理方式与 v1 相同。

这种设计具有额外的实际好处。中继不再能够进行审查，因为当header被解析时，竞价是符合条件的。中继尚未获得有关执行主体中的交易的信息，因此它无法根据这些交易进行审查。

乐观中继 v3 — “中继作为预言机”

下图演示了乐观中继 v3 下的关键路径。

<table><tr><td> <img width="400" alt="非乐观" src="img/v3.png">

1. 构建者向 mempool 提交仅header竞价（可以称为“bidpool”）。
2. 提议者将签名header发回 mempool，构建者发布完整区块。 </td></tr></table>

什么是关键路径？

请注意，现在中继已不在关键路径中！构建者 和提议者直接通过 p2p 层进行通信。我们假设构建者将是 p2p 网络中连接良好的节点，因为它们有动力拥有到提议者的极短 路径，因此消息仍然会很快。

现在，关键路径只是

• 提议者通过 p2p 网络侦听仅header竞价（这是几百个字节），以及
• 构建者通过 p2p 网络侦听与其竞价相对应的签名header。

中继仍然存在于此架构中，但仅在发生丢失slot的情况下充当预言机。中继观察 mempool 并确定是否 (a) 及时生成了签名header，但 (b) 没有及时生成相应的签名区块。在这种情况下，构建者有过错，他们的抵押品再次用于退还 提议者，如 v1 和 v2 中所示。

请注意，提议者付款可以以无条件的方式实施。Alex O. 和 Stephane 已经提出了这样一种机制。这将消除中继直接控制构建者抵押品的需求，并将中继简化为签名区块按时出现的 数据可用性预言机。这里的权衡 是使用智能合约来实现此逻辑的工程复杂性和固有风险。 这很值得在未来投入时间进行研究，但我们估计在短期内， 中继运营商（或 担保人）应手动处理退款。

ePBS — “用委员会替换中继”

下图演示了 ePBS 下的关键路径。

<table><tr><td> <img width="400" alt="非乐观" src="img/v4.png">

1. 构建者向 mempool 提交仅header竞价。 </td></tr></table>

什么是关键路径？

此路线图的最终演变是用验证者委员会替换 v3 中继，并将 PBS 固化到协议中。该机制的细节 可能会有所不同；Vitalik 提出了单slot 和 双slot。 在双slot实施（目前似乎是最流行的）下， 提议者选择一个header以包含在其信标区块中，并在其slot中发布它。 一个委员会证明了这个区块，一旦构建者确信该区块 不会被重组，他们就会在后续slot中发布一个包含完整执行负载的中间区块。其余委员会证明了这个中间区块。诚实行为的执行 已实施到分叉选择规则中，因此如果构建者生成一个 与获胜header不同的区块，委员会成员 simplemente 不会证明它。

第一个委员会证明 签名header的及时发布，其余委员会证明签名区块的及时发布，这正是 中继在 v3 中侦听的一组动作。

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