Dans le métro, le signal coupe et revient par à-coups. J’ai dû relire le document trois fois avant qu’il se charge enfin. Plus je regardais, plus je me sentais lucide : j’avais été entraîné hors du bon chemin par ces articles d’analyse.
Tout le monde parle de la confidentialité de Dusk, et la discussion tourne presque exclusivement autour du système de preuves à connaissance nulle de Phoenix : note, nullifier, adresses furtives… Ça sonne très “haut niveau”. Mais presque personne ne mentionne la couche réseau. Le protocole de diffusion utilisé par Dusk s’appelle Kadcast ; en dessous, c’est une structure de routage en couches basée sur Kademlia, avec une logique de routage selon la distance entre nœuds. Le message n’est pas envoyé aveuglément en “gossip” à tout le monde : il est transmis couche par couche le long de chemins dont la distance augmente, ce qui forme un arbre de multidiffusion en cascade. Cette conception vise à la base l’efficacité : les données des articles cités dans le whitepaper indiquent qu’on économise pas mal de bande passante par rapport au gossip, et que lorsque le rythme de production des blocs augmente, le taux de blocs obsolètes peut aussi baisser. Les chiffres exacts, je ne les ai plus en tête — de toute façon, c’est ce qui est mesuré dans les papiers, pas ce que Dusk a réellement testé.
Le plus intéressant, c’est que ce design entraîne aussi un effet secondaire : comme le message doit passer par plusieurs relais avant de se diffuser largement, ce n’est pas une diffusion directe des nœuds. Du coup, remonter pour déduire “de quel point la publication de ce message est partie en premier” devient beaucoup plus difficile. Mais ça n’a rien à voir avec la confidentialité des transactions portée par Phoenix grâce à la cryptographie. L’un repose sur une preuve mathématique, l’autre sur le flou introduit par la topologie réseau : la robustesse n’a absolument rien à voir.
Le plus absurde, c’est que beaucoup d’articles de vulgarisation mélangent ces deux couches, donnant l’impression que Dusk est privé de bout en bout. En réalité, cette ambiguïté au niveau réseau ne fait au mieux que “ajouter un petit plus”. Quand on fait face à une traçabilité professionnelle, ce n’est pas grand-chose. Je me suis presque laissé convaincre, moi aussi, par ce type d’explications vagues : quand je voyais quelqu’un dire que la confidentialité de la diffusion des messages de Dusk est forte, je supposais automatiquement que la confidentialité des transactions l’était aussi… mais ce n’est tout simplement pas la même chose. Ce n’est que ces derniers jours, en séparant clairement les deux couches, que j’ai enfin compris.
Désormais, quand je vois un projet de confidentialité, je commence toujours par demander : cette confidentialité dépend-elle de la cryptographie, ou est-elle due à la structure réseau ? La force n’est pas du tout la même.
Quand vous faites de l’analyse technique, est-ce que vous êtes aussi déjà tombés dans le piège de mélanger les caractéristiques de la couche réseau et la confidentialité de la couche application ? Dites-moi en commentaire. #dusk $DUSK @Dusk
Tout le monde parle de la confidentialité de Dusk, et la discussion tourne presque exclusivement autour du système de preuves à connaissance nulle de Phoenix : note, nullifier, adresses furtives… Ça sonne très “haut niveau”. Mais presque personne ne mentionne la couche réseau. Le protocole de diffusion utilisé par Dusk s’appelle Kadcast ; en dessous, c’est une structure de routage en couches basée sur Kademlia, avec une logique de routage selon la distance entre nœuds. Le message n’est pas envoyé aveuglément en “gossip” à tout le monde : il est transmis couche par couche le long de chemins dont la distance augmente, ce qui forme un arbre de multidiffusion en cascade. Cette conception vise à la base l’efficacité : les données des articles cités dans le whitepaper indiquent qu’on économise pas mal de bande passante par rapport au gossip, et que lorsque le rythme de production des blocs augmente, le taux de blocs obsolètes peut aussi baisser. Les chiffres exacts, je ne les ai plus en tête — de toute façon, c’est ce qui est mesuré dans les papiers, pas ce que Dusk a réellement testé.
Le plus intéressant, c’est que ce design entraîne aussi un effet secondaire : comme le message doit passer par plusieurs relais avant de se diffuser largement, ce n’est pas une diffusion directe des nœuds. Du coup, remonter pour déduire “de quel point la publication de ce message est partie en premier” devient beaucoup plus difficile. Mais ça n’a rien à voir avec la confidentialité des transactions portée par Phoenix grâce à la cryptographie. L’un repose sur une preuve mathématique, l’autre sur le flou introduit par la topologie réseau : la robustesse n’a absolument rien à voir.
Le plus absurde, c’est que beaucoup d’articles de vulgarisation mélangent ces deux couches, donnant l’impression que Dusk est privé de bout en bout. En réalité, cette ambiguïté au niveau réseau ne fait au mieux que “ajouter un petit plus”. Quand on fait face à une traçabilité professionnelle, ce n’est pas grand-chose. Je me suis presque laissé convaincre, moi aussi, par ce type d’explications vagues : quand je voyais quelqu’un dire que la confidentialité de la diffusion des messages de Dusk est forte, je supposais automatiquement que la confidentialité des transactions l’était aussi… mais ce n’est tout simplement pas la même chose. Ce n’est que ces derniers jours, en séparant clairement les deux couches, que j’ai enfin compris.
Désormais, quand je vois un projet de confidentialité, je commence toujours par demander : cette confidentialité dépend-elle de la cryptographie, ou est-elle due à la structure réseau ? La force n’est pas du tout la même.
Quand vous faites de l’analyse technique, est-ce que vous êtes aussi déjà tombés dans le piège de mélanger les caractéristiques de la couche réseau et la confidentialité de la couche application ? Dites-moi en commentaire. #dusk $DUSK @Dusk