通过 GossipSub 批量发布提升 DAS 性能 - 网络

作者: @cskiraly

本研究由 Codex Research Team 完成: @cskiraly, @leobago 和 @dryajov

TL;DR (太长不看)

• 通过应用 chunk/peer 调度技术，与使用 "标准" GossipSub 相比，我们可以在 DAS 中实现显著更低的延迟。
• 如果主要的带宽约束是发布者的上行链路，那么在发送出各个段的第一个副本后，这些段将很快在系统中扩散。因此，第一个副本应该被优先处理。
• 批量发布是一种在 GossipSub 中引入这种优先级的办法。
• 除了 GossipSub，类似的 chunk/peer 调度技术在其他为 DAS 设计的协议中也同样有益。

Intro (介绍)

在某些情况下，应用应该同时通过 GossipSub 发送多条消息。一个典型的例子是在 PeerDAS 和 FullDAS 中使用 GossipSub，其中一个较大的数据块被纠删码编码并分割成多个段（列、行或单元格），并且每个段都作为单独的消息发布在不同的 "列主题"（或行/列主题）上。

虽然这些消息可以按顺序发送，就像在今天的实现中那样一个接一个地发布，但将它们视为属于同一个 "批次" 的概念允许更高级的调度，从而带来显著的性能提升。

虽然我们过去曾在我们的 模拟器 和 演示文稿 中提到并使用过这种调度，但我们尚未提供专门的撰写。所以它来了。

The Problem (问题)

典型的 GossipSub 实现的问题在于，消息的排序是由发布 API 强制执行的。当一条消息被发布时，它会立即被发送（排队等待发送）到相关主题上的所有选定邻居。在可用上行带宽有限的情况下，最终结果是 "第一" 条消息会快速传播，而 "最后" 的消息将面临很长的排队时间，因此启动扩散的时间会非常晚，打破了消息之间 "扩散平衡"，而这些消息原本具有同等的优先级。

直观地说，很明显，在发布者发送出每个段的至少一个副本之前，整个数据无法在系统中扩散（为了简单起见，我们暂时忽略了纠删码和即时修复的影响）。如果某些部分通过容量有限的链路发送多次，则其他部分的扩散将不可避免地被延迟。因此，我们需要更好地控制消息发送的顺序。

Proposed Solution: Batch Publishing (提议的解决方案：批量发布)

我们可以使用 chunk 和 peer 调度技术来平衡各个段的扩散。我们的技术并非新事物，它显然受到了关于高效 p2p 分发文献和最佳实践的启发（例如，Bittorrent 中最稀有优先的 chunk 调度策略，或 一些其他与 chunk/peer 调度相关的文献）。

自我们开始进行 DAS 模拟以来，我们就一直在使用这种调度技术。事实上，调度很重要，无论使用 GossipSub 还是其他自定义的 pub-sub 协议，但在这里我们关注的是 GossipSub 方面。

虽然 chunk 和 peer 调度可能非常复杂，但在这里我们描述一种简单的策略，可以显著提高性能。主要目的是确保批次中每个消息的第一个副本在发送出第二个、第三个等副本之前发送到网络。换句话说，我们交错发布消息。这允许 p2p 重新分配尽可能快地发生，及时地在网络上分配负载。

我们建议引入 "批量发布" 的概念来描述和处理这种情况。批量发布的作用是明确地通知底层协议栈一组消息属于一起，允许该协议栈根据这些信息优化发布优先级。可以在 API 级别进行各种实现（在一个调用中传递所有消息，传递一个特殊的迭代器等），并且可以在底层实现各种调度技术。

一旦批量发布在 API 级别可用，调度策略的实现就相对简单了。一个简单的交错策略的原型实现在 nim-libp2p 中可用，我们使用它来获得下面展示的结果。

Simulations (模拟)

我们使用 Nim 版本的 DAS 模拟器，其中修改了 nim-libp2p GossipSub 栈，实现了批量发布。该模拟器基于 Shadow Network Simulator 框架。

我们用于性能比较的场景是一个同构的类似 PeerDAS 的场景（虽然很大程度上简化了）：

• blobs: 128KB 纠删码编码为 256KB
• blob 数量: 8
• 列数: 128
• custody: 16
• 节点数: 1000 (理想情况下我们应该使用 10000，但我们需要更大的模拟服务器，而 1000 仍然可以指示性能增益)
• 节点之间的网络延迟: 50ms
• GossipSub 度: 8
• 上行链路和下行链路带宽限制: 在 10 Mbps 和 100 Mbps 之间

上面的摘要图显示了平均 custody 时间 作为可用（对称）网络带宽的函数，包括传统的（顺序的）和批量发布。我们获取每个 999 个节点的 custody 时间（当所有 16 列都到达时），并对这些值进行平均。

正如预期的那样，当可用带宽较低时，批量发布具有巨大的优势，即使在较高的带宽下也有显着的优势。

为了更好地理解网络中发生的情况，我们还展示了传统和批量发布情况的详细图表。由于细节的程度，我们应该关注特定的带宽：我们选择 20 Mpbs 的场景。这些是密集的图表，有许多重叠的曲线，我们需要一些解释：

• per message propagation (每条消息的传播)：显示了每条单独消息的曲线（我们有 128 条），每条曲线显示了消息在网络中的扩散百分比作为时间的函数。扩散百分比是在订阅了特定列的节点中测量的。
• per peer custody progress (每个 peer 的 custody 进度)：显示了每个 peer 的曲线（999 条曲线），每条曲线显示了到达的 custody 列的百分比。100％ 表示所有 16 列都已到达。

请注意，顺序情况和批量情况的 x 轴具有不同的刻度。

当消息的第一个副本离开发布者时，曲线从每条消息图的底部开始。显然，这种情况在批量处理中发生得更早。一旦第一个副本发出，网络就有足够的带宽和 p2p 倍增效应来扩散单个消息，从而在短时间内实现给定消息的 100％ 扩散。

相反，每个 peer 的图向我们展示了 custody 进度在批量处理的情况下在 peer 之间是如何均匀的。在任何分位数（图上的水平切割）上，最佳和最差 peer 之间的时间差不超过 400 毫秒。仅在最后一步（从 15 列 custody 到所有 16 列 custody）中，该图才变宽。请注意，我们已经在 LossyDAS 文章 中引入了 "切断" 分布尾部的技术，并且类似的技术也可以在此处使用。

如果相反，我们查看顺序策略的情况，我们看到各个 peer 的 custody 进度之间的差异要大得多：几秒钟。

将使用不同的参数和异构场景进行进一步的实验，但我们希望批量处理在其他情况下也能提供显着的好处。

Sounds Great, but How Many Blobs? (听起来不错，但是多少个 Blobs？)

先前的模拟是在 8 个 blobs 的情况下运行的。在下图中，我们将 blob 的数量从 3 更改为 64，并绘制平均 custody 时间与可用网络带宽的函数关系图。这仍然是一个同构网络场景，但可以指示预期情况（另请注意，目前这是从单次运行中绘制的，因此曲线不平滑）。

\ image1076×500 65.2 KB

结果看起来很有希望，表明批量发布确实可以帮助增加 PeerDAS 中的 blob 数量。

将使用不同的参数和异构场景进行进一步的实验，但我们希望批量处理在其他情况下也能提供显着的好处。

Discussion (讨论)

批量发布只是我们准备用来提高 DAS 性能的技术之一。我们在 FullDAS 文章 和 演示文稿 中提到了其他几种可能性，并计划在将来提供更多详细信息。

通过所谓的 "交错发送" 可以实现与批量发布类似的效果，Tanguy 和 @Nashatyrev 过去对此进行了研究。我们认为批量处理的概念提供了更好的语义，并且允许比交错发送更好的调度。

在考虑可能的调度策略时，有很多方法可以使 上面描述的简单交错复杂化：

• Message order randomisation (消息顺序随机化)：批次中消息的顺序可以在迭代之间随机打乱。这样做的好处是可以从分发中消除更多的偏差。

• Per-message peer order randomisation (每条消息的 peer 顺序随机化)：关于单个消息的第一个、第二个等副本，我们可以随机化网格 peer 的顺序。这是为了确保负载在 peer 之间均匀分布。当然，随机化不是唯一可能的策略，只是最简单的策略。不同的 peer 可以在多个主题中成为网格邻居。基于计数器的策略可以提供更均匀的分布；如果有更多关于 peer 的信息（peer 分数、延迟、带宽估计等），则可以使用加权随机策略。

• Feedback based adjustment (基于反馈的调整)：在低上行带宽的情况下，很容易发生这种情况：当批次发布者开始发送第二个副本时，大多数消息已经扩散到网络中。关于单个消息的扩散状态的反馈（例如，通过 IHAVE 消息）也可能开始传入。这种反馈可用于优先处理一个消息的第二个、第三个等副本的种子，而不是另一个消息。我们注意到这种反馈是不可信的，因此在调整发送时间表时应格外小心。作为替代方案，还可以使用隐藏的受信任 "buddy" 节点来观察扩散状态。

如前所述，批量处理和 chunk/peer 调度不仅可以与 GossipSub 一起使用，还可以与发送多个副本的其他 pub-sub 协议一起使用。这对于基于 UDP 的协议是正确的，即使我们使用纠删码也是如此。一个值得注意的例外是使用 fountain 码或随机线性网络编码，其中没有副本。在这种情况下，peer 调度可能仍然很重要，但 chunk 调度不能直接应用。

批量发布的目标是减少发布者带宽瓶颈的影响，从而允许更好的家庭质押。即使可用带宽较高，它也能显着改善延迟。其他正在开发的技术，例如 分布式 Blob 构建 是我们技术的补充。

References (参考)

[1] 原始 PeerDAS 文章

[2] 我们的 FullDAS 文章

[3] DEVCON SEA 关于可扩展性的演讲

[4] libp2p Day 2024 曼谷演讲

libp2p in Ethereumfrom block diffusionto PeerDAS and FullDAS - Csaba Kiraly

[5] 批量发布原型实现

• PPPT: Fighting the GossipSub Overhead with Push-Pull Phase Transition
• FullDAS: towards massive scalability with 32MB blocks and beyond
• Doubling the blob count with Gossipsub v2.0
• Accelerating blob scaling with FullDASv2 (with getBlobs, mempool encoding, and possibly RLC)
• Improving column propagation with cell-centric erasure/network coding

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