#dusk $DUSK @Dusk
Ce qui a attiré mon attention n’est pas le message de conformité de Dusk, mais ce qu’a révélé un audit indépendant : une société d’audit a découvert quelque chose niché dans le système de preuve de Dusk, sécurisant le modèle de transaction à découvert de Phoenix @Dusk sur DuskDS.
Le mécanisme : Phoenix utilise des preuves PLONK pour qu’une dépense puisse être vérifiée sans révéler les soldes. Le vérificateur est censé contrôler un lot d’engagements de polynômes avec une clé de vérification de référence avant d’accepter toute preuve comme valide.
La partie que je voulais vérifier : selon une note de sécurité, quatre de ces évaluations de sélecteurs n’ont en réalité jamais été vérifiées par rapport à leurs engagements. Le vérificateur les a consommées sans les valider. En théorie, cette faille pourrait permettre à une preuve forgée de passer pour légitime.
Pourquoi c’est important : cela se trouve directement sous le pool protégé, censé hériter de la confidentialité des flux d’actifs qu’il régule. Une preuve forgée dans un système de notes opaque est difficile à détecter a posteriori : c’est précisément l’objectif du chiffrement.
Le détail le plus que beaucoup manqueraient : le correctif a été déployé à la mi-février 2026, avant la divulgation publique en avril — donc corrigé sans exploitation, d’après ce qui a été publié. Ce qui m’est moins clair, c’est de savoir si c’est une découverte issue de la revue interne de Dusk ou d’un acteur externe en premier, et comment ce calendrier a été communiqué aux partenaires qui s’appuient sur cette couche.
« Audited » (audité) signifie-t-il vraiment quelque chose si le correctif a précédé la divulgation de deux mois ?
$DUSK #dusk
Ce qui a attiré mon attention n’est pas le message de conformité de Dusk, mais ce qu’a révélé un audit indépendant : une société d’audit a découvert quelque chose niché dans le système de preuve de Dusk, sécurisant le modèle de transaction à découvert de Phoenix @Dusk sur DuskDS.
Le mécanisme : Phoenix utilise des preuves PLONK pour qu’une dépense puisse être vérifiée sans révéler les soldes. Le vérificateur est censé contrôler un lot d’engagements de polynômes avec une clé de vérification de référence avant d’accepter toute preuve comme valide.
La partie que je voulais vérifier : selon une note de sécurité, quatre de ces évaluations de sélecteurs n’ont en réalité jamais été vérifiées par rapport à leurs engagements. Le vérificateur les a consommées sans les valider. En théorie, cette faille pourrait permettre à une preuve forgée de passer pour légitime.
Pourquoi c’est important : cela se trouve directement sous le pool protégé, censé hériter de la confidentialité des flux d’actifs qu’il régule. Une preuve forgée dans un système de notes opaque est difficile à détecter a posteriori : c’est précisément l’objectif du chiffrement.
Le détail le plus que beaucoup manqueraient : le correctif a été déployé à la mi-février 2026, avant la divulgation publique en avril — donc corrigé sans exploitation, d’après ce qui a été publié. Ce qui m’est moins clair, c’est de savoir si c’est une découverte issue de la revue interne de Dusk ou d’un acteur externe en premier, et comment ce calendrier a été communiqué aux partenaires qui s’appuient sur cette couche.
« Audited » (audité) signifie-t-il vraiment quelque chose si le correctif a précédé la divulgation de deux mois ?
$DUSK #dusk
