Ces derniers jours, j’ai encore décortiqué une fois la structure des transactions de Phoenix. Cette fois, j’ai carrément séparé une transaction pour voir clairement quels éléments peuvent être visibles en chaîne et lesquels restent invisibles
━━━━━━━━━━━━━━
▎note : qu’y a-t-il vraiment dedans
Phoenix est un modèle UTXO : chaque fraction d’actif sur la chaîne s’appelle un note. Un note regroupe trois éléments : une promesse (commitment) du montant (ce n’est pas un nombre en clair, mais une valeur engagée chiffrée), un facteur d’aveuglement (dit simplement : une “sal” aléatoire ajoutée au commitment pour empêcher quelqu’un de deviner le montant par collision), et enfin un nombre aléatoire unique à usage unique, qui garantit que chaque note est distincte et ne “cogne” pas avec les autres
Avec ces trois éléments, ce que l’on voit en chaîne, ce sont simplement des données chiffrées : combien on a réellement transféré, et la valeur exacte de ce note… un tiers ne peut pas le deviner. Pourtant, le réseau peut vérifier que la somme des engagements garantit l’équilibre des entrées et des sorties, sans avoir besoin de déchiffrer aucun chiffre précis
━━━━━━━━━━━━━━
▎Anti-double dépense grâce au nullifier
Le point que je trouve vraiment ingénieux, c’est que le système ne se base pas sur “supprimer l’ancien note” pour empêcher une dépense en double. Il repose plutôt sur la publication d’un justificatif de consommation dont on ne peut pas le rattacher au note d’origine
Quand on dépense un note, on génère un nullifier correspondant. C’est un résultat calculé de manière déterministe, mais vu de l’extérieur, impossible de remonter à quel note il correspond. Le réseau a juste besoin de surveiller : « ce nullifier a-t-il déjà été vu ? » S’il apparaît, cela signifie que le note correspondant a déjà été dépensé. Si on tente de dépenser à nouveau le même note, on génère le même nullifier : il entre en collision avec un enregistrement existant, et le système rejette immédiatement
Tout le processus ne révèle pas « qui dépense quoi ». Tout se règle via la détection de collisions
━━━━━━━━━━━━━━
▎Hash Poseidon : les fondations de tout l’état de confidentialité
L’état de confidentialité doit être stocké dans un arbre de Merkle, afin de permettre des preuves d’inclusion (prouver que « ce note existe bien dans l’arbre d’état »)
Mettre une fonction de hachage classique dans un circuit zk coûterait extrêmement cher. Poseidon est un algorithme de hachage conçu spécifiquement pour les zk : sa structure s’accorde mieux avec le système de preuve, ce qui réduit fortement le coût des opérations de hachage dans les circuits. Sans un tel hash “friendly zk”, la génération des preuves de l’arbre d’état de confidentialité serait trop lente pour être utilisable
@Dusk $DUSK #dusk
Dans la transaction Phoenix, quel mécanisme empêche les actifs cachés d’être doublement dépensés ?