#dusk $DUSK Aujourd’hui, je lis la documentation de la couche réseau de @Dusk . Je pensais que les réseaux P2P de la blockchain se ressemblaient tous : diffusion des transactions, synchronisation des blocs, sans grand intérêt à approfondir. Jusqu’à ce que je tombe sur le terme « Kadcast » : je me suis rendu compte que Dusk n’a pas suivi cette vieille voie du protocole Gossip.
Le protocole Gossip fonctionne comme un jeu de téléphone : chaque nœud choisit aléatoirement quelques voisins pour transmettre un message, les voisins le transmettent à leurs propres voisins, et au final tout le réseau le sait. L’avantage, c’est une bonne tolérance aux pannes, mais le coût est énorme en gaspillage de bande passante : un même message peut être reçu plusieurs fois par un même nœud.
Kadcast remplace la diffusion aléatoire par un réseau de couverture structuré. Au lieu de choisir des voisins au hasard, les nœuds transmettent les messages de manière directionnelle selon une topologie organisée. La documentation officielle indique que cela permet d’économiser 25 % à 50 % de bande passante par rapport au protocole Gossip traditionnel.
Je comprends que cette conception s’accompagne d’une contrainte : dans les contextes financiers, la confirmation des transactions ne peut pas reposer sur la simple hypothèse « en l’envoyant plusieurs fois, ça finira forcément par arriver » comme garantie de transmission. Avec un routage structuré, les chemins de propagation sont plus prévisibles, et la latence est aussi plus maîtrisable. Pour les marchés financiers qui nécessitent un règlement déterministe, savoir « à peu près combien de temps pour que le message arrive » est aussi important que « que le message arrive ».
Mais l’autre face de cette optimisation, c’est que le réseau structuré est plus sensible à l’entrée et à la sortie des nœuds. Si un grand nombre de nœuds sont simultanément hors ligne, l’efficacité de la reconstruction des tables de routage pourrait-elle ralentir l’ensemble du réseau ? Dans la documentation publique actuelle, je n’ai pas trouvé de données de latence en cas de fluctuations importantes du nombre de nœuds.
En lisant la couche réseau de #dusk , je ne regarde pas seulement le TPS et le temps de production de blocs : je veux voir, après le déploiement sur le mainnet, l’économie de bande passante et la distribution de la latence observées en conditions réelles, avec la répartition des nœuds. Si la couche sous-jacente de DUSK tient ses performances de façon stable, les applications financières au-dessus auront une base solide. #dusk @Dusk