对建筑者去中心化风险性（通常是审查机制，以及各种方式的经济发展盘剥）的一种自然反应是尝试限定建筑者所拥有的权利。如果他获得竞拍，承建商将并没有良好控制修建全部商业街，反而是承建商将拥有更多有限的资源权利。这类能量应当依然足够捕捉绝大多数能够获取的 MEV，理想化前提下它应当依然足够捕捉 PBS 的许多益处，但应该消弱它是以限定乱用的好机会。

这样的想法有时候被称作一部分区块竞拍：并不是竞拍确定区块中万事万物的权力，反而是竞拍确定某些事的权力，在其中这些“某些事”很有可能占比如更微小。“建造者挑选区块的前半部而非第二部分”：你能授予建造者重新排序、外置、增加的权力，你甚至能够限定提议者。在这篇文章中，Vitalik Buterin将向同学们介绍一些可能性的方式，及其所产生的一些衡量。

作者：Vitalik Buterin

编译程序：陈一夜风

包含列表

在包含列表方式中，提议者给予包含列表，即她们标准的交易列表务必包含在块中，除非是构建的人可以用别的交易彻底添充块。

针对不会受到出现异常外部激励的影响利益最大化的奉献者而言，包含列表压根不受限制：在块结尾加上额外交易总会给建筑者该交易的优先选择花费做为额外盈利。

假如区块被补充到详细气体限定（的目标 2 倍），因而构建者必须要在该交易和其它交易中间来选择，则禁止使用管束。长远来看，这也不会影响包含，由于详细区块的运转只有短暂性保持，因为他使基本上花费呈指数增长（每 6 个区块约 2.02 倍）。

可是，假如承建商的确期待回绝包含其不赞成或者被鼓励清除的特殊交易，则其承建商将迫不得已不参加竞拍。

这样的设计非常简易，但最重要的是叙述它一些缺点：

• 鼓励兼容问题：构建者提早见到包含列表，构建者可以拒绝构建包含他们不愿意构建的包含列表的块。这会立刻鼓励提议者有着空包含列表，以最大程度地提升建筑者为其构建块机遇。

• 提议者的额外负担：提议者必须可以鉴别付钱交易。这就需要(i) 浏览内存池和(ii)载入情况来确认花费收取的水平，或者与交易有关的见证者。见证者更可用，因为我们会保存 PBS 特性，即验证者能是无状态手机客户端。

• 构建器仍然能够进行一些乱用：尤其是三明治进攻。但是，目前还不太清楚怎样在并没有极端化方式（比如应用高端密码算法来数据加密内存池）的情形下清除该问题，由于不然从构建者手里抢走这类权利代表着把它交到提议者，这将会鼓励提议者添加利益池。

• 必须一部分敬奉才能让账号抽象化起到作用：客户程序账号抽象化之途-HackMD 10

提议者后缀名

另一种构造是容许提议者为块建立后缀名。构建者在构建区块的时候不会见到相关提议者用意的数据，而且提议者将能够把构建者错过的人一切交易加上到后来。

• 降低鼓励兼容问题：构建者仍然能够追朔处罚提议者（比如，根据回绝不久的将来为其构建），包含构建者不赞成的交易，并把根发给构建者。这是在所难免的，但是这比构建者可以回绝即时构建块更友善的多（尤其是由于每一个独立的提议者偶尔明确提出，如今每 2 个月一次）。

• 提议者的额外负担- 提议者如今务必测算后情况根，这就意味着提议者务必拥有全部情况。因而，除非是提议者将这一每日任务业务外包给独立中介，不然无国籍根本不可能。

• 提议者在取得构建者回应和务必公布块中间赢得了一些 MEV 机遇。这大概只有1秒其价值，但是对于验证者添加利益池便于可以在外部进行改善动机依然有所增加。

• 建造者仍然能够像以前一样从业一些乱用个人行为。

• 像以前一样，必须一部分敬奉账号抽象化才可以工作中

修补提议者后缀名：事先服务承诺

提议者事先递交到 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 形成、情况根测算等），而且不参加挑选块具体内容

• 大家规定下一个块包含前一个块这种值。由下一个区块的提议者来获取中介公司来结构这种值，并且在需要的时候对它进行认证。

• 大家在协议中明确了一类独立中介，并为它们加了协议书内激励机制

• 大家让网络里的利他行为者来公布这种值（因而他们不被散列到块中）。证明者仅有当看到所提供的恰当值之后才能证实。

不管怎样，与此同时必须降到最低构建者可利用的权力和信息内容，及其强加于给提议者的压力，好像清晰地说明在块生产制造管道内需要一些第三个参加者（除非是大家咬着牙接纳构建者有权利查询包含列表，所以可以区别包含在同一扩展槽里的特殊交易）。我们要逐渐更加深入地思考这将会怎样处理。

转载：驼鸟区块链