DAS和分片Blob Mempool的新设计 - 分片

本文提出了一种数据可用性抽样 (DAS) 和分片 blob mempool 的新颖设计，旨在增强可扩展性，同时保持去中心化。传统的 Danksharding 策略假设一个区块构建者/提议者创建一个区块，对其进行纠删码编码，然后将完整的数据分发到整个点对点 (P2P) 网络。这在网络带宽方面要求很高，特别是对于小型家庭质押者，区块构建者和提议者是同一个节点。本文中的提案通过借助两个新思想来实现分布式区块构建 (DBB) 来克服这个问题：i) 分片 Blob Mempool，以及 ii) 部分列传播。

本文的其余部分组织如下。首先，阐明了作为此新设计基础的底层假设。然后，介绍了当前的 DAS 和 blob mempool 设计。最后，阐明了所提出的设计及其随之而来的好处。

假设

以下是我们在本文中使用的主要假设。

• 网络规模：目前以太坊的网络规模预计为 10,000 个节点左右。对于本文，我们假设网络规模将保持在 5,000 到 50,000 个节点之间，但理解这可能会在未来几年发生变化。

• 区块结构：我们假设所有数据 blob 都是由 512 字节的元素组成的，这些元素被称为“单元格”，然后使用纠删码（里德-所罗门）进行分组和扩展，以创建一个二维矩阵。

• 槽吞吐量：我们的目标吞吐量是每个槽 256 个 128KB 的 blob，在使用纠删码扩展之前，总计每个槽 32 MB。因此，在 2D 纠删码扩展后，大小为 128MB。

• 数据传播：Gossipsub 用于在 P2P 网络内的多个通道上，在共识层 (CL) 上传播数据。我们假设 Gossipsub 可以扩展到数千个主题及以上。

旧的 DAS 和 Mempool 设计

槽周期

一个区块及其 blob 的整个槽周期可以分为以下四个步骤来描述。

1. Mempool

在以太坊网络中，blob 通过类型 3 ( 0x03) 交易提交。自 Pectra 以来，该交易可以包含一个或多个 blob，最多九个。类型 3 交易通过 devP2P 网络进行 gossiped。这意味着，首先将交易的哈希值推送到所有节点，然后节点可以决定拉取交易和相关的 blob 数据，这些数据在 BlobTxSidecar 中传输。如果节点不希望下载，则不需要下载 type3 交易或 blob 数据。想要构建和提议区块的验证者节点应该监控网络上的交易，包括 type3，并且应该将所有 blob 下载到它们的 mempool 中。Blob 数据进入执行层 (EL) blob mempool，在那里等待包含到区块中。当节点被选择提议一个区块时，它将包含来自其mempool 的一些 blob, 假定它们的可用性已经得到验证。任何节点都可以选择下载所有 blob 数据用于其他目的（例如，监控、研究）。

2. 构建

一个区块由两个主要部分组成：执行 payload 和 blob 数据。执行 payload 不包含 blob 数据，它只通过 type3 交易引用 blob。区块构建者/提议者选择将哪些 blob 包含在区块中以及以什么顺序包含。在完全规模时，它选择每个槽最多 256 个 blob（每个 128KB），从而在纠删码之前总共产生约 32MB 的 blob 数据。区块构建者通过里德-所罗门编码水平和垂直地扩展这些数据，从而产生一个 128MB 的区块。

3. 传播

区块构建者/提议者将执行 payload 广播到网络以进行验证，并通过 Gossipsub 通道传播整个行和列。CL 节点仅保管（即存储）区块中所有行和列的一小部分。保管的行和列的数量由每个节点决定，但每个节点必须保管最少数量的行和列。一些节点可以决定保管所有行和列，这使得它们成为超级节点。CL 节点接收执行 payload，以及它们通过 Gossipsub 保管的整个行和列。CL 节点在它们的以太坊名称记录 (ENS) 中告知其他节点它们的保管大小。行和列是确定性地从节点 ID 派生的，因此任何节点都可以知道它的对等节点保管哪些行和列。

4. 抽样

CL 节点共同确保所有 blob 都是可检索的，而不需要每个节点都存储完整的区块 (128MB)。由于 blob 是使用纠删码扩展的，即使是部分 blob 数据也允许完全重建，如果可用数据足够的话。CL 节点执行随机抽样来验证数据可用性。每个节点选择一定数量的随机单元格从其对等节点进行抽样。它知道哪些对等节点保管哪些列/单元格，因此它可以向它们请求。或者，它可以将请求发送给多个对等节点，并让任何节点响应。

这种设计的缺点

• 想要构建/提议区块的验证者节点必须将所有 blob 下载到它们的 mempool 中。
• 区块构建者/提议者在生成一个区块时需要传播（即上传）所有经过纠删码的 blob 数据 (128MB)。
• Blob 在 EL 和 CL 上传播（作为行），导致冗余和带宽浪费。
• 整个行和列在网络上传播

新设计

想法和理由

这个新设计的主要目标有三个：

1. 减少 EL 节点需要在 blob mempool 中下载的数据量
2. 消除 EL 和 CL 之间存在的网络冗余
3. 减少 CL 节点需要上传以进行保管的数据量。

在本节中，我们介绍这个新设计中引入的新概念。

水平分片 Blob Mempool

每隔几秒钟下载数千万兆字节的 blob 数据可能会给互联网带宽有限的家庭质押者带来压力。因此，我们提出一种水平分片 mempool 设计，以便 EL 节点只需要下载部分 blob。主要思想是根据节点的节点 ID 和它们将存储的 blob 的 type 3 交易的哈希值对节点进行分片：当且仅当 type 3 交易的哈希值的最后 4 位与其节点 ID 的最后 4 位匹配时，节点才应该下载 type 3 交易及其相关的 blob。这创建了 16 个不同的分片，其中所有 type 3 交易和 blob 都是不相交的。EL 节点下载到其 mempool 中的相同 blob 是 CL 节点必须保管的相同行，因此无需通过 CL 网络下载行；它们可以通过从 EL 到 CL 的 getBlobs 获取。这意味着，对于每个槽，一个节点将根据 type 3 交易的哈希值保管不同的行。尽管如此，基于对等节点的节点 ID 和槽的执行 payload，计算对等节点对于给定槽保管哪些行 ID 应该相当简单。对于这个例子，我们使用了 4 位（16 个分片），但它不必是 4；它可以是任意位数的 B，将我们想要每个区块拥有的 256 个 blob 进行分片。这减少了网络带宽，同时在区块创建后加速了 CL 层的data传播。

\ image1415×651 71.1 KB

需要强调几个要点。由于行保管是基于 type 3 交易哈希的，节点必须存储的 blob/行数从一个槽到下一个槽并不相同，因为它取决于哈希和每个交易的 blob 数。然而，平均而言，所有节点在统计上存储相同数量的数据。相反，对于给定的槽，并非所有节点都存储相同数量的行。尽管如此，所有 blob 都平等地分布在节点中并被可靠地复制。这种策略通过消除 CL 中的 blob/行传播来避免 EL 和 CL 冗余。可以使用的另一种策略是验证者保管：要存储的 blob/行数可以与节点中的验证者数量成正比。例如，节点的基本要求可以是匹配节点 ID 的最后 B 位，而对于具有验证者的节点，它可以是匹配最后 B-1 位。具有更多验证者的节点可能更频繁地提议区块；因此，在它们的 blob mempool 中拥有更多 blob 可以帮助它们更快地构建区块。此外，在经济上，具有多个验证者的节点可能具有硬件和网络资源来保管更多的 blob/行。

部分列传播

列与 blob 的不同之处在于，它们只有在区块构建之后才知道。因此，只有在区块构建者/提议者决定包含哪些 blob 以及以什么顺序包含之后，才能传播列，甚至是部分传播。在这个提案中，CL 节点有一定数量的列要保管，并且列的精确索引是确定性地从节点 ID 决定的，就像在以前的设计中一样。这些列索引在节点的整个生命周期中保持不变。这意味着，与行相反，节点始终在每个槽存储相同数量的列，并且始终存储相同的列。行和列之间的这种不协调对于优化网络带宽利用率至关重要。 同时，它实现了强大的数据保管和快速抽样。

\ image1661×816 19.3 KB

与整个列传输相反，部分列传输是这个新设计的一个关键部分，因为使用水平分片 mempool, 大多数节点在收到执行 paypload 时将无法传播整个列。因此，部分列传输对于传播部分数据和加速区块扩散是必要的。例如，如果 blob mempool 被分成 16 个分片，那么为了获得完整的列，一个节点将需要在该列的 gossipsub 主题上接收 16 个部分列消息。通过在每个节点收到执行 payload 后立即传播部分列，网络不需要依赖于区块构建者/提议者的上传速度来获得它们各自的列。当区块提议者是上传带宽有限的家庭质押者时，这一点尤其重要。此外，即使所有 EL 节点在它们的 mempool 中拥有所有 blob 并共享完整的列以避免区块提议者瓶颈，它们仍然会上传整个列。相比之下，这种设计允许每个节点只发送 1/16 的列，从而减少带宽消耗。

新设计槽周期

1. Mempool

这个设计与现有设计的主要区别是引入了分片 mempool。在这个设计中，节点只下载一定数量的 type 3 交易和相关的 blob sidecar (即 blob 数据)。每个节点必须保管的 blob 是以确定性的方式从节点 ID 计算出来的，这样每个节点都可以知道为自己下载哪些 blob，以及它的对等节点保管哪些 blob。每个节点应该下载并在其 blob mempool 中存储的最小 type 3 交易数量。具有验证者的节点可以在它们的 blob mempool 中保管更多的 blob，类似于验证者保管。节点可以选择将每个 blob 下载到它们的 blob mempool 中，要么是因为它们有很多验证者，要么是因为它们需要它来完成它们的任务（例如，区块构建者、rollup、浏览器）。

2. 构建

目标是每个槽引入 256 个 128 KB 的 blob，总共 32 MB 的 blob 数据，在纠删码之前。有了这个新设计，区块构建者/提议者有一个有限的（即分片的）type 3 交易列表可以附加到它的区块。它可以决定只附加来自其受限列表的 blob。然而，还有另一种策略。由于区块提议者是提前知道的，一个必须在下一个 epoch 中提议区块的节点，可以暂时改变其 blob mempool 的行为，开始下载所有 type 3 交易和 blob，直到提议区块的那一刻，届时它们可以回到标准的 blob mempool 行为。

3. 传播

区块构建者/提议者应该传播的第一件事是执行 payload，其中包括附加到区块的 type 3 交易和 blob 的列表。

CL 节点需要保管（即存储）来自 EC 扩展区块的一些行和列。在这个设计中，我们建议 CL 必须保管的行应该与 EL 应该下载到它们的 mempool 中的相同 blob。通过这样做，我们确信，无论包括在区块中的 blob 是什么，每个遵循协议的 CL 节点都不需要在网络上接收任何水平行，因为它们已经在它们的 blob mempool 中拥有它。相反，它们可以通过纠删码水平地扩展它，并将其从 EL blob mempool 传输到 CL 保管存储。在这种情况下，没有节点，甚至区块构建者，应该通过 CL 网络推送水平行，因为没有必要，因为水平传播发生在 EL。如果由于某种原因（例如，网络或硬件故障），一个节点没有它应该在其 blob mempool 中拥有的 blob，它可以从其对等节点请求它们。

关于列传播，当 CL 节点收到区块的执行 payload 时，它知道哪些 blob 将被包括在区块中。由于该节点拥有区块的一些行，它也拥有该节点负责的一些列的单元格，但不是全部。因此，节点通过 Gossipsub 主题传播部分列，而不是发送整个列（除非它是一个超级节点）。这应该能够快速地从列主题中的所有对等节点检索列。一旦一个节点收到了来自非扩展列的所有单元格，它就使用纠删码垂直地扩展该列。此时，网络中的所有节点都应该拥有分配给保管的相应行和列。

4. 抽样

这个新设计中的抽样没有重大变化。一切都以与之前设计相同的方式发生。

一些数字

让我们假设在任何给定的时间，大约有一千个 type 3 交易，区块构建者可以从中选择将哪些交易引入到他们的下一个区块中。这使得想要在他们的 blob mempool 中拥有所有 blob 的区块构建者拥有大约 128MB 的 blob mempool。如果我们假设没有验证者的节点保管以与其节点 ID 相同的 4 位结尾的 blob，那么它们拥有 1/16 的 blob。平均而言，这相当于 1024 个 blob 中的 64 个 blob（约 8MB）。假设一个拥有 8,000 个节点和同质分布的节点 ID 的网络，每个 blob 将存储在大约 500 个节点上，提供足够的冗余和鲁棒性。感谢我们的爬虫，我们获取了当今网络中 EL 节点的当前列表，并按照这个设计对它们进行了分片。上图显示了每个分片中存在的节点数量。

\ image973×758 36.8 KB

我们还分析了从 Pectra（5 月 22 日）到 6 月 3 日（6107 个 epoch）的所有 type 3 交易，并根据它们各自的分片绘制了它们，以检查它们是如何同质分布的。总共有 254,097 个 Type 3 交易分布在 16 个分片中，如下所示。

\ image973×758 46.2 KB

类似地，我们验证了 707,923 个 blob 也同质地分布在各个分片中。

\ image987×589 18.5 KB

这不包括多验证者节点和超级节点。

实施这个新设计

• 为了实施本文中提出的水平分片 blob mempool 设计，EL 节点只需要做一个额外的检查，在拉取 type 3 交易之前验证哈希是否匹配。

• 对于列传播，我们需要实施部分列传输，以允许传播部分列。这可以像发送一个更短的(1/16) 列以及列中单元格位置的列表一样简单。

讨论

其他几种策略可以补充这个提案：

• 我们可以添加一个 blob mempool 票证，用于将 blob 引入到 blob mempool 中。该票证可以通过拍卖获得。blob mempool 票证的目标是限制注入到 mempool 中的 blob 数量，从而防止 DoS 攻击。然而，在这个设计中，blob mempool 是水平分片的，所以不太需要 blob mempool 票证。

• 区块构建者/提议者可以尽最大努力地传播所有数据（行和列）。虽然大多数数据列将通过部分传播从其他对等节点到达，但来自区块构建者的列可以用作备份策略。

• 节点应该使用 IDONTWANT 消息来减少单元格接收时的带宽。请注意，由于这些分片是不相交和确定性的，因此部分传播将始终传播完全相同的消息。因此，IDONTWANT 消息仍然可以在部分传播的上下文中使用。

• 由于列传播从所有节点同时开始，我们可以在最小化匿名性问题的情况下实施 push-pull 阶段转换策略。

致谢

这项研究是由 Codex 团队 完成的。我们要感谢 @dankrad 和其他 DAS 研究人员的反馈和贡献。

• 关于 blob mempool 的未来

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