对建设者中心化风险（主要是审查制度，还有各种形式的经济剥削）的一种自然反应是试图限制建设者拥有的权力。如果他们赢得拍卖，建筑商将没有完全控制建造整个街区，而是建筑商将拥有更有限的权力。这种力量应该仍然足以捕获几乎所有可以捕获的 MEV，理想情况下它应该仍然足以捕获 PBS 的其他好处，但应该削弱它以限制滥用的机会。
这个想法有时被称为部分区块拍卖：不是拍卖决定区块中所有事物的权利，而是拍卖决定某些事情的权利，其中那些“某些事情”可能比例如更细微。“建造者选择区块的前半部分而不是第二部分”：你可以赋予建造者重新排序、前置、追加的权利，你甚至可以限制提议者。在本文中，Vitalik Buterin将向大家介绍一些可能的方法，以及由此产生的一些权衡。
作者：Vitalik Buterin
(资料图)
编译：陈一晚风
包含列表
在包含列表范式中，提议者提供包含列表，即他们要求的交易列表必须包含在块中，除非构建者可以用其他交易完全填充块。
对于不受异常外部激励影响的利润最大化的建设者来说，包含列表根本没有限制：在块的末尾添加额外的交易总是会给建设者该交易的优先费用作为额外的利润。
如果区块被填充到完整的气体限制（目标的 2 倍），因此构建者必须在该交易和其他交易之间进行选择，则禁用约束。从长远来看，这不会影响包含，因为完整区块的运行只能短暂维持，因为它使基本费用呈指数增长（每 6 个区块约 2.02 倍）。
但是，如果建筑商确实希望拒绝包括其不赞成或被激励排除的特定交易，则该建筑商将被迫不参与拍卖。
这个设计相当简单，但重要的是描述它的一些弱点：
激励兼容性问题：构建者提前看到包含列表，构建者可以拒绝构建包含他们不想构建的包含列表的块。这会立即激励提议者拥有空的包含列表，以最大限度地提高建设者为他们构建块的机会。
提议者的额外负担：提议者需要能够识别付费交易。这需要(i) 访问内存池和(ii)读取状态以确定费用支付的能力，或与交易相关的见证人。见证人更可取，因为他们会保留 PBS 属性，即验证者可以是无状态客户端。
构建器仍然可以进行一些滥用：特别是三明治攻击。然而，目前尚不清楚如何在没有极端方法（例如使用高级密码学来加密内存池）的情况下消除此问题，因为否则从构建者手中夺走这种权力意味着将其交给提议者，这将激励提议者加入权益池。
需要部分供奉才能使帐户抽象起作用：请参阅帐户抽象之路-HackMD10
提议者后缀
另一种结构是允许提议者为块创建后缀。构建者在构建区块时不会看到有关提议者意图的信息，并且提议者将能够将构建者错过的任何交易添加到最后。
减少激励兼容性问题：构建者仍然可以追溯惩罚提议者（例如，通过拒绝在未来为他们构建），包括构建者不赞成的交易，并将根发送给构建者。这是不可避免的，但这比构建者能够拒绝实时构建块更友好得多（特别是因为每个单独的提议者只是偶尔提出，现在每 2 个月一次）。
提议者的额外负担- 提议者现在必须计算后状态根，这意味着提议者必须持有整个状态。因此，除非提议者将此任务外包给单独的中介，否则无国籍是不可能的。
提议者在获得构建者的响应和必须发布块之间获得了一些 MEV 机会。这可能只有半秒的价值，但对于验证者加入权益池以便能够在内部进行优化的动机仍然有所增加。
建造者仍然可以像以前一样从事一些滥用行为。
像以前一样，需要部分供奉帐户抽象才能工作
修复提议者后缀：预先承诺
提议者预先提交到 Merkle 树或 KZG 承诺或他们想要包含的 tx 集的其他累加器。构建器创建他们的块。然后，提议者必须添加完全由构建器尚未包含的 Merkle 树子集组成的后缀，并且气体限制允许他们包含，按 txhash 或其他一些标准化顺序排序（如果他们添加任何其他后缀，他们被削减）。
提议者后缀withtree.drawio541×512 20.8 KB
执行削减的细节有些复杂，特别是如果你想避免将提议者的包含树放在清楚的地方。使用 KZG 承诺和特殊用途的 ZK-SNARK 可以相当容易地完成，使用专门的多项式方程来验证“如果你从承诺 X 的集合开始，并删除 Y 中的任何东西，那么剩下的集合就是 Z ”。
这消除了提议者的 MEV 机会，因为一旦构建者用他们自己的区块内容回复，提议者在发布哪个区块的自由度为零，但其他问题仍未解决。
长期潜力：我们如何约束构建者并最小化提议者的责任？
理想情况下，提议者的角色应该保持最小：简单地识别值得包含的交易。最小化提议者的角色可确保该角色保持高度可访问性。理想情况下，构建者的角色应该保持最小：构建者应该有权从内存池中重新排序交易并插入他们自己的交易以收集 MEV，而不能根据他们将包含哪些交易来区分区块。
但这留下了许多其他重要任务未分配，尤其是未来将变得必要的任务：
计算后状态根的任务
计算和发布见证的任务
制作 ZK-SNARK以证明区块正确性的任务
如果这些任务不交给建造者或提议者，那么他们将不得不交给第三方。有几种可能的方法来实现这一点：
我们创建了一个单独的类builder-like intermediary，提议者与之签约，并认为自己只是一个专门的云计算提供商，其工作是计算函数的输出（ZK SNARK 生成、状态根计算等），并且不参与选择块内容
我们要求下一个块包含前一个块的这些值。由下一个区块的提议者来寻找中介来构造这些值，并在需要时对其进行验证。
我们在协议中规定了一类单独的中介，并为它们添加了协议内激励措施
我们让网络中的利他行为者来发布这些值（因此它们不会被散列到块中）。证明者只有在看到提供的正确值后才能证明。
无论如何，同时需要最小化构建者可用的权力和信息，以及强加给提议者的负担，似乎清楚地表明在块生产管道中需要一些第三个参与者（除非我们硬着头皮接受构建者有权查看包含列表，因此可以区分包含在同一插槽中的特定交易）。我们应该开始更深入地思考这将如何处理。
