La semaine dernière, mon nœud sur une configuration de relais en testnet à Karachi a continué à prendre du retard chaque fois que j’essayais de simuler un trafic de messages lourd. Je pensais que le problème venait simplement de ma bande passante, faible comme c’est typiquement le cas avec mon FAI local, un souci que j’ai déjà rencontré.
Puis j’ai réellement lu comment Dusk gère la communication pair à pair, et j’ai compris que mon hypothèse était à l’envers. Le décalage n’était pas dû à la bande passante brute : il venait de l’inefficacité du style de diffusion par inondation, où chaque nœud répète les messages à tous ses voisins, indépendamment de la distance.
Dusk utilise Kadcast, basé sur la structure de distance XOR de Kademlia. Les nœuds transmettent les messages uniquement à des pairs sélectionnés, à des distances croissantes, créant un effet en cascade plutôt qu’une répétition aveugle. Cela réduit considérablement les transmissions redondantes par rapport aux protocoles de type gossip, comme ceux sur lesquels Ethereum s’appuie. Cela dissimule aussi naturellement l’origine d’un message, puisqu’il passe par plusieurs sauts avant d’atteindre le réseau plus large, ce qui correspond à l’orientation confidentialité de Dusk pour les transactions financières.
Ce que le livre blanc n’explique pas clairement, ce sont des chiffres précis de latence dans le monde réel, dans des conditions réseau défavorables, comme ce qui se passe précisément lors d’une congestion régionale dans des lieux où l’infrastructure est instable. C’est un manque que je ne peux pas combler avec confiance.
Le vrai test pour DUSK est de savoir si Kadcast conserve son avantage d’efficacité lorsque le nombre de nœuds augmente jusqu’à atteindre des milliers, sous une pression réelle du réseau—pas seulement dans des conditions de testnet contrôlées.
Quelqu’un ici a-t-il réellement fait tourner un nœud Dusk assez longtemps pour remarquer par lui-même des différences de vitesse de propagation ?
#dusk $DUSK @Dusk
Puis j’ai réellement lu comment Dusk gère la communication pair à pair, et j’ai compris que mon hypothèse était à l’envers. Le décalage n’était pas dû à la bande passante brute : il venait de l’inefficacité du style de diffusion par inondation, où chaque nœud répète les messages à tous ses voisins, indépendamment de la distance.
Dusk utilise Kadcast, basé sur la structure de distance XOR de Kademlia. Les nœuds transmettent les messages uniquement à des pairs sélectionnés, à des distances croissantes, créant un effet en cascade plutôt qu’une répétition aveugle. Cela réduit considérablement les transmissions redondantes par rapport aux protocoles de type gossip, comme ceux sur lesquels Ethereum s’appuie. Cela dissimule aussi naturellement l’origine d’un message, puisqu’il passe par plusieurs sauts avant d’atteindre le réseau plus large, ce qui correspond à l’orientation confidentialité de Dusk pour les transactions financières.
Ce que le livre blanc n’explique pas clairement, ce sont des chiffres précis de latence dans le monde réel, dans des conditions réseau défavorables, comme ce qui se passe précisément lors d’une congestion régionale dans des lieux où l’infrastructure est instable. C’est un manque que je ne peux pas combler avec confiance.
Le vrai test pour DUSK est de savoir si Kadcast conserve son avantage d’efficacité lorsque le nombre de nœuds augmente jusqu’à atteindre des milliers, sous une pression réelle du réseau—pas seulement dans des conditions de testnet contrôlées.
Quelqu’un ici a-t-il réellement fait tourner un nœud Dusk assez longtemps pour remarquer par lui-même des différences de vitesse de propagation ?
#dusk $DUSK @Dusk
