J’ai suivi la migration via le @Dusk Bridge, parce que je pensais au départ que la partie la plus intéressante était le contrat EVM. Mais plus j’y regardais de près, plus je me rendais compte que le vrai problème vient du signataire qui se cache derrière.
Le contrat de migration lui-même est assez simple. Les utilisateurs bloquent des DUSK ERC20 ou BEP20, et le contrat émet un événement de migration. Mais cet événement ne devient pas automatiquement du DUSK natif. Un service externe doit le surveiller et réémettre le montant correspondant sur le #dusk .
C’est cette partie que je trouve plus intéressante que le flux de migration lui-même.
Dusk évolue vers un pont natif, permettant aux actifs de circuler entre DuskDS et DuskEVM sans actifs enveloppés ni garde externe. Mais l’ancienne voie de migration dépend encore d’un portefeuille de signature opérationnel : un événement EVM est observé, puis ce portefeuille signe une transaction sur Dusk.
J’ai vu cette dépendance le plus clairement dans les données de l’incident. Le 16 janvier, le portefeuille opérationnel a été compromis, et le chemin du pont a été utilisé pour déplacer du DUSK volé. 7,880 DUSK ont transité par le pont, suivis par encore 1,91 million de DUSK, avant que la mitigation n’empêche une tentative supplémentaire impliquant 8,91 million de DUSK.
Pour moi, le problème n’est pas simplement qu’un portefeuille a été compromis. Ce que je trouve plus intéressant à considérer, c’est que l’ingestion d’événements et la libération de valeur, qui semblent être deux processus distincts, étaient reliées par le même chemin opérationnel.
Cela me pousse à considérer les smart contracts différemment. Un contrat peut être déterministe, mais le système qui l’entoure dépend encore de la garde des clés, de l’isolation des serveurs, de la surveillance et de la gestion des transactions.
C’est pourquoi séparer l’ingestion d’événements de la signature et transformer les événements de migration en jobs persistés n’est pas qu un simple correctif. Cela déplace aussi l’endroit où la confiance est placée dans le système.
À partir de là, j’ai commencé à regarder les ponts sous un angle différent. Les contrats sont généralement là où l’on audite d’abord, mais la frontière de confiance peut être beaucoup plus profonde—dans le logiciel qui décide quand un événement devient de l’argent. $DUSK $TUT $P
Le contrat de migration lui-même est assez simple. Les utilisateurs bloquent des DUSK ERC20 ou BEP20, et le contrat émet un événement de migration. Mais cet événement ne devient pas automatiquement du DUSK natif. Un service externe doit le surveiller et réémettre le montant correspondant sur le #dusk .
C’est cette partie que je trouve plus intéressante que le flux de migration lui-même.
Dusk évolue vers un pont natif, permettant aux actifs de circuler entre DuskDS et DuskEVM sans actifs enveloppés ni garde externe. Mais l’ancienne voie de migration dépend encore d’un portefeuille de signature opérationnel : un événement EVM est observé, puis ce portefeuille signe une transaction sur Dusk.
J’ai vu cette dépendance le plus clairement dans les données de l’incident. Le 16 janvier, le portefeuille opérationnel a été compromis, et le chemin du pont a été utilisé pour déplacer du DUSK volé. 7,880 DUSK ont transité par le pont, suivis par encore 1,91 million de DUSK, avant que la mitigation n’empêche une tentative supplémentaire impliquant 8,91 million de DUSK.
Pour moi, le problème n’est pas simplement qu’un portefeuille a été compromis. Ce que je trouve plus intéressant à considérer, c’est que l’ingestion d’événements et la libération de valeur, qui semblent être deux processus distincts, étaient reliées par le même chemin opérationnel.
Cela me pousse à considérer les smart contracts différemment. Un contrat peut être déterministe, mais le système qui l’entoure dépend encore de la garde des clés, de l’isolation des serveurs, de la surveillance et de la gestion des transactions.
C’est pourquoi séparer l’ingestion d’événements de la signature et transformer les événements de migration en jobs persistés n’est pas qu un simple correctif. Cela déplace aussi l’endroit où la confiance est placée dans le système.
À partir de là, j’ai commencé à regarder les ponts sous un angle différent. Les contrats sont généralement là où l’on audite d’abord, mais la frontière de confiance peut être beaucoup plus profonde—dans le logiciel qui décide quand un événement devient de l’argent. $DUSK $TUT $P
⚡ Hidden Latency
100%
🔄 State Reuse
0%
🛡️ Security First
0%
📈 Demand Pressure
0%
1 Votes • Vote fermé