#dusk $DUSK @Dusk Mettre la conformité dans la couche de confidentialité, mais ne pas sortir le produit du CLI
Ces jours-ci, j’ai relu la testnet de Dusk et sa documentation. Je n’ai pas pris la feuille de route pour des promesses vides : j’ai juste essayé les trois entrées que sont les nœuds, les transferts et le navigateur de blocs. Ce que Dusk veut faire n’est pas nouveau dans la voie de la confidentialité : rendre par défaut sur la chaîne la confidentialité des actifs soumis à réglementation. Mais sa manière d’intégrer une identité conforme directement dans la construction des transactions ressemble assez peu à ce que font Secret et Oasis. Secret s’oriente vers des contrats de confidentialité généralistes, Oasis isole via la TEE ; Dusk, lui, ressemble plutôt à : d’abord afficher clairement la possibilité d’audit, puis comprimer la quantité d’informations à l’aide de preuves à connaissance zéro. La direction n’est pas mauvaise, mais du côté produit, c’est manifestement en retard d’un cran.
Les ressources nécessaires pour faire tourner un nœud ne sont pas démesurées, et cela reste plutôt favorable aux validateurs de taille moyenne. Le principal problème vient de l’expérience de bout en bout. Une fois qu’un transfert privé est envoyé, on ne voit presque aucun état lisible apparaître dans le navigateur de blocs : on ne peut revenir qu’aux journaux d’événements en attendant via le CLI. Cette semi-transparence peut se défendre au regard de l’intention de confidentialité, mais pour une équipe qui fait des audits de conformité, c’est franchement difficile. La documentation du SDK de Dusk a aussi des “trous” : les exemples de base fonctionnent, mais dès qu’on touche à la séparation des permissions et à la divulgation sélective, on se retrouve sans suite. En comparaison, chez Polymesh, les outils de couches d’identité sont beaucoup plus fins : les niveaux de rôle et les règles de signature se configurent directement dès la boîte.
Côté tokens, pour le moment la capture de valeur sur le réseau de Dusk tourne encore surtout autour du staking et des frais ; je n’ai pas vraiment vu de différenciation dans les pondérations de gouvernance. Leur récit de conformité est facile à faire accepter sur le marché secondaire, mais pour de vraies institutions, il manque encore un module de transfert d’identité qui ne dépend pas d’un KYC manuel. Oasis et Concordium sont plus matures dans la gestion des frontières entre identité privée et conformité on-chain. Si Dusk se contente de rester au stade de la démo sur testnet, l’écart ne fera que continuer à s’agrandir.
Je ne remets pas en cause la valeur à long terme des blockchains de confidentialité : je pense même que l’angle choisi par Dusk, davantage que la narration pure de l’anonymat, lui permet de mieux tenir face à la régulation. Mais à l’étape actuelle, j’ai l’impression qu’il y a davantage d’ambition côté protocole que de niveau d’aboutissement côté application. Plutôt que de continuer à insister sur le côté “conforme-friendly”, mieux vaudrait d’abord sortir les développeurs du CLI : compléter le navigateur et les outils d’identité.
Ces jours-ci, j’ai relu la testnet de Dusk et sa documentation. Je n’ai pas pris la feuille de route pour des promesses vides : j’ai juste essayé les trois entrées que sont les nœuds, les transferts et le navigateur de blocs. Ce que Dusk veut faire n’est pas nouveau dans la voie de la confidentialité : rendre par défaut sur la chaîne la confidentialité des actifs soumis à réglementation. Mais sa manière d’intégrer une identité conforme directement dans la construction des transactions ressemble assez peu à ce que font Secret et Oasis. Secret s’oriente vers des contrats de confidentialité généralistes, Oasis isole via la TEE ; Dusk, lui, ressemble plutôt à : d’abord afficher clairement la possibilité d’audit, puis comprimer la quantité d’informations à l’aide de preuves à connaissance zéro. La direction n’est pas mauvaise, mais du côté produit, c’est manifestement en retard d’un cran.
Les ressources nécessaires pour faire tourner un nœud ne sont pas démesurées, et cela reste plutôt favorable aux validateurs de taille moyenne. Le principal problème vient de l’expérience de bout en bout. Une fois qu’un transfert privé est envoyé, on ne voit presque aucun état lisible apparaître dans le navigateur de blocs : on ne peut revenir qu’aux journaux d’événements en attendant via le CLI. Cette semi-transparence peut se défendre au regard de l’intention de confidentialité, mais pour une équipe qui fait des audits de conformité, c’est franchement difficile. La documentation du SDK de Dusk a aussi des “trous” : les exemples de base fonctionnent, mais dès qu’on touche à la séparation des permissions et à la divulgation sélective, on se retrouve sans suite. En comparaison, chez Polymesh, les outils de couches d’identité sont beaucoup plus fins : les niveaux de rôle et les règles de signature se configurent directement dès la boîte.
Côté tokens, pour le moment la capture de valeur sur le réseau de Dusk tourne encore surtout autour du staking et des frais ; je n’ai pas vraiment vu de différenciation dans les pondérations de gouvernance. Leur récit de conformité est facile à faire accepter sur le marché secondaire, mais pour de vraies institutions, il manque encore un module de transfert d’identité qui ne dépend pas d’un KYC manuel. Oasis et Concordium sont plus matures dans la gestion des frontières entre identité privée et conformité on-chain. Si Dusk se contente de rester au stade de la démo sur testnet, l’écart ne fera que continuer à s’agrandir.
Je ne remets pas en cause la valeur à long terme des blockchains de confidentialité : je pense même que l’angle choisi par Dusk, davantage que la narration pure de l’anonymat, lui permet de mieux tenir face à la régulation. Mais à l’étape actuelle, j’ai l’impression qu’il y a davantage d’ambition côté protocole que de niveau d’aboutissement côté application. Plutôt que de continuer à insister sur le côté “conforme-friendly”, mieux vaudrait d’abord sortir les développeurs du CLI : compléter le navigateur et les outils d’identité.