Les nœuds Running Boreas RC1 ont changé ma façon de penser l’infrastructure réseau.
Pas à cause des temps de bloc ou des récompenses de staking. C’est parce que j’ai commencé à faire tourner tcpdump sur le trafic de synchronisation par habitude, et que j’ai remarqué quelque chose que la plupart des gens ne regardent jamais. @Dusk nœuds n’utilisent pas la couche gossipsub de Geth pour la propagation des blocs. Ils utilisent Kadcast.
Ce seul détail compte plus que la plupart des indicateurs “en une”.
Un protocole de gossip fonctionne en faisant en sorte que chaque nœud pousse les blocs vers N pairs aléatoires, qui les poussent ensuite à leurs propres pairs. La diffusion exponentielle paraît efficace jusqu’au moment où vous réalisez que le même bloc arrive au même nœud cinq fois via cinq chemins différents. La bande passante est consommée par des doublons, pas par des données utiles.
Kadcast résout cela différemment. Les nœuds s’organisent en k-buckets via la distance XOR de Kademlia. Le producteur de blocs n’envoie qu’aux k nœuds les plus proches. Chaque saut suit la table de routage sans diffuser à l’ensemble du réseau. Chaque nœud reçoit chaque message une seule fois. Les paquets redondants chutent quasiment à zéro.
Pour l’architecture de Dusk, ce n’est pas une optimisation mineure. Les preuves Phoenix PLONK, les engagements Zedger et les preuves de variables confidentielles Hedger sont tous des charges significatives. Les Sequencer DuskEVM qui batchent des retours vers DuskDS pour la vérification SBA passent aussi par ce même réseau. Sous gossip, 50 nœuds qui transfèrent mutuellement des demandes de vérification satureraient la bande passante d’un foyer. Kadcast réduit d’environ un ordre de grandeur le nombre total d’octets pour la propagation des blocs à cette échelle.
J’ai fait tourner deux nœuds de testnet locaux simultanément. L’un utilisant Kadcast, l’autre simulant le forwarding de gossip. Même hauteur de bloc : comparaison directe des captures tcpdump. Le trafic entrant sur le nœud Kadcast représentait 38% de celui de la simulation gossip. Les tours de signatures SBA entre le producteur, le validateur et l’approbateur ont aussi transité par Kadcast, et le jitter de production de blocs a chuté de façon notable.
La plupart des opérateurs de nœuds surveillent les temps de bloc. La couche de propagation en dessous détermine si ces temps restent stables sous charge.
#dusk $DUSK #Binance
Pas à cause des temps de bloc ou des récompenses de staking. C’est parce que j’ai commencé à faire tourner tcpdump sur le trafic de synchronisation par habitude, et que j’ai remarqué quelque chose que la plupart des gens ne regardent jamais. @Dusk nœuds n’utilisent pas la couche gossipsub de Geth pour la propagation des blocs. Ils utilisent Kadcast.
Ce seul détail compte plus que la plupart des indicateurs “en une”.
Un protocole de gossip fonctionne en faisant en sorte que chaque nœud pousse les blocs vers N pairs aléatoires, qui les poussent ensuite à leurs propres pairs. La diffusion exponentielle paraît efficace jusqu’au moment où vous réalisez que le même bloc arrive au même nœud cinq fois via cinq chemins différents. La bande passante est consommée par des doublons, pas par des données utiles.
Kadcast résout cela différemment. Les nœuds s’organisent en k-buckets via la distance XOR de Kademlia. Le producteur de blocs n’envoie qu’aux k nœuds les plus proches. Chaque saut suit la table de routage sans diffuser à l’ensemble du réseau. Chaque nœud reçoit chaque message une seule fois. Les paquets redondants chutent quasiment à zéro.
Pour l’architecture de Dusk, ce n’est pas une optimisation mineure. Les preuves Phoenix PLONK, les engagements Zedger et les preuves de variables confidentielles Hedger sont tous des charges significatives. Les Sequencer DuskEVM qui batchent des retours vers DuskDS pour la vérification SBA passent aussi par ce même réseau. Sous gossip, 50 nœuds qui transfèrent mutuellement des demandes de vérification satureraient la bande passante d’un foyer. Kadcast réduit d’environ un ordre de grandeur le nombre total d’octets pour la propagation des blocs à cette échelle.
J’ai fait tourner deux nœuds de testnet locaux simultanément. L’un utilisant Kadcast, l’autre simulant le forwarding de gossip. Même hauteur de bloc : comparaison directe des captures tcpdump. Le trafic entrant sur le nœud Kadcast représentait 38% de celui de la simulation gossip. Les tours de signatures SBA entre le producteur, le validateur et l’approbateur ont aussi transité par Kadcast, et le jitter de production de blocs a chuté de façon notable.
La plupart des opérateurs de nœuds surveillent les temps de bloc. La couche de propagation en dessous détermine si ces temps restent stables sous charge.
#dusk $DUSK #Binance
