TL;DR

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

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

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

PayloadTimelinessCommittee（PTC）作为监督作用，确保新区块中的交易内容及时性与有效性。前言

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

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

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

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

Builder想要购买构建区块的权利必须信任中间人。ePBS的革命性设计内置提议者-构建者分离

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

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

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

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

Builder：构建区块的具体内容兩大好處直接惩处恶行和无需授信第三方

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

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

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

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

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

*传统PBS與ePBS的比較圖

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

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

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

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

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

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

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

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

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

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

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

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

缺失块（missingblock）：空的slot。在Blockchain中预期存在但未被创建或未被成功添加到链上的区块。可以通过（block,slot）forkchoice投票，缺失区块可以被分为满块或者是空块。ePBS的抗审查性实现，结合InclusionList的设计

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

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

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

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

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