使用 Gossipsub v2.0 将 Blob 数量翻倍 - 网络
- 以太坊中文
- 发布于 2025-03-08 14:49
- 阅读 26
本文介绍了 Gossipsub v2.0 的设计，它通过引入 IANNOUNCE 和 INEED 消息，实现了一种 lazy-pull 机制，在降低网络放大的同时，也能保证消息的可靠传播。模拟结果表明，Gossipsub v2.0 可以将 Pectra 中的 blob 数量翻倍。同时，文章也讨论了 INEED 超时设置和恶意节点可能带来的问题，并提出了未来研究方向。
简而言之；通过 gossipsub v2.0，我们可以将 blob 数量增加到 Pectra 中指定的任何值的一倍
Gossipsub v2.0 规范：这里
介绍
Gossipsub 是一个基于 libp2p 的 pubsub 协议，它基于随机主题网格。一般的消息传播策略是将任何消息广播到其对等节点的子集。此子集称为“网格”。通过控制每个对等节点的出站度，你还可以控制网络中的放大因子。
通过选择足够高的度数，你可以实现具有最小延迟的健壮网络。这允许消息在短时间内弹性地分散在整个网络中。
选择的网格是随机的，并且通过 gossip 控制消息不断维护，以确保对等节点的质量保持一致并且不会下降。Gossip 元数据在每次心跳期间发出，以便可能由于下游消息丢失而错过某些消息的对等节点能够恢复并检索它们。
每个对等节点都会在一段时间内记住网络中所有已看到的消息。这允许节点删除重复项并防止它们被进一步传播。此外，记住已传播的消息允许对等节点对其网格对等节点做出评分决策。这允许他们从网格中修剪掉糟糕的对等节点并移植新的对等节点。
今天 Gossipsub 存在的问题
如上所示，gossipsub 作为一种 pubsub 协议具有一些非常理想的特性。但是，虽然你拥有一个具有最小延迟的弹性网络（假设有足够高的度数），但根据其当前设计，Gossipsub 会带来很高程度的放大。
当前设计的权衡是，如果网络需要以最小的延迟传播消息，则需要大量的放大。这在需要传播大型消息的网络中是有问题的，因为完成的放大是显着的。如果这些大型消息中的许多消息开始在网络中传播，它将影响网络的一般去中心化和可扩展性。
对于这些网络，Gossipsub v1.2 引入了一种名为 IDONTWANT 的新控制消息。此控制消息允许对等节点告诉其网格对等节点不要传播与特定消息 ID 匹配的消息。这样做的主要目标是防止发送重复项并减少整个网络中的放大。
虽然这确实有助于减少重复项，但它最终依赖于远程对等节点能够及时对控制消息采取行动。如果他们不这样做，消息最终仍然会被转发，从而浪费发送者和接收者的带宽。那么我们如何改进这一点呢？
我们的解决方案
我们在 GossipSub v2 中将延迟拉取机制置于原始的积极推送机制的旁边。通过延迟拉取，我们只广播消息 ID 而不是整个消息。我们通过引入两个新的控制消息 IANNOUNCE 和 INEED 来实现这一点，它们包含单个消息 ID。
本质上，使用 IANNOUNCE 宣布消息，并使用 INEED 请求已宣布的消息。节点等待实际消息作为 INEED 的响应，等待配置的超时。
如果超时过期，它会尝试从另一个对等节点获取消息（单个节点仅按顺序发送 INEED）。当超时发生时，节点也会降低对等节点的分数，以防止恶意对等节点忽略 INEED 并且永不发回消息。
通过这种延迟拉取机制，我们将重复项的数量减少到几乎为零，但是，通过权衡延迟。为了最大限度地减少延迟增加的影响，我们引入了宣布度的概念。宣布度表示节点从其网格中随机选择用于延迟拉取的网格对等节点的数量。因为这会将网格分成两部分，所以始终 D_announce <= D。
在将消息转发到每个网格对等节点之前，节点将抛Coin来决定是以 D_announce/D 的概率延迟发送消息，还是以其他方式积极发送消息，因此预期节点将消息延迟发送到其 D_announce 个网格对等节点，并积极发送到其 D-D_announce 个网格对等节点。
正式的规范及其简单性适应了未来的策略，最大限度地减少了延迟拉取机制的延迟影响。但是，在这篇文章中，我们通过模拟探索了 D_announce 的概念和一些其他策略。
模拟设置
我们使用了 go-libp2p 的 Gossipsub v2.0 实现，如 PR 所示，并使用 Shadow 作为模拟器。
我们运行了 1,000 个节点的模拟，其中 20% 的节点具有 1Gbps/1Gpbs 的带宽，80% 的节点具有 50Mbps/50Mbps 的带宽。发布者始终具有 1Gbps/1Gbps，以便获得一致的模拟结果。
每对节点之间的延迟与我们从模拟工具 Ethshadow 采用的真实世界地理位置一致。我们决定花费精力使它们尽可能接近真实世界，因为我们知道 IANNOUNCE/INEED 引起的往返时间对结果有重大影响，并且它在很大程度上取决于地理位置。
首先，我们模拟单个发布者发布具有不同消息大小的单个消息的网络。其次，我们模拟单个发布者发布具有不同消息数量的多个消息的网络，其中每个消息的大小为 128KB。
然后，我们重复提到 D_announce=0,7,8 和 D=8 以及 1 秒超时的情况。我们运行 D_announce=7 是为了看看当我们添加一些随机性时它是否会有所帮助。在 D_announce=7,8 的情况下，我们还将心跳间隔从默认的 CL 值 0.7 秒更改为 1.5 秒，以减少 IHAVE/IWANT 中的重复项数量。
结果
多个消息
首先，我们来看看当单个发布者同时发布多个消息时的模拟。
\
cdf_num_0800×600 57.4 KB
\
cdf_num_7800×600 50 KB
\
cdf_num_8800×600 51.5 KB你可以从结果中看到，对于 D_announce=0，你可以在 4 秒的截止时间内发布 16 条消息，而对于 D_announce=7,8，你可以发布 32 条消息。因此，我们得出结论，我们可以将 Pectra 中的 blob 计数加倍。
另请注意，D_announce=7 也比 D_announce=8 好得多，因为对于后者，传播可能会因每次跃点的往返时间而延迟。对于前者，每个节点预计会积极地将消息发送给一个随机对等节点，以允许消息更快地传播。
单个消息
即使发布单个消息对于以太坊来说并不重要，我们仍然应该考虑它，因为 Gossipsub 是一种通用的 pubsub 协议，而发布单个消息是最常见的用例。
\
cdf_sizes_0800×600 65.4 KB
\
cdf_sizes_7800×600 64.9 KB
\
cdf_sizes_8800×600 64.4 KB你可以从结果中看到，我们从 v2.0 中没有获得任何改进。我们的假设是，即使带宽消耗减少了，有时链路也会因往返时间而空闲。
重复项
让我们看看多个消息的情况下，每条消息的平均重复项数量。
| 1 条消息 | 2 条消息 | 4 条消息 | 8 条消息 | 16 条消息 | 32 条消息 | 64 条消息 | |
|---|---|---|---|---|---|---|---|
| D_announce=0 | 4.515 | 5.492 | 5.658 | 5.686 | 6.161 | 7.394 | 9.232 |
| D_announce=7 | 0.598 | 0.565 | 0.586 | 1.259 | 0.767 | 1.482 | 2.244 |
| D_announce=8 | 0.192 | 0.804 | 0.179 | 0.395 | 0.769 | 0.673 | 1.236 |
你可以看到数量的改进非常大，以至于进一步的带宽优化可能不会带来太大的好处。
我们还注意到，几乎所有剩余的重复项都是由于 IHAVE/IWANT 造成的，我们认为我们应该重新考虑它到底有多重要。
现在看看单个消息的平均重复项数量。
| 128KB | 256KB | 512KB | 1024KB | 2048KB | 4096KB | 8192KB | |
|---|---|---|---|---|---|---|---|
| D_announce=0 | 4.515 | 4.749 | 5.122 | 5.832 | 8.909 | 11.022 | 12.990 |
| D_announce=7 | 0.598 | 2.284 | 1.163 | 2.506 | 4.078 | 6.971 | 9.275 |
| D_announce=8 | 0.192 | 1.777 | 1.087 | 1.950 | 3.762 | 5.927 | 8.692 |
对于 128KB 到 1024KB，这些数字看起来不错，但对于更大的消息，它们并没有太大改进。这是因为更大的消息需要更多时间在对等节点之间发送，然后更有可能发生 INEED 超时。这导致发送许多 INEED，然后导致接收到更多的重复项。
担忧
Gossipsub v2 的主要担忧是我们引入了一个名为 INEED 超时的新参数，它是节点在发送 INEED 后等待消息的时间。
设置超时很棘手。我们不希望恶意行为者忽略 INEED 或延迟发送消息。我们应该以一种所有诚实节点都能够在大多数情况下遵循的方式设置超时。
在超时发生后降低对等节点的分数时，你还必须确保不要过度降低分数。否则，当他们偶尔触发超时时，你会过快地踢出诚实的对等节点。一种可能的替代方法是忽略以前反复忽略或过晚响应 INEED 消息的对等节点的 IANNOUNCE 消息，而不是降低它们的分数。
目前我们将超时设置为 1 秒，因为即使你有三个连续的对等节点触发超时，你仍然能够在 4 秒的截止时间内收到消息，甚至更好的是，IHAVE/IWANT 有时会帮助你在截止时间之前收到消息。模拟结果还表明，诚实节点的超时不会让你错过截止时间。
致谢
感谢 Vyzo 对 AnnounceSub 的宝贵意见，它是 GossipSub v2.0 的前身。
进一步研究
- 重新考虑 IHAVE/IWANT 有多重要。我们可以完全删除它，还是我们可以减少它的影响，例如通过增加心跳间隔等？
- 模拟网络中 5%、10%、20% 的恶意节点的网络，其中恶意节点是指忽略 INEED 的节点。
- 准确定义在超时发生后节点应该降低对等节点多少分数。
- 也许我们不需要 INEED 的超时，但最好根据对等节点回复消息的延迟程度来降低它们的分数。
- 与 Codex 的批量发布集成并查看结果。
资源
-
Gossipsub v2.0 规范：Gossipsub v2.0 规范：通过 ppopth 的延迟网格传播降低或零重复项 · Pull Request #653 · libp2p/specs · GitHub
-
go-libp2p-pubsub 中的 Gossipsub v2.0 实现：Gossipsub v2.0 by ppopth · Pull Request #587 · libp2p/go-libp2p-pubsub · GitHub
-
如果你想重新运行模拟，可以使用以下存储库：GitHub - ppopth/pubsub-shadow
- 原文链接： ethresear.ch/t/doubling-...
- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
