Les SMS d’alertes qui ont explosé mon téléphone à l’aube… ma première réaction a été que le RPC avait été floodé. Ce n’est qu’en voyant, dans iftop, qu’il n’y avait que des ports de kadcast impliqués dans les retransmissions externes que j’ai compris : ce vieux réflexe du gossip, « reçu puis redistribué à tous les voisins », devient un amplificateur d’autoréaction quand il y a du jitter entre zones. Ensuite, en plongeant dans le code de Rusk et dans le livre blanc version 2024, section 2, j’ai enfin compris que Dusk ne remplace pas le broadcast par Kadcast par un simple “petit correctif” pour économiser de la bande passante : c’est une réécriture complète de la couche P2P en adressage par distance XOR de Kademlia DHT. Chaque nœud range ses contacts par buckets ; au moment de relayer, il ne choisit que quelques peers dont la distance XOR augmente de façon progressive, pas un “arrosage” à tout le réseau.
Les études citées dans le livre blanc indiquent qu’on économise 25 % à 50 % de bande passante par rapport au gossip, et qu’on réduit les stale blocks de 10 % à 30 % en conditions de blocs rapides. Je l’ai pris pour un plafond “en laboratoire”. En environnement réel, par contre, les nœuds provisioner entrent et sortent toutes les quelques minutes, le RTT entre Tokyo et Francfort flotte autour de 40 ms, le rafraîchissement des buckets repose sur un ping périodique plutôt que sur un déclenchement par événement. Résultat : quelques secondes de vieillissement de table de routage suffisent, et le routage retombe sur un flood généralisé — on économise la bande passante, puis on la ré-engloutit presque à moitié.
Dans la phase de consensus SA en trois étapes (Generation → 1st/2nd Reduction → Agreement), les messages de vote du comité passent tous par Kadcast. Si le chemin de relai se fracture sous churn, la collecte des votes légaux en 2/3 (BLS) ne tient pas : la question n’est plus “épargne-t-on ou non de la bande passante”, c’est “ça bloque le tour”.
Là où Kadcast est plus fort que le gossip, c’est qu’il “disperse” vraiment le point d’origine d’un message. Il ne dépend plus d’une relation directe avec les voisins, et il augmente aussi d’un cran la difficulté de lier l’IP source, notamment pour masquer les transactions de Phoenix. Le revers, c’est que le raisonnement de débogage devient lourd mentalement : mempool par défaut à 10000 tx, stratégie d’expiration locale dans Rusk par défaut à 3 jours, et node-installer paramétré avec 30 minutes. Cette fragmentation de paramètres, chez les nouveaux en exploitation, se traduit par une myriade de “bugs fantômes”.
Je me demande si Kadcast en vaut la peine : je ne regarde pas les chiffres “25 %–50 %” sur papier, je juge sur trois points concrets. D’abord, le rafraîchissement des buckets converge-t-il dans la fenêtre d’1 epoch quand le nœud tombe hors ligne ? Ensuite, lors des partitions doubles, le vote SA arrive-t-il à reconstituer les 67 % requis grâce aux sous-graphes de connectivité restants ? Enfin, quand la proportion de nœuds provisioner en accès internet domestique augmente, l’augmentation de latence sur la “queue” va-t-elle s’effondrer ou non. Si ces trois portes sont franchies, alors c’est bien cette “distribution structurée” qu’un réseau financier devrait avoir ; si ça échoue, c’est juste un joli papier qui creuse des trous dans la vie de l’exploitation. #disk @Dusk $DUSK
Les études citées dans le livre blanc indiquent qu’on économise 25 % à 50 % de bande passante par rapport au gossip, et qu’on réduit les stale blocks de 10 % à 30 % en conditions de blocs rapides. Je l’ai pris pour un plafond “en laboratoire”. En environnement réel, par contre, les nœuds provisioner entrent et sortent toutes les quelques minutes, le RTT entre Tokyo et Francfort flotte autour de 40 ms, le rafraîchissement des buckets repose sur un ping périodique plutôt que sur un déclenchement par événement. Résultat : quelques secondes de vieillissement de table de routage suffisent, et le routage retombe sur un flood généralisé — on économise la bande passante, puis on la ré-engloutit presque à moitié.
Dans la phase de consensus SA en trois étapes (Generation → 1st/2nd Reduction → Agreement), les messages de vote du comité passent tous par Kadcast. Si le chemin de relai se fracture sous churn, la collecte des votes légaux en 2/3 (BLS) ne tient pas : la question n’est plus “épargne-t-on ou non de la bande passante”, c’est “ça bloque le tour”.
Là où Kadcast est plus fort que le gossip, c’est qu’il “disperse” vraiment le point d’origine d’un message. Il ne dépend plus d’une relation directe avec les voisins, et il augmente aussi d’un cran la difficulté de lier l’IP source, notamment pour masquer les transactions de Phoenix. Le revers, c’est que le raisonnement de débogage devient lourd mentalement : mempool par défaut à 10000 tx, stratégie d’expiration locale dans Rusk par défaut à 3 jours, et node-installer paramétré avec 30 minutes. Cette fragmentation de paramètres, chez les nouveaux en exploitation, se traduit par une myriade de “bugs fantômes”.
Je me demande si Kadcast en vaut la peine : je ne regarde pas les chiffres “25 %–50 %” sur papier, je juge sur trois points concrets. D’abord, le rafraîchissement des buckets converge-t-il dans la fenêtre d’1 epoch quand le nœud tombe hors ligne ? Ensuite, lors des partitions doubles, le vote SA arrive-t-il à reconstituer les 67 % requis grâce aux sous-graphes de connectivité restants ? Enfin, quand la proportion de nœuds provisioner en accès internet domestique augmente, l’augmentation de latence sur la “queue” va-t-elle s’effondrer ou non. Si ces trois portes sont franchies, alors c’est bien cette “distribution structurée” qu’un réseau financier devrait avoir ; si ça échoue, c’est juste un joli papier qui creuse des trous dans la vie de l’exploitation. #disk @Dusk $DUSK