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

在以太坊合并以前，解决 MEV 的方式是通过使用 Flashbots 开发的 MEV-Geth，MEV-Geth 是一种经过修改的 go-ethereum 客户端。其核心理念是让矿工专注于其本职工作挖矿，而非参与 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。MEV-Boost 被诟病最多的地方在于其中心化的 relay 市场。但这种设置引入了信任问题。builder 需要相信 relay 不会窃取他们的 MEV。proposer 也必须相信他们从 relay 收到并签署的区块头是有效的。然而，尽管发挥着至关重要的作用，中继却没有任何经济激励，并且运行 relay 也需要一笔不小的开支。去年，还有 11 个 relay 为以太坊网络提供支持，但如今，只有 9 个 relay 还在提供服务。 不论是出于解决 relay 中心化的问题，还是为了将协议外的部分移至协议内， 将 PBS 封装进以太坊的 ePBS 似乎成了一个必选项。目前，ePBS 已不再是讨论中的提案了，以太坊 EIP 编辑已经为其分配编号 ——EIP-7732。ePBS 为 proposer 和 builder 提供了一个无需信任的基础设施，以供他们来完成区块构建权的外包。原本在协议外的 builder 的角色被纳入了协议内，即验证者中多拆分出一个 builder 的角色，作为验证者的 builder 也需要在以太坊完成质押。由于将共识层原本 proposer 的职责进行了拆分，因此完成 ePBS 需要对共识层进行改动。其中，builder 负责构建 execution payload（该区块中要被执行的交易的最终列表）。proposer 的职责则是提议信标区块。 当然，也有不赞同 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 出售的是可编程的区块构建权。\n原文链接