#dusk $DUSK @Dusk La configuration de confidentialité de Dusk fonctionne en réalité sur deux filières distinctes. Sur DuskDS, le modèle Phoenix représente la valeur sous forme de notes engagées dans un arbre de Merkle — dépenser une note ne pointe pas vers quelle note est dépensée. À la place, l’émetteur publie un nullificateur et une preuve de connaissance zéro montrant que la dépense est valide, que la possession est réelle et qu’aucune valeur n’a été créée à partir de rien, sans révéler la note sous-jacente. En parallèle, Moonlight fonctionne comme un modèle transparent basé sur les comptes, sur la même chaîne.
Sur DuskEVM, en revanche, la confidentialité provient d’un ensemble d’outils complètement différent — un module appelé Hedger, qui combine un chiffrement homomorphe basé sur ElGamal avec des preuves de connaissance zéro, ainsi qu’une structure hybride UTXO/comptes. Ici, un utilisateur interagit avec des contrats via une adresse EVM standard, tandis qu’une adresse Hedger distincte gère les soldes chiffrés, avec une conformité imposée par liste d’autorisation.
Il ne s’agit pas de deux versions de la même idée. Phoenix est un système de preuve basé sur des notes ; Hedger calcule directement sur des soldes chiffrés, vérifiés via des preuves de connaissance zéro. La raison la plus probable de cette séparation est que la confidentialité basée sur des notes ne s’intègre pas naturellement dans une structure EVM basée sur des comptes, d’où la nécessité d’une approche différente.
Faire tourner en parallèle deux piles indépendantes de confidentialité cryptographique implique une surface d’attaque plus large et une charge d’audit plus lourde. On ne sait également pas clairement comment la garantie de confidentialité est préservée lorsque la valeur passe d’une couche à l’autre.
Le fait de maintenir deux moteurs de confidentialité distincts multiplie-t-il la charge d’audit de manière proportionnelle, ou bien le recours partagé aux preuves de connaissance zéro signifie-t-il que le coût incrémental du second moteur est en réalité plus faible qu’il n’y paraît ?
Sur DuskEVM, en revanche, la confidentialité provient d’un ensemble d’outils complètement différent — un module appelé Hedger, qui combine un chiffrement homomorphe basé sur ElGamal avec des preuves de connaissance zéro, ainsi qu’une structure hybride UTXO/comptes. Ici, un utilisateur interagit avec des contrats via une adresse EVM standard, tandis qu’une adresse Hedger distincte gère les soldes chiffrés, avec une conformité imposée par liste d’autorisation.
Il ne s’agit pas de deux versions de la même idée. Phoenix est un système de preuve basé sur des notes ; Hedger calcule directement sur des soldes chiffrés, vérifiés via des preuves de connaissance zéro. La raison la plus probable de cette séparation est que la confidentialité basée sur des notes ne s’intègre pas naturellement dans une structure EVM basée sur des comptes, d’où la nécessité d’une approche différente.
Faire tourner en parallèle deux piles indépendantes de confidentialité cryptographique implique une surface d’attaque plus large et une charge d’audit plus lourde. On ne sait également pas clairement comment la garantie de confidentialité est préservée lorsque la valeur passe d’une couche à l’autre.
Le fait de maintenir deux moteurs de confidentialité distincts multiplie-t-il la charge d’audit de manière proportionnelle, ou bien le recours partagé aux preuves de connaissance zéro signifie-t-il que le coût incrémental du second moteur est en réalité plus faible qu’il n’y paraît ?