作者 | Vitalik Buterin
特别感谢 Justin Drake 和 Flashbots 团队的反馈和讨论。
对现在运行中的去中心化共识网络的一个重大威胁是关于矿工可提取价值 (miner extractable value) 的经济学，即从选择下一个区块内容的能力中提取利润的复杂技巧。一个简单的 MEV 例子是根据前一个区块的价格变动在所有链上的去中心化交易所套利。尽管正常情况下 PoS 的奖励是合理的、平均的，即单个验证者的回报率跟强大的质押池是一样的，但现在找寻复杂的 MEV 提取机会已经形成相当显著的规模经济了。10 倍大的池子就有 10 倍的机会提取 MEV，但池子也需要能够在专有的优化上投入更多，以在每个机会里提取更多的价值。
除了这个问题以外，MEV 也让去中心化的质押池变得更复杂，因为在去中心化质押池里，打包交易和提议区块仍然需要由一个实体来完成，他们可以轻易地秘密提取 MEV，而不在池里分配这些收入。
最为人所知的是解决方案区块提议者 (proposer)/构建者 (block builder)分离。不同于区块提议者自己生成一个收入最大化的区块，他们依赖一个市场，这个市场由外部的区块构建者组成，他们生成包含完整区块内容和给区块提议者费用的交易捆，然后提议者选择包含最高费用的交易捆。这样，区块提议者的选择就被简化为选择费用最高的交易捆，这可以由一个简单算法实现——在一个去中心化池里，它甚至可以在 MPC (多方计算) 里完成，以防止作弊。
本文对如何实现这点提出了一些设计。
本文的想法非常直接地受 2018 年的这篇文章启发：
Optimised proposal commitment scheme 20
提议者/构建者分离的区块提议设计的所需特性
我们会专注的五大所需特性：
无须信任提议者友好性：提议者欺负区块构建者的风险几乎是零，因此区块构建者没有动机偏向链下有声誉的或与构建者有个人关系的提议者 (因为这有可能偏向大型质押池)。
无须信任构建者友好性：构建者欺负提议者的风险几乎是零，因此提议者没有动机偏向链下有声誉或与构建者有个人关系的构建者 (因为这有可能导致新进入市场的构建者不被选择)。
弱提议者友好性：这个机制不应该要求提议者有 (i) 高带宽或其他计算资源， 或 (ii) 高技术水平
不可窃取的交易捆 (bundle)：提议者应该不能接受由区块构建者提议的交易捆，并从中提取交易形成自己的交易捆，从而阻止区块提议者赚取利润 (并可能进一步伤害他们)
LendHub核心开发者：公链的竞争本质上是生态的竞争:金色财经报道，LendHub核心开发者Jason做客金色财经举办的以“星火燎原，Heco能否强势领跑交易所公链”为主题的金色沙龙活动圆桌论坛。
LendHub核心开发者Jason表示，在我看来公链的竞争本质上的生态的竞争。做好公链生态首先要吸引更多赛道的优质开发者参与到生态建设中来。就像投资一样，先要进行基石轮和种子轮的引进，如果投中了一个像AC那样出色的团队，对于整个公链生态会起到燃爆式的效应。所以，先要有一定量的开发者团队加入到公链生态队伍中，我认为公链生态先做好“大而全”是基础，就像Heco一样，先培养“火种”，要让各个赛道都布有火种，这个过程实则就是在为公链生态赋能。星火之所以能燎原，是公链生态中已有一定量的火种的前提下，再加上出现几个具有点燃性的生态项目，进而让公链生态迅速崛起发展。[2021/2/26 17:56:12]
共识层保持简单与安全：从共识层的角度，该机制应该保持安全性不变，最好与现有的区块提议机制一起可以被同一个分析框架。
想法1
区块构建者构建交易捆并发布这些交易捆的捆头 (bundle head)。一个交易捆头包含对交易捆主体 (bundle body) 的承诺 (预期的区块内容)，给提议者的付款信息，以及构建者的签名。
提议者选择提供最高费用的交易捆头 (仅需要考虑交易捆的构建者实际上是否有足够的余额可以支付)。他们对交易捆头签名并发布包含该交易捆头的一个提议。
当看到有签名的提议后，提供打包交易捆头的区块构建者发布完整的交易捆。
此时，分叉选择规则能够做出以下三个判断中的一个 (而不是平常的两个，存在区块 vs. 不存在区块)：
不存在区块提议
存在区块提议但不存在交易捆主体
区块提议和交易捆主体都存在
请注意，在第二种情况下，提议仍然会被打包到链上，区块构建者给提议者的付款也仍会处理 (但区块构建者自己不会获得任何费用或 MEV )。
分析
五项特性中的三项是相当容易呈现的：
区块提议者无条件接收承诺的付款，因此交易捆不能欺负提议者
三个步骤都非常自动化且低带宽，因此这满足弱提议者友好性
提议者不能看到他们要的签名交易捆的信息，因此这满足交易捆不可窃取性。
共识层特性和无须信任提议者友好性这两点比较棘手。这个设计的确会改变分叉选择机制，从两个选项增加到三个，这意味着提议者将不再是这个机制里的最后一个行动者。理论上，人们可以推断如果分叉选择是可以做出决定的，那么这应该没问题，但这仍然是一个具有潜在未知性的重大变更。
区块提议者看不到交易捆的内容，并不能通过窃取交易捆欺负区块构建者，但他们可以对区块构建者发起一种更微妙的攻击。他们可以在 slot 末发布提议，确保证明者 (大概) 能及时看到提议，但区块构建者没有足够的时间发布交易捆主体，因此很有可能证明者来不及看到交易捆主体。这会给区块构建者带来风险，并等于鼓励他们偏向值得信任的提议者。另外，这还给了恶意的大多数机会，重罚那些他们不喜欢的区块构建者。
我觉得有两套方法可以缓解这个问题。
证明者在他们接受提议的最长时间和他们接受交易捆主体的最长时间之间有 2 秒的延迟。如果你信任证明者，这基本解决了问题，尽管区块构建者丢失资金的这个风险仍然存在。另外，还不清楚让证明者以这种方式投票是否有激励作用 (虽然可以想象到会有人通过要求他们对一个 2 秒的可延迟验证函数的提议做证明，强迫他们等待)
如果交易捆的主体没有被打包，提议者只能获得付款的一半 (而区块构建者只需支付一半)。这使得提议者的破坏行为成本很高，但它仍然确保区块构建者破坏的成本也是高昂的 (当两种情况的成本都足够高时，总的来说你就能信任即使是匿名行动者都不会想做破坏行为)。例如，如果一个交易捆的提议者费用是 1，区块构建者获利 1.05：
诚实行为会带来的构建者和提议者收益分别是 0.05 和 1。
提议者或证明者太迟发布，导致仅区块头被接受了，这样构建者和提议者的收益分别是 -0.5 和 0.5。
想法2
区块构建者构建并发布交易捆头。交易捆头包含对内容的承诺、给提议者的付款、以及构建者的签名。
提议者对他们看到的交易捆头进行选择，形成列表，并对列表组成的声明进行签名。
在看到该声明时，被选的区块构建者会发布相应的交易捆主体。
提议者在他们之前承诺的一列交易捆头中选出一个并用它发布提议。
还需要一个新的罚没条件，任何在同一个 slot 里提议不在自己承诺列表里的交易捆头的提议者都会被逐出和被惩罚。
还要注意的是，在第 2 步里，提议者提交的交易捆头列表也可以成为一个对交易捆头进行加密的哈希值列表，其中哈希值都加密到区块构建者的公钥，因此只有构建者知道它们是否被接受了。这会减少 DoS 攻击风险。
同样地，五项特性中的三项式相当容易显示的：
提议者不能窃取交易捆，因为当他们已经把自己限制在一个有限的现有交易捆头集里时，他们只能看到交易捆的主体。
当完整的交易捆没有被打包前，构建者给提议者的付款是不可能成功的，因此提议者也无法在经济上构建者。
共识特性保持不变，因为系统设定仍然是提议者作为机制的最后行动者，共识规则决定的内容没有变更。
在这个情况里，更棘手的两个特性是弱提议者友好性和无须信任区块构建者友好性。对于这个方案的忧虑是恶意区块构建者可以通过制造大量高交易费的提议攻击提议者，但永远不发布这些交易捆的主体。如果提议者对接受的交易捆数有上限，这种攻击可以把所有合法交易捆排除在外，使得提议者没有合法交易捆可以提议打包到区块。如果提议者对接受的交易捆数没有上限，那么可能会有无数个满的交易捆主体 (试想：每个 500 kB) 发送给提议者，这将需要非常大量的带宽。
解决这个难题的一个办法是以某种方式对交易捆头的提交进行速率限制，这不是一个硬性限制。
提交交易捆需要支付一定费用，通过类似 EIP-1559 的机制来调整到某个速率 (例如，每 slot 8 个交易捆)
成为区块提议者需要押金 (无论如何都是必要的，以确保提议者得到报酬)，同时还需要一条规则，如果你发布的交易捆没有被打包，但一个更低价的交易捆被打包了，那么你在接下来的 N 个 slot 都无法提交交易捆。
只有在这种情况也会被扣费：你的交易捆没有被打包，但更低价的交易捆被打包了，因为这种特定情况可能是你作恶了 (或提议者作恶、或是网络状态不好)。
这方面有先例；之前的 ENS 竞拍设有 0.5% 失败者费用，以阻止有人在明显不会赢的情况下出价，以迫使赢家支付更多。
但是，这些技术可能会引入对提议者的信任要求，因此他们需要谨慎处理，对打包交易捆失败的惩罚不能太高。
一个替代方案是允许自由和无限制地发布交易捆主体，但限制主体在在网络层广播。一个简单算法是：
为交易捆得以传播添加一个稍微延迟的最短时间限制：交易价格最高的交易捆是 0 秒，第二高的交易是 0.2 秒，第三高的是 0.38 秒，一般来说对于第 k 个最高交易价格的交易困是 2∗[1−0.9^(k−1)] 秒。
增加一条规则：如果一个节点已经广播了一个更高交易费的交易捆主体，它不能再广播了。
这两项技术可以结合在一起：你可以用一个低价费用来减少预期的交易捆数，比如每个 slot 50 捆，然后使用像这样的网络层机制来进一步减少带宽要求。
结论
到目前为止，我不明确是否唯有上述两种方法能解决这个问题，可能还有其他。在这两种方法里，想法 (1) 在概念上更简单，但它会给区块构建者带来风险，也会引入更复杂的分叉选择规则要求。想法 (2) 在分叉选择和共识上更简单，但在处理恶意区块构建者带来的 DoS 攻击上有困难，且任何解决这个问题的方法都可抗产生其他问题，尽管可以想到将其最小化的方法。到目前为止，我仍然不确定哪一个更好。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。