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 ?
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 :
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 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.
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.
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.
Historiquement:
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.
À 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."
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.
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 ?
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 :
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 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.
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.
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.
Historiquement:
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.
À 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."
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.