#dusk $DUSK
Les solutions de double dépense sont apparues dans deux sections différentes des mêmes documents de protocole, et j’ai continué à les traiter comme la même idée jusqu’à ce que j’examine les deux de près.

Nonce Moonlight : un simple compteur. Votre compte possède un nonce actuel. Chaque transaction doit inclure exactement current_nonce + 1. Le réseau rejette tout le reste. Visible, séquentiel, vérifiable publiquement.

Nullificateur Phoenix : une valeur cryptographique dérivée de la clé secrète de la note. Lorsque vous dépensez une note, vous soumettez le nullificateur. Le réseau l’ajoute à la liste des nullificateurs. Personne ne peut renvoyer le même nullificateur — la double dépense est bloquée. Le nullificateur ne révèle rien au sujet de la note ni du montant.

Sur le réseau principal (mainnet), les transactions se règlent en moins de 10 secondes. Les deux mécanismes fonctionnent dans cette fenêtre : quel que soit le modèle utilisé, la vérification de double dépense se résout avant le bloc suivant.

Le nonce de Moonlight est transparent par conception : il permet à chacun de vérifier qu’une transaction est réellement nouvelle. Le nullificateur de Phoenix est privé par conception : il prouve l’unicité sans révéler quelle note a été dépensée.

La comparaison est plus intéressante qu’elle n’en a l’air : la même garantie fondamentale — ce transfert est nouveau et non rejouable — est appliquée avec des quantités d’information divulguées complètement différentes. L’un diffuse le compteur. L’autre prouve l’unicité sans rien montrer.

Quelle approche s’adapte le mieux à une forte charge de transactions — état séquentiel visible ou ensembles de nullificateurs privés ? @Dusk

$DUSK #dusk