#dusk $DUSK @Dusk
Tout le monde parle du consensus. Presque personne ne parle de la manière dont le bloc parvient aux personnes qui votent dessus. C’est le point sur lequel je me suis bloqué.
Dusk utilise quelque chose appelé Kadcast pour propager des messages à travers le réseau : un réseau overlay structuré, et non le mode « inondation » type commérage (gossip) que la plupart des chaînes utilisent. Les protocoles de gossip poussent simplement des données vers des pairs aléatoires et espèrent que cela se propage. Kadcast, lui, achemine les messages via une structure définie, plus proche de la façon dont les systèmes pair-à-pair basés sur Kademlia organisent les nœuds par distance.
Cela m’a d’abord semblé être un choix d’infrastructure mineur, jusqu’à ce que je pense au timing. Les tours de consensus dans Dusk sont conçus pour une finalité quasi instantanée. Mais la finalité n’est aussi rapide que le nœud honnête le plus lent, celui qui a besoin des données du bloc pour voter. Si la propagation est structurée plutôt qu’aléatoire, le temps de livraison devient plus prévisible — mais cela signifie aussi que le trajet qu’emprunte un bloc dépend de la topologie du réseau, et non du hasard.
Imaginez 300 nœuds validateurs. Dans un gossip pur, un message pourrait atteindre 90 % d’entre eux via des chemins imprévisibles et qui se chevauchent en quelques sauts. Dans un système structuré comme Kadcast, ce trajet est déterminé par la position de chaque nœud dans la structure — plus efficace en moyenne, mais tout nœud mal positionné, ou lent à mettre à jour sa table de routage, pourrait prendre du retard d’une manière structurelle plutôt qu’aléatoire.
Personne ne présente la propagation comme une question de confiance, mais elle l’est discrètement. Vous faites confiance à la forme du réseau autant qu’à ceux qui le font fonctionner.
Alors que devient la « finalité quasi instantanée » au moment où la topologie et le timing du consensus cessent d’être des problèmes séparés, et deviennent le même ?

$DUSK #dusk @Dusk