J’ai disséqué l’architecture de confidentialité de @Dusk et j’ai repéré plusieurs problèmes que recouvrent certains récits de « confidentialité L1 conforme ».
Première couche : deux voies, deux coûts, $DUSK — le réseau principal fait tourner en parallèle Moonlight (transparent) et Phoenix (privé). Moonlight offre une expérience EVM classique ; mais Phoenix exige que, pour chaque transaction, le client génère une preuve zk-SNARK. wallet-core permet de sous-traiter ces preuves à un Prover externe — cette conception, à elle seule, montre que l’appareil local ne supporte pas la charge de calcul de circuits à haute fréquence.
Deuxième couche : la KYC est une porte d’entrée préalable
Le modèle de licence utilisé pour la RWA par Citadel impose d’abord d’avoir terminé la KYC. Rien de scandaleux, mais cela enferme le trafic actuel du réseau principal dans une plage de « petits lots institutionnels, règlements à forte valeur ». La stabilité que vous voyez est le résultat d’un scénario à faible concurrence.
Troisième couche : les limitations faussent la vérification
Aujourd’hui, Phoenix ne représente qu’une faible part des transactions, donc la charge de preuves reste limitée. Le système est stable dans un environnement maîtrisé, mais cela ne signifie pas que, une fois face à un déploiement massif côté grand public et à de fortes concurrences, la puissance de calcul des clients, la file d’attente des Provers et le débit des validateurs pourront maintenir l’efficacité. Le réseau principal peut prouver que « la confidentialité fonctionne », mais il ne prouve pas que « la confidentialité tient en charge ».
Quatrième couche : l’utilisateur peut être bloqué à la toute dernière étape
Une fois la KYC complétée, les actifs verrouillés, et au moment d’initier une transaction Phoenix, si la puissance de calcul locale est insuffisante ou si la file d’attente du Prover est congestionnée, le dernier pas peut ne pas aboutir. DUSK veut apporter une DeFi de confidentialité grand public : l’extension des Provers et le retour sur les échecs ne doivent pas être cantonnés aux mises à jour techniques.
Mon avis
Je ne cherche pas à rejeter #dusk en invoquant les coûts ZK ou la KYC : une confidentialité L1 et une blockchain sans permission sont tout simplement deux voies différentes. Mais « le processus peut tourner » et « il peut encaisser la charge » sont deux choses distinctes. Tant que la part de Phoenix n’a pas augmenté, que le réseau de Prover n’est pas suffisamment mature, et que l’optimisation des circuits de contrats complexes n’est pas au point, il faut observer le taux d’échec, le temps de génération des preuves et la fluidité des conversions entre modèles pour savoir s’il s’agit de « confidentialité qui tourne » ou de « confidentialité qui encaisse la charge ».
Première couche : deux voies, deux coûts, $DUSK — le réseau principal fait tourner en parallèle Moonlight (transparent) et Phoenix (privé). Moonlight offre une expérience EVM classique ; mais Phoenix exige que, pour chaque transaction, le client génère une preuve zk-SNARK. wallet-core permet de sous-traiter ces preuves à un Prover externe — cette conception, à elle seule, montre que l’appareil local ne supporte pas la charge de calcul de circuits à haute fréquence.
Deuxième couche : la KYC est une porte d’entrée préalable
Le modèle de licence utilisé pour la RWA par Citadel impose d’abord d’avoir terminé la KYC. Rien de scandaleux, mais cela enferme le trafic actuel du réseau principal dans une plage de « petits lots institutionnels, règlements à forte valeur ». La stabilité que vous voyez est le résultat d’un scénario à faible concurrence.
Troisième couche : les limitations faussent la vérification
Aujourd’hui, Phoenix ne représente qu’une faible part des transactions, donc la charge de preuves reste limitée. Le système est stable dans un environnement maîtrisé, mais cela ne signifie pas que, une fois face à un déploiement massif côté grand public et à de fortes concurrences, la puissance de calcul des clients, la file d’attente des Provers et le débit des validateurs pourront maintenir l’efficacité. Le réseau principal peut prouver que « la confidentialité fonctionne », mais il ne prouve pas que « la confidentialité tient en charge ».
Quatrième couche : l’utilisateur peut être bloqué à la toute dernière étape
Une fois la KYC complétée, les actifs verrouillés, et au moment d’initier une transaction Phoenix, si la puissance de calcul locale est insuffisante ou si la file d’attente du Prover est congestionnée, le dernier pas peut ne pas aboutir. DUSK veut apporter une DeFi de confidentialité grand public : l’extension des Provers et le retour sur les échecs ne doivent pas être cantonnés aux mises à jour techniques.
Mon avis
Je ne cherche pas à rejeter #dusk en invoquant les coûts ZK ou la KYC : une confidentialité L1 et une blockchain sans permission sont tout simplement deux voies différentes. Mais « le processus peut tourner » et « il peut encaisser la charge » sont deux choses distinctes. Tant que la part de Phoenix n’a pas augmenté, que le réseau de Prover n’est pas suffisamment mature, et que l’optimisation des circuits de contrats complexes n’est pas au point, il faut observer le taux d’échec, le temps de génération des preuves et la fluidité des conversions entre modèles pour savoir s’il s’agit de « confidentialité qui tourne » ou de « confidentialité qui encaisse la charge ».