信任、安全、抗审查，builder 的去中心化应该怎么 build？

免责声明：本文旨在传递更多市场信息，不构成任何投资建议。文章仅代表作者观点，不代表MarsBit官方立场。

小编：记得关注哦

来源：Jon Charbonneau

原文标题：Decentralizing the Builder Role

简介

根据Vitalik在《Endgame》中提出的观点，所有的道路似乎都通向：

• 中心化的区块生产
• 去中心化和无信任的区块验证
• 审查制度仍然被阻止

中心化的建设者仍然不是很理想，那么我们能不能做得更好呢？有两种方法解决这个问题：

有许多建设者的去中心化市场：确保建设者市场具有竞争性，没有根深蒂固的各方。

去中心化建设者角色本身：使获胜的建设者本身成为一个去中心化的协议。去中心化的参与者都会为构建特定的区块做出贡献。

本文将主要围绕Vitalik最近在SBC MEV研讨会上的演讲展开。我将对此进行分解并提供进一步的分析。

去中心化的建设者能够获胜吗？

这里有两个潜在的问题：

• 技术可行性：将在下文对此进行介绍
• 竞争力：用户是否真的愿意使用它？或者说中心化的建设者在功能和效率上是否总是比去中心化的建设者更胜一筹？

去中心化什么?

成为中心化建设者很容易。下面考虑了分布式建设者需要在多个搜索者和用户之间聚合bundle和交易的一些可以去中心化的设想：

• 算法——建设者运行算法来聚合搜索者的 bundle和其他交易，然后自己填充区块的其余部分。该算法及其输入是去中心化的。(注意，这是以分布式建设者只运行一种算法的简单情况为前提的。实际上，不同参与者有可能在运行不同算法的同时贡献区块的不同部分。)

• 资源——资源需求将显著增加，特别是在Danksharding方面。区块将携带更多的数据，构建起来也更复杂→构建区块将需要更高的带宽和硬件要求。与其需要一个节点来构建和分发整个区块，不如将工作分配给许多节点。
• 额外的建设者服务——建设者可以发挥创意，提供交易预确认等新的服务。分布式建设者要想成功，就需要提供可以与集中式建设者竞争的服务。
• 订单流的访问——将订单流发送至单个建设者非常简单，并且可以为用户提供好处。将订单流的访问权分散给潜在的许多参与者则更为棘手。
• 隐私——分布式建设者需要一种方法来提供交易隐私，同时还需要在这个过程中纳入许多去中心化的参与方。
• 跨链执行——分布式建设者需要一种与外部参与者协调的方式来捕捉跨链MEV(例如，如果Y链上的交换是以原子方式完成，则只完成X链上的swap)。

挑战

如果我们想在整个区块生产供应链中避免可信的第三方，有几个障碍需要克服。我将在这里谈到的一些挑战包括：

如何保护搜索者免受MEV窃取？

• 如果建设者看到搜索者提交给他们的bundle，他们可以复制交易，然后用自己的地址替换搜索者的地址。建设者会捕获MEV，搜索者则没有奖励。
• 在PBS和MEV-Boost(加上一个中介可信中继)中使用的提交-披露方案从提议者←→建设者的关系中消除了这种MEV窃取威胁，但对于搜索者←→建设者来说，这是一个尚未解决的问题。搜索者目前只是信任建设者，但信任并不是一个可扩展的解决方案。

如何允许聚合机制来组合搜索者输入？

• 保护搜索者不被mev窃取意味着他们的bundle不能以明文发送。但如果它们不是明文，建设者如何将它们聚合起来呢?

如何确保聚合机制能够真正发布该区块？

• bundle的内容最终必须是透明的。从密文到明文的过程是怎样的?在没有信任假设的情况下，我们如何做到这一点?

如何保护搜索者免受聚合器+提议者的勾结？

想法1：可信硬件

这种方法利用可信硬件—TPM(可信的平台模块)。它是这样的：

在解密区块之前，TPM必须确信两件事：

• 提议者签名——对区块头的承诺可以防止提议者窃取mev。如果提议者试图在构建区块主体被揭示后为自己窃取MEV(通过提出一个替代区块)，任何人都可以提交其原始承诺。这证明提议者在相同区的块高度签署了两个区块→他们会被踢出局。
• 提议者签名的有效性证明——防止聚合器+提议者串通。仅仅存在提议者的承诺是不够的，它必须是可用的。如果只有聚合器收到承诺，他们可以简单地将其永远隐藏起来，让提议者提出一个替代的MEV窃取区块。TPM必须确信原始提议者签名实际上是公开的。

有几种方法可以证明提议者签名的有效性：

• 验证者——验证者可以验证是否看到提议者的签名，然后TPM可以检查提议者和这些验证者的签名。这需要更改以太坊协议。
• 低安全性的实时数据可用性oracle——像Chainlink这样的东西可以证明签名存在并将被重新广播的事实。
• 聚合器内的M of N假设——聚合器本身可以是一个分布式的M of N协议。在聚合器协议内可能有一个阈值投票，你对此会有一个诚实的假设。

想法2：合并不相交的bundle和顺序拍卖

合并不相交的bundle

这种方法需要N中的M个聚合器，但是我们可以去掉TPM。这个过程看起来像这样：

1. 搜索者发送的bundle被加密到一个阈值密钥。bundle包含一个访问列表(它们访问的帐户和存储slot的列表)和一个证明正确性的SNARK(注意技术复杂性以快速生成此列表)。
2. 聚合器合并不相交的bundle，使总出价最大化。(我们这里讨论的只是整合不一致的出价，但有可能进一步改善这一点。)
3. 聚合器必须计算state root

最后一步是棘手的。计算state root需要清楚地看到交易，或者至少看到它们的状态更新。然而，即使看到状态更新也足以进行mev窃取。对于何时计算状态，我们有两个选项：

1. 让一个聚合器节点解密，然后计算状态。但是，他们可以与提议者串通。
2. 只有在提议者承诺支持接收到的任何区块和state root之后，才会计算state root。该设置将利用EigenLayer。提议者发送一条链外消息，承诺他们生成的唯一区块会包含这组bundle(无论它们是什么)。只有在提议者做出承诺之后，bundle才会被解密，并计算出state root。如果提议者违反了这个承诺，他们就会被踢出局。

注意，这种EigenLayer结构还可以避免前面提到的SNARK要求。这里的提议者可以预先提交一个替代区块或替代区块组合，如果提交给他们的区块被证明是无效的，就会使用这个备选区块。第一个区块组合的无效性可以用欺诈证明来检查。

顺序拍卖

EigenLayer技术可以直接用于不相交的bundle合并，或者它也可以依赖于每个slot内的多轮顺序拍卖。

例如，以下情况可能在单个区块内发生：

第一轮

1. 提议者签署一个EigenLayer消息，预先同意一些交易(包括bundle1)，使他们在这一轮的出价最大化，以开始区块。
2. 建设者揭示区块的这部分内容
3. 提议者公布状态差异

第二轮

4.提议者签署一个EigenLayer信息，预先同意额外的交易(包括bundle2)，这使他们在这一轮的出价最大化，以继续区块

5.建设者披露该区块的这部分内容

6.提议者发布状态差异

第三轮……

一个缺点是这种合并可能是次优的。例如，提议者可能已经预先同意bundle1，然后他们将获得与bundle1冲突的更有利可图的bundle2。他们将不得不拒绝这个bundle2。

一个具有相同订单流的中心化建设者可以看到所有的交易，可以在他们构建区块的最后阶段包含bundle 2(因为他们没有预先同意bundle 1)。

另一个潜在的缺点是，顺序拍卖可能使非原子MEV相当困难，因为如果世界状态发生变化，搜索者将没有办法取消或更新他们的出价(一旦承诺)。如果你需要在交易被列入的前10几秒承诺，你就不能像保留更新出价的能力那样承担那么多风险。

然而，该示例假设订单流相同。在现实中，由于它提供的保证，分布式建设者可能会在接收更多订单流方面胜过集中式建设者。更好的保证→更多的订单流→建立最有利可图的区块(即使有其他缺点)。因此，提议者选择这种结构(切断自己接受其他建设者的区块)就有了经济意义，因为分布式构建者始终提供最高价值的区块。

要想成功，分布式建设者提供的价值可能需要超过它带来的缺点(包括合并效率较低和执行非原子MEV的挑战)。

区块构建后的Danksharding

Danksharding对验证者的节点要求很低。单个节点只负责下载区块的部分内容。

然而，最初提出的设计将有意义地增加构建以太坊区块的硬件和带宽需求(尽管验证者总是可以以分布式的方式重构)。那么问题来了，我们是否能以分布式的方式进行初始构建。这这样就不需要一个单一的高资源实体来构建整个区块、计算所有KZG承诺、连接到许多子网来发布它，等等。

实际上，以分布式的方式构建是非常可能的。分布式纠删编码并不是那么难。

首先，包含数据交易的人要负责对其进行编码，并将blob传播到子网和数据可用性网络。

当聚合器选择包含哪些数据交易时，它们可以使用实时DA oracle。聚合器本身不能仅凭自己进行数据可用性抽样(DAS)，因为当只有一方进行DAS时，这是不安全的。所以一些分布式oracle需要下载全部内容。

然后网络就可以从这里填写列。记住，数据是在2D模式中扩展的。例如，每个blob是512块，但它将擦除编码为1024个块。然后扩展也是纵向的。例如，你在图像中有32个blob，然后被垂直扩展成64个。多项式承诺在每一行的水平方向和每一列的垂直方向上都在运行。

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具有这种承诺线性和证明线性(IIPA和Merkle树不满足这两个条件)。

这里想说的是KZG有一些非常好的属性，允许分布式区块构建和重构。你不需要要求任何一方处理、扩展所有数据、计算所有KZG承诺并传播它们。它它们可以针对每行和每列单独执行。如果这样做，我们就没有剩余的超级节点要求：

额外的建设者服务-预先确认

以太坊的区块时间很慢，而用户希望有快速的区块时间。以太坊做出这样的牺牲主要是希望支持一个大型的去中心化验证者集。但我们能做到两全其美吗?

以太坊聚合用户已经开始了解并喜爱这些预先确认。建设者创新可以在基础层提供类似的服务。

例如，建设者可以同意：

• 如果用户发送了一笔优先级费用≥5的交易，建设者会立即发送一条可强制执行的签名消息，同意包含该交易。
• 如果用户发送了一笔优先级费用≥8的交易，建设者甚至提供了一个后置state root。因此，优先级较高的费用迫使交易以某种顺序被包含，让用户立即知道该交易的后果。

如果建设者不遵守他们的承诺，他们可以被砍掉。

在未来使用并行EVM时，你还可以使用更高级的预先确认。例如，只要用户关心的状态没有被更改，即使在给出预先确认之后，建设者也可以在区块内重新排序一些交易。

分布式建设者可以提供预先确认吗？

是的。分布式建设者可以只运行一些内部共识算法，比如Tendermint，它的区块时间很快。建设者可能会因以下情况而受到处罚：

• Tendermint机制内的双重终结性
• 签署了一个与Tendermint机制不兼容的区块

请注意，在这里需要对最终建设者签名进行某种类型的帐户抽象，以获得最好的安全性。阈值BLS是不可归因的，这意味着如果建设者只用BLS签署区块，我们不知道如果出现问题，谁应该被削减。抽象签名可以解决这个问题。

对于任何建设者预先确认服务(分布式或集中式)，请注意预先确认只与他们实际构建成功区块的能力相同。更主流的建设者和更高的纳入率可以提供更好的预先确认。

然而，你可以在分布式建设者处获得更强的预先确认，比如EigenLayer结构。如果当前的提议者选择了EigenLayer，并且你得到了预先确认，那么你的交易就必须被包含。你不再把赌注押在概率上。

分布式建设者的优点和缺点

假设所有的技术都是可行的，且一个分布式的建设者有成千上万的参与者。你甚至可以让Ethereum验证者中的很大一部分选择加入EigenLayer结构，提供亚秒级的预先确认。与集中式建设者相比，这种分布式建设者有一些不错的竞争优势：

• 经济安全——巨额保证金支持预确认服务
• 信任——搜索者对此的信任远远超过单一的集中式实体。
• 抗审查性——相对于单个集中式运营者的恶意行为，破坏和控制任何安全的分布式系统要更加困难

集中式建设者可能还有其他优点，有些是固有的，有些是基于分布式建设者的构造：

• 更快地适应新功能：适应市场需求的灵活性很有价值，这可能是上面描述的分布式建设者结构所缺乏的。理想情况下，你可以将来自多个方面的独特功能聚合到一个区块中。
• 更低的延迟：对于跨链的MEV来说尤其如此，因为搜索者更有可能希望在跨域的世界状态变化时更新他们的出价。(正如前面提到的，他们还希望在整个区块过程中灵活地修改出价。)

最后的想法

以太坊在很大程度上是基于最坏的假设设计的。然而，我们可以(也应该)同时努力避免这种最坏情况的假设。本文描述的两个想法提供了一些更有趣的可能性。然而，这些建议远远不是详尽无遗的。

此外，这不应该被视为“独占订单流的问题神奇地消失了，所以我们不再需要围绕它进行构建。”dApp必须继续围绕MEV在机制设计上进行创新，包括降低对排他订单流的需求。MEV是不会消失的。

责任编辑：Felix