Tendance
Découvrez les publications les plus populaires.
Publications
2187Bot 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
- Sui
93Meilleure réponse- Article0xduckmove1056PourSuiApr 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
- Sui
- Architecture
- SDKs and Developer Tools
8 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.
- Sui
- SDKs and Developer Tools
- Move
73Meilleure réponse
Comment Sui empêche-t-elle le piratage des contrats intelligents ?
Le piratage des contrats intelligents a tourmenté l'industrie de la blockchain, avec plus de 3 milliards de dollars perdus rien qu'en 2023 en raison d'exploits sur des plateformes comme Ethereum. Sui Network, conçu avec la sécurité comme priorité, introduit plusieurs innovations clés pour minimiser ces risques. Cet article explore : 🔒 Caractéristiques de sécurité intégrées de Sui 💡 Comment le langage Move empêche les exploits courants 🛡️ Comparaison avec les vulnérabilités d'Ethereum 🚀 Pourquoi Sui pourrait devenir la plateforme de contrats intelligents la plus sûre 1. Le langage de programmation Move : une approche axée sur la sécurité Sui utilise Move, un langage développé à l'origine pour la blockchain Diem de Facebook, spécialement conçu pour la gestion sécurisée des actifs. Principaux avantages de Move en matière de sécurité : Pas d'appels externes non contrôlés — Empêche les attaques de réentrée (comme le piratage DAO de 60 millions de dollars sur Ethereum). Règles de saisie et de propriété strictes — Élimine les pertes de fonds accidentelles dues à des erreurs de codage. Support de vérification formelle : permet de prouver mathématiquement l'exactitude du contrat. Exemple : Dans Ethereum, une simple faute de frappe peut épuiser des fonds. Dans Move, le compilateur rejette le code non sécurisé avant le déploiement. ###2. Modèle centré sur l'objet : isoler les vulnérabilités Contrairement au modèle d'état partagé d'Ethereum (où un bogue peut affecter de nombreux contrats), les limites de stockage basées sur les objets de Sui exploitent la propagation : Chaque actif (pièce, NFT, etc.) est un objet distinct soumis à des règles de propriété strictes. Les contrats ne peuvent pas modifier arbitrairement des données non liées. Conséquence : même si un contrat est compromis, les dommages sont maîtrisés, contrairement aux risques de composabilité d'Ethereum (par exemple, le piratage du pont Wormhole de 325 millions de dollars). 3. Pas d'attaques de type « Gas Griefing » Sur Ethereum, les attaquants peuvent spammer des contrats contenant des transactions coûteuses afin de bloquer les utilisateurs légitimes (par exemple, des attaques par déni de service). La solution de Sui : Transactions fixes à faible coût (pas d'enchères de gaz). L'exécution parallèle évite la congestion de l'ensemble du réseau. ##4. Surveillance de la sécurité en chaîne Les validateurs de Sui surveillent activement les activités suspectes : Vérifications préalables des transactions — Rejetez les demandes manifestement malveillantes. Analyses en temps réel : signalez les comportements anormaux (par exemple, des retraits importants et soudains). ##5. Bilan de sécurité dans le monde réel (jusqu'à présent) Sui n'a subi aucun piratage majeur depuis le lancement du réseau principal (2023). Ethereum enregistre en moyenne 2 à 3 exploits DeFi majeurs par mois. Étude de cas : Un DEX (Cetus) basé sur SUI a traité plus de 1 milliard de dollars de transactions sans incidents de sécurité, contrairement aux DEX Ethereum, qui sont fréquemment victimes d'exploits. ##6. Pérennisation : vérification et audits formels Sui encourage : Vérification formelle — Prouver mathématiquement que les contrats sont exempts de bogues. Exigences relatives à plusieurs audits — Les grands projets doivent réussir au moins 3 audits. Conclusion : Sui est-elle la plateforme de contrats intelligents la plus sécurisée ? Bien qu'aucun système ne soit totalement résistant au piratage, le langage Move, le modèle d'objet et l'exécution parallèle de Sui le rendent bien moins vulnérable qu'Ethereum aujourd'hui. L'essentiel : Pour les développeurs : Move réduit les risques d'erreur humaine. Pour les utilisateurs : moins de chances de perdre de l'argent à cause d'exploits. Pour les institutions : une sécurité de niveau professionnel renforce la confiance. **Quelle est la prochaine étape ? Ethereum adoptera-t-il des fonctionnalités similaires à Move ? Sui pourra-t-elle maintenir son bilan de sécurité irréprochable à mesure que le taux d'adoption augmente ?** Partagez vos réflexions ci-dessous
- Sui
6- Articleharry phan903PourSuiApr 24, 2025
Gestion des enfants multimodule avec public_receive
Il s'agit de la troisième partie de la série « Les objets parent-enfant dans Sui Move ». Parfois, vos types de parents et d'enfants sont définis dans différents modules ou même dans différents packages. Par exemple, vous pouvez disposer d'un objet Warehouse générique qui peut stocker n'importe quel type d'objets Parcel. Le module Warehouse souhaite extraire un enfant de colis, mais le type de colis est défini ailleurs. Dans de tels cas, nous utilisons transfer : :public_receive, qui est le cousin intermodule de receive. ###recevoir contre public_receve Comme nous l'avons vu, transfer : :receive ne peut être appelé que dans le module qui définit T (ou un ami) car il ne nécessite pas T : store. Le vérificateur de bytecode Move garantit en fait que dans tout appel à recevoir, le type T provient du module en cours. Il s'agit d'une restriction de sécurité pour les objets dotés uniquement d'une clé. transfer : :public_receive est une variante qui requierce T : key + store mais permet de recevoir en dehors du module de T. En d'autres termes, si le type d'objet possède la capacité de stockage (ce qui signifie qu'il est autorisé à exister librement dans le stockage global), alors n'importe quel module (avec l'UID &mut du parent) peut le recevoir en utilisant public_receive. C'est parfait pour les cas où le module du parent est différent de celui de l'enfant. Pourquoi avoir besoin d'un magasin ? Parce que stockez les marques indiquant que l'objet peut être conservé en toute sécurité et transmis en dehors de son module de définition. Les objets à clé uniquement peuvent avoir des invariants personnalisés que le module d'origine souhaite appliquer lors du transfert/de la réception ; en les excluant de public_receive, Sui oblige les développeurs à les gérer dans le module (comme nous le verrons avec les objets liés à l'âme). Si un objet a un stockage, il est plus permissif, et Sui autorise une logique générique de transfert/réception pour le gérer en externe. ###Exemple : modules séparés pour les parents et les enfants Illustrons avec un scénario simple : un entrepôt qui stocke des objets Parcel. Le type de colis est défini dans son propre module et l'entrepôt dans un autre. Nous allons montrer comment Warehouse peut recevoir un colis enfant à l'aide de public_receive. module demo::parcel { // Child module use sui::object::{Self, UID}; use sui::tx_context::{Self, TxContext}; /// A parcel object that can be stored in a Warehouse. /// It has both key and store, so it can be transferred across modules. struct Parcel has key, store { id: UID, contents: vector } public entry fun create_parcel(contents: vector, ctx: &mut TxContext): Parcel { Parcel { id: object::new(ctx), contents } } } module demo::warehouse { // Parent module use sui::transfer::{Self, Receiving, public_receive}; use demo::parcel::{Self, Parcel}; use sui::object::{UID}; use sui::tx_context::{Self, TxContext}; struct Warehouse has key { id: UID, location: address } public entry fun create_warehouse(location: address, ctx: &mut TxContext): Warehouse { Warehouse { id: object::new(ctx), location } } /// Receive a Parcel that was sent to this Warehouse. /// Returns the Parcel to the caller (transferred to caller's address). public entry fun withdraw_parcel( warehouse: &mut Warehouse, parcel_ticket: Receiving, ctx: &mut TxContext ): Parcel { // Using public_receive because Parcel is defined in another module and has store let parcel = public_receive(&mut warehouse.id, parcel_ticket) oai_citation_attribution:27‡docs.sui.io oai_citation_attribution:28‡github.com; // Transfer the parcel to the transaction sender (so the caller gets ownership) transfer::transfer(parcel, tx_context::sender(ctx)); // We return nothing because we've transferred the Parcel out to the caller. } } Découvrons ce qui se passe dans withdraw_parcel : Nous appelons public_receive (&mut warehouse.id, parcel_ticket). Comme Parcel a la capacité de stocker, cet appel est autorisé même si nous ne sommes pas dans le module Colis. En principe, cela effectue les mêmes vérifications et extractions que la réception, mais cela est autorisé entre les modules car store indique que cela peut être fait en toute sécurité. https://github.com/MystenLabs/sui/blob/main/crates/sui-framework/packages/sui-framework/sources/transfer.move#:~:text=public%20fun%20public_receive,T%3E%29%3A%20T Nous transférons ensuite immédiatement le colis reçu à l'adresse de l'appelant (tx_context : :sender (ctx)). Cette étape garantit que le colis quitte l'entrepôt et est envoyé à l'utilisateur qui a initié le retrait. Nous aurions également pu simplement renvoyer Parcel à partir de la fonction, et Sui le traiterait comme une sortie appartenant à l'adresse de l'appelant (puisqu'il s'agit d'une sortie de fonction d'entrée). Faire un transfert explicite est plus détaillé, mais cela permet de comprendre ce qui se passe (et nous permet de faire toutes les vérifications avant de libérer l'objet). Pourquoi inclure le point de vente dans le colis ? Si Parcel n'avait pas la capacité de stockage (c'est-à-dire s'il n'avait que la clé), l'appel public_receive dans demo : :warehouse ne serait pas compilé — Sui impose que T possède un store pour public_receive. Dans ce cas, nous serions obligés de récupérer le colis en utilisant receive dans le module de colis lui-même (ou en utilisant une relation d'amitié), ce qui complique la conception intermodule. En ajoutant store à Parcel, nous disons en fait que « cet objet peut être déplacé et reçu librement par des modules externes », ce que nous voulons pour un modèle de conteneur générique. Modèle d'appel de fonction :Pour les utiliser dans une transaction, le flux serait le suivant : 1.Dépôt (transfert vers un objet) :Appelez transfer : :public_transfer (parcel_obj, @warehouse_id) pour envoyer un colis dans un entrepôt. Cela indique que le propriétaire du colis est l'entrepôt. (Nous utilisons public_transfer ici car il se trouve en dehors du module Parcel et Parcel a une boutique. Dans le module du colis, un simple transfert fonctionnerait également.) Retirer (recevoir un retour) :Plus tard, appelez withdraw_parcel (warehouse_obj, Receiving (parcel_id,...)). La réception peut être obtenue par le SDK en faisant référence à l'identifiant du colis et à la dernière version. La fonction appellera public_receive puis vous transférera le colis. Après l'appel withdraw_parcel, le propriétaire du colis revient à une adresse (la vôtre). Il s'agit donc à nouveau d'un objet appartenant à une adresse normale. L'entrepôt n'en est plus propriétaire. Considérations relatives à l'intermodule :Notez que le module Warehouse devait connaître le type de colis (nous utilisons demo : :parcel : :Parcel). En effet, nous saisissons explicitement la réception comme réception. Si vous vouliez un conteneur véritablement générique pouvant recevoir n'importe quel type d'objet, vous devrez utiliser des génériques ou une approche différente (éventuellement des champs dynamiques avec effacement de type). Mais dans la plupart des cas d'utilisation, vous saurez à quels types d'enfants vous attendez. Pourquoi public_receive au lieu de simplement appeler receive ? Si nous essayions transfer : :receive (&mut warehouse.id, parcel_ticket) dans le module warehouse, le vérificateur Move le rejetterait car Parcel n'est pas défini dans demo : :warehouse. Sui fournit le public_receive comme moyen privilégié de le faire avec une vérification de capacité supplémentaire (nécessitant un magasin). De même, Sui a transfer vs public_transfer, freeze_object vs public_freeze_object, etc., suivant le même schéma : les versions public_ sont destinées à être utilisées en dehors du module de définition et nécessitent un stockage. N' oubliez pas l'autorisation des parents :Même avec public_receive, vous avez toujours besoin de &mut warehouse.id. Nous l'avons obtenu car withdraw_parcel se trouve dans le module de Warehouse et accepte &mut Warehouse. Ainsi, seule une personne capable de l'appeler (le propriétaire de l'entrepôt) peut retirer le colis. Si le module d'entrepôt ne fournissait pas une telle fonction publiquement, personne ne pourrait non plus appeler public_receive en externe sur ses enfants. Ainsi, le cross-module ne contourne pas le contrôle du parent ; il permet simplement au code du parent de fonctionner avec des enfants de types qu'il n'a pas définis. Remarque sur la capacité de stockage : Le fait de donner un magasin d'objets le rend plus flexible mais légèrement moins restreint. Tout module avec la référence parent peut l'extraire à l'aide de public_receive. Si vous souhaitezrestreindrela manière dont un objet est récupéré (par exemple, appliquer une logique personnalisée ou empêcher une extraction facile), vous pouvez délibérément en faire une clé uniquement. Nous en verrons un exemple avec les objets liés à l'âme. Dans ces cas, vous pouvez implémenter une fonction de réception personnalisée au lieu de vous fier à public_receive. Pour résumer cette partie : public_receive est votre ami pour la gestion des objets enfants définis dans d'autres modules, à condition que ces objets puissent être stockés. Il vous permet de créer des systèmes multimodules (comme notre Entrepôt/Colis) tout en respectant la propriété et le contrôle d'accès. N'oubliez pas d'inclure le store sur les types d'enfants et d'utiliser public_transfer lorsque vous les envoyez à un parent depuis l'extérieur de son module.
- Sui
- Architecture
6 - Questions et Réponses avec des ExpertsPourSuiJun 30, 2025
Why can’t I connect my wallet to a Sui dApp?
I’m trying to use a Sui dApp (like Tradeport, SuiSwap, or a custom platform), but my wallet won’t connect properly. Sometimes, I get no error at all—just nothing happens when I click "Connect Wallet." Other times, I see errors like: "Wallet not detected" (even though I have Sui Wallet or another wallet installed) "Connection failed: Invalid account" "Transaction rejected" before I even approve anything What I’ve tried: Refreshing the page Switching browsers (Chrome, Firefox, Brave) Checking wallet extension permissions Trying different networks (Devnet, Testnet, Mainnet) Reinstalling the wallet extension Questions: Why does this happen, and how can I fix it? Are there common mistakes users make when connecting wallets to Sui dApps? If my wallet was working before but suddenly stopped, what could be the cause?
- Sui
- Transaction Processing
61Meilleure réponse 
Comment créer une DApp complexe sur Sui Move ?
Cours #2 : Approfondissement de la programmation Move — Création de dApps complexes sur Sui Maintenant que vous avez compris les bases de la programmation de Move et déployé votre premier contrat intelligent, il est temps de passer à la vitesse supérieure. Dans cet article, nous verrons comment créer des applications décentralisées (DApps) plus complexes à l'aide de Move on the Sui blockchain. Étape 1 : Maîtriser les concepts avancés de Sui Move Avant de plonger dans le codage, revenons sur certaines fonctionnalités avancées de Move qui le rendent particulièrement adapté à la création de dApps sécurisées et évolutives : ####1. Programmation axée sur les ressources Move traite les actifs numériques comme desressources, en veillant à ce qu'ils ne puissent pas être dupliqués, supprimés involontairement ou utilisés à mauvais escient (https://docs.sui.io/learn/resource-oriented-programming). Ceci est réalisé grâce à des règles de propriété strictes et à la sécurité des types. Par exemple : module examples::token { use sui::object::{Self, UID}; use sui::transfer; struct Token has key, store { id: UID, value: u64, } public fun mint(ctx: &mut TxContext, value: u64): Token { Token { id: object::new(ctx), value, } } public fun transfer_token(token: Token, recipient: address) { transfer::public_transfer(token, recipient); } } Dans cet exemple, la Tokenressource est créée et transférée de manière sécurisée. Les ressources de Move sont immuables par défaut, sauf si elles sont explicitement marquées comme mutables, ce qui ajoute une couche de sécurité supplémentaire. ####2. Modules et encapsulation Les modules de Move agissent comme des unités fonctionnelles autonomes, permettant une meilleure organisation et une meilleure réutilisation. Par exemple, vous pouvez séparer la logique de création de jetons de la logique de transfert dans des modules distincts (https://examples.sui.io/modules). Cette modularité garantit un code plus propre et une maintenance plus facile. ####3. Conception centrée sur l'objet UIDSui Move introduit unmodèle centré sur l'objet, où chaque ressource possède un identifiant unique au monde (). Cela permet un référencement direct et une interaction avec les objets, ce qui facilite la gestion des transitions d'état complexes (https://docs.sui.io/objects). Étape 2 : Rédaction d'un contrat intelligent modulaire Créons un contrat intelligent plus avancé qui illustre ces concepts. Nous allons créer une place de marché NFT simple où les utilisateurs pourront créer et échanger des NFT. ####Définissez la ressource NFT Commencez par définir une ressource NFT dans un module Move : module examples::nft_marketplace { use sui::object::{Self, UID}; use sui::transfer; struct NFT has key, store { id: UID, name: String, price: u64, } public fun mint_nft(ctx: &mut TxContext, name: String, price: u64): NFT { NFT { id: object::new(ctx), name, price, } } public fun list_for_sale(nft: NFT, price: u64, ctx: &mut TxContext) { nft.price = price; transfer::public_transfer(nft, tx_context::sender(ctx)); } } Ici, la NFTressource inclut des propriétés telles que nameetprice. La mint_nftfonction crée un nouveau NFT, tout en list_for_salepermettant aux utilisateurs de répertorier leurs NFT à vendre. ####Compiler et déploier Utilisez la CLI Sui pour compiler et déployer votre contrat. Écrivez un script de déploiement pour automatiser ce processus : sui move build sui client publish --gas-budget 10000 Cela permettra d'empaqueter et de déployer votre module sur le Sui Devnet (https://docs.sui.io/cli). Étape 3 : Création d'une interface React pour votre place de marché Une fois votre contrat intelligent déployé, connectons-le à une interface React. ####Configurer le projet Initialisez un projet React si ce n'est pas déjà fait : npx create-react-app nft-marketplace cd nft-marketplace npm install @mysten/sui.js ####Intégrer à Sui Wallet Utilisez la @mysten/sui.jsbibliothèque pour interagir avec la blockchain Sui : import { JsonRpcProvider, SuiClient } from '@mysten/sui.js'; const provider = new SuiClient({ url: 'https://fullnode.devnet.sui.io' }); async function fetchNFTs(ownerAddress) { const objects = await provider.getObjectsOwnedByAddress(ownerAddress); console.log('User NFTs:', objects); } ####Afficher les données NFT Récupérez et affichez les données NFT dans votre application React : function NFTList({ ownerAddress }) { const [nfts, setNFTs] = useState([]); useEffect(() => { async function loadNFTs() { const response = await provider.getObjectsOwnedByAddress(ownerAddress); setNFTs(response.data); } loadNFTs(); }, [ownerAddress]); return ( {nfts.map((nft) => ( {nft.name} Price: {nft.price} SUI ))} ); } Étape 4 : Améliorer la sécurité et les performances ####1. Transactions sécurisées Assurez-vous que toutes les transactions sont validées à la fois en chaîne et hors chaîne. Utilisez des bibliothèques telles que @mysten/sui.jspour vérifier les reçus de transactions : async function verifyTransaction(txDigest) { const result = await provider.getTransaction({ digest: txDigest }); console.log('Transaction Verified:', result); } ####2. Optimisez les frais de gaz Associez-vous à des services tels que* Shami Gas Station* pour proposer des transactions sans gaz et améliorer ainsi l'expérience utilisateur. Vous pouvez également effectuer des transactions par lots pour réduire les coûts (https://docs.sui.io/gas-optimization). ####3. Tirez parti de l'évolutivité de Sui L'architecture de Sui prend en charge un débit élevé et une faible latence, ce qui la rend idéale pour les DApps à forte utilisation. Testez votre application dans des conditions de charge simulées pour vous assurer que les performances restent constantes (https://performance.sui.io). Étape 5 : Test et débogage Les tests sont essentiels pour éviter les vulnérabilités. Utilisez des outils tels que* Sui Explorer* pour surveiller les transactions et résoudre les problèmes. En outre, rédigez des tests unitaires pour vos modules Move : #[test] fun test_mint_nft() { use sui::test_scenario; let ctx = &mut test_scenario::ctx(); let nft = examples::nft_marketplace::mint_nft(ctx, "Test NFT", 100); assert!(nft.price == 100, 0); } Exécutez vos tests à l'aide de la CLI Sui : sui move test Étape 6 : Interagir avec la communauté La création de dApps ne se limite pas au codage, c'est aussi une question de collaboration. Partagez vos progrès sur des plateformes telles que* GitHub,* Discord* ou* Twitter**. Participez à des hackathons et à des défis pour développeurs organisés par la Sui Foundation pour affiner vos compétences et gagner en visibilité (https://sui.peera.ai/). Conclusion En maîtrisant les concepts avancés de Move, en rédigeant des contrats intelligents modulaires et en créant des interfaces intuitives, vous êtes sur la bonne voie pour devenir un développeur dApp compétent sur la blockchain Sui. N'oubliez pas de donner la priorité à la sécurité, d'optimiser les performances et de vous engager auprès de la communauté pour maximiser votre impact. Restez connectés pour* Course #3*, où nous explorerons des cas d'utilisation concrets et des techniques avancées pour faire évoluer vos DApps sur Sui ! Si vous souhaitez des éclaircissements supplémentaires ou des ressources supplémentaires, n'hésitez pas à demander !
- Sui
- Architecture
- Move
6
Débuter avec Move Learning - Cours #1
Que vous soyez un développeur débutant ou expérimenté, ce guide étape par étape vous aidera à comprendre comment Move, un langage de programmation orienté ressources, peut être utilisé pour créer des DApps sur la blockchain Sui. ###Étape 1 : Comprendre Move et ses principales caractéristiques Avant de plonger dans le codage, expliquons brièvement ce qu'estMoveet pourquoi il est unique. Moveest un langage de programmation conçu pour écrire des contrats intelligents sûrs et efficaces. Il introduit laprogrammation axée sur les ressources**, dans laquelle les actifs numériques sont traités comme des ressources de première classe, garantissant ainsi qu'ils ne peuvent pas être dupliqués ou supprimés involontairement. Contrairement à d'autres langages,Moveminimise les vulnérabilités grâce à des fonctionnalités telles que lasaisie statiqueet lagestion robuste des ressources. Si vous découvrezMove, nous vous recommandons de regarder la vidéoIntro to Sui Move(https://www.youtube.com/watch?v=cJwN3IhpLnQ)by) Shayan de la Fondation Sui. Cela fournira des connaissances de base sur le réseau Sui et le rôle de Move au sein de celui-ci. ###Étape 2 : Configuration de votre environnement de développement Pour commencer, vous devez installer les outils et les fichiers binaires nécessaires. Procédez comme suit : 1.Installez les sous-binaires Commencez par installer lesbinaires Suipour vous assurer que votre environnement de développement est prêt. La CLI (interface de ligne de commande) Sui vous permettra d'interagir avec la blockchain Sui. Vous trouverez des instructions détaillées dans les Sui Docs. 2.Choisissez votre plateforme Selon que vous utilisez Windows, macOS ou Linux, suivez les instructions de configuration correspondantes fournies dans la série de vidéos ou dans la documentation officielle de Sui. 3.Configurer un VPS (facultatif) Si votre ordinateur portable n'est pas assez puissant, envisagez de configurer un serveur privé virtuel (VPS) pour gérer la charge de calcul. ###Étape 3 : Rédaction de votre contrat intelligent First Move Maintenant que votre environnement est prêt, écrivons un simple contrat intelligentMove. Pour ce tutoriel, je vous conseille d'utiliser l'exempleSweet Place, inspiré deFlash Place. 1.Définir les ressources Commencez par définir une ressource dans votre module Move. Par exemple : module examples::sweet_place { use sui::object::{Self, UID}; use sui::transfer; struct SweetPlace has key { id: UID, name: String, } public fun create_sweet_place(ctx: &mut TxContext, name: String) { let sweet_place = SweetPlace { id: object::new(ctx), name, }; transfer::public_transfer(sweet_place, tx_context::sender(ctx)); } } 2.Compiler et déploier Utilisez la CLI Sui pour compiler et déployer votre contrat. Écrivez unscript de déploiementpour automatiser ce processus, afin de garantir une intégration fluide avec votre frontend ultérieurement. ###Étape 4 : Création du frontend React Une fois votre contrat intelligent déployé, il est temps de le connecter à uneinterface React. Cette étape suppose que vous avez une certaine expérience de React. Sinon, consultez leBeginner React Coursede FreeCodeCamp.org. 1.Configurer le projet Initialisez un projet React en utilisant create-react-apple framework de votre choix. 2.Intégrer à Sui Wallet Utilisez des bibliothèques comme @mysten/sui.jspour interagir avec la blockchain Sui. Par exemple : import { JsonRpcProvider } from '@mysten/sui.js'; const provider = new JsonRpcProvider('https://fullnode.devnet.sui.io'); 3.Récupérez les données de votre contrat Interrogez les données de votre contrat Move déployé et affichez-les dans votre application React. Utilisez unindexeurpour suivre efficacement les transactions et les changements d'état. ###Étape 5 : Améliorer l'expérience utilisateur (UX) L'une des caractéristiques les plus remarquables de ce didacticiel est qu'il met l'accent sur la création d'une expérience utilisateur fluide. Voici comment améliorer l'expérience utilisateur : 1.Intégrez les transactions sans gaz Associez-vous à des services tels queShami Gas Stationpour permettre à vos utilisateurs de faire des transactions sans gaz. Cela élimine les obstacles pour les nouveaux arrivants qui ne sont pas familiarisés avec les frais liés aux cryptomonnaies. 2.Optimisez les performances Tirez parti du haut débit et de la faible latence de Sui pour garantir le bon fonctionnement de votre DApp, même en cas de forte charge. ###Étape 6 : Test et déboguage Les tests sont essentiels pour garantir que votre application fonctionne comme prévu. Utilisez des outils tels queSui Explorerpour vérifier les transactions et résoudre les problèmes [[Web Search]]. Consultez également laplateforme d'apprentissage en ligne MOVEpour en savoir plus sur les meilleures pratiques en matière de tests et de mesures. ###Étape 7 : Interagir avec la communauté Enfin, n'oubliez pas de participer à lacommunauté Sui ! Partagez vos progrès, posez des questions et collaborez avec d'autres personnes. Comme le souligne la transcription de la vidéo, le réseautage avec d'autres développeurs peut donner lieu à des opportunités intéressantes.
- Sui
- Architecture
- SDKs and Developer Tools
- Move
6- Article0xduckmove1056PourSuiMar 12, 2025
Setting Up a Project to Test the SUI Name Service (SuiNS)
The SUI Name Service (SuiNS) is a decentralized naming system on the SUI blockchain that allows users to map human-readable names (e.g., "0xduck.sui") to blockchain addresses or other data, enhancing usability and accessibility. For developers, testing the SuiNS SDK is an essential step to ensure applications can resolve these names correctly. In this article, we’ll walk you through the process of setting up a project to test the SuiNS SDK, from preparing your development environment to querying a name record like "0xduck.sui" and understanding the results. Introduction to SUI Name Service The SUI Name Service (SuiNS) simplifies blockchain interactions by allowing users to register memorable names instead of using complex cryptographic addresses. For example, instead of sending tokens to "0x1234...abcd", you could send them to "0xduck.sui". Testing the SuiNS SDK ensures that your application can correctly interact with this system, retrieving and interpreting name records as needed. In this project, we’ll set up a Node.js environment, connect to the SUI mainnet, and write a script to query the name record for "0xduck.sui". By the end, you’ll have a working setup to explore SuiNS further. Prerequisites Before starting, ensure you have the following: Node.js (version 14 or higher) and npm (version 6 or higher) installed. Download them from nodejs.org if needed. Basic understanding of JavaScript, particularly asynchronous programming (e.g., async/await). A code editor like Visual Studio Code (VS Code) for writing and running scripts. An internet connection to install packages and connect to the SUI. Setting Up the Development Environment Let’s create a new project directory and initialize it as a Node.js project. This will provide a clean workspace for our test. Step-by-Step Instructions: Open your terminal (e.g., Command Prompt, PowerShell, or a Unix shell). Create a new directory: mkdir suins-test-project cd suins-test-project Initialize a Node.js project: Run this command to create a package.json file with default settings: npm init -y Your project is now set up with a basic structure. Installing Dependencies Run the following in your terminal: npm install @mysten/suins @mysten/sui Verify the Installation: Check that the packages are added to package.json under dependencies. You can also confirm the installed versions by running: npm list @mysten/suins @mysten/sui This should output something like: suins-test-project@1.0.0 ├── @mysten/sui@x.x.x └── @mysten/suins@y.y.y Configuring the SUI Client The SUI client connects your project to the SUI blockchain. For testing, we’ll use the mainnet. Create a Script File: In your project directory, create a file named test-suins.js: touch test-suins.js # On Unix/macOS echo. > test-suins.js # On Windows Open test-suins.js in your editor and add the following: import { getFullnodeUrl, SuiClient } from '@mysten/sui/client'; // Create a SUI client connected to the testnet const suiClient = new SuiClient({ url: getFullnodeUrl('testnet') }); Note: If you encounter an error about ES modules (e.g., "Cannot use import statement outside a module"), add "type": "module" to your package.json: { "name": "suins-test-project", "version": "1.0.0", "type": "module", ... } Testing the Name Service Now, let’s write a script to query the name record for "0xduck.sui" and log the result. import { getFullnodeUrl, SuiClient } from '@mysten/sui/client'; import { SuinsClient } from '@mysten/suins'; // Create a SUI client connected to the testnet // const suiClient = new SuiClient({ url: getFullnodeUrl('mainnet') }); const client = new SuiClient({ url: getFullnodeUrl('mainnet') }); // Create a SuiNS client using the SUI client const suinsClient = new SuinsClient({ client, network: 'mainnet', }); // Function to test the name service async function testNameService() { try { // Query the name record for 'demo.sui' const nameRecord = await suinsClient.getNameRecord('0xduck.sui'); // Log the result console.log('Name Record for "0xduck.sui":', nameRecord); } catch (error) { console.error('Error fetching name record:', error.message); } } testNameService(); In your terminal, execute: node test-suins.js
- SDKs and Developer Tools
6 - Questions et Réponses avec des ExpertsPourSuiJun 26, 2025
How to Properly Use the Sui SDK for Frontend Integration?
I'm building a frontend (React/Next.js) for a Sui dApp and need to interact with the blockchain—fetching objects, sending transactions, and listening to events. I’ve tried using the @mysten/sui.js SDK, but I’m running into issues: Wallet Connection: Sometimes, the wallet doesn’t return the user’s address after connecting. Transaction Handling: Transactions fail silently or return vague errors. RPC Limits: I get rate-limited or timeouts when fetching large datasets. Real-Time Updates: How can I listen for on-chain events (e.g., NFT mints, balance changes)? What I’ve tried: ✔ Basic SuiClient setup with mainnet and testnet RPCs. ✔ Using useWallet() from @mysten/dapp-kit for wallet integration. ✔ Manual transaction signing with signAndExecuteTransactionBlock. Questions: What’s the recommended way to initialize the Sui SDK in a frontend app? How do I handle errors gracefully (e.g., RPC failures, wallet rejections)? Are there best practices for optimizing queries (batching, caching, etc.)? How can I subscribe to real-time updates (e.g., new transactions, object changes)?
- Sui
- SDKs and Developer Tools
62Meilleure réponse
- Implémentation de portefeuilles multi-signatures dans Sui Move00
- Vous êtes confus au sujet du portefeuille Playtron et des récompenses manquantes ?00
- Mise en œuvre de normes de jetons personnalisées au-delà de SUI et COIN in Move01
- Impossible de connecter mon appareil Ledger pour envoyer mes jetons SUI — Ma solution0
- Des pièces non reconnues dans mon portefeuille cryptographique : qu'est-ce que cela signifie ?0
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.
- 2565
- 1780
- 1056
- 903
- 711
- 536
- 527
- 486
- 415
- 402