我们能在多大程度上限制建设者？

https://ethresear.ch/t/how-much-can-we-constrain-builders-without-bringing-back-heavy-burdens-to-proposers/13808

在不给提议者带来沉重负担的情况下，我们可以在多大程度上限制建设者？

对建设者中心化风险（主要是审查制度，但也包括各种形式的经济剥削）的一种自然反应是试图限制建设者拥有的权力。而不是建设者全权负责建造全部的 如果他们赢得拍卖，建筑商将拥有更有限的权力。这种力量应该仍然足以捕获几乎所有可以捕获的 MEV，理想情况下它应该仍然足以捕获 PBS 的其他好处，但它应该被削弱以限制滥用的机会。

这个想法有时被称为部分区块拍卖：不是拍卖区块中决定一切的权利，而是拍卖决定的权利有些东西 ，其中那些“某些东西”可能比例如更细微。 “建造者选择区块的前半部分而不是后半部分”：你可以赋予建造者重新排序、前置、追加的权利，你甚至可以限制提议者。这篇文章讨论了一些可能的方法，以及由此产生的一些权衡。

包含列表

在包含列表范式中，提议者提供了一个包含列表 ，他们要求的交易列表必须包含在区块中，除非构建者可以填充区块完全地 与其他交易。

对于不受异常外部激励影响的利润最大化构建者来说，包含列表根本不是约束：在区块末尾添加额外交易总是给构建者该交易的优先费作为额外利润。

在区块被填充到完全 gas 限制（目标的 2 倍）的情况下，因此构建者必须在该交易和其他交易之间做出选择，约束将被禁用。从长远来看，这不会影响包容性，因为完整区块的运行只能短暂维持，因为它会使基本费用呈指数增长（每 6 个区块约 2.02 倍）。

但是，如果建筑商确实希望拒绝包括其不赞成或被激励排除的特定交易，则该建筑商将被迫不参与拍卖。

这个设计相当简单，但描述它的一些弱点很重要：

• 激励兼容性问题 ：构建者提前看到包含列表，并且构建者可以拒绝构建包含他们不想构建的包含列表的块。这会立即激励提议者拥有空的包含列表，以最大限度地提高构建者为他们构建区块的机会。
• 提议者的额外负担 ：提议者需要能够识别付费交易。这需要 (i) 访问 mempool 和 (ii) 读取状态以确定费用支付的能力，或与交易相关的见证。见证人是更可取的，因为他们将保留验证者可以是无状态客户端的 PBS 属性。
• 建筑商仍然可以从事一些滥用行为 : 特别是三明治攻击。然而，目前尚不清楚如何在不使用高级密码学加密内存池等极端方法的情况下解决这个问题，因为否则将这种权力从构建者手中夺走意味着将其交给提议者，这将激励提议者加入权益池。
• 需要部分供奉才能使帐户抽象工作： 看账户抽象之路 - HackMD

建议后缀

另一种结构是允许提议者为区块创建后缀。建造者在建造区块时看不到提议者意图的任何信息，提议者可以将建造者遗漏的任何交易添加到最后。

• 减少激励兼容性问题 ：建造者仍然可以追溯惩罚提议者（例如，通过拒绝在未来为他们建造）包括建造者不赞成的交易，并将根发送给建造者。这是不可避免的，但这比建设者能够实时拒绝构建区块（特别是因为每个提议者只是偶尔提议，今天每约 2 个月一次）对提议者更友好。
• 提议者的额外负担更多 - 提议者现在必须计算后状态根，这意味着提议者必须持有整个状态。因此，无状态是不可能的，除非提议者将这项任务外包给分离 中介。
• 提议者获得一些 MEV 机会 在获得构建器的响应和必须发布块之间。这可能只有半秒的价值，但它仍然增加了验证者加入权益池以便能够在内部进行优化的动机。
• 建造者仍然可以像以前一样从事一些滥用行为
• 需要部分供奉才能使帐户抽象工作， 像之前一样

修复提议者后缀：预承诺

提议者预先提交他们想要包含的一组 tx 的 Merkle 树或 KZG 承诺或其他累加器。构建器创建他们的块。然后，提议者必须添加后缀，该后缀完全由构建者尚未包含的 Merkle 树子集组成，并且气体限制允许他们包含，按 txhash 或其他一些标准化顺序排序（如果他们添加任何其他后缀，他们被削减）。

执行削减的细节有些涉及，特别是如果你想避免将提议者的包含树放在明文中。使用 KZG 承诺和特殊用途的 ZK-SNARK 可以相当容易地完成，使用专门的多项式方程来验证“如果你从承诺 X 的集合开始，并删除 Y 中的任何东西，那么剩下的集合是 Z”的概念”。

这消除了提议者的 MEV 机会，因为一旦构建者用他们自己的块内容回复，提议者在发布哪个块方面的自由度为零，但其他问题未解决。

长期的结局：我们如何约束建设者和 尽量减少提议者的责任？

理想情况下，提案人的角色应该保持在最低限度：简单地确定值得包含的交易。最小化提议者的角色可确保该角色保持高度可访问性。理想情况下，建造者的角色应该保持在最低限度：建造者应该有权从内存池中重新排序交易并插入他们自己的交易以收集 MEV，而不能根据它们将包含哪些交易来区分区块。

但这留下了许多其他重要任务未分配，尤其是将来必须执行的任务：

• 计算后状态根的任务
• 计算和发布见证的任务
• 制作 ZK-SNARK 证明区块正确性的任务

如果这些任务不交给构建者或提议者，那么他们将不得不去一些第三 演员。有几种可能的方法来实现这一点：

• 我们创建了一个单独的类似构建器的中介类，提议者与之签约，并且认为自己只是一个专门的云计算提供商，其工作是计算函数的输出（ZK SNARK 生成、状态根计算等），并且不参与选择块内容
• 我们要求下一个 块以包含前一个块的这些值。由下一个区块的提议者找到一个中介来构造这些值，并在需要时验证它们。
• 我们在协议中加入了一个单独的中介类别，并为他们添加了协议中的激励措施
• 我们让网络中的利他行为者来发布这些值（这样它们就不会散列到块中）。证明者只有在看到提供的正确值后才会证明。

无论如何，同时需要最小化构建者可用的权力和信息，以及强加给提议者的负担，似乎清楚地表明在块生产管道中需要一些第三方参与者（除非我们硬着头皮接受构建者有权查看包含列表，因此会歧视包含在同一槽中的特定交易）。我们应该开始更深入地思考将如何处理这件事。