`IDONTWANT` 对重复消息数量的影响 - 网络

介绍

这项工作是我们之前对重复消息数量进行的原始研究的后续研究，在采用 IDONTWANT 消息原语之前：

方法论

用于生成以下研究的数据是使用我们的 GossipSup 监听器 hermes 在 2025 年 5 月 27 日位于澳大利亚悉尼收集的。

注意：我们还分析了来自位于美国加利福尼亚州的第二个 hermes 节点的数据，以验证数字差异不大，情况确实如此。

采用 IDONTWANT

IDONTWANT 消息已经存在于 libp2p gossipsub 规范 中一段时间了，但并非所有实现都支持它们。从这个意义上说，Pectra 升级不仅仅是对以太坊协议的同步更新，它还显着增加了支持新控制消息的节点数。

截至 5 月 27 日，从我们的每周报告中，我们可以观察到大部分网络都支持 IDONTWANT（meshsub/1.2.0 版本的一部分）。在总 已发现节点 中，仅缺少约 5%（大约 400 个节点）。

\ image714×597 70.5 KB

当前的重复水平

从我们之前的 报告 中，当我们提到 beacon_blocks 主题时，我们发现了以下内容：

• 几乎没有没有重复的已记录消息（1%-2%）。
• 54% 的消息报告了来自 mesh 的预期 3 个重复项
• 查看 CDF 的尾部（显示在下面的下拉图中），有一些消息最多被接收了 34 或 40 次。

与之前的结果相比，我们目前的发现表明，在具有“足够大”的消息的主题中，重复项略有但明显减少（超过 1Kb msg size），即 beacon_block 和 beacon_blobs 主题：

• 在添加 IDONTWANT 之后，没有重复的区块数量从 2%（之前）增加到 9%。
• 在下面的图中，我们看到平均值的减少，现在保持在 2 个重复项，而不是之前的 3 个。只有 5% 的消息超过 4 个重复项。
• 重复项的尾部明显减少 - 我们之前在某些极端情况下测量到最多 34 或 40 个重复项，而现在，尾部停在 6-8 个副本。

在 IDONTWANT 之前：

\ image1000×600 66.9 KB

在 IDONTWANT 之后：

\ image582×347 44.9 KB

总的来说，我们看到的是，98% 的重复项在收到第一条消息后的第一秒内到达，79% 在半秒内到达，并再延长 400 毫秒，直到最后一个重复项到达。

\ image582×360 46 KB

消息大小和重复数量之间的相关性

下图显示了每个主题的消息到达和第一个重复消息之间的时间差。在图中，我们可以看到两种类型的主题之间的明显差异。beacon_block 通常具有比 blob_sidecar 更小的消息，或者至少 blob_sidecar 主题在消息大小方面不太稳定（检查下面的块大小分布）。

到第一个重复的时间：

\ image581×355 57.4 KB

当然，下图显示了消息大小的 CDF，我们看到信标块通常小于 sidecar。

\ image580×358 61.5 KB

因此，消息的大小与重复的数量之间存在很小的相关性。在查看下面的 CDF 图表时，我们看到较大的消息确实往往获得更高的副本数量，因为它们通常需要更长的时间才能通过网络传输。

\ image580×360 41.4 KB

注意：size_range 属于 X 到 X+19 KB 的范围

示例：size_range 0 包括 [0kb, 20kb)

IDONTWANT 的数量

方法论

此报告的数据来自位于澳大利亚的单个节点，已知该节点位于网络核心之外，具有更高的延迟和更低的带宽。但是，通过检查美国节点的 结果，我们发现非常相似的结果。

我们的目标是检查 IDONTWANT 消息是否实际发送，以及发送这些消息的时间。这两个都是相关的点，可以查看实现级别是否存在任何瓶颈。

结果摘要

重复项明显减少，但低于我们的预期 → 我们假设大多数重复项将通过 mesh 传播（[ D-2]( Gossipsub 网络直径估计)）

但是，我们没有测量到在消息低于阈值（1KB）的主题上发送任何 IDONTWANT 消息的迹象。

有趣的是，下图显示我们的控制节点发送的 IDONTWANT 消息数量与我们收到的重复项数量相似。这可能表明 IDONTWANT 没有我们预期的那么有效。

一种可能的解释是，我们及时将 IDONTWANT 发送给我们的 mesh 节点。但是，我们仍然收到我们刚刚发送 IDONTWANT 的消息，这表明该消息已经在网络中传输。

\ image582×350 44.9 KB

重复项何时到达

考虑到发送的 IDONTWANT 消息数量与收到的重复项之间的相关性，IDONTWANT 是否有用仍然不清楚。该节点可能以消息到达后很小但足够的时间延迟发送控制消息。因此，下图显示了发送 IDONTWANT 消息与第一条消息到达之间的时间差。该图显示，消息到达和 IDONTWANT 通知之间确实没有延迟。该图甚至显示了一些案例，在我们可以跟踪消息的“传递”之前，控制通知已发送。

注意：当通过 Deliver 通知读取消息到达时，我们会看到负时间，而不是通过 RPC 收到消息时。

\ image580×358 31.2 KB

在 IDONTWANT 消息之后是什么触发了重复项

如上所述，有趣的是，我们仍然看到在通知远程节点 IDONTWANT 后到达的重复项。

下图显示了 IDONTWANT 消息的通知与从同一节点收到的重复项之间的时间差。我们可以看到，在收到 IDONTWANT 后，某些实现或版本不会停止传输消息（rust-libp2p 正在进行工作以解决此问题，请参见 GH issue 和 GH PR）。

值得注意的是，正在进行一项工作以修复已发布的 RPC 排队且 IDONTWANT 消息到达的情况（issue）。我们认为这将有助于显着减少重复项的数量。

\ image592×359 65.7 KB

为了提供有关这种情况发生频率的一些数字，我们有：

• 30,607 个唯一消息 ID（区块和 blob）
• 63,735 个重复消息
• 144,524 个已发送的 IDONTWANT
• 25,201 个已发送的 IWANT
• 14,255 个消息 ID，我们同时发送了 IWANT 和 IDONTWANT

• 在 63,735 个总重复项中，44,875 个来自已通过 IDONTWANT 消息通知的节点（约占重复项的 70%）

  • 来自产生重复项的同一节点的事件序列：
    • ( 44,875): msg_arrival > sent_idontwant > recv_duplicate
  • ( 18) sent_iwant > msg_arrival > sent_idontwant > recv_duplicate
    • 相对于发送的控制消息总数来说非常少
    • 在 IDONTWANT 和 IWANT 之间的重叠中，至少 go 实现似乎没有通知远程 IWANT-notified 节点停止扩散

IWANT 的数量

在查看 hermes 实例在主题上发送的 IWANT 消息数量时，我们看到相当多的重复项是作为对我们发送的 IWANT 的回复而来的。

\ image580×358 42.9 KB

查看这些消息的发送时间，我们看到大约 60% 的 (25,201) 个已发送的 IWANT 在区块到达前 4 毫秒共享。因此，每个发送的 IWANT 产生一个重复消息。显然，这意味着我们的节点几乎完成了接收消息，然后才发送 IWANT 消息，从而导致重复。

\ image580×358 37.4 KB

下图显示，通过 IWANT 完全下载区块和 sidecar 消息需要 500 毫秒到 1.5 秒。

\ image575×351 61.9 KB

总结

我们在下图，总结了所以事件，该图显示为相对于消息到达我们收集结果的节点的时间。也就是说，0 是我们的节点收到消息的时间点。

\ image592×359 63.8 KB

为了提供有关事件及其频率的一些数字，以下是摘要：

• 30,607 个唯一消息 ID（区块和 blob）
• 63,735 个重复消息
• 144,524 个已发送的 IDONTWANT
• 25,201 个已发送的 IWANT
• 14,255 个消息 ID，我们同时发送了 IWANT 和 IDONTWANT
• 44,875 个来自通过 IDONTWANT 消息通知的节点的重复项（约占重复项的 70%）→ msg_arrival > sent_idontwant > recv_duplicate

• 18,540 个来自通过 IWANT 请求消息的节点的重复项（约占重复项的 29%）→ sent_iwant > msg_arrival > recv_duplicate（没有发送 IDONTWANT 来取消 IWANT）

  • ( 18) sent_iwant > msg_arrival > sent_idontwant
    • 当我们尝试使用 IDONTWANT 取消发送的 IWANT 时，情况很少见 → go 实现的预期结果，但由规范定义。
    • 在 18 个案例中，我们收到了一个重复项

我们的建议

• 总的来说，IDONTWANT 显着改善了这种情况，但在以下情况下变得无效：

  • msg_id 已经通过 IWANT 请求，在这种情况下，我们不发送 IDONTWANT 消息
  • 消息已在管道中，并且未被取消

• 也就是说，在处理控制消息方面仍有改进的空间：

  • 限制发送的 IWANT 消息的数量，如 此问题 和 Devcon SEA 中所讨论的那样。正如前面讨论的那样，我们已经看到该节点为单个消息 ID 发送了许多冗余 IWANT 消息

  • 延迟第一个 IWANT 消息，以避免在第一个消息到达前 10 毫秒请求的 60% 的分发，我们知道这将产生冗余副本。

    • 在收到 IDONTWANT 后取消 IWANT 的回复，即使消息已在传输/在线路上。

      • 对于所有实现来说，情况似乎并非如此（肯定不适用于 Go）。
      • 已经有一个检查我们即将发布的消息（link）。但在序列 msg_arrival -> sent_idontwant -> recv_duplicate 之后，许多重复项到达

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