Explorer
Connectez-vous aux communautés et découvrez de nouvelles idées.
Gagne ta part de 1000 Sui
Gagne des points de réputation et obtiens des récompenses pour avoir aidé la communauté Sui à se développer.
Communautés
Sui is a Layer 1 protocol blockchain designed as the first internet-scale programmable blockchain platform.
Meilleurs articlesMeilleurs membres- 4622
- 4200
- 4038
Move is an executable bytecode language used to implement custom transactions and smart contracts.
Meilleurs articlesMeilleurs membres- 271
- 260
- 251
Peera is a decentralized questions and answers protocol for Web3 where users can organize and store their interests and skills, creating a common community platform
Meilleurs articlesMeilleurs membres- 328
- 286
- 225
The InterPlanetary File System (IPFS) is a protocol, hypermedia and file sharing peer-to-peer network for storing and sharing data in a distributed file system.
Meilleurs articlesMeilleurs membres- 25
- 20
- 20
Walrus is a decentralized storage and data availability protocol designed specifically for large binary files, or "blobs"
Meilleurs articlesMeilleurs membres- 41
- 40
- 38
Prime
Erreur Sui Move - Impossible de traiter la transaction Aucune pièce de gaz valide n'a été trouvée pour la transaction
Quand je fais ça : //Séparer le paiement de la pièce principale const [PaymentCoin] = TX.SplitCoins ( tx.object (PrimaryCoin.CoinObjectId), [tx.pure.u64 (montant de paiement requis)] ) ; //Utilisez la pièce originale pour le paiement de l'essence TX.setGasPayment ([{ ID de l'objet : PrimaryCoin.CoinObjectID, version : PrimaryCoin.version, résumé : PrimaryCoin.Digest }]) ; Tx. Budget gazier fixe (10_000_000) ; Il se plaint du fait que les objets mutables ne peuvent pas apparaître plus d'une fois dans une transaction. Lorsque je supprime le paiement du gaz, il se plaint « Impossible de traiter la transaction » Aucune pièce de gaz valide n'a été trouvée pour la transaction. ». Ma fonction de contrat accepte 0,01 sui en échange d'un NFT
29- +15Xavier.eth308PourSuiJun 27, 2025
Échec de la transaction Sui : objets réservés pour une autre transaction
Je rencontre un problème persistant JsonRpcErrorlorsque j'essaie d'exécuter des transactions sur Sui. L'erreur indique que les objets sont réservés pour une autre transaction, même si j'ai implémenté un traitement séquentiel des transactions avec des retards. JsonRpcError: Failed to sign transaction by a quorum of validators because one or more of its objects is reserved for another transaction. Other transactions locking these objects: AV7coSQHWg5vN3S47xada6UiZGW54xxUNhRv1QUPqWK (stake 33.83) 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 J'ai essayé : Exécution séquentielle des transactions (en attente de la fin de la transaction précédente) Ajout de délais de 3 secondes entre les transactions Et j'obtiens toujours la même erreur. Utilisation de Sui RPC pour la soumission des transactions. Le même identifiant d'objet apparaît plusieurs fois dans la liste de verrouillage. Une erreur se produit même avec un séquençage minutieux des transactions. Qu'est-ce qui fait que les objets sont « réservés » pour d'autres transactions ? Comment puis-je vérifier correctement si un objet est disponible avant de l'utiliser dans une transaction ? Existe-t-il des bonnes pratiques pour gérer les verrous d'objets dans Sui ? Cela pourrait-il être lié au calendrier de finalité de la transaction ? Quelqu'un a-t-il déjà rencontré ce problème ? Toute information sur la gestion appropriée des objets dans les transactions Sui serait grandement appréciée !
48 - +15Xavier.eth308PourSuiJun 17, 2025
Comment les contraintes de capacité interagissent-elles avec les champs dynamiques dans des collections hétérogènes ?
Je suis en train de créer une place de marché qui doit gérer plusieurs types d'actifs avec des exigences de capacité différentes, et je me suis posé quelques questions fondamentales concernant le système de types de Move. Je souhaite stocker différents types de ressources dans la même collection, mais leurs fonctionnalités sont différentes : NFT classiques : key + store(transférables) Jetons Soulbound : key uniquement (non transférables) Actifs personnalisés avec restrictions de transfert public struct Marketplace has key { id: UID, listings: Bag, // Want to store different asset types here } // This works for transferable assets public fun list_transferable( marketplace: &mut Marketplace, asset: T, price: u64 ) { /* ... */ } // But how to handle soulbound assets? public fun list_soulbound( // No store ability marketplace: &mut Marketplace, asset_ref: &T, // Can only take reference price: u64 ) { /* How do I store metadata about this? */ } Questions clés : Compétences requises : lors de l'utilisationdynamic_field::add(), en a-t-on Vtoujours besoin store au moment de la compilation ? Les types de wrapper peuvent-ils contourner ce problème ? Stockage hétérogène : un seul sac peut-il stocker des objets dotés de différents ensembles de capacités (key + store + copyvskey + store) et les gérer différemment lors de l'exécution ? Sécurité des types : étant donné que les champs dynamiques permettent d'effacer les caractères, comment puis-je garantir la sécurité des types lors de la récupération des valeurs ? Quel est le modèle de stockage des métadonnées de type ? Modèle de témoin : comment fonctionnent les contraintes de capacité avec les types de fantômes ? Puis-je stocker Assetet stocker Assetdans la même collection et extraire les informations de type ultérieurement ? Construire un système dans lequel les NFT, les jetons soul bound et les actifs restreints nécessitent tous des fonctionnalités de marché, mais avec une sémantique de transfert différente. J'ai essayé des types de wrapper, plusieurs collections par ensemble de capacités, un stockage de métadonnées de type séparé. Chacune comporte des compromis entre la sécurité du type, les coûts du gaz et la complexité.
07
Le plus nouveau
Le rôle de Sui dans la rationalisation du commerce mondial et de l'infrastructure de la chaîne d'approvisionnement
Introduction : Le commerce mondial est un goulot d'étranglement en matière de confiance La chaîne d'approvisionnement moderne couvre des dizaines de pays, des centaines de fournisseurs et d'innombrables documents, dont beaucoup sont papier, sujets aux erreurs ou invérifiables. Du suivi des conteneurs aux déclarations douanières et aux certificats d'origine, le commerce mondial est entravé par : • Fragmentation des données entre les juridictions et les systèmes • Documentation frauduleuse et contrefaçon • Résolution des litiges inefficace • Conciliation coûteuse et manque de transparence Sui propose une plateforme blockchain programmable, transparente et évolutive capable de modéliser l'ensemble du processus commercial mondial, avec une automatisation sécurisée, une traçabilité et une gouvernance modulaire. Pourquoi utiliser Sui pour le commerce et la chaîne d'approvisionnement ? Contrairement à de nombreuses blockchains à usage général, l'architecture orientée objet et l'exécution parallèle de Sui permettent aux entreprises de : Avantage des fonctionnalités dans les applications commerciales Modélisation basée sur les objets Modélisez des actifs du monde réel tels que des conteneurs, des envois, des documents Évolutivité horizontale Gérez le suivi et les mises à jour des événements à volume élevé Authentification ZKLogin Identifiez en toute sécurité les utilisateurs (agents des douanes, fournisseurs) Enregistrement des événements et émissions Suivez l'intégralité de la chaîne de contrôle sur les réseaux Les modules Custom Move encodent la logique des contrats (par exemple, règles d'origine, tarifs) Sui transforme les documents commerciaux en actifs numériques vérifiables, et les processus en flux de travail transparents et auto-exécutables. Cas d'utilisation : envoi international avec certificat d'origine Passons en revue un cas d'utilisation simplifié. 👟 Scénario : expédition de baskets du Vietnam vers l'UE Parties prenantes : • Fabricant à Ho Chi Minh • Transporteur de marchandises • Courtiers en douane • Importateur de l'UE Flux de travail basé sur l'interface utilisateur : ShipmentObject créé par le fabricant (origine, numéro de lot, contenu) Certificat d'origine de l'objet délivré par l'autorité commerciale du Vietnam La compagnie de fret met à jour TransitStatusObject au fur et à mesure que l'expédition est L'agent des douanes vérifie les documents et signe numériquement le dédouanement Un détaillant de l'UE reçoit un produit vérifiable et des métadonnées sur la chaîne Avantages : • Toutes les parties prenantes ont accès à une piste d'audit infalsifiable • Pas de partage de documents par e-mail ni de falsification de PDF • Conformité immédiate aux règles d'import/export Architecture d'un protocole commercial basé sur Sui Chaque actif ou document de la chaîne d'approvisionnement devient un citoyen de premier ordre sur la chaîne. 🔩 Modules de base : • ShipmentObject : inclut les articles, le poids, l'origine et un identifiant unique • CertificateModule : vérifie l'authenticité des documents et les rôles des émetteurs • Module d'approbation des douanes : les agents des douanes peuvent approuver/rejeter l'expédition • TransitEventModule : émet des mises à jour de localisation (par exemple, port scanné, chargé) 🔐 Exemple : module de déplacement pour la vérification des certificats module trade : :CertificateModule { struct Le certificat a une clé { pays_origine : vecteur, émetteur : adresse, valide_jusqu'à : u64, } public fun issue_certificate (émetteur : &signataire, pays : vecteur) { let cert = Certificat { pays_origine : pays, émetteur : signer : :address_of (émetteur), valide_jusqu'à : 1690000000, } ; move_to (émetteur, certificat) ; } public fun validate (cert : &Certificate) : bool { timestamp : :now () < cert.valid_until } } Cette logique garantit que seules les autorités de confiance peuvent émettre et valider des documents commerciaux. Interopérabilité : collaboration transfrontalière en temps réel La logique modulaire d'identité et d'objet de Sui permet une coopération interjuridictionnelle sans contrôle central : Action des parties prenantes concernant Sui L'autorité portuaire ajoute un événement de numérisation à ShipmentObject L'Office national des exportations émet un certificat signé numériquement Le transporteur met à jour l'ETA des expéditions et les rapports de condition L'agent des douanes vérifie l'authenticité et la conformité en chaîne Le détaillant récupère un historique vérifiable des produits et des métadonnées sur le CO2 Grâce aux API et aux tableaux de bord basés sur Sui, même les acteurs non techniques peuvent participer au protocole en toute sécurité. Prévention des fraudes et traçabilité La fraude commerciale mondiale entraîne des milliards de dollars de pertes de revenus chaque année. Sui combat cela avec : • Documents signés numériquement liés à l'identité via ZKLogin • Chaîne de traçabilité immuable avec événements horodatés • Jetons de marchandises basés sur le NFT avec certifications associées • Déclencheurs intelligents qui empêchent la falsification ou les transferts non autorisés Exemple : preuve anti-contrefaçon Chaque jeton de produit de luxe (par exemple, un sac à main de créateur) peut : • Lien vers le certificat d'origine + le numéro de lot d'usine • Inclure un code QR lié à un objet en chaîne • Empêcher la revente à moins d'être authentifié par un compte vérifié Crédits de carbone et intégration des critères ESG Les entreprises sont soumises à des pressions pour prouver la durabilité de leurs chaînes d'approvisionnement. Sui peut : • Émissions de carbone records par expédition ou unité de produit • Permettre à des tiers (auditeurs, ONG) de vérifier les scores carbone • Joignez des rapports ESG à l'expédition de NFT • Permettre le commerce en chaîne ou la réclamation de compensations de carbone Exemple : les journaux de mouvements d'un conteneur d'expédition sont utilisés pour estimer les émissions, et un CarbonScoreObject est attaché au jeton du produit. Les acheteurs peuvent le vérifier avant d'acheter. Considérations relatives à l'évolutivité des réseaux mondiaux L'exécution parallélisée et la faible latence de Sui le rendent prêt à être utilisé en entreprise : Scale Requirement Sui Feature 100 000 mises à jour quotidiennes Traitement parallèle des objets Plus de 100 parties prenantes par chaîne Autorisations au niveau de l'objet L'API en temps réel nécessite des RPC à haut débit et des abonnements à des événements Conservation des données Historique des objets + journaux en chaîne Sui peut évoluer aussi rapidement que la demande logistique mondiale augmente. Défis et stratégies de déploiement Stratégie d'atténuation des défis Contraintes relatives aux données juridictionnelles Utiliser des modules spécifiques à la région + des balises d'objet Connaissances limitées en matière de blockchain Créez des applications DApps et des interfaces utilisateur Web conviviales Intégration avec les systèmes existants Middleware + connecteurs hors chaîne Audit de sécurité + conformité Journaux d'émissions + attestations signées Commencez par une voie commerciale ou une gamme de produits, puis étendez progressivement les protocoles et les intégrations. Conclusion : Construire l'avenir du commerce mondial sur Sui L'architecture programmable et évolutive centrée sur les objets de Sui constitue la base d'un protocole commercial mondial et vérifiable. Avec Sui, les entreprises peuvent : • Réduisez les formalités administratives, les retards et les fraudes • Automatisez les flux de travail multipartites • Bénéficiez d'une traçabilité complète et d'une conformité ESG • Créez des couches de données partagées sans serveurs centraux Dans un monde où la confiance, la transparence et la rapidité définissent le succès commercial, Sui est bien plus qu'une blockchain, c'est l'infrastructure de confiance pour les chaînes d'approvisionnement de demain.
0🔒 Sécurisation de votre application Sui : une liste de contrôle de sécurité pratique
S'appuyer sur Sui est passionnant : son modèle centré sur l'objet ouvre la voie à de nouveaux modèles de conception et à un parallélisme plus rapide. Mais ⚠️ nouveaux modèles = nouvelles erreurs. Les bugs de propriété, les fuites d'entiercement ou la négligence des clés d'administration peuvent entraîner des pertes coûteuses. Ce guide vous propose une liste de contrôle de sécurité étape par étape 📝 ainsi qu'un exemple pratique de marketplace pour vous montrer comment éviter les pièges les plus courants. ✅ 1) La liste de contrôle de sécurité Sui 🔑 Le moindre privilège • Ne vous fiez pas à une seule « clé d'administration » globale. • Utilisez des objets de capacité pour obtenir de l'autorité. • Protégez les pouvoirs administratifs critiques grâce à une gouvernance multisignature ou en chaîne. ⚖️ Transferts séquestres atomiques • Sécurisez toujours les actifs dans des objets de liste dédiés. • Utilisez des blocs de transactions programmables (PTB) pour les échanges atomiques → évitez les dépenses anticipées et les doubles dépenses. 🛡️ Validez toutes les entrées • Dans Move, vérifiez les longueurs, les limites et les contraintes des vecteurs. • Validez la désérialisation et rejetez les objets mal formés. • Ne présumez jamais la sécurité des entrées simplement parce que l'objet existe sur la chaîne. 🧪 Testez et fuzz de manière agressive • Rédigez des tests négatifs : entrées non valides, mises à jour simultanées, épuisement des gaz. • Ajoutez du fuzzing pour les flux de transactions inattendus. • Automatisez dans CI pour détecter les régressions à un stade précoce. 🔐 Gestion des clés • Stockez les clés d'administration dans des portefeuilles matériels. • Utilisez le multisig pour les actions de gouvernance. • Faites pivoter les touches lorsque les membres de l'équipe partent. 👀 Audits et mesures incitatives • Faites auditer les modules Move critiques. • Lancez un programme Bug Bounty à des fins de test communautaire. • N'oubliez pas : les yeux extérieurs détectent ce qui vous manque. 🏪 2) Exemple pratique : un marché sûr Voici comment appliquer la liste de contrôle dans une DApp de la place de marché : • Sécurisez les NFT en toute sécurité : Le vendeur déplace le NFT vers un objet d'annonce. Le contrat de la place de marché ne peut pas accepter de fonds sans l'approbation du vendeur. • Gérez correctement les redevances : Calculez les redevances dans le PTB, en veillant à une répartition correcte des frais (attention aux arrondis !). • Réentrée ? Pas ici : Le modèle de ressources de Move empêche la copie/la réentrée dès sa conception. Testez tout de même tous les flux pour vous assurer qu'il n'y a aucune faille logique. 📚 Sources et lectures complémentaires • Sui Docs : concepts et transactions • Livre blanc Sui (modèle centré sur l'objet) • Documentation sur le SDK TypeScript de Mysten Labs • Carnet de films • Sur GitHub Repo ✨ À retenir : sur Sui, la sécurité est moins une question de bogues de réentrée de type EVM qu'une question de propriété, d'autorité et d'atomicité. Si vous suivez la liste de contrôle, vous réduirez considérablement votre surface d'attaque tout en protégeant les actifs des utilisateurs.
0De l'installation propre à votre premier objet connecté à la chaîne sans rester bloqué
Vous commencez par installer la CLI Sui et la chaîne d'outils Move pour créer et publier du code, puis vous exécutez sui client active-address pour confirmer qu'une paire de touches fonctionne et vous appuyez sur le robinet pour tester SUI, puis vous créez un nouveau package Move avec le modèle pour ne pas vous opposer à la structure des dossiers, puis vous modifiez un seul module pour définir un objet simple avec un champ propriétaire et quelques méthodes telles que init, update et transfer afin de pouvoir exercer Modélisez rapidement les objets de Sui, puis vous compilez avec sui move build et corrigez toutes les erreurs affichées par le compilateur car c'est votre boucle de feedback la plus rapide, puis vous publiez avec sui client publish --gas-budget et vous récupérez les ID de package et de module depuis la sortie pour pouvoir appeler des fonctions, puis vous appelez votre fonction d'entrée d'initialisation pour créer un objet et copiez l'ID de l'objet depuis les effets de la transaction, puis vous exécutez sui client object pour voir la version, le propriétaire et les champs afin de confirmer que la chaîne a écrit ce que vous attendez, si vous rencontrez un « gaz insuffisant », vous réduisez le budget de gaz ou demandez plus de tests SUI depuis chaque publication et chaque appel coûtent de l'essence, si vous obtenez « module introuvable », vous avez probablement utilisé le mauvais identifiant de package ou si vous avez oublié de reconstruire, si votre transfert échoue en raison d'une erreur de capacité, vous avez probablement partagé l'objet alors que vous vouliez dire possédé ou vous avez oublié de transmettre la forme d'argument correcte. Une fois les bases fonctionnent, vous scriptez le flux dans un shell ou un script JavaScript afin qu'une commande crée, publie, crée, mette à jour et transfère, ce qui permet de gagner du temps et d'éviter les fautes de frappe. Enfin, vous envoyez cet exemple minimal à un dépôt afin que vos coéquipiers puissent cloner et exécuter les mêmes étapes en quelques minutes ; en traitant l'objet comme une unité de pensée plutôt que comme un contrat global unique, vous alignez votre façon de coder avec la façon dont Sui stocke l'état, ce qui permet de garder votre modèle mental propre et d'éviter les réinscriptions difficiles à déboguer ou les courses à l'État mondial que vous pourriez rencontrer sur d'autres chaînes, et comme Sui parallélise les transactions d'objets personnels, vous en voyez également une confirmation rapide au fur et à mesure que vous itérez, ce qui rend l'intégration encore plus agréable.
0
Sans réponse
Tendance
Bot AMM dans l'écosystème Sui
Quelles sont les principales caractéristiques et fonctionnalités des robots AMM au sein de l'écosystème Sui ? Comment améliorent-ils les mécanismes de trading traditionnels et quels avantages offrent-ils aux utilisateurs utilisant les protocoles DeFi sur le réseau Sui ? Dois-je en construire un ou je peux utiliser Turbos Finance par exemple
94- 0xduckmove2038PourSuiApr 08, 2025
👀 SEAL- Je pense que la confidentialité des données Web3 est sur le point de changer
👀 SEAL est en ligne sur Sui Testnet — Je pense que la confidentialité des données Web3 est sur le point de changer Dans le Web3, il est courant d'entendre des phrases telles que* « les utilisateurs sont propriétaires de leurs données »* ou* « décentralisé par conception »*. Mais à y regarder de plus près, de nombreuses applications s'appuient toujours sur des infrastructures centralisées pour gérer les données sensibles, en utilisant des services tels qu'AWS ou Google Cloud pour la gestion des clés. Cela introduit une contradiction : la décentralisation en surface, la centralisation en dessous. Et s'il existait un moyen de gérer les secrets en toute sécurité, sans renoncer à la décentralisation ? Présentation de SEAL — Gestion décentralisée des secrets (DSM), désormais disponible sur le Sui Testnet. SEAL vise à corriger l'une des plus grandes hypocrisies du Web3 : crier à la décentralisation tout en utilisant secrètement AWS Vous me demandez peut-être : Qu'est-ce que SEAL ? SEAL est un protocole qui vous permet de gérer les données sensibles de manière sécurisée etdécentralisée, spécialement conçu pour le monde Web3. Considérez-le comme une couche de contrôle d'accès axée sur la confidentialité qui se connecte à votre DApp. Vous pouvez considérer SEAL comme une sorte de verrou programmable pour vos données. Vous ne vous contentez pas de verrouiller et de déverrouiller des éléments manuellement : vousinscrivez des politiques directement dans vos contrats intelligents, à l'aide de Move on Sui. Supposons que vous créiez une DApp où : Seuls les détenteurs de NFT peuvent débloquer un tutoriel premium Ou peut-être qu'un DAO doit voter avant que des fichiers sensibles ne soient révélés Ou vous souhaitez que les métadonnées soient verrouillées dans le temps et ne soient accessibles qu'après une date précise SEAL rend tout cela possible. Le contrôle d'accès se fait en chaîne, entièrement automatisé, aucun administrateur n'est nécessaire pour le gérer. Juste de la logique, intégrée à la blockchain. SEAL rend tout cela possible. Le contrôle d'accès se fait en chaîne, entièrement automatisé, aucun administrateur n'est nécessaire pour le gérer. Juste de la logique, intégrée à la blockchain. Un autre élément intéressant est la façon dont SEAL gère lechiffrement. Il utilise ce que l'on appelle lechiffrage à seuil, ce qui signifie qu'aucun nœud ne peut déchiffrer les données. Il faut un groupe de serveurs pour fonctionner ensemble, un peu comme en mode multi-sig, mais pour débloquer des secrets. Cela permet de répartir la confiance et d'éviter le problème habituel de point de défaillance unique. Et pour garantir la confidentialité des informations, SEAL chiffre et déchiffre toutcôté client. Vos données ne sont jamais visibles par aucun backend. Il reste entre vos mains, littéralement, sur votre appareil. et SEAL ne se soucie pas de l'endroit où vous stockez vos données. Qu'il s'agisse d'IPFS, d'Arweave, de Walrus ou d'une autre plateforme, SEAL n'essaie pas de contrôler cette partie. Il se concentre uniquement surqui est autorisé à voir quoi, et non sur où les objets sont stockés. Donc oui, il ne s'agit pas simplement d'une bibliothèque ou d'une API, c'est unecouche de confidentialité par défaut, dont l'accès est contrôlé et dont l'accès est contrôlé, pour votre DApp. SEAL comble une lacune assez critique. Décrivons cela un peu plus. Si vous créez une DApp qui traitetoute forme de données sensible(contenu sécurisé, documents utilisateur, messages cryptés, même des métadonnées NFT verrouillées dans le temps), vous rencontrerez le même problème : ➡️ Comment gérer les accès en toute sécurité, sans recourir à un service centralisé ? Sans quelque chose comme SEAL, la plupart des équipes non plus : Utilisez des outils centralisés tels qu'AWS KMS ou Firebase, ce qui va clairement à l'encontre de la décentralisation Ou essayez de corriger vous-même une logique de chiffrement à moitié cuite, qui s'avère généralement fragile et difficile à auditer https://x.com/EmanAbio/status/1908240279720841425?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1908240279720841425%7Ctwgr%5E697f93dc65359d0c8c7d64ddede66c0c4adeadf1%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fwww.notion.so%2Fharryph%2FSEAL-Launches-on-Sui-Testnet-1cc4f8e09bb380969c0dcc627b96cc22 Aucun de ces modèles n'est bien adapté. Surtout pas lorsque vous essayez de créer des applications fiables pour plusieurs chaînes ou communautés. SEAL rend l'ensemble de ce processus modulaire et programmable. Vous définissez vos règles d'accès dans les contrats intelligents Move, et SEAL s'occupe du reste (génération de clés, approbations de déchiffrement et application des droits d'accès), le tout sans que personne n'émette manuellement des clés ou n'effectue de vérifications en arrière-plan. Mieux encore, ces règles sontauditables et immuables : une fois qu'elles sont connectées, elles suivent le contrat, pas un administrateur humain. Donc, au lieu de demander « qui doit gérer l'accès à ces données ? » il vous suffit de demander : « Quelle logique devrait définir l'accès ? » > ... et laissez la chaîne s'en occuper. Propre et évolutif. C'est ce qui rend SEAL pertinent pour bien plus que de simples « outils de sécurité » : c'est une couche de base pourtoute DApp soucieuse de la confidentialité, de la conformité ou de la logique d'accès dynamique. C'est un petit changement, mais cela change beaucoup la façon dont nous envisageons les données dans le Web3. Au lieu de chiffrer après le déploiement ou de faire appel à des services externes, vous commencez par intégrer la confidentialité et l'accès entièrement géré par une logique de contrat intelligent. Et c'est exactement ce dont Web3 a besoin en ce moment. Comment fonctionne réellement SEAL ? Nous avons expliquéce qu'est SEALetpourquoi Web3 en a besoin, voyons comment il est réellement construit sous le capot. C'est dans cette partie que les choses deviennent plus techniques, mais dans le bon sens. L'architecture est élégante une fois que vous voyez comment toutes les pièces s'emboîtent. À un niveau élevé, SEAL fonctionne en combinant lalogique d'accès en chaîneavec lagestion des clés hors chaîne, en utilisant une technique appeléeIdentity-Based Encryption (IBE). Cela permet aux développeurs de crypter les données sous forme d'identité, puis de s'appuyer sur des contrats intelligents pour définir qui est autorisé à les déchiffrer. Étape 1 : Règles d'accès dans les contrats intelligents (sur Sui) Tout commence par le contrat intelligent. Lorsque vous utilisez SEAL, vous définissez une fonction appelée seal_approve dans votre contrat Move. C'est là que vous écrivez vos conditions de déchiffrement. Par exemple, voici une règle de verrouillage temporel simple écrite dans Move : entry fun seal_approve(id: vector, c: &clock::Clock) { let mut prepared: BCS = bcs::new(id); let t = prepared.peel_u64(); let leftovers = prepared.into_remainder_bytes(); assert!((leftovers.length() == 0) && (c.timestamp_ms() >= t), ENoAccess); } Une fois déployé, ce contrat fait office de gardien. Chaque fois que quelqu'un souhaite déchiffrer des données, sa demande sera vérifiée par rapport à cette logique. Si elle passe, la clé est relâchée. Si ce n'est pas le cas, ils sont bloqués. Personne n'a besoin d'intervenir. ##Étape 2 : Chiffrement basé sur l'identité (IBE) C'est là que la magie opère. Au lieu de chiffrer les données pour une adresse de portefeuille spécifique (comme avec PGP ou RSA), SEAL utilise deschaînes d'identité, ce qui signifie que vous chiffrez selon un format tel que : 0 x adresse du portefeuille dao_voted:proposal_xyz PKGID_2025_05_01 (règle basée sur l'horodatage) ou même game_user_nft_holder Lorsque les données sont cryptées, elles se présentent comme suit : Encrypt(mpk, identity, message) mpk = clé publique principale (connue de tous) identité = le destinataire défini par la logique message = les données réelles Plus tard, si quelqu'un souhaite déchiffrer, le serveur de clés vérifie s'il correspond à la politique (via l'appel seal_approve onchain). S'il est approuvé, il renvoie une clé privée dérivée pour cette identité. Derive(msk, identity) → sk Decrypt(sk, encrypted_data) L'utilisateur peut ensuite déchiffrer le contenu localement. Le cryptage est donc effectué sans avoir besoin de savoir qui va déchiffrer à l'avance. Il vous suffit de définir les conditions, et SEAL s'occupera du reste plus tard. C'est dynamique. ##Étape 3 : Le serveur de clés — Offchain, mais pas centralisé Vous vous demandez peut-être : qui détient ces clés principales ? C'est là qu'intervient leKey Serverde SEAL. Considérez-le comme un backend qui : Contient la clé secrète principale (msk) Surveille les contrats en chaîne (comme votre logique seal_approve) N'émet des clés dérivées que si les conditions sont remplies Mais, et c'est essentiel, SEAL ne s'appuie pas sur un seul serveur de clés. Vous pouvez l'exécuter enmode seuil, où plusieurs serveurs indépendants doivent être d'accord avant qu'une clé de déchiffrement ne soit émise. Par exemple : 3 serveurs de clés sur 5 doivent approuver la demande. Cela évite les points de défaillance centraux et permet également la décentralisation au niveau de la couche de gestion clé. Mieux encore, à l'avenir, SEAL prendra en charge leMPC (calcul multipartite) et lesconfigurations basées sur des enclave(comme TEE), afin que vous puissiez obtenir des garanties encore plus strictes sans compromettre la convivialité. ##Étape 4 : Décryptage côté client Une fois la clé renvoyée à l'utilisateur, le déchiffrement proprement dit s'effectuesur son appareil. Cela signifie que : Le serveur ne voit jamais vos données Le backend ne stocke jamais de contenu déchiffré Seul l'utilisateur peut accéder au message final Il s'agit d'un modèle de confidentialité solide. Même si quelqu'un compromet la couche de stockage (IPFS, Arweave, etc.), il ne peut toujours pas lire les données sans passer la logique d'accès. Voici le modèle mental rapide : Cette structure facilite la création de dApps où les règles d'accès ne sont pas codées en dur : elles sont dynamiques, vérifiables et entièrement intégrées à votre logique de chaîne. ##L'équipe derrière SEAL SEAL est dirigé parSamczsun, une figure bien connue de la communauté de la sécurité blockchain. Ancien partenaire de recherche chez Paradigm, il a audité et sauvé plusieurs écosystèmes contre des exploits majeurs. Maintenant, il se concentre à plein temps sur l'intégration de SEAL au cœur de l'infrastructure de confidentialité de Web3. Grâce à son expérience et à sa crédibilité, SEAL n'est pas un simple outil expérimental comme les autres, mais une tentative sérieuse de rendre la confidentialité des données décentralisée à la fois pratique et évolutive. Alors que SEAL est mis en ligne sur le Sui Testnet, il apporte une nouvelle norme sur la façon dont les applications Web3 peuvent gérer les secrets. En combinant le contrôle d'accès en chaîne, le cryptage des seuils et la confidentialité côté client, SEAL offre une base plus fiable pour le traitement décentralisé des données. Que vous créiez des DApps, des DAO ou des jeux décentralisés, SEAL fournit une puissante boîte à outils pour renforcer le contrôle d'accès et protéger les données des utilisateurs sans compromettre la décentralisation. Si le Web3 veut aller de l'avant, une infrastructure sécurisée comme SEAL n'est pas facultative, elle est essentielle
8 Comment fusionner deux pièces dans Move ?
*J'essaie de comprendre cet aspect du réseau Sui parce que je suis en train de créer, de déboguer ou de déployer quelque chose qui touche à ce domaine. Je souhaite une explication détaillée du fonctionnement de ce mécanisme ou de cette fonctionnalité, ainsi que l'utilisation pertinente de la CLI, la structure du code Move ou les concepts architecturaux. Mon objectif est d'obtenir suffisamment de clarté pour appliquer ces connaissances à un projet réel, qu'il s'agisse d'un contrat intelligent personnalisé, d'un système NFT, d'une intégration de portefeuille ou d'un outil DeFi. Le réseau Sui possède des caractéristiques uniques par rapport aux chaînes EVM. Je m'intéresse donc particulièrement à ce qui le distingue et à la manière dont cela affecte les meilleures pratiques de développement. Il serait utile de disposer d'exemples de code, d'exemples de ligne de commande ou d'erreurs typiques à surveiller, en particulier lors de l'utilisation de la CLI Sui, du SDK ou d'un déploiement sur localnet/testnet. En fin de compte, je souhaite éviter les erreurs courantes, suivre les meilleurs principes de sécurité et m'assurer que les fonctionnalités sur lesquelles je travaille se comportent comme prévu dans des conditions réalistes. *
715