Le hacker a volé l'argent, alors Sui peut-il le voler ?

Avancé6/9/2025, 1:52:27 AM
Bien que L2 joue un rôle important dans l'innovation et l'avancement économique, une dépendance excessive à L2 peut affaiblir l'effet de réseau d'Ethereum Layer 1 (L1). L'article propose le concept de Rollup ultrasonique, qui est un design de Rollup natif combinant la disponibilité des données, l'exécution et l'ordonnancement, visant à renforcer plutôt qu'à affaiblir l'effet de réseau d'Ethereum.

Introduction

Cet incident est une victoire pour le capital, pas pour les utilisateurs, et c'est un revers pour le développement de l'industrie.

Bitcoin à gauche, Sui à droite, chaque secousse dans l'industrie décentralisée renforce 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 qui ont besoin d'un espace libre.

Il était une fois, les chaînes de consortium étaient plus populaires que les chaînes publiques car elles répondaient aux besoins réglementaires de cette époque. Aujourd'hui, le déclin des chaînes de consortium signifie en réalité que se conformer à cette exigence ne reflète pas les véritables besoins des utilisateurs. Avec la perte d'utilisateurs réglementés, quel est l'intérêt des outils réglementaires ?

1. Contexte de l'événement

Le 22 mai 2025, Cetus, le plus grand échange décentralisé (DEX) de l'écosystème de la chaîne publique Sui, a subi une attaque de hacker, entraînant une chute instantanée de la liquidité, l'effondrement des prix de plusieurs paires de trading et des pertes dépassant 220 millions de dollars.

Au moment de la publication, le calendrier est le suivant :

  • Le matin du 22 mai, un hacker a attaqué Cetus, extrayant 230 millions de dollars. Cetus a suspendu d'urgence les contrats et a publié un communiqué.
  • Le 22 mai dans l'après-midi, un hacker a transféré environ 60 millions de dollars à travers les chaînes, tandis que les 162 millions de dollars restants sont toujours dans l'adresse de la chaîne Sui. Les nœuds validateurs de Sui ont rapidement agi, ajoutant l'adresse du hacker à la "Liste de Refus" et gelant les fonds.
  • Le soir du 22 mai, Sui CPO@emanabioConfirmation de tweet : Les fonds ont été gelés et les remboursements commenceront sous peu.
  • Le 23 mai, Cetus a commencé à corriger les vulnérabilités et à mettre à jour les contrats.
  • Le 24 mai, le PR open-source de Sui a expliqué que les fonds seront bientôt récupérés grâce au mécanisme d'aliasing et à la liste blanche.
  • Le 26 mai, Sui a lancé un vote de gouvernance sur la chaîne, proposant d'exécuter une mise à niveau du protocole et de transférer les actifs des hackers vers une adresse de garde.
  • Le 29 mai, les résultats du vote ont été annoncés, avec plus de 2/3 du poids des nœuds validateurs en soutien ; la mise à niveau du protocole est prête à être exécutée.
  • Du 30 mai au début juin, la mise à niveau du protocole a pris effet, le hachage de trading désigné a été exécuté et les actifs du hacker ont été "transférés légalement."

2. Principe de l'attaque

Concernant les principes des événements, l'industrie a déjà publié plusieurs déclarations. Ici, nous ne fournissons qu'un aperçu des principes fondamentaux :

Du point de vue du processus d’attaque :

L'attaquant a d'abord emprunté environ 10 024 321,28 haSUI en utilisant un prêt flash, provoquant instantanément une baisse du prix dans le pool de trading.

99,90 %. Cet ordre de vente massif a fait chuter le prix du pool cible d'environ 1,8956×10^19 à 1,8425×10^19, presque complètement.

Par la suite, l'attaquant a créé une position de liquidité sur Cetus dans une plage très étroite (limite inférieure de Tick 300000, limite supérieure 300200, avec une largeur de plage de seulement 1,00496621 %). Une plage aussi étroite amplifie l'impact des erreurs de calcul ultérieures sur la quantité de jetons requise.

Le principe de base de l’attaque :

Il existe une vulnérabilité de débordement d'entier dans la fonction get_delta_a utilisée par Cetus pour calculer le nombre requis de jetons. Un attaquant prétend intentionnellement ajouter une énorme liquidité (environ 10^37 unités), mais ne contribue en réalité qu'à hauteur de 1 jeton au contrat.

En raison de la condition de détection de débordement incorrecte de checked_shlw, le contrat a connu une troncature des bits élevés lors des calculs de décalage à gauche, ce qui a conduit le système à sous-estimer gravement le montant requis de haSUI, obtenant ainsi une énorme quantité de liquidités à un coût extrêmement bas.

Techniquement, la vulnérabilité mentionnée précédemment provient du fait que Cetus utilise des masques incorrects et des conditions de jugement dans le contrat intelligent Move, permettant à toute valeur inférieure à 0xffffffffffffffff << 192 de contourner la détection ; de plus, les données de haut ordre sont tronquées après un décalage à gauche de 64 bits, amenant le système à croire qu'il a acquis une liquidité significative avec seulement une petite quantité de tokens collectés.

Après l'incident, deux opérations officielles ont émergé : "Gel" contre "Récupérer", qui sont deux phases :

  • La phase de gel est complétée grâce à la liste de refus + consensus des nœuds ;
  • La phase de récupération nécessite des mises à niveau de protocole on-chain + un vote de la communauté + une exécution de transactions désignée pour contourner la liste noire.

3. Le mécanisme de gel de Sui

La chaîne Sui elle-même dispose d'un mécanisme spécial de liste de refus qui a permis de geler les fonds de ce hacker. De plus, le standard de token de Sui a également un modèle de "token régulé", qui inclut une fonction de gel intégrée.

Ce gel d'urgence utilise cette caractéristique : les nœuds validateurs ont rapidement ajouté les adresses liées aux fonds volés dans leurs fichiers de configuration locaux. En théorie, chaque opérateur de nœud peut modifier TransactionDenyConfig pour mettre à jour la liste noire, mais pour garantir la cohérence du réseau, la Fondation Sui, en tant que publisher de la configuration originale, a coordonné de manière centralisée.

La fondation a d'abord publié officiellement une mise à jour de configuration contenant l'adresse du hacker, et les validateurs se sont synchronisés selon la configuration par défaut, "scellant" temporairement les fonds du hacker sur la chaîne. En fait, il existe des facteurs hautement centralisés derrière cela.

Afin de secourir les victimes de fonds gelés, l'équipe Sui a rapidement lancé un patch de mécanisme de liste blanche.

Ceci est pour l'opération de transfert de fonds à l'avenir. Vous pouvez pré-construire des transactions légitimes et les enregistrer sur la liste blanche. Même si l'adresse de fonds est toujours sur la liste noire, elle peut toujours être exécutée de manière forcée.

Cette nouvelle fonctionnalité transaction_allow_list_skip_all_checks permet d'ajouter préalablement des transactions spécifiques à la "liste d'exemption", permettant à ces transactions de passer outre toutes les vérifications de sécurité, y compris les signatures, les autorisations, les listes noires, etc.

Il est important de noter que le patch de liste blanche ne saisit pas directement les actifs des hackers ; il ne fait que permettre à certaines transactions de contourner les gelons, tandis que le transfert réel des actifs nécessite toujours une signature légale ou des modules de permission système supplémentaires pour être complété.

En fait, les solutions de gel grand public dans l'industrie se produisent souvent au niveau du contrat de jeton et sont contrôlées par des signatures multiples de l'émetteur.

Prenons l'USDT émis par Tether comme exemple, son contrat dispose d'une fonction de liste noire intégrée, permettant à la société émettrice de geler les adresses non conformes, les empêchant de transférer des USDT. Ce schéma nécessite une multi-signature pour initier la demande de gel sur la chaîne, et il n'est exécuté qu'après que la multi-signature ait atteint un consensus, ce qui entraîne un délai d'exécution.

Le mécanisme de gel de Tether est efficace, mais les statistiques montrent que le processus de multi-signature a souvent des "fenêtres d'opportunité", laissant place aux criminels pour en tirer parti.

En revanche, le gel de Sui se produit au niveau du protocole sous-jacent, opéré collectivement par les nœuds validateurs, avec une vitesse beaucoup plus rapide que celle des appels de contrats réguliers.

Dans ce modèle, exécuter rapidement signifie que la gestion de ces nœuds validateurs eux-mêmes est hautement unifiée.

4. Le principe de mise en œuvre du "recyclage basé sur le transfert" de Sui.

Encore plus étonnant, Sui n'a pas seulement gelé les actifs du hacker, mais prévoit également de mettre en œuvre une mise à niveau on-chain pour "transférer" les fonds volés.

Le 27 mai, Cetus a proposé un plan de vote communautaire pour mettre à jour le protocole et envoyer les fonds gelés vers un portefeuille de garde multi-signatures. La Fondation Sui a immédiatement lancé un vote de gouvernance en chaîne.

Le 29 mai, les résultats du vote ont été annoncés, avec environ 90,9 % des validateurs pondérés soutenant la proposition. Les responsables de Sui ont annoncé qu'une fois la proposition approuvée, "tous les fonds gelés dans les deux comptes Hacker seront récupérés dans un portefeuille multi-signatures sans avoir besoin de signatures des Hackers."

Aucune signature de hacker n'est requise, quelle caractéristique unique, l'industrie de la blockchain n'a jamais eu une telle méthode de réparation.

D'après le PR officiel GitHub de Sui, il est clair que le protocole a introduit un mécanisme d'aliasing d'adresse. La mise à niveau comprend : la pré-spécification des règles d'alias dans ProtocolConfig, permettant à certaines transactions autorisées de considérer les signatures valides comme envoyées depuis des comptes de Hacker.

Spécifiquement, la liste des hachages des transactions de sauvetage à exécuter est liée à l'adresse cible (c'est-à-dire, l'adresse du Hacker). Tout exécuteur qui signe et publie ces résumés de transaction fixes est considéré comme ayant initié la transaction en tant que propriétaire valide de l'adresse du Hacker. Pour ces transactions spécifiques, le système de nœuds validateurs contournera la vérification de la liste de refus.

D'un point de vue code, Sui a ajouté la vérification suivante dans la logique de validation des transactions : lorsque une transaction est interceptée par la liste noire, le système itère sur ses signataires pour vérifier si protocol_config.is_tx_allowed_via_aliasing(sender, signer, tx_digest) est vrai.

Tant qu'il y a un signataire qui respecte la règle d'alias, la transaction marquée comme autorisée à passer ignorera les erreurs d'interception précédentes et continuera à être regroupée et exécutée normalement.

5. Opinion

160 millions, déchirant les croyances les plus profondes de l'industrie.

L'incident Cetus, de mon point de vue personnel, peut passer rapidement, mais ce modèle ne sera pas oublié, car il subvertit les fondements de l'industrie et brise le consensus traditionnel d'immutabilité dans la blockchain sous le même registre.

Dans la conception de la blockchain, les contrats sont la loi, et le code est l'arbitre.

Cependant, dans cet incident, le code a échoué, la gouvernance est intervenue et le pouvoir a prévalu, formant un schéma de "comportement de vote adjudicant les résultats du code."

La raison en est que l'appropriation directe des transactions par Sui contraste fortement avec la façon dont les blockchains mainstream gèrent les problèmes de hackers.

Ce n'est pas la première fois que l'on "manipule le consensus", mais c'est la plus silencieuse.

Historiquement:

  • L'incident de la DAO d'Ethereum en 2016 a annulé des transactions par le biais d'un hard fork pour compenser les pertes, mais cette décision a conduit à la scission d'Ethereum et d'Ethereum Classic en deux chaînes. Le processus a été très controversé, mais finalement, différents groupes ont formé différentes croyances de consensus.
  • La communauté Bitcoin a également été confrontée à des défis techniques similaires : le bug de dépassement de valeur en 2010 a été réparé d'urgence par des développeurs qui ont mis à jour les règles de consensus, effaçant complètement environ 1,84 milliard de bitcoins générés illégalement.

C'est le même modèle de hard fork, ramenant le registre à un moment avant le problème, après quoi les utilisateurs peuvent toujours décider quel système de registre continuer à utiliser.

Contrairement au hard fork de la DAO, Sui n'a pas choisi de diviser la chaîne, mais a plutôt ciblé précisément cet événement par le biais de mises à jour de protocole et d'alias de configuration. Ce faisant, Sui maintient la continuité de la chaîne et garde la plupart des règles de consensus inchangées, tout en indiquant que le protocole sous-jacent peut être utilisé pour mettre en œuvre des "opérations de sauvetage" ciblées.

Le problème est que historiquement, les "retours en arrière basés sur des forks" sont une question de choix des utilisateurs ; les "corrections basées sur le protocole" de Sui sont des décisions prises au nom de la chaîne.

Pas votre clé, pas votre pièce ? J'ai bien peur que ce ne soit plus le cas.

À long terme, cela signifie que l'idée de "Pas vos clés, pas vos pièces" est mise à mal sur la chaîne Sui : même si les utilisateurs possèdent les clés privées complètes, le réseau peut toujours empêcher le mouvement des actifs et rediriger les actifs par le biais de changements de protocole collectifs.

Si cela devient un précédent pour que la blockchain réagisse à de grands incidents de sécurité à l'avenir, ou même soit considéré comme une pratique à laquelle on peut se conformer à nouveau.

"Lorsqu'une chaîne peut enfreindre les règles de la justice, elle établit un précédent pour enfreindre n'importe quelle règle."

Une fois qu'il y a eu un "grab de fonds de bienfaisance" réussi, la prochaine fois, cela pourrait être une opération dans la "zone grise morale".

Que se passera-t-il alors ?

Le hacker a effectivement volé l'argent de l'utilisateur, alors le vote en groupe peut-il lui retirer son argent ?

Le vote est-il basé sur qui a plus d'argent (pos) ou qui a plus de gens ? Si celui qui a plus d'argent gagne, alors le producteur ultime dans l'écriture de Liu Cixin arrivera bientôt. Si celui qui a plus de gens gagne, alors la foule chaotique fera également entendre sa voix.

Dans les systèmes traditionnels, il est très normal que les gains illégaux ne soient pas protégés, et le gel et le transfert sont des opérations courantes des banques traditionnelles.

Mais d'un point de vue théorique technique, cela ne peut pas être réalisé, n'est-ce pas la racine du développement de l'industrie de la blockchain ?

Le bâton de la conformité industrielle fermente continuellement. Aujourd'hui, il peut geler et modifier les soldes des comptes des hackers, et demain, il peut effectuer des modifications arbitraires pour des facteurs géopolitiques et des facteurs de conflit. Si la chaîne devient un outil régional.

La valeur de cette industrie a également été considérablement compressée, au mieux, elle n'est qu'un autre ensemble d'un système financier moins utile.

C'est aussi la raison pour laquelle l'auteur est ferme dans l'industrie : "La blockchain a de la valeur non pas parce qu'elle ne peut pas être gelée, mais parce qu'elle ne change pas pour vous même si vous la détestez."

Avec la réglementation en hausse, la blockchain peut-elle conserver son âme ?

Il était une fois, les chaînes de consortium étaient plus populaires que les chaînes publiques car elles répondaient aux besoins réglementaires de cette époque. De nos jours, le déclin des consortiums signifie en réalité que se conformer simplement à ces besoins ne reflète pas les véritables besoins des utilisateurs. Les utilisateurs perdus à cause de la réglementation soulèvent la question des outils réglementaires nécessaires.

Du point de vue du développement industriel

"Centralisation efficace"—est-elle une étape nécessaire dans le développement de la blockchain ? Si l'objectif ultime de la décentralisation est de protéger les intérêts des utilisateurs, pouvons-nous tolérer la centralisation comme un moyen transitoire ?

Le terme "démocratie" dans le contexte de la gouvernance sur la chaîne est en réalité pondéré par les tokens. Donc, si un hacker détient une grande quantité de SUI (ou qu'un jour un DAO est piraté et que le hacker contrôle les droits de vote), peuvent-ils aussi "voter légalement pour s'exonérer" ?

En fin de compte, la valeur de la blockchain réside non pas dans le fait qu'elle puisse être gelée, mais dans le choix de ne pas le faire même lorsque le groupe a la capacité de geler.

L'avenir d'une chaîne n'est pas déterminé par son architecture technique, mais par l'ensemble des croyances qu'elle choisit de défendre.

Déclaration :

  1. Cet article est reproduit à partir de [Quatorze bactéries] Le droit d'auteur appartient à l'auteur original [Quatorze bactéries] Si vous avez des objections à la réimpression, veuillez contacter Équipe Gate LearnL'équipe le traitera dès que possible conformément aux procédures pertinentes.
  2. Avertissement : Les vues et opinions exprimées dans cet article sont uniquement celles de l'auteur et ne constituent pas de conseils en investissement.
  3. Les autres versions linguistiques de l'article sont traduites par l'équipe de Gate Learn, sauf mention contraire.GateDans ce cas, il est interdit de copier, de diffuser ou de plagier des articles traduits.

Le hacker a volé l'argent, alors Sui peut-il le voler ?

Avancé6/9/2025, 1:52:27 AM
Bien que L2 joue un rôle important dans l'innovation et l'avancement économique, une dépendance excessive à L2 peut affaiblir l'effet de réseau d'Ethereum Layer 1 (L1). L'article propose le concept de Rollup ultrasonique, qui est un design de Rollup natif combinant la disponibilité des données, l'exécution et l'ordonnancement, visant à renforcer plutôt qu'à affaiblir l'effet de réseau d'Ethereum.

Introduction

Cet incident est une victoire pour le capital, pas pour les utilisateurs, et c'est un revers pour le développement de l'industrie.

Bitcoin à gauche, Sui à droite, chaque secousse dans l'industrie décentralisée renforce 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 qui ont besoin d'un espace libre.

Il était une fois, les chaînes de consortium étaient plus populaires que les chaînes publiques car elles répondaient aux besoins réglementaires de cette époque. Aujourd'hui, le déclin des chaînes de consortium signifie en réalité que se conformer à cette exigence ne reflète pas les véritables besoins des utilisateurs. Avec la perte d'utilisateurs réglementés, quel est l'intérêt des outils réglementaires ?

1. Contexte de l'événement

Le 22 mai 2025, Cetus, le plus grand échange décentralisé (DEX) de l'écosystème de la chaîne publique Sui, a subi une attaque de hacker, entraînant une chute instantanée de la liquidité, l'effondrement des prix de plusieurs paires de trading et des pertes dépassant 220 millions de dollars.

Au moment de la publication, le calendrier est le suivant :

  • Le matin du 22 mai, un hacker a attaqué Cetus, extrayant 230 millions de dollars. Cetus a suspendu d'urgence les contrats et a publié un communiqué.
  • Le 22 mai dans l'après-midi, un hacker a transféré environ 60 millions de dollars à travers les chaînes, tandis que les 162 millions de dollars restants sont toujours dans l'adresse de la chaîne Sui. Les nœuds validateurs de Sui ont rapidement agi, ajoutant l'adresse du hacker à la "Liste de Refus" et gelant les fonds.
  • Le soir du 22 mai, Sui CPO@emanabioConfirmation de tweet : Les fonds ont été gelés et les remboursements commenceront sous peu.
  • Le 23 mai, Cetus a commencé à corriger les vulnérabilités et à mettre à jour les contrats.
  • Le 24 mai, le PR open-source de Sui a expliqué que les fonds seront bientôt récupérés grâce au mécanisme d'aliasing et à la liste blanche.
  • Le 26 mai, Sui a lancé un vote de gouvernance sur la chaîne, proposant d'exécuter une mise à niveau du protocole et de transférer les actifs des hackers vers une adresse de garde.
  • Le 29 mai, les résultats du vote ont été annoncés, avec plus de 2/3 du poids des nœuds validateurs en soutien ; la mise à niveau du protocole est prête à être exécutée.
  • Du 30 mai au début juin, la mise à niveau du protocole a pris effet, le hachage de trading désigné a été exécuté et les actifs du hacker ont été "transférés légalement."

2. Principe de l'attaque

Concernant les principes des événements, l'industrie a déjà publié plusieurs déclarations. Ici, nous ne fournissons qu'un aperçu des principes fondamentaux :

Du point de vue du processus d’attaque :

L'attaquant a d'abord emprunté environ 10 024 321,28 haSUI en utilisant un prêt flash, provoquant instantanément une baisse du prix dans le pool de trading.

99,90 %. Cet ordre de vente massif a fait chuter le prix du pool cible d'environ 1,8956×10^19 à 1,8425×10^19, presque complètement.

Par la suite, l'attaquant a créé une position de liquidité sur Cetus dans une plage très étroite (limite inférieure de Tick 300000, limite supérieure 300200, avec une largeur de plage de seulement 1,00496621 %). Une plage aussi étroite amplifie l'impact des erreurs de calcul ultérieures sur la quantité de jetons requise.

Le principe de base de l’attaque :

Il existe une vulnérabilité de débordement d'entier dans la fonction get_delta_a utilisée par Cetus pour calculer le nombre requis de jetons. Un attaquant prétend intentionnellement ajouter une énorme liquidité (environ 10^37 unités), mais ne contribue en réalité qu'à hauteur de 1 jeton au contrat.

En raison de la condition de détection de débordement incorrecte de checked_shlw, le contrat a connu une troncature des bits élevés lors des calculs de décalage à gauche, ce qui a conduit le système à sous-estimer gravement le montant requis de haSUI, obtenant ainsi une énorme quantité de liquidités à un coût extrêmement bas.

Techniquement, la vulnérabilité mentionnée précédemment provient du fait que Cetus utilise des masques incorrects et des conditions de jugement dans le contrat intelligent Move, permettant à toute valeur inférieure à 0xffffffffffffffff << 192 de contourner la détection ; de plus, les données de haut ordre sont tronquées après un décalage à gauche de 64 bits, amenant le système à croire qu'il a acquis une liquidité significative avec seulement une petite quantité de tokens collectés.

Après l'incident, deux opérations officielles ont émergé : "Gel" contre "Récupérer", qui sont deux phases :

  • La phase de gel est complétée grâce à la liste de refus + consensus des nœuds ;
  • La phase de récupération nécessite des mises à niveau de protocole on-chain + un vote de la communauté + une exécution de transactions désignée pour contourner la liste noire.

3. Le mécanisme de gel de Sui

La chaîne Sui elle-même dispose d'un mécanisme spécial de liste de refus qui a permis de geler les fonds de ce hacker. De plus, le standard de token de Sui a également un modèle de "token régulé", qui inclut une fonction de gel intégrée.

Ce gel d'urgence utilise cette caractéristique : les nœuds validateurs ont rapidement ajouté les adresses liées aux fonds volés dans leurs fichiers de configuration locaux. En théorie, chaque opérateur de nœud peut modifier TransactionDenyConfig pour mettre à jour la liste noire, mais pour garantir la cohérence du réseau, la Fondation Sui, en tant que publisher de la configuration originale, a coordonné de manière centralisée.

La fondation a d'abord publié officiellement une mise à jour de configuration contenant l'adresse du hacker, et les validateurs se sont synchronisés selon la configuration par défaut, "scellant" temporairement les fonds du hacker sur la chaîne. En fait, il existe des facteurs hautement centralisés derrière cela.

Afin de secourir les victimes de fonds gelés, l'équipe Sui a rapidement lancé un patch de mécanisme de liste blanche.

Ceci est pour l'opération de transfert de fonds à l'avenir. Vous pouvez pré-construire des transactions légitimes et les enregistrer sur la liste blanche. Même si l'adresse de fonds est toujours sur la liste noire, elle peut toujours être exécutée de manière forcée.

Cette nouvelle fonctionnalité transaction_allow_list_skip_all_checks permet d'ajouter préalablement des transactions spécifiques à la "liste d'exemption", permettant à ces transactions de passer outre toutes les vérifications de sécurité, y compris les signatures, les autorisations, les listes noires, etc.

Il est important de noter que le patch de liste blanche ne saisit pas directement les actifs des hackers ; il ne fait que permettre à certaines transactions de contourner les gelons, tandis que le transfert réel des actifs nécessite toujours une signature légale ou des modules de permission système supplémentaires pour être complété.

En fait, les solutions de gel grand public dans l'industrie se produisent souvent au niveau du contrat de jeton et sont contrôlées par des signatures multiples de l'émetteur.

Prenons l'USDT émis par Tether comme exemple, son contrat dispose d'une fonction de liste noire intégrée, permettant à la société émettrice de geler les adresses non conformes, les empêchant de transférer des USDT. Ce schéma nécessite une multi-signature pour initier la demande de gel sur la chaîne, et il n'est exécuté qu'après que la multi-signature ait atteint un consensus, ce qui entraîne un délai d'exécution.

Le mécanisme de gel de Tether est efficace, mais les statistiques montrent que le processus de multi-signature a souvent des "fenêtres d'opportunité", laissant place aux criminels pour en tirer parti.

En revanche, le gel de Sui se produit au niveau du protocole sous-jacent, opéré collectivement par les nœuds validateurs, avec une vitesse beaucoup plus rapide que celle des appels de contrats réguliers.

Dans ce modèle, exécuter rapidement signifie que la gestion de ces nœuds validateurs eux-mêmes est hautement unifiée.

4. Le principe de mise en œuvre du "recyclage basé sur le transfert" de Sui.

Encore plus étonnant, Sui n'a pas seulement gelé les actifs du hacker, mais prévoit également de mettre en œuvre une mise à niveau on-chain pour "transférer" les fonds volés.

Le 27 mai, Cetus a proposé un plan de vote communautaire pour mettre à jour le protocole et envoyer les fonds gelés vers un portefeuille de garde multi-signatures. La Fondation Sui a immédiatement lancé un vote de gouvernance en chaîne.

Le 29 mai, les résultats du vote ont été annoncés, avec environ 90,9 % des validateurs pondérés soutenant la proposition. Les responsables de Sui ont annoncé qu'une fois la proposition approuvée, "tous les fonds gelés dans les deux comptes Hacker seront récupérés dans un portefeuille multi-signatures sans avoir besoin de signatures des Hackers."

Aucune signature de hacker n'est requise, quelle caractéristique unique, l'industrie de la blockchain n'a jamais eu une telle méthode de réparation.

D'après le PR officiel GitHub de Sui, il est clair que le protocole a introduit un mécanisme d'aliasing d'adresse. La mise à niveau comprend : la pré-spécification des règles d'alias dans ProtocolConfig, permettant à certaines transactions autorisées de considérer les signatures valides comme envoyées depuis des comptes de Hacker.

Spécifiquement, la liste des hachages des transactions de sauvetage à exécuter est liée à l'adresse cible (c'est-à-dire, l'adresse du Hacker). Tout exécuteur qui signe et publie ces résumés de transaction fixes est considéré comme ayant initié la transaction en tant que propriétaire valide de l'adresse du Hacker. Pour ces transactions spécifiques, le système de nœuds validateurs contournera la vérification de la liste de refus.

D'un point de vue code, Sui a ajouté la vérification suivante dans la logique de validation des transactions : lorsque une transaction est interceptée par la liste noire, le système itère sur ses signataires pour vérifier si protocol_config.is_tx_allowed_via_aliasing(sender, signer, tx_digest) est vrai.

Tant qu'il y a un signataire qui respecte la règle d'alias, la transaction marquée comme autorisée à passer ignorera les erreurs d'interception précédentes et continuera à être regroupée et exécutée normalement.

5. Opinion

160 millions, déchirant les croyances les plus profondes de l'industrie.

L'incident Cetus, de mon point de vue personnel, peut passer rapidement, mais ce modèle ne sera pas oublié, car il subvertit les fondements de l'industrie et brise le consensus traditionnel d'immutabilité dans la blockchain sous le même registre.

Dans la conception de la blockchain, les contrats sont la loi, et le code est l'arbitre.

Cependant, dans cet incident, le code a échoué, la gouvernance est intervenue et le pouvoir a prévalu, formant un schéma de "comportement de vote adjudicant les résultats du code."

La raison en est que l'appropriation directe des transactions par Sui contraste fortement avec la façon dont les blockchains mainstream gèrent les problèmes de hackers.

Ce n'est pas la première fois que l'on "manipule le consensus", mais c'est la plus silencieuse.

Historiquement:

  • L'incident de la DAO d'Ethereum en 2016 a annulé des transactions par le biais d'un hard fork pour compenser les pertes, mais cette décision a conduit à la scission d'Ethereum et d'Ethereum Classic en deux chaînes. Le processus a été très controversé, mais finalement, différents groupes ont formé différentes croyances de consensus.
  • La communauté Bitcoin a également été confrontée à des défis techniques similaires : le bug de dépassement de valeur en 2010 a été réparé d'urgence par des développeurs qui ont mis à jour les règles de consensus, effaçant complètement environ 1,84 milliard de bitcoins générés illégalement.

C'est le même modèle de hard fork, ramenant le registre à un moment avant le problème, après quoi les utilisateurs peuvent toujours décider quel système de registre continuer à utiliser.

Contrairement au hard fork de la DAO, Sui n'a pas choisi de diviser la chaîne, mais a plutôt ciblé précisément cet événement par le biais de mises à jour de protocole et d'alias de configuration. Ce faisant, Sui maintient la continuité de la chaîne et garde la plupart des règles de consensus inchangées, tout en indiquant que le protocole sous-jacent peut être utilisé pour mettre en œuvre des "opérations de sauvetage" ciblées.

Le problème est que historiquement, les "retours en arrière basés sur des forks" sont une question de choix des utilisateurs ; les "corrections basées sur le protocole" de Sui sont des décisions prises au nom de la chaîne.

Pas votre clé, pas votre pièce ? J'ai bien peur que ce ne soit plus le cas.

À long terme, cela signifie que l'idée de "Pas vos clés, pas vos pièces" est mise à mal sur la chaîne Sui : même si les utilisateurs possèdent les clés privées complètes, le réseau peut toujours empêcher le mouvement des actifs et rediriger les actifs par le biais de changements de protocole collectifs.

Si cela devient un précédent pour que la blockchain réagisse à de grands incidents de sécurité à l'avenir, ou même soit considéré comme une pratique à laquelle on peut se conformer à nouveau.

"Lorsqu'une chaîne peut enfreindre les règles de la justice, elle établit un précédent pour enfreindre n'importe quelle règle."

Une fois qu'il y a eu un "grab de fonds de bienfaisance" réussi, la prochaine fois, cela pourrait être une opération dans la "zone grise morale".

Que se passera-t-il alors ?

Le hacker a effectivement volé l'argent de l'utilisateur, alors le vote en groupe peut-il lui retirer son argent ?

Le vote est-il basé sur qui a plus d'argent (pos) ou qui a plus de gens ? Si celui qui a plus d'argent gagne, alors le producteur ultime dans l'écriture de Liu Cixin arrivera bientôt. Si celui qui a plus de gens gagne, alors la foule chaotique fera également entendre sa voix.

Dans les systèmes traditionnels, il est très normal que les gains illégaux ne soient pas protégés, et le gel et le transfert sont des opérations courantes des banques traditionnelles.

Mais d'un point de vue théorique technique, cela ne peut pas être réalisé, n'est-ce pas la racine du développement de l'industrie de la blockchain ?

Le bâton de la conformité industrielle fermente continuellement. Aujourd'hui, il peut geler et modifier les soldes des comptes des hackers, et demain, il peut effectuer des modifications arbitraires pour des facteurs géopolitiques et des facteurs de conflit. Si la chaîne devient un outil régional.

La valeur de cette industrie a également été considérablement compressée, au mieux, elle n'est qu'un autre ensemble d'un système financier moins utile.

C'est aussi la raison pour laquelle l'auteur est ferme dans l'industrie : "La blockchain a de la valeur non pas parce qu'elle ne peut pas être gelée, mais parce qu'elle ne change pas pour vous même si vous la détestez."

Avec la réglementation en hausse, la blockchain peut-elle conserver son âme ?

Il était une fois, les chaînes de consortium étaient plus populaires que les chaînes publiques car elles répondaient aux besoins réglementaires de cette époque. De nos jours, le déclin des consortiums signifie en réalité que se conformer simplement à ces besoins ne reflète pas les véritables besoins des utilisateurs. Les utilisateurs perdus à cause de la réglementation soulèvent la question des outils réglementaires nécessaires.

Du point de vue du développement industriel

"Centralisation efficace"—est-elle une étape nécessaire dans le développement de la blockchain ? Si l'objectif ultime de la décentralisation est de protéger les intérêts des utilisateurs, pouvons-nous tolérer la centralisation comme un moyen transitoire ?

Le terme "démocratie" dans le contexte de la gouvernance sur la chaîne est en réalité pondéré par les tokens. Donc, si un hacker détient une grande quantité de SUI (ou qu'un jour un DAO est piraté et que le hacker contrôle les droits de vote), peuvent-ils aussi "voter légalement pour s'exonérer" ?

En fin de compte, la valeur de la blockchain réside non pas dans le fait qu'elle puisse être gelée, mais dans le choix de ne pas le faire même lorsque le groupe a la capacité de geler.

L'avenir d'une chaîne n'est pas déterminé par son architecture technique, mais par l'ensemble des croyances qu'elle choisit de défendre.

Déclaration :

  1. Cet article est reproduit à partir de [Quatorze bactéries] Le droit d'auteur appartient à l'auteur original [Quatorze bactéries] Si vous avez des objections à la réimpression, veuillez contacter Équipe Gate LearnL'équipe le traitera dès que possible conformément aux procédures pertinentes.
  2. Avertissement : Les vues et opinions exprimées dans cet article sont uniquement celles de l'auteur et ne constituent pas de conseils en investissement.
  3. Les autres versions linguistiques de l'article sont traduites par l'équipe de Gate Learn, sauf mention contraire.GateDans ce cas, il est interdit de copier, de diffuser ou de plagier des articles traduits.
Lancez-vous
Inscrivez-vous et obtenez un bon de
100$
!