L'événement de "gel" de l'adresse du hacker sur le réseau Sui suscite des controverses

Récemment, après qu'un certain protocole a été attaqué par un hacker, le réseau Sui a pris une mesure qui a suscité une large attention : il a "gelé" l'adresse du hacker, récupérant environ 160 millions de dollars d'actifs. Cet acte a déclenché de vives discussions sur la nature de la décentralisation. Analysons cet événement d'un point de vue technique.

Après que le Hacker a réussi à mener l'attaque, il a rapidement transféré une partie des actifs comme l'USDC vers d'autres réseaux de blockchain via un pont inter-chaînes. Cette partie des fonds est maintenant irrécupérable, car une fois qu'ils ont quitté l'écosystème Sui, les validateurs ne peuvent plus intervenir. Cependant, une quantité considérable de fonds volés reste sous le contrôle du Hacker dans une Adresse Sui, devenant ainsi la cible des "fonds gelés".

Selon la déclaration officielle, un grand nombre de validateurs ont identifié les adresses des fonds volés et ont commencé à ignorer les transactions sur ces adresses. Ce mécanisme de "gel" est principalement réalisé par les deux aspects suivants :

1. Filtrage des transactions au niveau des validateurs :

   • Les validateurs ignorent directement les transactions des adresses de hacker à l'étape du pool de transactions.
   • Ces transactions sont techniquement valides, mais ne sont pas incluses dans la chaîne.
   • Les fonds du Hacker sont donc "assignés à résidence" dans l'Adresse

2. Caractéristiques du modèle d'objet Move language :

   • Le transfert d'actifs doit être enregistré sur la chaîne : bien que le Hacker contrôle une grande quantité d'actifs dans l'Adresse, le transfert de ces objets USDC, SUI, etc. doit être initié par une transaction et confirmé par les validateurs.
   • Les validateurs ont le pouvoir de décision : si un validateur refuse de packager, l'objet ne peut pas être déplacé
   • Résultat : le hacker "possède" ces actifs en apparence, mais ne peut pas les utiliser.

Cette situation est similaire à celle de posséder une carte bancaire, mais où tous les distributeurs automatiques refusent de vous servir. Les fonds sont sur la carte, mais ne peuvent pas être retirés. Sous la surveillance et l'intervention continues des nœuds de validation Sui, les jetons SUI et autres dans l'adresse du hacker ne pourront pas circuler, ces fonds volés étant en réalité dans un état de "destruction", ce qui pourrait objectivement engendrer un effet de "déflation".

En plus de la coordination temporaire des validateurs, Sui pourrait avoir préconfiguré une fonction de liste de refus au niveau du système. Si cela s'avère vrai, les parties concernées pourraient ajouter l'adresse du hacker à la liste de refus du système, et les validateurs exécuteraient alors cette règle système en refusant de traiter les transactions des adresses figurant sur la liste noire.

Quelle que soit la méthode utilisée, il est nécessaire que la majorité des validateurs agissent de manière cohérente. Cela met en évidence une concentration excessive du pouvoir au sein du réseau de validateurs de Sui, où quelques nœuds peuvent contrôler les décisions clés du réseau. Il convient de noter que le problème de la concentration des validateurs n'est pas unique à Sui, car d'Ethereum à d'autres réseaux PoS, tous font face à des risques similaires de concentration des validateurs, Sui ne faisant que rendre ce problème plus évident.

Ce qui est encore plus déroutant, c'est que les autorités de Sui ont indiqué qu'elles prévoient de restituer les fonds congelés au pool de liquidités. Cependant, si, comme il est dit, les validateurs "ont refusé d'emballer les transactions", ces fonds ne devraient théoriquement pas pouvoir être déplacés. Comment Sui compte-t-elle réaliser le remboursement des fonds ? Cela soulève davantage de questions sur les caractéristiques de décentralisation de Sui.

Avant la publication des détails spécifiques, il est nécessaire de discuter des compromis liés à la décentralisation :

Les mesures d'intervention en cas d'urgence, est-ce toujours négatif de sacrifier un certain degré de décentralisation ? Face à une attaque de hacker, le fait que tout le réseau ne fasse rien est-il vraiment conforme aux attentes des utilisateurs ?

Il est compréhensible que les utilisateurs ne souhaitent pas que leurs fonds tombent entre les mains d'un Hacker. Cependant, la plus grande préoccupation soulevée par cette mesure est la "subjectivisation" des normes de gel : comment définir les "fonds volés" ? Qui établit les normes ? Où se situe la limite ? Aujourd'hui, on gèle un Hacker, demain on pourrait geler qui ? Une fois ce précédent établi, la valeur fondamentale d'anti-censure des chaînes de blocs sera gravement menacée, ce qui entraînera inévitablement une diminution de la confiance des utilisateurs.

La décentralisation n'est pas un concept binaire. Sui a choisi un point d'équilibre spécifique entre la protection des utilisateurs et la décentralisation. La question clé réside dans le manque de mécanismes de gouvernance transparents et de normes de frontière claires.

À ce stade, la plupart des projets blockchain effectuent des compromis similaires. Mais les utilisateurs ont le droit de connaître la vérité et ne doivent pas être trompés par l'étiquette "entièrement décentralisé". Cet événement offre sans aucun doute à l'ensemble de l'industrie une occasion de réflexion approfondie sur la manière de trouver un meilleur équilibre entre sécurité, efficacité et décentralisation.