特别感谢 Justin Drake 以及 Flashbots 团队给予的反馈和讨论。
威胁共识网络持续去中心化的一个主要风险是围绕矿工可提取价值（MEV）的经济学，这是从选择下一个区块内容的能力中获取利润的复杂技巧。列举一个简单的 MEV 示例：针对自上一个区块以来发生的价格变动对所有链上去中心化交易所进行套利。虽然一般的 PoS 奖励是相当平等的，因为单一验证器的回报率与强大的验证池相同，但在寻找复杂的 MEV 提取机会方面，存在着显著的规模经济性。简单说，一个规模大 10 倍的池子就拥有 10 倍的机会来提取 MEV，并且它可以花费更多的精力来进行优化，以从每个利润机会中提取更多。除了这个问题之外，MEV 还使得去中心化池复杂化，因为在去中心化池子中，仍然需要一个实体来负责打包并提出区块，并且他们可以轻松地秘密提取 MEV，而无需和池子本身分割收入。
最出名的解决方案就是提议者（proposer）/区块构建者（block-builder）分离。与区块提议者试图自己生产收益最大化的区块不同，他们依赖于一个市场，在这个市场中，我们称之为区块构建者的外部参与者生产包含完整区块内容和提议者费用的 bundle 包，而提议者选择最高费用的 bundle 包。提议者的选择被简化为选取费用最高的 bundle 包，这种算法非常简单，以至于在一个去中心化池子中，它甚至可以在 MPC 内完成以防止欺诈。
这篇文章提出了一些关于如何实现这一点的设计。
另请参阅 2018 年的想法，这些想法与此处的想法密切相关：优化提议承诺方案（Optimised proposal commitment scheme）
提议者/构建者分离区块提议设计的所需属性
我们将重点关注五个主要的期望属性：
1.不受信任的提议者友好性 ：提议者欺骗区块构建者的风险很小或没有风险，因此区块构建者没有动机选择具有一定链下声誉或与构建者有个人关系的提议者（因为这将有利于大型池子）。
2.不受信任的构建者友好性 ：区块构建者欺骗提议者的风险很小或没有风险，因此提议者没有动机选择具有一定链下声誉或与提议者有个人关系的构建者（因为这会让新的构建者更难进入市场）。如果需要存款来实现这一点，则应最大限度地降低门槛。
3.弱提议者友好性 ：该机制不应该要求提议者具有 (i) 高带宽或其他计算资源或 (ii) 高技术复杂性。
4.Bundle 包不可窃取 ：提议者应不可接受区块构建者提出的 Bundle 包并从中提取交易来制作自己的 Bundle 包，从而阻止区块构建者获利（并可能进一步损害他们）。
5.共识层的简单性和安全性 ：从共识层的角度来看，该机制应该继续是安全的，并且最好与现有的区块提议机制进行相同的分析。
想法 1
1.区块构建者生成 bundle 包并发布它们创建的 bundle 包的头（headers），一个 bundle 包头包含对包主体（bundle body）的 commitment 承诺（预期的区块内容）、对提议者的付款以及构建者的签名。
2.提议者选择提供最高付款的 bundle 包头（仅考虑构建者有足够余额来实际支付的 bundle 包）。他们签署并发布包含该包头（bundle header）的提议。
3.看到签名的提议后，提供包含包头（bundle header）的区块构建者将发布完整的 bundle 包。
在这一点上，分叉选择规则有能力做出三个判断中的一个（而不是通常的两个）：
1.区块提议不存在
2.区块提议存在，但包主体（bundle body）不存在
3.区块提议存在，并且包主体（bundle body）存在
请注意，在第二种情况下，proposal 仍然成为了链的一部分，并且至关重要的是，区块构建者向提出者的付款仍在处理（但区块构建者自己不会获得任何费用或自己获取 MEV）。
分析
五个属性中的三个很容易满足：
1.提议者无条件地接受承诺的付款，因此 bundle 包不能欺骗提议者；
2.三个步骤都是非常自动化和低带宽的，因此这满足弱提议者友好性；
3.提议者无法看到他们正在签署的 bundle 包的内容，因此这满足 bundle 包的不可窃取性；
而共识层属性，以及不受信任的提议者友好性要更加棘手。这种设计确实改变了分叉选择的工作方式，将其从 2 个选项增加到 3 个选项，这也意味着提议者不再是游戏中的最后一个参与者。从理论上讲，人们可以推断，如果分叉选择能够做出决定，那么这应该是好的，但这仍然是一个潜在未知的重大变化。
提议者看不到 bundle 包内容，也不能通过 bundle 包窃取来欺骗区块构建者，但是他们可以对区块构建者使用更微妙的攻击。他们可以在一个 slot 时间段的末尾发布他们的提议，确保证明人（可能）按时看到 proposal 提议，但不能给区块构建者足够的时间发布 body，因此证明人很有可能没有按时看到 body。这给区块构建者带来了风险，并激励他们青睐值得信赖的提议者。此外，它还创造了一个机会，通过这个机会，恶意的大多数人可以对自己不喜欢的区块构建者进行重罚。
对于这一问题，我认为有两种缓解方法：
1.证明人在接受提议的最长时间和接受一个 body 的最长时间之间有 2 秒的延迟。如果你信任证明人，这基本上可以解决问题，尽管区块构建者有损失资金风险的基本问题仍然存在。此外，尚不清楚证明者以这种方式投票是否符合激励措施（尽管可通过要求他们证明提案的 2 秒长 VDF 解决方案来迫使他们等待）。
2.如果一个 body 没有被包含在内，提议者只会得到一半的付款（而区块构建者只支付一半）。这使得提议者恶意破坏的代价很高，但它仍确保了区块构建者恶意破坏的代价仍然很高（在这两种情况下，代价都足以让你相信甚至匿名参与者也不想这么做）。例如，如果一个 bundle 包的提议者费用为 1，区块构建者利润为 1.05:
（1）诚实的行为将导致（构建者，提议者）回报为（0.05, 1）；
（2）提议者或证明人发布太晚，导致一个只有 header 头的区块被接受，则回报为 (-0.5, 0.5) ；
想法 2
1.区块构建者制作 bundle 包并发布他们创建的 bundle 包头。一个 bundle 包头包含对内容的承诺、对提议者的付款以及来自构建者的签名。
2.提议者选择并签署一份声明，该声明由他们所看到的 bundle 包头列表组成。
3.看到该声明后，选定的区块构建者会发布其相应的包主体（bundle body）。
4.提议者从他们预先提交的列表中选择一个 bundle 包头，并用它发布一个提议。
有一个新的罚没条件，它可以驱逐和惩罚任何发布不属于（相同 slot 时间段内）列表提议的提议者。
还要注意的是，提议者在步骤（2）中提交的 bundle 包头列表也可以是包头的加密哈希列表，其中每个哈希都加密到该 bundle 包的构建者的公钥，以便只有构建者知道它们是否被接受。这降低了 DoS 攻击风险。
分析
同样，五个属性中有三个很容易满足：
提议者不能窃取 bundle 包，因为他们只有在已将自己限制在有限的现有 bundle 包头集时才能看到任何 bundle 包主体。
如果不包括完整的 body，就不可能发生构建者对提议者的付款，因此提议者也不能在经济上欺骗构建者。
共识属性和以前一样，因为系统仍然是提议者为最后一个行动者的游戏，并且共识规则决定的内容没有变化。
在这种情况下要确保的两个较难的属性是，弱提议者友好性和不受信任的区块构建者友好性。令人担忧的是，恶意的区块构建者可以通过提出大量的提议来攻击提议者，这些提议都提供了非常高的费用，但从不公布其中任何一个提议的 body。如果提议者对他们接受多少 bundle 包有上限，那么这种攻击可以将所有合法 bundle 包定价，并使提议者没有可合法包含在其区块中的 bundle 包。如果提议者可接受的 bundle 包数量没有上限，那么这可能导致向提议者发送无限数量的全 bundle 包体（相想每个 500 kb），这是一个巨大的带宽需求。
该难题的一个解决方案是以某种非硬性限制的方式对 bundle 包头提交进行速率限制。
1.提交 bundle 包的费用，通过一些类似 EIP-1559 的机制进行调整以达到一定的速率（例如每个 slot 8 个 bundle 包）。
2.作为区块建设者的存款要求，以及一条规则，即当更低价格的 bundle 包被包含了，而你发布的 bundle 包没有被包含，那么你就不能为接下来的 N 个 slot 提交 bundle 包。
费用本身也可能仅在你的 bundle 包未包含，但较低价格的 undle 包包含在内的情况下收取，因为这是你可能存在恶意行为的具体情况（或提议者是恶意的或网络当时是坏的）。
这是有先例的，比如 ENS 拍卖收取 0.5% 的失败者费用，以阻止人们在显然不会获胜的情况下进行出价（只是为了增加获胜者必须支付的金额）。
然而，这些技术存在对提议者引入信任要求的风险，因此需要谨慎完成，并且未能将 bundle 包包含在内的惩罚不能太高。
另一种解决方案是允许免费和无限制的 bundle 包主体发布，但限制网络层的主体传播。一种简单的算法是：
为可以传播 bundle 包主体的最小时间添加一个轻微的延迟：最高支付 bundle 包的延迟为 0 秒，第二高支付 bundle 包的延迟为 0.2 秒，第三高支付 bundle 包的延迟为 0.38 秒，第 K 高支付的 bundle 包，就延迟
秒。
添加一个规则，如果节点已广播了一个更高收入的 bundle 包主体，则该节点不会再广播一个 bundle 包主体。
这两种技术可以结合在一起：你可以收取少量费用来将预期的 bundle 包数量减少到（例如）每 slot 50 个，然后使用这样的网络层机制进一步降低带宽需求。
结论
截至目前，我还无法确定上述两种方法是否是解决问题的唯一途径，可能还会有其他的方法。在这两种方法中，想法 (1) 在概念上更简单，但它给区块构建者带来了风险以及更复杂的分叉选择规则要求。
而从分叉选择和共识角度来看，想法 (2) 要更简单，但它在处理恶意区块构建者 DoS 攻击方面存在挑战，并且该问题的任何解决方案也有可能产生其他的问题（尽管可以想象这可以最小化）。到目前为止，我仍然不确定哪个方案会更好一些。
声明：此文出于传递更多信息之目的，并不意味着赞同其观点或证实其描述。本网站所提供的信息，只供参考之用。
