Concernant l'incident avec @ResupplyFi, beaucoup d'entre vous ont des associations et des émotions à ce sujet. Je voudrais dire quelques points ici, en espérant aider à clarifier certains contextes : Tout d'abord, l'équipe de @CurveFinance n'a pas participé au développement de Resupply, ce point a été clarifié publiquement par @newmichwill, personne au sein de Curve n'a rejoint ce projet. De plus, Resupply est en réalité un SubDAO de @yearnfi, ce qui est également précisé sur leur compte Twitter officiel. Resupply a choisi crvUSD comme l'un de ses actifs sous-jacents, c'est un choix du protocole et ne signifie pas que Curve a un lien substantiel. Cela dit, c'est tout de même un événement regrettable. Le développeur de Resupply, @C2tP, a finalement déboursé plus de 1,39 million de dollars pour rembourser les créances douteuses, cette attitude responsable mérite d'être respectée. D'autre part, je tiens également à remercier particulièrement le patron @ohyishi et le rôle de supervision qu'il représente. Ses diverses observations, critiques et préoccupations concernant Prisma, Resupply, et même Curve sur Twitter sont en réalité très importantes. Dans le monde de la finance décentralisée (DeFi), sans ces personnes qui continuent à poser des questions, nous ne verrions pas les risques et nous ne pourrions pas progresser. Qu'elles soient positives ou négatives, ces voix permettent aux protocoles de prendre conscience des préoccupations des utilisateurs et apprennent aux équipes de projet à s'exprimer, à gouverner et à répondre à la communauté de manière plus claire. Le rôle que représente Yishi est en soi une contribution. Ce n'est pas seulement une question de technique, mais un rappel mutuel sur les valeurs. Depuis l'été DeFi jusqu'à aujourd'hui, nous avons été témoins de nombreuses innovations et avons également subi de nombreux revers. La naissance d'Uniswap, Aave et Curve est le résultat d'une série d'expérimentations où l'on n'a pas eu peur de l'échec. Cependant, ces dernières années, de plus en plus de protocoles choisissent la prudence et évitent l'innovation, car un nouveau contrat peut signifier des risques de centaines de milliers de dollars. Cette stagnation représente en réalité un risque encore plus grand. Nous ne devrions pas seulement commémorer le passé de l'été DeFi, mais nous devons nous demander : pouvons-nous encore créer une fois de plus ? Pouvons-nous encore permettre l'échec, protéger l'innovation et apprendre collectivement ? - - - - - - Liens connexes - - - - - - 👉🏻 👉🏻 - - - - - - Liens connexes - - - - - - Enfin, je tiens à préciser que je n'ai aucun lien avec l'équipe de Resupply et que je n'ai pas participé à ses activités de minage. Cet article n'est que le reflet de mes observations et de mes réflexions en tant qu'observateur, participant et constructeur de DeFi.
En voyant le patron de onekey défendre ses droits, avec des pertes de plusieurs millions d'actifs, je me suis rendu compte que le Defi est vraiment trop fragile. Après avoir fait le tour, il semble que personne n'explique clairement comment le hacker a attaqué, alors j'ai fait un peu de recherche et je partage avec vous : Le protagoniste de l'histoire est ResupplyPair, où les utilisateurs peuvent emprunter en mettant en gage des actifs. Le modificateur isSolvent dans le contrat est responsable de vérifier si l'utilisateur est éligible pour emprunter les actifs demandés, la logique de code spécifique est : On peut voir à la ligne 282 le calcul de l'ltv, si nous avons un moyen de mettre _exchangeRate à 0, alors la vérification serait toujours vraie ? Continuons à lire le code : On peut voir que cette valeur provient de l'appel à l'oracle getPrices, et c'est le dénominateur, en d'autres termes, nous devons faire en sorte que le prix du collateral soit extrêmement élevé. En lisant le code de l'oracle, on peut savoir que getPrices n'est qu'un relais, en réalité, il appelle l'interface convertToAssets de cet actif mis en gage (c'est-à-dire le coffre). Continuons à lire le code : On peut voir que ce résultat est composé de calculs mathématiques très complexes, ici le hacker a amplifié le numérateur, et plus loin le total_assets, pour réaliser l'attaque. En vérifiant l'implémentation de la fonction _total_assets, on peut découvrir : Cette valeur est liée au borrowed_token détenu par le contrat controller de ce coffre, c'est-à-dire crvUSD. À ce stade de l'analyse, c'est en fait clair, ResupplyPair a été créé en utilisant un coffre vide, le hacker a transféré une certaine quantité de borrowed_token au contrat controller du coffre, ce qui a finalement fait que _exchangeRate est tombé à zéro, permettant ainsi à ses actifs mis en gage de voir leur valeur multipliée à l'infini, empruntant jusqu'à 10 millions de reUSD à un coût très faible. Transaction d'attaque : Adresse du contrat ResupplyPair : Adresse du contrat controller du coffre : Adresse du contrat du coffre : Adresse du contrat oracle :
Afficher l’original
Le contenu de cette page est fourni par des tiers. Sauf indication contraire, OKX n’est pas l’auteur du ou des articles cités et ne revendique aucun droit d’auteur sur le contenu. Le contenu est fourni à titre d’information uniquement et ne représente pas les opinions d’OKX. Il ne s’agit pas d’une approbation de quelque nature que ce soit et ne doit pas être considéré comme un conseil en investissement ou une sollicitation d’achat ou de vente d’actifs numériques. Dans la mesure où l’IA générative est utilisée pour fournir des résumés ou d’autres informations, ce contenu généré par IA peut être inexact ou incohérent. Veuillez lire l’article associé pour obtenir davantage de détails et d’informations. OKX n’est pas responsable du contenu hébergé sur des sites tiers. La détention d’actifs numériques, y compris les stablecoins et les NFT, implique un niveau de risque élevé et leur valeur peut considérablement fluctuer. Examinez soigneusement votre situation financière pour déterminer si le trading ou la détention d’actifs numériques vous convient.