Un fait inconfortable est plus utile qu’un fait confortable ; voici donc un fait inconfortable à propos de Dusk Network : un audit interne achevé début 2026 a révélé 39 problèmes dans sa base de code de production, dont sept critiques, plus d’un an après que le mainnet avait déjà commencé à traiter de la valeur réelle.
Les quatre causes profondes derrière ces constats critiques méritent d’être nommées clairement plutôt que d’être édulcorées. Deux provenaient d’une propriété de mémoire non fiable dans Piecrust, le sandbox de la machine virtuelle, qui pouvait permettre à deux nœuds honnêtes d’exécuter un code identique et de calculer discrètement des résultats différents — une catégorie de défauts pire qu’un crash, parce qu’elle peut rester invisible. Une autre provenait d’un chemin de désérialisation côté hôte qui faisait confiance à des octets contrôlés par un contrat sans les valider au préalable, transformant un bug au niveau du contrat en problème d’intégrité du nœud. Une autre se trouvait dans la manière dont Phoenix, le modèle de transaction protégé, liait sa logique de frais et de remboursement, une faille qui, à elle seule, ouvrait des voies vers l’inflation de l’offre, l’arrêt de la chaîne et la redirection des remboursements, tout à la fois. La dernière était une faiblesse de construction cryptographique dans le schéma de signature BLS, au cœur même de l’authentification du consensus. Enquêter sur une exploitation antérieure impliquait de passer au crible les journaux et les preuves au niveau de l’hôte sur toute la pile, et pas seulement de rechercher un motif de bug isolé dans l’historique des transactions.
Dusk affirme que sa propre enquête n’a trouvé aucune preuve que l’un des sept problèmes ait été exploité avant le déploiement du correctif sous forme de hard fork en mars 2026, sa plus grande version depuis le lancement. Je n’ai aucun moyen de confirmer indépendamment cette affirmation, et personne qui lit ceci non plus, même si, avec NPEX seul prévoyant de déplacer plus de 300 millions d’euros vers cette base de code, les enjeux liés à une correction juste n’étaient jamais faibles. Ce que j’en retiens est plus nuancé qu’un simple réconfort : détecter cela avant une exploitation est réellement un bon travail, mais cela signifie aussi qu’un code aussi déterminant a fonctionné en production pendant plus d’un an en portant des failles que personne n’avait encore trouvées. Un audit propre est une étape importante. Ce n’est pas la même chose qu’une garantie continue.
@Dusk $DUSK #dusk
Les quatre causes profondes derrière ces constats critiques méritent d’être nommées clairement plutôt que d’être édulcorées. Deux provenaient d’une propriété de mémoire non fiable dans Piecrust, le sandbox de la machine virtuelle, qui pouvait permettre à deux nœuds honnêtes d’exécuter un code identique et de calculer discrètement des résultats différents — une catégorie de défauts pire qu’un crash, parce qu’elle peut rester invisible. Une autre provenait d’un chemin de désérialisation côté hôte qui faisait confiance à des octets contrôlés par un contrat sans les valider au préalable, transformant un bug au niveau du contrat en problème d’intégrité du nœud. Une autre se trouvait dans la manière dont Phoenix, le modèle de transaction protégé, liait sa logique de frais et de remboursement, une faille qui, à elle seule, ouvrait des voies vers l’inflation de l’offre, l’arrêt de la chaîne et la redirection des remboursements, tout à la fois. La dernière était une faiblesse de construction cryptographique dans le schéma de signature BLS, au cœur même de l’authentification du consensus. Enquêter sur une exploitation antérieure impliquait de passer au crible les journaux et les preuves au niveau de l’hôte sur toute la pile, et pas seulement de rechercher un motif de bug isolé dans l’historique des transactions.
Dusk affirme que sa propre enquête n’a trouvé aucune preuve que l’un des sept problèmes ait été exploité avant le déploiement du correctif sous forme de hard fork en mars 2026, sa plus grande version depuis le lancement. Je n’ai aucun moyen de confirmer indépendamment cette affirmation, et personne qui lit ceci non plus, même si, avec NPEX seul prévoyant de déplacer plus de 300 millions d’euros vers cette base de code, les enjeux liés à une correction juste n’étaient jamais faibles. Ce que j’en retiens est plus nuancé qu’un simple réconfort : détecter cela avant une exploitation est réellement un bon travail, mais cela signifie aussi qu’un code aussi déterminant a fonctionné en production pendant plus d’un an en portant des failles que personne n’avait encore trouvées. Un audit propre est une étape importante. Ce n’est pas la même chose qu’une garantie continue.
@Dusk $DUSK #dusk
