#dusk $DUSK Ces dernières années, en voyant des « blockchains de confidentialité » faire faillite, j’ai pris, doucement, l’habitude suivante : je me soucie moins de savoir si les algorithmes de chiffrement ont été cassés. À la place, je regarde d’abord si la personne qui a laissé des « backdoors » conformes est bien tenue par des contraintes. J’ai vu trop de projets de confidentialité exploser. Le problème n’est pas que la preuve à divulgation nulle (zero-knowledge) a été brisée. La racine, c’est la conception des permissions : dès le départ, elle suppose implicitement que « le projet ne touchera pas aux données des utilisateurs ». Tant que cette hypothèse ne tient pas une seule fois, les données d’actifs et les données de transaction des utilisateurs finissent par être exposées — tôt ou tard.
C’est <dusk_foundation> que j’ai suivi pour le flux d’exécution ZkKYC de la version RC du mainnet. Ce qui m’a fait m’arrêter, c’est cette couche. Ce n’est pas juste ajouter un module de conformité par-dessus une blockchain de confidentialité : c’est transformer directement la question de « qui peut voir mes données » en une règle rigide vérifiable par un circuit à divulgation nulle. Avant que l’utilisateur n’active les droits d’audit, la règle doit d’abord passer par la vérification du circuit du module natif Citadel. Les justificatifs d’identité restent détenus localement ; l’état des transactions repose sur des engagements chiffrés de type Pedersen. La logique de vérification est entièrement publique on-chain. Même le projet ne peut pas contourner le circuit pour récupérer des données utilisateur en direct : la preuve à divulgation nulle garantit en plus que le processus de contrôle des droits n’a pas été falsifié. Si l’utilisateur n’a pas autorisé la portée définie, aucune demande d’audit ne peut, en réalité, accéder aux données en clair.
#dusk Cette approche ressemble à obtenir une preuve de fonds à la banque : le guichetier ne peut pas parcourir directement l’ensemble de votre historique de compte ; il ne peut établir, uniquement, les justificatifs correspondant au montant et à l’usage que vous demandez, sans obtenir d’informations supplémentaires. Jusqu’à présent, la chaîne manquait de ce verrou d’« attestation de confidentialité » : Dusk ne veut pas renforcer l’anonymat à l’extrême, mais tracer une frontière contrôlable par l’utilisateur.
Je ne vais pas non plus le porter aux nues. Si l’utilisateur perd ses justificatifs KYC locaux, il ne pourra plus ouvrir des preuves d’audit conformes. Si le circuit à divulgation nulle a un bug logique, le contrôle des permissions aura aussi des failles. La vraie question n’est pas de savoir si le récit est joli : c’est de vérifier si, une fois que ces actifs RWA réels tournent réellement, les contraintes de confidentialité tiennent.
À l’avenir, il y aura de plus en plus d’actifs conformes on-chain. Ce qui m’importe le plus n’est pas de savoir si la chaîne peut faire des transactions anonymes, mais plutôt qui peut prouver que votre confidentialité n’appartient qu’à vous — et que vous seul en décidez @Dusk
C’est <dusk_foundation> que j’ai suivi pour le flux d’exécution ZkKYC de la version RC du mainnet. Ce qui m’a fait m’arrêter, c’est cette couche. Ce n’est pas juste ajouter un module de conformité par-dessus une blockchain de confidentialité : c’est transformer directement la question de « qui peut voir mes données » en une règle rigide vérifiable par un circuit à divulgation nulle. Avant que l’utilisateur n’active les droits d’audit, la règle doit d’abord passer par la vérification du circuit du module natif Citadel. Les justificatifs d’identité restent détenus localement ; l’état des transactions repose sur des engagements chiffrés de type Pedersen. La logique de vérification est entièrement publique on-chain. Même le projet ne peut pas contourner le circuit pour récupérer des données utilisateur en direct : la preuve à divulgation nulle garantit en plus que le processus de contrôle des droits n’a pas été falsifié. Si l’utilisateur n’a pas autorisé la portée définie, aucune demande d’audit ne peut, en réalité, accéder aux données en clair.
#dusk Cette approche ressemble à obtenir une preuve de fonds à la banque : le guichetier ne peut pas parcourir directement l’ensemble de votre historique de compte ; il ne peut établir, uniquement, les justificatifs correspondant au montant et à l’usage que vous demandez, sans obtenir d’informations supplémentaires. Jusqu’à présent, la chaîne manquait de ce verrou d’« attestation de confidentialité » : Dusk ne veut pas renforcer l’anonymat à l’extrême, mais tracer une frontière contrôlable par l’utilisateur.
Je ne vais pas non plus le porter aux nues. Si l’utilisateur perd ses justificatifs KYC locaux, il ne pourra plus ouvrir des preuves d’audit conformes. Si le circuit à divulgation nulle a un bug logique, le contrôle des permissions aura aussi des failles. La vraie question n’est pas de savoir si le récit est joli : c’est de vérifier si, une fois que ces actifs RWA réels tournent réellement, les contraintes de confidentialité tiennent.
À l’avenir, il y aura de plus en plus d’actifs conformes on-chain. Ce qui m’importe le plus n’est pas de savoir si la chaîne peut faire des transactions anonymes, mais plutôt qui peut prouver que votre confidentialité n’appartient qu’à vous — et que vous seul en décidez @Dusk
