J’ai regardé le code qui n’allait pas avec Cetus hier soir, et la première chose dont j’étais très méfiant get_delta_b était pourquoi cette fonction convertirait u256 en u64, ce qui a causé le problème d’interception de la précision. Après avoir demandé à l’IA, il est probable que lorsque cetus a migré toutes les formules uniswap v3, parce que uni utilise un point fixe, il doit être converti en un nombre à virgule flottante sans considération de sécurité minutieuse. Ce type de logique d’entreprise, qui appartient au niveau de l’algorithme, est difficile à détecter dans les audits de code, à moins que l’institution d’audit ne dispose également de chercheurs qui connaissent à la fois les algorithmes et le code. Voici la logique qui explique pourquoi l’IA analyse le code comme elle le fait : Sur la base de mon analyse de la base de code, je peux maintenant expliquer pourquoi l’auteur a choisi de l’implémenter de cette façon get_delta_b fonctions et causes possibles : Pourquoi l’auteur de la fonction implémente get_delta_b méthode Optimisation des performances : ) et bitmask gèrent directement les types U256. Cela est le plus susceptible d’améliorer les performances et de réduire la surcharge de calcul. Dans les applications DeFi, en particulier les scénarios de trading à haute fréquence, les performances sont essentielles. Le code commenté utilise u256 ::get ,u256 ::shrw Alors que l’implémentation actuelle utilise des opérations BIT (>> 64 Économisez sur les frais de gaz : les opérations sur la blockchain Sui doivent payer des frais de gaz, et les opérations plus complexes consommeront plus de gaz. La simplification des calculs peut réduire les coûts de transaction, en particulier pour les fonctions de base de l’AMM fréquemment utilisées. Réduction des dépendances : les fonctions du module, et l’implémentation actuelle réduit les appels à ces fonctions, peut-être pour réduire les dépendances vis-à-vis des bibliothèques externes, ou pour éviter des problèmes avec certaines fonctions externes. Le code dans les commentaires utilise plus de u256 Portage de Solidity to Move : En termes de style de code, il pourrait s’agir d’un portage du code Solidity d’Ethereum vers le langage Move de Sui. Cette utilisation de la manipulation et du masquage des bits est courante dans Solidity, en particulier dans les implémentations AMM telles que Uniswap V3. Gérer les mathématiques en virgule fixe : Le résultat de 256 bits qui en résulte doit être traité correctement, et le décalage de 64 bits vers la droite est un moyen courant d’obtenir la position correcte de la virgule. Les mathématiques en virgule fixe sont souvent utilisées dans les AMM pour traiter les valeurs décimales. full_math_u128 ::full_mul Problèmes potentiels Cependant, cette mise en œuvre introduit plusieurs problèmes : Mauvaise lisibilité du code : l’utilisation de masques codés en dur et d’opérations de déplacement rend le code difficile à comprendre et à auditer. Absence de vérification des limites complètes : les opérations de bits et les opérations de conversion de type ne disposent pas d’une vérification complète des limites, ce qui peut entraîner un comportement inattendu dans des cas extrêmes. Le code commenté coexiste avec le code d’implémentation : la conservation d’anciennes versions du code commenté indique que le code peut être dans un état transitoire ou ne pas avoir été testé de manière adéquate, ce qui est dangereux pour le code critique traitant des actifs financiers. Risque de dépassement d’entier : lorsqu’il s’agit de valeurs importantes, les opérations et les transformations de bits peuvent entraîner un dépassement d’entier, et les implémentations simplifiées peuvent ne pas disposer de mécanismes de protection adéquats. résumé Il est probable que la principale raison de l’auteur pour mettre en œuvre ce code soit d’optimiser les performances et de réduire les coûts de gaz, tout en gérant des calculs mathématiques en virgule fixe dans les AMM. Cependant, cette optimisation, au détriment de la sécurité et de la lisibilité du code, peut fournir aux attaquants des vulnérabilités exploitables, comme vous pouvez le voir avec l’incident de vol de Cetus que vous avez signalé. Dans les projets DeFi, la sécurité doit toujours primer sur l’optimisation des performances, en particulier pour les fonctions de base qui gèrent les actifs des utilisateurs. Il est préférable d’utiliser des fonctions de bibliothèque éprouvées, d’ajouter des vérifications complètes des limites et d’effectuer des audits de sécurité adéquats.