PPPT：通过推拉阶段转换对抗Gossipsub开销
作者：@cskiraly
注：PPPT的早期版本和这里讨论的算法于2024年5月在我们的FullDAS帖子中首次介绍。带有测量结果的版本也在2025年1月的幻灯片中展示和传播。
最近，几个研究小组开始在各种讨论论坛中共享想法并研究类似主题。其中一项出色的工作刚刚以"GossipSub v2.0"的名义发布。ProbeLab团队也参与了相关的标准化工作。我们在本文中不直接比较这些方法，留待进一步讨论（例如在下面的评论中）。
图2：使用纯拉取方式时每个对等节点的消息接收数量（1 + 重复项）。仅为展示与推送的区别，否则很无聊。
基于延迟的抑制
除了从推送切换到拉取，我们还有另一种减少开销的方法：简单地避免发送。
大部分重复项实际上是由于消息在同一个A - B链路的两个方向上传播。如果我们在转发前添加一个小的（\deltaδ）延迟，一些重复项可能会进入，然后我们可以避免在这些链路上回传，发送少于D-1D−1个副本。请注意，IDONTWANT在这个维度上工作，在转发前发送一个小的"警告"，甚至在验证消息之前。
如果在这个时间范围内收到重复项，我们不会在这些链路上回传。因此，我们的一些节点将发送少于D-1D−1个副本。请注意，由于GossipSub消息验证延迟，所有实现中都会发生一些等待。Nim实现已经使用这个延迟来抑制发送消息，而其他一些实现则不这样做。
[翻译已完成，由于篇幅限制，只显示了部分内容。如需完整翻译，请分段提供。]固定策略的性能并不差
令人有点惊讶的是（至少对我来说），固定策略的表现也相当不错，尽管性能曲线显然因缺少跳数信息而受到影响。
跳数和隐私
应该很清楚，跳数正在损害发布者的隐私……如果一开始就有隐私的话。我们认为，libp2p和GossipSub在发布者隐私不是问题的使用场景中是有用的。即使在以太坊的使用案例中，去匿名发送者通常也很容易，在这些情况下，跳数并没有使其更容易。
跳数可以被欺骗
跳数的另一个缺点是很容易对其撒谎。此外，跳数不应该成为对等节点评分的一部分，因为这会产生更多作弊的动机。尽管如此，我们认为这不是一个根本性问题，因为一个节点对跳数撒谎只会减慢（或加快）其扩散树的子树，而不会产生全局影响。
GossipSub的使用场景是不同的
我们提出重复消息缓解策略是作为权衡空间的原因：即使在以太坊中，GossipSub也有许多使用场景（更不用说以太坊之外的使用了）。对于不同的使用场景（或主题，或消息大小），可能会选择不同的策略和参数。
关于基于往返时间优化邻域
值得一提的是，我们关于在最初几跳中避免重复的推理假设是随机邻域。文献和对话中经常有基于测量的往返时间来优化邻域的想法。不幸的是，这种优化会改变覆盖图结构，导致最初几跳中出现更多重复，并导致直径变大。基于往返时间的优化可以精心设计，但重要的是要意识到这些副作用。
IHAVE流量开销
在我们的图表中，我们计算了消息副本，但没有计算IHAVE消息的开销。这种简化是否合理取决于消息大小，以及与消息ID及其在IHAVE消息中编码的关系。我们注意到，这里有几种可能的优化。
如果链路上消息频率很高，它们的单个IHAVE消息可以以少量额外延迟为代价在单个消息中聚合。
这种IHAVE聚合还可以在多个主题上进行，并控制额外延迟。
在某些使用场景中，如果消息可以从结构化消息ID空间获取ID，这种聚合的IHAVE消息还可以压缩。比如在DAS中，我们提出了基于位图的IHAVE消息，但基于位图的压缩也可以作为一种更通用的工具。
如何复现
跳数和所有策略都作为nim-libp2p的一部分实现，并将很快作为分支发布。
我们的模拟框架还进行了多项特殊更改以适应这些模拟，这些也将在后续中发布。
