#dusk $DUSK Je suis en train de lire aujourd’hui la documentation du modèle de transaction Phoenix de @Dusk , et je bloque sur un concept de base en matière de chaînes de confidentialité, mais souvent facilement ignoré : $DUSK n’a tout simplement pas d’« comptes » au niveau du protocole.
Sur une blockchain transparente comme Ethereum, chaque adresse correspond à un compte : le solde et l’historique des transactions sont visibles par tout le monde. Mais Phoenix suit une approche UTXO : le protocole ne stocke pas de comptes, seulement une multitude de choses appelées des « note ». Chaque note contient un montant et une condition de dépense. Une transaction, c’est le processus qui consiste à consommer des anciennes notes et à en produire de nouvelles. Le hachage de la nouvelle note est ajouté à un arbre de Merkle, dont les feuilles contiennent les empreintes de toutes les notes du réseau.
Le mécanisme anti-double dépense y devient particulièrement intéressant. Chaque transaction est accompagnée d’un ensemble de valeurs déterministes appelées des « nullifier ». Chaque nullifier correspond à une note consommée : il la marque comme invalide. Mais la façon dont ces nullifier sont générés passe par des opérations cryptographiques : un observateur externe qui voit apparaître un nullifier sait qu’« il y a une note qui a été dépensée », mais ne peut pas relier ce nullifier à une note précise. Le réseau confirme l’annulation, mais ne sait pas qui l’a annulée.
Je le compare à la comptabilité bancaire : ce n’est pas comme si on ouvrait une page et qu’on voyait alors toutes les opérations d’une personne. C’est plutôt comme déchiqueter chaque reçu, puis le jeter dans un destructeur, et utiliser ensuite un procédé de chiffrement pour dire au système : « ce reçu est déjà annulé ». Le système confirme que l’annulation est valide, mais celui qui fouille dans le destructeur ne peut pas reconstituer le reçu original, ni savoir à qui appartenait ce reçu.
Mais ce design n’a pas non plus de coût nul. À mesure que le nombre de notes augmente, l’arbre de Merkle grossit : chaque nœud complet doit maintenir la structure complète de l’arbre. La génération des nullifier dépend en outre d’hypothèses cryptographiques sous-jacentes ; si le choix des paramètres pose problème, la protection de la confidentialité devient alors quasi fictive. La documentation officielle publie les détails du protocole, mais dans un environnement de production, les taux de collision des nullifier et la vitesse d’expansion de l’arbre doivent être vérifiés en continu après le lancement sur le mainnet.
En regardant #dusk la couche de confidentialité, je ne me contenterai pas de me focaliser sur l’étiquette « on utilise UTXO ». Ce qu’il faut vraiment suivre, ce sont : la courbe de croissance du nombre de notes, la taille de l’ensemble des nullifier, et la charge de stockage des nœuds de vérification. $DUSK intègre la confidentialité dans la base du protocole, mais le coût d’entretien du registre de base se reflétera finalement sur les performances globales du réseau.
#dusk @Dusk