À 1 h du matin, j’ai revu l’incident du pont Dusk et enchaîné avec l’analyse d’AEGIS, et juste avant de fermer la page j’ai eu un petit frisson de peur : il y a quelques jours, j’ai moi aussi failli accepter cette idée tellement pratique en apparence : « ce n’est pas une faille L1, donc il n’y a rien à craindre » ou « le pont a eu un problème, donc toute la chaîne est forcément non sécurisée ».
En réalité, c’est beaucoup plus compliqué que des slogans. Le 16 janvier 2026, l’attaquant a obtenu les droits liés au portefeuille de signatures utilisé par le service de pont Dusk vers EVM.
Le bilan officiel est clair : ce n’est ni un échec de consensus, ni une compromission du protocole de base Dusk, mais bien une violation du chemin de signature du pont. L’ancienne conception empilait le portefeuille de signatures, le traitement des événements et la connexion réseau sur une seule voie d’exploitation. Dès qu’une clé était compromise, la portée que l’attaquant pouvait atteindre devenait beaucoup trop large.
Ce qui est intéressant, c’est que le point de réparation n’est pas juste « remplacer une clé ». La nouvelle conception sépare la réception des événements, la persistance des tâches, la libération des fonds et un signataire dédié. Elle gère les transactions avec une machine à états du type seen, submitted, completed, failed, stuck. Le portefeuille chaud ne conserve que le solde nécessaire à court terme ; s’il manque des fonds, on met en pause, puis le portefeuille froid est alimenté manuellement.
Je peux résumer simplement : on a remplacé un camion de transport d’argent chargé par des compartiments, des plafonds et une libération échelonnée, étape par étape.
Et AEGIS, c’est une autre histoire : en interne, l’audit a poussé 39 correctifs, dont 7 ont été classés comme « critiques », avec des causes racines impliquant l’isolation des VM, la désérialisation non sécurisée, lier les frais Phoenix et les remboursements, la contrefaçon BLS, etc. Les responsables indiquent qu’ils n’ont pas encore trouvé de preuves que ces problèmes critiques aient été exploités auparavant. L’incident du pont et AEGIS ne peuvent pas être fusionnés en une seule et même faille, et même si tout a été corrigé, on ne peut pas dire que le risque retombe à zéro.
Donc, mon avis actuel est le suivant : ce n’est pas une faille de consensus, et cela ne veut pas dire que ce n’est pas un problème de sécurité pour les utilisateurs. Le bilan public mérite d’être salué, mais il ne peut pas remplacer une stabilité à long terme ni une vérification par des tiers.
Quand vous évaluez une chaîne, est-ce que vous incluez le pont et l’exploitation opérationnelle dans le score de sécurité du protocole ?
#dusk $DUSK @Dusk
En réalité, c’est beaucoup plus compliqué que des slogans. Le 16 janvier 2026, l’attaquant a obtenu les droits liés au portefeuille de signatures utilisé par le service de pont Dusk vers EVM.
Le bilan officiel est clair : ce n’est ni un échec de consensus, ni une compromission du protocole de base Dusk, mais bien une violation du chemin de signature du pont. L’ancienne conception empilait le portefeuille de signatures, le traitement des événements et la connexion réseau sur une seule voie d’exploitation. Dès qu’une clé était compromise, la portée que l’attaquant pouvait atteindre devenait beaucoup trop large.
Ce qui est intéressant, c’est que le point de réparation n’est pas juste « remplacer une clé ». La nouvelle conception sépare la réception des événements, la persistance des tâches, la libération des fonds et un signataire dédié. Elle gère les transactions avec une machine à états du type seen, submitted, completed, failed, stuck. Le portefeuille chaud ne conserve que le solde nécessaire à court terme ; s’il manque des fonds, on met en pause, puis le portefeuille froid est alimenté manuellement.
Je peux résumer simplement : on a remplacé un camion de transport d’argent chargé par des compartiments, des plafonds et une libération échelonnée, étape par étape.
Et AEGIS, c’est une autre histoire : en interne, l’audit a poussé 39 correctifs, dont 7 ont été classés comme « critiques », avec des causes racines impliquant l’isolation des VM, la désérialisation non sécurisée, lier les frais Phoenix et les remboursements, la contrefaçon BLS, etc. Les responsables indiquent qu’ils n’ont pas encore trouvé de preuves que ces problèmes critiques aient été exploités auparavant. L’incident du pont et AEGIS ne peuvent pas être fusionnés en une seule et même faille, et même si tout a été corrigé, on ne peut pas dire que le risque retombe à zéro.
Donc, mon avis actuel est le suivant : ce n’est pas une faille de consensus, et cela ne veut pas dire que ce n’est pas un problème de sécurité pour les utilisateurs. Le bilan public mérite d’être salué, mais il ne peut pas remplacer une stabilité à long terme ni une vérification par des tiers.
Quand vous évaluez une chaîne, est-ce que vous incluez le pont et l’exploitation opérationnelle dans le score de sécurité du protocole ?
#dusk $DUSK @Dusk