Un point de vue : les hackers ont volé de l'argent, donc Sui peut le confisquer ?
TechFlow SélectionTechFlow Sélection
Un point de vue : les hackers ont volé de l'argent, donc Sui peut le confisquer ?
La valeur de la blockchain ne réside pas dans la possibilité ou non de geler des actifs, mais dans le fait que même si un groupe en a la capacité, il choisit de ne pas le faire.
Dédié à des analyses Web3 approfondiesRédaction : Shi Jun
Cet événement représente une victoire du capital, pas celle des utilisateurs, et constitue même un recul pour le développement du secteur.
Bitcoin à gauche, Sui à droite. Chaque action dans l'industrie qui ébranle la décentralisation renforce davantage la croyance en Bitcoin.
Le monde a besoin non seulement d'une meilleure infrastructure financière mondiale, mais il y aura toujours un groupe de personnes nécessitant un espace de liberté.
Il fut un temps où les blockchains consortiales étaient plus populaires que les blockchains publiques, car elles répondaient aux besoins réglementaires de cette époque. Le déclin actuel de ces blockchains consortiales signifie en réalité que répondre uniquement à ces exigences n'est pas conforme aux véritables besoins des utilisateurs. Si les utilisateurs réglementés disparaissent, pourquoi aurait-on encore besoin d'outils de régulation ?
1. Contexte de l'événement
Le 22 mai 2025, Cetus, le principal échange décentralisé (DEX) au sein de l'écosystème de la blockchain publique Sui, a été victime d'une attaque par piratage informatique. La liquidité a chuté brutalement, les prix de nombreux couples de trading se sont effondrés, entraînant une perte supérieure à 220 millions de dollars américains.
À la date de publication, la chronologie des faits est la suivante :
-
Le matin du 22 mai : Un pirate informatique s'est emparé de 230 millions de dollars via une attaque sur Cetus. Cetus a immédiatement suspendu son contrat intelligent et publié une annonce officielle.
-
L’après-midi du 22 mai : Le pirate a transféré environ 60 millions de dollars via un pont entre chaînes ; les 162 millions restants demeurent sur une adresse de la chaîne Sui. Les nœuds validateurs de Sui ont rapidement agi en ajoutant l’adresse du pirate à une « liste noire de refus de service (Deny List) », gelant ainsi les fonds.
-
Le soir du 22 mai : Le directeur produit de Sui, @emanabio, a confirmé par tweet que les fonds étaient gelés et que leur restitution débuterait prochainement.
-
Le 23 mai : Cetus a commencé à corriger la vulnérabilité et à mettre à jour son contrat.
-
Le 24 mai : Sui a publié une demande d’intégration (PR) open source expliquant qu’il utiliserait bientôt un mécanisme d’alias (aliasing) et une whitelist pour récupérer les fonds.
-
Le 26 mai : Sui a lancé un vote de gouvernance sur chaîne afin de décider s’il fallait ou non exécuter une mise à niveau du protocole permettant de transférer les actifs du pirate vers une adresse de garde.
-
Le 29 mai : Résultats du vote annoncés : plus des deux tiers du poids total des nœuds validateurs ont donné leur accord ; la préparation de l’exécution de la mise à niveau du protocole a commencé.
-
Du 30 mai au début juin : La mise à niveau du protocole est entrée en vigueur, des transactions spécifiques ont été exécutées, et les actifs du pirate ont été « légalement transférés ».
2. Principe de l'attaque
Concernant le principe technique de cet incident, plusieurs articles ont déjà été publiés dans le secteur. Nous n’en présentons ici qu’un aperçu synthétique :
Sur le plan du processus d’attaque :
L’attaquant a d’abord utilisé un prêt flash pour emprunter environ 10 024 321,28 haSUI, provoquant une chute instantanée de 99,90 % du prix dans le pool de trading.
Cette vente massive a fait passer le prix du pool ciblé d’environ 1,8956×10¹⁹ à 1,8425×10¹⁹, vidant presque entièrement le pool.
Ensuite, l’attaquant a créé une position de liquidité sur Cetus avec un intervalle extrêmement étroit (borne inférieure Tick = 300000, borne supérieure = 300200, largeur d’intervalle de seulement 1,00496621 %). Ce petit intervalle amplifie fortement l’impact des erreurs de calcul sur la quantité de jetons requis.
Le cœur du problème technique :
Un dépassement d’entier (integer overflow) existe dans la fonction get_delta_a de Cetus, utilisée pour calculer la quantité de jetons nécessaire. L’attaquant a déclaré intentionnellement vouloir ajouter une très grande quantité de liquidité (environ 10³⁷ unités), tout en ne déposant réellement qu’un seul jeton dans le contrat.
En raison d’une erreur dans la condition de détection du dépassement checked_shlw, le système a tronqué les bits de poids fort lors d’un décalage à gauche, sous-estimant gravement la quantité requise de haSUI. Ainsi, l’attaquant a pu acquérir une immense liquidité à très faible coût.
D’un point de vue technique, cette vulnérabilité provient de l’utilisation incorrecte d’un masque et de conditions de vérification dans le contrat intelligent Move de Cetus, permettant à toute valeur inférieure à 0xffffffffffffffff << 192 de contourner la vérification. Après un décalage de 64 bits, les données de poids fort sont tronquées, et le système considère avoir reçu une grande liquidité alors qu’il n’a perçu qu’un très petit nombre de jetons.
Après l’incident, deux opérations officielles ont été mises en œuvre : « gel » vs « récupération ». Il s’agit de deux phases distinctes :
-
La phase de gel repose sur la Deny List et le consensus des nœuds ;
-
La phase de récupération nécessite une mise à niveau du protocole sur chaîne, un vote communautaire, puis l’exécution d’une transaction désignée contournant la liste noire.
3. Mécanisme de gel de Sui
Sui dispose nativement d’un mécanisme particulier appelé Deny List (liste de refus), qui a permis le gel des fonds piratés. En outre, la norme de jeton de Sui inclut également un mode « jeton réglementé », doté d’une fonction intégrée de gel.
C’est précisément cette caractéristique qui a été exploitée pour le gel d’urgence : les opérateurs de nœuds validateurs ont rapidement ajouté les adresses liées aux fonds volés dans leurs fichiers de configuration locaux. Théoriquement, chaque opérateur peut modifier manuellement TransactionDenyConfig pour mettre à jour la liste noire. Toutefois, afin d’assurer la cohérence du réseau, la Fondation Sui, en tant qu’autorité initiale de configuration, a coordonné cette action de manière centralisée.
La Fondation a d’abord publié officiellement une mise à jour de configuration incluant l’adresse du pirate. Les validateurs, synchronisant cette configuration par défaut, ont rendu effectif le blocage, « scellant » temporairement les fonds sur la chaîne. Cette procédure révèle en réalité un haut degré de centralisation.
Pour permettre aux victimes de récupérer leurs fonds, l’équipe de Sui a ensuite introduit un correctif basé sur un mécanisme de liste blanche (Whitelist).
Ce dispositif concerne les opérations ultérieures de retour des fonds. Des transactions légitimes peuvent être prédéfinies et inscrites sur la whitelist. Même si l’adresse des fonds reste sur la liste noire, ces transactions peuvent être exécutées de force.
La nouvelle fonctionnalité transaction_allow_list_skip_all_checks permet d’inscrire certaines transactions dans une « liste sans contrôle », leur permettant de contourner toutes les vérifications de sécurité, y compris signature, autorisations et liste noire.
Il convient de noter que ce correctif de whitelist ne permet pas de saisir directement les actifs du pirate ; il accorde simplement à certaines transactions la capacité de contourner le gel. Le transfert réel des actifs nécessite toujours une signature valide ou un module de permissions système supplémentaire.
En général, les solutions industrielles courantes de gel s’appliquent au niveau du contrat du jeton et sont contrôlées par une signature multiple de l’émetteur.
Par exemple, USDT émis par Tether intègre une fonction de liste noire dans son contrat, permettant à l’entreprise émettrice de bloquer des adresses malveillantes empêchant ainsi tout transfert d’USDT. Cette solution nécessite qu’une signature multiple lance une demande de gel sur chaîne, et l’exécution effective n’intervient qu’après accord unanime, ce qui implique un délai d’exécution.
Bien que le mécanisme de gel de Tether soit efficace, les statistiques montrent que le processus multisig présente souvent une « période creuse », offrant une opportunité aux fraudeurs.
En comparaison, le gel réalisé par Sui intervient au niveau fondamental du protocole, mis en œuvre collectivement par les nœuds validateurs, dont la vitesse d’exécution est bien supérieure à un simple appel de contrat.
Dans ce modèle, pour agir rapidement, cela suppose que la gestion des nœuds validateurs eux-mêmes soit hautement centralisée.
3. Principe de la « récupération par transfert » de Sui
Plus impressionnant encore, Sui n’a pas seulement gelé les actifs du pirate, mais a aussi prévu de « récupérer » les fonds volés via une mise à niveau de la chaîne.
Le 27 mai, Cetus a proposé un vote communautaire demandant une mise à niveau du protocole afin d’envoyer les fonds gelés vers un portefeuille de garde multisig. La Fondation Sui a aussitôt lancé un vote de gouvernance sur chaîne.
Le 29 mai, les résultats du vote ont été publiés : environ 90,9 % du poids total des validateurs ont approuvé la proposition. Sui a annoncé officiellement que, une fois la proposition adoptée, « tous les fonds gelés sur les deux comptes du pirate seraient récupérés vers un portefeuille multisig sans nécessiter la signature du pirate ».
Ne pas nécessiter la signature du pirate : quelle différence frappante ! Jamais auparavant l’industrie blockchain n’avait connu une telle méthode de correction.
D’après la demande d’intégration (PR) publiée sur GitHub par Sui, le protocole introduit un mécanisme d’alias d’adresse (address aliasing). La mise à jour comprend la définition anticipée de règles d’alias dans ProtocolConfig, permettant à certaines transactions autorisées de faire croire que leur signature provient du compte du pirate.
Concrètement, une liste de hachages de transactions de secours est liée à l’adresse cible (l’adresse du pirate). Tout exécutant qui signe et publie l’un de ces résumés de transaction fixe est considéré comme le véritable détenteur du compte pirate lançant la transaction. Pour ces transactions spécifiques, le système des nœuds validateurs contourne le contrôle de la Deny List.
Au niveau du code, Sui a ajouté dans sa logique de validation des transactions le test suivant : lorsque une transaction est interceptée par la liste noire, le système examine ses signataires et vérifie si protocol_config.is_tx_allowed_via_aliasing(sender, signer, tx_digest) est vrai.
Dès qu’un signataire satisfait aux règles d’alias, la transaction est marquée comme autorisée, l’erreur d’interception précédente est ignorée, et le traitement normal de packaging et d’exécution continue.
4. Analyse
160 millions, déchirant la foi la plus profonde du secteur
Pour l’auteur, l’affaire Cetus pourrait bien passer rapidement, mais ce modèle ne sera pas oublié, car il bouleverse les bases du secteur et brise le consensus traditionnel selon lequel un même registre blockchain doit être immuable.
Dans la conception blockchain, le contrat est la loi, le code est l’arbitre.
Mais dans cet incident, le code a échoué, la gouvernance est intervenue, le pouvoir a pris le dessus, instaurant un modèle où une décision collective annule les résultats du code.
C’est précisément parce que la méthode employée par Sui — déplacer directement les transactions — diffère radicalement de la manière habituelle utilisée par les blockchains pour traiter les problèmes de piratage.
Ce n’est pas la première fois que le consensus est « altéré », mais c’est la plus silencieuse
Historiquement :
-
Lors de l’incident The DAO sur Ethereum en 2016, une bifurcation dure (hard fork) avait permis de remettre à zéro les transferts et de compenser les pertes. Cette décision a conduit à la scission entre Ethereum et Ethereum Classic. Bien que controversée, elle a finalement vu différents groupes former leurs propres consensus.
-
La communauté Bitcoin a également connu un défi technique similaire : en 2010, une vulnérabilité d’excès de valeur a été corrigée en urgence par les développeurs, mettant à jour les règles de consensus et effaçant complètement environ 18,4 milliards de bitcoins illégalement générés.
Il s’agit là aussi de modèles de hard fork : revenir en arrière dans le registre avant l’apparition du problème, laissant ensuite aux utilisateurs le choix de continuer sur l’un ou l’autre registre.
Comparé au hard fork de DAO, Sui n’a pas choisi de diviser la chaîne, mais a utilisé une mise à niveau du protocole combinée à un mécanisme d’alias pour cibler précisément cet incident. Ainsi, Sui a préservé la continuité de la chaîne et la plupart des règles de consensus inchangées, tout en montrant que le protocole sous-jacent peut être utilisé pour mener des « opérations de sauvetage » ciblées.
Le problème est que les « retours par fork » historiques laissaient le choix aux utilisateurs ; la « correction par protocole » de Sui prend la décision à leur place.
Not Your Key, Not Your Coin ? Peut-être plus maintenant.
À long terme, cela signifie que le principe « Not your keys, not your coins » est sapé sur Sui : même avec une clé privée intacte, le réseau peut collectivement bloquer et rediriger les actifs via une modification du protocole.
Si cela devient un précédent pour traiter les grands incidents de sécurité dans l’avenir, voire une pratique répétable.
« Quand une chaîne peut violer les règles pour la justice, elle crée un précédent lui permettant de violer n’importe quelle règle. »
Dès qu’un « vol pour une bonne cause » réussit, la prochaine intervention pourrait concerner un terrain moralement flou.
Et que se passera-t-il alors ?
Le pirate a effectivement volé l’argent des utilisateurs. Alors, par vote majoritaire, peut-on lui prendre son argent ?
Le vote repose-t-il sur celui qui a le plus d’argent (PoS) ou sur celui qui a le plus de voix ? Si c’est l’argent qui l’emporte, le « dernier propriétaire » imaginé par Liu Cixin arrivera vite. Si c’est le nombre, alors la foule irrationnelle dominera.
Dans les systèmes traditionnels, les gains illégaux ne sont pas protégés, et le gel ou le transfert sont des opérations courantes dans les banques.
Mais justement, l'impossibilité technique de faire cela n’était-elle pas la racine même du développement de l’industrie blockchain ?
Aujourd’hui, avec la pression croissante de la conformité réglementaire, si on peut geler aujourd’hui pour un piratage ou modifier des soldes de comptes, demain on pourra le faire pour des raisons géopolitiques ou conflictuelles. Si la chaîne devient un outil régionalisé…
Alors la valeur du secteur sera fortement réduite, n’étant guère plus qu’un autre système financier, encore moins pratique.
C’est pour cela que je crois fermement en ce secteur : « La blockchain n’a pas de valeur parce qu’on ne peut pas geler, mais parce qu’elle refuse de changer, même si on la déteste. »
Face à la tendance inévitable de la régulation, la chaîne pourra-t-elle garder son âme ?
Il fut un temps où les blockchains consortiales dominaient les blockchains publiques, car elles répondaient aux besoins réglementaires de l’époque. Leur déclin actuel signifie que se plier aveuglément à ces besoins ne correspond pas aux véritables attentes des utilisateurs. Sans utilisateurs réglementés, pourquoi aurait-on encore besoin d’outils de régulation ?
D’un point de vue sectoriel
L’efficacité centralisée est-elle une étape incontournable du développement blockchain ? Si l’objectif final de la décentralisation est de protéger les intérêts des utilisateurs, pouvons-nous tolérer la centralisation comme moyen transitoire ?
Le mot « démocratie », dans le contexte de la gouvernance sur chaîne, est en réalité pondéré par jetons (token weighted). Si un pirate détient une grande quantité de SUI (ou si un jour un DAO piraté donne au pirate le contrôle du vote), pourra-t-il « légalement voter pour se blanchir » ?
Finalement, la valeur de la blockchain ne réside pas dans sa capacité à geler, mais dans le choix de ne pas le faire, même quand la communauté en a le pouvoir.
L’avenir d’une chaîne n’est pas déterminé par son architecture technique, mais par la foi qu’elle choisit de protéger.
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
