Je lisais le protocole Citadel de Dusk Network pendant la tâche. Le dépôt Citadel sur GitHub a récupéré des commits le 8 août — un travail actif, pas une spécification statique — et je me suis retrouvé coincé sur le modèle à trois parties plus longtemps que prévu.
L’expression « divulgation sélective » est très souvent utilisée dans les documents $DUSK @Dusk #dusk . Elle est exacte. Mais il y a un point structurel que l’architecture révèle et que le discours ne met pas vraiment en avant.
Citadel comporte trois parties : l’Utilisateur, le Fournisseur de licence (LP) et le Fournisseur de services (SP). Les preuves ZK vous protègent du SP — elles vérifient que vous atteignez un seuil de conformité sans voir vos données réelles. Cette partie fonctionne comme décrit. Mais le LP fait du KYC complet. Ils détiennent vos données. Ils émettent la licence on-chain. Chaque fournisseur de services ultérieur ne reçoit qu’une preuve, ce qui est élégant. La friction se situe en amont, lors de l’onboarding, pas à chaque « portillon ».
Ainsi, le modèle de confidentialité de Dusk n’est pas « caché à l’autorité ». C’est « caché aux contreparties, visible pour l’autorité que vous avez choisie ». Le LP sait tout. Les SP ne savent rien. Pour la finance réglementée, c’est probablement le bon design : il faut bien que quelqu’un soit le responsable de la conservation des données pour les régulateurs. Mais ça se lit différemment de la façon dont la plupart des gens interprètent la « confidentialité de la blockchain », qui a tendance à signifier caché à tout le monde par défaut.
Hmm… la question ouverte et intéressante, c’est qui joue réellement le rôle de LP dans la pratique. Si c’est un dépositaire réglementé ou un fournisseur KYC agréé, alors c’est une identité externalisée avec une meilleure UX, pas une identité décentralisée. Je ne suis pas sûr que ces deux visions finissent vraiment par se résoudre pleinement l’une dans l’autre.
L’expression « divulgation sélective » est très souvent utilisée dans les documents $DUSK @Dusk #dusk . Elle est exacte. Mais il y a un point structurel que l’architecture révèle et que le discours ne met pas vraiment en avant.
Citadel comporte trois parties : l’Utilisateur, le Fournisseur de licence (LP) et le Fournisseur de services (SP). Les preuves ZK vous protègent du SP — elles vérifient que vous atteignez un seuil de conformité sans voir vos données réelles. Cette partie fonctionne comme décrit. Mais le LP fait du KYC complet. Ils détiennent vos données. Ils émettent la licence on-chain. Chaque fournisseur de services ultérieur ne reçoit qu’une preuve, ce qui est élégant. La friction se situe en amont, lors de l’onboarding, pas à chaque « portillon ».
Ainsi, le modèle de confidentialité de Dusk n’est pas « caché à l’autorité ». C’est « caché aux contreparties, visible pour l’autorité que vous avez choisie ». Le LP sait tout. Les SP ne savent rien. Pour la finance réglementée, c’est probablement le bon design : il faut bien que quelqu’un soit le responsable de la conservation des données pour les régulateurs. Mais ça se lit différemment de la façon dont la plupart des gens interprètent la « confidentialité de la blockchain », qui a tendance à signifier caché à tout le monde par défaut.
Hmm… la question ouverte et intéressante, c’est qui joue réellement le rôle de LP dans la pratique. Si c’est un dépositaire réglementé ou un fournisseur KYC agréé, alors c’est une identité externalisée avec une meilleure UX, pas une identité décentralisée. Je ne suis pas sûr que ces deux visions finissent vraiment par se résoudre pleinement l’une dans l’autre.