Blob公证人：用于扩展DA的分片分布式Blob发布设计

作者：Nicolas, Lorenzo 和 Jonas，来自 Chainbound。

感谢 Francesco 和 Julian 提供的早期反馈！

或者，如何在以太坊中将 blob 数据传播 与 共识 分离。

TL;DR: 该提案源于最近关于分片 blob mempool 的讨论，旨在达到以太坊路线图中设定的中期扩容目标。可以总结为：

• 委托以太坊节点的一个子集来证明已经看到特定的 blob
• 将 DA 检查延迟到下一个 slot，以防止 DoS 并留出更多传播时间
• 在 EL mempool 中用轻量级的 DA 证书替换 blob 交易 sidecar

目录

1. 介绍
2. 现有提案
3. 提案：Blob 公证人

3.1. 全新的 Blob 交易流程

4. 此方法的益处
5. 与 ePBS (EIP-7732) 的兼容性
6. 开放性问题
7. 实现说明
8. 未来工作
9. 引用

1. 介绍

以太坊的 DA 扩容路线图主要关注通过 DAS（PeerDAS, Proto-Danksharding）在共识层上扩容 DA。这里的核心思想是，数据被安全地分片并分散在验证者集合中，并使用一些机制来确保所讨论的数据是真正可用的，而无需下载所有数据。这将使我们能够将 DA 扩展到每个区块可能包含数百个 blob。

但正如 Mike Neuder 在 最近的一篇文章 中所展示的那样，EL blob mempool（blobpool）并没有受到同样的关注。事实上，在今天的 blobpool 中，每个验证者仍然通过 lazy-pull 机制下载完整的 type 3 交易（包括 blob）。这种不对称性，即使今天不是问题，将来肯定会成为瓶颈。此外，CL 上的 DA 扩容最终会受到（本地）区块构建者的上行链路的限制，因为提议者需要上传整个 blob 包。我们稍后会看到，我们修复 blobpool 的提案也解锁了分布式 blob 发布。

2. 现有提案

已经提出了许多解决方案来解决上述不对称性。以下是这些方案的简要概述，以及它们的局限性：

• 弃用 blobpool：从 EL 中删除 blobpool，并依靠构建者提供私有的 blob 包含端点。这里的问题如下：

  • 我们需要一个公共 blobpool，以提高审查阻力 (CR)，因为没有它们，type 3 交易永远不可能成为包含列表 (IL) 的一部分。CR 总体上会更糟糕。
  • 构建者有责任尽快传播所有 blob，否则他们的区块可能会变成非规范区块。今天的 blobpool 也充当预提议 blob 分发机制。对于本地区块构建者来说，这可能会迫使他们根本不包含 blob，因为他们无法处理所需的上传带宽。更多信息请参见 这篇文章。
• 垂直分片 blobpool：我们可以简单地镜像 CL 上的结构，并要求 blob 发送者在传播他们的 blob 之前对其进行垂直分片。这里的主要问题是 DoS：恶意参与者可以用无效的分片（即不属于有效的、付费交易的分片，或者只是不完整的数据）淹没网络。研究人员提出了解决方案，包括 数据驱动的方法（即根据一些启发式方法限制发送 blob 的能力，以确保发送者不会垃圾邮件网络）和 市场驱动的方法（即使用链上拍卖来限制对 blobpool 的访问）。
• 水平分片 blobpool：blob 交易仍然像今天一样完整广播，但它们基于某些谓词（如发送者地址或交易哈希）在不同的 mempool 或子网中传播。这里的主要优点是它很简单，并且具有防 DoS 能力。但是，正如 Dankrad 在 这里 所指出的，它仍然需要（本地）区块构建者下载和传播所有 blob 才能提出它们。

最新的提案 基于垂直分片，但包含一个市场机制来确定谁可以写入 blobpool。这确保了发布 blob 始终存在前期成本，只有在包含完整的 blob 时才能收回该成本，从而解决了原始提案中的 DoS 问题。我们看到的主要缺点如下：

• 作为 blob 发布者：
  • 包含 blob 和实际包含 blob 之间存在延迟。
  • 放置投标的 execution gas 成本。
• 作为协议：
  • 在 L1 上运行拍卖可能会引入很大的复杂性
  • 使用以太坊区块空间和 gas 购买拍卖票可能不是很有效

3. 提案：Blob 公证人

我们建议引入一个新的委员会（Blob 委员会），它是验证者集合的一个随机子集，具有以下职责：

• 接收 type 3 交易（携带 blob）并验证它们
• 通过生成 blob 证书 （blob commitment 上的 BLS 签名）来证明 blob 数据的可用性
• 最终在 CL 上分片和发布列

我们将这些委员会成员称为 Blob 公证人。Blob 公证人能够隔离初始 blob 和交易验证，以防止全网范围的 DoS。此外，在区块生产期间，可以依靠它们作为临时 DA 预言机，因此可以消除本地构建和 PBS 提议热路径中的下载瓶颈。最后，他们可以通过在彼此之间分配工作来提高 blob 传播的吞吐量，从而解锁 分布式 blob 发布。

请注意，这个委员会最终可能会演变成一个独立的验证者角色，偏向更高的带宽使用，这与 rainbow staking 的精神一致。

3.1. 全新的 Blob 交易流程

我们将重点关注提案的 happy path，以避免复杂性而使文章混乱。但是，一些初步问题和答案可以在下面的 实现说明 中找到。

步骤 1：获取 Blob 仲裁证书 (QC)

\ shapes at 25-06-24 14.46.371668×1167 183 KB

• blob 发送者将 type 3 交易（包括 blob sidecar）gossip 到该 slot 的所有 blob 公证人。
• blob 公证人将在 pending 状态下验证交易，并回复他们在 blob commitment 上的签名。我们将此签名称为 Blob 证书。
• blob 发送者将这些 BLS 签名聚合为 2/3 多数，从而获得 blob 仲裁证书 (QC)。

此步骤确保在委员会成员之间，有足够多的诚实成员保管 blob 数据并证明该交易有效。QC 是对此的反映。但是，QC 的存在并不能保证网络级别的 DA，因为证明者尚未投票。它们可以被认为是“可信的信号”，但不能保证可用性。

步骤 2：广播到 EL Mempool

\ shapes at 25-06-24 14.49.141860×570 81.1 KB

• 获得 QC 后，blob 发送者可以在 EL mempool 上发送带有 QC 的 type 3 交易信封，而不是带有 blob sidecar 的 type 3 交易。
• 常规节点只需要传播带有轻量级证书的交易。
• 验证 QC 需要与 CL 进行一定程度的通信。设计空间非常大，但我们尚未找到令人信服的设计。有关更多详细信息，请参见 开放性问题 部分。

步骤 3：区块提议和证明

\ shapes at 25-06-24 14.59.082164×575 86.1 KB

• 提议者像往常一样在其区块中包含 type 3 交易。但是，它不会将 blob 包添加到信标区块信封中，而是会添加 blob 的 QC。这包括 BeaconBlockBody 容器上的一个新字段 blob_quorum_certificates。
• 信标区块信封不再包含此处的完整 blob 包。
• 当证明者收到新区块时，他们不会立即验证其 QC 的可用性，而只会验证区块的执行（稍后会详细介绍）。
• 如果该区块及时收到足够多的有效投票，它将像往常一样成为规范区块。

步骤 4：blob 分片传播

\ shapes at 25-06-24 15.09.582142×1524 218 KB

• 现在证明者已经投票并将新区块添加到其规范链中，blob 公证人可以开始通过垂直分片将 blob 数据传播到网络的其余部分。
• 任何节点都可以立即验证这些分片是否有效，因为它们属于 commitment 包含在链的头部区块中的 blob，并带有有效的 QC。这可以防止上面 现有提案 中确定的 DoS 向量。
• Blob 公证人已经签署了规范区块中的 blob，因此他们有充分的动力在 数据可用性证明截止日期 之前共享数据。

步骤 5：DA 证明

\ shapes at 25-06-24 15.22.271920×1474 86.1 KB

• 下一个 slot 开始，证明者被要求对两件事进行投票：
  1. 该 slot 中提议的区块 (区快 N) 的有效执行
  2. 上一个 slot 中提议的 blob 的数据可用性 (区快 N-1)
• 从逻辑上讲，这些被认为是两个证明事件，但在实践中，我们可以将证明视为适应一种新的、更复杂的 fork-choice 规则：
  • 区块 N 的 执行 必须 有效，并且区块 N-1 的 数据 必须 可用。
• 这种机制允许花费整整一个 slot 的时间来传播 blob 分片：大约从上一个 slot 的证明截止日期到当前 slot 的证明截止日期。

4. 此方法的益处

1. 高 blob 吞吐量

以太坊中的 Blob 吞吐量受到以下因素的限制：

• 验证者（包括solo-staker）需要在提议时上传整个 blob 包
• 在 PeerDAS 之后，提议者仍然只有有限的时间在 CL 中传播 blob 分片

我们的提案尝试通过传统的扩展方法来解决这些限制：

• 水平扩展：通过拥有许多 blob 公证人而不是只有一个提议者，网络的累积 blob 上行链路可以高出几个数量级。
• 垂直扩展：通过为 blob 公证人指定一个特定的网络角色（à la rainbow staking），我们可以扩展他们的硬件/带宽要求，而不会损害可信的去中心化证明者集合的良好特性，例如审查和共谋抵抗。

2. CL 上没有 blob 分片垃圾邮件

如果 CL 节点收到不属于任何最近 blob 的分片，它们可以拒绝它，并对共享它的对等方应用必要的声誉惩罚，从而最大限度地减少 DoS 潜力。

作为一项额外的好处，将 DA 检查延迟到下一个 slot 也会最大限度地提高数据及时可用的可能性，因为 blob 公证人现在有整整一个 slot 的时间（大约从上一个 slot 的证明截止日期到当前的 slot 证明截止日期）来传播分片。

3. EL 中更便宜的 blob 交易替换

目前，替换 type 3 交易非常昂贵（例如，Geth 需要 100% 的手续费增长）。这主要是因为网络必须承担在 EL mempool 中传播完整 blob sidecar 的成本。有了 blob 委员会，EL mempool 中的交易只会携带轻量级的 QC，从而使交易替换与其他交易类型一样便宜。

4. 更低的包含 blob 的“延迟成本”

今天的 PBS 中的 blob 交易需要支付间接延迟成本。这是因为具有更多 blob 的区块 需要在 PBS 拍卖中与更轻量级的区块竞争。通过此提案，具有更多 blob 的区块只会对其证书产生边际大小的增加。

5. 对 type 3 IL 交易的简单支持

由于完整的 blob 在 EL mempool 中被轻量级的 DA 证书替换，type 3 交易变得更小，并且可以被 FOCIL 支持。验证 QC 将成为验证 IL 的 CL P2P 验证规则 的一部分。

5. 与 ePBS (EIP-7732) 的兼容性

当前的 ePBS 规范允许将执行和 DA 证明转移到同一个 slot 中，从而允许使用更简单的 fork-choice 规则。但是，由于 QCs 没有自然的“commit”阶段，节点必须依赖较弱的保证来对抗 DoS。

本质上，blob 公证人需要等待 payload 发布后才能开始传播 blob 分片。这样，接收节点就可以验证它们接收到的数据实际上是它们刚从对等方接收到的 payload 的一部分。任何不属于 payload 的分片都将被丢弃，并且发送者将累积负面声誉。为了解决数据竞争，节点甚至可以在判断最近接收到的分片的有效性之前等待 payload。

以下是 slot 结构，遵循最近的 double deadline PTC vote ePBS 设计：

\ shapes at 25-07-07 16.07.432025×772 70.9 KB

证明者会将红色 X 之前收到的 Blob 分片缓存一小段时间，一旦 payload 到达，他们就会对其进行验证。如果它们与 payload 中包含的任何 blob commitment 不匹配，则可以将其丢弃并惩罚发送对等方。如果它们有效，则可以将它们广播给其他对等方。这样，常规证明者只会在知道他们正在传播有效数据时才参与扇出，这是理想的。

6. 开放性问题

1. blob 公证人很可能需要比常规证明者更高的带宽。网络应该如何处理低性能的公证人？他们是应该简单地错过奖励还是被削减？网络如何可靠地检测（较差的）性能？
2. blob 公证人是否应该因其在协议中的工作而获得公平奖励？如果是，该怎么做？
3. 如何在 EL mempool 中验证 QC？任何解决方案都需要将 CL 数据通信到 EL；以下是我们想到的一些可能的选项：
   1. 我们可以将 blob 公证人密钥存储并更新在定期更新的系统合约中，并在新的 EIP-4844 变体中以及 QC 一起在 EL 上广播聚合位列表（有点类似于 EIP-4788）。
   2. 现有的引擎 API 可以通过经由端点 engine_newQuorumCertificates 定期发送 (tx_hash, quorum_certificates) 元组来扩展。当在 devp2p 上收到 type 3 交易公告时，只有在已经从 CL 听到了该交易哈希时才提取该交易。
   3. devp2p 中没有 QC 验证，但是当下一个提议者从 EL 数据创建一个区块时，在 engine_forkchoiceUpdated PayloadAttributes 中，我们还会发送 CL 客户端已经验证过的 QC 列表。虽然这仍然可以确保有效的交易提议，但它可能会在 EL mempool 中引发一些 DoS 问题。
4. 在此模型下，私有 blob 提交给区块构建者将如何工作？
   1. 或许可以保留当前的 blob 交易管道作为后备，然后构建者可以使用它来包含 blob。本质上，这意味着可以通过在提议中提供其全部内容或有效的签名 QC 来包含 blob。如果信标区块信封携带一些完整的 blob，则该 slot 的区块构建者和提议者将承担及时分发数据以进行 DA 证明的额外风险。可以通过使私有 blob 的平均发送成本更高，来简单地通过 PBS 市场吸收此额外风险，这也符合不通过增加带宽要求来限制常规证明者的愿望。
5. 对于证明、缺少 DA、blob 公证人奖励等的故障情况仍然在很大程度上是不确定的！

7. 实现说明

1. 关于 EIP-4844 交易信封和证书

我们引入了一个新的 EIP-4844 交易变体，该变体携带 仲裁证书 而不是 blob sidecar。已签名的交易信封不会改变，因为它今天已经不包含 sidecar，而是将 QC 视为一个新的共识层项目。

以下是我们想象 blob 如何存在于协议中的简要概述：

• 带有完整 blob sidecar：仅在 EL 上的 RPC 层（用户摄取所必需）
• 带有 QC：当交易可以被包含时，在 EL mempool 中

注意：我们不建议创建新的交易类型。EL 规范已经涉及如何看待 EIP-4844 交易的不同表示形式：一种带有 blob sidecar，一种不带 blob sidecar。我们建议添加一个新的变体：不带 blob sidecar 但 带有 QC。

2. 恶意用户可能会将 type 3 交易发送给 blob 公证人，但随后从不在 mempool 中提交交易，从而浪费 blob 公证人的资源

• 为避免这种情况，我们可以利用信标链中 聚合器 的角色来提供冗余，以便他们中的任何一个都可以代替 blob 发起者在 EL mempool 中提交有效的交易；这看起来类似于当前的证明子网聚合器，在委员会成员之间随机选择。
• Blob 聚合器在提议流程的步骤 1) 中履行其职责。在步骤 2) 中，聚合器可以在 mempool 中发送 blob 交易以增加冗余。

3. 为什么要分离两个证明（执行和 DA）？

• 这个想法是，通过这种区分，仍然挂起的 blob 分片将不允许进入 CL P2P 网络，从而最大限度地减少整体的 DoS 向量。
• 增加的好处是用于传播数据 更 长的时限，这可以很好地随着吞吐量的增加而扩展。

8. 未来工作

• 我们计划研究与目前计划用于 Glamsterdam 硬分叉的其他 EIP 的兼容性，例如 EIP-7886：延迟执行 和 EIP-7782：减少区块延迟中提出的六秒 slot 时间。
• 我们想根据现有的 p2p 数据和新的 slot 截止日期，提出此技术允许的吞吐量的理论基准。
• blob 公证人的要求和经济学也是一个有趣的话题，但超出了技术规范的范围，但很高兴能进行探索。

9. 引用

• 关于 blob mempool 的未来
• Payload-timeliness committee (PTC) – an ePBS design
• Estimating Validator Decentralization Using p2p Data
• Decoupling throughput from local building
• Time, slots, and the ordering of events in Ethereum Proof-of-Stake - Paradigm
• EIP-7886：延迟执行
• Sharded blob mempool and distributed block production - HackMD

• 原文链接： ethresear.ch/t/blob-nota...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～