$SOL La conformité de la confidentialité est la forteresse de Dusk, mais aussi sa propre « rampe ralentisseuse »
En relisant la documentation et le testnet de Dusk, une même conclusion me revient sans cesse : la direction est la bonne, mais la mise en œuvre est plus lente que ce que j’imaginais. $DUSK , en tant que gaz et actifs mis en jeu sur cette chaîne, mise sur un récit qui consiste à tokeniser des actifs conformes et à offrir une divulgation optionnelle de la confidentialité : dans le contexte réglementaire européen, l’idée est particulièrement séduisante. Mais dès qu’on exécute concrètement le processus d’émission d’actifs, les problèmes apparaissent. Dusk ne suit pas la voie compatible EVM. Son propre Rusk VM n’est pas en soi un problème, mais cela m’empêche de réutiliser directement l’outillage déjà prêt d’Ethereum.
Le volet « confidentialité » est paradoxalement la partie qui m’inquiète le moins chez Dusk. Les preuves à connaissance nulle combinées à la divulgation sélective signifient que le régulateur peut voir ce qu’il doit voir, tandis que les contreparties ne voient pas ce qu’elles ne devraient pas voir. C’est plus fin que l’approche de Polymesh, où l’identité est figée dans la chaîne. Polymesh convient davantage aux organisations qui ont déjà clairement accepté la conformité on-chain. Dusk ressemble plutôt à une recherche d’équilibre entre confidentialité et réglementation. Mais cet équilibre a un coût : les développeurs doivent se réadapter à la chaîne de compilation Rust vers WASM, et les coûts de migration ne sont pas négligeables. Cette friction peut encore être masquée par des subventions sur un marché haussier ; à présent, elle ne fera qu’aggraver les difficultés de démarrage.
En allant vraiment tester l’exploitation des nœuds, l’impression est plus directe. La synchronisation du testnet n’est pas lente, mais les procédures liées aux validateurs sont plutôt « hardcore ». La documentation est dispersée sur plusieurs entrées, sans qu’il existe un chemin unique qui permette d’aller jusqu’au bout. Si on prend Secret Network en exemple, on constate, dans le même axe « confidentialité », que les outils développeurs et l’expérience de portefeuille y sont plus fluides. En revanche, sur le cadre de conformité pour la tokenisation d’actifs, Secret n’a pas une conscience narrative aussi forte que Dusk. Les deux trajectoires diffèrent : le problème de Dusk ne se situe pas au niveau du protocole, mais dans l’écosystème et les outils périphériques.
Pour l’instant, je ne traiterai cette chaîne Dusk que comme un actif à observer sur le long terme. Sa voie technologique est rare, mais la densité d’écosystème et l’expérience de développement déterminent la vitesse à laquelle elle pourra avancer. Dans l’état actuel de démarrage à froid, c’est plus long que ce que j’avais imaginé. #dusk $DUSK @Dusk
En relisant la documentation et le testnet de Dusk, une même conclusion me revient sans cesse : la direction est la bonne, mais la mise en œuvre est plus lente que ce que j’imaginais. $DUSK , en tant que gaz et actifs mis en jeu sur cette chaîne, mise sur un récit qui consiste à tokeniser des actifs conformes et à offrir une divulgation optionnelle de la confidentialité : dans le contexte réglementaire européen, l’idée est particulièrement séduisante. Mais dès qu’on exécute concrètement le processus d’émission d’actifs, les problèmes apparaissent. Dusk ne suit pas la voie compatible EVM. Son propre Rusk VM n’est pas en soi un problème, mais cela m’empêche de réutiliser directement l’outillage déjà prêt d’Ethereum.
Le volet « confidentialité » est paradoxalement la partie qui m’inquiète le moins chez Dusk. Les preuves à connaissance nulle combinées à la divulgation sélective signifient que le régulateur peut voir ce qu’il doit voir, tandis que les contreparties ne voient pas ce qu’elles ne devraient pas voir. C’est plus fin que l’approche de Polymesh, où l’identité est figée dans la chaîne. Polymesh convient davantage aux organisations qui ont déjà clairement accepté la conformité on-chain. Dusk ressemble plutôt à une recherche d’équilibre entre confidentialité et réglementation. Mais cet équilibre a un coût : les développeurs doivent se réadapter à la chaîne de compilation Rust vers WASM, et les coûts de migration ne sont pas négligeables. Cette friction peut encore être masquée par des subventions sur un marché haussier ; à présent, elle ne fera qu’aggraver les difficultés de démarrage.
En allant vraiment tester l’exploitation des nœuds, l’impression est plus directe. La synchronisation du testnet n’est pas lente, mais les procédures liées aux validateurs sont plutôt « hardcore ». La documentation est dispersée sur plusieurs entrées, sans qu’il existe un chemin unique qui permette d’aller jusqu’au bout. Si on prend Secret Network en exemple, on constate, dans le même axe « confidentialité », que les outils développeurs et l’expérience de portefeuille y sont plus fluides. En revanche, sur le cadre de conformité pour la tokenisation d’actifs, Secret n’a pas une conscience narrative aussi forte que Dusk. Les deux trajectoires diffèrent : le problème de Dusk ne se situe pas au niveau du protocole, mais dans l’écosystème et les outils périphériques.
Pour l’instant, je ne traiterai cette chaîne Dusk que comme un actif à observer sur le long terme. Sa voie technologique est rare, mais la densité d’écosystème et l’expérience de développement déterminent la vitesse à laquelle elle pourra avancer. Dans l’état actuel de démarrage à froid, c’est plus long que ce que j’avais imaginé. #dusk $DUSK @Dusk