信任危机实验：探索ePBS协议内置机制的优势与挑战

Table of Contents

TL;DR

ePBS的核心设计理念聚焦于提升Builder的安全性，通过赋予Builder对区块交易的完整控制权来实现这一目标。作为将PBS直接整合进以太坊共识层的提案，ePBS也被称为In-Protocol PBS，其诞生旨在解决潜在的中继故障问题并消除系统中的单点故障风险。在保持原有PBS框架的基础上，ePBS通过削弱单一实体对区块内容的控制能力，进一步增强了网络的抗审查特性和去中心化程度。其中，Payload Timeliness Committee（PTC）扮演着关键监督角色，确保新区块中交易内容的及时性和有效性。

前言

今年2月，Prysm开发者Potuz针对以太坊主网存在的信任问题提出建议，主张将Electra分叉推迟至2025年，以便通过Interop event进一步完善ePBS的设计方案。然而，以太坊社区对ePBS的看法存在分歧，部分开发者和研究人员对其潜在风险表示担忧。面对这些不同声音，我们有必要深入了解ePBS究竟是什么？它与传统PBS有哪些本质区别？

此前我们讨论过PBS机制如何确保Proposer承诺的安全性和Builder解释的安全性，这一机制依赖于可信中继的角色。中继负责保管区块内容，确保Proposer能够获取区块内容但无法轻易窃取Builder的劳动成果。然而当中继存在恶意行为时，Proposer和Builder都将遭受损失，此时他们只能寄希望于其他中继的可靠性。这种机制本质上仍需要依赖可信第三方，因为PBS属于协议外的解决方案，其运行依赖于社区共识和自愿遵守，需要额外的协调和信任机制。

在PBS框架下，中间人角色作为可信第三方不可或缺：Proposer若想出售区块内容的权利必须信任中间人，同样Builder想要购买区块构建权也必须依赖中间人的诚信。

ePBS的革命性设计

内置提议者-构建者分离

Enshrined Proposer-Builder Separation（ePBS）作为PBS的演进版本，是将提议者-构建者分离机制直接写入以太坊共识层的提案，因此也被称为In-Protocol PBS。这一设计的初衷是为了应对潜在的中继故障并消除系统中的单点故障风险。作为一种创新的共识机制，我们将深入解析ePBS的核心原理、优势及其与传统PBS的关键区别。

ePBS的本质是以太坊协议内置的机制，旨在用协议本身取代需要被信任的Relay角色。当Proposer或Builder出现恶意行为时，将由以太坊协议直接实施惩罚（如罚没机制），而不再需要依赖特定角色的诚信。这正是ePBS与传统PBS协议最根本的区别所在。

在角色分离方面，ePBS延续了PBS的基本框架，通过限制单一实体对区块内容的控制权，有效提升了区块链网络的抗审查能力和去中心化水平。其中Proposer负责区块提议（包括区块头信息），而Builder则专注于构建区块的具体内容。

两大核心优势

直接惩处机制与去信任化设计

从名称中的”Enshrined”一词即可看出，ePBS通过将协议内置化实现了两大突破：一是建立了直接的作恶行为惩罚机制，二是从根本上改变了信任模型。

在传统PBS中，作恶行为的识别和惩罚需要依赖第三方（如validator、relay等）的介入。而ePBS由于采用协议内设计，系统本身就能直接识别和处理违规行为。更重要的是，PBS需要依赖外部治理或第三方机构，存在信任中心化的风险；相比之下，ePBS将规则写入协议底层，大幅降低了对第三方信任的需求，显著提升了系统的去中心化程度。

*传统PBS与ePBS对比图表

	PBS（提议者-构建者分离）	ePBS（内置提议者-构建者分离）
协议内/外	协议外	协议内
作恶行为处理	依赖第三方来识别和惩罚	协议本身具备识别和处理能力，可直接施加惩罚
信任需求	依赖外部治理或第三方，存在信任中心化风险	减少了对外部第三方的信任需求，提高去中心化
去中心化程度	低，存在中心化治理的影响	高，所有参与者遵守相同的协议内规则

ePBS运行机制

执行层与共识层的协同

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

来源：ethresearch，一个ePBS slot将由CL（共识层）与EL（执行层）共同处理。区块信息首先在共识层广播，随后提交给执行层进行验证。

具体流程包括：Builder启动竞价并将报价发送给Proposer；Proposer选择报价并决定是否使用Inclusion List构建区块内容后广播区块；验证者根据验证结果进行投票；聚合证明由Aggregators创建，他们将多个验证者对同一区块的证明进行聚合；Builder需在规定时间内公开完整的执行有效负载（Execution Payload）；PTC作为特别委员会监督验证Builder的payload是否及时有效；最终，下一个slot的Proposer根据PTC投票结果和聚合证明决定构建完整块或空块。当区块获得足够多的及时发布票数时，将被认定为满块。

PTC：确保交易及时性的监督者

Payload Timeliness Committee（PTC）即”有效负载及时性委员会”，其主要职责是确保新区块中的交易内容能够及时准确地被纳入。该委员会由521名验证者组成（从信标链委员会中抽调），他们在每个区块创建周期结束前检查Builder是否按时完成了区块交易填充工作，并确认这些交易符合执行规则。

简而言之，PTC就像是一个质量监督团队，确保Builder按时提交符合要求的区块。通过投票机制，PTC直接影响区块被认定为”完整块”或”空块”的状态。当PTC确认负载的及时性和正确性后，该区块将被标记为”完整块”；若负载缺失或延迟提交，则可能被标记为”空块”。基于PTC的投票结果，网络将直接对Proposer和Builder实施奖励或惩罚，以此激励及时准确的区块构建行为。

在ePBS框架下，区块可分为三种状态：完整块（包含有效payload和及时更新的交易执行状态）、空块（几乎不包含任何交易或只含极少数交易，不更新EL状态）以及缺失块（预期存在但未被成功创建的区块，可通过fork choice投票被分类为满块或空块）。

抗审查设计：Inclusion List的巧妙应用

虽然ePBS设计的核心是保障Builder安全性并赋予其对区块交易的完全控制权，但通过与Inclusion List的结合使用，这一机制能够完美实现抗审查和去中心化的双重目标。

此前我们介绍过CL的工作流程（详情可参阅：https://mp.weixin.qq.com/s/EBzr0ttBLosYnRBNVKF6rg），Proposer会向Builder提供Inclusion List并要求优先处理这些交易。该列表应涵盖所有当前活跃交易，无论是否已在交易池中。只要区块尚有空间，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机制实现时能突破提前承诺费用的限制，这值得我们期待！