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