Les chemins de moindre résistance : Présentation de WFR-Gossip Résumé : 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 en diminuant la latence au 90ᵉ percentile 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 les messages le long de chemins plus rapides. 👇

Les potins classiques considèrent la propagation comme un processus aléatoire. Le WFR-Gossip le recontextualise comme un transport de masse : un message est comme un tas de sable, et la latence est le coût pour le déplacer. Cela se connecte naturellement à la théorie du transport optimal.

Dans un réseau de rumeurs : • masse en mouvement = transférer un message • création de masse = dupliquer un message • destruction de masse = supprimer un duplicata La métrique Wasserstein-Fisher-Rao (WFR) capture cela, nous permettant 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 atteint : • ~98 % de couverture réseau • 50 % de bande passante en moins • 40 % de latence au 90ᵗʰ percentile en moins Le fallback IHAVE/IWANT gère les 2 % restants des 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 évite les goulets d'étranglement et est moins sujet à la manipulation.

C'est également peu invasif : • Pas de nouvelles topologies • Compatible avec le scoring par pairs • Fonctionne bien avec CHOKE, IDONTWANT, etc. • Utilise uniquement des règles et des données locales (RTTs)

Quelle est la suite ? • Mise en œuvre dans les simulateurs libp2p • Tests dans des conditions plus réalistes/adversariales travail précoce par @open_sourcery ici :

Lien vers le post : Lien vers le dépôt GitHub pour le code de simulation : Merci à Leo Monsaingeon, @casparschwa, @_julianma, @weboftrees, @raulvk, @yannvon, @cskiraly et @open_sourcery pour leurs retours et leurs critiques !