Accueil

harry phan421

May 31, 2025

Article

Le 22 mai 2025, un exploit majeur a ciblé le protocole Cetus sur la blockchain Sui, entraînant des dommages estimés à 223 millions de dollars. Cet incident a immédiatement attiré l'attention de l'ensemble de l'écosystème, en particulier de la part des observateurs techniques en raison des mécanismes inhabituels impliqués. Ce qui suit est une analyse complète de l'attaque, allant des échanges de flash et des manipulations de ticks à une vulnérabilité silencieuse dans la logique de détection des débordements. https://suiscan.xyz/mainnet/tx/DVMG3B2kocLEnVMDuQzTYRgjwuuFSfciawPvXXheB3x La configuration L'attaquant a lancé l'exploit en utilisant flash_swap pour emprunter une grande quantité de jetons SUI en échange de HasUI. Contrairement aux flashloans traditionnels, flash_swap dans Cetus permet à un utilisateur de recevoir token1 (SUI dans ce cas) à l'avance, puis de rembourser token0 (hasUI) dans le cadre de la même transaction. Ce mécanisme est au cœur de la configuration de l'attaquant. Dans ce cas précis, l'attaquant a réussi à acquérir 5,76 millions de SUI et a été obligé de rembourser 10,02 millions de HASUI. Mais au cours de cet échange, le prix de HaSUI dans le pool de liquidités a été radicalement manipulé. Le cours du pool est passé d'un tick représentant un ratio de 1,056 à un tick si bas que le cours n'a atteint que 0,0000009977, soit une énorme dévaluation à 0,00009 % de son prix initial. La fourchette de prix correspondant à la fourchette à cocher est la suivante : Injection stratégique de liquidités À la suite de cette chute des cours, l'attaquant a utilisé open_position pour créer une position de liquidité à fourchette étroite, en choisissant une fourchette de ticks très spécifique (TickLower : 300000, TickUpper : 300200). Dans cet environnement manipulé, ils ont injecté une quantité astronomique de liquidités : plus de 10^34 unités, toutes comprises dans la fourchette de prix ultra-compressée créée par l'effondrement des ticks. Cela a été rendu possible par une fonction apparemment anodine : get_amount_by_liquidity. Dans des conditions normales, cette fonction calcule la quantité de jeton A et de jeton B nécessaire pour correspondre à un certain niveau de liquidité. Pour ce faire, il utilise des fonctions d'assistance telles que get_delta_a, qui repose sur get_sqrt_price_at_tick. Cependant, étant donné que le tick actuel manipulé était de -138185 et que la plage de ticks choisie se situait bien en dehors de cette plage (à partir de 300 000), le chemin logique dans get_amount_by_liquidity garantissait que les calculs passeraient par une section vulnérable du code impliquant une opération de décalage vers la gauche (checked_shlw). Débordement et troncature : la principale vulnérabilité C'est là que l'exploit devient vraiment technique. La fonction checked_show est censée gérer le décalage de 64 bits vers la gauche d'un nombre de 256 bits. Dans les environnements similaires à Solidity, une telle opération est risquée car elle peut déborder. Cette implémentation particulière a tenté de détecter les débordements en vérifiant si l'entrée dépassait un seuil prédéfini : 0xffffffffffffff << 192. Le seuil réel pour détecter un décalage sécurisé de 64 bits doit être de 2^ (256 - 64) - 1. Cependant, (0xffffffffffffffff << 192) est supérieur à 2^192. Cela signifie qu'une entrée soigneusement sélectionnée pourrait contourner le contrôle de débordement en étant inférieure au seuil utilisé dans le code, tout en restant suffisamment grande pour provoquer un débordement lors de l'exécution. L'attaquant a fourni une telle entrée, où la multiplication de la liquidité et de la différence de prix a débordé silencieusement, renvoyant une valeur bien inférieure à celle prévue, presque nulle en fait. En conséquence, le protocole a calculé que l'attaquant n'avait besoin que de payer un montant insignifiant de jeton, essentiellement une unité, pour ajouter des liquidités massives au pool. Cette erreur de calcul a permis à l'attaquant d'injecter des liquidités massives sans aucun coût réel. Par la suite, l'attaquant a supprimé les liquidités supplémentaires via remove_liquidity et a terminé l'attaque en payant les jetons impayés de flash_swap via repay_flash_swap. L'attaquant a réalisé un bénéfice de 5 765 124 SUI et 10 024 321 HasUI. Enfin, l'équipe de Cetus a corrigé la vulnérabilité grâce à deux PR : https://github.com/CetusProtocol/integer-mate/pull/6/files Cetus a rapidement publié un correctif sur son référentiel Integer-Mate, la première pull request tentant d'affiner la détection des débordements. Cependant, ce correctif initial était inadéquat. Il a utilisé un masque de 1 << 192, ce qui laissait toujours passer les valeurs des majuscules. Une deuxième demande d'extraction a suivi d'une comparaison plus stricte, vérifiant que l'entrée est supérieure ou égale à 2^192, garantissant ainsi des limites appropriées pour un décalage vers la gauche en toute sécurité. Ce n'est qu'avec cette correction que la vulnérabilité a été efficacement atténuée. https://github.com/CetusProtocol/integer-mate/pull/7/files

0xduckmove308

May 31, 2025

Article

Account.tech est un framework open source sur la blockchain Sui qui introduit les comptes intelligents de manière très fluide Des objets de compte flexibles, sécurisés et personnalisables qui peuvent exécuter des actions en chaîne via une architecture modulaire basée sur l'intention. Considérez-le comme des portefeuilles programmables avec prise en charge native du multisig, de la logique DAO, de l'exécution planifiée, du contrôle d'accès dynamique, etc. Pourquoi choisir les comptes intelligents ? Les comptes traditionnels ne sont que des conteneurs passifs. Ils détiennent des actifs et signent des transactions. Les comptes intelligents sont des entités actives et programmables qui peuvent définir une logique de propriété, automatiser les flux de travail et gérer les actifs en fonction de règles. Avec Account.tech, ces règles sont intégrées à la chaîne, sont personnalisables via les modules Move et sont appliquées via Intents. Concepts clés Structure de compte intelligente public struct Account has key, store { id: UID, metadata: Metadata, deps: Deps, intents: Intents, config: Config, } Un compte intelligent est un objet partagé contenant : Métadonnées : informations descriptives Deps — paquets de dépendances utilisés Intentions : demandes actives ou en attente pour effectuer des actions Configuration : ensemble de règles personnalisé (par exemple, multisig, basé sur les rôles, logique DAO) Chaque compte possède un module de configuration unique qui détermine la manière dont les intentions sont résolues. Exécution basée sur l'intention Une intention est une demande structurée visant à effectuer une ou plusieurs actions en chaîne. Il se déroule en 3 étapes : [ ] Demandez à l'utilisateur de créer l'intention avec des actions [ ] Résolution — le module de configuration vérifie si les conditions sont remplies [ ] Exécution — n'importe qui peut exécuter l'intention lorsqu'elle est valide Exemple : une intention multisignature visant à transférer des fonds ne sera exécutée que lorsqu'un nombre suffisant de membres l'auront approuvée. Actions = Unités d'exécution modulaires Chaque action est une structure Move autonome, comme : struct WithdrawAction { object_id: ID } struct TransferAction { recipient: address } Vous pouvez composer plusieurs actions dans une seule intention. Par exemple : Withdraw → Transfer → Withdraw → Transfer Cela permet des flux de travail avancés, tels que les échanges atomiques, les transferts par lots, les versions de coffres-forts basées sur le temps, etc. Configuration : logique de propriété personnalisable Le type de configuration définit la manière dont les intentions sont résolues. Vous pouvez intégrer une logique telle que : ✅ Multisig avec votes pondérés 🔐 Contrôle d'accès basé sur les rôles 🗳 Logique de vote DAO ⏳ Retards ou tâches récurrentes 💾 Flux de récupération Chaque intention suit un résultat, qui représente l'état de la résolution (par exemple, les votes collectés, les approbations accordées, etc.). En savoir plus 🔗 Documents : https://account-tech.gitbook.io/docs 🧑‍💻 GitHub : https://github.com/account-tech

0xduckmove308

May 30, 2025

Article

Si vous vous basez sur Sui ou que vous bricolez avec Move, vous avez probablement entendu le terme BCS circuler. C'est l'abréviation de la machine de formatage de sérialisation canonique binaire conçue à l'origine pour la blockchain Diem, et qui constitue désormais la pierre angulaire des écosystèmes basés sur Move tels que Sui, Aptos, Starcoin et 0L. Alors oui, tu ferais mieux de t'y mettre à l'aise si tu veux vraiment construire dans cet espace. Qu'est-ce que BCS ? La sérialisation canonique binaire (BCS) est un format utilisé pour sérialiser (encoder) et désérialiser (décoder) des données structurées en octets. Vous le verrez utilisé lorsque : Encodage des transactions avant de les signer. Émettre ou analyser des événements depuis la blockchain. Interagir avec les contrats intelligents Move off-chain via JavaScript. Mais BCS n'inclut pas d'informations de type dans les octets. Cela signifie que vous devez connaître la structure à l'avance lors du décodage, contrairement aux formats tels que JSON ou Protocol Buffers, qui sont plus autodescriptifs. Principales caractéristiques de BCS Aucune métadonnée de type La sortie sérialisée ne contient aucune indication sur les types de champs. Vous devez savoir à quoi vous avez affaire lorsque vous décodez. Sérialisation dépendante de l'ordre Les structures sont codées dans l'ordre exact de leurs champs. Modifiez l'ordre et votre désérialisation s'interrompt. C'est pourquoi les fonctions peel_* de Move doivent correspondre à la disposition 1:1. de la structure. Type générique Dans une structure comme : struct BCSObject has drop, copy { id: ID, owner: address, meta: Metadata, generic: T } Vous ne pouvez désérialiser de manière fiable que jusqu'au champ méta. Les types génériques perturbent l'analyse BCS, alors mettez-les toujours en dernier si vous voulez que vos données soient décodées en toute sécurité. Utilisation de BCS en JavaScript Grâce à la bibliothèque @mysten /bcs, vous pouvez travailler avec BCS dans JS comme un pro. npm i @mysten/bcs et exemple de base : import { BCS, getSuiMoveConfig } from "@mysten/bcs"; const bcs = new BCS(getSuiMoveConfig()); const ser = bcs.ser(BCS.U16, 10); console.log(ser.toBytes()); // [0x0a, 0x00] const des = bcs.de(BCS.U16, ser.toBytes()); console.log(des); // 10 Vous pouvez également sérialiser des vecteurs et des chaînes : bcs.ser("vector", [1, 2, 3, 4]); // 04 01 02 03 04 bcs.ser(BCS.STRING, "test string"); // 0b7465737420737472696e67 Enregistrement de types personnalisés Supposons que vous ayez les structures Move suivantes : struct Metadata has drop, copy { name: std::ascii::String } struct BCSObject has drop, copy { id: ID, owner: address, meta: Metadata } Vous pouvez les enregistrer comme ceci dans JS : bcs.registerStructType("Metadata", { name: BCS.STRING, }); bcs.registerStructType("BCSObject", { id: BCS.ADDRESS, owner: BCS.ADDRESS, meta: "Metadata", }); Exemple de sérialisation et de désérialisation Sérialisation JavaScript : const bytes = bcs .ser("BCSObject", { id: "0x0000000000000000000000000000000000000005", owner: "0x000000000000000000000000000000000000000a", meta: { name: "aaa" } }) .toString("hex"); console.log("Hex:", bytes); La sortie peut être : 0x0000000000000000000000000000000000000005000000000000000000000000000000000000000a03616161 Cela peut désormais être transféré dans un contrat Move ou même testé manuellement dans Sui CLI. Le BCS peut sembler de bas niveau et riche en octets, mais une fois que vous aurez compris comment il code les données, vous pourrez mieux comprendre comment fonctionnent réellement les contrats intelligents Move et comment relier en toute sécurité les systèmes hors chaîne on-chain ↔. Et si vous déboguez des octets BCS sur Sui Explorer (comme celui ci-dessous) : Encodage BCS La sérialisation canonique binaire, ou BCS, est un format de sérialisation développé dans le contexte de la blockchain Diem et est désormais largement utilisé dans la plupart des blockchains basées sur Move (Sui, Starcoin, Aptos, 0L). Le BCS n'est pas seulement utilisé dans la machine virtuelle Move, mais également dans le codage des transactions et des événements, comme la sérialisation des transactions avant la signature ou l'analyse des données d'événements. Il est essentiel de connaître le fonctionnement de BCS si vous souhaitez comprendre le fonctionnement de Move à un niveau plus approfondi et devenir un expert de Move. Allons-y. Spécifications et propriétés du BCS Il convient de garder à l'esprit certaines propriétés de haut niveau du codage BCS au cours de la suite de la leçon : Le BCS est un format de sérialisation de données dans lequel les octets de sortie résultants ne contiennent aucune information de type ; de ce fait, la partie recevant les octets codés devra savoir comment désérialiser les données Il n'y a pas de structures dans BCS (puisqu'il n'y a pas de types) ; la structure définit simplement l'ordre dans lequel les champs sont sérialisés Les types de wrapper sont ignorés, donc OuterType et UnnestedType auront la même représentation BCS : structure OuterType { propriétaire : InnerType } structure innerType { adresse : adresse } structure UnnestedType { adresse : adresse } Les types contenant les champs de type générique peuvent être analysés jusqu'au premier champ de type générique. Il est donc recommandé de placer le ou les champs de type générique en dernier s'il s'agit d'un type personnalisé qui sera utilisé/supprimé. la structure BCSobject a été déposée, copiez { identifiant : identifiant, propriétaire : adresse, méta : métadonnées, générique : T } Dans cet exemple, nous pouvons tout désérialiser jusqu'au champ méta. Les types primitifs tels que les entiers non signés sont codés au format Little Endian Le vecteur est sérialisé sous la forme d'une longueur ULEB128 (avec une longueur maximale allant jusqu'à u32) suivie du contenu du vecteur. La spécification BCS complète se trouve dans le référentiel BCS. Utilisation de la bibliothèque JavaScript @mysten /bcs Installation La bibliothèque que vous devrez installer pour cette partie est la bibliothèque @mysten /bcs. Vous pouvez l'installer en saisissant dans le répertoire racine d'un projet de nœud : npm dans @mysten /bcs Exemple de base Utilisons d'abord la bibliothèque JavaScript pour sérialiser et désérialiser certains types de données simples : import {BCS, GetSuiMoveConfig} depuis « @mysten /bcs » ; //initialise le sérialiseur avec les configurations Sui Move par défaut const bcs = nouveau BCS (getSuiMoveConfig ()) ; //Définition de certains types de données de test entier constant = 10 ; tableau const = [1, 2, 3, 4] ; const string = « chaîne de test » //utilise bcs.ser () pour sérialiser les données const ser_integer = bcs.ser (BCS.U16, entier) ; const ser_array = bcs.ser (« vecteur », tableau) ; const ser_string = bcs.ser (BCS.STRING, chaîne de caractères) ; //utilisation de bcs.de () pour désérialiser les données const de_integer = bcs.de (BCS.U16, SER_Integer.toBytes ()) ; const de_array = bcs.de (« vecteur », SER_Array.toBytes ()) ; const de_string = bcs.de (BCS.STRING, SER_STRING.tobytes ()) ; Nous pouvons initialiser l'instance du sérialiseur avec le paramètre par défaut intégré pour Sui Move en utilisant la syntaxe ci-dessus, new BCS (getSuiMoveConfig ()). Il existe des ENUM intégrés qui peuvent être utilisés pour les types Sui Move tels que BCS.U16, BCS.STRING, etc. Pour les types génériques, il peut être défini en utilisant la même syntaxe que dans Sui Move, comme vector dans l'exemple ci-dessus. Examinons de plus près les champs sérialisés et désérialisés : Les entiers sont des hexadécimaux de petite taille 0a00 10 le premier élément d'un vecteur indique la longueur totale, alors c'est juste les éléments du vecteur 0401020304 1, 2, 3, 4 les chaînes ne sont que des vecteurs de u8, le premier élément étant égal à la longueur de la chaîne 0b7465737420737472696e67 chaîne de test Type d'enregistrement Nous pouvons enregistrer les types personnalisés sur lesquels nous allons travailler en utilisant la syntaxe suivante : import {BCS, GetSuiMoveConfig} depuis « @mysten /bcs » ; const bcs = nouveau BCS (getSuiMoveConfig ()) ; //Enregistrement du type de métadonnées BCS.RegisterStructType (« Métadonnées », { nom : BCS.STRING, }) ; //Idem pour l'objet principal que nous avons l'intention de lire BCS.RegisterStructType (« BCSobject », { //BCS.ADDRESS est utilisé pour les types d'ID ainsi que pour les types d'adresses identifiant : BCS.ADDRESS, propriétaire : BCS.ADDRESS, meta : « Métadonnées », }) ; Utilisation de BCS dans Sui Smart Contracts Continuons notre exemple ci-dessus avec les structures. Définition de la structure Nous commençons par les définitions de structure correspondantes dans le contrat Sui Move. { //.. struct Les métadonnées ont été supprimées, copiez { nom : std : :ascii : :String } la structure BCSobject a été déposée, copiez { identifiant : identifiant, propriétaire : adresse, méta : Métadonnées } //.. } Désérialisation Écrivons maintenant la fonction permettant de désérialiser un objet dans un contrat Sui. public fun object_from_bytes (bcs_bytes : vecteur) : BCSobject { //Initialise l'instance bcs bytes let bcs = bcs : :new (bcs_bytes) ; //Utilise peel_*des fonctions pour extraire les valeurs des octets sérialisés. //L'ordre doit être le même que celui que nous avons utilisé pour la sérialisation ! let (identifiant, propriétaire, méta) = ( bcs : :peel_address (&mut bcs), bcs : :peel_address (&mut bcs), bcs : :peel_vec_u8 (&mut bcs) ) ; //Compresse une structure BCSobject avec les résultats de la sérialisation BCSobject {id : object : :id_from_address (id), propriétaire, méta : Metadata {name : std : :ascii : :string (meta)}}} Les différentes méthodes peel_* du module Sui Frame bcs sont utilisées pour « extraire » chaque champ individuel des octets sérialisés BCS. Notez que l'ordre dans lequel nous décorons les champs doit être exactement le même que celui des champs dans la définition de la structure. Quiz : Pourquoi les résultats des deux premiers appels peel_address sur le même objet bcs ne sont-ils pas les mêmes ? Notez également comment nous convertissons les types d'adresse en identifiant et de vecteur en std : :ascii : :string avec des fonctions d'assistance. Quiz : Que se passerait-il si BSCobject avait un type d'UID au lieu d'un type d'ID ? Exemple Ser/De complet Trouvez l'intégralité des exemples de codes JavaScript et Sui Move dans le dossier example_projects. Tout d'abord, nous sérialisons un objet de test à l'aide du programme JavaScript : //Nous construisons un objet de test à sérialiser, notez que nous pouvons spécifier le format de la sortie en hexadécimal let _bytes = bcs .ser (« BCSobject », { identifiant : « 0x0000000000000000000000000000000000000000000000000005", propriétaire : « 0x000000000000000000000000000000000000000000000000000a », meta : {nom : « aaa"} }) .toString (« hexadécimal ») ; Nous voulons que la sortie du graveur BCS soit au format hexadécimal cette fois, ce qui peut être spécifié comme ci-dessus. Fixez la chaîne hexadécimale du résultat de la sérialisation avec le préfixe 0x et exportez-la vers une variable d'environnement : export Object_HexString=0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000A03616161 Nous pouvons maintenant soit exécuter les tests unitaires Move associés pour vérifier leur exactitude : test de mouvement de costume Vous devriez voir ceci dans la console : BÂTIMENT bcs_move Exécution de tests unitaires avec Move [PASS] 0x0 : :bcs_object : :test_désérialisation Résultat du test : OK. Nombre total de tests : 1 ; réussis : 1 ; échec : 0 Ou nous pouvons publier le module (et exporter le PACKAGE_ID) et appeler la méthode emit_object en utilisant la chaîne hexagonale sérialisée BCS ci-dessus : appel client sui --function emit_object --module bcs_object --package $PACKAGE_ID --args $OBJECT_HEXSTRING Nous pouvons ensuite consulter l'onglet Événements de la transaction sur le Sui Explorer pour voir que nous avons émis le BCSObject correctement désérialisé :

Vens.sui134

May 29, 2025

Article

En mai 2025, le monde de la DeFi a été secoué par l'une des failles de sécurité les plus importantes de l'histoire récente. Cetus Protocol, l'un des principaux protocoles d'échange décentralisé (DEX) et de liquidité sur la blockchain Sui, a été victime d'un piratage sophistiqué qui a entraîné des pertes supérieures à 200 millions de dollars. Cet incident a non seulement provoqué une onde de choc dans la communauté DeFi, mais a également suscité de sérieuses inquiétudes quant à la sécurité des contrats intelligents et à la robustesse des protocoles basés sur des blockchains émergentes comme Sui. Cetus Protocol s'était imposé comme le premier DEX du réseau Sui, offrant aux utilisateurs une plate-forme pour échanger des jetons et fournir des liquidités. En tant que composant d'infrastructure clé de l'écosystème Sui, Cetus a joué un rôle essentiel en facilitant le commerce décentralisé et en contribuant à la liquidité globale du réseau. Son importance en a fait une cible attrayante pour les acteurs malveillants qui cherchaient à exploiter les vulnérabilités de sa base de code. Le Cetus Hack se dévoile La violation s'est produite le 22 mai 2025, lorsque des attaquants ont identifié et exploité une faille critique dans la logique des contrats intelligents de Cetus. Plus précisément, la vulnérabilité provenait d'un subtil bogue de débordement arithmétique qui a permis au pirate informatique de manipuler les mécanismes de comptabilité internes du protocole. En déployant des jetons frauduleux et en manipulant les courbes de prix au sein des pools de liquidités, l'attaquant a pu drainer de grandes quantités de fonds sans déclencher de systèmes de détection immédiats. Vers 3 h 52 PT (11 h 52 UTC), les moniteurs de blockchain ont commencé à détecter des transactions irrégulières dans plusieurs pools de liquidités sur Cetus. En quelques heures, l'étendue des dégâts est devenue claire : plus de 260 millions de dollars d'actifs avaient été détournés du protocole. Les fonds volés ont été rapidement échangés et transférés vers d'autres blockchains, ce qui a compliqué les efforts de récupération. Impact sur le marché et l'écosystème Sui Les conséquences du piratage ont été rapides et graves. La négociation sur Cetus a été immédiatement interrompue car les développeurs se sont efforcés d'évaluer la situation et d'atténuer les pertes supplémentaires. Pendant ce temps, la valeur des jetons natifs associés à la plate-forme a chuté, certains ayant connu des baisses allant jusqu'à 80 % en quelques heures. Les investisseurs et les utilisateurs ont subi des pertes massives et la confiance dans l'écosystème Sui a été ébranlée. Une évolution particulièrement alarmante s'est produite lorsque le réseau Sui a tenté une contre-mesure controversée : voter pour geler le portefeuille de l'attaquant contenant 160 millions de dollars de fonds volés. Bien que cette décision ait démontré une approche proactive du recouvrement d'actifs, elle a également suscité des débats sur les principes de décentralisation et sur la question de savoir si de telles actions minaient la confiance dans l'immuabilité des transactions blockchain. Dans un élan, $SUI a perdu 5 % et $CETUS +- 40 %, ce bond était à la fois incroyable et terrifiant. Détails techniques de l'exploit du protocole Cetus Selon une analyse fournie par la société de cybersécurité Halborn, la cause première de l'exploit réside dans la façon dont Cetus a validé certaines opérations arithmétiques lors d'échanges de jetons. Un oubli dans la gestion de grands nombres a entraîné une situation de débordement, que l'attaquant a habilement manipulée pour créer des déséquilibres artificiels dans les pools de liquidités. Ces déséquilibres ont ensuite été exploités pour extraire des actifs réels du système sans compensation adéquate pour les fournisseurs de liquidités. Ce type de vulnérabilité est particulièrement insidieux car il ne se manifeste pas toujours dans des conditions de fonctionnement normales ; il nécessite plutôt des cas limites spécifiques impliquant des valeurs très importantes ou des séquences de transactions inhabituelles pour se déclencher. Ces bogues sont notoirement difficiles à détecter lors des audits et des phases de test standard, ce qui en fait des candidats de choix pour l'exploitation par des adversaires disposant de ressources suffisantes. Efforts de réponse et de rétablissement de la part de la Fondation Cetus et Sui (alias Mysten Labs) Au cours de l'attaque, environ 160 millions de dollars auraient été gelés et seraient remboursés aux piscines de Cetus. C'est pourquoi toutes les fondations Sui ont lancé un vote pour débloquer ces jetons. À la suite de l'attaque, l'équipe de Cetus a publié des déclarations publiques reconnaissant la violation et décrivant les étapes à suivre pour y remédier. Ils ont travaillé en étroite collaboration avec des sociétés d'analyse de chaînes de blocs comme Elliptic et Chainalysis pour suivre le mouvement des fonds volés et identifier les voies potentielles de recouvrement. En outre, des discussions ont eu lieu concernant la mise en œuvre de mises à niveau d'urgence pour corriger les vulnérabilités existantes et améliorer la résilience future contre des attaques similaires. Les membres de la communauté ont exprimé des réactions mitigées face à ces développements. Alors que beaucoup ont salué la transparence dont a fait preuve la direction de Cetus après le piratage, d'autres ont critiqué le manque de préparation à de tels scénarios et se sont demandé si des garanties suffisantes avaient été mises en œuvre avant le lancement.

HaGiang164

May 25, 2025

Article

Parce que la transparence ne doit pas signifier dévoiler ses secrets. Sur la plupart des blockchains publiques actuelles, chaque transaction et chaque identité d'utilisateur sont visibles publiquement. Bien que la transparence soit l'un des principaux atouts de la blockchain, elle se fait au détriment de la confidentialité, en particulier en matière d'authentification. ZKat, abréviation de Zero-Knowledge Authenticators, est une nouvelle primitive cryptographique qui introduit une authentification préservant la confidentialité dans le monde de la blockchain. Avec ZKat, les utilisateurs peuvent prouver qu'ils sont autorisés à effectuer une transaction sans révéler les règles ou les politiques qui sous-tendent cette autorisation. ##Le problème des approches traditionnelles Les tentatives précédentes de confidentialité lors de l'authentification, telles que l'utilisation designatures à seuil, ne pouvaient masquer que des informations limitées. Par exemple, ils peuvent masquer quels utilisateurs ont signé une transaction, mais pas grand-chose d'autre. Ils étaient également confrontés à despolitiques d'authentification complexes(telles que des combinaisons de rôles, d'identités ou de règles). ZKat change la donne en : Soutenir des politiquesarbitrairement complexes Permettre des structures flexibles telles quedes combinaisons de signatures multischémes Garderl'intégralité de la politiquecachée au public ##Comment fonctionne ZKat Pour créer zKAT, les auteurs ont conçu uncompilateurqui transforme le système zk-SNARKGroth16largement utilisé en un nouveau type de preuveNon-Interactive Zero-Knowledge (NIZK), prenant en charge lesclés de vérification équivoques. Qu'est-ce que cela signifie ? Cela signifie que le vérificateurne peut pas direquelle politique est utilisée, mais la preuve le convainc tout de même qu'elle est valide. Il s'agit d'une toute nouvelle propriété cryptographique présentée dans l'article, qui constitue la base de la manière dont zKat garantit laconfidentialité des politiques. Mais les auteurs ne se sont pas arrêtés à ZKat. Ils sont allés encore plus loin avecZKat, une version qui prend en charge lesmises à jour oubliées. En bref : Un émetteur de politique peut mettre à jour la politique d'authentification sans rien révéler de nouveau C'est très puissant dans les systèmes de blockchain du monde réel où les politiques peuvent devoir évoluer. Pensez aux DAO mettant à jour les règles de vote ou à la rotation des clés des institutions. Ils explorent également l'utilisation depreuves zk-récursivespour rendre zKat⁺ évolutif et adapté à l'intégration de la blockchain. Les chercheurs ont implémenté ZKat dans un prototype d'authentification basée sur des seuils. Leur évaluation montre que : Les performances sont comparables à celles des signatures de seuil traditionnelles ZKat prend en chargedes politiques beaucoup plus complexes Tout cela, avecdes frais généraux minimaux 

0xduckmove308

May 19, 2025

Article

(p/s : Pas une de ces « mises à jour Web3 » qui vous donnent 3 lignes de fluff et qui les appellent alpha 😮‍💨) Lire l'article complet : https://x.com/InternSui81687/status/1897309368644985108 Vous arrive-t-il de déplacer des actifs d'une chaîne à l'autre en ayant l'impression d'être Indiana Jones en train d'esquiver les pièges ? Ouais. En effet, à l'heure actuelle, l'interopérabilité est synonyme de ponts risqués et de points de défaillance centraux. Ika répond : « Non, on en a fini avec ça. » Ils mettent au point un système de mise au point automatique rapide et fiable qui ne donne vos clés à personne. Construit sur Sui, il utilise le cryptage Threshold et 2PC-MPC Dans la vidéo ici, David Lash (co-fondateur d'Ika) dit carrément ce que tout le monde pense : l'interopérabilité est cassée AF. Et au lieu d'écrire un autre blog « nous avons besoin d'une solution » comme le font la plupart des équipes, elles ont passé deux ans à faire appel à des experts en sécurité, à des spécialistes de l'IA et à des universitaires pour en créer un. Qu'est-ce qu'ils ont trouvé ? Un système utilisant un MPC 2PC et un cryptage à seuil, des mots fantaisistes qui signifient en gros : vos clés restent les vôtres, vos actifs ne sont pas remballés comme un cadeau de Noël en 2017 et tout va très vite. Par exemple, Ika ne se contente pas de sécuriser tes affaires. Il analyse les transactions avec une latence inférieure à la seconde tout en restant décentralisé. En attendant, les ponts arrivent en 8 minutes et votre âme vient juste pour confirmer un échange. Ils l'ont construit sur Sui. Et si tu as dormi sur Sui jusqu'à présent, cette sieste est terminée. Le modèle centré sur l'objet de Sui, sa finalité fulgurante et le Mysticeti Consensus (oui, c'est une chose, non, ce n'est pas inventé) correspondent parfaitement à ce que cherche à faire Ika. David a même déclaré que l'expérience de Sui en matière de développement en faisait un choix évident, ce qui est un éloge rare dans le domaine de la cryptographie, où chaque outil de développement ressemble à un ancien parchemin. Mais ce qui m'a vraiment séduit, c'est leur point de vue sur l'UX. La meilleure cryptomonnaie ? Le genre qui est ennuyeux. Pas dans le mauvais sens, mais de la façon « ça marche tout simplement ». Ika vise un futur où vous ne savez même pas que vous faites des activités inter-chaînes. Pas de fenêtres contextuelles, pas de ponts, pas de faux jetons. Ouvrez simplement votre portefeuille, prêtez vos BTC de manière native, effectuez un échange entre chaînes et continuez à vibrer. C'est ce que nous demandions et que nous avons oublié d'exiger d'une manière ou d'une autre. Et ne pensez pas que c'est juste pour Degen Bros. Ika permet aux DAO, aux équipes indépendantes et aux entreprises de déployer leurs propres solutions de conservation. Pensez au « pack de démarrage Fireblocks », mais sous stéroïdes et réellement accessible. Vous n'avez plus besoin d'une configuration de 500 000$ pour créer une infrastructure sécurisée. Juste Sui, Ika et un peu de courage. Oh, et ne dormons pas sur Bitcoin. BTC est resté sur la touche pendant des années, comme ce type qui refuse de participer au jeu. Mais Ika est en train de le rendre jouable. DeFi sans emballage ni déplacement : verrouillez-le simplement en tant que garantie native et c'est parti. Les institutions vont l'adorer car cela leur permet de rester conformes et efficaces. Pas de FUD fiscal, pas de pièges de détention. C'est juste que les capitaux circulent correctement. Donc, si quelqu'un vous demande : « Quelle est la prochaine étape pour la cryptographie ? » ne leur envoyez pas de fil de tweet disant « L'interopérabilité, c'est l'avenir »

RogueRig134

May 13, 2025

Article

@ikadotxyz, le réseau MPC parallèle ultrarapide de la blockchain Sui, suscite un vif engouement en raison de son potentiel à révolutionner la sécurité et l'interopérabilité du Web3. Des publications récentes sur X mettent en évidence le sentiment haussier, IKA se négociant apparemment entre 4,90$ et 10$ sur des plateformes de pré-commercialisation comme Whales, malgré une offre de 1 milliard de jetons. Cela suggère une capitalisation boursière possible de plusieurs milliards de dollars si la dynamique se maintient, alimentée par un investissement stratégique de 21 millions de dollars de la Fondation Sui et une campagne artistique record de 1,4 million de dollars SUI NFT. La latence inférieure à la seconde d'Ika et sa capacité à s'adapter à des centaines de nœuds signataires changent la donne pour les applications DeFi, la conservation décentralisée et les applications inter-chaînes. Le prochain lancement du jeton IKA sur Sui devrait permettre de débloquer un nouvel utilitaire, favorisant ainsi son adoption. Les utilisateurs de X sont enthousiasmés par le rôle d'IKA dans le programme de fidélité @GiveRep, certains le qualifiant de l'une des plus grandes opportunités de largage sur Sui. Cela dit, les prix avant la mise en marché peuvent être volatils et spéculatifs, de sorte que le maintien de la fourchette de 4,90 à 10 dollars n'est pas garanti après le lancement. Examinez toujours les fondamentaux du projet (consultez les chaînes officielles d'Ika pour en savoir plus) et évaluez les risques avant de vous lancer. L'écosystème Sui se réchauffe, mais rien n'est sûr en matière de cryptographie

Rogue129

May 13, 2025

Article

Pour configurer un nœud Sui, vous devez installer les fichiers binaires Sui, cloner le référentiel Sui et configurer le nœud. Vous pouvez compiler à partir des sources ou utiliser Docker. Une fois que le nœud est en cours d'exécution, vous pouvez surveiller son état et synchroniser la progression. Étapes détaillées : Installez Sui Binaries : Suivez les instructions de la documentation Sui pour installer les fichiers binaires Sui. Si vous utilisez Docker, suivez les instructions du fichier Docker Readme du nœud Sui Full. Si vous créez à partir des sources, vous devrez cloner le référentiel Sui et le compiler. Configurez le nœud : Nœud complet : vous pouvez configurer un nœud Sui Full à l'aide de Docker ou en le construisant à partir des sources, conformément à la documentation Sui. Nœud de validation : suivez les instructions de la section Configuration du nœud de validation Sui pour configurer un nœud de validation. Cela inclut l'installation et la configuration de Sui, la gestion des clés et la configuration du stockage. Configuration complète du nœud : Arrêtez tout nœud complet en cours d'exécution. Supprimez la base de données et le fichier genesis.blob. Récupérez la source de la dernière version. Réinitialisez votre succursale. Téléchargez le dernier blob Genesis. Mettez à jour votre fichier de configuration fullnode.yaml, si nécessaire. Redémarrez votre nœud Sui Full. Exécutez le nœud : Démarrez le nœud Sui à l'aide de la commande appropriée à votre méthode de configuration (par exemple, les commandes sui-node ou Docker). Surveillez le nœud : Surveillez l'état de votre nœud, la progression de la synchronisation et les journaux pour vous assurer qu'il fonctionne correctement. Utilisez des outils tels que la journalisation, le suivi et les métriques pour surveiller le nœud. Le port des métriques par défaut est 9184, mais vous pouvez le modifier dans le fichier fullnode.yaml. Étapes supplémentaires : Inscription au comité : si vous gérez un nœud de validation, vous devez vous inscrire auprès du comité. Liquid Staking : si vous gérez un nœud, vous pouvez également participer au Liquid Staking. Synchronisez votre fork : si vous contribuez au projet Sui, vous devrez synchroniser votre fork avec le référentiel principal. En suivant ces étapes, vous pouvez configurer et exécuter avec succès un nœud Sui.

HaGiang164

May 12, 2025

Article

Dans l'exploration du monde Web3, au-delà de la recherche commune de vitesses de transaction plus rapides et de frais réduits, des défis structurels plus profonds apparaissent de plus en plus. Comment stocker de grandes quantités de données de manière économique ? Comment protéger en toute sécurité les informations sensibles dans un environnement décentralisé ? Des calculs complexes peuvent-ils être exécutés efficacement hors chaîne tout en ayant leurs résultats vérifiés et fiables en chaîne ? De nombreux projets tentent de résoudre ces problèmes en combinant divers services tiers. Cependant, cette méthode s'accompagne souvent d'une complexité d'intégration, de potentiels problèmes de confiance et d'une expérience utilisateur fragmentée. Face à ces défis au niveau de l'infrastructure, la blockchain Sui et son équipe de développement principale Mysten Labs ont proposé une solution plus intégrée. Plutôt que de s'appuyer sur une mosaïque d'outils externes, ils ont conçu une blockchain dotée d'une architecture unique, notamment son modèle centré sur les objets et le langage de programmation Move, tout en créant simultanément trois composants d'infrastructure natifs étroitement connectés : Walrus, Seal et Nautilus. Cet article vise à déballer les concepts de conception qui sous-tendent ces trois composants, à explorer leur fonctionnement, leurs relations les uns avec les autres et les véritables changements qu'ils pourraient apporter aux applications Web3. L'architecture unique de Sui Pour comprendre comment ces trois outils fonctionnent sur Sui, nous devons d'abord examiner certaines caractéristiques clés de la plateforme Sui elle-même. L'une des principales innovations de Sui est son modèle orienté objet, un changement fondamental par rapport à l'architecture traditionnelle basée sur les comptes. Sui traite les jetons, les NFT et même les structures de données complexes comme des « objets » autonomes. Imaginez gérer chaque actif dans une boîte distincte au lieu de tout enregistrer dans un seul registre. Cette conception permet de traiter en parallèle des actions indépendantes, comme la gestion de deux NFT indépendants, pour améliorer le débit. Cette granularité des objets crée une synergie naturelle avec Walrus et Seal : Walrus traite les données stockées comme des objets, tandis que Seal peut associer des règles d'autorisation directement à des objets individuels. En outre, Sui utilise le langage de programmation Move, conçu spécifiquement pour la gestion des actifs numériques. Move met l'accent sur la sécurité et vise à réduire de nombreuses vulnérabilités courantes liées aux contrats intelligents au niveau de la langue. Cette base solide le rend parfaitement adapté à la construction de composants d'infrastructure robustes. En alignant la conception de la chaîne et le développement de l'infrastructure sous un même toit (Mysten Labs), Sui vise à offrir une expérience de développement plus fluide et plus synergique. Walrus : stockage décentralisé programmable et économique Le stockage de fichiers volumineux (images, vidéos, modèles d'IA, collectivement appelés blobs) directement en chaîne est notoirement coûteux. Les solutions de stockage décentralisées existantes présentent chacune des avantages, mais Walrus cherche à trouver un nouvel équilibre entre la rentabilité et l'interactivité des contrats intelligents, en s'attaquant directement aux obstacles financiers liés aux données en chaîne à grande échelle. Au cœur de Walrus se trouve le codage d'effacement, une technique intelligente qui « fragmente » un fichier et ajoute des « indices de restauration » afin que le fichier puisse être reconstruit même en cas de perte de parties. Walrus appelle ces fragments supplémentaires « Red Stuff ». Pensez-y de cette façon : si vous avez deux nombres, disons 3 et 5, et que vous stockez les deux ainsi que leur somme (8), perdre le 3 n'est pas catastrophique. Vous pouvez le récupérer en utilisant 8 - 5 = 3. Les fragments de récupération supplémentaires jouent un rôle similaire, mathématiquement lié aux originaux. Après fragmentation et encodage, Walrus distribue ces fragments sur de nombreux nœuds. Même si certaines partitions disparaissent, le système peut reconstruire le fichier d'origine tant qu'un nombre seuil de fragments est récupéré, ce qui permet d'économiser beaucoup d'espace par rapport à la réplication complète du fichier. Cette approche réduit considérablement les coûts de stockage et pourrait rapprocher la tarification du stockage décentralisé de celle des fournisseurs de cloud centralisés. Plus intéressant encore, Walrus exploite le modèle d'objet de Sui : chaque fichier stocké devient un objet programmable en chaîne. Les développeurs peuvent utiliser Move pour rédiger des contrats intelligents qui gèrent ces objets de stockage, en définissant des règles d'accès, en mettant à jour automatiquement les métadonnées, etc. Le stockage n'est plus simplement passif, il devient une ressource programmable de manière native. Il existe également une couche utilitaire de jetons : l'interaction avec les données de Walrus sur Sui nécessite des jetons SUI pour enregistrer les métadonnées (telles que les noms de fichiers, les tailles, les emplacements de stockage) et éventuellement pour verrouiller les jetons pour les frais de stockage. Si l'adoption de Walrus augmente, la demande de SUI pourrait augmenter, ce qui réduirait l'offre. Seal : le coffre-fort décentralisé et le gardien des accès De nombreuses applications Web3 traitent des données sensibles : identifiants d'utilisateur, informations financières, contenu payant. Dans un contexte décentralisé, comment stocker des secrets en toute sécurité et en contrôler l'accès ? Seal est une solution de gestion décentralisée des secrets (DSM) conçue pour répondre à cette question. L'une de ses technologies de base est le Threshold Encryption. Imaginez un coffre dont l'ouverture nécessite deux clés, chacune détenue par une personne différente. De même, le chiffrement à seuil divise les clés de déchiffrement en plusieurs parties et les distribue à des serveurs de clés indépendants. Ce n'est que lorsqu'un nombre prédéfini d'entre eux collaborent (le seuil) que les données peuvent être déchiffrées. Aucun serveur ne peut le faire seul, ce qui accroît la confiance et augmente la tolérance aux pannes. L'autre caractéristique intelligente de Seal est que la logique de contrôle d'accès est écrite sous la forme Move smart contracts on-chain. Les développeurs peuvent définir des règles claires : par exemple, seuls les utilisateurs détenant un certain NFT ou ayant payé des frais peuvent accéder à certaines données. Cette transparence et cette vérifiabilité distinguent Seal des systèmes d'accès centralisés traditionnels. Lorsqu'un utilisateur ou une application souhaite déchiffrer un secret, il envoie une demande aux serveurs clés. Ces serveurs vérifient les règles de la chaîne. Ce n'est que si les conditions sont remplies qu'ils libèrent leurs fragments clés. Le déchiffrement proprement dit s'effectue sur l'appareil client, de sorte que les serveurs clés ne touchent jamais les données d'origine. Seal peut protéger les données stockées n'importe où, sur Walrus, sur d'autres réseaux décentralisés ou même sur des clouds centralisés. Il est donc idéal pour la messagerie sécurisée, les données privées des utilisateurs, le blocage du contenu payant, le vote confidentiel, etc. Nautilus : rendre le calcul hors chaîne vérifiable en chaîne Les blockchains ne sont pas efficaces pour les tâches complexes ou gourmandes en ressources. Les faire en chaîne est lent, coûteux et compromet la confidentialité. Des solutions telles que Layer 2s ou oracles sont utiles, mais Nautilus explore une autre voie : permettre un calcul hors chaîne fiable. Nautilus utilise une solution matérielle appelée Trusted Execution Environments (TEES). Considérez un TEE comme une zone isolée et sécurisée à l'intérieur d'un processeur. Le code et les données contenus dans cette zone sont protégés du reste du système, y compris du système d'exploitation lui-même. Le flux de travail de base est le suivant : Un développeur déploie une tâche informatique (par exemple, modèles financiers, inférence d'IA, logique de jeu) sur un TEE qu'il contrôle. Une fois la tâche terminée, le TEE produit une attestation cryptographique, une sorte de « reçu » infalsifiable qui prouve : la tâche a été exécutée dans un TEE le code n'a pas été falsifié le processus s'est terminé avec succès. Cette attestation et le résultat sont soumis à un contrat intelligent Move sur Sui. Le contrat vérifie l'attestation (par exemple, la validité de la signature et le hachage du code). Ce n'est que si la vérification est réussie que le contrat accepte le résultat et procède à des actions en chaîne. Nautilus associe l'informatique hors chaîne hautes performances à la vérifiabilité et à la confiance en chaîne, sans exposer de détails sensibles. Nautilus en action : l'affaire Bluefin Bluefin, une plateforme de trading perpétuel décentralisée, en est un exemple concret. La plupart des plateformes de trading performantes sont confrontées à un dilemme : maintenir les carnets d'ordres entièrement connectés à la chaîne offre de la transparence mais est lent et coûteux ; les déplacer hors chaîne améliore la vitesse mais crée des problèmes de confiance. Bluefin utilise Nautilus pour combler cette lacune : • L'appariement des commandes s'effectue au sein d'un TEE, garantissant un traitement sécurisé et isolé. • Nautilus fournit la preuve cryptographique que la logique correspondante a fonctionné correctement. • Les preuves et les résultats sont soumis en chaîne, où les contrats intelligents les vérifient avant d'exécuter le règlement. Cette approche permet à Bluefin de proposer un appariement rapide hors chaîne avec des garanties de confiance en chaîne, ce qui la rend viable pour les DeFi à forte performance, comme le trading de produits dérivés. Bien entendu, cela fait passer une partie de la confiance du pur consensus de la blockchain au matériel et à la mise en œuvre du TEE.