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

信息来源自 substack，略有修改，作者Jon Charbonneau

编译：RR

简介

根据 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 是不会消失的。