Réveil avec le piratage de rsETH, j'ai commencé à faire des recherches.

Beaucoup de personnes accusent Kelp de négligence.
Puis je suis tombé sur la recherche récemment publiée de @stacy_muur concernant l'exploit, et jusqu'à présent c'est la pièce la plus détaillée sur CT.
Résumé de ce qui s'est réellement passé ↓
Environ 116 500 rsETH ( ~ 292 millions de dollars ) ont été drainés du pont.
Mais ce n'était PAS :
– un exploit de mint
– pas un bug de contrat intelligent
– pas une réentrance
C'est important.
Ce qui s'est passé, c'est un faux message cross-chain que Ethereum a accepté comme réel.
Pensez-y comme ceci :
Ethereum a reçu un message disant
« hé, libère les fonds – ils ont été brûlés sur l'autre chaîne »
Sauf… ils n'ont jamais été brûlés.
Le message semblait 100 % légitime structurellement, donc le système l'a exécuté.
Important :
– la garantie rsETH sur le réseau principal est intacte
– les détenteurs existants de rsETH ne subissent pas de coupe directe pour l'instant
Et voici la situation réaliste des zones de responsabilité :
@KelpDAO :
▪ Configuration DVN 1:1. C'est la configuration minimale de LayerZero.
▪ Cette configuration était en place depuis au moins 90 jours – pas une erreur précipitée
▪ 11 des 12 routes entrantes de Kelp étaient en configuration 1-à-1 – c'était leur modèle standard
▪ Kelp a réagi et a gelé les contrats, bloquant d'autres attaques
@LayerZero_Core :
▪ La seule DVN requise est celle étiquetée "LayerZero: DVN" sur Etherscan
▪ Un paquet a été vérifié et engagé par cette DVN sans un véritable événement source
▪ La même DVN fonctionne normalement sur des centaines d'autres routes
En gros, la DVN de LayerZero est le composant qui a vérifié un message. Que cela soit dû à une clé compromise, un bug logiciel, ou une mauvaise entrée en amont reste la question centrale sans réponse.