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

文章转载来源： Techub News

撰文：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 承担损失。

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 提供高额回报。