#dusk $DUSK @Dusk a fixé le document de Dusk pendant presque quarante minutes. Je n’ai cessé de réfléchir à une question : comment ces deux ensembles, Moonlight et Phoenix, se gèrent-ils au final ?
Moonlight suit une voie basée sur des comptes publics. Le solde, l’émetteur du virement, le destinataire et le montant sont tous inscrits sur la chaîne : tout le monde peut le voir. Ce système convient bien aux scénarios où la transparence est indispensable, comme l’alimentation d’un exchange ou la réconciliation comptable d’une institution.
Phoenix repose sur une logique totalement différente : l’actif devient un « note » chiffré, caché dans un arbre de Merkle. Quand vous dépensez de l’argent, vous ne révélez pas précisément quelle note vous utilisez. Vous envoyez plutôt un nullifier et une preuve ZKP. Le réseau peut vérifier que vous avez l’argent et que vous ne faites pas de double dépense, mais il ne voit ni le montant ni l’émetteur. Pour l’audit, il est possible de divulguer de manière sélective via une clé de vision (viewing key).
En début de mois, j’avais rencontré un problème similaire en rédigeant des notes sur les virements SEPA : entre deux systèmes bancaires, la réconciliation devient très pénible quand les statuts ne concordent pas. On m’a tellement fait tourner en rond que je suis resté éveillé jusqu’à deux heures du matin.
Si la blockchain mettait aussi en place deux registres isolés, autant en revenir à la finance traditionnelle.
À ce moment-là, j’étais un peu agacé : j’avais l’impression que le document n’expliquait pas assez clairement cette question. J’ai repris la section sur l’architecture des contrats du module Rusk. Les deux premiers paragraphes ne m’ont pas vraiment convaincu : il s’agissait surtout de décrire, pour Moonlight et Phoenix, leurs structures de données respectives. Ce n’est qu’en arrivant au quatrième paragraphe que j’ai compris l’intention de la conception : dans la définition de l’interface du Transfer Contract, il y avait un type d’énumération pour le payload.
Le Transfer Contract sert de point d’entrée de coordination. Il reçoit des payloads de formats différents — certains au format Moonlight, d’autres au format Phoenix. Le contrat se moque de votre origine ; il se contente de regarder quels champs sont contenus dans le payload, puis les dirige vers la logique de vérification correspondante. La vérification de Moonlight lit directement l’état du compte public ; celle de Phoenix exécute une preuve ZK. Une fois les deux vérifications réussies, le résultat est enregistré dans le même arbre d’état global.
Je n’ai mis un moment à comprendre l’élément clé de cette étape : si vous fusionnez les arbres d’état des deux systèmes en une seule structure, alors transférer de l’argent depuis le compte public vers une note privée revient essentiellement à une conversion de payload. Il n’est pas nécessaire de passer par un pont inter-chaînes, ni de mettre en place des protocoles de synchronisation complexes. Les mises à jour d’état sont atomiques : soit tout réussit, soit tout est annulé (rollback).
Moonlight suit une voie basée sur des comptes publics. Le solde, l’émetteur du virement, le destinataire et le montant sont tous inscrits sur la chaîne : tout le monde peut le voir. Ce système convient bien aux scénarios où la transparence est indispensable, comme l’alimentation d’un exchange ou la réconciliation comptable d’une institution.
Phoenix repose sur une logique totalement différente : l’actif devient un « note » chiffré, caché dans un arbre de Merkle. Quand vous dépensez de l’argent, vous ne révélez pas précisément quelle note vous utilisez. Vous envoyez plutôt un nullifier et une preuve ZKP. Le réseau peut vérifier que vous avez l’argent et que vous ne faites pas de double dépense, mais il ne voit ni le montant ni l’émetteur. Pour l’audit, il est possible de divulguer de manière sélective via une clé de vision (viewing key).
En début de mois, j’avais rencontré un problème similaire en rédigeant des notes sur les virements SEPA : entre deux systèmes bancaires, la réconciliation devient très pénible quand les statuts ne concordent pas. On m’a tellement fait tourner en rond que je suis resté éveillé jusqu’à deux heures du matin.
Si la blockchain mettait aussi en place deux registres isolés, autant en revenir à la finance traditionnelle.
À ce moment-là, j’étais un peu agacé : j’avais l’impression que le document n’expliquait pas assez clairement cette question. J’ai repris la section sur l’architecture des contrats du module Rusk. Les deux premiers paragraphes ne m’ont pas vraiment convaincu : il s’agissait surtout de décrire, pour Moonlight et Phoenix, leurs structures de données respectives. Ce n’est qu’en arrivant au quatrième paragraphe que j’ai compris l’intention de la conception : dans la définition de l’interface du Transfer Contract, il y avait un type d’énumération pour le payload.
Le Transfer Contract sert de point d’entrée de coordination. Il reçoit des payloads de formats différents — certains au format Moonlight, d’autres au format Phoenix. Le contrat se moque de votre origine ; il se contente de regarder quels champs sont contenus dans le payload, puis les dirige vers la logique de vérification correspondante. La vérification de Moonlight lit directement l’état du compte public ; celle de Phoenix exécute une preuve ZK. Une fois les deux vérifications réussies, le résultat est enregistré dans le même arbre d’état global.
Je n’ai mis un moment à comprendre l’élément clé de cette étape : si vous fusionnez les arbres d’état des deux systèmes en une seule structure, alors transférer de l’argent depuis le compte public vers une note privée revient essentiellement à une conversion de payload. Il n’est pas nécessaire de passer par un pont inter-chaînes, ni de mettre en place des protocoles de synchronisation complexes. Les mises à jour d’état sont atomiques : soit tout réussit, soit tout est annulé (rollback).
