Je suis allé examiner le flux de migration du pont Dusk en m’attendant à la partie intéressante : le contrat EVM. En fait, c’était le signataire qui se trouvait derrière.
Le contrat de migration lui-même était assez simple. Les utilisateurs verrouillaient des ERC20 ou BEP20 DUSK et un événement de migration était émis. Mais cet événement ne créait pas magiquement du DUSK natif. Un service externe devait l’observer et réémettre les fonds sur Dusk.
Cette distinction compte plus qu’il n’y paraît au premier abord.
L’architecture plus large de Dusk évoluait vers un modèle de pont natif, où la valeur pouvait circuler entre DuskDS et DuskEVM sans actifs encapsulés ni custodians externes. Pourtant, l’ancienne voie de migration dépendait encore d’une enveloppe de signature opérationnelle pour transformer un événement EVM observé en une transaction Dusk réelle.
Les données de l’incident rendent cette dépendance visible. Le 16 janvier, un attaquant a compromis ce portefeuille, puis a transféré le DUSK volé via le chemin du pont. La séquence a inclus 7 880 DUSK pontés, puis encore 1,91 million de DUSK avant que la mitigation n’arrête une nouvelle tentative de 8,91 millions de DUSK.
Ce qui m’importe n’est pas seulement qu’un portefeuille ait été compromis.
C’est le fait que l’ingestion d’événements et la libération de valeur étaient effectivement reliées via un seul chemin opérationnel. Un smart contract peut être déterministe, tandis que le système qui l’entoure dépend encore de la garde des clés, de l’isolation des serveurs, de la supervision et de la gestion des transactions.
Le refonte qui sépare l’ingestion d’événements de la signature et le passage des événements de migration en jobs persistés est donc plus qu’un simple correctif de sécurité. Elle modifie l’endroit où réside la confiance.
En lisant cela, j’ai commencé à réfléchir différemment aux ponts. Le contrat est souvent la partie qu’on inspecte en premier, mais la véritable limite de confiance peut se trouver plusieurs couches derrière le contrat, dans le logiciel qui décide quand un événement devient de l’argent.
#dusk $DUSK @Dusk
Le contrat de migration lui-même était assez simple. Les utilisateurs verrouillaient des ERC20 ou BEP20 DUSK et un événement de migration était émis. Mais cet événement ne créait pas magiquement du DUSK natif. Un service externe devait l’observer et réémettre les fonds sur Dusk.
Cette distinction compte plus qu’il n’y paraît au premier abord.
L’architecture plus large de Dusk évoluait vers un modèle de pont natif, où la valeur pouvait circuler entre DuskDS et DuskEVM sans actifs encapsulés ni custodians externes. Pourtant, l’ancienne voie de migration dépendait encore d’une enveloppe de signature opérationnelle pour transformer un événement EVM observé en une transaction Dusk réelle.
Les données de l’incident rendent cette dépendance visible. Le 16 janvier, un attaquant a compromis ce portefeuille, puis a transféré le DUSK volé via le chemin du pont. La séquence a inclus 7 880 DUSK pontés, puis encore 1,91 million de DUSK avant que la mitigation n’arrête une nouvelle tentative de 8,91 millions de DUSK.
Ce qui m’importe n’est pas seulement qu’un portefeuille ait été compromis.
C’est le fait que l’ingestion d’événements et la libération de valeur étaient effectivement reliées via un seul chemin opérationnel. Un smart contract peut être déterministe, tandis que le système qui l’entoure dépend encore de la garde des clés, de l’isolation des serveurs, de la supervision et de la gestion des transactions.
Le refonte qui sépare l’ingestion d’événements de la signature et le passage des événements de migration en jobs persistés est donc plus qu’un simple correctif de sécurité. Elle modifie l’endroit où réside la confiance.
En lisant cela, j’ai commencé à réfléchir différemment aux ponts. Le contrat est souvent la partie qu’on inspecte en premier, mais la véritable limite de confiance peut se trouver plusieurs couches derrière le contrat, dans le logiciel qui décide quand un événement devient de l’argent.
#dusk $DUSK @Dusk