Croyance ferme après la crise de sécurité : pourquoi SUI a-t-il encore un potentiel de hausse à long terme ?
1. Une réaction en chaîne provoquée par une attaque.
Le 22 mai 2023, le protocole AMM de premier plan, Cetus, déployé sur le réseau SUI, a été victime d'une attaque de hackers. Les attaquants ont exploité une faille logique liée à un "problème de dépassement d'entier" pour lancer une manipulation ciblée, entraînant une perte de plus de 200 millions de dollars d'actifs. Cet incident est non seulement l'un des plus grands accidents de sécurité dans le domaine de la DeFi cette année, mais il représente également l'attaque de hackers la plus destructrice depuis le lancement du réseau principal SUI.
Selon les données de DefiLlama, le TVL total de SUI a chuté de plus de 330 millions de dollars le jour de l'attaque, et le montant des fonds verrouillés du protocole Cetus a même été réduit de 84%, atteignant 38 millions de dollars. En conséquence, plusieurs tokens populaires sur SUI (y compris Lofi, Sudeng, Squirtle, etc.) ont connu une chute de 76% à 97% en l'espace d'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 vague de choc, l'écosystème SUI a montré une grande résilience et capacité de récupération. Bien que l'événement Cetus ait provoqué des fluctuations de 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. Il dressera un bilan du paysage écologique actuel de cette blockchain publique qui en est encore au stade précoce de son développement et explorera 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'incident d'attaque de Cetus par l'équipe SlowMist, les hackers ont réussi à exploiter une vulnérabilité d'arithmétique critique dans le protocole, en utilisant des prêts éclair, une manipulation précise des prix 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 phases principales :
①Lancer un prêt éclair, manipuler les prix
Les hackers ont d'abord utilisé un flash loan de 10 milliards de haSUI avec un glissement maximum, empruntant d'énormes fonds pour manipuler les prix.
Le prêt éclair permet aux utilisateurs d'emprunter et de rembourser des fonds dans la même transaction, ne nécessitant que le paiement de frais, avec des caractéristiques de haut levier, faible risque et faible coût. Les hackers ont profité de ce mécanisme pour faire chuter le prix du marché en peu de temps et le contrôler précisément 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é suffisante de jetons et une liquidité massive. Ensuite, ils ont manipulé plusieurs jetons sans valeur réelle.
②Ajouter de la liquidité
L'attaquant crée des positions de liquidité étroites, déclare qu'il ajoute 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 :
Paramètres de masque trop larges : équivalent à une limite d'ajout de liquidité extrêmement élevée, ce qui rend la vérification des entrées utilisateur dans le contrat pratiquement inutile. Les hackers contournent la détection de débordement en définissant des paramètres anormaux, construisant des entrées qui restent 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 bits s'est produit en raison du dépassement de la largeur de bits valide du type de données uint256 (256 bits). La partie haute débordante a été automatiquement abandonnée, ce qui a conduit à un résultat de calcul bien inférieur aux attentes, entraînant ainsi une sous-estimation du nombre de haSUI nécessaires pour l'échange. Le résultat final du calcul est d'environ inférieur à 1, mais comme il est arrondi à l'entier supérieur, le résultat final est donc égal à 1, ce qui signifie que le hacker n'a besoin d'ajouter qu'un seul jeton pour échanger une énorme liquidité.
③ Retrait de liquidité
Effectuer le remboursement du prêt éclair, tout en conservant d'énormes bénéfices. Finalement, retirer des pools de liquidité multiples des actifs de jetons d'une valeur totale de plusieurs centaines de millions de dollars.
La situation des pertes financières est grave, l'attaque a entraîné le vol des actifs suivants :
12,9 millions de SUI (environ 5,4 millions de dollars)
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é s'étant tarie.
2.2 Causes et caractéristiques de cette vulnérabilité
Cette vulnérabilité de Cetus présente trois caractéristiques :
Coût de correction très faible : d'une part, la cause fondamentale de l'incident Cetus est une lacune dans la bibliothèque mathématique de Cetus, et non une erreur dans le mécanisme de prix du protocole ou une erreur d'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é se situe dans une condition limite, il suffit de modifier deux lignes de code pour éliminer complètement le risque ; une fois la correction effectuée, elle peut être immédiatement déployée sur le réseau principal, garantissant que la logique des contrats ultérieurs est complète et éliminant cette vulnérabilité.
Haute confidentialité : Le contrat fonctionne de manière stable sans aucune défaillance depuis deux ans. Le protocole Cetus a subi plusieurs audits, mais aucune vulnérabilité n'a été trouvée, principalement parce que la bibliothèque Integer_Mate utilisée pour les calculs mathématiques n'a pas été incluse dans le périmètre des audits.
Les hackers utilisent des valeurs extrêmes pour construire précisément des intervalles de transaction, créant ainsi des scénarios très rares avec une liquidité extrêmement é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 de la perception humaine, c'est pourquoi ils restent latents 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, intégrant une détection native des problèmes de dépassement d'entier dans des situations courantes. Ce dépassement est dû au fait qu'en ajoutant de la liquidité, un nombre erroné a d'abord été utilisé pour vérifier la limite supérieure lors du calcul du nombre de jetons requis, et que l'opération de décalage a remplacé l'opération de multiplication conventionnelle. Si des opérations d'addition, de soustraction, de multiplication ou de division conventionnelles étaient utilisées, Move vérifierait automatiquement les situations de dépassement, évitant ainsi ce problème de troncature de bits.
Des vulnérabilités similaires se sont également produites dans d'autres langages (comme Solidity, Rust), et étaient même plus facilement exploitables en raison de leur manque de protection contre les débordements d'entiers ; avant la mise à jour de la version de Solidity, la vérification des débordements était très faible. Historiquement, il y a eu des débordements d'addition, de soustraction et de multiplication, la cause directe étant que le résultat des calculs a dépassé la portée. Par exemple, les vulnérabilités des contrats intelligents BEC et SMT dans le langage Solidity ont été exploitées en contournant les instructions de vérification dans le contrat à l'aide de paramètres soigneusement élaborés, permettant des transferts excessifs pour réaliser 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 de participation 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 degré 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 les utilisateurs ordinaires ont du mal à influencer directement la gouvernance du réseau.
Nombre moyen de validateurs : 106
Durée moyenne de l'Epoch : 24 heures
Processus de mécanisme :
Délégation de participation : Les utilisateurs ordinaires n'ont pas besoin de faire fonctionner un nœud eux-mêmes, il leur suffit de staker SUI et de le déléguer à des validateurs candidats pour participer à la sécurité du réseau et à la distribution 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, un roulement dynamique est effectué pour réélire l'ensemble des validateurs en fonction du poids des votes, garantissant ainsi la vitalité des nœuds, la cohérence des intérêts et la décentralisation.
Les avantages du DPoS :
Haute efficacité : Grâce à un nombre contrôlé de nœuds de validation, le réseau peut confirmer en millisecondes, répondant ainsi aux besoins élevés en TPS.
Coût réduit : Moins de nœuds participant au consensus, ce qui réduit considérablement la bande passante réseau et les ressources de calcul nécessaires pour la synchronisation des informations et l'agrégation des signatures. Cela entraîne une diminution des coûts matériels et des coûts d'exploitation, ainsi qu'une baisse des exigences en matière de puissance de calcul, ce qui réduit les coûts. L'utilisateur bénéficie finalement de frais de transaction plus bas.
Haute sécurité : le mécanisme de staking et de délégation amplifie le coût et le risque des attaques ; associé au mécanisme de confiscation en chaîne, cela permet de réprimer efficacement les comportements malveillants.
En même temps, le mécanisme de consensus de SUI utilise un algorithme basé sur le BFT (tolérance aux pannes byzantines), exigeant qu'une majorité des deux tiers des votes des validateurs s'accorde pour confirmer une transaction. Ce mécanisme garantit que même si quelques nœuds agissent de manière malveillante, le réseau peut rester sécurisé et fonctionner efficacement. Pour effectuer toute mise à niveau ou décision majeure, il est également nécessaire d'obtenir plus des deux tiers des votes pour procéder.
En essence, le DPoS est en réalité une solution de compromis pour le triangle impossible, qui a réalisé un compromis entre décentralisation et efficacité. Le DPoS choisit de réduire le nombre de nœuds de validation actifs afin d'obtenir de meilleures performances dans le "triangle impossible" de sécurité-décentralisation-extensibilité, abandonnant un certain degré de décentralisation complète par rapport à un PoS pur ou un PoW, mais améliorant de manière significative le débit du réseau et la vitesse des transactions.
3.2 La performance de SUI lors de cette attaque
3.2.1 fonctionnement du mécanisme de gel
Dans cet événement, SUI a rapidement gelé les adresses liées à l'attaquant.
D'un point de vue du code, cela empêche les transactions de transfert d'être regroupées et enregistrées sur la chaîne. Les nœuds de validation sont des composants essentiels 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 au niveau du consensus un mécanisme similaire au 'gel de compte' dans la finance traditionnelle.
SUI intègre en soi un mécanisme de liste de refus (deny list), qui est une fonction de liste noire permettant de bloquer toute transaction impliquant des adresses listé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 du hacker. Sans cette fonctionnalité, même si SUI n'a que 113 validateurs, il serait difficile pour Cetus 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. Quiconque exécute un nœud peut modifier ce fichier, le recharger à chaud ou redémarrer le nœud, et mettre à jour la liste. À première vue, chaque validateur semble libre d'exprimer ses propres valeurs.
En réalité, pour assurer 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 d'urgence poussée par l'équipe SUI", cela signifie essentiellement que c'est la fondation SUI (ou ses développeurs autorisés) qui met en place et met à jour cette liste de refus.
SUI a publié une liste noire, théoriquement les validateurs peuvent choisir de l'adopter ou non ------ mais en réalité, la plupart des gens l'adopteront automatiquement par défaut. Ainsi, bien que cette fonctionnalité protège les fonds des utilisateurs, elle a en réalité un certain degré de centralisation.
3.2.3 La nature de la fonction de liste noire
La fonction de liste noire n'est en réalité pas une logique de base du protocole, mais plutôt une couche de sécurité supplémentaire destinée à faire face à des situations imprévues et à garantir la sécurité des fonds des utilisateurs.
C'est essentiellement un mécanisme de garantie de sécurité. Semblable à une "chaîne de sécurité" attachée à la porte, elle n'est activée que pour ceux qui souhaitent pénétrer chez vous, c'est-à-dire pour ceux qui veulent nuire au protocole. Pour l'utilisateur :
Pour les gros investisseurs, principaux fournisseurs de liquidité, le protocole souhaite garantir la sécurité des fonds, car en réalité, les données on-chain tvl proviennent principalement des contributions des gros investisseurs. Pour un développement durable du protocole, il est impératif de prioriser la sécurité.
Pour les petits investisseurs, contributeurs à l'activité de l'écosystème, et soutiens solides de la co-construction technique et communautaire. Les porteurs de projet espèrent également que cela peut
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.
8 J'aime
Récompense
8
4
Partager
Commentaire
0/400
GetRichLeek
· Il y a 7h
J'ai trop investi, Rekt, mais je ne peux pas m'empêcher d'acheter le dip sur SUI.
Voir l'originalRépondre0
ShadowStaker
· 07-26 06:40
la résilience du réseau est mise à l'épreuve fr... mais ces exploits de débordement d'entiers deviennent vieux smh. où est la validation appropriée ?
Voir l'originalRépondre0
NFTRegretter
· 07-26 06:32
Qu'est-ce que tu achètes, sui ? J'ai perdu tellement.
La résilience de l'écosystème SUI se manifeste, montrant un potentiel de hausse à long terme même après la crise de sécurité.
Croyance ferme après la crise de sécurité : pourquoi SUI a-t-il encore un potentiel de hausse à long terme ?
1. Une réaction en chaîne provoquée par une attaque.
Le 22 mai 2023, le protocole AMM de premier plan, Cetus, déployé sur le réseau SUI, a été victime d'une attaque de hackers. Les attaquants ont exploité une faille logique liée à un "problème de dépassement d'entier" pour lancer une manipulation ciblée, entraînant une perte de plus de 200 millions de dollars d'actifs. Cet incident est non seulement l'un des plus grands accidents de sécurité dans le domaine de la DeFi cette année, mais il représente également l'attaque de hackers la plus destructrice depuis le lancement du réseau principal SUI.
Selon les données de DefiLlama, le TVL total de SUI a chuté de plus de 330 millions de dollars le jour de l'attaque, et le montant des fonds verrouillés du protocole Cetus a même été réduit de 84%, atteignant 38 millions de dollars. En conséquence, plusieurs tokens populaires sur SUI (y compris Lofi, Sudeng, Squirtle, etc.) ont connu une chute de 76% à 97% en l'espace d'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 vague de choc, l'écosystème SUI a montré une grande résilience et capacité de récupération. Bien que l'événement Cetus ait provoqué des fluctuations de 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. Il dressera un bilan du paysage écologique actuel de cette blockchain publique qui en est encore au stade précoce de son développement et explorera 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'incident d'attaque de Cetus par l'équipe SlowMist, les hackers ont réussi à exploiter une vulnérabilité d'arithmétique critique dans le protocole, en utilisant des prêts éclair, une manipulation précise des prix 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 phases principales :
①Lancer un prêt éclair, manipuler les prix
Les hackers ont d'abord utilisé un flash loan de 10 milliards de haSUI avec un glissement maximum, empruntant d'énormes fonds pour manipuler les prix.
Le prêt éclair permet aux utilisateurs d'emprunter et de rembourser des fonds dans la même transaction, ne nécessitant que le paiement de frais, avec des caractéristiques de haut levier, faible risque et faible coût. Les hackers ont profité de ce mécanisme pour faire chuter le prix du marché en peu de temps et le contrôler précisément 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é suffisante de jetons et une liquidité massive. Ensuite, ils ont manipulé plusieurs jetons sans valeur réelle.
②Ajouter de la liquidité
L'attaquant crée des positions de liquidité étroites, déclare qu'il ajoute 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 :
Paramètres de masque trop larges : équivalent à une limite d'ajout de liquidité extrêmement élevée, ce qui rend la vérification des entrées utilisateur dans le contrat pratiquement inutile. Les hackers contournent la détection de débordement en définissant des paramètres anormaux, construisant des entrées qui restent 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 bits s'est produit en raison du dépassement de la largeur de bits valide du type de données uint256 (256 bits). La partie haute débordante a été automatiquement abandonnée, ce qui a conduit à un résultat de calcul bien inférieur aux attentes, entraînant ainsi une sous-estimation du nombre de haSUI nécessaires pour l'échange. Le résultat final du calcul est d'environ inférieur à 1, mais comme il est arrondi à l'entier supérieur, le résultat final est donc égal à 1, ce qui signifie que le hacker n'a besoin d'ajouter qu'un seul jeton pour échanger une énorme liquidité.
③ Retrait de liquidité
Effectuer le remboursement du prêt éclair, tout en conservant d'énormes bénéfices. Finalement, retirer des pools de liquidité multiples des actifs de jetons d'une valeur totale de plusieurs centaines de millions de dollars.
La situation des pertes financières est grave, l'attaque a entraîné le vol des actifs suivants :
12,9 millions de SUI (environ 5,4 millions de dollars)
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é s'étant tarie.
2.2 Causes et caractéristiques de cette vulnérabilité
Cette vulnérabilité de Cetus présente trois caractéristiques :
Coût de correction très faible : d'une part, la cause fondamentale de l'incident Cetus est une lacune dans la bibliothèque mathématique de Cetus, et non une erreur dans le mécanisme de prix du protocole ou une erreur d'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é se situe dans une condition limite, il suffit de modifier deux lignes de code pour éliminer complètement le risque ; une fois la correction effectuée, elle peut être immédiatement déployée sur le réseau principal, garantissant que la logique des contrats ultérieurs est complète et éliminant cette vulnérabilité.
Haute confidentialité : Le contrat fonctionne de manière stable sans aucune défaillance depuis deux ans. Le protocole Cetus a subi plusieurs audits, mais aucune vulnérabilité n'a été trouvée, principalement parce que la bibliothèque Integer_Mate utilisée pour les calculs mathématiques n'a pas été incluse dans le périmètre des audits.
Les hackers utilisent des valeurs extrêmes pour construire précisément des intervalles de transaction, créant ainsi des scénarios très rares avec une liquidité extrêmement é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 de la perception humaine, c'est pourquoi ils restent latents 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, intégrant une détection native des problèmes de dépassement d'entier dans des situations courantes. Ce dépassement est dû au fait qu'en ajoutant de la liquidité, un nombre erroné a d'abord été utilisé pour vérifier la limite supérieure lors du calcul du nombre de jetons requis, et que l'opération de décalage a remplacé l'opération de multiplication conventionnelle. Si des opérations d'addition, de soustraction, de multiplication ou de division conventionnelles étaient utilisées, Move vérifierait automatiquement les situations de dépassement, évitant ainsi ce problème de troncature de bits.
Des vulnérabilités similaires se sont également produites dans d'autres langages (comme Solidity, Rust), et étaient même plus facilement exploitables en raison de leur manque de protection contre les débordements d'entiers ; avant la mise à jour de la version de Solidity, la vérification des débordements était très faible. Historiquement, il y a eu des débordements d'addition, de soustraction et de multiplication, la cause directe étant que le résultat des calculs a dépassé la portée. Par exemple, les vulnérabilités des contrats intelligents BEC et SMT dans le langage Solidity ont été exploitées en contournant les instructions de vérification dans le contrat à l'aide de paramètres soigneusement élaborés, permettant des transferts excessifs pour réaliser 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 de participation 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 degré 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 les utilisateurs ordinaires ont du mal à influencer directement la gouvernance du réseau.
Nombre moyen de validateurs : 106
Durée moyenne de l'Epoch : 24 heures
Processus de mécanisme :
Délégation de participation : Les utilisateurs ordinaires n'ont pas besoin de faire fonctionner un nœud eux-mêmes, il leur suffit de staker SUI et de le déléguer à des validateurs candidats pour participer à la sécurité du réseau et à la distribution 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, un roulement dynamique est effectué pour réélire l'ensemble des validateurs en fonction du poids des votes, garantissant ainsi la vitalité des nœuds, la cohérence des intérêts et la décentralisation.
Les avantages du DPoS :
Haute efficacité : Grâce à un nombre contrôlé de nœuds de validation, le réseau peut confirmer en millisecondes, répondant ainsi aux besoins élevés en TPS.
Coût réduit : Moins de nœuds participant au consensus, ce qui réduit considérablement la bande passante réseau et les ressources de calcul nécessaires pour la synchronisation des informations et l'agrégation des signatures. Cela entraîne une diminution des coûts matériels et des coûts d'exploitation, ainsi qu'une baisse des exigences en matière de puissance de calcul, ce qui réduit les coûts. L'utilisateur bénéficie finalement de frais de transaction plus bas.
Haute sécurité : le mécanisme de staking et de délégation amplifie le coût et le risque des attaques ; associé au mécanisme de confiscation en chaîne, cela permet de réprimer efficacement les comportements malveillants.
En même temps, le mécanisme de consensus de SUI utilise un algorithme basé sur le BFT (tolérance aux pannes byzantines), exigeant qu'une majorité des deux tiers des votes des validateurs s'accorde pour confirmer une transaction. Ce mécanisme garantit que même si quelques nœuds agissent de manière malveillante, le réseau peut rester sécurisé et fonctionner efficacement. Pour effectuer toute mise à niveau ou décision majeure, il est également nécessaire d'obtenir plus des deux tiers des votes pour procéder.
En essence, le DPoS est en réalité une solution de compromis pour le triangle impossible, qui a réalisé un compromis entre décentralisation et efficacité. Le DPoS choisit de réduire le nombre de nœuds de validation actifs afin d'obtenir de meilleures performances dans le "triangle impossible" de sécurité-décentralisation-extensibilité, abandonnant un certain degré de décentralisation complète par rapport à un PoS pur ou un PoW, mais améliorant de manière significative le débit du réseau et la vitesse des transactions.
3.2 La performance de SUI lors de cette attaque
3.2.1 fonctionnement du mécanisme de gel
Dans cet événement, SUI a rapidement gelé les adresses liées à l'attaquant.
D'un point de vue du code, cela empêche les transactions de transfert d'être regroupées et enregistrées sur la chaîne. Les nœuds de validation sont des composants essentiels 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 au niveau du consensus un mécanisme similaire au 'gel de compte' dans la finance traditionnelle.
SUI intègre en soi un mécanisme de liste de refus (deny list), qui est une fonction de liste noire permettant de bloquer toute transaction impliquant des adresses listé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 du hacker. Sans cette fonctionnalité, même si SUI n'a que 113 validateurs, il serait difficile pour Cetus 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. Quiconque exécute un nœud peut modifier ce fichier, le recharger à chaud ou redémarrer le nœud, et mettre à jour la liste. À première vue, chaque validateur semble libre d'exprimer ses propres valeurs.
En réalité, pour assurer 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 d'urgence poussée par l'équipe SUI", cela signifie essentiellement que c'est la fondation SUI (ou ses développeurs autorisés) qui met en place et met à jour cette liste de refus.
SUI a publié une liste noire, théoriquement les validateurs peuvent choisir de l'adopter ou non ------ mais en réalité, la plupart des gens l'adopteront automatiquement par défaut. Ainsi, bien que cette fonctionnalité protège les fonds des utilisateurs, elle a en réalité un certain degré de centralisation.
3.2.3 La nature de la fonction de liste noire
La fonction de liste noire n'est en réalité pas une logique de base du protocole, mais plutôt une couche de sécurité supplémentaire destinée à faire face à des situations imprévues et à garantir la sécurité des fonds des utilisateurs.
C'est essentiellement un mécanisme de garantie de sécurité. Semblable à une "chaîne de sécurité" attachée à la porte, elle n'est activée que pour ceux qui souhaitent pénétrer chez vous, c'est-à-dire pour ceux qui veulent nuire au protocole. Pour l'utilisateur :
Pour les gros investisseurs, principaux fournisseurs de liquidité, le protocole souhaite garantir la sécurité des fonds, car en réalité, les données on-chain tvl proviennent principalement des contributions des gros investisseurs. Pour un développement durable du protocole, il est impératif de prioriser la sécurité.
Pour les petits investisseurs, contributeurs à l'activité de l'écosystème, et soutiens solides de la co-construction technique et communautaire. Les porteurs de projet espèrent également que cela peut