欧意交易所

欧易OKX下载

欧易OKX交易所

全球前三大交易所！注册可领取最高6万元盲盒奖励，100%中奖！同步注册可辅助进行OTC

点击注册

更多交易所入口

一站式注册各大交易所、点击进入加密世界、永不失联，币安Binance/欧易OKX/抹茶MEXC/火币Huobi入口

点击进入

信任危机实验 ePBS的协议内置

由 ·

TL;DR

  • ePBS 的设计核心是围绕 Builder 安全性而构建的概念，它授予 Builder 对区块交易的完全控制权。

  • ePBS 是将 PBS 直接纳入以太坊共识层的提议，被称为 In-Protocol PBS，旨在应对潜在的中继故障和消除系统内单点故障。

  • ePBS 依旧沿袭原 PBS 的基础，通过降低单一实体对区块内容的控制能力，提高网络的抗审查性和去中心化。

  • Payload Timeliness Committee（PTC）作为监督作用，确保新区块中的交易内容及时性与有效性。

前言

2 月分，Prysm 开发者 Potuz 认为以太坊主网存在信任问题，主张推迟 Electra 分叉至 2025 年，利用Interop event 完善 ePBS 设计。然而，以太坊社区对 ePBS 持有不同意见，部分开发者和研究员担忧其可能带来的风险。对于 ePBS，大家的意见各不相同，今天我们将来了解下 ePBS 是什么？和 PBS 有什么区别？

之前我们提到过 PBS 的机制是为了确保 Proposer 承诺的安全性和确保 Builder 解释的安全性，于是将这个权利交给被信任的中继来承担。中继负责保管区块内容，确保 Proposer 会拿到区块内容但不能轻易偷走 Builder 的区块内容。但如果中继是恶意的，则 Proposer 和 Builder 都会受害，且他们只能转向和其他 Relay 合作并期望其他中继不是恶意的。这里面就存在一个问题，我们必须要找到一个授信第三方从而进行信任委托。因为 PBS 是一种协议外的解决方案。PBS 依赖于社区的共识和自愿遵守，需要额外的协调和信任。

PBS中必须有一个中间人角色作为第三方授信方处理问题：

  • Proposer 若想要出售区块内容的权利必须信任中间人。

  • Builder 想要购买构建区块的权利必须信任中间人。

ePBS 的革命性设计

内置提议者-构建者分离

Enshrined Proposer-Builder Separation（ePBS）内置提议者-构建者分离，是 PBS 衍伸出的又一种变体。ePBS 是一个将 PBS 直接纳入以太坊共识层的提议，于是被又称为 In-Protocol PBS。它的诞生是为了应对潜在的中继故障和消除系统内单点故障的需求。作为一种新兴的共识机制，接下来我们将对ePBS 进行深入解析，旨在阐明其核心原理、优势以及与传统 Proposer-Builder Separation（PBS）的区别。

ePBS，即内置提议者-构建者分离，区块链协议中内置的机制。以 Ethereum 协议来取代这个需要被信任的 Relay 角色，如果 Proposer 或 Builder 任一方作恶，都能由 Ethereum 协议本身来施加惩罚（罚没），而不是必须要仰赖对某个角色的信任。这也是整个协议与之前我们所提到过的 PBS 协议最大的区别和不同。

当然，角色分离在 ePBS 的运用中依旧沿袭原 PBS 的基础，通过降低单一实体对区块内容的控制能力从而提高区块链网络的抗审查性和去中心化程度。

  • Proposer：负责区块提议，包括区块头信息

  • Builder：构建区块的具体内容

兩大好處

直接惩处恶行和无需授信第三方

从名字上观察，就能得知 ePBS 中的 Enshrined 就可以得知因为将协议进行内置的工作，也将会对作恶行为处理做出直接的惩罚，并且信任中心也在该设置下悄然发生转变。

  1. 协议具备识别和处理能力，直接惩处

PBS 中，作恶行为的识别和惩罚需要依赖第三方（validator、relay 等）的介入。而在 ePBS 中，由于其设计在协议内，作恶行为可以直接被协议本身识别和处理。

  1. 无需授信第三方，提升去中心化程度

PBS 在一定程度上依赖于外部治理或第三方，存在信任中心化的问题。相比之下，ePBS 通过将规则写进协议中，从源头减少了对外部第三方的信任需求，提高了系统的去中心化程度。

*传统 PBS 與 ePBS 的比較圖

RDHyMXTJfNP6SbfcG782CBVk1YySWmyA3GS8IgQs.png

ePBS 设计

执行和验证之舞

以太坊 POS 中，slot 的时间被分割成 12 秒的间隔。在每个 slot 中，随机选择一个验证者来提议一个区块。同时，指定一个委员会来验证区块有效性。如果一个区块在给定的 slot 中没有被提议，4 秒后，负责证明的验证者将对前一个区块进行验证。

obaogaduHLXOWe1oGurEddxNRa0WfTSzdShmhe83.png

source：ethresearch，一个 ePBS slot 将会由 CL（共识层）与 EL（执行层）进行处理。区块信息在共识层被广播，接着区块将被提交给执行层进行验证。

  1. 区块竞价阶段：Bulider 将开始竞价，发送给 Proposer。

  2. proposer 广播：Proposer 选择竞价并选择是否运用 Inclusion List 构建自己的区块内容。接着广播区块。

  3. 验证者投票：看到区块后，会根据其验证结果投票。

  4. 聚合证明（ Aggregate attestation）：聚合证明是由聚合器（Aggregators）创建的，他们将多个验证者对同一区块的证明进行聚合。验证者通过聚合证明进行验证。

  5. payload 广播：Builder 需要在规定的时间内公开完整的执行有效负载（Execution Payload）。

  6. PTC 投票：特别委员会，监督和验证 Builder 的 payload 是否及时和有效。

  7. 下一个 slot 的 Proposer 发布他们的区块，根据 PTC 的投票结果和聚合证明构建在完整块或者空块上。当一个区块的 PT 票数中及时发布的百分比更高，那么它将被视为满块。

PTC，监督新区块中的交易内容及时性与有效性

Payload Timeliness Committee（PTC），“有效负载及时性委员会”。主要任务是确保新区块中的交易内容能够及时、准确地被添加进去。这个委员会由验证者组成（从信标链委员会借来的 521 人作为委员会的组成部分），他们的工作是在每个区块创建周期结束前，检查 Builder 是否已经完成了区块的交易填充工作，并且这些交易是按规则正确执行的。

简单来说，PTC就像是一个监督团队，监督 Builder 是否按时提交了他们的工作，是否包含了正确交易的区块。如果 Builder 做得很好，按时提交了符合要求的区块，PTC 会通过投票来确认这一点。这样，网络就能够知道哪些区块是完整和有效的，哪些可能存在问题或者不完整。

通过投票机制，PTC 影响区块是否被视为“完整块”或“空块”的状态。如果 PTC 验证了负载的及时性和正确性，该区块可以被认定为“完整块”状态；如果没有负载或负载提交延迟，区块则可能被标记为“空块”。接着，根据 PTC 的投票结果，网络直接对 Proposer 和 Builder 实施奖励或惩罚，以激励及时和准确的区块构建。

  • 完整块（full block）：区块包含一组有效的 payload，它也可以包含多个交易，并且交易执行状态会及时更新。

  • 空块（empty block）：区块几乎没有包含任何交易，或者只包含极少数交易。它可以是 CL 块，但不会更新EL状态。

  • 缺失块（missing block）：空的slot。在区块链中预期存在但未被创建或未被成功添加到链上的区块。可以通过（block, slot）fork choice 投票，缺失区块可以被分为满块或者是空块。

ePBS 的抗审查性实现，结合 Inclusion List 的设计

尽管，ePBS 的设计核心是围绕 Builder 安全性而构建的概念，它授予 Builder 对区块交易的完全控制权。那么，在这个基础上，运用 Inclusion List 将是一个非常完美能够实现抗审查与去中心化的组合形式。

之前我们的文章中有提到过 CL ，大致讲述下流程（详情可点击链接：undefined。https://mp.weixin.qq.com/s/EBzr0ttBLosYnRBNVKF6rg）Proposer 向 Builder 提供这份列表，需要优先考虑这些交易。它应涵盖所有当前活跃的交易，无论是这些交易是否在交易池中。只要区块还有剩余空间，列表中的交易应被纳入 Builder 的区块。如果区块已满，Builder 应明确标识，并确认他们已经注意到了这份列表。

当 Builder 试图审查某些交易，由于 EIP-1559 的实施，不断用交易去填满的区块会导致 base fee 迅速上升。若此时 Builder 还坚持通过在区块中添加虚假交易来审查，不断增加的费用将使得这种行为成本过高，将变得不再实际。

小结

ePBS 通过协议内置，将提议者和构建者角色分离。通过 PTC 作为证明委员会的一个子集，负责对Builder 发布的 Execution Payload 的有效性与及时性进行投票。其核心优势在于它将传统的信任第三方的角色，转变为由以太坊协议本身来执行监督和惩罚，从而减少了对单一实体的信任需求。不仅提高了系统的抗审查性，还通过 Inclusion List 等机制，增强了对交易的保护，使得审查交易的成本变得高昂而不切实际。

另外声明下， ePBS 只是提供一个协议层级别的区块 Proposer 与 Builder 分离的选项，而不是强制性的，他们最大的区别是支付机制和信任模型。当考虑到整个协议的信任问题时，需要付出的代价是需要提前承诺支付费用。与 ePBS 相比，MEV-Boost 可以根据自己排序的 Execution Payload 中实现的收益来决定支付给 Beacon Proposer 的金额，具有更多的利润和空间。或许有一天 ePBS 的机制实现或许无需考虑提前承诺费用的时候，抱有一点小小的幻想和期待！