J’ai lu la “whitepaper” de @Dusk et, franchement, je suis un peu accro… et aussi un peu perplexe.
La grosse affaire va bien ? Est-ce que le BTC a encore un avenir ?
Leur standard XSC repose sur un principe : “vouloir tout et en même temps”. Autrement dit : avoir à la fois la confidentialité et la conformité. Sur le papier, ça paraît parfait, mais en y réfléchissant, ce n’est pas aussi simple.
Dans la whitepaper, les détails techniques sont plutôt évoqués de façon subtile : on dit souvent “pour plus d’informations, voir un autre article”, et les points vraiment décisifs sont passés sous silence.
Ceux qui ont déjà traîné dans la finance savent que le nœud le plus complexe n’est jamais de savoir si la technologie peut fonctionner, mais plutôt à qui appartiennent réellement les droits et qui a la main.
Dans la whitepaper de Dusk, il est question d’un rôle appelé “Auditor” : les données de transaction seraient chiffrées avec la clé publique de l’auditeur, pour permettre une traçabilité côté régulation. Mais le problème, c’est : qui est cet auditeur ? Est-ce l’équipe du projet ? Un tiers désigné ? Ou l’institution de régulation elle-même ?
La logique derrière n’est pas du tout la même. Si la clé d’audit est détenue par l’équipe du projet, alors en quoi est-ce différent du modèle de garde centralisée classique de la finance traditionnelle ? Les clients institutionnels déposent leurs actifs… et du coup votre contrepartie, la taille de vos positions : le projet peut tout voir, parce qu’il en a la possibilité. Ce n’est pas de la confidentialité : c’est de la transparence à sens unique.
La whitepaper dit aussi que l’auditeur peut fonctionner en mode multi-signature “m-of-n”, géré via la cryptographie des seuils. L’idée est bonne : répartir le pouvoir. Mais concrètement, qui détient les fragments de clé ? Comment s’assurer que le processus d’audit ne soit pas détourné ? À ces niveaux de mise en œuvre, la whitepaper ne précise pas vraiment.
Un autre point intéressant : plus tard, Dusk a mis à niveau le modèle de trading Moonlight, en disant qu’il peut identifier l’identité de l’expéditeur d’une transaction Phoenix pour la montrer au destinataire. Autrement dit, on passe d’une anonymité totale à une “confidentialité contrôlée” : on sait qui a envoyé l’argent, mais les passants ne savent pas. En fait, c’est précisément l’état dont la finance conforme a besoin : entre contreparties, la clarté est totale ; mais l’interface du marché ne divulgue pas les secrets commerciaux.
En clair : pour savoir si XSC peut vraiment marcher, ce n’est pas uniquement une question de robustesse du ZK prouvant, mais de l’endroit où cette clé est attachée — et à quel mur elle est verrouillée. Si la conception de la gestion des clés n’est pas suffisamment rigoureuse, alors confidentialité et conformité deviennent un cycle mort où elles se freinent mutuellement au lieu de se compléter.
Et le partenariat de Dusk avec NPEX autour de 300 millions d’euros de titres tokenisés met bien ce problème sur la table. @Dusk $DUSK #dusk
La grosse affaire va bien ? Est-ce que le BTC a encore un avenir ?
Leur standard XSC repose sur un principe : “vouloir tout et en même temps”. Autrement dit : avoir à la fois la confidentialité et la conformité. Sur le papier, ça paraît parfait, mais en y réfléchissant, ce n’est pas aussi simple.
Dans la whitepaper, les détails techniques sont plutôt évoqués de façon subtile : on dit souvent “pour plus d’informations, voir un autre article”, et les points vraiment décisifs sont passés sous silence.
Ceux qui ont déjà traîné dans la finance savent que le nœud le plus complexe n’est jamais de savoir si la technologie peut fonctionner, mais plutôt à qui appartiennent réellement les droits et qui a la main.
Dans la whitepaper de Dusk, il est question d’un rôle appelé “Auditor” : les données de transaction seraient chiffrées avec la clé publique de l’auditeur, pour permettre une traçabilité côté régulation. Mais le problème, c’est : qui est cet auditeur ? Est-ce l’équipe du projet ? Un tiers désigné ? Ou l’institution de régulation elle-même ?
La logique derrière n’est pas du tout la même. Si la clé d’audit est détenue par l’équipe du projet, alors en quoi est-ce différent du modèle de garde centralisée classique de la finance traditionnelle ? Les clients institutionnels déposent leurs actifs… et du coup votre contrepartie, la taille de vos positions : le projet peut tout voir, parce qu’il en a la possibilité. Ce n’est pas de la confidentialité : c’est de la transparence à sens unique.
La whitepaper dit aussi que l’auditeur peut fonctionner en mode multi-signature “m-of-n”, géré via la cryptographie des seuils. L’idée est bonne : répartir le pouvoir. Mais concrètement, qui détient les fragments de clé ? Comment s’assurer que le processus d’audit ne soit pas détourné ? À ces niveaux de mise en œuvre, la whitepaper ne précise pas vraiment.
Un autre point intéressant : plus tard, Dusk a mis à niveau le modèle de trading Moonlight, en disant qu’il peut identifier l’identité de l’expéditeur d’une transaction Phoenix pour la montrer au destinataire. Autrement dit, on passe d’une anonymité totale à une “confidentialité contrôlée” : on sait qui a envoyé l’argent, mais les passants ne savent pas. En fait, c’est précisément l’état dont la finance conforme a besoin : entre contreparties, la clarté est totale ; mais l’interface du marché ne divulgue pas les secrets commerciaux.
En clair : pour savoir si XSC peut vraiment marcher, ce n’est pas uniquement une question de robustesse du ZK prouvant, mais de l’endroit où cette clé est attachée — et à quel mur elle est verrouillée. Si la conception de la gestion des clés n’est pas suffisamment rigoureuse, alors confidentialité et conformité deviennent un cycle mort où elles se freinent mutuellement au lieu de se compléter.
Et le partenariat de Dusk avec NPEX autour de 300 millions d’euros de titres tokenisés met bien ce problème sur la table. @Dusk $DUSK #dusk
