Peera.

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

  • Bolke .Peera.
    Bolke 193
    PourSuiAug 12, 2025
    +15

    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

    0
    5
  • Xavier.eth.Peera.
    Xavier.eth303
    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 !

    3
    6
  • Xavier.eth.Peera.
    Xavier.eth303
    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
    5

Le plus nouveau

  • dhaholar.Peera.
    dhaholar10
    PourSuiAug 14, 2025

    Comment Sui gère le stockage : quels en sont les coûts, comment vous pouvez économiser et pourquoi la planification est importante

    Problème que cela résout : Les équipes oublient que sur Sui, les frais de stockage sont initiaux et remboursables en cas de suppression. Cela conduit à des designs gonflés et à des frais élevés. Ce que tu vas apprendre : Comment sont calculés les frais de stockage En quoi consistent les remises et quand les obtenez-vous Gestion du cycle de vie des données en chaîne Modèles d'élagage et d'archivage 1) Modèle de frais de stockage initiaux Lorsque vous créez ou développez un objet, vous payez une redevance unique proportionnelle à l'augmentation de taille. Lorsque vous supprimez un objet, vous bénéficiez d'une remise sur l'entreposage (un pourcentage des frais initiaux). 2) Pourquoi c'est important Les objets volumineux ou nombreux peuvent entraîner des coûts importants. Les remises encouragent la collecte des déchets non utilisés. 3) Conception du cycle de vie Création : payez la totalité des frais pour les octets ajoutés. Mutation : différence de taille entre le paiement et la réception. Suppression : bénéficiez d'une remise. 4) Étape par étape : élagage des enchères expirées Enregistrez un horodatage d'expiration dans chaque objet de la vente aux enchères. Une fois expiré, autorisez n'importe quel acteur à clôturer les enchères. fermer l'enchère transfère les actifs restants, supprime l'objet de l'enchère. L'appelant bénéficie d'une petite prime sous la forme d'une remise sur l'espace de stockage (ou d'une récompense distincte). Conservez des journaux d'événements pour l'historique au lieu de conserver l'objet complet. Résultat : réduction du gonflement en chaîne, reprise des remises. 5) Modèles de contrôle des coûts Regroupez les données dans des objets plus petits et plus volumineux. Utilisez le stockage hors chaîne pour les actifs volumineux (IPFS, Arweave). Tirez parti des champs dynamiques pour éviter les structures monolithiques.

    0
  • dhaholar.Peera.
    dhaholar10
    PourSuiAug 14, 2025

    Dans le moteur de Sui : Consensus, Narwhal et Bullshark

    Problème que cela résout : De nombreux développeurs supposent que toutes les blockchains sérialisent les transactions dans un journal semblable à une chaîne unique, mais le consensus de Sui est optimisé pour permettre une exécution parallèle. Une mauvaise compréhension de cela conduit à des hypothèses erronées quant à la finalité et à l'ordre des transactions. Ce que tu vas apprendre : Comment Narwhal et Bullshark travaillent ensemble Ce que le « consensus » commande réellement en Sui Comment l'exécution parallèle et la finalité interagissent Modèles de conception pour éviter de dépendre de la commande globale 1) Le modèle Narwhal-Bullshark Sui utilise une pile de consensus à deux composants : Narwhal : une couche de mémorisation et de disponibilité des données. Il gère la diffusion des transactions et garantit que tous les validateurs voient le même ensemble de transactions avec des preuves. Bullshark : protocole de consensus basé sur le DAG qui ordonne les transactions lorsque cela est nécessaire (transactions d'objets partagés). Les transactions portant sur des objets détenus ne nécessitent pas d'ordre consensuel : elles s'exécutent indépendamment une fois que les objets en entrée sont validés. 2) Catégories de transactions et règles de commande Transactions portant sur des objets personnels : aucune commande consensuelle n'est requise. Les validateurs vérifient la propriété/la version, exécutent et finalisent rapidement. Transactions d'objets partagés : elles doivent être ordonnées pour éviter des écritures conflictuelles. Implications sur la conception : Ne vous fiez qu'à un ordre déterministe lorsque vous touchez des objets partagés ; ne supposez pas que « tx A se produit avant tx B » globalement. 3) Garanties de finalité Sui vise un caractère définitif inférieur à la seconde pour les transactions à propriétaire unique dans des conditions normales. Les transactions d'objets partagés sont finalisées après un ordre consensuel (environ 2 à 3 secondes, généralement dans des conditions de testnet). 4) Idées fausses courantes chez les développeurs Idée fausse : « Si je soumets tx A puis tx B, ils seront toujours exécutés dans l'ordre. » Réalité : S'ils touchent des objets appartenant à des personnes disjointes, ils peuvent finaliser en parallèle ou même hors ordre de soumission. Idée fausse : « Chaque taxe doit faire l'objet d'un consensus. » Réalité : Seules les écritures sur objets partagés l'exigent. 5) Étape par étape : conception d'un classement de jeu Problème : vous avez besoin d'un classement, mais vous ne voulez pas de latence consensuelle à chaque mise à jour du score. Solution : Conservez les scores par joueur dans les objets PlayerStats que vous possédez. Exécutez périodiquement une tâche planifiée qui regroupe les scores dans un objet de classement partagé pour un affichage public. Émettez des événements en cas de changement de score ; les systèmes hors chaîne mettent à jour les classements en temps quasi réel. Les utilisateurs voient des mises à jour locales instantanées, tandis que les classements publics sont mis à jour à intervalles réguliers. Résultat : les actions de l'utilisateur restent sur le chemin à faible latence ; charge consensuelle uniquement pour les synchronisations périodiques. 6) Liste de contrôle Minimisez les écritures sur les objets partagés. Ne vous fiez pas aux commandes fiscales mondiales. Utilisez l'agrégation périodique ou pilotée par les événements pour les vues publiques.

    0
  • BBT101.Peera.
    BBT10110
    PourSuiAug 14, 2025

    Automatisation des flux de travail d'entreprise avec les modules Move

    Introduction : Le passage à une logique métier autonome Les entreprises modernes abandonnent de plus en plus les opérations manuelles et les flux de travail impliquant de nombreux intermédiaires au profit de systèmes automatisés et autonomes. Les contrats intelligents constituent l'épine dorsale de cette évolution, permettant aux entreprises de : • Réduire les frais généraux • Éliminez les retards • Améliorer la transparence • Minimiser les erreurs et les fraudes Cependant, de nombreuses plateformes de contrats intelligents ne sont pas suffisamment flexibles, sûres et performantes. Découvrez Move, le langage de contrat intelligent qui sous-tend Sui, qui introduit une automatisation modulaire et programmable pour les flux de travail de niveau entreprise. Pourquoi les modules Move sont idéaux pour l'automatisation des entreprises Le langage Move de Sui vous permet de définir des composants de code modulaires et réutilisables appelés modules Move. Ces modules encapsulent les règles de gestion et peuvent être intégrés à des systèmes automatisés de tous les secteurs. Principales caractéristiques qui profitent aux entreprises : Fonctionnalité Impact commercial Le modèle de sécurité des ressources empêche les doubles dépenses et les conditions de concurrence Logique centrée sur les objets Suivi clair des actifs et contrôle de propriété Architecture modulaire Flux de travail réutilisables et composants évolutifs Accès basé sur les capacités Autorisations de rôle affinées dans les flux de travail Vérification formelle Exactitude du programme et assurance de conformité Exemple de cas d'utilisation : automatisation d'un flux de travail d'approvisionnement Explorons comment une entreprise peut automatiser son processus d'approvisionnement et d'intégration des fournisseurs à l'aide des modules Move. Flux de travail traditionnel : La demande de devis (RFQ) est créée Le fournisseur soumet un devis manuellement Approbation interne par le responsable des achats Le bon de commande (PO) est émis Le fournisseur livre les marchandises et les factures Paiement traité par le biais du service financier Sur Sui avec modules Move : RFQModule émet une requête en chaîne QuoteModule accepte les soumissions d'offres cryptographiques Le module d'approbation vérifie la conformité et approuve automatiquement les devis éligibles Le module PurchaseOrderModule déclenche l'émission de contrats intelligents DeliveryModule suit les confirmations de réception en chaîne Le module de paiement libère les fonds automatiquement à la livraison ✅ Toutes les interactions sont enregistrées, exécutoires et vérifiables. Architecture de base d'un flux de travail automatisé basé sur les déplacements Les modules Move suivent généralement la structure suivante : 🔧 Conception du module : module procurement : :PurchaseOrder { struct Order a la clé { identifiant : u64, acheteur : adresse, fournisseur : adresse, statut : u8,//0 : En attente, 1 : Approuvé, 2 : Expédié, 3 : Payé montant : 64 u, } public fun approve_order (ordre : &mut Order) { affirmez ! (order.status == 0, « Commande déjà traitée ») ; état de la commande = 1 ; } public fun mark_shipped (commande : &mut Order) { affirmez ! (order.status == 1, « Commande non approuvée ») ; état de la commande = 2 ; } public funrelease_payment (commande : &mut Order) { affirmez ! (order.status == 2, « Article non encore expédié ») ; état de la commande = 3 ; //Logique de transfert de fonds au fournisseur } } 🔐 Contrôle d'accès : Vous pouvez définir qui peut appeler quelles fonctions à l'aide d'objets de capacité ou de contrôles de signature liés aux rôles de l'entreprise (par exemple, équipe financière, responsable, fournisseur). Avantages de l'automatisation modulaire des flux de travail ✅ Auditabilité : Chaque fonction émet des journaux qui peuvent être capturés et indexés à des fins de contrôle de conformité. ✅ Interopérabilité : Les modules peuvent référencer des objets externes tels que des factures, des reçus de livraison ou des informations d'identification utilisateur. ✅ Évolutivité : Une fois déployés, les modules peuvent desservir plusieurs départements, zones géographiques ou unités commerciales avec un minimum de duplication de code. ✅ Évolutivité : Grâce au système centré sur les objets de Sui, les modules peuvent être versionnés et mis à niveau sans perturber l'ensemble du système. Stratégie d'intégration d'entreprise Pour intégrer l'automatisation intelligente aux systèmes d'entreprise existants, Sui soutient : • Passerelles API pour intégrer les modules Move aux ERP traditionnels (par exemple, SAP, Oracle) • Webhooks ou services Oracle pour alimenter les événements hors chaîne (par exemple, les mises à jour d'expédition) • ZKLogin pour un accès basé sur les rôles via les systèmes d'identité d'entreprise (par exemple, Google Workspace, Azure AD) Exemple : • Une plateforme logistique intègre des capteurs IoT qui confirment l'arrivée GPS d'un camion → déclenche le contrat Sui pour marquer la livraison → déclenche l'autorisation de paiement. Étude de cas : Automatiser les réclamations d'assurance Enterprise : un assureur multinational Flux de travail automatisé : demandes d'indemnisation pour accidents de véhicules Ancien processus : inspection manuelle, règlements lents, taux de fraude élevé Nouveau flux de travail Sui : L'utilisateur dépose une réclamation sur une application mobile Images et données téléchargées hors chaîne L'IA confirme la gravité des accidents Le module Move vérifie la politique + vérifie l'horodatage/la localisation Le contrat est approuvé automatiquement ou augmente en fonction du score de confiance Le module de paiement libère les fonds de réclamation Résultats : • 80 % des demandes valides sont réglées en moins de 30 minutes • Diminution de 60 % des demandes frauduleuses • Piste d'audit complète accessible aux régulateurs et aux équipes de conformité Gouvernance et conformité au sein de Move Automation L'approche modulaire de Sui permet une gouvernance d'entreprise intégrée, telle que : • Approbation multisignature pour les transferts de grande valeur • Fonctions de pause/reprise personnalisées en cas de blocage légal • Liste blanche/liste noire des modules ou des portefeuilles interactifs • Logique d'entiercement pour les actions conditionnelles entre des parties non fiables Les modules Move peuvent être conçus pour refléter les politiques internes, la conformité régionale ou les normes spécifiques au secteur (telles que ISO, SOC2 ou PCI DSS). Défis et considérations relatives aux risques Atténuation des défis grâce aux modules Move Erreur humaine dans l'automatisation Utiliser le contrôle des capacités et la vérification formelle Divergence des flux de travail La conception modulaire permet des chemins parallèles ou personnalisés Intégration des systèmes existants Créez des ponts hybrides à l'aide de services hors chaîne Contrôle réglementaire Émettez des événements + des journaux structurés pour faciliter les audits Bugs liés aux contrats intelligents Effectuez des tests formels et des audits par des tiers Les entreprises qui adoptent Move doivent investir dans des systèmes de conception de contrats, d'évaluation par les pairs et de surveillance afin de garantir la fiabilité et la gouvernance. Conclusion : Sui + Move = révolution des flux de travail d'entreprise Les modules Move sur Sui représentent un changement de paradigme dans la manière dont les entreprises conçoivent et déploient la logique métier : • Automatisez les processus en toute transparence et sécurité • Réduire les coûts en minimisant les intermédiaires et les révisions manuelles • Adaptez-vous rapidement à l'évolution de la réglementation ou du marché grâce à une conception modulaire • Fournissez des services plus rapides et plus intelligents à vos clients et partenaires En faisant passer les flux de travail critiques à des contrats intelligents programmables et vérifiables, les entreprises optimisent leur efficacité, leur résilience et leur agilité stratégique dans un monde décentralisé.

    0

Sans réponse

  • casey.Peera.
    casey10
    PourSuiAug 13, 2025

    Comment estimer le coût du gaz pour une transaction SUI

    J'essaie d'envoyer une simple transaction sui sur le réseau sui à l'aide d'un script Java, j'essaie d'envoyer la totalité du solde sui du portefeuille A au portefeuille B, sans analyser manuellement un montant fixe, et je sais que je devrai payer des frais de gaz pour que ma transaction soit exécutée. Ma question est de savoir comment estimer le coût du gaz pour une transaction, afin qu'il puisse être soustrait du montant total de sui dans le portefeuille, puis analyser la valeur dans la transaction.

    0
    0
  • FUNLOP431.Peera.
    FUNLOP43110
    PourMoveAug 13, 2025

    Maîtriser Move on Sui Network : le guide complet pour les débutants et les constructeurs

    Si vous avez étudié le développement de chaînes de blocs, vous avez probablement remarqué un engouement croissant pourSui Networket son langage de programmation unique,Move. Il ne s'agit pas simplement d'un autre « langage contractuel intelligent » qui se bat pour attirer l'attention des développeurs. Move propose une approche complètement différente de la programmation blockchain : une approche rapide, sûre et parfaite pour les applications basées sur des actifs. Dans cet article, vous obtiendrez uneprésentation approfondie de Move on Sui : comment il fonctionne, pourquoi il est différent et comment vous pouvez commencer à en tirer parti. Nous explorerons également les erreurs courantes, les meilleures pratiques et des conseils pratiques pour réussir. ##1. Qu'est-ce que Move et pourquoi est-ce que Sui l'utilise ? Move est unlangage de programmation basé sur des bytecodesdéveloppé à l'origine par Meta (anciennement Facebook) pour la blockchain Libra/Diem. Sui a adopté Move mais l'a étendu et optimisé pour l'adapter à sonmodèle de données centré sur l'objet. À la base, Move est conçu pourgérer en toute sécurité les actifs numériques. Les langages de contrats intelligents traditionnels tels que Solidity traitent les actifs comme des chiffres figurant dans les soldes des comptes, mais dans Move, les actifs sont descitoyens de première classe. Cela signifie que : Les actifsne peuvent pas être dupliqués accidentelement. Les actifsne peuvent pas être perdussans les détruire explicitement. Les actifsdoivent être clairement identifiés. Cette philosophie permet de raisonner plus facilement sur la sécurité des actifs et d'éviter les bugs et les piratages courants. Pourquoi Sui a choisi Move : Sécurité :**La propriété des actifs est appliquée au niveau de la langue. Vitesse :**Les programmes Move s'exécutent rapidement et évitent les calculs inutiles. Flexibilité :**Vous pouvez créer des types d'actifs personnalisés au-delà de simples jetons. Exécution parallèle :**L'architecture de Sui permet au code Move de traiter les transactions en parallèle, augmentant ainsi le débit. ##2. Comment fonctionne Move sur Sui Alors que d'autres blockchains exécutent les transactions de manière séquentielle, Sui organise les données enobjets. Chaque objet : A unpropriétaire(il peut s'agir d'un utilisateur, d'un autre objet ou du système). Ne peut être modifié que par son propriétaire ou par des fonctions de déplacement spécifiques. Possède un identifiant unique. Move on Sui repose sur trois concepts principaux : 1.Objets Tout ce qui est stocké sur la chaîne est un objet. Les objets sont stockés et modifiés par les modules Move. Exemple : une pièce, un NFT, un personnage de jeu. 2.Modules Conteneurs pour le code Move. Définissez les types, les fonctions et les règles de comportement des objets. 3.Transactions Actions entreprises par les utilisateurs. Appelez les fonctions Move en leur transmettant les objets qu'elles possèdent. ##3. Comparaison entre Move et Solidity | Fonctionnalité | Move (Sui) | Solidity (Ethereum) | | -----------------| -------------------------------------------------| -------------------------------------------| |Objectif principal| Sécurité des actifs, propriété | Logique générale des contrats intelligents | |Modèle de données| Basé sur les objets | Basé sur les comptes | |Exécution| Parallélisé (lorsqu'aucun objet n'est en conflit) | Séquentiel | |Sécurité des types| Fortement dactylographié, les ressources ne peuvent pas être copiées/déposées | Système de saisie plus souple | |Sécurité| Empêche les doubles dépenses et les pertes involontaires d'actifs | Problèmes courants : réentrée, dépassement d'entiers | Si vous venez de Solidity, vous remarquerez que Movevous obligeà être explicite sur la gestion des actifs. C'est parfois frustrant au début, mais c'est aussi la raison pour laquelle les programmes Move sont plus difficiles à exploiter. ##4. Rédaction de votre module First Move sur SUI Passons en revue un exemple de base de Move : un module qui crée et transfère un jeton personnalisé. ###Création d'un jeton module my_project::my_coin { use sui::coin; use sui::transfer; use sui::tx_context::{self, TxContext}; /// Create a new coin type struct MyCoin has drop, store {} /// Initialize a new coin and send it to the transaction sender public entry fun mint(ctx: &mut TxContext) { let coin = coin::mint(1000, ctx); transfer::transfer(coin, tx_context::sender(ctx)); } } Explication : struct MyCoindéfinit un nouveau type de pièce. mintLa fonction crée 1 000 unités MyCoinet les transfère à l'expéditeur. TxContextdonne accès aux détails de la transaction (comme la personne qui l'a envoyée). ##5. Les types de ressources de Move — La sauce secrete Move introduit lestypes de ressources, qui sont desstructures de données non copiables et non duplicables. Concrètement : si vous avez un billet de 10$, vous ne pouvez pas simplement le « copier », vous le conservez ou vous le donnez. Les ressources fonctionnent de la même manière. En mouvement : struct MyCoin has key, store { value: u64 } key**— Peut être stocké en tant qu'objet de niveau supérieur. store**— Peut être stocké à l'intérieur d'un autre objet. Si vous essayez decopierune ressource, le compilateur refusera de compiler votre code. Cela permet d'éviter les bogues dans lesquels des actifs sont clonés accidentellement. ##6. Les extensions de déménagement spécifiques à Sui Sui a apporté plusieurs modifications à vanilla Move afin de l'optimiser pour l'exécution basée sur les objets : Champs d'objets dynamiques :**Vous pouvez ajouter des champs aux objets une fois qu'ils ont été créés. Objets partagés :**Plusieurs utilisateurs peuvent interagir avec le même objet. Références mutables :**Autorisez la modification des données des objets de manière contrôlée. Émission d'événements :**Les modules Move peuvent émettre des événements pour les auditeurs hors chaîne. Par exemple, créer un classement de jeu partagé : struct Leaderboard has key { scores: vector } Cela pourrait être mis à jour par plusieurs joueurs sans provoquer de goulots d'étranglement à l'échelle de la blockchain. N°7. Flux de développement Voici le flux de travail de base pour développer avec Move on Sui : 1.Installez Sui CLI curl -fsSL https://sui.io/install.sh | bash 2.Créez un nouveau package Move sui move new my_project sourcesÉcrivez vos modulesdans le dossier. 4.Créez votre package sui move build 5.Publier sur Sui sui client publish --gas-budget 100000000 6.Fonctions d'appelen utilisant : sui client call --package --module my_module --function my_function #8. Test de votre code de déménagement Sui Move prend en charge les tests unitaires directement dans la langue. Exemple : #[test] fun test_mint() { let ctx = test::new_tx_context(@0x1); my_project::my_coin::mint(&mut ctx); // Add assertions here } Exécutez des tests : sui move test N°9. Erreurs courantes commises par les débutants Oublier de transmettre TxContext**— De nombreuses fonctions nécessitent de &mut TxContextcréer ou de transférer des objets. Incompréhension de la propriété de l'objet**— Si vous ne le possédez pas, vous ne pouvez pas le muter. Ne pas gérer la destruction des actifs**— Vous devez explicitement « détruire » les ressources dont vous n'avez plus besoin. Publier sans version**— La mise à jour d'un module implique la publication d'une nouvelle version. ##10. Meilleures pratiques pour Move on Sui Utilisez des conventions de dénomination claires**— Rend le code lisible. Limiter l'utilisation des objets partagés**— Ils sont plus lents que les objets possédés. Émettre des événements pour les changements d'état**— Aide à l'indexation hors chaîne. Rédigez des tests approfondis**— Le compilateur détecte beaucoup de choses, mais des bogues logiques persistent. Documentez vos modules**— À l'avenir, vous vous en remercierez. ##11. Cas d'utilisation réels Ressources de jeu**— Chaque épée, skin ou animal de compagnie peut être un objet unique. Marketplaces NFT**— Transferts et enchères sécurisés avec contrôles de propriété intégrés. Protocoles DeFi**— Prêts, jalonnement et échanges utilisant une gestion sécurisée des actifs. Suivi de la chaîne d'approvisionnement**— Représentez les marchandises comme des objets se déplaçant dans le système. ##12. L'avenir de Move on Sui Le langage Move de Sui continue d'évoluer. Les travaux actuels incluent : De meilleursoutils pour développeurs. Bibliothèques standard**pour les modèles courants. Interopérabilité**avec d'autres blockchains. À mesure que l'adoption augmente, nous pouvons nous attendre à une documentation plus riche, à des projets open source plus importants et à des intégrations plus approfondies avec l'infrastructure Web3. ##Réflexions finales Si vous voulez vraiment créer desapplications blockchain sécurisées et performantes, Move on Sui mérite votre attention. Sa conception stricte mais logique vous permet d'éviter des catégories entières de bugs tout en permettant des cas d'utilisation innovants qui ne sont pas possibles sur les chaînes de comptes traditionnelles. Que vous créiez un protocole DeFi, un jeu ou un écosystème NFT complexe, Move vous fournit leséléments de base pour un avenir blockchain plus sûr et plus rapide.

    0
    0
  • theking.Peera.
    theking918
    PourSuiJul 25, 2025

    Quelle est la norme d'affichage des objets sur Sui ?

    L'Object Display Standard (https://docs.sui.io/standards/object-display) définit la manière dont les objets Sui (par exemple, les NFT) sont affichés avec des métadonnées telles que le nom, la description et les URL des images. Il est utilisé pour un rendu cohérent dans les portefeuilles et les places de marché. Implémentez-le dans votre contrat Move en ajoutant une structure Display avec des champs tels que name et image_url. Consultez les exemples de code Sui NFT (https://github.com/MystenLabs/sui).

    2
    0

Tendance

  • Vens.sui.Peera.
    Vens.sui213
    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

    9
    3
  • 0xduckmove.Peera.
    0xduckmove2018
    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
  • BigSneh.Peera.
    BigSneh2024
    PourSuiJul 30, 2025

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

    7
    13