Version populaire : Une simple « traduction » pour interpréter l’analyse du @CetusProtocol hacker par le patron de la tech : Cette attaque met en évidence un problème classique de dépassement d’entier, qui se manifeste par une troncature des données lors de la conversion de type. Détails techniques démontés : 1) Emplacement de la vulnérabilité : le problème se produit dans le mécanisme de conversion de type de la fonction get_amount_by_liquidity, et la conversion de cast de U256 à U64 entraîne une perte de données de haut niveau. 2) Processus d’attaque : 1. L’attaquant transmet une grande quantité de paramètres de liquidité via la fonction add_liquidity ; 2. Le nombre de jetons B requis pour le calcul de l’appel système get_delta_b de la fonction ; 3. Dans le processus de calcul, les deux données de type U128 sont multipliées et le résultat théorique doit être de type U256 ; Défaut clé : Le résultat u256 est converti en u64 lorsque la fonction est renvoyée, ce qui entraîne la troncature des données de haut niveau 128 bits. 3) Effet d’utilisation : Le quota de liquidité qui nécessitait à l’origine un grand nombre de jetons pour être frappé peut désormais être complété avec seulement un très petit nombre de jetons. L’attaquant obtient une énorme part de liquidité à très faible coût, puis réalise l’arbitrage du pool en détruisant une partie de la liquidité. Analogie simple : tout comme l’utilisation d’une calculatrice qui ne peut afficher que 8 chiffres pour calculer 1 milliard × 1 milliard, le résultat d’un calcul à 20 chiffres ne peut afficher que les 8 derniers chiffres, et les 12 premiers chiffres disparaissent directement. L’attaquant exploite cette vulnérabilité. Pour être clair : cette vulnérabilité n’a rien à voir avec l’architecture de sécurité sous-jacente de @SuiNetwork, et la « gloire » de la sécurité du langage Move est encore crédible pour le moment. Pourquoi? Le langage Move présente des avantages significatifs en termes de gestion des ressources et de sécurité des types, et peut prévenir efficacement les problèmes de sécurité de bas niveau tels que les doubles dépenses et les fuites de ressources. Cependant, cette fois-ci, le protocole Cetus est une erreur mathématique au niveau de la logique de l’application, et non un défaut de conception dans le langage Move lui-même. Plus précisément, le système de type de Move, bien que rigoureux, repose toujours sur le bon jugement du développeur pour un casting explicite. Lorsqu’un programme effectue activement une conversion de type de U256 à U64, le compilateur ne peut pas dire s’il s’agit d’une erreur intentionnelle ou d’une erreur logique. De plus, cet incident de sécurité n’a rien à voir avec les fonctions sous-jacentes de Sui telles que le mécanisme de consensus, le traitement des transactions et la gestion de l’état. Sui Network n’exécute fidèlement que les instructions de transaction soumises par le protocole Cetus, et la vulnérabilité provient des défauts logiques du protocole de couche applicative lui-même. Pour le dire crûment, aucun langage de programmation avancé ne peut éliminer complètement les erreurs logiques au niveau de la couche application. Move peut prévenir la plupart des risques de sécurité sous-jacents, mais il ne peut pas remplacer les développeurs par la vérification des limites de la logique métier et la protection contre les débordements des opérations mathématiques.