Une foi inébranle après une crise de sécurité : pourquoi SUI conserve un potentiel de croissance à long terme ?
TechFlow SélectionTechFlow Sélection
Une foi inébranle après une crise de sécurité : pourquoi SUI conserve un potentiel de croissance à long terme ?
Que ce soit dans les infrastructures, la DeFi, le jeu ou encore les domaines DePIN et IA, SUI a fait preuve d'une compétitivité et d'une innovation remarquables.
Dédié à des analyses Web3 approfondiesRédaction : Klein Labs, Aquarius Capital
TL ; DR
1. La vulnérabilité de Cetus provient de l'implémentation du contrat, et non de SUI ou du langage Move :
L’attaque découle principalement de l’absence de vérification des limites arithmétiques dans le protocole Cetus — une faille logique causée par un masque trop large et un décalage entraînant un dépassement. Elle n’a aucun lien avec le modèle de sécurité des ressources de la blockchain SUI ou du langage Move. Un simple « contrôle de borne » suffirait à corriger ce problème, sans compromettre la sécurité fondamentale de l’écosystème.
2. Le « centralisme raisonnable » intégré au mécanisme SUI s’est révélé précieux en période de crise :
Bien que SUI adopte un système DPoS (Preuve d’enjeu déléguée) avec rotation des validateurs et fonctionnalité de liste noire pouvant sembler légèrement centralisé, cette caractéristique a joué un rôle clé lors de l’incident Cetus : les validateurs ont rapidement synchronisé l’adresse malveillante sur la Deny List, refusant ainsi de valider toute transaction associée, permettant le gel immédiat de plus de 160 millions de dollars. Il s’agit en réalité d’un « keynésianisme on-chain » positif, où une régulation macroéconomique efficace apporte une contribution bénéfique au système économique.
3. Réflexions et recommandations en matière de sécurité technique :
Calculs mathématiques et vérifications de bornes : introduire des assertions de limite supérieure et inférieure pour toutes les opérations arithmétiques critiques (décalages, multiplications, divisions), accompagnées de tests par fuzzing sur valeurs extrêmes et de vérifications formelles. De plus, renforcer l’audit et la surveillance : au-delà des audits classiques, ajouter des équipes spécialisées en audit mathématique et mettre en place une détection en temps réel des comportements anormaux des transactions on-chain, afin d’identifier précocement des anomalies comme des fractionnements inhabituels ou des flash loans massifs.
4. Bilan et recommandations concernant les mécanismes de protection financière :
Dans l’affaire Cetus, SUI et l’équipe du projet ont collaboré efficacement, réussissant à geler plus de 160 millions de dollars et proposant un plan de compensation à 100 %, démontrant ainsi une forte capacité de réponse on-chain et un sens élevé de responsabilité écologique. La fondation SUI a également ajouté 10 millions de dollars dédiés aux audits pour renforcer la sécurité. À l’avenir, il serait pertinent de développer davantage des systèmes de traçage on-chain, des outils de sécurité construits collectivement par la communauté, ou encore des assurances décentralisées, afin de parfaire le dispositif de garantie financière.
5. L’expansion diversifiée de l’écosystème SUI
En moins de deux ans, SUI est passé d’une « nouvelle chaîne » à un « écosystème fort », construisant un paysage écologique diversifié couvrant stablecoins, DEX, infrastructures, DePIN, jeux, etc. La capitalisation totale des stablecoins dépasse désormais 1 milliard de dollars, fournissant une base solide de liquidité pour les modules DeFi. Avec une TVL classée 8ᵉ mondiale, une activité transactionnelle 5ᵉ mondiale et 3ᵉ parmi les réseaux non-EVM (derrière Bitcoin et Solana), SUI affiche une capacité robuste d’engagement utilisateur et de captation d’actifs.
1. Une attaque déclenchant une réaction en chaîne
Le 22 mai 2025, le protocole AMM phare Cetus, déployé sur le réseau SUI, a été victime d'une attaque informatique. L’attaquant a exploité une faille logique liée à un « dépassement d’entier », menant à un contrôle précis des marchés et à la perte de plus de 200 millions de dollars d’actifs. Cet événement constitue l’un des plus grands incidents de sécurité dans le domaine DeFi depuis le début de l’année, et représente l’attaque la plus destructrice subie par SUI depuis son lancement officiel.
Selon les données de DefiLlama, la TVL globale de SUI a chuté de plus de 330 millions de dollars le jour de l’attaque. Quant au montant bloqué sur Cetus, il a fondu de 84 % en quelques instants, tombant à 38 millions de dollars. Plusieurs jetons populaires sur SUI (notamment Lofi, Sudeng, Squirtle, etc.) ont plongé entre 76 % et 97 % en moins d’une heure, suscitant une vive inquiétude quant à la sécurité et à la stabilité de l’écosystème SUI.
Pourtant, après ce choc initial, l’écosystème SUI a fait preuve d’une grande résilience et d’une capacité de rebond remarquable. Bien que l’incident Cetus ait temporairement entamé la confiance, l’activité financière et l’engagement des utilisateurs n’ont pas connu de déclin durable. Au contraire, cet événement a stimulé une prise de conscience collective autour de la sécurité, du développement des infrastructures et de la qualité des projets.
Klein Labs analyse ici les causes de cette attaque, le mécanisme de consensus des nœuds SUI, la sécurité du langage Move et l’évolution de l’écosystème, afin de dresser un panorama complet de cette blockchain encore jeune, tout en explorant son potentiel futur.
2. Analyse des causes de l’attaque Cetus
2.1 Processus d’exécution de l’attaque
Selon l’analyse technique de l’équipe Slowmist sur l’attaque Cetus, l’attaquant a exploité avec succès une vulnérabilité critique de dépassement arithmétique dans le protocole, combinant flash loan, manipulation de prix précise et défaut de contrat, pour voler plus de 200 millions de dollars en actifs numériques. Le chemin d’attaque peut être divisé en trois phases principales :
① Lancer un flash loan, manipuler le prix
-
L’attaquant a d’abord emprunté massivement 10 milliards de haSUI via un flash swap avec un slippage maximal, obtenant ainsi de grandes liquidités pour manipuler les prix.
-
Les flash loans permettent à un utilisateur d’emprunter et de rembourser des fonds dans une seule transaction, moyennant uniquement des frais. Cette méthode offre un effet de levier élevé, un risque faible et un coût réduit. L’attaquant a utilisé ce mécanisme pour faire chuter brutalement le prix du marché, qu’il a ensuite contrôlé avec précision dans une fourchette très étroite.
-
Il a ensuite préparé la création d’une position de liquidité extrêmement étroite, définissant l’intervalle de prix entre 300 000 et 300 200, soit une amplitude de seulement 1,00496621 %.
-
Grâce à une quantité suffisamment élevée de jetons et une liquidité massive, l’attaquant a réussi à manipuler le prix du haSUI, puis a appliqué la même stratégie à plusieurs jetons sans valeur intrinsèque.
② Ajout de liquidité
L’attaquant a créé une position de liquidité étroite, annoncé l’ajout de liquidités, mais en raison d’un bogue dans la fonction checked_shlw, seul 1 jeton a finalement été perçu.
Cela découle essentiellement de deux raisons :
-
Masque trop large : équivalent à une limite maximale d’ajout de liquidité excessivement élevée, rendant inopérante la vérification des entrées utilisateur. En configurant des paramètres anormaux, l’attaquant a pu contourner la détection de dépassement.
-
Dépassement tronqué : lors de l’opération de décalage n << 64 sur la valeur n, un dépassement s’est produit car le décalage excède la largeur effective du type uint256 (256 bits). La partie haute a été automatiquement tronquée, conduisant à un résultat bien inférieur aux attentes. Le calcul final était environ inférieur à 1, mais arrondi à l’excès, donnant donc 1. Ainsi, l’attaquant n’avait besoin d’ajouter qu’un seul jeton pour retirer une quantité colossale de liquidités.
③ Retrait de liquidité
Remboursement du flash loan, conservation d’un profit massif. Finalement, l’attaquant a retiré des actifs d’une valeur totale de plusieurs centaines de millions de dollars de plusieurs pools de liquidité.
La perte financière a été sévère, entraînant le vol des actifs suivants :
- 12,9 millions de SUI (environ 54 millions de dollars)
- 60 millions de dollars USDC
- 4,9 millions de dollars Haedal Staked SUI
- 19,5 millions de dollars TOILET
- Autres jetons tels que HIPPO et LOFI en baisse de 75 à 80 %, liquidité asséchée
2.2 Origine et particularités de cette vulnérabilité
La faille Cetus présente trois caractéristiques :
1. Coût de correction extrêmement faible : d’une part, la cause fondamentale réside dans une omission de la bibliothèque mathématique de Cetus, et non dans une erreur du mécanisme de prix ou de l’architecture sous-jacente du protocole. D’autre part, elle est strictement limitée à Cetus et n’a aucun lien avec le code de SUI. La racine du problème se situe dans une condition limite, qui peut être complètement éliminée en modifiant deux lignes de code. Une fois corrigée, la mise à jour peut être déployée immédiatement sur le réseau principal, garantissant l’intégrité logique future et neutralisant la vulnérabilité.
2. Grande discrétion : le contrat a fonctionné sans incident pendant deux ans. Cetus Protocol a subi plusieurs audits, mais la faille n’a pas été détectée, principalement parce que la bibliothèque Integer_Mate utilisée pour les calculs mathématiques n’était pas incluse dans le périmètre d’audit.
L’attaquant a construit avec précision des intervalles de transaction extrêmes, créant un scénario rare impliquant une liquidité très élevée, déclenchant ainsi une logique anormale. Ce type de problème est difficile à détecter par des tests standards. Il se trouve souvent dans des zones aveugles, restant longtemps latente avant d’être découverte.
3. Problème non spécifique à Move :
Move surpasse de nombreux langages de contrats intelligents en matière de sécurité des ressources et de vérification des types, intégrant nativement la détection des dépassements d’entiers dans des cas courants. Ce dépassement s’est produit car, lors de l’ajout de liquidité, une mauvaise valeur a été utilisée pour la vérification de limite supérieure, et une opération de décalage a remplacé une multiplication standard. Or, avec des opérations classiques d’addition, soustraction, multiplication ou division, Move effectue automatiquement une vérification de dépassement, empêchant ainsi les problèmes de troncature haute.
Des vulnérabilités similaires sont apparues dans d’autres langages (comme Solidity ou Rust), voire plus fréquentes en raison de leur absence de protection contre les dépassements. Avant sa mise à jour, Solidity offrait une protection très faible contre les dépassements. Des cas historiques de dépassements d’addition, de soustraction ou de multiplication sont dus au fait que le résultat des opérations sortait de la plage autorisée. Par exemple, les failles dans les contrats BEC et SMT sur Solidity ont permis à des attaquants de transférer illégalement des fonds en contournant les instructions de vérification grâce à des paramètres soigneusement conçus.
3. Le mécanisme de consensus de SUI
3.1 Présentation du mécanisme de consensus SUI
Medium officiel de SUI
Vue d’ensemble :
SUI adopte un cadre de Preuve d’enjeu déléguée (DPoS). Bien que ce mécanisme améliore le débit transactionnel, il ne permet pas d’atteindre le haut niveau de décentralisation offert par la Preuve de travail (PoW). Ainsi, le degré de décentralisation de SUI est relativement faible, et le seuil de gouvernance plus élevé, limitant l’influence directe des utilisateurs ordinaires sur la gouvernance du réseau.
- Nombre moyen de validateurs : 106
- Durée moyenne d’un Epoch : 24 heures
Fonctionnement du mécanisme :
- Délégation d’enjeu : les utilisateurs ordinaires n’ont pas besoin d’héberger un nœud eux-mêmes. En engageant leurs SUI et en les déléguant à des validateurs candidats, ils participent à la sécurité du réseau et reçoivent une récompense. Ce mécanisme abaisse le seuil d’entrée pour les utilisateurs, qui peuvent ainsi « embaucher » des validateurs de confiance pour participer au consensus. C’est là un avantage majeur du DPoS par rapport au PoS traditionnel.
- Rotation des blocs par représentants : un petit nombre de validateurs sélectionnés produisent les blocs selon un ordre fixe ou aléatoire, augmentant ainsi la vitesse de confirmation et le TPS.
- Élection dynamique : à la fin de chaque période de vote, un nouveau jeu de validateurs est élu selon le poids des votes, garantissant la vitalité des nœuds, l’alignement des intérêts et un certain niveau de décentralisation.
Avantages du DPoS :
- Haute efficacité : avec un nombre contrôlé de nœuds producteurs de blocs, le réseau peut confirmer les transactions en millisecondes, répondant aux besoins élevés en TPS.
- Faible coût : moins de nœuds participant au consensus réduit considérablement la bande passante réseau et les ressources nécessaires à la synchronisation et à l’agrégation des signatures. Les coûts matériels et d’exploitation baissent, de même que les exigences en puissance de calcul, abaissant ainsi les frais pour les utilisateurs.
- Sécurité élevée : le mécanisme d’engagement et de délégation amplifie simultanément le coût et le risque d’attaque ; combiné à un mécanisme d’amende on-chain, il dissuade efficacement les comportements malveillants.
Par ailleurs, SUI utilise un algorithme basé sur BFT (Byzantine Fault Tolerance), exigeant qu’au moins deux tiers des validateurs atteignent un consensus pour confirmer une transaction. Ce mécanisme assure la sécurité et le bon fonctionnement du réseau même si certains nœuds deviennent malveillants. Pour toute mise à niveau ou décision majeure, plus des deux tiers des votes sont requis.
En essence, le DPoS représente un compromis dans le triangle impossible, équilibrant décentralisation et efficacité. Dans le triangle « sécurité - décentralisation - évolutivité », le DPoS choisit de réduire le nombre de nœuds producteurs actifs pour gagner en performance, sacrifiant une certaine forme de décentralisation complète par rapport au PoS pur ou au PoW, mais augmentant significativement le débit et la vitesse des transactions.
3.2 Performance de SUI durant l’attaque
3.2.1 Fonctionnement du mécanisme de gel
Dans cet incident, SUI a gelé rapidement les adresses liées à l’attaquant :
Au niveau du code, cela signifie que les transactions associées ne peuvent plus être incluses dans les blocs. Les nœuds validateurs étant des composants centraux de la blockchain SUI, chargés de valider les transactions et d’appliquer les règles du protocole, en ignorant collectivement les transactions liées à l’attaquant, ces validateurs ont mis en œuvre, au niveau du consensus, un mécanisme similaire au « gel de compte » dans la finance traditionnelle.
SUI dispose nativement d’un mécanisme de liste de refus (deny list), une fonction de liste noire capable de bloquer toute transaction impliquant des adresses inscrites. Comme cette fonctionnalité existe déjà dans les clients, dès l’attaque,
SUI a pu immédiatement geler l’adresse du pirate. Sans cette fonction, même avec seulement 113 validateurs, Cetus aurait eu du mal à coordonner rapidement tous les validateurs pour une réponse unifiée.
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. Tout exploitant de nœud peut modifier ce fichier, le recharger à chaud ou redémarrer le nœud, et ainsi mettre à jour la liste. En apparence, chaque validateur exprime librement ses propres valeurs.
-
En réalité, pour assurer la cohérence et l’efficacité des stratégies de sécurité, ces mises à jour critiques sont généralement coordonnées. Puisqu’il s’agit d’une « mise à jour d’urgence lancée par l’équipe SUI », c’est en pratique la Fondation SUI (ou ses développeurs autorisés) qui configure et met à jour cette liste de refus.
-
SUI publie la liste noire ; théoriquement, les validateurs peuvent choisir de l’adopter ou non — mais en pratique, la majorité l’adoptent par défaut. Ainsi, bien que cette fonction protège les fonds des utilisateurs, elle comporte effectivement un certain degré de centralisation.
3.2.3 Nature fondamentale de la fonction de liste noire
La fonction de liste noire n’est pas non plus une logique de base du protocole. Elle ressemble davantage à une couche de sécurité supplémentaire mise en place pour faire face à des situations d’urgence et garantir la sécurité des fonds des utilisateurs.
Elle constitue essentiellement un mécanisme de garantie de sécurité. Comme une « chaîne de porte » installée chez soi, elle n’est activée que contre ceux qui cherchent à forcer l’entrée, c’est-à-dire contre ceux qui tentent de violer le protocole. Pour les utilisateurs :
- Pour les gros portefeuilles, principaux fournisseurs de liquidité, le protocole a tout intérêt à garantir la sécurité de leurs fonds, car la TVL on-chain repose largement sur eux. Pour assurer un développement durable, la priorité va naturellement à la sécurité.
- Pour les petits investisseurs, contributeurs à l’activité écologique et soutiens clés du développement technologique et communautaire. Les projets souhaitent aussi attirer ces petits acteurs pour enrichir progressivement l’écosystème et améliorer la rétention. Dans le domaine DeFi, la priorité absolue reste la sécurité financière.
Le critère clé pour juger du « degré de centralisation » doit être le contrôle que possède l’utilisateur sur ses actifs. Sur ce point, SUI illustre parfaitement la propriété native des fonds grâce au langage Move :
SUI est construit sur le langage Move, dont le principe fondamental peut se résumer à « les fonds suivent l’adresse » :
Contrairement à Solidity, où le contrat intelligent est au cœur des interactions, dans Move, les actifs des utilisateurs sont toujours directement stockés sous leur propre adresse, et la logique transactionnelle tourne autour du transfert de propriété des ressources. Cela signifie que le contrôle des actifs appartient naturellement à l’utilisateur, sans être hébergé par un contrat, réduisant ainsi les risques de perte dus à des bogues de contrat ou à une mauvaise conception des permissions, et renforçant fondamentalement les attributs de décentralisation.
SUI s’efforce actuellement de renforcer sa décentralisation. Grâce à la proposition SIP-39, elle travaille à réduire progressivement les barrières d’entrée pour les validateurs. La nouvelle proposition ajuste le seuil d’entrée non plus uniquement selon la quantité engagée, mais selon le poids du vote, augmentant ainsi la participation des utilisateurs ordinaires.
3.3 Limites et réalités de la décentralisation : la controverse de gouvernance soulevée par SUI
Dans la réponse d’urgence de SUI, l’action conjointe de la communauté et des validateurs a suscité de vives discussions sur son degré de « décentralisation » :
Certains professionnels du chiffrement considèrent que SUI est plutôt décentralisé
- Membres de la communauté SUI répondent : « Être décentralisé, ce n’est pas rester inactif face aux victimes, mais permettre à chacun d’agir ensemble sans permission. » — Face au vol massif de fonds, il est impossible de rester passif.
- « C’est là la vraie décentralisation dans le monde réel, pas l’impuissance, mais la capacité à agir de concert avec la communauté. Le cœur de la décentralisation n’est pas d’observer sans rien faire pendant qu’on attaque quelqu’un, mais la capacité de la communauté à coopérer sans autorisation. »
- Ce n’est pas propre à SUI — de l’Ethereum à la BSC, la plupart des chaînes PoS font face à des risques similaires de centralisation des validateurs. Le cas SUI n’a fait que rendre le problème plus visible.
D’autres professionnels jugent SUI trop centralisé :
- Par exemple : Justin Bons, fondateur de Cyber Capital, affirme franchement que les validateurs SUI collaborent pour censurer les transactions du pirate. Cela signifie-t-il que SUI est centralisé ? Réponse courte : oui. Mais plus important encore, pourquoi ? Parce que les « fondateurs » détiennent la majeure partie de l’offre, et qu’il n’y a que 114 validateurs ! En comparaison, Ethereum compte plus d’un million de validateurs, Solana en a 1 157.
Nous pensons toutefois que cette théorie est quelque peu partielle :
- Tous les validateurs SUI ont essentiellement les mêmes fonctions, et sont soumis à une rotation dynamique, assurant un renouvellement constant, empêchant la concentration du pouvoir et les inégalités de configuration.
D’un point de vue macroéconomique, en raison de l’asymétrie d’information et d’un marché encore imparfait, une centralisation modérée et légère est nécessaire à ce stade.
D’un point de vue de la théorie économique classique, le modèle centralisé présente aussi ses avantages
- Réduction des risques d’asymétrie d’information : les entités centralisées disposent souvent de plus d’informations, leur permettant d’évaluer plus précisément les risques de transaction, évitant ainsi efficacement la sélection adverse et les risques moraux.
- Réponse aux fluctuations du marché : face à des chocs externes ou des risques systémiques, un mécanisme centralisé peut prendre rapidement des décisions unifiées et mobiliser des ressources, renforçant la résilience et la capacité d’adaptation du marché.
- Favorise la coordination et la coopération : les institutions centralisées facilitent une coordination plus efficace dans les conflits d’intérêts multiples, promouvant une allocation rationnelle des ressources et une amélioration globale de l’efficacité.
En résumé, une centralisation légère et encadrée n’est pas un fléau, mais un complément efficace à l’idéal de « décentralisation » dans les conditions économiques réelles. Il s’agit d’un arrangement transitoire, tandis que le monde du chiffrement évoluera inévitablement vers la décentralisation — c’est un consensus sectoriel, et l’objectif ultime du développement technologique et conceptuel. Dans ce scénario, cette centralisation a permis une régulation macroéconomique similaire au keynésianisme. Tout comme dans une économie, un marché entièrement décentralisé peut connaître des crises, et une régulation macroéconomique modérée peut orienter le système économique dans une direction favorable.
4. Le fossé technologique de Move
Dans le monde du chiffrement, où les incidents de sécurité contractuelle sont fréquents, le langage Move, grâce à son modèle de ressources, son système de types et ses mécanismes de sécurité, devient progressivement une infrastructure clé pour les nouvelles blockchains :
1. Propriété claire des fonds, isolation naturelle des permissions
Move : les actifs sont des ressources, chaque ressource est indépendante, appartient à un seul compte, et le propriétaire doit être explicitement défini. Les actifs appartiennent strictement à l’argent dans le portefeuille utilisateur, seul l’utilisateur peut les gérer, permissions claires.
Solidity : les actifs des utilisateurs sont en réalité contrôlés par le contrat, les développeurs doivent écrire manuellement des logiques de contrôle pour limiter l’accès. Une erreur dans les permissions peut entraîner des dysfonctionnements du contrat intelligent, permettant une manipulation arbitraire des actifs.
2. Protection linguistique contre les attaques de réentrance
- Move : basé sur la propriété des ressources et le système de types linéaires, chaque utilisation d’une ressource la vide, rendant impossible un appel répété, bloquant naturellement les attaques de réentrance.
- Solidity : la « réentrance » est l’une des attaques les plus célèbres sur Ethereum, comme la fameuse faille The DAO. Solidity comporte un risque de réentrance, que les développeurs doivent contrer manuellement via le modèle « Vérifier - Effet - Interaction ». Une omission entraîne des risques élevés.
3. Gestion automatique de la mémoire et suivi de la propriété des ressources
- Move : inspiré du modèle linéaire et de la propriété de Rust, tous les cycles de vie des ressources peuvent être suivis au moment de la compilation. Le système récupère automatiquement les variables inutilisées et interdit les copies implicites ou les abandons, éliminant les risques de pointeurs pendus ou de libération multiple.
- Solidity : utilise un modèle de pile avec gestion manuelle de la mémoire. Les développeurs doivent gérer eux-mêmes le cycle de vie des variables, ce qui peut facilement entraîner des fuites de mémoire, des références invalides ou des abus de permissions, augmentant ainsi les vulnérabilités et les surfaces d’attaque.
4. Architecture issue de Rust, plus sûre et plus lisible
- Syntaxe plus rigoureuse : vérification de type forte à la compilation, sécurité mémoire, absence de variables non initialisées, les erreurs logiques sont détectées avant l’exécution, réduisant les incidents en production.
- Mécanisme d’erreur complet : le compilateur indique clairement l’emplacement et le type d’erreur, facilitant le développement et le débogage, réduisant les comportements imprévisibles.
5. Coût Gas plus bas, efficacité d’exécution plus élevée
Le langage Move, structurellement léger, avec des chemins d’exécution plus courts et une machine virtuelle optimisée, consomme moins de ressources par unité de calcul (Gas). Cela améliore l’efficacité d’exécution, réduit le coût des opérations pour les utilisateurs, et convient particulièrement aux applications à transactions fréquentes comme DeFi ou mint NFT.
En résumé, le langage Move surpasse nettement les langages traditionnels de contrats intelligents en termes de sécurité et de maîtrise, évitant fondamentalement les chemins d’attaque et les failles logiques courantes grâce à son modèle de ressources et son système de types. Move incarne l’évolution du développement de contrats intelligents, passant de « fonctionner coûte que coûte » à « sécurisé par conception ». Il fournit une infrastructure solide pour de nouvelles blockchains comme SUI, et ouvre de nouvelles perspectives à l’évolution technologique du secteur du chiffrement.
5. Réflexions et recommandations suite à l’incident SUI
Les avantages techniques ne signifient pas l’invulnérabilité. Même sur une blockchain conçue pour la sécurité, des interactions complexes entre contrats ou un traitement inadéquat des conditions limites peuvent devenir des points d’entrée pour les attaquants. L’incident récent sur SUI nous rappelle une fois de plus qu’en plus de la conception sécurisée, l’audit et la validation mathématique sont indispensables. Voici quelques recommandations ciblées issues des perspectives de développement et de gestion des risques.
5.1 Attaques de hackers
1. Les conditions limites mathématiques doivent être rigoureusement analysées
L’attaque révèle une faille due à des conditions limites mathématiques imprécises. L’attaquant a manipulé la position de liquidité du contrat, exploitant des erreurs de limite et des dépassements numériques pour contourner les contrôles de sécurité. Il est donc impératif d’analyser rigoureusement toutes les fonctions mathématiques critiques, afin de garantir leur bon fonctionnement sous toutes les conditions d’entrée.
2. Introduire des audits mathématiques spécialisés pour les vulnérabilités complexes
La vulnérabilité de dépassement de données et d’erreur de vérification de limite dans cet incident implique des calculs mathématiques complexes et des opérations de décalage, difficiles à détecter par un audit classique. Les audits traditionnels se concentrent sur la fonctionnalité et la sécurité du contrat, mais l’examen de problèmes mathématiques complexes requiert un bagage spécialisé. Nous recommandons donc d’intégrer des équipes d’audit mathématique professionnelles pour identifier et corriger ces risques.
3. Renforcer les normes d’audit pour les projets déjà attaqués
Le hacker a utilisé le mécanisme de flash loan pour manipuler le marché, prouvant que même les projets ayant déjà subi une attaque restent vulnérables. Si un projet a déjà été attaqué, son code et son contrat doivent subir un examen plus rigoureux et approfondi, pour éviter des failles similaires. En particulier, les revues liées au traitement mathématique, aux dépassements de données et aux failles logiques doivent être plus exhaustives.
4. Vérification stricte des conversions numériques croisées entre types
Le pirate a exploité un masque trop large et une troncature de dépassement, provoquant une erreur de calcul dans le contrat, puis manipulant les prix. Toutes les conversions numériques entre types, comme celles entre entiers et flottants, doivent être strictement vérifiées aux limites, pour éviter tout risque de dépassement ou de perte de précision. En particulier lors du calcul avec de grandes valeurs, des méthodes de traitement plus strictes doivent être adoptées.
5. La « petite monnaie attaque » peut causer des dommages considérables
Le pirate a manipulé des jetons à faible valeur (« poussière ») pour influencer les prix, profitant de leur faible liquidité. Dans les échanges AMM DeFi, ces jetons sont faciles à manipuler. Cette opération ne concerne pas seulement les jetons à haute valeur, les jetons à faible valeur peuvent aussi devenir des points d’attaque. Les projets doivent donc prendre conscience de la menace potentielle de la « petite monnaie attaque » et y prévoir des mesures de prévention.
6. Renforcer la surveillance en temps réel et la capacité de réponse aux comportements de hackers
Avant de réussir à attaquer le protocole, le pirate avait tenté une attaque similaire, mais la transaction avait échoué probablement par manque de Gas. Une transaction de liquidité aussi importante, même ratée, aurait dû être détectée et signalée immédiatement. Le système de surveillance de la plateforme devrait déclencher un mécanisme de contrôle des risques dès qu’une transaction anormale se produit, identifiant précocement les menaces potentielles. En renforçant la surveillance en temps réel des comportements transactionnels on-chain, combinée à des outils d’analyse avancés, la plateforme peut intervenir rapidement en phase initiale pour éviter des pertes supplémentaires.
5.2 Garantie de sécurité financière on-chain et gestion des urgences
5.2.1 Mécanisme de réponse de SUI en situation de crise
1. Interconnexion des nœuds validateurs, blocage rapide de l’adresse du pirate
-
SUI a renforcé l’interconnexion entre les nœuds validateurs, bloquant rapidement l’adresse du pirate, minimisant ainsi les pertes.
-
Il faut d’abord comprendre le principe fondamental du transfert de fonds on-chain : chaque transfert doit être signé par une clé privée pour prouver la propriété des fonds, puis validé par les validateurs du réseau (nœuds ou séquenceurs) pour légitimité, ensuite empaqueté dans un bloc et diffusé sur la chaîne, aboutissant à un processus de règlement immuable.
-
Le blocage des fonds par SUI s’effectue précisément à l’étape de validation : en ajoutant l’adresse du pirate à la liste noire, puis en la synchronisant à tous les nœuds validateurs, ceux-ci refusent de valider et d’empaqueter les transactions associées, bloquant ainsi l’inscription des fonds, réalisant un effet de gel.
2. Subventions d’audit et renforcement de la sécurité on-chain
SUI accorde une grande importance à la sécurité on-chain, offrant des services d’audit gratuits aux projets. Elle soutient fortement la sécurité écologique. Après l’attaque sur Cetus, la Fondation SUI a annoncé un financement supplémentaire de 10 millions de dollars dédiés aux audits, renforçant davantage la sécurité on-chain.
3. Réponse coordonnée entre Cetus et SUI
Dans cet incident de sécurité, Cetus et SUI ont montré une forte capacité de réponse coordonnée et un mécanisme de liaison écologique. Dès l’anomalie détectée, l’équipe Cetus a rapidement communiqué avec les nœuds validateurs SUI, et avec le soutien de la majorité d’entre eux, a réussi à geler deux adresses portefeuilles du pirate, immobilisant plus de 160 millions de dollars, gagnant un délai crucial pour le recouvrement et la compensation des actifs.
Plus important encore, Cetus a officiellement annoncé qu’en combinant ses réserves en espèces et en jetons, et avec le soutien clé de la Fondation SUI, il serait en mesure d’assurer une compensation intégrale à 100 % pour les utilisateurs affectés.
Cette série d’actions coordonnées illustre non seulement la flexibilité et l’efficacité des infrastructures de SUI face aux risques extrêmes, mais reflète aussi la base de confiance et le consensus de responsabilité entre les projets de l’écosystème, jetant des bases solides pour un écosystème DeFi SUI plus résilient.
5.2.2 Réflexions sur la sécurité financière des utilisateurs suite à l’attaque Cetus
1. Du point de vue technique, la restauration directe des fonds on-chain n’est pas totalement impossible. Deux méthodes courantes existent :
- Annuler les opérations on-chain : revenir en arrière sur certaines transactions, ramenant l’état à un moment antérieur à l’attaque ;
- Utiliser une permission multisignature : via une autorisation multipartite, contrôler un portefeuille clé pour récupérer de force les fonds depuis l’adresse du pirate.
Toutefois, ces méthodes ne sont généralement activées que lorsque le volume de fonds est très élevé et le risque extrême. Elles sont efficaces, mais heurtent le principe de décentralisation, risquant de susciter des controverses. Ainsi, de nombreux projets évitent de les utiliser, sauf en dernier recours, quand les négociations échouent et que les fonds ne peuvent être récupérés.
Dans le cas récent de Cetus et SUI, aucune intervention directe sur les données on-chain n’a été choisie. Ils ont opté pour une approche plus douce : geler les demandes de transaction depuis les adresses malveillantes au niveau des validateurs. Comparée aux méthodes brutales, cette approche respecte davantage l’esprit de décentralisation, illustrant une capacité de gouvernance de sécurité plus nuancée dans l’écosystème Move.
2. Construction collective par la communauté, amélioration des mécanismes de traçage de sécurité
Pour renforcer la sécurité de l’écosystème Move, la construction communautaire est essentielle. Actuellement, la base technique Move est solide, mais les participants sont encore peu nombreux, notamment en matière de traçage on-chain et d’audit de sécurité. Par comparaison, Ethereum a développé grâce à la communauté des outils complets de surveillance on-chain (comme Etherscan). Il est donc nécessaire que davantage de développeurs et d’organismes de sécurité participent à la construction de systèmes similaires, améliorant ainsi la transparence et la résilience de l’écosystème.
3. Introduire des assurances pour garantir la sécurité financière
Certains projets décentralisés collaborent avec des protocoles d’assurance comme Nexus Mutual pour protéger les fonds des utilisateurs, réduisant ainsi les pertes dues à des vulnérabilités ou attaques.
6. Un écosystème SUI en plein essor : au-delà du DeFi, tout prospère
SUI traverse actuellement une période particulière. Malgré certains défis, il conserve une position dominante en matière de TVL, d’activité des développeurs et de développement écologique, consolidant sa place de leader parmi les blockchains Move. Pourtant, certaines parties de la communauté restent dans la FUD (peur, incertitude, doute), manquant de compréhension rationnelle des atouts techniques et du potentiel écologique de SUI.
À ce jour, la TVL du réseau SUI atteint environ 1,6 milliard de dollars, avec un volume quotidien moyen des DEX autour de 300 millions de dollars, témoignant d’une forte activité financière et d’un grand enth
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@kleinlabsxyz
