J’ai regardé assez longtemps les « chaînes de confidentialité » pour savoir que la vraie friction ne vient pas seulement du fait de cacher les montants. Elle vient de ce qui se passe quand la chaîne commence à courir après la compatibilité EVM. La plupart des projets présentent cela comme un simple gain—plus de développeurs, des portefeuilles familiers, des outils existants. J’ai vu à quelle vitesse cette commodité commence à façonner, elle aussi, la conception de la confidentialité.
Dusk est intéressant parce qu’il ne fait pas semblant de pouvoir forcer les deux modèles à se rejoindre. DuskDS conserve l’approche Phoenix UTXO pour les transferts chiffrés natifs. Notes, nullifiants, preuves à divulgation nulle de connaissance qui dissimulent réellement le graphe. Côté EVM, ils ont construit Hedger : un chiffrement homomorphe pour masquer les valeurs, et des preuves pour démontrer que le calcul reste bien conforme. Les documentations officielles sont étonnamment honnêtes sur la limite : le modèle de compte d’EVM ne peut tout simplement pas fournir le même ensemble d’anonymat que Phoenix.
Cette franchise est rare. La plupart des équipes contournent le compromis. Vous voulez Solidity, MetaMask, toute la pile : vous acceptez que la confidentialité complète du graphe des transactions disparaisse et vous essayez de récupérer ce que vous pouvez avec des soldes chiffrés et de la divulgation sélective. La question devient alors de savoir si la norme de confidentialité tient dans les deux environnements d’exécution, ou si l’un finit discrètement par devenir le parent faible.
Je n’en suis pas encore sûr. J’ai vu trop de projets qui promettent un « EVM respectueux de la confidentialité » et finissent par proposer quelque chose qui ne cache que les chiffres, tandis que les adresses et les schémas d’interaction restent publics. La partie difficile a toujours été de prouver que le résultat est valide sans divulguer les entrées. Phoenix le fait d’une manière. Hedger tente une autre. Les deux doivent répondre au même problème discret qui revient après chaque cycle : combien de confidentialité reste-t-il quand on commence à rendre la chaîne pratique pour tout le monde.
@Dusk_Foundation #dusk $DUSK
Dusk est intéressant parce qu’il ne fait pas semblant de pouvoir forcer les deux modèles à se rejoindre. DuskDS conserve l’approche Phoenix UTXO pour les transferts chiffrés natifs. Notes, nullifiants, preuves à divulgation nulle de connaissance qui dissimulent réellement le graphe. Côté EVM, ils ont construit Hedger : un chiffrement homomorphe pour masquer les valeurs, et des preuves pour démontrer que le calcul reste bien conforme. Les documentations officielles sont étonnamment honnêtes sur la limite : le modèle de compte d’EVM ne peut tout simplement pas fournir le même ensemble d’anonymat que Phoenix.
Cette franchise est rare. La plupart des équipes contournent le compromis. Vous voulez Solidity, MetaMask, toute la pile : vous acceptez que la confidentialité complète du graphe des transactions disparaisse et vous essayez de récupérer ce que vous pouvez avec des soldes chiffrés et de la divulgation sélective. La question devient alors de savoir si la norme de confidentialité tient dans les deux environnements d’exécution, ou si l’un finit discrètement par devenir le parent faible.
Je n’en suis pas encore sûr. J’ai vu trop de projets qui promettent un « EVM respectueux de la confidentialité » et finissent par proposer quelque chose qui ne cache que les chiffres, tandis que les adresses et les schémas d’interaction restent publics. La partie difficile a toujours été de prouver que le résultat est valide sans divulguer les entrées. Phoenix le fait d’une manière. Hedger tente une autre. Les deux doivent répondre au même problème discret qui revient après chaque cycle : combien de confidentialité reste-t-il quand on commence à rendre la chaîne pratique pour tout le monde.
@Dusk_Foundation #dusk $DUSK