Croyance ferme après une crise de sécurité : pourquoi SUI a-t-il toujours un potentiel de hausse à long terme ?
1. Une réaction en chaîne provoquée par une attaque.
Le 22 mai 2025, le protocole AMM de premier plan déployé sur le réseau SUI, Cetus, a été victime d'une attaque de hacker. L'attaquant a exploité une vulnérabilité logique liée à un "problème de débordement d'entier" pour lancer une manipulation précise, entraînant une perte de plus de 200 millions de dollars d'actifs. Cet événement est non seulement l'un des incidents de sécurité les plus importants dans le domaine de la DeFi cette année, mais il représente également la plus destructive des attaques de hacker depuis le lancement du réseau principal SUI.
Selon les données, la TVL totale de SUI a chuté de plus de 330 millions de dollars le jour de l'attaque, et le montant verrouillé par le protocole Cetus a même disparu instantanément de 84 %, tombant à 38 millions de dollars. De plus, plusieurs jetons populaires sur SUI ont connu une chute de 76 % à 97 % en seulement une heure, suscitant une large préoccupation du marché concernant la sécurité de SUI et la stabilité de son écosystème.
Mais après cette onde de choc, l'écosystème SUI a montré une grande résilience et capacité de récupération. Bien que l'incident Cetus ait provoqué une fluctuation de la confiance à court terme, les fonds sur la chaîne et l'activité des utilisateurs n'ont pas subi de déclin durable, mais ont plutôt incité l'ensemble de l'écosystème à accorder une attention significative à la sécurité, à la construction d'infrastructures et à la qualité des projets.
Cet article se concentrera sur les raisons de cet incident d'attaque, le mécanisme de consensus des nœuds de SUI, la sécurité du langage MOVE et le développement de l'écosystème de SUI, en passant en revue l'écosystème actuel de cette blockchain qui en est encore au stade précoce de son développement, et en explorant son potentiel de développement futur.
2. Analyse des causes de l'attaque de l'événement Cetus
2.1 Processus de mise en œuvre de l'attaque
Selon l'analyse technique de l'équipe de sécurité sur l'incident d'attaque de Cetus, les hackers ont réussi à exploiter une vulnérabilité clé d'overflow arithmétique dans le protocole, en utilisant des prêts flash, une manipulation de prix précise et des défauts de contrat, pour voler plus de 200 millions de dollars d'actifs numériques en peu de temps. Le chemin de l'attaque peut être divisé en trois grandes étapes :
①Lancer un prêt flash, manipuler les prix
Les hackers ont d'abord utilisé un échange instantané de 10 milliards de haSUI avec un slippage maximal, empruntant d'énormes fonds pour manipuler les prix.
Le prêt éclair permet aux utilisateurs d'emprunter et de rembourser des fonds dans une seule transaction, ne nécessitant que le paiement de frais, avec des caractéristiques de levier élevé, de faible risque et de faible coût. Des hackers ont utilisé ce mécanisme pour faire chuter les prix du marché en peu de temps et les contrôler avec précision dans une fourchette très étroite.
Ensuite, l'attaquant se prépare à créer une position de liquidité extrêmement étroite, en définissant précisément la plage de prix entre l'offre la plus basse de 300 000 et le prix le plus élevé de 300 200, avec une largeur de prix de seulement 1.00496621 %.
Grâce à la méthode ci-dessus, les hackers ont réussi à manipuler le prix de haSUI en utilisant une quantité suffisamment importante de jetons et une énorme liquidité. Par la suite, ils ont également manipulé plusieurs jetons sans valeur réelle.
② Ajouter de la liquidité
L'attaquant crée une position de liquidité étroite, déclare ajouter de la liquidité, mais en raison d'une vulnérabilité dans la fonction checked_shlw, il ne reçoit finalement qu'un seul jeton.
C'est essentiellement dû à deux raisons :
La configuration du masque est trop large : équivalent à une limite d'ajout de liquidité extrêmement élevée, rendant les vérifications des entrées utilisateur dans le contrat pratiquement inutiles. Les hackers contournent la détection de débordement en configurant des paramètres anormaux, construisant des entrées qui sont toujours inférieures à cette limite.
Débordement de données tronqué : lors de l'exécution de l'opération de décalage n << 64 sur la valeur n, un débordement de données s'est produit en raison du déplacement dépassant la largeur de bit efficace du type de données uint256 (256 bits). La partie supérieure débordée a été automatiquement abandonnée, ce qui a entraîné un résultat de calcul bien inférieur aux attentes, conduisant ainsi le système à sous-estimer le nombre de haSUI requis pour l'échange. Le résultat final du calcul est d'environ moins de 1, mais comme il s'agit d'un arrondi vers le haut, le résultat final est égal à 1, ce qui signifie que le hacker n'a besoin d'ajouter qu'un seul token pour obtenir une énorme liquidité.
③ Retirer la liquidité
Effectuer le remboursement d'un prêt éclair, tout en conservant d'énormes bénéfices. Finalement, retirer des actifs token d'une valeur totale de plusieurs centaines de millions de dollars de plusieurs pools de liquidités.
La situation de perte de fonds est grave, l'attaque a entraîné le vol des actifs suivants :
12,9 millions de SUI (environ 5,4 millions de dollars américains)
6000万美元USDC
4,9 millions de dollars Haedal Staked SUI
19,5 millions de dollars TOILET
D'autres tokens comme HIPPO et LOFI ont chuté de 75 à 80 %, la liquidité étant épuisée.
2.2 Causes et caractéristiques de la vulnérabilité
Les vulnérabilités de Cetus présentent trois caractéristiques :
Coût de réparation extrêmement faible : d'une part, la cause fondamentale de l'incident Cetus est une négligence dans la bibliothèque mathématique de Cetus, et non une erreur dans le mécanisme de prix du protocole ou une erreur dans l'architecture sous-jacente. D'autre part, la vulnérabilité est limitée à Cetus lui-même et n'est pas liée au code de SUI. La racine de la vulnérabilité réside dans un jugement de condition de frontière, il suffit de modifier deux lignes de code pour éliminer complètement le risque ; une fois la réparation terminée, elle peut être déployée immédiatement sur le réseau principal, assurant que la logique des contrats ultérieurs est complète et éliminant cette vulnérabilité.
Haute dissimulation : le contrat fonctionne de manière stable et sans défaut depuis deux ans, avec plusieurs audits réalisés, mais aucune vulnérabilité n'a été trouvée, la principale raison étant que la bibliothèque Integer_Mate utilisée pour les calculs mathématiques n'a pas été incluse dans le champ d'audit.
Les hackers utilisent des valeurs extrêmes pour construire des intervalles de transaction précis, créant des scénarios extrêmement rares avec une liquidité très élevée, ce qui déclenche une logique anormale, indiquant que ce type de problème est difficile à détecter par des tests ordinaires. Ces problèmes se situent souvent dans des zones d'ombre dans la perception des gens, c'est pourquoi ils restent cachés pendant longtemps avant d'être découverts.
Ce n'est pas un problème propre à Move :
Move est supérieur à de nombreux langages de contrats intelligents en matière de sécurité des ressources et de vérification des types, il intègre une détection natale des problèmes de débordement d'entiers dans des scénarios courants. Ce débordement est survenu parce que, lors de l'ajout de liquidités, une mauvaise valeur a d'abord été utilisée pour le contrôle de la limite supérieure lors du calcul du nombre de jetons requis, et un décalage binaire a été utilisé à la place de l'opération de multiplication conventionnelle. Dans Move, si l'on effectue des opérations d'addition, de soustraction, de multiplication ou de division conventionnelles, un contrôle de débordement est automatiquement effectué, évitant ainsi ce problème de troncature de bits élevés.
Des vulnérabilités similaires se sont également produites dans d'autres langages (comme Solidity, Rust), et ont même été plus facilement exploitées en raison de leur manque de protection contre les débordements d'entiers ; avant les mises à jour de version de Solidity, la vérification des débordements était très faible. Dans le passé, il y a eu des débordements d'addition, de soustraction, de multiplication, etc., dont la cause directe était que le résultat des opérations dépassait la plage. Par exemple, les vulnérabilités des contrats intelligents BEC et SMT en langage Solidity ont contourné les instructions de vérification dans le contrat grâce à des paramètres soigneusement construits, permettant ainsi des transferts excessifs pour mener des attaques.
3. Mécanisme de consensus de SUI
3.1 Introduction au mécanisme de consensus SUI
Aperçu :
SUI adopte un cadre de preuve d'enjeu déléguée (DeleGated Proof of Stake, abrégé DPoS). Bien que le mécanisme DPoS puisse augmenter le débit des transactions, il ne peut pas offrir un niveau de décentralisation aussi élevé que le PoW (preuve de travail). Par conséquent, le degré de décentralisation de SUI est relativement faible, le seuil de gouvernance est relativement élevé, et il est difficile pour les utilisateurs ordinaires d'influencer directement la gouvernance du réseau.
Nombre moyen de validateurs : 106
Durée moyenne d'Epoch : 24 heures
Mécanisme de processus :
Délégation de droits : les utilisateurs ordinaires n'ont pas besoin de faire fonctionner un nœud eux-mêmes, il leur suffit de mettre en jeu leur SUI et de le déléguer à un validateur candidat pour participer à la garantie de la sécurité du réseau et à la répartition des récompenses. Ce mécanisme peut réduire le seuil de participation pour les utilisateurs ordinaires, leur permettant de participer au consensus du réseau en "employant" des validateurs de confiance. C'est également un grand avantage du DPoS par rapport au PoS traditionnel.
Représente le tour de production de blocs : un petit nombre de validateurs sélectionnés produisent des blocs dans un ordre fixe ou aléatoire, ce qui améliore la vitesse de confirmation et augmente le TPS.
Élection dynamique : à la fin de chaque cycle de vote, une rotation dynamique est effectuée en fonction du poids des votes pour réélire l'ensemble des validateurs, garantissant ainsi la vitalité des nœuds, la cohérence des intérêts et la décentralisation.
Avantages de DPoS :
Haute efficacité : Grâce à un nombre contrôlable de nœuds de production de blocs, le réseau peut compléter la confirmation en millisecondes, répondant ainsi aux besoins élevés en TPS.
Coût réduit : moins de nœuds participant au consensus, la bande passante réseau et les ressources de calcul nécessaires pour la synchronisation des informations et l'agrégation des signatures sont considérablement réduites. Cela réduit les coûts matériels et opérationnels, diminue les exigences en matière de puissance de calcul et entraîne des coûts plus faibles. Cela permet finalement d'atteindre des frais d'utilisateur plus bas.
Haute sécurité : le mécanisme de mise en jeu et de délégation amplifie les coûts et les risques d'attaque ; associé au mécanisme de confiscation sur la chaîne, il permet de réprimer efficacement les comportements malveillants.
En même temps, dans le mécanisme de consensus de SUI, un algorithme basé sur le BFT (tolérance aux pannes byzantines) est utilisé, exigeant qu'au moins deux tiers des votes des validateurs s'accordent pour confirmer une transaction. Ce mécanisme garantit que même si quelques nœuds agissent malicieusement, le réseau peut rester sûr et fonctionner efficacement. Pour toute mise à niveau ou décision majeure, il est également nécessaire d'obtenir plus des deux tiers des votes pour mettre en œuvre.
En essence, le DPoS est en réalité une sorte de compromis dans le triangle impossible, réalisant un compromis entre décentralisation et efficacité. Le DPoS choisit de réduire le nombre de nœuds de validation actifs pour obtenir de meilleures performances dans le "triangle impossible" sécurité-décente-élargissement, renonçant à un certain degré de décentralisation complète par rapport au PoS pur ou au PoW, mais améliorant considérablement le débit du réseau et la vitesse des transactions.
3.2 La performance de SUI lors de cette attaque
Mécanisme de gel 3.2.1 en fonctionnement
Dans cet événement, SUI a rapidement gelé les adresses liées à l'attaquant.
D'un point de vue code, cela empêche les transactions de transfert d'être empaquetées sur la chaîne. Les nœuds de validation sont les composants clés de la blockchain SUI, responsables de la validation des transactions et de l'exécution des règles du protocole. En ignorant collectivement les transactions liées aux attaquants, ces validateurs mettent en œuvre un mécanisme similaire au gel de compte dans la finance traditionnelle au niveau du consensus.
SUI dispose d'un mécanisme de liste de refus (deny list) intégré, qui est une fonction de liste noire permettant d'empêcher toute transaction impliquant des adresses répertoriées. Étant donné que cette fonctionnalité est déjà présente dans le client, lorsque l'attaque se produit
SUI peut immédiatement geler l'adresse des hackers. Sans cette fonctionnalité, même si SUI n'a que 113 validateurs, il est difficile de coordonner tous les validateurs un par un dans un court laps de temps.
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. Toute personne exécutant un nœud peut éditer ce fichier, le recharger à chaud ou redémarrer le nœud et mettre à jour la liste. En apparence, chaque validateur semble exprimer librement ses valeurs.
En réalité, pour garantir la cohérence et l'efficacité des politiques de sécurité, la mise à jour de cette configuration clé est généralement coordonnée. Étant donné qu'il s'agit d'une "mise à jour urgente poussée par l'équipe", c'est essentiellement la fondation (ou ses développeurs autorisés) qui établit et met à jour cette liste de refus.
Publier une liste noire, théoriquement les validateurs peuvent choisir s'ils souhaitent l'adopter ------ mais en pratique, la plupart des gens l'adoptent automatiquement par défaut. Ainsi, bien que cette fonctionnalité protège les fonds des utilisateurs, elle présente en réalité un certain degré de centralisation.
3.2.3 L'essence de la fonction de liste noire
La fonction de liste noire n'est en réalité pas une logique de niveau protocolaire, mais plutôt une couche de sécurité supplémentaire destinée à faire face aux situations imprévues et à garantir la sécurité des fonds des utilisateurs.
Il s'agit essentiellement d'un mécanisme de garantie de sécurité. Semblable à une "chaîne de sécurité" attachée à la porte, elle ne s'active que pour ceux qui souhaitent s'introduire chez vous, c'est-à-dire pour ceux qui souhaitent nuire au protocole. Pour l'utilisateur :
Pour les gros investisseurs, principaux fournisseurs de liquidités, le protocole veut avant tout garantir la sécurité des fonds, car en réalité, les données on-chain TVL sont entièrement fournies par les principaux gros investisseurs. Pour que le protocole se développe durablement, il est impératif de prioriser la sécurité.
Pour les petits investisseurs, contributeurs à l'activité de l'écosystème, de puissants soutiens à la co-construction technique et communautaire. Les porteurs de projets espèrent également attirer des petits investisseurs pour co-construire, afin de perfectionner progressivement l'écosystème et d'améliorer le taux de rétention. Et en ce qui concerne le domaine de la defi, la priorité est la plus importante.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
14 J'aime
Récompense
14
4
Partager
Commentaire
0/400
LiquidityOracle
· Il y a 7h
chute... quand est-ce que ça va s'arrêter?
Voir l'originalRépondre0
SatoshiNotNakamoto
· Il y a 21h
Tout noir et marche avec assurance
Voir l'originalRépondre0
PuzzledScholar
· Il y a 21h
Ne paniquez pas, c'est ce qu'on appelle une hausse par short squeeze.
Voir l'originalRépondre0
ImpermanentLossFan
· Il y a 21h
Encore un autre site où l'on prend les gens pour des idiots !
Résilience de l'écosystème SUI : Analyse de l'incident d'attaque de Cetus et discussion sur le potentiel de développement futur
Croyance ferme après une crise de sécurité : pourquoi SUI a-t-il toujours un potentiel de hausse à long terme ?
1. Une réaction en chaîne provoquée par une attaque.
Le 22 mai 2025, le protocole AMM de premier plan déployé sur le réseau SUI, Cetus, a été victime d'une attaque de hacker. L'attaquant a exploité une vulnérabilité logique liée à un "problème de débordement d'entier" pour lancer une manipulation précise, entraînant une perte de plus de 200 millions de dollars d'actifs. Cet événement est non seulement l'un des incidents de sécurité les plus importants dans le domaine de la DeFi cette année, mais il représente également la plus destructive des attaques de hacker depuis le lancement du réseau principal SUI.
Selon les données, la TVL totale de SUI a chuté de plus de 330 millions de dollars le jour de l'attaque, et le montant verrouillé par le protocole Cetus a même disparu instantanément de 84 %, tombant à 38 millions de dollars. De plus, plusieurs jetons populaires sur SUI ont connu une chute de 76 % à 97 % en seulement une heure, suscitant une large préoccupation du marché concernant la sécurité de SUI et la stabilité de son écosystème.
Mais après cette onde de choc, l'écosystème SUI a montré une grande résilience et capacité de récupération. Bien que l'incident Cetus ait provoqué une fluctuation de la confiance à court terme, les fonds sur la chaîne et l'activité des utilisateurs n'ont pas subi de déclin durable, mais ont plutôt incité l'ensemble de l'écosystème à accorder une attention significative à la sécurité, à la construction d'infrastructures et à la qualité des projets.
Cet article se concentrera sur les raisons de cet incident d'attaque, le mécanisme de consensus des nœuds de SUI, la sécurité du langage MOVE et le développement de l'écosystème de SUI, en passant en revue l'écosystème actuel de cette blockchain qui en est encore au stade précoce de son développement, et en explorant son potentiel de développement futur.
2. Analyse des causes de l'attaque de l'événement Cetus
2.1 Processus de mise en œuvre de l'attaque
Selon l'analyse technique de l'équipe de sécurité sur l'incident d'attaque de Cetus, les hackers ont réussi à exploiter une vulnérabilité clé d'overflow arithmétique dans le protocole, en utilisant des prêts flash, une manipulation de prix précise et des défauts de contrat, pour voler plus de 200 millions de dollars d'actifs numériques en peu de temps. Le chemin de l'attaque peut être divisé en trois grandes étapes :
①Lancer un prêt flash, manipuler les prix
Les hackers ont d'abord utilisé un échange instantané de 10 milliards de haSUI avec un slippage maximal, empruntant d'énormes fonds pour manipuler les prix.
Le prêt éclair permet aux utilisateurs d'emprunter et de rembourser des fonds dans une seule transaction, ne nécessitant que le paiement de frais, avec des caractéristiques de levier élevé, de faible risque et de faible coût. Des hackers ont utilisé ce mécanisme pour faire chuter les prix du marché en peu de temps et les contrôler avec précision dans une fourchette très étroite.
Ensuite, l'attaquant se prépare à créer une position de liquidité extrêmement étroite, en définissant précisément la plage de prix entre l'offre la plus basse de 300 000 et le prix le plus élevé de 300 200, avec une largeur de prix de seulement 1.00496621 %.
Grâce à la méthode ci-dessus, les hackers ont réussi à manipuler le prix de haSUI en utilisant une quantité suffisamment importante de jetons et une énorme liquidité. Par la suite, ils ont également manipulé plusieurs jetons sans valeur réelle.
② Ajouter de la liquidité
L'attaquant crée une position de liquidité étroite, déclare ajouter de la liquidité, mais en raison d'une vulnérabilité dans la fonction checked_shlw, il ne reçoit finalement qu'un seul jeton.
C'est essentiellement dû à deux raisons :
La configuration du masque est trop large : équivalent à une limite d'ajout de liquidité extrêmement élevée, rendant les vérifications des entrées utilisateur dans le contrat pratiquement inutiles. Les hackers contournent la détection de débordement en configurant des paramètres anormaux, construisant des entrées qui sont toujours inférieures à cette limite.
Débordement de données tronqué : lors de l'exécution de l'opération de décalage n << 64 sur la valeur n, un débordement de données s'est produit en raison du déplacement dépassant la largeur de bit efficace du type de données uint256 (256 bits). La partie supérieure débordée a été automatiquement abandonnée, ce qui a entraîné un résultat de calcul bien inférieur aux attentes, conduisant ainsi le système à sous-estimer le nombre de haSUI requis pour l'échange. Le résultat final du calcul est d'environ moins de 1, mais comme il s'agit d'un arrondi vers le haut, le résultat final est égal à 1, ce qui signifie que le hacker n'a besoin d'ajouter qu'un seul token pour obtenir une énorme liquidité.
③ Retirer la liquidité
Effectuer le remboursement d'un prêt éclair, tout en conservant d'énormes bénéfices. Finalement, retirer des actifs token d'une valeur totale de plusieurs centaines de millions de dollars de plusieurs pools de liquidités.
La situation de perte de fonds est grave, l'attaque a entraîné le vol des actifs suivants :
12,9 millions de SUI (environ 5,4 millions de dollars américains)
6000万美元USDC
4,9 millions de dollars Haedal Staked SUI
19,5 millions de dollars TOILET
D'autres tokens comme HIPPO et LOFI ont chuté de 75 à 80 %, la liquidité étant épuisée.
2.2 Causes et caractéristiques de la vulnérabilité
Les vulnérabilités de Cetus présentent trois caractéristiques :
Coût de réparation extrêmement faible : d'une part, la cause fondamentale de l'incident Cetus est une négligence dans la bibliothèque mathématique de Cetus, et non une erreur dans le mécanisme de prix du protocole ou une erreur dans l'architecture sous-jacente. D'autre part, la vulnérabilité est limitée à Cetus lui-même et n'est pas liée au code de SUI. La racine de la vulnérabilité réside dans un jugement de condition de frontière, il suffit de modifier deux lignes de code pour éliminer complètement le risque ; une fois la réparation terminée, elle peut être déployée immédiatement sur le réseau principal, assurant que la logique des contrats ultérieurs est complète et éliminant cette vulnérabilité.
Haute dissimulation : le contrat fonctionne de manière stable et sans défaut depuis deux ans, avec plusieurs audits réalisés, mais aucune vulnérabilité n'a été trouvée, la principale raison étant que la bibliothèque Integer_Mate utilisée pour les calculs mathématiques n'a pas été incluse dans le champ d'audit.
Les hackers utilisent des valeurs extrêmes pour construire des intervalles de transaction précis, créant des scénarios extrêmement rares avec une liquidité très élevée, ce qui déclenche une logique anormale, indiquant que ce type de problème est difficile à détecter par des tests ordinaires. Ces problèmes se situent souvent dans des zones d'ombre dans la perception des gens, c'est pourquoi ils restent cachés pendant longtemps avant d'être découverts.
Move est supérieur à de nombreux langages de contrats intelligents en matière de sécurité des ressources et de vérification des types, il intègre une détection natale des problèmes de débordement d'entiers dans des scénarios courants. Ce débordement est survenu parce que, lors de l'ajout de liquidités, une mauvaise valeur a d'abord été utilisée pour le contrôle de la limite supérieure lors du calcul du nombre de jetons requis, et un décalage binaire a été utilisé à la place de l'opération de multiplication conventionnelle. Dans Move, si l'on effectue des opérations d'addition, de soustraction, de multiplication ou de division conventionnelles, un contrôle de débordement est automatiquement effectué, évitant ainsi ce problème de troncature de bits élevés.
Des vulnérabilités similaires se sont également produites dans d'autres langages (comme Solidity, Rust), et ont même été plus facilement exploitées en raison de leur manque de protection contre les débordements d'entiers ; avant les mises à jour de version de Solidity, la vérification des débordements était très faible. Dans le passé, il y a eu des débordements d'addition, de soustraction, de multiplication, etc., dont la cause directe était que le résultat des opérations dépassait la plage. Par exemple, les vulnérabilités des contrats intelligents BEC et SMT en langage Solidity ont contourné les instructions de vérification dans le contrat grâce à des paramètres soigneusement construits, permettant ainsi des transferts excessifs pour mener des attaques.
3. Mécanisme de consensus de SUI
3.1 Introduction au mécanisme de consensus SUI
Aperçu :
SUI adopte un cadre de preuve d'enjeu déléguée (DeleGated Proof of Stake, abrégé DPoS). Bien que le mécanisme DPoS puisse augmenter le débit des transactions, il ne peut pas offrir un niveau de décentralisation aussi élevé que le PoW (preuve de travail). Par conséquent, le degré de décentralisation de SUI est relativement faible, le seuil de gouvernance est relativement élevé, et il est difficile pour les utilisateurs ordinaires d'influencer directement la gouvernance du réseau.
Nombre moyen de validateurs : 106
Durée moyenne d'Epoch : 24 heures
Mécanisme de processus :
Délégation de droits : les utilisateurs ordinaires n'ont pas besoin de faire fonctionner un nœud eux-mêmes, il leur suffit de mettre en jeu leur SUI et de le déléguer à un validateur candidat pour participer à la garantie de la sécurité du réseau et à la répartition des récompenses. Ce mécanisme peut réduire le seuil de participation pour les utilisateurs ordinaires, leur permettant de participer au consensus du réseau en "employant" des validateurs de confiance. C'est également un grand avantage du DPoS par rapport au PoS traditionnel.
Représente le tour de production de blocs : un petit nombre de validateurs sélectionnés produisent des blocs dans un ordre fixe ou aléatoire, ce qui améliore la vitesse de confirmation et augmente le TPS.
Élection dynamique : à la fin de chaque cycle de vote, une rotation dynamique est effectuée en fonction du poids des votes pour réélire l'ensemble des validateurs, garantissant ainsi la vitalité des nœuds, la cohérence des intérêts et la décentralisation.
Avantages de DPoS :
Haute efficacité : Grâce à un nombre contrôlable de nœuds de production de blocs, le réseau peut compléter la confirmation en millisecondes, répondant ainsi aux besoins élevés en TPS.
Coût réduit : moins de nœuds participant au consensus, la bande passante réseau et les ressources de calcul nécessaires pour la synchronisation des informations et l'agrégation des signatures sont considérablement réduites. Cela réduit les coûts matériels et opérationnels, diminue les exigences en matière de puissance de calcul et entraîne des coûts plus faibles. Cela permet finalement d'atteindre des frais d'utilisateur plus bas.
Haute sécurité : le mécanisme de mise en jeu et de délégation amplifie les coûts et les risques d'attaque ; associé au mécanisme de confiscation sur la chaîne, il permet de réprimer efficacement les comportements malveillants.
En même temps, dans le mécanisme de consensus de SUI, un algorithme basé sur le BFT (tolérance aux pannes byzantines) est utilisé, exigeant qu'au moins deux tiers des votes des validateurs s'accordent pour confirmer une transaction. Ce mécanisme garantit que même si quelques nœuds agissent malicieusement, le réseau peut rester sûr et fonctionner efficacement. Pour toute mise à niveau ou décision majeure, il est également nécessaire d'obtenir plus des deux tiers des votes pour mettre en œuvre.
En essence, le DPoS est en réalité une sorte de compromis dans le triangle impossible, réalisant un compromis entre décentralisation et efficacité. Le DPoS choisit de réduire le nombre de nœuds de validation actifs pour obtenir de meilleures performances dans le "triangle impossible" sécurité-décente-élargissement, renonçant à un certain degré de décentralisation complète par rapport au PoS pur ou au PoW, mais améliorant considérablement le débit du réseau et la vitesse des transactions.
3.2 La performance de SUI lors de cette attaque
Mécanisme de gel 3.2.1 en fonctionnement
Dans cet événement, SUI a rapidement gelé les adresses liées à l'attaquant.
D'un point de vue code, cela empêche les transactions de transfert d'être empaquetées sur la chaîne. Les nœuds de validation sont les composants clés de la blockchain SUI, responsables de la validation des transactions et de l'exécution des règles du protocole. En ignorant collectivement les transactions liées aux attaquants, ces validateurs mettent en œuvre un mécanisme similaire au gel de compte dans la finance traditionnelle au niveau du consensus.
SUI dispose d'un mécanisme de liste de refus (deny list) intégré, qui est une fonction de liste noire permettant d'empêcher toute transaction impliquant des adresses répertoriées. Étant donné que cette fonctionnalité est déjà présente dans le client, lorsque l'attaque se produit
SUI peut immédiatement geler l'adresse des hackers. Sans cette fonctionnalité, même si SUI n'a que 113 validateurs, il est difficile de coordonner tous les validateurs un par un dans un court laps de temps.
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. Toute personne exécutant un nœud peut éditer ce fichier, le recharger à chaud ou redémarrer le nœud et mettre à jour la liste. En apparence, chaque validateur semble exprimer librement ses valeurs.
En réalité, pour garantir la cohérence et l'efficacité des politiques de sécurité, la mise à jour de cette configuration clé est généralement coordonnée. Étant donné qu'il s'agit d'une "mise à jour urgente poussée par l'équipe", c'est essentiellement la fondation (ou ses développeurs autorisés) qui établit et met à jour cette liste de refus.
Publier une liste noire, théoriquement les validateurs peuvent choisir s'ils souhaitent l'adopter ------ mais en pratique, la plupart des gens l'adoptent automatiquement par défaut. Ainsi, bien que cette fonctionnalité protège les fonds des utilisateurs, elle présente en réalité un certain degré de centralisation.
3.2.3 L'essence de la fonction de liste noire
La fonction de liste noire n'est en réalité pas une logique de niveau protocolaire, mais plutôt une couche de sécurité supplémentaire destinée à faire face aux situations imprévues et à garantir la sécurité des fonds des utilisateurs.
Il s'agit essentiellement d'un mécanisme de garantie de sécurité. Semblable à une "chaîne de sécurité" attachée à la porte, elle ne s'active que pour ceux qui souhaitent s'introduire chez vous, c'est-à-dire pour ceux qui souhaitent nuire au protocole. Pour l'utilisateur :
Pour les gros investisseurs, principaux fournisseurs de liquidités, le protocole veut avant tout garantir la sécurité des fonds, car en réalité, les données on-chain TVL sont entièrement fournies par les principaux gros investisseurs. Pour que le protocole se développe durablement, il est impératif de prioriser la sécurité.
Pour les petits investisseurs, contributeurs à l'activité de l'écosystème, de puissants soutiens à la co-construction technique et communautaire. Les porteurs de projets espèrent également attirer des petits investisseurs pour co-construire, afin de perfectionner progressivement l'écosystème et d'améliorer le taux de rétention. Et en ce qui concerne le domaine de la defi, la priorité est la plus importante.