Les voies de la moindre résistance : Présentation de WFR-Gossip tldr : WFR-Gossip applique des principes de transport optimal à la couche de gossip d’Ethereum. Il préserve la résilience de Gossipsub, tout en réduisant la bande passante de 50 % et la latence du 90e centile de 40 % dans les simulations.

Le Gossipsub d’Ethereum est robuste mais inefficace. Les nœuds reçoivent souvent le même message plusieurs fois. Bon pour la résilience, coûteux en bande passante/latence. WFR-Gossip adopte une approche différente : inspiré par la théorie du transport optimal, il transmet des messages le long de chemins plus rapides. 👇

Les commérages classiques traitent la propagation comme un processus aléatoire. WFR-Gossip le recadre comme un transport de masse : un message est comme un tas de sable, et la latence est le coût à payer pour le déplacer. Cela se rattache naturellement à la théorie du transport optimal.

Dans un réseau de potins : • Moving Mass = Transfert d’un message • création de masse = duplication d’un message • destruction de masse = suppression d’un doublon La métrique Wasserstein-Fisher-Rao (WFR) capture cela, ce qui nous permet de modéliser le flux de messages avec une intuition physique.

Chaque nœud utilise une règle simple : • Rediriger vers quelques homologues à faible latence (D₍robust₎ ≈ 3) • Pour les autres, ne transmettez que si RTT_out < RTT_in Cette heuristique « descendante » ne nécessite pas de coordination mondiale. Juste des temps d’aller-retour (RTT) locaux, déjà en libp2p.

À D_robust = 3, WFR-Gossip réalise : • ~98 % de couverture réseau • 50 % de bande passante en moins • Latence du 90e centile réduite de 40 % Le repli IHAVE/IWANT gère les 2 % restants de nœuds manqués.

WFR-Gossip ne se contente pas de transmettre au pair le plus rapide. Il combine redondance et filtrage : propagation aléatoire robuste + élagage sélectif des chemins lents. Cela permet d’éviter les goulets d’étranglement et d’être moins sujet à la manipulation.

Il est également peu invasif : • Pas de nouvelles topologies • Compatible avec le scoring par les pairs • Joue bien avec CHOKE, IDONTWANT, etc. • N’utilise que des règles et des données locales (RTT)

Quelle est la prochaine étape ? • Implémentation dans les simulateurs libp2p • Essais dans des conditions plus réalistes/contradictoires Les premiers travaux de @open_sourcery ici :

Lien vers l’article : Lien vers le dépôt githup pour le code de simulation : Merci à Leo Monsaingeon, @casparschwa, @_julianma, @weboftrees, @raulvk, @yannvon, @cskiraly et @open_sourcery pour leurs commentaires et avis !