Quand je lisais le livre blanc, cette question me tournait sans cesse dans la tête. Le plus grand récit de Dusk, c’est : je veux à la fois la confidentialité et la conformité, et l’expérience historique m’apprend que ce genre de promesse finit généralement par mécontenter tout le monde.#dusk
Regardons d’abord les mauvais exemples. Zcash et Monero ont poussé la confidentialité à l’extrême, mais les autorités de régulation n’ont pas accepté, les exchanges les ont retirés, et la liquidité a décliné. Ethereum et Bitcoin ne posent aucun problème du point de vue de la conformité, mais toutes les transactions sont transparentes : quand une institution effectue une grosse opération, le contrepartiste voit tout clairement. Dusk dit avoir trouvé une troisième voie, et au début, j’étais sceptique.@Dusk
La solution proposée dans le livre blanc repose sur un modèle de double transaction et le protocole Zedger. Moonlight est prévu pour les scénarios de conformité, Phoenix pour les scénarios de confidentialité, et Zedger permet d’exécuter des contrats intelligents dans un état confidentiel tout en conservant la capacité d’être auditable. En théorie, cette architecture pourrait fonctionner.
Mais en le terminant, je découvre une faille essentielle. Le livre blanc dit que les autorités de régulation peuvent accéder aux données nécessaires, mais il n’explique pas comment, par quel mécanisme l’autorisation est accordée, qui héberge les clés, ni comment révoquer les droits d’accès. Dans un système de confidentialité qui se veut auditable, la difficulté ne consiste pas tant à permettre aux régulateurs de voir les données, que de garantir que seules les bonnes personnes voient les bonnes données — et uniquement pendant la période autorisée.
J’ai essayé d’en déduire la logique de cette manière. Si Dusk utilise un système de preuves du type zk-SNARK, que les autorités conservent une clé d’audit spécifique,$DUSK pourrait alors vérifier la conformité des transactions sans exposer la confidentialité des utilisateurs. Dans ce cas, le schéma tient. Mais si les pouvoirs de régulation sont abusés, ou si la clé fuit, alors tout l’édifice de la protection de la vie privée s’effondre.
Donc ma conclusion est la suivante : la coexistence de la confidentialité et de la conformité est compréhensible en théorie et, sur le plan technique, potentiellement réalisable, mais l’effet réel dépend entièrement des détails de la conception des mécanismes de contrôle des permissions. Or, pour l’instant, le livre blanc ne fournit pas ces détails : je dois donc attendre la publication de davantage de documents techniques avant de pouvoir juger. La réponse à cette question n’est pas dans le livre blanc, elle se trouve dans le code du réseau principal.
Regardons d’abord les mauvais exemples. Zcash et Monero ont poussé la confidentialité à l’extrême, mais les autorités de régulation n’ont pas accepté, les exchanges les ont retirés, et la liquidité a décliné. Ethereum et Bitcoin ne posent aucun problème du point de vue de la conformité, mais toutes les transactions sont transparentes : quand une institution effectue une grosse opération, le contrepartiste voit tout clairement. Dusk dit avoir trouvé une troisième voie, et au début, j’étais sceptique.@Dusk
La solution proposée dans le livre blanc repose sur un modèle de double transaction et le protocole Zedger. Moonlight est prévu pour les scénarios de conformité, Phoenix pour les scénarios de confidentialité, et Zedger permet d’exécuter des contrats intelligents dans un état confidentiel tout en conservant la capacité d’être auditable. En théorie, cette architecture pourrait fonctionner.
Mais en le terminant, je découvre une faille essentielle. Le livre blanc dit que les autorités de régulation peuvent accéder aux données nécessaires, mais il n’explique pas comment, par quel mécanisme l’autorisation est accordée, qui héberge les clés, ni comment révoquer les droits d’accès. Dans un système de confidentialité qui se veut auditable, la difficulté ne consiste pas tant à permettre aux régulateurs de voir les données, que de garantir que seules les bonnes personnes voient les bonnes données — et uniquement pendant la période autorisée.
J’ai essayé d’en déduire la logique de cette manière. Si Dusk utilise un système de preuves du type zk-SNARK, que les autorités conservent une clé d’audit spécifique,$DUSK pourrait alors vérifier la conformité des transactions sans exposer la confidentialité des utilisateurs. Dans ce cas, le schéma tient. Mais si les pouvoirs de régulation sont abusés, ou si la clé fuit, alors tout l’édifice de la protection de la vie privée s’effondre.
Donc ma conclusion est la suivante : la coexistence de la confidentialité et de la conformité est compréhensible en théorie et, sur le plan technique, potentiellement réalisable, mais l’effet réel dépend entièrement des détails de la conception des mécanismes de contrôle des permissions. Or, pour l’instant, le livre blanc ne fournit pas ces détails : je dois donc attendre la publication de davantage de documents techniques avant de pouvoir juger. La réponse à cette question n’est pas dans le livre blanc, elle se trouve dans le code du réseau principal.