Frères, demain nouveau largage de jetons. Pensez à régler l’alarme, ne le ratez pas.
La semaine dernière, sur un serveur, j’ai utilisé `tcpdump` pour capturer les paquets réseau de l’instance du nœud @Dusk et j’ai constaté qu’elle ne parvenait quasiment pas à établir un handshake TCP standard de `libp2p-gossipsub` propre à la communauté Ethereum. À la place, elle est saturée de paquets UDP à haute fréquence. En remontant dans l’arbre des dépendances Rust jusqu’à la couche réseau sous-jacente de `rusk`, la bibliothèque `dusk-kadcast`, je me suis rendu compte qu’elle réécrit directement, au niveau de la couche de transport P2P, tout un protocole de diffusion Kadcast.
Beaucoup de chaînes publiques qui font de la confidentialité ZK se heurtent à un angle mort physique, facile à ignorer : **la latence de transmission réseau**. Les paquets contenant des données avec preuve de connaissance nulle sont beaucoup plus volumineux que des transferts ordinaires. Si l’on utilise le protocole Gossip traditionnel pour “errer au hasard” et inonder en diffusion, les nœuds créent une énorme redondance de données, saturant instantanément la bande passante réseau. Et dans le système de consensus SA de Dusk (avec un bloc toutes les 2 secondes), dès que la diffusion de preuve accuse un léger retard, le délai de validation est déclenché.
La solution d’ingénierie de Kadcast, dans `kadcast/src/peer.rs`, est vraiment très “hardcore” : elle intègre en profondeur la structure de topologie Kademlia et une **correction d’erreurs avant (FEC de Reed-Solomon)**.
Lors de la diffusion de blocs, les nœuds ne transmettent pas le fichier complet ; ils découpent la preuve ZK puis l’encodent en fragments redondants, avec une livraison orientée selon la distance logique de Kademlia. Le nœud récepteur n’a qu’à recevoir un nombre déterminé de fragments pour reconstituer localement la preuve originale au niveau de la milliseconde. Cela réduit directement le facteur d’amplification des données sur le réseau P2P d’un ordre de grandeur.
La plupart des projets pensent que les performances dépendent uniquement du fait que la machine virtuelle (VM) tourne assez vite, mais ils négligent que la couche réseau P2P est le véritable goulot d’étranglement du débit ZK. En comprenant Kadcast, on voit que Dusk, pour supporter des règlements financiers à haute fréquence, a même refondu en profondeur, au niveau des infrastructures, jusqu’aux paquets UDP les plus bas.
Et dans l’ensemble du plan de routage et d’ordonnancement des nœuds Kadcast, ainsi que du réseau de relais, le socle repose entièrement sur le maintien des incitations et du règlement#dusk $DUSK
La semaine dernière, sur un serveur, j’ai utilisé `tcpdump` pour capturer les paquets réseau de l’instance du nœud @Dusk et j’ai constaté qu’elle ne parvenait quasiment pas à établir un handshake TCP standard de `libp2p-gossipsub` propre à la communauté Ethereum. À la place, elle est saturée de paquets UDP à haute fréquence. En remontant dans l’arbre des dépendances Rust jusqu’à la couche réseau sous-jacente de `rusk`, la bibliothèque `dusk-kadcast`, je me suis rendu compte qu’elle réécrit directement, au niveau de la couche de transport P2P, tout un protocole de diffusion Kadcast.
Beaucoup de chaînes publiques qui font de la confidentialité ZK se heurtent à un angle mort physique, facile à ignorer : **la latence de transmission réseau**. Les paquets contenant des données avec preuve de connaissance nulle sont beaucoup plus volumineux que des transferts ordinaires. Si l’on utilise le protocole Gossip traditionnel pour “errer au hasard” et inonder en diffusion, les nœuds créent une énorme redondance de données, saturant instantanément la bande passante réseau. Et dans le système de consensus SA de Dusk (avec un bloc toutes les 2 secondes), dès que la diffusion de preuve accuse un léger retard, le délai de validation est déclenché.
La solution d’ingénierie de Kadcast, dans `kadcast/src/peer.rs`, est vraiment très “hardcore” : elle intègre en profondeur la structure de topologie Kademlia et une **correction d’erreurs avant (FEC de Reed-Solomon)**.
Lors de la diffusion de blocs, les nœuds ne transmettent pas le fichier complet ; ils découpent la preuve ZK puis l’encodent en fragments redondants, avec une livraison orientée selon la distance logique de Kademlia. Le nœud récepteur n’a qu’à recevoir un nombre déterminé de fragments pour reconstituer localement la preuve originale au niveau de la milliseconde. Cela réduit directement le facteur d’amplification des données sur le réseau P2P d’un ordre de grandeur.
La plupart des projets pensent que les performances dépendent uniquement du fait que la machine virtuelle (VM) tourne assez vite, mais ils négligent que la couche réseau P2P est le véritable goulot d’étranglement du débit ZK. En comprenant Kadcast, on voit que Dusk, pour supporter des règlements financiers à haute fréquence, a même refondu en profondeur, au niveau des infrastructures, jusqu’aux paquets UDP les plus bas.
Et dans l’ensemble du plan de routage et d’ordonnancement des nœuds Kadcast, ainsi que du réseau de relais, le socle repose entièrement sur le maintien des incitations et du règlement#dusk $DUSK
