以太坊创始人V神（Vitalik Buterin） 发文表示，可通过部分区块拍卖限制构建者权力以应对其中心化风险（即可赋予构建者重新排序、前置、追加的权利，至可以限制提议者），并主要介绍了包含列表（Inclusion lists）、创建提议者后缀（Proposer Suffixes）、修复提议者后缀-预承诺（Fix to proposer suffixes: pre-commitment）三种可能方式：

1.包含列表（Inclusion Lists）：在此模式中，提议者提供一个包含列表，他们要求的事务（交易）列表必须包含在区块中，除非构建者可以完全用其他事务（交易）填充块。这种设计相当简单，但存在以下问题：激励兼容性问题；提议者的额外负担；构建者仍然可以从事一些滥用行为；需要partial enshrining才能使账户抽象化发挥作用。2.创建提议者后缀（Proposer Suffixes）：即允许提议者为区块创建一个后缀。构建者在构建区块时不会看到关于提议者意图的信息，而提议者能够将构建者遗漏的任何交易添加到末端。这样的做法减少了激励的兼容性问题，在从构建者那里得到响应和必须发布区块之间，提议者将得到一些MEV机会。不过仍存在提议者增加额外负担、滥用行为的发生以及需要partial enshrining才能使账户抽象化发挥作用。3.修复提议者后缀-预承诺，即提议者预先提交到Merkle树或KZG承诺或他们想要包含的txset的其他累加器，构建器创建他们的区块。 然后，提议者必须添加由构建器尚未包含的Merkle树的子集组成的后缀，并且gas限制允许他们包含这些后缀，按txhash或其他一些标准化顺序排序。这消除了提议者的MEV机会，因为一旦构建者用他们自己的区块内容回复，提议者在发布哪个区块的自由度为零，但其他问题仍未解决。

V神总结道，理想情况下，提议者和构建者的角色应该保持最小：提议者简单地识别值得包含的交易，最小化提议者的角色可确保该角色保持高度可访问性；构建者应该有权从内存池中重新排序交易并插入他们自己的交易以收集MEV，而不能根据他们将包含哪些交易来区分区块。但这留下了许多其他重要任务未分配，如计算后状态根的任务、计算和发布见证的任务、制作ZK-SNARK以证明区块正确性的任务。如果这些任务不交给建造者或提议者，那么他们将不得不交给第三方。长期来看，在任何情况下，我们需要在最大限度地减少构建者的权力和信息的同时，最大程度地减少强加给提议者的负担，而这似乎清楚地表明在区块生产中需要一些第三方参与。