当前以太坊共识与 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。
![当前以太坊共识与 MEV 的博弈,要从 PoW 转向 PoS 那天说起……插图 当前以太坊共识与 MEV 的博弈,要从 PoW 转向 PoS 那天说起……](http://www.inohara-mika.com/wp-content/uploads/2024/07/20240726_66a33e0cde083.jpg)
因为还需要解决一些其他问题,比如如何确保 builder 一定会支付费用给 proposer,且一定会在最后向 proposer 披露区块内容从而避免 proposer 不会因提交空白区块而罚没;比如如何确保 builder 提交的区块一定会被纳入信标链等。这些保障 builder 和 proposer 权益的问题,主要通过 relay 来实现。
builder 会将区块发送给 relay,然后 relay 根据每个区块能获得的利润对区块进行排序,再将区块利润最高的区块头发送给 proposer,以此来确保 proposer 对区块内容不可见。在 proposer 对区块提议作出承诺(对该区块头签名)后,relay 才会将完整区块披露给 proposer。builder 支付给 proposer 的费用也需借助 relay 才能确保完成。支付给 proposer 的交易被包含在提交的区块中,但由于 proposer 无法看到区块内容,依旧需要由 relay 提前帮忙确认。
![当前以太坊共识与 MEV 的博弈,要从 PoW 转向 PoS 那天说起……插图1 当前以太坊共识与 MEV 的博弈,要从 PoW 转向 PoS 那天说起……](http://www.inohara-mika.com/wp-content/uploads/2024/07/20240726_66a33e0d23882.jpg)
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 也拥有一定的规则制定权。
![当前以太坊共识与 MEV 的博弈,要从 PoW 转向 PoS 那天说起……插图2 当前以太坊共识与 MEV 的博弈,要从 PoW 转向 PoS 那天说起……](http://www.inohara-mika.com/wp-content/uploads/2024/07/20240726_66a33e0d7f142.jpg)
![当前以太坊共识与 MEV 的博弈,要从 PoW 转向 PoS 那天说起……插图3 当前以太坊共识与 MEV 的博弈,要从 PoW 转向 PoS 那天说起……](http://www.inohara-mika.com/wp-content/uploads/2024/07/20240726_66a33e0db7d55.jpg)
数据来自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 的职责则是提议信标区块。具体流程如下:
- 在知道被选为 Proposer 后,制作并广播 Inclusion List(IL,即在该 slot 中必须包含的交易)。
- builder 们将包含了 execution payload 的区块哈希以及愿意支付给 proposer 费用的承诺「SignedExecutionPayloadHeader」发送给 proposer(execution payload 需满足 IL)
- proposer 从 builders 发来的「SignedExecutionPayloadHeader」中选择一个将其纳入(通常会选支付给 proposer 价格最高的那个)。并广播提议的信标区块「SignedBeaconBlock」。
- 见证者履行见证职责
- Aggregators 提交 attestation aggregates;同时,builder 广播 execution payload
- 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 提供高额回报。