Hier soir, en dépouillant en parallèle les logs d’erreurs des nœuds RPC, j’ai aussi ressorti les enregistrements on-chain de l’incident de sécurité du pont inter-chaînes survenu mi-janvier (@Dusk ) pour en faire la reconstitution. J’ai l’habitude, dans le trading de crypto et l’interaction, de suivre une règle : « sauver sa vie d’abord ». Dès qu’il y a le moindre bruit, ma réaction instinctive est de ne jamais me fier aux rumeurs : il faut impérativement aller fouiller le code et les flux on-chain pour trouver la vérité.
À l’époque, beaucoup étaient complètement paniqués, pensant que le protocole sous-jacent de Dusk s’était effondré. Mais j’ai vérifié la trace on-chain : il faut d’abord dire quelque chose d’objectif pour sa couche de consensus. Le consensus DuskDS sous-jacent n’a pas été percé, et le code du protocole central ne présentait pas de bug. Ce que les hackers ont vraiment malmené, c’est le portefeuille de signature du service de pont qui connecte la chaîne EVM. En clair : ce n’est pas le protocole qui a une fuite, c’est le « gardien » en charge de la clé privée—lequel s’est fait voler.
Lors de la reconstitution de la transaction de la nuit, les actions de l’attaquant ont commencé à 21:28. Plus de 2,7 millions, 1,9 million et 8 millions ($DUSK ) ont été vidés un à un, coup par coup, jusqu’à ce qu’à peu près deux heures plus tard l’équipe coupe d’urgence les accès. La dernière transaction, avec 8,91 millions d’unités, a finalement été bloquée de façon ferme. Entre-temps, une partie des fonds a été blanchie vers la BSC.
Cette affaire m’a profondément marqué. En temps normal, quand on écrit nos propres contrats Solidity ou quand on conçoit une architecture, on croit souvent aveuglément à la soi-disant « modularité et découplage » : séparer clairement consensus, règlement et exécution, avec l’impression que tout est extrêmement solide. Mais la réalité est cruelle : plus on découpe finement les composants d’un système, plus on multiplie les « jonctions » exposées à l’extérieur. Pour aller vite et intégrer le tout de façon légère, le projet a concentré les autorisations de signature sur un chemin unique, forcément fragile. Ainsi, les murs construits dans la chaîne via ZKP (preuves de connaissance zéro) et une finalité déterministe sont restés intacts, solides comme du roc—mais, à l’extérieur, le portefeuille de signature inter-chaînes n’a tenu qu’une seule attaque.
Donc, aujourd’hui, quand j’observe un projet, je ne me fie plus à l’idée que « le consensus est forcément ultra-robuste ». Dès que des actifs sortent de la couche de règlement native, ces ponts périphériques et portefeuilles de signature, à la première occasion, peuvent ramener la décentralisation dans un bourbier de confiance humaine fragile. Ce sont souvent ces faiblesses de sécurité aux frontières qui constituent le vrai danger le plus mortel.
Les gars, selon vous, pour ce pont inter-chaînes à risque de point unique d’une blockchain modulaire, existe-t-il une solution au niveau du code ?
#dusk $DUSK @Dusk
À l’époque, beaucoup étaient complètement paniqués, pensant que le protocole sous-jacent de Dusk s’était effondré. Mais j’ai vérifié la trace on-chain : il faut d’abord dire quelque chose d’objectif pour sa couche de consensus. Le consensus DuskDS sous-jacent n’a pas été percé, et le code du protocole central ne présentait pas de bug. Ce que les hackers ont vraiment malmené, c’est le portefeuille de signature du service de pont qui connecte la chaîne EVM. En clair : ce n’est pas le protocole qui a une fuite, c’est le « gardien » en charge de la clé privée—lequel s’est fait voler.
Lors de la reconstitution de la transaction de la nuit, les actions de l’attaquant ont commencé à 21:28. Plus de 2,7 millions, 1,9 million et 8 millions ($DUSK ) ont été vidés un à un, coup par coup, jusqu’à ce qu’à peu près deux heures plus tard l’équipe coupe d’urgence les accès. La dernière transaction, avec 8,91 millions d’unités, a finalement été bloquée de façon ferme. Entre-temps, une partie des fonds a été blanchie vers la BSC.
Cette affaire m’a profondément marqué. En temps normal, quand on écrit nos propres contrats Solidity ou quand on conçoit une architecture, on croit souvent aveuglément à la soi-disant « modularité et découplage » : séparer clairement consensus, règlement et exécution, avec l’impression que tout est extrêmement solide. Mais la réalité est cruelle : plus on découpe finement les composants d’un système, plus on multiplie les « jonctions » exposées à l’extérieur. Pour aller vite et intégrer le tout de façon légère, le projet a concentré les autorisations de signature sur un chemin unique, forcément fragile. Ainsi, les murs construits dans la chaîne via ZKP (preuves de connaissance zéro) et une finalité déterministe sont restés intacts, solides comme du roc—mais, à l’extérieur, le portefeuille de signature inter-chaînes n’a tenu qu’une seule attaque.
Donc, aujourd’hui, quand j’observe un projet, je ne me fie plus à l’idée que « le consensus est forcément ultra-robuste ». Dès que des actifs sortent de la couche de règlement native, ces ponts périphériques et portefeuilles de signature, à la première occasion, peuvent ramener la décentralisation dans un bourbier de confiance humaine fragile. Ce sont souvent ces faiblesses de sécurité aux frontières qui constituent le vrai danger le plus mortel.
Les gars, selon vous, pour ce pont inter-chaînes à risque de point unique d’une blockchain modulaire, existe-t-il une solution au niveau du code ?
#dusk $DUSK @Dusk