Croyance ferme après une crise de sécurité : pourquoi SUI possède-t-il encore un potentiel de hausse à long terme ?

1. Une réaction en chaîne déclenchée par une attaque

Le 22 mai 2025, le protocole AMM de premier plan déployé sur le réseau SUI, Cetus, a été victime d'une attaque de hacker. L'attaquant a exploité une vulnérabilité logique liée à un "problème de débordement d'entier" pour effectuer une manipulation précise, entraînant une perte de plus de 200 millions de dollars d'actifs. Cet incident est non seulement l'un des accidents de sécurité les plus importants dans le domaine DeFi cette année, mais il est également devenu la cyberattaque la plus destructrice depuis le lancement du réseau principal SUI.

Selon les données de DefiLlama, le TVL total de la chaîne SUI a chuté de plus de 330 millions de dollars le jour de l'attaque, et le montant verrouillé du protocole Cetus a même été évaporé de 84% en un instant, tombant à 38 millions de dollars. En conséquence, plusieurs tokens populaires sur SUI (y compris Lofi, Sudeng, Squirtle, etc.) ont chuté de 76% à 97% en seulement une heure, suscitant une large préoccupation du marché concernant la sécurité de SUI et la stabilité de son écosystème.

Mais après cette onde de choc, l'écosystème SUI a montré une grande résilience et capacité de récupération. Bien que l'incident Cetus ait provoqué des fluctuations de confiance à court terme, les fonds en chaîne et l'activité des utilisateurs n'ont pas subi de déclin durable, mais ont plutôt incité l'ensemble de l'écosystème à accorder une attention significative à la sécurité, à la construction d'infrastructures et à la qualité des projets.

Klein Labs va examiner la cause de cet incident d'attaque, le mécanisme de consensus des nœuds de SUI, la sécurité du langage MOVE et le développement de l'écosystème de SUI, en analysant le paysage actuel de cet écosystème de blockchain qui est encore à un stade précoce de développement, et en explorant son potentiel de développement futur.

2. Analyse des causes de l'attaque Cetus

2.1 Processus de mise en œuvre de l'attaque

Selon l'analyse technique de l'incident d'attaque de Cetus par l'équipe Slow Mist, les hackers ont réussi à exploiter une vulnérabilité clé de débordement arithmétique dans le protocole, en utilisant des prêts éclair, une manipulation précise des prix et des défauts de contrat, pour voler plus de 200 millions de dollars d'actifs numériques en peu de temps. Le chemin de l'attaque peut être divisé en trois étapes principales :

①Lancer un prêt éclair, manipuler les prix

Les hackers ont d'abord utilisé un échange instantané de 10 milliards de haSUI avec un slippage maximal, empruntant d'énormes sommes d'argent pour manipuler les prix.

Le prêt flash permet aux utilisateurs d'emprunter et de rembourser des fonds dans une même transaction, ne nécessitant que le paiement de frais, avec des caractéristiques de haute levée, de faible risque et de faible coût. Les hackers ont exploité ce mécanisme pour faire chuter rapidement le prix du marché et le contrôler avec précision dans une plage très étroite.

Ensuite, l'attaquant prépare à créer une position de liquidité très étroite, en définissant précisément la plage de prix entre l'offre la plus basse de 300,000 et le prix le plus élevé de 300,200, dont la largeur de prix n'est que de 1.00496621 %.

Grâce à cette méthode, les hackers ont réussi à manipuler le prix de haSUI en utilisant un nombre suffisant de jetons et une énorme liquidité. Ensuite, ils ont également manipulé plusieurs jetons sans valeur réelle.

②Ajouter de la liquidité

L'attaquant crée des positions de liquidité étroites, déclare avoir ajouté de la liquidité, mais en raison d'une vulnérabilité dans la fonction checked_shlw, ne reçoit finalement qu'un seul jeton.

C'est essentiellement dû à deux raisons :

1. Paramètre de masque trop large : équivaut à une limite d'ajout de liquidité extrêmement élevée, rendant les vérifications des entrées des utilisateurs dans le contrat inefficaces. Les hackers contournent la détection de débordement en définissant des paramètres anormaux, construisant des entrées toujours inférieures à cette limite.

2. Débordement de données tronqué : lors de l'exécution de l'opération de décalage n << 64 sur la valeur n, un débordement s'est produit en raison du décalage dépassant la largeur de bit effective du type de données uint256 (256 bits). La partie de débordement haute a été automatiquement abandonnée, ce qui a conduit à un résultat de calcul bien inférieur aux attentes, amenant ainsi le système à sous-estimer le nombre de haSUI nécessaires pour l'échange. Le résultat final du calcul est d'environ moins de 1, mais comme il s'agit d'un arrondi vers le haut, le résultat final est donc égal à 1, ce qui signifie que le hacker n'a besoin d'ajouter qu'un seul jeton pour obtenir une énorme liquidité.

③ Retrait de liquidités

Effectuer le remboursement d'un prêt éclair, en conservant d'énormes bénéfices. Retirer finalement des pools de liquidité un total de plusieurs centaines de millions de dollars d'actifs en tokens.

La situation de perte de fonds est grave, l'attaque a entraîné le vol des actifs suivants :

• 12,9 millions de SUI (environ 5,4 millions de dollars)

• 60 millions de dollars USDC

• 490万美元Haedal Staked SUI

• 19,5 millions de dollars TOILET

• D'autres jetons comme HIPPO et LOFI ont chuté de 75 à 80 %, la liquidité s'est tarie.

2.2 Causes et caractéristiques de la vulnérabilité

Cette vulnérabilité de Cetus présente trois caractéristiques :

1. Coût de réparation extrêmement bas : d'une part, la cause fondamentale de l'incident Cetus est une erreur dans la bibliothèque mathématique de Cetus, et non une erreur dans le mécanisme de prix du protocole ou une erreur dans l'architecture sous-jacente. D'autre part, la vulnérabilité est limitée à Cetus lui-même et n'a rien à voir avec le code de SUI. La racine de la vulnérabilité réside dans une condition de frontière, il suffit de modifier deux lignes de code pour éliminer complètement le risque ; une fois la réparation effectuée, elle peut être immédiatement déployée sur le réseau principal, garantissant que la logique des contrats ultérieurs est complète et empêchant cette vulnérabilité.

2. Haute discrétion : Le contrat fonctionne de manière stable sans aucun incident depuis deux ans. Le protocole Cetus a subi plusieurs audits, mais aucune vulnérabilité n'a été trouvée, principalement parce que la bibliothèque Integer_Mate utilisée pour les calculs mathématiques n'a pas été incluse dans le champ d'audit.

Les hackers utilisent des valeurs extrêmes pour construire avec précision des intervalles de transaction, créant des scénarios extrêmement rares de soumission d'une liquidité très élevée, ce qui déclenche une logique anormale, indiquant que ce type de problème est difficile à détecter par des tests ordinaires. Ces problèmes se situent souvent dans des zones d'ombre de la perception humaine, c'est pourquoi ils restent latents pendant longtemps avant d'être découverts.

3. Ce n'est pas un problème uniquement lié à Move :

Move est supérieur à de nombreux langages de contrats intelligents en matière de sécurité des ressources et de vérification des types, avec une détection native des problèmes de dépassement d'entier dans des situations courantes. Ce dépassement est dû à l'utilisation d'une valeur incorrecte pour la vérification des limites lors du calcul du nombre de jetons nécessaires lors de l'ajout de liquidités, et à l'utilisation d'opérations de décalage à la place de l'opération de multiplication conventionnelle. En revanche, si des opérations d'addition, de soustraction, de multiplication ou de division conventionnelles sont utilisées dans Move, un contrôle automatique des dépassements sera effectué, évitant ainsi ce problème de troncature des bits supérieurs.

Des vulnérabilités similaires sont également apparues dans d'autres langages (comme Solidity et Rust), et sont même plus facilement exploitées en raison de leur manque de protection contre les débordements d'entiers ; avant la mise à jour de la version de Solidity, la vérification des débordements était très faible. Historiquement, il y a eu des débordements d'addition, de soustraction, de multiplication, etc., dont la cause directe était le dépassement de la plage des résultats de calcul. Par exemple, les vulnérabilités des contrats intelligents BEC et SMT sur le langage Solidity ont contourné les instructions de vérification dans le contrat à l'aide de paramètres soigneusement construits, permettant ainsi des transferts excessifs pour réaliser des attaques.

3. Mécanisme de consensus de SUI

3.1 Introduction au mécanisme de consensus SUI

Aperçu :

SUI adopte un cadre de preuve d'enjeu déléguée (DeleGated Proof of Stake, abrégé DPoS)). Bien que le mécanisme DPoS puisse augmenter le débit des transactions, il ne peut pas fournir un niveau de décentralisation aussi élevé que le PoW (preuve de travail). Par conséquent, le niveau de décentralisation de SUI est relativement bas, le seuil de gouvernance est relativement élevé, et les utilisateurs ordinaires ont du mal à influencer directement la gouvernance du réseau.

• Nombre moyen de validateurs : 106

• Durée moyenne de l'Epoch : 24 heures

Mécanisme de processus :

• Délégation des droits : les utilisateurs ordinaires n'ont pas besoin de faire fonctionner un nœud par eux-mêmes, il leur suffit de staker SUI et de le déléguer à des validateurs candidats pour participer à la garantie de la sécurité du réseau et à la distribution des récompenses. Ce mécanisme peut abaisser le seuil de participation pour les utilisateurs ordinaires, leur permettant de participer au consensus du réseau en "employant" des validateurs de confiance. C'est également un grand avantage du DPoS par rapport au PoS traditionnel.

• Représentation des tours de production de blocs : un petit nombre de validateurs sélectionnés produisent des blocs selon un ordre fixe ou aléatoire, ce qui augmente la vitesse de confirmation et améliore le TPS.

• Élection dynamique : après chaque cycle de dépouillement, en fonction du poids des votes, effectuer une rotation dynamique pour réélire l'ensemble des Validateurs, garantissant la vitalité des nœuds, la cohérence des intérêts et la décentralisation.

Avantages de DPoS :

• Haute efficacité : Grâce à un nombre contrôlé de nœuds de création de blocs, le réseau peut réaliser des confirmations en millisecondes, répondant ainsi aux besoins élevés de TPS.

• Coût faible : Moins de nœuds participant au consensus, la bande passante réseau et les ressources de calcul nécessaires pour la synchronisation des informations et l'agrégation des signatures sont considérablement réduites. Cela entraîne une diminution des coûts matériels et d'exploitation, une baisse des exigences en matière de puissance de calcul, et des coûts plus bas. Cela permet finalement d'atteindre des frais d'utilisateur plus bas.

• Haute sécurité : les mécanismes de staking et de délégation amplifient les coûts et les risques d'attaque ; associés au mécanisme de confiscation en chaîne, ils répriment efficacement les comportements malveillants.

En même temps, le mécanisme de consensus de SUI utilise un algorithme basé sur le BFT (tolérance aux pannes byzantines), exigeant qu'une majorité de plus des deux tiers des votes des validateurs soit atteinte pour confirmer une transaction. Ce mécanisme garantit que même si un petit nombre de nœuds agissent de manière malveillante, le réseau peut rester sécurisé et fonctionner efficacement. Pour effectuer toute mise à niveau ou décision majeure, il est également nécessaire d'obtenir plus des deux tiers des votes pour pouvoir mettre en œuvre.

En essence, le DPoS est en réalité une solution de compromis au triangle impossible, un compromis entre décentralisation et efficacité. Dans le "triangle impossible" de sécurité-décentralisation-scalabilité, le DPoS choisit de réduire le nombre de nœuds de production actifs pour obtenir de meilleures performances, renonçant à un certain degré de décentralisation complète par rapport au pur PoS ou PoW, mais améliorant considérablement le débit du réseau et la vitesse des transactions.

3.2 La performance de SUI lors de cette attaque

3.2.1 Mécanisme de gel en fonctionnement

Lors de cet événement, SUI a rapidement gelé les adresses liées à l'attaquant.

D'un point de vue technique, cela empêche les transactions de transfert d'être empaquetées sur la chaîne. Les nœuds de validation sont des composants clés de la blockchain SUI, responsables de la validation des transactions et de l'exécution des règles du protocole. En ignorant collectivement les transactions liées aux attaquants, ces validateurs mettent en œuvre un mécanisme similaire à celui de la 'gel des comptes' dans la finance traditionnelle au niveau du consensus.

SUI lui-même dispose d'un mécanisme de liste de refus (deny list), qui est une fonction de liste noire, permettant de bloquer toute transaction impliquant des adresses répertoriées. Étant donné que cette fonction existe dans le client, lorsque l'attaque se produit,

SUI peut immédiatement geler l'adresse des hackers. Sans cette fonctionnalité, même si SUI n'a que 113 validateurs, il est difficile pour Cetus de coordonner tous les validateurs un par un dans un court laps de temps.

3.2.2 Qui a le pouvoir de modifier la liste noire ?

TransactionDenyConfig est un fichier de configuration YAML/TOML chargé localement par chaque validateur. Toute personne exécutant un nœud peut modifier ce fichier, le recharger à chaud ou redémarrer le nœud, et mettre à jour la liste. En surface, chaque validateur semble exprimer librement ses valeurs.

En réalité, pour garantir la cohérence et l'efficacité des politiques de sécurité, la mise à jour de cette configuration clé est généralement coordonnée. Comme il s'agit d'une "mise à jour urgente poussée par l'équipe SUI", c'est essentiellement la fondation SUI (ou les développeurs autorisés par celle-ci) qui établit et met à jour cette liste de refus.

SUI a publié une liste noire, en théorie, les validateurs peuvent choisir s'ils souhaitent l'adopter ------ mais en pratique, la plupart des gens l'adoptent automatiquement par défaut. Par conséquent, bien que cette fonctionnalité protège les fonds des utilisateurs, elle présente en effet un certain degré de centralisation.

3.2.3 La nature de la fonctionnalité de liste noire

La fonction de liste noire n'est en réalité pas une logique de base du protocole, elle ressemble plutôt à une couche de sécurité supplémentaire pour faire face à des situations d'urgence et garantir la sécurité des fonds des utilisateurs.

C'est essentiellement un mécanisme de garantie de sécurité. Semblable à une "chaîne de sécurité" attachée à la porte, elle s'active uniquement pour ceux qui souhaitent pénétrer dans la maison, c'est-à-dire pour ceux qui veulent nuire au protocole. Pour l'utilisateur :

• Pour les gros investisseurs, principaux fournisseurs de liquidité, le protocole veut avant tout garantir la sécurité des fonds, car en réalité, les données on-chain TVL sont entièrement fournies par les principaux gros investisseurs. Pour assurer le développement durable du protocole, il est impératif de donner la priorité à la sécurité.

• Pour les investisseurs individuels, contributeurs à l'activité de l'écosystème, et soutiens forts de la co-construction technique et communautaire.