币圈最新消息编译：DeFi 之道
对构建者中心化的风险（主要是审查，但也有各种形式的经济剥削）的一个自然反应是试图限制其拥有的权力。如果构建者赢得拍卖，那么构建者不应全权构建整个区块，而是应该拥有更有限的权力。这种权力应该仍然足以捕获几乎所有可以捕获的 MEV，而且最好仍然足以捕获 PBS 的其他好处，但它应该被削弱以限制滥用。
这个想法有时被称为部分区块拍卖：与其拍卖决定区块中的一切权利，不如拍卖决定某些事情的权利，这里的“某些事情”可以比“构建者选择区块的前半部分而不是后半部分”更为细微：你可以给构建者重新排序、预置、追加权利，你甚至可以限制提议者。本篇文章介绍了一些可能的方法，以及由此产生的一些权衡。
包含列表（Inclusion lists）
在包含列表模式（inclusion list paradigm）中，提议者提供一个包含列表，即他们要求必须包含在区块中的交易清单，除非构建者能用其他交易完全填满一个区块。
对于一个不受特殊外部激励影响的旨在利益最大化的构建者来说，包含列表根本不算什么约束：在区块的末尾增加一个额外的交易总是会给构建者带来该交易的优先费作为额外的收益。
如果区块被填满，达到 Gas 的全部限制（目标的 2 倍），那么构建者必须在该交易和其他交易之间做出选择，而该约束将无用。从长远来看，这并不影响交易的纳入，因为满区块的运行只能短暂维持，它会使基础费用呈指数级上升（每 6 个区块～2.02 倍）。
然而，如果一个构建者确实有一些愿望，拒绝包括它不赞成的或被激励排除的特定交易，那么该构建者将被迫不参与拍卖。
这种设计是相当简单的，但有必要介绍一下它的一些弱点：
激励相容性问题：构建者提前看到了包含列表，可以拒绝构建包含他们不想构建的区块。这就直接激励了提议者提议空的包含列表，以最大限度地提高构建者为他们构建区块的机会。提议者的额外负担：提议者需要能够识别付费交易。这需要（i）访问 mempool 且（ii）能够读取状态以确定支付费用的能力，或者是连接到交易的验证者。验证者会保留 PBS 的属性，即验证者可以是去状态的客户端。构建者仍然可以从事一些滥用行为：特别是三明治攻击。然而，目前还不清楚如何在不使用高级加密技术等极端方法的情况下（如使用高级加密技术来加密 mempool），消除这个问题，因为如果不这样做，那么将这种权力从构建者手中剥夺意味着将其交给提议者，这将激励提议者加入质押池。需要 partial enshrining 才能使账户抽象化发挥作用：见《账户抽象化之路》--HackMD 5
提议者后缀（Proposer Suffixes）
另一种构建方法是允许提议者为区块创建一个后缀。构建者在构建区块时不会看到关于提议者意图的信息，而提议者能够将构建者遗漏的任何交易添加到末端。
减少了激励的兼容性问题：构建者仍然可以追溯性地惩罚包括构建者不赞成的交易的提议者（例如，拒绝在未来为他们构建），并将根发给所有构建者。这是不可避免的，但相对于构建者能够实时拒绝构建区块而言，这对提议者要友好得多（特别是由于每个单独的提议者只是偶尔提议，例如每两个月一次）。对提议者来说甚至有更多的额外负担：提议者现在必须计算后状态根，这意味着提议者必须持有整个状态。因此，不存在去状态是可能的，除非提议者将这项任务外包给一个单独的中介。在从构建者那里得到响应和必须发布区块之间，提议者得到一些 MEV 机会。这可能只有半秒的价值，但它仍然增加了验证者加入质押池的动力，以便能够在内部进行优化。构建者仍然可以像以前一样，从事一些滥用行为。和之前一样，需要 partial enshrining 以使账户抽象化发挥作用。
对提议者后缀的修正：预承诺（pre-commitment）
提议者预先承诺 Merkle 树或 KZG commitment 或其他他们想纳入的 txs 集合的聚合器。构建者创建他们的区块。然后，提议者必须添加后缀，该后缀正好由构建者尚未纳入的 Merkle 树的子集组成，并且 gas 限制允许他们纳入，并按 txhash 或其他标准化的顺序排序（如果他们添加任何其他后缀，他们会被罚没）。
执行罚没的细节有些复杂，特别是如果你想避免把提议者的包容树（inclusion tree）置于明处。这可以用 KZG commitments 和特殊目的的 ZK-SNARKs 轻松完成，即使用专门的多项式方程来验证“如果你从有 commitment X 的集合开始，移除 Y 中的任何东西，那么剩下的集合就是 Z”这一概念。
这消除了提议者的 MEV 机会，因为一旦构建者回复了他们自己的区块内容，那么提议者在发布什么区块方面的自由度为零，但它留下了其他未解决的问题。
更长远的讨论：我们如何约束构建者，并尽量减少提议者的负担？
提议者的角色最好保持最小化：只需确定值得被纳入的交易。最小化提议者的角色，可以确保这个角色保持高度的可及性。构建者的角色也最好最小化：构建者应该有权利从 mempool 中重新排序交易，并插入他们自己的交易来收集 MEV，而不能根据他们将纳入哪些交易来区别对待区块。
但是，这使得许多其他重要的任务不能得到分配，特别是那些在未来变得必要的任务：
计算后状态根的任务计算和发布见证的任务制作一个证明区块正确性的 ZK-SNARK 的任务
如果这些任务不交给构建者或提议者，那么它们就必须交给某个第三行为者。对此，有几种可能的方法来实现这一点：
我们可以创建一个单独的类似于构建者的中介类别，让提议者与之签订合同，这类中介只相当于一个专门的云计算供应商，其工作是计算函数的输出（ZK SNARK 生成、状态根计算等），而不参与选择区块的内容。我们可以要求下一个区块包含前一个区块的这些值。这就需要下一个区块的提议者找到一个中介来构建这些值，如果需要的话，还要验证它们。我们可以在协议中规定一个单独的中介类别，并为他们增加协议中的激励措施。我们可以让网络中的利他主义者来发布这些值（因此它们不会被散列在区块中）。认证者只有在看到提供的正确值时才会认证。
在任何情况下，我们需要在最大限度地减少构建者的权力和信息的同时，最大程度地减少强加给提议者的负担，而这似乎清楚地表明在区块生产中需要一些第三行为者（除非我们咬紧牙关，接受构建者有权查看包含列表，从而歧视特定交易被包含在同一 slot 中）。我们应该开始更深入地思考究竟如何处理这个问题。
