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的一部分實現，並將很快作為分支釋出。
我們的模擬框架還進行了多項特殊更改以適應這些模擬，這些也將在後續中釋出。
