Je suis entré dans le contrat de migration Dusk en m’attendant à une faille Solidity. Au lieu de ça, j’ai trouvé quelque chose de plus intéressant.

Le contrat lui-même est simple : les utilisateurs bloquent des DUSK ERC-20 et un événement « Locked » est émis.

La vraie puissance se situe hors chaîne.

Un écouteur backend observe cet événement et déclenche un portefeuille de signature pour émettre des DUSK natifs. Cela signifie que le contrat ne termine pas réellement la migration—c’est le processus backend et sa clé qui le font.

L’incident du 16 janvier a mis ce risque en évidence. Un attaquant a d’abord testé le système avec 7 880 DUSK, puis déplacé 1,91 M DUSK. Un troisième transfert de 8,91 M a été stoppé seulement après l’arrêt du service de signature.

Le contrat n’a pas été cassé. Ce sont les opérations qui l’ont été.

La refonte—séparer l’écouteur, le signataire, la base de données et la file de jobs—est une amélioration significative, mais elle n’élimine pas la confiance. Elle transfère la confiance dans l’infrastructure autour du contrat.

Ça a changé ma façon de penser les ponts :

Un pont n’est pas seulement des contrats intelligents. C’est l’ensemble du processus qui transforme un événement on-chain en une autorisation off-chain.

Parfois, la faille la plus effrayante n’est pas dans Solidity.

C’est le script qui tourne en silence en arrière-plan avec une clé privée.

@Dusk_Foundation #dusk $DUSK