Phoenix contre Moonlight : Pourquoi Dusk avait besoin de deux modèles de transaction
Je pense que la partie la plus mal comprise de @Dusk n’est pas sa couche de confidentialité.
C’est la raison pour laquelle Dusk a construit, dès le départ, un modèle de transaction transparent aux côtés de Phoenix.
La réponse est simple : les marchés financiers ne fonctionnent pas avec une seule exigence de confidentialité.
Le livre blanc 2024 de Dusk décrit Moonlight comme la couche de transaction publique ajoutée en parallèle de Phoenix. Moonlight utilise un modèle basé sur des comptes, où les adresses et les soldes sont visibles. Phoenix emprunte le chemin inverse : des transactions protégées, basées sur des notes, avec des preuves à divulgation de connaissance nulle.
Avec Moonlight, un échange peut analyser les comptes, rapprocher les soldes et traiter les dépôts à l’aide d’un modèle de registre public familier. La documentation d’intégration actuelle de Dusk recommande d’ailleurs Moonlight pour les dépôts et retraits des échanges, car Phoenix nécessite une architecture différente de garde et d’analyse.
Ses notes sont chiffrées, tandis que les preuves à connaissance nulle permettent au réseau de vérifier des éléments comme la validité et la protection contre la double dépense sans révéler le montant de la transaction ni les notes spécifiques utilisées. Dusk a aussi conçu une divulgation sélective pour que la confidentialité ne signifie pas automatiquement « absence de responsabilité ».
Ainsi, le choix de conception initial n’était pas :
Phoenix contre Moonlight.
C’était :
la confidentialité quand c’est nécessaire + la transparence quand c’est requis.
Et il y a une mise à jour importante en 2026.
Le hard fork AEGIS de Dusk a corrigé 39 constats, dont 7 problèmes critiques, avec une cause racine critique liée à l’attachement des frais/remboursements de Phoenix.
Plus important encore, la documentation réseau la plus récente indique que la mise à niveau Boreas met fin aux transactions Phoenix sur le réseau, tandis que la gestion canonique des transactions a progressé.
Phoenix n’était pas simplement une fonctionnalité de confidentialité. C’était une expérience visant à faire fonctionner un règlement confidentiel aux côtés d’un rail financier public.
Ce sont des exigences de règlement différentes.
L’évolution de Dusk est particulièrement intéressante précisément parce que le protocole affine désormais les parties de cette architecture à double modèle initiale qui doivent encore appartenir à la pile de production.
#dusk
$DUSK
Je pense que la partie la plus mal comprise de @Dusk n’est pas sa couche de confidentialité.
C’est la raison pour laquelle Dusk a construit, dès le départ, un modèle de transaction transparent aux côtés de Phoenix.
La réponse est simple : les marchés financiers ne fonctionnent pas avec une seule exigence de confidentialité.
Le livre blanc 2024 de Dusk décrit Moonlight comme la couche de transaction publique ajoutée en parallèle de Phoenix. Moonlight utilise un modèle basé sur des comptes, où les adresses et les soldes sont visibles. Phoenix emprunte le chemin inverse : des transactions protégées, basées sur des notes, avec des preuves à divulgation de connaissance nulle.
Avec Moonlight, un échange peut analyser les comptes, rapprocher les soldes et traiter les dépôts à l’aide d’un modèle de registre public familier. La documentation d’intégration actuelle de Dusk recommande d’ailleurs Moonlight pour les dépôts et retraits des échanges, car Phoenix nécessite une architecture différente de garde et d’analyse.
Ses notes sont chiffrées, tandis que les preuves à connaissance nulle permettent au réseau de vérifier des éléments comme la validité et la protection contre la double dépense sans révéler le montant de la transaction ni les notes spécifiques utilisées. Dusk a aussi conçu une divulgation sélective pour que la confidentialité ne signifie pas automatiquement « absence de responsabilité ».
Ainsi, le choix de conception initial n’était pas :
Phoenix contre Moonlight.
C’était :
la confidentialité quand c’est nécessaire + la transparence quand c’est requis.
Et il y a une mise à jour importante en 2026.
Le hard fork AEGIS de Dusk a corrigé 39 constats, dont 7 problèmes critiques, avec une cause racine critique liée à l’attachement des frais/remboursements de Phoenix.
Plus important encore, la documentation réseau la plus récente indique que la mise à niveau Boreas met fin aux transactions Phoenix sur le réseau, tandis que la gestion canonique des transactions a progressé.
Phoenix n’était pas simplement une fonctionnalité de confidentialité. C’était une expérience visant à faire fonctionner un règlement confidentiel aux côtés d’un rail financier public.
Ce sont des exigences de règlement différentes.
L’évolution de Dusk est particulièrement intéressante précisément parce que le protocole affine désormais les parties de cette architecture à double modèle initiale qui doivent encore appartenir à la pile de production.
#dusk
$DUSK