当前以太坊共识与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 承担损失。

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, 즉 이 슬롯에 반드시 포함되어야 하는 거래)를 만들어 방송합니다.

2. 빌더는 실행 페이로드와 제안자에게 지불하겠다는 약속 "SignedExecutionPayloadHeader"이 포함된 블록 해시를 제안자에게 보냅니다(실행 페이로드는 IL을 충족해야 함)

3. 빌더가 보낸 제안자 중 하나를 선택합니다. "SignedExecutionPayloadHeader"를 포함합니다(보통 제안자에게 지급되는 가격이 가장 높은 것이 선택됩니다). 그리고 제안된 비콘 블록 "SignedBeaconBlock"을 방송합니다.

4. 증인은 증인 임무를 수행합니다

5. 집계자는 동시에 증명 집계를 제출하고 빌더는 실행 페이로드를 방송합니다

6. PTC(페이로드 적시성 위원회), 각 슬롯에서 512명의 검증자가 PTC 회원으로 선택됩니다. 빌더가 실행 페이로드를 적시에 공개하고 결과를 방송하는지 확인하세요

ePBS도 제안 시점부터 최종 EIP 번호까지 많은 논의를 거쳤습니다. 처음에는 6월 21일에 Vitalik이 PBS를 제안했고, 4개월 후에는 2슬롯 솔루션이 개선되었습니다. 또 3개월 후에는 7월 23일이 되어서야 PTC의 아이디어가 공식적으로 제안되었습니다. .

PEPC (Protocol-Enforced Proposer Commitments)

물론 ePBS에 동의하지 않고 대신 다른 솔루션을 사용하기를 희망하는 사람들도 있습니다. PEPC가 그렇습니다. ePBS는 프로토콜에 특정 규칙을 포함하지만 여기 PEPC에서는 제안자가 프로그래밍 가능한 블록 구성 권한을 판매합니다.

PEPC는 2022년 10월 barnabe가 제안했습니다. barnabe는 PBS 메커니즘이 프로토콜 내에서 구현되려면 특정 신뢰할 수 있는 신호 메커니즘(예: 블록 구축을 요청받은 경우)을 구현하는 대신 신뢰할 수 있는 신호 전송을 위한 일반적인 메커니즘을 구현하는 것을 고려해야 한다고 믿습니다. xx ETH를 반환합니다).

PEPC(Protocol-Enforced Proposer Commitments)라는 이름처럼, 프로토콜 내에서 제안자가 제출한 약속을 통해 구축자와 제안자의 권리와 이익을 보장하는 일부 메커니즘이 완성됩니다. 주로 작업 코드 "BEACONROOT"를 통해 달성합니다. 이는 보다 일반적인 메커니즘으로, 모든 블록 생성 권한을 아웃소싱하거나 블록의 일부만 아웃소싱할 수 있습니다. 즉, 제안자는 프로그래밍 가능한 블록 생성 권한을 판매합니다.

요약

以上是当前以太坊共识与MEV的博弈，要从PoW转向PoS那天说起……的详细内容。更多信息请关注PHP中文网其他相关文章！