Je regardais comment Phoenix gère les notes dépensées, en m’attendant à ce que les nullifiants invalident simplement et discrètement de vieilles UTXO et qu’on passe à autre chose. C’est le modèle mental que donnent les chaînes transparentes : un spend a lieu, l’enregistrement se met à jour, les anciennes données deviennent sans intérêt.

Mais ce n’est pas exactement ce qui se passe ici. La note précédente ne disparaît pas. Son hash reste en permanence dans l’arbre de Merkle des notes — dépensée ou non, la feuille est toujours là, parce que l’arbre est append-only (ajout uniquement) et que le réseau ne peut pas élaguer sélectivement une note sans divulguer lesquelles étaient de vraies dépenses versus des leurres. C’est le nullifiant qui invalide la note pour la suite, et il est conçu de manière à ce qu’aucun observateur ne puisse lier un nullifiant à la note d’où il provient.

Cela m’a fait faire une pause : ici, la confidentialité n’est pas obtenue en supprimant de l’information, mais en accumulant de l’information impossible à recoupler. L’arbre ne fait que grandir. Chaque portefeuille qui se synchronise depuis zéro doit parcourir un ensemble de notes plus grand que le solde non dépensé réel dont il se soucie — les notes dépensées sont une charge morte qu’il doit tout de même traiter pour prouver correctement l’appartenance.

Ce n’est pas forcément un défaut. C’est le prix à payer pour rendre le recoupement computationnellement inutile plutôt que légalement interdit. Mais cela signifie que la confidentialité de Phoenix évolue avec la croissance de l’état, et non l’inverse — à surveiller au fur et à mesure que l’usage s’intensifie. #dusk $DUSK @Dusk