本文主要围绕Vitalik最近的SBCMEV研讨会演讲而构建，并提供进一步的分析。原文标题：《如何实现区块构建者角色的去中心化？这里有两种方法》
撰文：JonCharbonneau
引言
快速回顾——本报告的一个关键主题是VitalikButerin在《终局游戏》一文中的想法，即所有前进道路似乎都通向：
中心化区块生产
去中心化和去信任的区块验证
继续提供抗审查
生产者-构建者分离试图将中心化与构建者隔离，然后以太坊添加盔甲以减轻构建者的审查权力。构建者自然会很老练，所以悬而未决的问题主要是他们的中心化程度。我们是在说1个构建者？还是10个？
一个中心化构建者仍然不理想，那么我们能做得更好吗？解决这个问题有两种方法：
拥有许多构建者的去中心化市场——确保构建者市场在没有根深蒂固的参与方的情况下具有竞争力。许多构建者竞争并只获得很小的利润。这个角色变得非常商品化。这需要解决诸如排他性订单流之类的问题，否则这些问题可能会巩固单个构建者。
去中心化构建者角色本身——使获胜的构建者本身成为去中心化的协议。一组去中心化的参与者都有助于构建一个给定的区块。
本报告主要围绕Vitalik最近的SBCMEV研讨会演讲而构建。我将把它分解并提供进一步的分析。
去中心化的构建者能胜出吗？
这里实际上有两个潜在的问题：
技术可行性——我将介绍一些可行的路径
竞争力——用户真的想使用它吗？或者一个中心化构建者总是会在功能和效率上胜过去中心化构建者？
去中心化什么？
中心化构建者很容易。下面考虑了一些可以去中心化的分布式构建者，需要在许多搜索者和用户之间聚合捆绑和交易：
算法-构建者运行算法来聚合搜索者的捆绑包和其他交易，然后自己填写区块的其余部分。该算法及其输入可以分散。
资料来源：基于VitalikButerin的图片
资源?-资源需求将显着增加，尤其是使用Danksharding。区块将携带更多数据并且构建起来更加复杂→构建它们的带宽和硬件要求更高。不需要一个节点来构建和分发整个区块，而是可以在多个节点之间拆分工作。
额外的构建者服务——构建者可以发挥创意并提供新的服务，例如交易预确认。为了使分布式构建者取得成功，他们需要提供与中心化构建者相比具有竞争力的服务。
访问订单流——将订单流发送给单个构建者非常简单，并且可以为用户带来好处。也许他们承诺不抢跑你的交易，他们可以在你后面给你一些回扣。在潜在的许多参与者之间分散对订单流的访问是比较棘手的。
隐私——同样，相信您的订单将私下执行的构建者是最容易的，因此您可以将其发送给他们。分布式构建者需要一种方法来提供交易隐私，同时在此过程中还包括许多去中心化方。
跨链执行——分布式构建者需要一种与外部参与者协调以捕获跨链MEV的方法。
挑战
如果我们想在整个区块生产供应链中避开受信任的第三方，有几个障碍需要克服。我将在这里解决的一些挑战包括：
如何保护搜索者免受MEV窃取？
如果建设者看到搜索者提交给他们的捆绑包，他们可以复制交易，然后用他们自己的地址替换搜索者的地址。构建者在不奖励搜索者的情况下捕获了MEV。
神圣PBS和MEV-Boost中使用的提交披露方案从提议者←→构建者关系中消除了同样的MEV窃取威胁，但对于搜索者←→构建者来说，这是一个未解决的问题。搜索者目前只信任构建者，但信任不是可扩展的解决方案。
如何允许聚合器机制组合搜索者输入？
保护搜索者免受MEV窃取意味着他们的捆绑包不能以明文形式发送。但是，如果它们不在明处，那么构建者如何聚合它们呢？
如何保证聚合器机制能够真正发布这个区块？
捆绑内容最终必须明确。从密文→明文的过程是什么，我们如何在没有信任假设的情况下实现这一目标？
如何保护搜索者免受聚合者+提议者勾结？
请注意，这并不是构建分布式构建者所面临的挑战的详尽列表。还有其他悬而未决的问题和未知的未知数。
想法1-可信硬件
一种方法利用可信硬件-TPM。排序如下所示：
在解密区块之前，TPM必须确信两件事：
提议者签名-这种对区块头的承诺防止提议者窃取MEV。如果提议者在构建者区块体被公开后试图为自己窃取MEV，任何人都可以提出他们最初的承诺。这证明提议者在相同的区块高度签署了两个区块→他们被削减了。
提议者签名的可用性证明-防止聚合者+提议者串通。提议者的承诺存在是不够的——它必须是可用的。如果只有聚合器收到承诺，他们可以简单地永远隐藏它，允许提议者提出替代的MEV窃取区块。TPM必须确信最初的提议者签名实际上是公开的。
有几种方法可以证明提议者签名的可用性：
证明者-验证者可以证明看到提议者签名，然后TPM可以检查提议者和这些证明者签名。这需要更改以太坊协议。
低安全性实时数据可用性预言机——像Chainlink这样的东西可以证明签名存在并将被重新广播的事实。
聚合器内的MofN假设-聚合器本身可以是分布式MofN协议。聚合器协议中可能存在阈值投票，您对此有一个诚实的假设。
想法2-合并不相交的捆绑包和顺序拍卖
合并不相交的捆绑包
这种方法需要MofN聚合器，但我们可以摆脱TPM。该过程如下所示：
搜索者发送加密到一个阈值密钥的捆绑包。捆绑包包含访问列表和正确性SNARK。
聚合器合并不相交的捆绑包，使总出价最大化。
聚合器必须计算状态根
最后一步很棘手。计算状态根需要清楚地看到交易，或者至少看到它们的状态更新。然而，即使看到状态更新也可能足以进行MEV窃取。对于何时计算状态，我们有几个选项：
让一个聚合器节点解密然后计算状态。但是，他们可以与提议者勾结。
只有在提议者承诺支持接收到的任何区块和状态根之后，才计算状态根。这种设置将利用EigenLayer-提议者让自己受到额外的削减条件才能参与。提议者发送一条链下消息，承诺他们将依次生成的唯一区块是包含这组捆绑包的区块。只有在提议者做出承诺之后，捆绑包才会被解密，并计算状态根。如果提议者违反了这一承诺，那么他们将被削减。
请注意，对于此EigenLayer构造，也可以避免前面提到的SNARK要求。这里的提议者可以预先提交一个替代区块或替代区块组合，如果提交给他们的区块或替代区块组合被证明是无效的。然后可以使用一个欺诈证明来检查第一个区块组合的无效性。
顺序拍卖
EigenLayer技术可以直接用于不相交的捆绑合并，或者它可以依赖于每个插槽内的多轮顺序拍卖。
例如，以下可能发生在一个区块中：
第1轮
1.提议者签署一个EigenLayer消息，预先同意一些交易，从而在这一轮中最大化他们的出价以启动区块
2.构建者公布该区块的这一部分
3.提议者发布状态差异
第2轮
4.提议者签署一条EigenLayer消息，预先同意额外的交易，从而在本轮中最大化他们的出价以继续这个区块
5.构建者公布该区块的这一部分
6.提议者发布状态差异
第3轮…
一个缺点是这种合并可能不是最理想的。例如，提议者可能已经预先同意捆绑包1，然后他们收到了与捆绑包1冲突的更有利可图的捆绑包2。他们将不得不拒绝此捆绑包2。
具有相同订单流的中心化构建者可以看到所有交易，当他们在插槽末尾构建区块时可以包含捆绑包2。
另一个潜在的缺点-顺序拍卖可能会使非原子MEV变得非常困难，因为如果世界状况发生变化，搜索者将无法取消或更新他们的出价。如果您需要在交易被包含之前10秒以上提交交易，那么如果您保留更新出价的能力，您将无法承担尽可能多的风险。
但是，该示例假定相同的订单流。实际上，由于它提供的保证，这种分布式构建者可能能够在接收更多订单流方面胜过中心化构建者。更好的保证→更多的订单流→构建最有利可图的区块。然后，由于分布式构建者始终提供最高价值的区块，因此提议者选择这种结构将具有经济意义。
为了取得成功，分布式构建者提供的价值可能需要超过它带来的缺点。
区块构建post-Danksharding
Danksharding使验证者的节点要求较低。单个节点只负责下载区块的一部分。
然而，最初提出的设计将有意义地增加构建以太坊区块的硬件和带宽要求。那么问题是我们是否甚至可以以分布式方式进行初始构建。这将消除对单个高资源实体构建完整区块、计算所有KZG承诺、连接到许多子网以发布它，等等。
。
实际上很有可能以分布式方式构建。分布式纠删码甚至没有那么难。
首先，包含每个数据交易的人负责对其进行编码并将blob区块传播到子网和数据可用性网络。
当聚合器选择包含哪些数据交易时，他们可以使用实时DA预言机。聚合器不能只自己进行数据可用性采样(DAS)，因为当只有一方进行DAS时，这并不安全。所以一些分布式预言机需要下载整个东西。
然后网络可以从这里填写列。请记住，数据在此2D方案中得到扩展。例如，每个blob是512个chunks，但它被擦除编码为1024个chunks。然后扩展也垂直运行。例如，您在此处说图像中有32个blob，然后垂直扩展为64个blob。多项式承诺在每行水平和每列垂直运行。
资料来源：VitalikButerin
KZG承诺
由于KZG承诺的线性，你可以填写这些列，这将用于以太坊的分片设计。
KZG的承诺(com)具有线性关系。例如，您可以说com(A)+com(B)=com(A+B)。
你在证明中也有线性。例如，如果：
Q?证明A=在某个坐标z处的某个值，并且
Q?证明B=在同一坐标z处的某个值，则
您可以对Q?和Q?进行线性组合，这本身就是证明A和B的相同线性组合在相同坐标z处具有正确值
更正式地说：
让Q?证明A(z)和Q?证明B(z)
然后，cQ?+dQ?证明(cA+dB)(z)
这种线性属性允许网络填入所有内容。例如，如果您有第0列中第0-31行的证明，那么您可以使用它来生成第0列中第32-63行的证明。
只有KZG具有这种承诺线性和证明线性。
要更深入地了解以太坊的2DKZG方案，您可以查看我的以太坊报告或Dankrad最近的KZG演讲。Vitalik的这篇研究文章?还谈到了将KZG与IPA用于DAS的考虑因素。
这里的TLDR是KZG有一些非常好的属性，允许分布式区块构建和重建。您不需要任何一方来处理所有数据、扩展所有数据、计算所有KZG承诺并传播它们。它们可以为每一行和每一列单独完成。如果这样做了，我们就没有剩余的超级节点要求：
资料来源：DankradFeist和VitalikButerin
非KZG替代选择
如果我们无法实现所有KZG魔法，那么这是下一个最佳选择。
行承诺的前半部分只是blob，所以没有问题。然后，构建者必须提供其余部分和一些列承诺。
然后这些承诺必须匹配。所以j??坐标处的i??行承诺=i??坐标处的j??列承诺。
更正式地说：
构建者必须提供行承诺R?…R?和列承诺C?…C?，其中R?(x?)=C?(x?)
以及承诺等价的证明
这可以像讨论的那样以分布式方式完成，但请注意，这样做更难：
前面描述的KZG方法-可以在一轮中完成。构建者只检查所有blob然后发布。网络在不涉及构建者的完全独立的过程中填充行。
此处的分布式方法-至少需要两轮协议。构建者需要参与。
额外的构建者服务-预先确认
以太坊区块时间很慢，用户喜欢快速的区块时间。以太坊做出这一牺牲主要是希望支持一个大型去中心化验证者集——Vitalik在这里写过的权衡空间。但是我们能做到两全其美吗？
以太坊rollup用户已经了解并喜欢这些预先确认。构建者创新也许能够在基础层提供类似的服务。
例如，构建者可以同意：
如果用户发送优先级费用≥5的交易，构建者会立即发送一个可执行的签名消息，同意将其包含在内。
如果用户发送优先级费用≥8的交易，构建者甚至提供后状态根。因此，较高的优先级费用迫使交易以某种顺序被包含在内，从而使用户可以立即知道该交易的结果是什么。
如果构建者不履行他们的承诺，他们可能会被削减。
在具有并行化EVM的未来，您还可以通过预先确认获得更高级的信息。例如，只要用户关心的状态没有改变，即使在给出预先确认之后，构建者也可以重新排序一个区块中的一些交易。
分布式构建者可以提供预先确认吗？
是的。分布式构建者可以运行一些内部共识算法，例如具有快速出块时间的Tendermint。构建者可能会因以下原因受到处罚：
Tendermint机制内的双重确定性
签署与Tendermint机制认同的内容不兼容的区块
请注意，为了在此处获得最佳安全性，需要对最终构建者签名进行某种帐户抽象。阈值BLS是不可归因的——这意味着如果建设者只是BLS签署区块，如果出现问题，我们将不知道该削减谁。抽象签名将解决这个问题。
对于任何构建者预确认服务，请注意，预确认仅与他们实际构建获胜区块的能力一样好。具有更高包含率的更占主导地位的构建者可以提供更好的预确认。
但是，您实际上可以通过分布式构建者获得更强的预先确认，例如EigenLayer构造。如果当前提议者选择了EigenLayer并且您获得了预先确认，那么您的交易必须包括在内。您不再押注于中心化构建者的概率赔率，给您一个预先确认然后最终是否赢得区块。
分布式构建者的优缺点
假设所有的技术都成功了，分布式构建者有成千上万的参与者。你甚至可以让大部分以太坊验证者选择加入提供亚秒级预确认的EigenLayer构造。与中心化构建者相比，这种分布式构建者具有一些不错的竞争优势：
经济安全——支持预确认服务的巨额安全存款
信任——搜索者可以信任这个分布式构建者，而不是单个中心化实体
抗审查——与决定恶意的单个中心化运营商相比，破坏和控制任何安全的分布式系统都更加困难
中心化构建者可能具有其他优势，一些是固有的，一些基于分布式构建者的构造：
更快地适应新功能——适应市场需求的灵活性是有价值的，而这可能是上述分布式构建者构造所缺乏的。理想情况下，您可以将来自多方的独特功能聚合到一个区块中。
更低的延迟——这总是相关的，但对于跨链MEV尤其如此，当世界状态跨域变化时，搜索者更有可能想要更新他们的出价。
结论性想法
以太坊在很大程度上是根据最坏情况假设设计的——即使只有一个构建者存在，我们如何才能最好地减轻他们的权力？
然而，我们可以同时努力避免这种最坏情况的假设。这意味着设计一个并不总是导致根深蒂固的中心化构建者的系统。这里描述的两个想法提供了一些更有趣的可能性。然而，它们远不是一个详尽的清单——其他想法正在积极探索中，并且应该继续探索。
此外，这不应被视为「专有订单流的问题神奇地消失了，因此我们不再需要围绕它进行构建。」dApps必须继续围绕MEV进行机制设计创新，包括减少对专有订单流的需求。MEV不会去任何地方。
特别感谢VitalikButerin、SreeramKannan、RobertMiller和StephaneGosselin的审阅和意见。没有他们的工作，这份报告是不可能完成的。
来源：金色财经
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。