使用 FullDASv2 加速 blob 扩容（包含 getBlobs、内存池编码，以及可能的 RLC）- 网络

TL;DR

• FullDAS 是一种基于二维纠删码的 DAS 构造，具有单元级别的消息传递功能，旨在将 blob 数量扩展到 200+ 范围。它基于两个流水线阶段：分散到保管，以及从保管处抽样，从而最大限度地减少两个组件中的扩散延迟。
• FullDASv2 展示了如何将 FullDAS 与 EL blob 扩散 ( getBlobs)、EL blob 编码和 RLNC 编码相结合。
• 带有 getBlobs 的 FullDASv2 进一步提高了本地构建和带宽效率，即使在分片或分段的 mempool 情况下也能进行重建。这种组合还允许混合了私有和公共 blob 的区块从 getBlobs 中受益。
• 我们提出了一个新版本的 getBlobs (v3)，带有一个流式接口，以使协同效应更好。
• EL blob 编码 具有与 PeerDAS 中相同的效果，从而减轻了区块构建者和使用 getBlobs 的节点的计算负担。
• 使用 RLNC (Random Linear Network Coding) 而不是 2D RS 码是一种选择，但它带来了一些妥协，因为我们可能会失去行/列修复的优势，从托管到采样的单元级别流水线的延迟优势，甚至无法有效利用 p2p 重新分配的可能性。我们讨论了几种设计方案，以及它们各自的优缺点。
• 最后，我们分析了将 DAS blob 数量扩展到 200+ 范围时潜在的网络瓶颈，得出的结论是原始带宽不是主要问题。相反，我们应该关注的是每个消息的处理和信令开销。

介绍

大约一年前，我们发布了我们的 FullDAS 设计，基于二维纠删码，目标是每个 slot 32MB 数据（256 个 blob），包含以下要素：

1. 一种用于分散到保管的有效协议，使用
   • 单元级别消息传递
   • 基于位图的行/列/单元 ID gossip
   • 基于网络内部的即时纠删码恢复
   • 行和列之间的交叉转发以实现可用性放大
   • 批量发布 以减少或消除发布者的带宽开销
   • 推-拉阶段转换 以减少或消除 p2p 网络中的带宽开销，同时保持低延迟并继续分配负载
2. 一种快速且轻量级的协议，用于从保管处采样，使用
   • 单元级别消息传递
   • 用于提高采样安全性的本地随机性
   • 从保管处快速传递样本
   • 改进的和自适应的采样，带有 LossyDAS
3. 一种基于行和列 ID 的新对等发现结构，以消除连接延迟

实际上，该设计的几个部分自 2022 年以来一直在制作中，首先在 EthereumZurich’2023 上展示。

自我们发布以来，一些技术已经实现了（网络内部修复，批量发布），一些技术越来越受欢迎（GossipSub 中的推-拉，单元级别消息传递），而另一些技术仍需要讨论，并证明它们有用，或者被其他东西取代。这篇文章的目标是提供一个更新，希望能加速 blob 扩展的时间表。

我们关注四个关键方面：

1. 通过 getBlobs 连接 EL 和 CL 中的 blob 扩散路径（也为 getBlobs v3 提出更改）
2. 单元级别消息传递的实用性，也考虑到 getBlobs
3. blob 编码，就在 mempool 中
4. 二维编码本身，使用 Reed Solomon (RS) 码的优势，以及可能的替代方案，例如 RL(N)C

最后，我们通过考虑 EL 和 CL 中与网络相关的扩展瓶颈来结束本文。

GetBlobs，以及更好的 GetBlobs（v3？）

自从我们最初的 FullDAS 文章发布以来，引入了 getBlobs 引擎 API 调用，以连接 EL（mempool gossip）和 CL（DAS 扩散）中 blob 的扩散路径。这也改进了我们的 FullDAS 方案，如下所述。

在 DAS 编码方案中，blob 变成行，而列“横切”包含在区块中的所有 blob。当前版本的 PeerDAS（本质上是 SubnetDAS）基于列级别的消息，这意味着网络层看到的单位是一整列。而 GetBlobs 是面向行的。这种不匹配在系统中造成了两个效率低下的问题：

• 无法进行列重建：虽然实现 PeerDAS 的节点可以使用 getBlobs 从 EL 获取行，但只有当相应的 EL 节点在其 mempool 中拥有所有 blob 时，它才能创建一整列。虽然在当前的 mempool 中，对于带有公共 blob 的区块来说，这种情况几乎总是成立的，但正如我们在 mempool 分析中展示的那样，随着 blob 数量的增加，这种情况很可能不会发生。如果 EL 仅丢失一个 blob，则无法创建列，并且 getBlobs 变得毫无用处。
• 无法重建单个行：一个节点只有在拥有该行的 K 个单元格时才能按行重建。但是由于它只能将单元格作为整列的一部分获取，因此它只能在拥有 K 列时重建，也就是整个数据。换句话说，只有“超级节点”才能参与重建。

引入基于 getBlobs 的列重建

相反，在我们的 FullDAS 设计中，节点可以从 EL 中提取 blob，甚至是一个 blob，并开始在列主题上 gossip 它的单元格（也在行主题上，但现在不太重要）。根据节点的托管列，这可能采取两种形式（但这只是进一步的优化）：

• 如果节点订阅了一个列主题，它可以直接将单元格推送到其邻居。与流行的看法相反，与在 GossipSub 上接收单元格并转发它的基线情况相比，这不会在系统中产生额外的开销。
• 如果节点未订阅列主题，它仍然可以推送单元格，或者至少 gossip 单元格的可用性。我们认为后者是一个更好的选择，以低成本启用额外的网络恢复路径。

结果是，即使没有拥有所有 blob 的节点，也可以重建列。

getBlobs 和私有 blob

有些人可能会说，是的，但是存在私有 blob（从未进入 mempool 的 blob，因为它们的 blob 携带交易来自构建者的私有交易源）。在这种情况下，如果没有纠删码的第二维度，列重建将是不可能的。但是，如果区块构建者开始发布来自纠删码行的单元格（下半部分），即使区块中包含一些私有 blob，getBlobs 也会变得有用。

无需“超级节点”

在当前的 PeerDAS 设计中，只有当一个节点拥有所有列的一半时，才有可能基于纠删码进行恢复。虽然在测试网和当前的 mainnet 上有这样的节点，但如果不需要这样的节点，协议会更加健壮。我们的带有单元级别消息的设计支持在没有“超级节点”的情况下进行恢复。实际上，任何托管单个行或列的节点都会在其正常活动中积极进行基于纠删码的恢复。

更好的 getBlobs（v3？）

虽然当前的 getBlobs 设计似乎足以满足这些用例，但我们可以使其更好。当区块到达时，CL 可以获得特定 blob 需要的信息（也有提案将此信息移动到区块头）。同时，EL 节点关于该特定 blob 的 mempool 的状态可能有所不同：

• 也许它已经到达
• 也许 EL 已经知道它，已经请求了它（请注意，携带 blob 的交易不会被推送，而是在 mempool 中宣布请求），但它没有到达
• 也许 EL 已经知道它，但尚未请求
• 也许 EL 从未听说过它。

由于 CL 对这些细节一无所知，因此它面临着决定何时调用 getBlobs 的问题。在这里，我们进入 getBlobs API 调用的语义。理想情况下，EL 会记下 CL 的请求，并以“流式”方式满足它，尽快发送 blob（或者，通知 CL 关于到达）。我们暂且将这样的流式接口称为 getBlobs v3。

EL 甚至可以做更多的事情，以更高的优先级处理请求的 blob，并从其对等方获取它们。

Blob 编码，就在 mempool 中

发生的另一个重要变化是，blob 现在直接在 mempool 中进行编码，更准确地说，是在将它们提交到 mempool 时进行编码。这有几个积极的含义：

• 首先，减少了构建者的负载。与 PeerDAS 的一维情况相比，我们仍然应该进行第二维的扩展，但是现在准备 DAS 数据结构的计算量较少。

• 其次，当节点使用 getBlobs 从 EL 获取行时，可以避免大部分计算。

除了这些直接的优势之外，还可能发生更深层次的结构性变化。通过将纠删码移动到 mempool，mempool 本身也可能变得有纠删码意识，我们可以开始考虑垂直分片和基于 EC 的采样，就在 mempool 中。

为什么（不）使用 RL(N)C 或其他代码来代替 RS？

我们的二维 RS 纠删码使用二元多项式对数据进行编码，其中每个单元格都派生为其行和列坐标的函数。这只是用一种复杂的方式说我们进行了两次纠删码。一次是在将携带 blob 的交易提交到 mempool 时，另一次是在组成区块及其 blob 矩阵时。

这种结构，带有二维 RS 码，允许我们修复单个列，单个行，并且即使在进行修复之前，也可以在行和列之间进行交叉转发，实现快速的可用性放大。

一年前，在我们的文章中，我们也暗示了使用其他代码，强调了我们使用的二维 RS 的一些属性，但没有详细介绍替代方案。由于最近其他代码，尤其是 RLC 越来越受欢迎（用于大型消息扩散，但尚未用于 DAS），现在是探索这方面的时候了。

将大型消息广播到许多节点（我们在区块中需要的）与分散到保管处（我们在 FullDAS 中所做的）之间的关键区别在于，在前一种情况下，每个节点都需要所有数据，而在后一种情况下，每个节点都有自己的兴趣，即它想要获取的数据子集。

RLC，用于大型消息，专注于广播服务。它没有上述的本地修复和交叉转发的属性。在基线 RLC 中，随机系数由发送者确定。这允许 RLNC，其中发送者可以随机组合先前的组合，作为多跳多路径转发的一部分。然而，将随机性留给发送者，很容易在发送者端被欺骗，通过生成线性相关的组合，这将阻碍甚至不可能进行解码。如果目标是解码，节点会注意到这个问题。但是如果目标只是像 DAS 那样收集片段，这可能会仍然不被注意到。

克服这个线性依赖问题的一个简单补救方法是让接收者选择随机系数。以交互方式，在一个查询中（让我们称之为 I-RLC），或者在其非交互式版本中，通过从接收者的 ID（NI-RLC）派生随机系数。然而，这样的设置使得即时重组（RLNC 中的 N）成为不可能。节点只有在收到足够的片段进行解码后才能生成新的组合，解码数据，然后根据需要进行重组。

另一个问题是，由于随机系数分布在整个单元格 ID 空间中，因此没有部分修复。一个节点需要收集（至少）与结构中的单元格一样多的原始单元格的线性组合。这就是为什么许多基于线性组合（甚至简单的 XOR）的代码限制了从中构建组合的原始元素（单元格）的数量和范围。可以想象，这就像将大多数系数强制设置为 0，并且只允许随机选择少数系数。这以降低编码效率为代价实现了部分修复。例如，LT 代码使用此技巧来实现有效的解码。我们称这个概念为 Resticted RLC (R-RLC)。

类似地，我们可以将 RLC 限制在列中（或行中），仅使用给定列的单元格中的线性组合，并将这些组合发送给托管该列的节点。这将允许节点在他们拥有足够的列单元格时立即进行恢复，这是一种部分恢复。但是，我们仍然无法在行和列之间进行交叉转发，因为列单元格的线性组合对行分布没有帮助。即使在解码列之后，交叉转发也将受到限制：解码同一列的节点都将具有相同的行元素，而不是不同的线性组合。

可以想到的另一个选择是使用类似于二维 RS 码的线性组合，具有预定义的扩展因子，并使系数依赖于行和列 ID ... 但是通过这样做，我们基本上会复制我们的 Reed-Solomon 码所做的事情。

那么我们能用 RLC 做什么呢？在这里，我们列出了设计空间中的一些选项，以及它们的优缺点。请注意，这仍然是进行中的工作，因此不要期望有一个比我们的基线（二维 RS 编码）更好的明确解决方案。

基于 RLC 的设计方案 1

我们保持行和列的分布不变，使用二维 RS 码，但是我们将采样更改为获取线性组合。这里的想法是授权采样节点在需要恢复时做更多的事情。

优点：

在最终的重建中，单个样本现在更有用。它不仅仅是一个单元格，而是给定列（或行）的所有单元格的随机线性组合。这意味着我们需要更少的样本来恢复一列，或整个区块，因为没有两个样本是相同的。构建此概率模型很容易（我们稍后会这样做），但更重要的是，欺骗节点更加困难。在 RS 情况下，我们可以选择 255（或 N-K-1）个单元格，并根据需要分发尽可能多的副本，但是仍然无法进行重建。在 RLC 情况下，一旦分发了 256 个 NI-RLC 副本，就可以保证解码。

缺点：

在我们的 v1 FulDAS 设计中，采样速度快的原因之一是托管节点可以在收到单元格时立即转发它。这使得采样在单元级别上“滞后”于分散到托管的 1 跳延迟。使用新设计，只有在节点拥有整个列（或行）的托管之后，才能发送样本。这比较慢。

基于 RLC 的设计方案 2

我们保留基于行和列的分布，但是我们使用 RLC 来做这件事。区块构建者将受限且可验证的 NI-RLC 发送给对托管列（或行）感兴趣的节点，并且这些节点以 p2p 方式转发它们，例如，使用 GossipSub。

然后我们像在设计方案 1 中那样进行基于 RLC 的采样。

优点：

• 我们没有混合 RS 和 RLC。

缺点：

• 就像在设计方案 1 中一样，我们减慢了采样速度。
• 基于 RLC 的行/列分布意味着我们无法在行和列之间进行交叉转发，这会导致更慢的扩散和更少的可用性放大。

基于 RLC 的设计方案 3

在这种设计中，我们改变了每个人（包括验证者和完整节点）的托管和采样的概念。

在我们最初的设计中，节点托管 blob 数据的整个行和列。但是，要保证概率保证，不必这样。具有可验证的、依赖于目的地的随机性的线性组合可以发挥相同的作用。

这种设计的问题在于，应该有人创建这些组合，并且只有区块构建者或拥有所有 blob 的节点才能做到这一点。因此，我们将失去 p2p 重新分配，并拥有一个客户端服务器模型。显然不是我们想要的。

优点：

• 我们拥有更强的、没有重叠的个性化样本。这比二维 RS 给我们的更强大，这意味着我们需要从网络收集更少的片段来重组原始数据。

缺点：

• 我们失去了 p2p 网络效应，区块构建者基本上充当整个网络的服务器。
• 节点只有线性组合，但没有人拥有原始数据的实际片段。虽然这在理论上是足够的，但在实践中，拥有数据本身（如在系统代码（如 RS）中）具有其优势。

由于没有 p2p 重新分配，这实际上不是一个可行的选择，只是选择方案 4 的前奏

基于 RLC 的设计方案 4

我们能否更好地结合基于 RLC 的概率保证、目的地强制的线性组合和 p2p 重新分配？

我们认为我们可以，通过构建受限制的线性组合 (R-RLC) 的分层结构，但为此我们计划撰写一篇专门的文章。

逐步将 blob 数量扩展到 256

那么我们如何从 6 扩展到 256？

通过识别瓶颈并引入克服它们的技巧，逐步进行。在 这篇文章 中已经概述了一条可能的路径，但现在我们可以添加更多细节。

瓶颈在 EL mempool 中吗？

人们通常认为公共 mempool 是扩展的瓶颈。在公共 mempool 中，我们使用纯 gossip（不要与 GossipSub 混淆）来分发携带 blob 的交易。拥有携带 blob 的交易的节点会将其对等方宣传交易 ID，然后由仍然需要它们的对等方提取交易。没有像 GossipSub 那样的推送，因此没有重复项。虽然这比基于推送的技术慢，但我们可以负担得起，因为 mempool 中的扩散的时间紧迫性较低。尽管如此，正如我们在 mempool 分析中展示的那样，扩散非常快。

如果我们现在采用一个 blob，它是 128 KB，和一个 slot，它是 12 秒，很容易看出一个 blob 大约花费 11 KB/秒（加上一些开销）给每个接收它的节点，无论是入口还是平均而言，也是出口。很容易看出，mempool 中有足够的空间来扩展 blob 数量。

即使某些节点无法负担得起这样的出口，mempool gossip 系统也是自适应的，将出口流量转移到具有上行链路容量的节点，从而即使在节点异构的情况下也能更好地利用系统中的聚合上行链路容量。

但即使节点无法负担得起这样的出口流量，会发生什么情况是 blob 不会在 mempool 中 100% 扩散，这不是问题，只是降低了 getBlobs 的效率。重要的是要在这里看到的是，使用 getBlobs，我们只需要几个节点就可以帮助启动 CL 扩散。我们不需要 90% 的节点，甚至不需要 10% 或 1%，只需少数几个节点。

如果没有 CL 中的单元级别消息传递，我们仍然会遇到一个可能的问题，因为随着我们扩展 blob 数量，拥有区块的所有 blob 的节点的数量可能会变得非常低。但是通过单元级别消息传递，我们也克服了这个问题。

我们如何克服 CL 中的瓶颈，其中延迟至关重要？

这里要强调的关键点是源处的带宽瓶颈与 p2p 扩散期间的一般带宽稀缺之间的区别。

区块构建者的上行链路瓶颈

如果我们采用天真的解决方案，即区块构建者必须发送每个 blob 的每个单元格的多个副本，则带宽要求会迅速升级。

幸运的是，我们有一些工具可以解决这个问题：

• 对于进入公共 mempool 的 blob，EL gossip 充当预先播种，并且这是免费的，甚至不消耗区块构建者的带宽，因为它不是 blob 的原始来源，而 blob 的原始来源很可能在另一个节点进入了 mempool。
• 区块构建者也不应发送多个副本，或者至少不应从那里开始。批量发布 和纠删码的结合也解决了这个问题。
• 使用 RLC 或 fountain code，可以尝试进一步优化此操作。但是与基于二维 RS 的设计相比，最终的差异可能很小，而且因为要使用这些代码达到最佳性能，还需要一个反馈循环来停止生成新片段，而我们（尚未）有这样的反馈给构建者。

区块构建者的上行链路可能是一个瓶颈，但是如果区块构建者依赖于公共 mempool，并且我们使用先前讨论的技术，我们可以使即使是低带宽节点也可以创建具有许多 blob 的区块。相反，如果有人使用私有交易源，则负担会变得更大。

p2p 瓶颈

这里 p2p 是指实际的 p2p 转发部分，其中利用了源节点以外的节点的上行链路带宽。

在这种情况下要澄清的最重要的事情是，DAS 分散的聚合上行链路带宽要求远低于 p2p 消息广播（如区块扩散）。虽然我们发送一个 32 MB 的区块，并且通过纠删码使其更大，但具有基本托管要求的完整节点仅下载 ~512 KB 作为行/列采样，以及 ~50 KB 作为单元采样。这些数字是每个 slot 的，因此我们说的是总共 ~50 KB/秒。

简而言之，带宽不是 DAS p2p 重新分配中的主要问题，除非我们必须处理大量重复项。

当然，存在 GossipSub 开销，但是如此处 和此处 讨论的，推-拉技术可以将此开销降低 2 倍甚至更多，而不会显着增加延迟。

那么瓶颈在哪里？

基于单元的模型最可能的瓶颈是在每个消息的开销中。这包括处理开销（如消息验证和纠删码），以及网络开销（如标头和消息 ID gossip）。

对于后者，我们提出了使用结构化消息 ID 和 IHAVE/IWANT 位图。这还有待指定和实现。

相反，对于处理开销，我们应该审查我们的网络堆栈并改进诸如批量验证之类的事情。我们可能最终不得不使用多单元消息而不是单单元消息作为妥协。混合模型，既使用列级别消息又使用单元级别消息也正在讨论中。

结论

FullDAS 仍在发展中，并且设计很可能会改变，但是我们已经拥有一系列可以逐步引入的技术，以逐步扩展 blob 数量。这些变化中的许多都是正交的，可以使我们可以支持的 blob 数量成倍增长，从而使我们能够快速扩展以太坊 blob 数量。

• 基于 RLNC 的替代 DAS 概念
• 用于 DAS 和分片 Blob Mempool 的新设计

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