当前以太坊共识与MEV的博弈，要从PoW转向PoS那天说起……

撰文：Tia，Techub News

解决 MEV 问题的过程实际上是在重新制定区块空间的分配规则。对于 MEV，相信大家已经不再陌生，但如果想知道一些以太坊 MEV 治理提案究竟在谈论什么，可能依旧需要一些背景资料的补充，因此，本文梳理了自以太坊转向 PoS 后一系列关于治理 MEV 的提案如 PBS、ePBS、PEPC，希望能为大家提供一些背景信息。

PBS（Proposer Builder Seperatioin）

在以太坊合并以前，解决 MEV 的方式是通过使用 Flashbots 开发的 MEV-Geth，MEV-Geth 是一种经过修改的 go-ethereum 客户端。其核心理念是让矿工专注于其本职工作——挖矿，而非参与 MEV 争夺，从而避免可能出现的潜在重组问题。MEV-Geth 的机制很简单，是一个市场化的解决方案，即矿工在打包区块时可根据 searcher 提交 bundle 利润的大小来进行选择。通过这一巧妙的市场化机制，各方在获取利益的同时也形成了一定的约束。虽然 searcher 需要将部分利润分给矿工，但其换来的却是更加安全的不被矿工偷窃的保障。当圈住了 searcher 这一利润的主要来源时，矿工也会被动开始使用 MEV-Geth，并进一步被 MEV-Geth 的机制约束。MEV-Geth 会维护一个矿工的白名单，只有在白名单上的矿工才可接收 searcher 的 bundle。通过对矿工进行信誉约束，即将偷窃 searcher 成果的矿工剔除白名单，则可以防止矿工抢夺 searcher 的 MEV 利润。

但合并后，由于出块方式变为从验证者中随机选取作为 proposer 来提议区块，信誉约束的方式来防止 proposer 抢夺 MEV 就不可行了。

可能的解决方案是让区块内容对验证者不可见。沿着这个思路再进一步完善就是 PBS（Proposer Builder Seperatioin，提议构建分离）。PBS 将作为 proposer 的验证者的职责进一步解构为区块构建和区块提议，将复杂的可能参与利益争夺的构建权外包给 builder，这样一来，proposer 的工作就变得很简单，只需对根据 builder 提交区块的利润大小进行选择来提议区块。

***初，以太坊想要在 merge 的时候将 PBS 嵌入协议内，但由于潜在的复杂性，这一进程就先被搁置了，因此给予了 MEV-Boost 介入到 PBS 的机会。目前，PBS 通过 Flashbots 开发的MEV-Boost来实现。除了 builder 和 proposer，其中还有一个很重要的角色——relay。builder 并非将区块直接发送给 proposer，而是通过第三个角色 relay。

因为还需要解决一些其他问题，比如如何确保 builder 一定会支付费用给 proposer，且一定会在***后向 proposer 披露区块内容从而避免 proposer 不会因提交空白区块而罚没；比如如何确保 builder 提交的区块一定会被纳入信标链等。这些保障 builder 和 proposer 权益的问题，主要通过 relay 来实现。

builder 会将区块发送给 relay，然后 relay 根据每个区块能获得的利润对区块进行排序，再将区块利润***高的区块头发送给 proposer，以此来确保 proposer 对区块内容不可见。在 proposer 对区块提议作出承诺（对该区块头签名）后，relay 才会将完整区块披露给 proposer。builder 支付给 proposer 的费用也需借助 relay 才能确保完成。支付给 proposer 的交易被包含在提交的区块中，但由于 proposer 无法看到区块内容，依旧需要由 relay 提前帮忙确认。

In protocol & out protocol

为了能参与到 MEV-Boost 构建的市场中去，验证者需要在运行以太坊共识客户端和执行客户端的同时，再运行一个第三方的非以太坊的 MEV-Boost 程序。这就是目前所运行着的 PBS 神奇的之处，它让协议外的第三方参与到了以太坊的共识形成的规则设计中。从所有权的角度来看，这是匪夷所思的。

这也引发了对协议机制「可信度」的思考，可信度是如何被加强的以及又是如何通过其他机制被侵蚀的。MEV-Boost 就是一个很好的例子，因为可能存在外部协议会对现有机制进行更改的情况。当协议本身开始出现滞后性时，这种更改可能就会从外部开始萌发，外部机制的萌发一定是契合目前的市场需求的，但是外部机制是否可信，是否经过严密设计以防止潜在问题的出现，甚***外部机制可能会破坏协议，这都尚未可知。

中心化的 Relay

MEV-Boost 被诟病***多的地方在于其中心化的 relay 市场。但这种设置引入了信任问题。builder 需要相信 relay 不会窃取他们的 MEV。proposer 也必须相信他们从 relay 收到并签署的区块头是有效的。然而，尽管发挥着***关重要的作用，中继却没有任何经济激励，并且运行 relay 也需要一笔不小的开支。去年，还有11 个 relay 为以太坊网络提供支持，但如今，只有 9 个 relay 还在提供服务。

值得注意的是，relay 并不是无需准入的，如Eden 这样的 relay 就只中继自己的 builder。还有一些 relay 如 bloXroute 则声称会过滤掉抢跑和三明治攻击相关的交易。从某种程度上来说，relay 也拥有一定的规则制定权。

数据来自Rated Network

并且，从 Liveness 的角度来看，由于 relay 的存在，builder 与 proposer 之间无法提供原子级别的确认。假如当 proposer 对区块头签署了 commitment，并且 builder 也提供了 payload 内容，但由于 relay 的失误（无论是恶意还是非恶意的）而无法及时提交该内容，都会使 builder 和 proposer 承担损失。

(WEEX交易所官网：www.weex.com)

ePBS：将 PBS 封装进以太坊

不论是出于解决 relay 中心化的问题，还是为了将协议外的部分移***协议内， 将 PBS 封装进以太坊的 ePBS 似乎成了一个必选项。目前，ePBS 已不再是讨论中的提案了，以太坊 EIP 编辑已经为其分配编号——EIP-7732。

ePBS 为 proposer 和 builder 提供了一个无需信任的基础设施，以供他们来完成区块构建权的外包。原本在协议外的 builder 的角色被纳入了协议内，即验证者中多拆分出一个 builder 的角色，作为验证者的 builder 也需要在以太坊完成质押。由于将共识层原本 proposer 的职责进行了拆分，因此完成 ePBS 需要对共识层进行改动。其中，builder 负责构建 execution payload（该区块中要被执行的交易的***终列表）。proposer 的职责则是提议信标区块。具体流程如下：

1. 在知道被选为 Proposer 后，制作并广播 Inclusion List（IL，即在该 slot 中必须包含的交易）。

2. builder 们将包含了 execution payload 的区块哈希以及愿意支付给 proposer 费用的承诺「SignedExecutionPayloadHeader」发送给 proposer（execution payload 需满足 IL）

3. proposer 从 builders 发来的「SignedExecutionPayloadHeader」中选择一个将其纳入（通常会选支付给 proposer 价格***高的那个）。并广播提议的信标区块「SignedBeaconBlock」。

4. 见证者履行见证职责

5. Aggregators 提交 attestation aggregates；同时，builder 广播 execution payload

6. PTC（Payload Timeliness Committee，每个 slot 中，都会有 512 个验证者会被选为 PTC 成员）检查 builder 是否及时揭示 execution payload，并对结果进行广播

ePBS 从提出到***终获取 EIP 编号中间也经历了多次讨论。***初 PBS 由 Vitalik在 21 年 6 月提出，4 个月后完善了Two-slot这一方案，又过了 3 个月，推出了Single-slot PBS，直到 23 年 7 月，PTC的想法才被正式提出。

PEPC（Protocol-Enforced Proposer Commitments）

当然，也有不赞同 ePBS，希望用其他方案来代替的。PEPC 就是如此。ePBS 是将一种确定的规则嵌入协议之中，但在 PEPC 这里，proposer 出售的是可编程的区块构建权。

PEPC 是 barnabe 在 2022 年 10 月提出的。barnabe 认为，如果要将 PBS 机制放到协议内来实现，应当考虑实现一种用于可信信号传递的通用机制，而不是实现某一特定可信信号的机制（比如如果让我构建区块的话我会返还给你 xx ETH）。

就像 PEPC（Protocol-Enforced Proposer Commitments）的名字一样，一些确保 builder 以及 proposer 权益的机制是通过 proposer 在协议内提交的 commitment 来完成的，这些 commitments 是能够在链上进行验证的，主要由操作码 「BEACONROOT」来实现。这是一个更通用的机制，commitment 可以是将区块构建权全部外包，也可以是只外包一部分区块，即 proposer 出售的是可编程的区块构建权。

小结

以上就是对于 PBS、ePBS、PEPC 的简单介绍。从协议设计的角度，不仅需要设计一个重新分配 MEV 的市场机制，同时还需要考虑如何才能使验证者更加去中心化，以及如何才能提高抗审查性。并且，协议的设计中还存在很多取舍。拿已经获取 EIP 编号的 ePBS 来举例，虽然 ePBS 的设计解决了中心化 relay 这一难题，但作为协议外第三方 relay 这一关键角色真的只有负面影响么？就从 builder 的支付机制来看，使用 relay 反而更优于 ePBS 机制，因为 ePBS 是预付费机制，如果 builder 打包了一个超高利润的区块，那么在预付费机制下将无法向 proposer 提供高额回报。