#dusk $DUSK Quand je lis la documentation technique de Dusk, je fais particulièrement attention au processus de génération et de vérification des preuves à divulgation nulle (ZKP) dans le protocole Phoenix. Le livre blanc décrit très clairement le protocole Plonk, mais ce qui m’a vraiment fait m’arrêter, c’est ceci : le document ne donne presque aucun repère de temps de génération des preuves dans un environnement de réseau principal.
C’est précisément le goulot d’étranglement clé pour concrétiser les transactions de confidentialité. Phoenix représente les fonds sous forme de notes chiffrées, et à chaque transfert il faut générer une preuve localement — la preuve autorise l’expéditeur à consommer la note, garantit que le montant n’est pas négatif, que les entrées et sorties sont équilibrées, et qu’il n’y a pas de double dépense. Cette génération de preuve s’effectue sur l’appareil de l’utilisateur : elle ne dépend pas du réseau, mais elle nécessite de la puissance de calcul.
La question est donc la suivante : si un utilisateur met 30 secondes, voire plus, pour générer la preuve d’une transaction shielded sur son téléphone, alors les transferts privés ne peuvent pas devenir une expérience de paiement quotidienne. Si la génération de preuves exige beaucoup de mémoire, les appareils bas de gamme ne peuvent tout simplement pas l’utiliser. Le problème, c’est aussi que, dans Dusk, Phoenix et Moonlight sont deux modèles : lorsque l’utilisateur repasse de shielded vers public, il faut encore générer une preuve.
J’ai consulté le dépôt GitHub de Dusk et les discussions de la communauté. À l’heure actuelle, les données de performance que je peux trouver proviennent surtout d’environnements de test ou de matériels spécifiques. Je n’ai pas vu de rapports de benchmarks ciblant le mobile, le navigateur ou même un ordinateur portable standard. Et l’optimisation de la génération de preuves ZKP — du choix de l’algorithme à la conception du circuit, puis à l’accélération matérielle — peut soit réduire la latence de l’échelle des secondes à celle des millisecondes, soit au contraire partir en vrille si la complexité gonfle.
Un autre aspect facile à négliger, ce sont les coûts de vérification. Même si la génération de preuves est réalisée côté utilisateur, la vérification on-chain consomme du Gas. Si le coût de vérification augmente linéairement avec la complexité de la transaction, alors à forte charge, une transaction de confidentialité peut coûter plusieurs fois plus cher qu’une transaction publique — autrement dit, on repousse l’utilisateur vers Moonlight… par le prix.@Dusk
Donc, pour évaluer l’utilisabilité de la confidentialité dans Dusk, je ne me demande pas quel système de preuves il supporte : je regarde la latence de génération des preuves sur du matériel ordinaire, la courbe de consommation de Gas pour la vérification on-chain, et la part que représentent les transactions Phoenix dans l’ensemble, en vérifiant si elle augmente naturellement. Les mathématiques du livre blanc sont un point de départ ; le minuteur sur l’appareil est l’arrivée. $DUSK