使用 Gossipsub v2.0 将 blob 数量翻倍 - 网络传输
- 以太坊中文
- 发布于 2025-03-08 16:22
- 阅读 28
本文介绍了 Gossipsub v2.0 协议，该协议通过引入 lazy-pull 机制，在消息传播过程中减少了重复消息的数量，从而降低了网络带宽的消耗。通过模拟实验表明，Gossipsub v2.0 可以在不牺牲延迟的情况下，将 Pectra 中的 blob 数量翻倍。同时，文章还讨论了 INEED 超时等问题，并提出了未来研究方向。
概要：使用 gossipsub v2.0，我们可以将 blob 数量从 Pectra 中指定的任何数量翻倍
Gossipsub v2.0 规范：这里
简介
Gossipsub 是一种基于 libp2p 的发布/订阅协议，它基于随机主题网格。一般的消息传播策略是将任何消息广播到其对等节点的子集。这个子集被称为“网格”。通过控制每个对等节点的出站度，你还可以控制网络中的放大因子。
通过选择足够高的度，你可以获得一个具有最小延迟的强大网络。这允许消息在短时间内弹性地分散在整个网络中。
选择的网格是随机的，并通过 gossip 控制消息不断维护，以确保对等节点的质量保持一致且不会恶化。Gossip 元数据在每次心跳期间发出，以允许可能由于下游消息丢失而错过某些消息的对等节点能够恢复并检索它们。
每个对等节点都有一个在一段时间内网络中所有已见消息的内存。这允许节点丢弃重复项并防止它们被进一步传播。此外，拥有已传播消息的内存允许对等节点对其网格对等节点做出评分决策。这允许他们从网格中修剪掉糟糕的对等节点并加入新的对等节点。
今天 Gossipsub 存在的问题
如上所示，gossipsub 作为一种发布/订阅协议具有一些非常理想的特性。但是，虽然你拥有一个具有最小延迟的弹性网络（假设足够高的度），但截至当前设计，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 是一种通用发布/订阅协议，而发布单个消息是最常见的用例。
\
cdf_sizes_0800×600 65.4 KB
\
cdf_sizes_7800×600 64.9 KB
\
cdf_sizes_8800×600 64.4 KB你可以从结果中看到，我们没有从 v2 中获得任何改进。我们的假设是，即使带宽消耗减少了，有时链接也会因为往返时间而处于空闲状态。
重复项
让我们看看多个消息情况下每个消息的平均重复项数量。
| 1 msg | 2 msgs | 4 msgs | 8 msgs | 16 msgs | 32 msgs | 64 msgs | |
|---|---|---|---|---|---|---|---|
| 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 spec: Lower or zero duplicates by lazy mesh propagation by 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 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
