Sui.

Explorer

Connectez-vous aux communautés et découvrez de nouvelles idées.

Sui.X.Peera.

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

Filtrer :Toutes les blockchains

Prime

  • Xavier.eth.Peera.
    Xavier.eth313
    PourSuiJun 27, 2025
    +15

    É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 !

    2
    4
  • Xavier.eth.Peera.
    Xavier.eth313
    PourSuiJun 17, 2025
    +15

    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é.

    0
    4
  • Peera Admin.Peera.
    Peera Admin37
    PourSuiMay 29, 2025
    +10

    Pourquoi BCS exige-t-il un ordre de champs exact pour la désérialisation alors que les structures Move ont des champs nommés ?

    Pourquoi BCS exige-t-il un ordre de champs exact pour la désérialisation alors que les structures Move ont des champs nommés ? J'ai approfondi le codage/décodage BCS dans Move, en particulier pour la communication inter-chaînes et le traitement des données hors chaîne. En parcourant les exemples de la documentation de Sui Move, j'ai rencontré un comportement qui semble contre-intuitif et j'essaie de comprendre les décisions de conception sous-jacentes. Selon la spécification BCS, « 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 ». Cela signifie que lors de la désérialisation, nous devons utiliser peel_*les fonctions exactement dans le même ordre que la définition du champ de structure. Mes questions spécifiques : Justification de la conception : pourquoi BCS exige-t-il une correspondance exacte de l'ordre des champs alors que les structures Move ont des champs nommés ? Ne serait-il pas plus robuste de sérialiser les noms de champs à côté des valeurs, de la même manière que le JSON ou d'autres formats auto-descriptifs ? Interaction entre types génériques : La documentation mentionne que « les types contenant des champs de type générique peuvent être analysés jusqu'au premier champ de type générique ». Considérez cette structure : struct ComplexObject has drop, copy { id: ID, owner: address, metadata: Metadata, generic_data: T, more_metadata: String, another_generic: U } Comment fonctionne exactement la désérialisation partielle ici ? Puis-je désérialiser jusqu'à more_metadata et ignorer les deux champs génériques, ou est-ce que le premier champ générique (generic_data) bloque complètement la poursuite de la désérialisation ? Cohérence entre les langues : lorsque vous utilisez la bibliothèque JavaScript @mysten /bcs pour sérialiser les données qui seront consommées par les contrats Move, que se passe-t-il si : Je réorganise accidentellement les champs de l'objet JavaScript ? La définition de la structure Move change l'ordre des champs lors d'une mise à niveau du contrat ? J'ai des structures imbriquées avec leurs propres paramètres génériques ? Implications pratiques : dans les systèmes de production, comment les équipes gèrent-elles l'évolution du schéma BCS ? Versiez-vous vos schémas BCS ou vous attendez-vous à ce que l'ordre des champs de structure soit immuable une fois déployé ?

    5
    3

Le plus nouveau

  • CarlkawIy.Peera.
    CarlkawIy259
    PourSuiJul 01, 2025

    Comment récupérer des pièces SUI d'un ancien portefeuille ?

    J'ai essayé de localiser mes pièces SUI lors de la création d'un nouveau compte Slush, mais je ne les vois pas. Comment puis-je vérifier si j'utilise la bonne phrase pour importer mon ancien portefeuille ?

    0
    2
  • MiniBob.Peera.
    MiniBob701
    PourSuiJul 01, 2025

    Maîtriser les concepts du langage mobile — Cours #2

    Alors que leCours #1 que j'ai déjà fait vous a présenté les bases de la rédaction de contrats intelligents dans Move et de la création de DApps simples sur la blockchain Sui, ce cours se concentre surapprofondir votre compréhension du langage Move lui-même, de son puissant système de types aux modèles avancés tels que les génériques, les événements, les modules et les mécanismes de contrôle d'accès. À la fin de ce cours, vous serez capable de : Rédigez un code Move modulaire, réutilisable et sécurisé Utiliser efficacement les génériques, les capacités et les types de ressources Implémentez un contrôle d'accès précis à l'aide de fonctionnalités Émettez et écoutez des événements pour une intégration hors chaîne Travaillez avec des structures de données complexes telles que des tableaux et des vecteurs Comprenez en quoi Move diffère des autres langages de contrats intelligents tels que Solidity Plongeons au cœur du langage Move ! Étape 1 : Comprendre les fonctionnalités linguistiques de base de Move Move est conçu dans un souci de sécurité et de clarté. Explorons certaines des fonctionnalités les plus importantes qui font de Move un langage contractuel intelligent unique. 1.1 Programmation axée sur les ressources (revisitée) Au cœur de Move se trouve le concept deressources, qui sont des types spéciaux qui ne peuvent pas être copiés ou supprimés sauf autorisation explicite. Cela permet de gérer en toute sécurité les actifs numériques tels que les jetons ou les NFT. module examples::token { use sui::object::{Self, UID}; struct MyToken has key, store { id: UID, value: u64, } public fun mint(ctx: &mut TxContext): MyToken { MyToken { id: object::new(ctx), value: 100, } } } Dans cet exemple : MyToken- keyest uneressourcecar elle en a la capacité. Il peut être stocké (store) et identifié de manière unique par sonid. Il ne peut pas être dupliqué ou supprimé sauf indication contraire. Cela garantit que chaque MyTokeninstance est détenue et gérée de manière unique, évitant ainsi toute duplication ou suppression accidentelle. 1.2 Système de capacités Chaque type de Move possède un ensemble decapacitésqui définissent les opérations qu'il prend en charge : | Capacité | Signification | | --------| ---------| | copy| Peut être dupliqué | | drop| Peut être jeté sans destruction | | store| Peut être stocké dans le stockage mondial | | key| Peut être utilisé comme structure avec un champ ID (c'est-à-dire un objet) | Exemple : struct Example has copy, drop { value: u64 } Il est essentiel de comprendre ces capacités pour concevoir des contrats intelligents sécurisés et prévisibles. Pourquoi les capacités sont importantes Les capacités appliquent des règles strictes au moment de la compilation. Par exemple : Une structure contenant uniquement keyet storene pouvant pas être copiée ou supprimée. Vous ne pouvez pas renvoyer une structure non supprimable à partir d'une fonction à moins qu'elle ne soit stockée ou transférée. Cela permet d'éviter des bugs tels que la double dépense ou la perte accidentelle de jetons. 1.3 Génériques et paramètres de type Move prend en charge les types génériques, ce qui permet aux développeurs d'écrire du code flexible et réutilisable. module examples::storage { use sui::object::{Self, UID}; struct Box has key { id: UID, content: T, } public fun new_box(ctx: &mut TxContext, content: T): Box { Box { id: object::new(ctx), content, } } } `Voici unparamètre de type, qui permet de Box`fonctionner avec n'importe quel type tout en restant sûr et efficace. Remarque : Le phantommot clé indique que Tcela n'affecte pas la représentation d'exécution de la structure, ce qui est utile pour la modélisation abstraite. Étape 2 : Développement modulaire et gestion des packages À mesure que la complexité de vos projets Move augmente, l'organisation de votre code devient essentielle. 2.1 Création et publication de packages Move Unpackage Movecontient un ou plusieurs modules et définit les dépendances. Il s'agit de l'unité de déploiement et de gestion des versions dans Move. Structure du répertoire : sources/ place.move user.move Move.toml Définissez les dépendances dans Move.toml: [dependencies] Sui = { git = "https://github.com/MystenLabs/sui.git", subdir = "crates/sui-framework" } MyLibrary = { local = "../my-library" } Vous pouvez publier des packages sur le réseau Sui et les réutiliser sur plusieurs DApps. 2.2 Réutiliser les modules existants cointransfertx_contextLeSui Frameworkfournit des modules testés au combat tels que, et. Vérifiez toujours ce qui est disponible avant d'écrire une logique personnalisée. Par exemple, pour transférer un objet : use sui::transfer; public entry fun send_place(place: Place, recipient: address) { transfer::public_transfer(place, recipient); } L'utilisation de bibliothèques standard garantit un développement plus sûr et plus rapide ainsi qu'une meilleure interopérabilité. Étape 3 : Événements et communication hors chaîne Pour créer des applications réelles, vos contrats Move doivent communiquer avec des systèmes hors chaîne tels que les frontends ou les indexeurs. 3.1 Émission d'événements Move permet d'émettre desévénementsqui peuvent être indexés par des services externes. use sui::event; struct PlaceCreated has drop { name: String, } public fun emit_place_created(name: String) { event::emit(PlaceCreated { name }); } Cet événement apparaîtra sur la blockchain et pourra être récupéré par des explorateurs ou des outils d'indexation. 3.2 Écouter les événements Utilisez des outils tels queSuite Explorer,Subsquidou l'API Sui JSON-RPC pour écouter les événements émis et réagir en conséquence dans votre application. En Javascript/TypeScript : import { JsonRpcProvider } from '@mysten/sui.js'; const provider = new JsonRpcProvider('https://fullnode.devnet.sui.io'); const events = await provider.getEvents({ MoveEventType: '0x...::example::PlaceCreated' }); Étape 4 : Contrôle d'accès et modèles de sécurité La sécurité est primordiale lorsqu'il s'agit de contrats intelligents. Move fournit plusieurs outils pour mettre en œuvre un contrôle d'accès robuste. 4.1 Modèle de propriété des objets Sui applique la propriété au niveau du protocole. Seul le propriétaire d'un objet peut le muter ou le transférer. public entry fun update_name(sweet_place: &mut SweetPlace, new_name: String) { sweet_place.name = new_name; } Seul le propriétaire actuel peut appeler cette fonction. 4.2 Modèle de capacités Pour des autorisations plus précises, utilisez lemodèle de capacité : créez des objets spéciaux qui accordent un accès limité à certaines fonctions. struct AdminCap has key { id: UID } public entry fun grant_admin_cap(ctx: &mut TxContext) { let cap = AdminCap { id: object::new(ctx) }; transfer::public_transfer(cap, tx_context::sender(ctx)); } public entry fun restricted_action(_: &AdminCap) { // perform admin action } Désormais, seuls les utilisateurs qui détiennent la touche AdminCappeuvent exécuterrestricted_action. Ce modèle est largement utilisé dans DeFi et les DAO pour déléguer des pouvoirs en toute sécurité. Étape 5 : Utilisation de structures de données complexes Move prend en charge les types de données structurés qui permettent aux développeurs de modéliser des logiques et des relations complexes. 5.1 Vecteurs Les vecteurs sont utilisés pour stocker des collections ordonnées d'articles du même type. let names = vector[String::utf8(b"Alice"), String::utf8(b"Bob")]; Ils sont utiles pour stocker des listes de NFT, de rôles d'utilisateurs ou de métadonnées dynamiques. Exemple d'utilisation : vector::push_back(&mut names, String::utf8(b"Charlie")); 5.2 Tableaux (via la bibliothèque Sui Standard) Bien que Move ne prenne pas en charge nativement les cartes ou les tables de hachage, Sui fournit le Tabletype dans sa bibliothèque standard. use sui::table::{Self, Table}; struct Registry has key { id: UID, entries: Table, } public fun add_entry(registry: &mut Registry, key: u64, value: String) { table::add(&mut registry.entries, key, value); } Utilisez des tableaux pour gérer efficacement de grands ensembles de données. Étape 6 : Tester et déboguer vos contrats Les tests garantissent que votre code Move se comporte comme prévu dans diverses conditions. 6.1 Tests unitaires dans Move Écrivez des tests unitaires directement dans vos modules Move à l'aide du framework de test. #[test] public fun test_create_sweet_place() { let ctx = tx_context::dummy(); create_sweet_place(&mut ctx, String::utf8(b"My House")); } Exécutez des tests avec : sui move test 6.2 Utilisation de Sui Explorer Après avoir déployé votre contrat, utilisez le Sui Explorer pour inspecter les transactions, afficher l'état des objets et résoudre les problèmes. Étape 7 : Applications concrètes des concepts de déplacement avancés Maintenant que vous comprenez les principales fonctionnalités du langage, voyons comment elles s'appliquent à des scénarios du monde réel. Plateforme de frappe NFT 7.1 Créez une plate-forme qui permet aux utilisateurs de créer des NFT soutenus par les ressources de Move, en tirant parti des modèles de propriété et de ressources. 7.2 Système de vote DAO Implémentez une organisation autonome décentralisée (DAO) utilisant Move pour le vote, les propositions et la gouvernance, en utilisant des événements et des fonctionnalités pour des actions sécurisées. 7.3 Échanges de jetons et guichets automatiques Créez un échange décentralisé (DEX) à l'aide des modules Move pour représenter les pools de liquidités et les échanges de jetons, en utilisant des génériques et des tableaux pour une gestion efficace de l'état.

    2
  • Evgeniy CRYPTOCOIN.Peera.
    Evgeniy CRYPTOCOIN196
    PourSuiJun 30, 2025

    Que sont les NFT dynamiques et pourquoi Sui y excelle ?

    L'espace NFT évolue au-delà des images statiques et des images de profil (PFP). La prochaine frontière ? NFT dynamiques (DNFT) : jetons qui peuvent changer en fonction de données réelles, d'interactions avec les utilisateurs ou d'événements en chaîne. Alors que de nombreuses blockchains prennent en charge les NFT, Sui Network occupe une position unique pour propulser l'avenir des DNFT grâce à son architecture innovante. Cet article explore : Qu'est-ce qui rend un NFT « dynamique » ? Pourquoi la technologie de Sui est parfaite pour les DNFT Des cas d'utilisation concrets aujourd'hui L'avenir des actifs numériques interactifs ##1. Que sont les NFT dynamiques ? Contrairement aux NFT traditionnels (qui sont statiques et immuables), les NFT dynamiques peuvent mettre à jour leurs : Des métadonnées (par exemple, un NFT sportif qui change en fonction des statistiques du jeu) Apparence (par exemple, une œuvre d'art qui évolue au fil du temps) Utilité (par exemple, un NFT de fidélité qui débloque de nouveaux avantages) Comment fonctionnent-ils ? Les DNFT utilisent une logique de contrat intelligent + des entrées de données externes (oracles, actions des utilisateurs, etc.) pour déclencher des modifications. Exemple : Une œuvre d'art NFT sensible aux conditions météorologiques qui change de couleur en fonction des données climatiques en temps réel. Un personnage de jeu NFT qui monte de niveau au fur et à mesure que vous jouez. ##2. Pourquoi Sui est la meilleure blockchain pour les NFT dynamiques Bien qu'Ethereum et Solana prennent également en charge les DNFT, la conception de Sui offre des avantages clés : Stockage en chaîne (aucune dépendance externe) La plupart des blockchains stockent les métadonnées NFT hors chaîne (par exemple, IPFS), ce qui rend les mises à jour dynamiques difficiles. Sui stocke tout en chaîne, ce qui permet des modifications instantanées et fiables. Move Language : mises à niveau sécurisées et flexibles La solidité d'Ethereum nécessite des contrats proxy complexes pour les NFT évolutifs. Le langage Move de Sui permet une mutation native, sans aucune solution de contournement maladroite. Traitement parallèle (évolutivité massive) Mettre à jour des milliers de DNFT à la fois ? Ethereum est aux prises avec la congestion. L'exécution parallèle de Sui gère des millions de mises à jour sans ralentissement. Modèle centré sur l'objet (contrôle granulaire) Chaque NFT est un objet indépendant doté d'une logique personnalisable. Permet une interactivité affinée (par exemple, seul le propriétaire peut déclencher des modifications). #3. Cas d'utilisation réels des DNFT sur Sui Jeux et métaverse Des objets évolutifs dans le jeu (par exemple, une épée NFT qui gagne des capacités en l'utilisant). Interopérabilité entre les jeux (les objets de Sui peuvent se déplacer entre les DApps). Exemple : *Les jeux basés sur l'interface utilisateur tels que Panzerdogs utilisent des DNFT pour les avatars personnalisables. * Art génératif et réactif Des NFT alimentés par l'IA qui changent de style en fonction des tendances du marché. Art collaboratif où les collectionneurs influencent la pièce finale. Exemple : *Des laboratoires d'art tels que la galerie Sui accueillent des expositions DnFT. * Suivi des actifs dans le monde réel (RWA) Des NFT d'actes qui sont mis à jour avec les registres de propriété. Badges de certification qui expirent ou se renouvellent automatiquement. Programmes de fidélité et d'adhésion Des NFT à remises dynamiques qui s'améliorent en fonction des dépenses des clients. Des passes d'accès VIP qui débloquent de nouveaux niveaux au fil du temps. Exemple : *Les partenaires commerciaux de Sui testent les programmes de fidélité DnFT. * N° 4. L'avenir des DNFT sur Sui Attendez-vous à voir : Les DNFT intégrés à l'IA (par exemple, les chatbots vivant dans des avatars NFT). DNFT garantis par DeFi (la valeur s'ajuste en fonction des conditions du marché). Des jeux entièrement connectés où chaque actif est un dNFT mutable. Conclusion : Sui construit l'avenir des NFT Alors que les NFT statiques ont dominé la période 2021-2023, les NFT dynamiques domineront la prochaine période haussière, et la technologie de Sui en fait la plateforme idéale. Grâce au** stockage en chaîne, à la sécurité de Move et à une évolutivité inégalée, Sui est sur le point de devenir le berceau des DNFT avancés.

    5

Sans réponse

  • Owen.Peera.
    Owen496
    PourSuiJun 11, 2025

    Comment mettre à jour la clé d'un marchand dans ObjectTable lorsqu'elle change dans la structure ?

    Bonjour à tous, je commence tout juste à écrire des contrats intelligents et je travaille sur mon tout premier projet. J'adorerais avoir de l'aide pour résoudre un problème sur lequel je suis bloqué. Jusqu'à présent, j'ai créé une Merchantstructure qui ressemble à ceci : id: un identifiant unique (UID) owner: l'adresse du commerçant key: une chaîne utilisée comme clé unique balance: un u64 représentant leur équilibre J'ai également créé une MerchantRegistrystructure pour gérer tous les marchands : id: un autre UID merchant_to_address: et ObjectTablemappage des adresses vers les commerçants merchant_to_key: et des ObjectTableclés de mappage pour les commerçants Je veux pouvoir rechercher un marchand soit par sonadresse, soit par saclé. Lorsqu'un utilisateur met à jour sa clé dans la Merchantstructure, la modification ne met pas automatiquement à jour la clé dans la merchant_to_keytable. Cela signifie que l'ancienne clé pointe toujours vers le marchand, qui casse les objets. J'ai essayé de supprimer l'entrée du tableau et de la réinsérer avec la nouvelle clé, mais je continue de rencontrer des erreurs telles que : « Impossible d'ignorer les valeurs sans possibilité de suppression » Je suis presque sûr qu'il s'agit d'une erreur de débutant, mais je n'ai trouvé nulle part d'explication ou de solution claire. Existe-t-il un moyen approprié de gérer la mise à jour de la clé à la fois dans la structure et dans la table de recherche ?

    5
    0
  • 0xduckmove.Peera.
    0xduckmove618
    PourSuiJun 06, 2025

    Quelle est l'interface la plus simple pour télécharger des blobs de morses ?

    juste une interface utilisateur simple à télécharger sur Walrus ? (en plus de Tusky)

    2
    0
  • 1 Luca.Peera.
    1 Luca199
    PourSuiApr 09, 2025

    Que se passe-t-il si je ne réclame pas d'ETH via Sui bridge ?

    J'ai utilisé le pont Sui pour transférer des ETH mais je ne les ai pas encore réclamés car les frais sont assez élevés. Que se passera-t-il si je ne le réclame pas ?

    0
    0

Tendance

  • Vens.sui.Peera.
    Vens.sui211
    PourSuiApr 29, 2025

    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

    8
    2
  • 0xduckmove.Peera.
    0xduckmove618
    PourSuiApr 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
  • MarlKey.Peera.
    MarlKey61
    PourSuiApr 30, 2025

    Est-ce le seul moyen de publier des packages Move via un EOA ?

    Je suppose qu'il n'y a aucun moyen sur Sui chain car il n'y a pas de module sur la chaîne qui publie des packages.

    7
    3