如何实现区块构建者角色的去中心化？

本文主要围绕 Vitalik 最近的 SBC MEV 研讨会演讲而构建，并提供进一步的分析。

原文标题：《如何实现区块构建者角色的去中心化？这里有两种方法》（ Decentralizing the Builder Role ）

撰文：Jon Charbonneau

引言

快速回顾——本报告的一个关键主题是 Vitalik Buterin 在《终局游戏》一文中的想法，即所有前进道路似乎都通向：

• 中心化区块生产

• 去中心化和去信任的区块验证

• 继续提供抗审查

生产者 - 构建者分离（PBS）试图将中心化与构建者隔离（远离验证者），然后 以太坊 添加盔甲（例如 crList）以减轻构建者的审查权力。构建者自然会很老练，所以悬而未决的问题主要是他们的中心化程度。我们是在说 1 个构建者？还是 10 个？

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

• 拥有许多构建者的去中心化市场 —— 确保构建者市场在没有根深蒂固的参与方的情况下具有竞争力。许多构建者竞争并只获得很小的利润。这个角色变得非常商品化。这需要解决诸如排他性订单流之类的问题，否则这些问题可能会巩固单个构建者。

• 去中心化构建者角色本身 —— 使获胜的构建者本身成为去中心化的协议。一组去中心化的参与者都有助于构建一个给定的区块。

本报告主要围绕 Vitalik 最近的 SBC MEV 研讨会演讲而构建。我将把它分解并提供进一步的分析。

去中心化的构建者能胜出吗？

这里实际上有两个潜在的问题：

• 技术可行性——我将介绍一些可行的路径（存在其他可能性，并且正在积极探索中）

• 竞争力——用户真的想使用它吗？或者一个中心化构建者总是会在功能和效率上胜过去中心化构建者？

去中心化什么？

中心化构建者很容易。下面考虑了一些可以去中心化的分布式构建者，需要在许多搜索者和用户之间聚合捆绑和交易：

• 算法 - 构建者运行算法来聚合搜索者的捆绑包和其他交易，然后自己填写区块的其余部分。该算法及其输入可以分散。（请注意，这里假设分布式构建者仅运行一种算法的简单情况。实际上，分布式构建者中的不同参与者可能在运行不同算法时贡献区块的不同部分。）

资料来源：基于 Vitalik Buterin 的图片

• 资源 - 资源需求将显着增加，尤其是使用 Danksharding。区块将携带更多数据并且构建起来更加复杂→构建它们的带宽和硬件要求更高。不需要一个节点来构建和分发整个区块，而是可以在多个节点之间拆分工作。

• 额外的构建者服务——构建者可以发挥创意并提供新的服务，例如交易预确认。为了使分布式构建者取得成功，他们需要提供与中心化构建者相比具有竞争力的服务。

• 访问订单流（orderflow）——将订单流发送给单个构建者非常简单，并且可以为用户带来好处。也许他们承诺不抢跑你的交易，他们可以在你后面给你一些回扣。在潜在的许多参与者之间分散对订单流的访问是比较棘手的。

• 隐私——同样，相信您的订单将私下执行的构建者是最容易的，因此您可以将其发送给他们。分布式构建者需要一种方法来提供交易隐私，同时在此过程中还包括许多去中心化方。

• 跨链执行——分布式构建者需要一种与外部参与者协调以捕获跨链 MEV 的方法（例如，如果链 Y 上的交换将以原子方式完成，则仅在链 X 上完成交换）。

挑战

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

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

如果建设者看到搜索者提交给他们的捆绑包，他们可以复制交易，然后用他们自己的地址替换搜索者的地址。构建者在不奖励搜索者的情况下捕获了 MEV。

神圣（enshrined）PBS 和 MEV-Boost（加上中间可信中继）中使用的提交披露方案从提议者 ←→ 构建者关系中消除了同样的 MEV 窃取威胁，但对于搜索者 ←→ 构建者来说，这是一个未解决的问题。搜索者目前只信任构建者，但信任不是可扩展的解决方案。

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

保护搜索者免受 MEV 窃取意味着他们的捆绑包不能以明文形式发送。但是，如果它们不在明处，那么构建者如何聚合它们呢？

如何保证聚合器机制能够真正发布这个区块？

捆绑内容最终必须明确。从密文→明文的过程是什么，我们如何在没有信任假设的情况下实现这一目标？

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

请注意，这并不是构建分布式构建者所面临的挑战的详尽列表。还有其他悬而未决的问题（例如，您如何防止分布式构建者受到他们被迫模拟的大量不良捆绑包的 DDOS 攻击？）和未知的未知数。

想法 1 - 可信硬件

一种方法利用可信硬件 - TPM（可信平台模块）。排序如下所示：

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

• 提议者签名 - 这种对区块头的承诺（没有看到区块体）防止提议者窃取 MEV。如果提议者在构建者区块体被公开后（通过提议替代区块）试图为自己窃取 MEV，任何人都可以提出他们最初的承诺。这证明提议者在相同的区块高度签署了两个区块→他们被削减了。

• 提议者签名的可用性证明 - 防止聚合者 + 提议者串通。提议者的承诺存在是不够的——它必须是可用的。如果只有聚合器收到承诺，他们可以简单地永远隐藏它，允许提议者提出替代的 MEV 窃取区块。TPM 必须确信最初的提议者签名实际上是公开的。

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

• 证明者 - 验证者可以证明看到提议者签名，然后 TPM 可以检查提议者和这些证明者签名。这需要更改以太坊协议。

• 低安全性实时数据可用性预言机——像 Chainlink 这样的东西可以证明签名存在并将被重新广播的事实。

• 聚合器内的 M of N 假设 - 聚合器本身可以是分布式 M of N 协议。聚合器协议中可能存在阈值投票，您对此有一个诚实的假设。

想法 2 - 合并不相交的捆绑包和顺序拍卖

合并不相交的捆绑包

这种方法需要 M of N 聚合器，但我们可以摆脱 TPM。该过程如下所示：

• 搜索者发送加密到一个阈值密钥的捆绑包。捆绑包包含访问列表（他们访问的帐户和存储槽的列表）和正确性 SNARK（注意快速生成此内容的技术复杂性）。

• 聚合器合并不相交的捆绑包，使总出价（bid）最大化。（我们在这里只讨论聚合不相交的出价，但有可能进一步改进这一点。）

• 聚合器必须计算状态根

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

• 让一个聚合器节点解密然后计算状态。但是，他们可以与提议者勾结。

• 只有在提议者承诺支持接收到的任何区块和状态根之后，才计算状态根。这种设置将利用 EigenLayer - 提议者让自己受到额外的削减条件才能参与。提议者发送一条链下消息，承诺他们将依次生成的唯一区块是包含这组捆绑包（无论它们是什么）的区块。只有在提议者做出承诺之后，捆绑包才会被解密，并计算状态根。如果提议者违反了这一承诺，那么他们将被削减。

请注意，对于此 EigenLayer 构造，也可以避免前面提到的 SNARK 要求。这里的提议者可以预先提交一个替代区块或替代区块组合，如果提交给他们的区块或替代区块组合被证明是无效的。然后可以使用一个欺诈证明来检查第一个区块组合的无效性。

顺序拍卖

EigenLayer 技术可以直接用于不相交的捆绑合并，或者它可以依赖于每个插槽内的多轮顺序拍卖。（请注意，如果需要，也可以在此顺序构造中避免 SNARK 要求。）

例如，以下可能发生在一个区块中：

第 1 轮

1. 提议者签署一个 EigenLayer 消息，预先同意一些交易（包括捆绑 1），从而在这一轮中最大化他们的出价以启动区块

2. 构建者公布该区块的这一部分

3. 提议者发布状态差异

第 2 轮

4. 提议者签署一条 EigenLayer 消息，预先同意额外的交易（包括捆绑 2），从而在本轮中最大化他们的出价以继续这个区块

5. 构建者公布该区块的这一部分

6. 提议者发布状态差异

第 3 轮…

一个缺点是这种合并可能不是最理想的。例如，提议者可能已经预先同意捆绑包 1，然后他们收到了与捆绑包 1 冲突的更有利可图的捆绑包 2。他们将不得不拒绝此捆绑包 2。

具有相同订单流的中心化构建者可以看到所有交易，当他们在插槽末尾构建区块时可以包含捆绑包 2（因为他们没有预先同意捆绑包 1）。

另一个潜在的缺点 - 顺序拍卖可能会使非原子 MEV 变得非常困难，因为如果世界状况发生变化，搜索者将无法取消或更新他们的出价（一旦承诺）。如果您需要在交易被包含之前 10 秒以上提交交易，那么如果您保留更新出价的能力，您将无法承担尽可能多的风险。

但是，该示例假定相同的订单流。实际上，由于它提供的保证，这种分布式构建者可能能够在接收更多订单流方面胜过中心化构建者。更好的保证 → 更多的订单流 → 构建最有利可图的区块（即使有其他缺点）。然后，由于分布式构建者始终提供最高价值的区块，因此提议者选择这种结构（切断自己接受其他构建器的区块）将具有经济意义。

为了取得成功，分布式构建者提供的价值可能需要超过它带来的缺点（包括效率较低的合并和非原子 MEV 的挑战）。

区块构建 post-Danksharding

Danksharding 使验证者的节点要求较低。单个节点只负责下载区块的一部分。

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

（注意：这个架构是否会使用子网或类似 DHT 的开放研究问题，但我会在这里假设子网）。

实际上很有可能以分布式方式构建。分布式纠删码甚至没有那么难。

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

当聚合器选择包含哪些数据交易时，他们可以使用实时 DA 预言机。聚合器不能只自己进行数据可用性采样 (DAS)，因为当只有一方进行 DAS 时，这并不安全。所以一些分布式预言机需要下载整个东西。

然后网络可以从这里填写列。请记住，数据在此 2 D 方案中得到扩展。例如，每个 blob 是 512 个 chunks，但它被擦除编码为 1024 个 chunks。然后扩展也垂直运行。例如，您在此处说图像中有 32 个 blob，然后垂直扩展为 64 个 blob。多项式承诺在每行水平和每列垂直运行。

资料来源：Vitalik Buterin

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 具有这种承诺线性和证明线性（IPA 和 Merkle 树，包括 SNARK 的 Merkle 树不能同时满足这两个）。

要更深入地了解以太坊的 2 D KZG 方案，您可以查看我的以太坊报告或 Dankrad 最近的 KZG 演讲。Vitalik 的这篇研究文章‌还谈到了将 KZG 与 IPA 用于 DAS 的考虑因素。

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

资料来源：Dankrad Feist 和 Vitalik Buterin

非 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 不会去任何地方。

特别感谢 Vitalik Buterin、Sreeram Kannan、Robert Miller 和 Stephane Gosselin 的审阅和意见。没有他们的工作，这份报告是不可能完成的。