Die Wege des geringsten Widerstands: Wir stellen vor: WFR-Gossip tldr: WFR-Gossip wendet optimale Transportprinzipien auf die Gossip-Schicht von Ethereum an. Es bewahrt die Ausfallsicherheit von Gossipsub, reduziert die Bandbreite um 50 % und reduziert die Latenz im 90. Perzentil um 40 % in Simulationen.

Gossipsub von Ethereum ist robust, aber ineffizient. Knoten erhalten oft mehrmals dieselbe Nachricht. Gut für die Ausfallsicherheit, kostspielig in Bezug auf Bandbreite/Latenz. WFR-Gossip verfolgt einen anderen Ansatz: Inspiriert von der Theorie des optimalen Transports leitet es Nachrichten auf schnelleren Wegen weiter. 👇

Klassischer Klatsch behandelt die Vermehrung als einen zufälligen Prozess. WFR-Gossip deutet es als Massentransport um: Eine Nachricht ist wie ein Haufen Sand, und Latenz ist der Preis, um sie zu bewegen. Dies knüpft natürlich an die Theorie des optimalen Transports an.

In einem Klatschnetzwerk: • bewegte Masse = Weiterleiten einer Nachricht • Erstellen von Massen = Duplizieren einer Nachricht • Masse zerstören = ein Duplikat fallen lassen Die Wasserstein-Fisher-Rao-Metrik (WFR) erfasst dies und ermöglicht es uns, den Nachrichtenfluss mit physischer Intuition zu modellieren.

Jeder Knoten verwendet eine einfache Regel: • Weiterleiten an einige Peers mit geringer Latenz (D₍robust₎ ≈ 3) • Für andere nur dann vorspulen, wenn RTT_out < RTT_in Diese Heuristik "bergab" erfordert keine globale Koordination. Nur lokale Round-Trip Times (RTTs), bereits in libp2p.

Bei D_robust = 3 erreicht WFR-Gossip: • ~98 % Netzabdeckung • 50 % weniger Bandbreite • 40 % niedrigere Latenz im 90. Perzentil IHAVE/IWANT-Fallback behandelt die restlichen 2 % der fehlenden Knoten.

WFR-Gossip leitet nicht nur an den schnellsten Peer weiter. Es kombiniert Redundanz mit Filterung: robuste zufällige Ausbreitung + selektives Beschneiden langsamer Pfade. Dadurch werden Engpässe vermieden und es ist weniger anfällig für Manipulationen.

Es ist auch minimalinvasiv: • Keine neuen Topologien • Kompatibel mit Peer-Scoring • Spielt gut mit CHOKE, IDONTWANT usw. • Verwendet nur lokale Regeln und Daten (RTTs)

Was kommt als nächstes? • Implementierung in libp2p-Simulatoren • Testen unter realistischeren/kontradiktorischeren Bedingungen Frühe Arbeiten von @open_sourcery hier:

Link zum Beitrag: Link zum githup-Repo für Simulationscode: Vielen Dank an Leo Monsaingeon, @casparschwa, @_julianma, @weboftrees, @raulvk, @yannvon, @cskiraly und @open_sourcery für Feedback und Bewertungen!