I percorsi di minor resistenza: Presentazione di WFR-Gossip tldr: WFR-Gossip applica i principi del trasporto ottimale al livello di gossip di Ethereum. Preserva la resilienza di Gossipsub, riducendo al contempo la larghezza di banda del 50% e la latenza del 90° percentile del 40% nelle simulazioni.

Gossipsub di Ethereum è robusto ma inefficiente. I nodi spesso ricevono lo stesso messaggio molte volte. Buono per la resilienza, costoso in termini di larghezza di banda/latenza. WFR-Gossip adotta un approccio diverso: ispirato dalla teoria del trasporto ottimale, inoltra i messaggi lungo percorsi più veloci. 👇

Il pettegolezzo classico tratta la propagazione come un processo casuale. WFR-Gossip lo riformula come trasporto di massa: un messaggio è come un mucchio di sabbia e la latenza è il costo per spostarlo. Questo si collega naturalmente alla teoria del trasporto ottimale.

In una rete di gossip: • massa in movimento = inoltro di un messaggio • creazione di massa = duplicazione di un messaggio • distruggere la massa = sganciare un duplicato La metrica Wasserstein-Fisher-Rao (WFR) cattura questo aspetto, consentendoci di modellare il flusso di messaggi con l'intuizione fisica.

Ogni nodo utilizza una semplice regola: • Inoltro ad alcuni peer a bassa latenza (D₍robusto₎ ≈ 3) • Per gli altri, inoltrare solo se RTT_out < RTT_in Questa euristica "in discesa" non richiede un coordinamento globale. Solo i Round-Trip Times (RTT) locali, già in libp2p.

A D_robust = 3, WFR-Gossip ottiene: • ~98% di copertura di rete • 50% in meno di larghezza di banda • Latenza del 90° percentile inferiore del 40% Il fallback IHAVE/IWANT gestisce il restante 2% dei nodi mancanti.

WFR-Gossip non è solo l'inoltro al peer più veloce. Combina la ridondanza con il filtraggio: robusta propagazione casuale + potatura selettiva dei percorsi lenti. In questo modo si evitano colli di bottiglia ed è meno soggetto a manipolazioni.

È anche minimamente invasivo: • Nessuna nuova topologia • Compatibile con il punteggio tra pari • Funziona bene con CHOKE, IDONTWANT, ecc. • Utilizza solo regole e dati locali (RTT)

Qual è il prossimo passo? • Implementazione in simulatori libp2p • Test in condizioni più realistiche/contraddittorie I primi lavori di @open_sourcery qui:

Link al post: Link al repository githup per il codice di simulazione: Grazie a Leo Monsaingeon, @casparschwa, @_julianma, @weboftrees, @raulvk, @yannvon, @cskiraly e @open_sourcery per feedback e recensioni!