?以太坊很快将从 PoW 过渡到 PoS 共识协议。开发者们已经致力于实现这一转变数年时间，并且分多个步骤进行。第一步是在 2020 年 12 月推出信标链，当前信标链现在已经上线，在撰写本文时，信标链上已经有超过 16 万名个验证者 (validators)，相当于质押了约 500 万 ETH。

第二步「大合并」可能会在 2022 年初发生。虽然在这一步之外还有很多细节需要解决，但关于 PoS 以太坊 (即 eth2) 已经有足够多的细节被解决，这就允许我们能够推断出最大可提取价值 (MEV，即 Maximal Extractable Value，旧称为"矿工可提取价值") 在 eth2 中的情况。

在本文中，我们将研究 eth2 中的交易排序，并分析由 MEV 价值提取而带来的验证者收益增长。我们发现，MEV 将显著提高验证者获得的奖励，但也可能会加剧 eth2 参与者之间 (收益) 的不平等。我们还将讨论 eth2 中 MEV 的定性方面，比如交易所和验证者池 (即质押池) 等最大利益相关者之间的潜在动态。

eth2 概述

目前以太坊的共识由运行挖矿硬件的矿工们实现，这些硬件被优化以更好地解决 PoW 挑战。而从 PoW 共识到 PoS 共识的转变意味着以太坊网络将由验证者 (而非矿工) 来保护，每个验证者节点需要质押 32 ETH 的保证金，并通过投票以达成对信标链状态的共识。验证者这样做有着经济上的激励，即验证者的良好行为将获得奖励，而离线或者恶意行为将受到惩罚 (罚没)。

目前，信标链与 eth1 链并行运行，自 2020 年 12 月以来信标链一直在成功地在运行中。“大合并”将使得信标链与当前的 eth1 链合并。在本文中，我们将使用「eth1」来表示包含区块和交易的以太坊执行引擎；使用「信标链」来表示 eth2 新的底层 PoS 共识机制；使用「eth2」来表示合并之后的以太坊权威链，这条链包括了 eth1 执行引擎和用于实现共识的信标链。

eth2 以 6.4 分钟 (称为一个 epoch) 的增量达成共识。每个 epoch 包含 32 个 slot，每个 slot 时长为 12 秒，每个 slot 都代表了一个区块被添加进信标链的机会。在正常运行的情况下，每个 slot 都会产生一个区块，但是诸如验证者离线等原因将可能导致某些 slots 产生 0 个区块。

对于每个 epoch，所有验证者都是被伪随机地分配去提议区块 (propose block) 或者对由其他验证者提议的区块进行证明 (attest to blocks)，提议区块的验证者称为「提议者」，证明区块的验证者称为「证明者」。每个 slot 期间仅会有 1 名提议者和多名证明者，这些证明者将负责证明该区块中的所有信息，包括来自 eth1 的数据和来自信标链的数据。证明者通过对信标链的“三个方面”的当前值 (current values) 进行正确地投票来获得奖励，这三个方面分别是：区块链的链头 (即顶端区块)、被证明的检查点以及被敲定的检查点。

eth2 中的 MEV

MEV (最大可提取价值) 是区块提议者通过对他们提议的区块内的交易进行重新排序、审查或者加塞交易，从而获得的所有可能的价值。为了理解 eth2 中的交易排序，我们首先来了解一下被用来对交易进行排序的软件 (即 eth2 客户端) 的内部工作原理。

1. eth2 客户端

由于 eth2 本质上是合并在一起的两条链 (即 eth1 链和信标链)，因此 eth2 客户端由两个「子客户端」(sub-clients) 组成也就不足为奇了：其中一个是执行引擎客户端，另一个是共识客户端。值得注意的是，当前的 PoW 以太坊客户端 (即 eth1 客户端) 将继续存在于 eth2 中，并与信标客户端一起运行，彼此分工不同。

其中，eth2 中的 eth1 客户端是对当前的 PoW 以太坊客户端剥离掉其共识职责，而仅专注于 eth1 链的交易池、eth1 执行和 EVM；而信标客户端负责共识和分配验证者的职责 (比如对信标区块的证明和提议)。这两个客户端并行运行，各自维护自己的 p2p 网络堆栈 (信标客户端维护 libp2p，eth1 客户端维护 devp2p)。

eth2 客户端可能看起来就像下图这个经修改的示意图 (源自 Danny Ryan 撰写的文章 [1])

图1

2. eth1 的区块提议

正如在当前的 PoW 以太坊中一样，eth2 中的 eth1 客户端将维护一个本地的交易池 (mempool)，其中包含了来自其 p2p 网络中接收到的交易。正如 Rayonism 规范 [2] 中所描述的，信标客户端将与 eth1 客户端交互，从而形成一个 eth1 区块。虽然该规范中的 (两个客户端之间的) 通信途径细节可能会在生产中发生变化，但大致的方式很可能会保持一致：

• 经过多次来回，信标客户端向 eth1 客户端查询其通过 eth1 交易池形成的某个 eth1 区块，检查该区块是否满足各种有效性条件；

• 一旦这个 eth1 区块被信标客户端接收，并且满足了各种有效性检查，则该 eth1 区块将被提议者 (proposers) 打包进当前的信标区块中，并成为证明者 (attesters) 要投票的数据的一部分。

• 然后信标客户端将要求 eth1 客户端把 eth1 链的链头 (即顶端区块) 更新为这个最新被打包的 eth1 区块；

• 一段之间之后，这个包含了该信标区块的epoch 会被敲定 (finalized)，然后信标客户端将告知 eth1 客户端这个 eth2 区块已经在共识层被敲