Je viens de passer en revue la dernière mise à jour de Dusk et un détail ne cesse d’être présenté de façon erronée.
La question habituelle est : cette chaîne a-t-elle de la confidentialité ou non. C’est une mauvaise question pour les institutions. J’ai vérifié comment Moonlight et Phoenix s’insèrent dans le même réseau Dusk et j’ai constaté qu’une
seule institution peut exécuter les deux postures selon ce que chaque transaction exige.
Pensez-y de cette façon. Moonlight est le grand livre entièrement public, des soldes transparents, simple pour les auditeurs. Phoenix est le grand livre protégé, les montants étant masqués par défaut, avec vérification appuyée par des preuves. Même institution, même réseau, deux postures réglementaires disponibles à la demande.
CHAÎNE DE POSTURE : Moonlight → Flux Standard → Soldes Publics → Le Régulateur lit directement | Phoenix → Opérations sensibles → Montants obfusqués → Vérification ZK → Pas de piste complète → Les validateurs DUSK appliquent les deux
Ce qui m’a frappé ici, c’est l’implication pratique. Les flux retail passent par Moonlight. Les grosses transactions par blocs, lorsque la taille de la position constitue une information non publique, passent par Phoenix. Il s’agit d’une divulgation graduée au niveau du protocole, pas d’un contournement.
Et franchement, le durcissement de Phoenix dans cette mise à jour compte précisément pour cette raison. Les transferts obfusquent maintenant la valeur par défaut. W3sper intègre son propre pilote de portefeuille plutôt que de dépendre de l’nOde, renforçant la frontière de confidentialité. Les entrées mal formées sont rejetées de manière plus stricte. Les notes de sortie transparentes non nulles sont bloquées avant d’entrer dans le flux.
Je continuais à me demander ce que cela signifie face à toute offre de confidentialité en L1, comme un mode unique et fixe. Changer de posture réglementaire selon le type de transaction sans modifier les chaînes constitue une proposition d’architecture réellement différente.
Le découpage entre Moonlight et Phoenix est-il la partie la plus sous-estimée de DUSK, ou la gestion de deux types de registres crée-t-elle plus de complexité que la flexibilité ne le justifie ?
#dusk $DUSK @Dusk
La question habituelle est : cette chaîne a-t-elle de la confidentialité ou non. C’est une mauvaise question pour les institutions. J’ai vérifié comment Moonlight et Phoenix s’insèrent dans le même réseau Dusk et j’ai constaté qu’une
seule institution peut exécuter les deux postures selon ce que chaque transaction exige.
Pensez-y de cette façon. Moonlight est le grand livre entièrement public, des soldes transparents, simple pour les auditeurs. Phoenix est le grand livre protégé, les montants étant masqués par défaut, avec vérification appuyée par des preuves. Même institution, même réseau, deux postures réglementaires disponibles à la demande.
CHAÎNE DE POSTURE : Moonlight → Flux Standard → Soldes Publics → Le Régulateur lit directement | Phoenix → Opérations sensibles → Montants obfusqués → Vérification ZK → Pas de piste complète → Les validateurs DUSK appliquent les deux
Ce qui m’a frappé ici, c’est l’implication pratique. Les flux retail passent par Moonlight. Les grosses transactions par blocs, lorsque la taille de la position constitue une information non publique, passent par Phoenix. Il s’agit d’une divulgation graduée au niveau du protocole, pas d’un contournement.
Et franchement, le durcissement de Phoenix dans cette mise à jour compte précisément pour cette raison. Les transferts obfusquent maintenant la valeur par défaut. W3sper intègre son propre pilote de portefeuille plutôt que de dépendre de l’nOde, renforçant la frontière de confidentialité. Les entrées mal formées sont rejetées de manière plus stricte. Les notes de sortie transparentes non nulles sont bloquées avant d’entrer dans le flux.
Je continuais à me demander ce que cela signifie face à toute offre de confidentialité en L1, comme un mode unique et fixe. Changer de posture réglementaire selon le type de transaction sans modifier les chaînes constitue une proposition d’architecture réellement différente.
Le découpage entre Moonlight et Phoenix est-il la partie la plus sous-estimée de DUSK, ou la gestion de deux types de registres crée-t-elle plus de complexité que la flexibilité ne le justifie ?
#dusk $DUSK @Dusk
Dusk’s Privacy Model
Moonlight vs Phoenix
Dual Ledger Design
4 heure(s) restante(s)
