Parlons des performances de la blockchain : sur dix personnes, neuf pensent d’abord au TPS. La dernière, c’est peut-être la latence. Mais pour le projet Dusk, si tu prends son livre blanc et que tu le relis attentivement, tu verras qu’il y a quelque chose qui mérite plus d’attention que la vitesse des transactions : la façon dont les nœuds « se parlent » entre eux.
La grosse affaire, c’est que ça va pour le reste — BTC a chuté, mais pas de beaucoup !
Je ne dis pas ça parce que le TPS n’est pas important. Simplement, « calculer vite » et « transmettre vite », ce sont deux choses différentes. Même si ta couche d’exécution est très performante et que la conception du consensus est ingénieuse, si les messages restent bloqués dans le réseau de nœuds — par exemple, si la proposition n’arrive pas aux validateurs, ou si les résultats de validation ne reviennent pas au comité de ratification — alors tout le processus en trois étapes doit attendre. Un bloc qui arrive avec quelques secondes de retard : dans le meilleur des cas, l’expérience utilisateur en pâtit ; dans le pire, différents nœuds voient des blocs candidats différents, et le taux de stale blocks grimpe en flèche.
Dusk a choisi la voie de Kadcast. Ce n’est pas un mode de diffusion façon Gossip du type « je transfère à tout le monde ». C’est un réseau de couverture structuré construit à partir de Kademlia DHT : la distance XOR entre les identifiants de nœuds détermine le routage, et les messages se déploient couche par couche, comme un arbre. Ça sonne académique, non ? Mais la logique centrale tient en une seule phrase : chaque message ne prend que le chemin qui lui convient, sans détour inutile.
Le livre blanc cite des recherches : par rapport à Gossip, Kadcast permet d’économiser de 25 % à 50 % de bande passante. Par exemple, si on consommait 100 unités de bande passante auparavant, on en utilise désormais environ 50 à 75. Mais ces chiffres ne se traduisent pas directement par « les coûts des nœuds sont divisés par deux ». Les configurations des machines ne changent pas, le calcul des preuves ne change pas, les coûts de stockage ne changent pas : ce qui change, c’est seulement le coût de transmission dans la couche réseau. Cela dit, pour ceux qui exécutent des nœuds, qu’est-ce que ça veut dire de n’utiliser qu’une moitié de bande passante ? Ça signifie qu’avec les mêmes contraintes de bande passante, on peut connecter plus de nœuds ; ou, pour une taille de réseau identique, qu’on évite plus facilement d’être étranglé par les frais de bande passante.
Il y a un détail qui illustre bien le problème. Dans la documentation des nœuds, le couple 9000/udp est marqué comme port obligatoire pour Kadcast. Pour que le Provisioner participe au consensus, il faut que ce canal soit joignable ; en revanche, 8080/tcp est optionnel : il n’est nécessaire que si on a besoin de l’interface de requête. Autrement dit, Kadcast n’est pas un simple ornement sur le schéma d’architecture — il fixe directement le seuil d’accès à la possibilité pour un nœud de participer au consensus.
Si tu connais la diffusion pair-à-pair de BTC, tu sais que la façon dont les messages traversent le réseau de nœuds n’a jamais été anecdotique. @Dusk $DUSK #dusk
La grosse affaire, c’est que ça va pour le reste — BTC a chuté, mais pas de beaucoup !
Je ne dis pas ça parce que le TPS n’est pas important. Simplement, « calculer vite » et « transmettre vite », ce sont deux choses différentes. Même si ta couche d’exécution est très performante et que la conception du consensus est ingénieuse, si les messages restent bloqués dans le réseau de nœuds — par exemple, si la proposition n’arrive pas aux validateurs, ou si les résultats de validation ne reviennent pas au comité de ratification — alors tout le processus en trois étapes doit attendre. Un bloc qui arrive avec quelques secondes de retard : dans le meilleur des cas, l’expérience utilisateur en pâtit ; dans le pire, différents nœuds voient des blocs candidats différents, et le taux de stale blocks grimpe en flèche.
Dusk a choisi la voie de Kadcast. Ce n’est pas un mode de diffusion façon Gossip du type « je transfère à tout le monde ». C’est un réseau de couverture structuré construit à partir de Kademlia DHT : la distance XOR entre les identifiants de nœuds détermine le routage, et les messages se déploient couche par couche, comme un arbre. Ça sonne académique, non ? Mais la logique centrale tient en une seule phrase : chaque message ne prend que le chemin qui lui convient, sans détour inutile.
Le livre blanc cite des recherches : par rapport à Gossip, Kadcast permet d’économiser de 25 % à 50 % de bande passante. Par exemple, si on consommait 100 unités de bande passante auparavant, on en utilise désormais environ 50 à 75. Mais ces chiffres ne se traduisent pas directement par « les coûts des nœuds sont divisés par deux ». Les configurations des machines ne changent pas, le calcul des preuves ne change pas, les coûts de stockage ne changent pas : ce qui change, c’est seulement le coût de transmission dans la couche réseau. Cela dit, pour ceux qui exécutent des nœuds, qu’est-ce que ça veut dire de n’utiliser qu’une moitié de bande passante ? Ça signifie qu’avec les mêmes contraintes de bande passante, on peut connecter plus de nœuds ; ou, pour une taille de réseau identique, qu’on évite plus facilement d’être étranglé par les frais de bande passante.
Il y a un détail qui illustre bien le problème. Dans la documentation des nœuds, le couple 9000/udp est marqué comme port obligatoire pour Kadcast. Pour que le Provisioner participe au consensus, il faut que ce canal soit joignable ; en revanche, 8080/tcp est optionnel : il n’est nécessaire que si on a besoin de l’interface de requête. Autrement dit, Kadcast n’est pas un simple ornement sur le schéma d’architecture — il fixe directement le seuil d’accès à la possibilité pour un nœud de participer au consensus.
Si tu connais la diffusion pair-à-pair de BTC, tu sais que la façon dont les messages traversent le réseau de nœuds n’a jamais été anecdotique. @Dusk $DUSK #dusk