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

  • Peera Admin.Peera.
    Peera Admin31
    PourMoveMar 11, 2025
    +10

    Sui Move vs Aptos Move - What is the difference?

    Sui Move and Aptos Move - two prominent implementations of the Move programming language. While both are rooted in the same foundational principles, they have diverged significantly in design, execution, and ecosystem development. To better understand their differences, we need to uncover some of their key aspects: How do their runtimes differ? Both Sui and Aptos implement their own custom Move virtual machines (VMs). How does this impact performance, scalability, and developer experience? For instance: Does Sui's runtime optimize for parallel execution differently than Aptos'? Are there notable differences in transaction lifecycle management or gas models? What are the differences between their standard libraries? The Move standard library is a critical component for building smart contracts. However, Sui and Aptos have forked their implementations, leading to divergence: Are there modules or functions unique to one implementation but absent in the other? How do these differences affect common use cases like token creation, NFTs, or decentralized finance (DeFi)? How does data storage differ between them? One of the most significant distinctions lies in how Sui and Aptos handle data storage: Sui uses an object-centric model, where each object has its own ownership and permissions. Aptos, on the other hand, retains a more traditional account-based model similar to Ethereum. How does this impact state management, composability, and gas efficiency? Is it fair to say that Aptos is closer to EVM while Sui is closer to SVM? Some developers argue that Aptos' account-based architecture resembles Ethereum's EVM, while Sui's object-centric approach aligns more closely with Solana's SVM. Do you agree with this analogy? Why or why not? How does this architectural choice influence developer ergonomics and application design? Are there universal packages working for both Sui Move and Aptos Move? Given their shared origins, it would be ideal if some libraries or tools were interoperable across both ecosystems. Are there any existing universal packages or frameworks that work seamlessly on both platforms? If not, what are the main barriers to achieving compatibility? Can one of them be transpiled into another? If a project is built on Sui Move, could it theoretically be transpiled to run on Aptos Move, or vice versa? What are the technical challenges involved in such a process? Are there tools or compilers currently available to facilitate this kind of migration?

    2
    1
  • Peera Admin.Peera.
    Peera Admin36
    PourSuiMar 05, 2025
    +10

    « Erreurs de vérification de sources multiples » dans les publications du module Sui Move - Résolution automatique des erreurs

    Les développeurs travaillant avec Sui Move rencontrent fréquemment des problèmes liés à des « erreurs de vérification de sources multiples détectées » lorsqu'ils tentent de publier ou de mettre à niveau des modules. Ces erreurs sont dues à des incohérences entre les dépendances locales et leurs homologues en chaîne, ce qui entraîne des échecs de publication et des problèmes de déploiement. Vous trouverez ci-dessous un exemple consolidé des erreurs auxquelles les développeurs sont confrontés : Failed to publish the Move module(s), reason: [warning] Multiple source verification errors found: Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::vec_set Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::vec_map Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000001::MoveStdlib::bit_vector Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000001::MoveStdlib::ascii Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::hex Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::zklogin_verified_id Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::prover Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::coin Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::dynamic_field Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::transfer On-chain version of dependency Sui::zklogin_verified_id was not found. On-chain version of dependency Sui::zklogin_verified_issuer was not found. Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::tx_context Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::transfer_policy Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::kiosk Ce problème se pose souvent pour les raisons suivantes : Versions incompatibles entre l'environnement de développement local (par exemple, Sui CLI) et l'état de la chaîne. Différences dans la configuration des packages entre les réseaux (par exemple, Mainnet contre Testnet). Dépendances manquantes ou obsolètes dans l'environnement en chaîne. Questions clés Comment pouvons-nous automatiser la détection et la résolution de ces incohérences de dépendance pendant le processus de publication ? Quels outils ou scripts peuvent être développés pour garantir que les dépendances locales s'alignent toujours sur leurs homologues en chaîne ? Existe-t-il un moyen de rationaliser ce processus en intégrant des contrôles de dépendance dans les pipelines CI/CD existants ou en améliorant le SDK Sui ? Votre tâche consiste à proposer une solution qui réponde à ces défis, en garantissant des déploiements plus fluides et plus fiables pour les développeurs de Sui Move. N'oubliez pas de publier votre solution ci-dessous.

    4
    1

Le plus nouveau

  • Pluto Dev👽.Peera.
    Pluto Dev👽10
    PourWalrusMay 01, 2025

    Where else can I get SUI from a faucet?

    I've been using a SUI faucet for some transactions, but I'm looking for alternative options to receive SUI tokens. Are there other faucets or methods I can try?

    0
    1
  • McMMoKing.Peera.
    McMMoKing175
    PourSuiMay 01, 2025

    Comment résoudre les problèmes de connexion au portefeuille Sui et au Ledger ?

    Je rencontre des problèmes avec mon portefeuille Sui sur le navigateur Brave, protégé par mon appareil Ledger. Lorsque j'essaie d'envoyer des fonds à une plateforme d'échange, elle me demande de connecter le Ledger, mais elle prétend qu'il est déconnecté. Comment puis-je résoudre ce problème ? Et ai-je besoin de la phrase de récupération des données pour reconnecter mon Ledger ?

    0
    2
  • elfDani.Peera.
    elfDani10
    PourWalrusMay 01, 2025

    Is my file private when uploaded to Walrus?

    I'm thinking of using Walrus for storing some files. My main concern is whether my files are private by default when I upload them. I don't really want my personal or sensitive data out in the open for everyone to see. Can someone let me know if there's a way to keep my files private, or should I be looking into alternatives?

    0
    1

Sans réponse

  • Rogue.Peera.
    Rogue82
    PourSuiApr 25, 2025

    Meilleur memecoin sur SUI

    Donnez-moi des memecoins SUI

    2
    0
  • RogueRig.Peera.
    RogueRig82
    PourSuiApr 25, 2025

    Walrus Protocol - Le joyau caché de SUI

    Le terme « Walrus » dans le contexte des documents que vous avez fournis fait référence à une plate-forme de stockage décentralisée développée par Mysten Labs, qui fait partie de l'écosystème Sui. Walrus est conçu pour répondre aux besoins de stockage de données à grande échelle que les blockchains traditionnelles ne peuvent pas gérer efficacement. Il propose une solution de stockage rentable, évolutive et programmable, renforçant la position de Sui en tant que couche de coordination mondiale. La plateforme Walrus est également associée au jeton WAL, qui joue un rôle crucial dans l'alimentation du réseau grâce à une preuve de participation déléguée et dans la garantie d'un stockage fiable des données grâce à de nouveaux défis d'attestation. De plus, Walrus est utilisé pour stocker du contenu multimédia, comme le démontre Decrypt, un média Web3 de premier plan, qui publie l'intégralité de sa bibliothèque de contenu sur Walrus. Pour des informations plus détaillées, vous pouvez consulter le livre blanc Walrus.

    1
    0
  • 1 Luca.Peera.
    1 Luca186
    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

  • 0xduckmove.Peera.
    0xduckmove220
    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
  • harry phan.Peera.
    harry phan360
    PourSuiApr 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.

    5
  • 0xduckmove.Peera.
    0xduckmove220
    PourSuiApr 25, 2025

    Récapitulatif : la vidéo peut dynamiser votre parcours Sui Dev

    Soyons réalistes, si vous avez déjà construit surSui, vous avez probablement heurté des murs. Qu'il s'agisse d'identifier des objets cryptés, de jongler avec des CLI ou de créer des réseaux locaux, c'est comme se préparer à un combat de boss avant même d'avoir écrit votre première ligne de logique métier. Lors d'un récent atelier organisé dans le cadre de la série Road to Overflow, Moven de la Fondation Dubhe a expliqué comment fonctionne Dubhe Engine, quels problèmes il résout et en quoi c'est bien plus qu'un simple outil, c'est un mouvement en pleine croissance. Lien vidéo : https://www.youtube.com/watch?v=CHkOS-TYehM Le problème : outillage fragmenté, configuration lourde Moven a débuté par une véritable discussion sur le paysage actuel des développeurs Sui : Les nouveaux arrivants sont confrontés à une courbe d'apprentissage ardue : configuration de portefeuilles, récupération de jetons de test, packages d'échafaudage, apprentissage de la syntaxe Move, création de réseaux de test locaux, configuration de SDK, etc. Même les développeurs expérimentés perdent du temps à effectuer des tâches de configuration répétitives au lieu de se concentrer sur la véritable logique DApp. Les bases de code deviennent rapidement monolithiques : des fichiers .move volumineux et désordonnés contenant des structures de données, des constructeurs, des assistants et des fonctions de saisie sont tous entassés. En résumé : l'écosystème se développe rapidement, mais les outils n'ont pas suivi le rythme jusqu'à présent. ##La solution : la génération de code basée sur un schéma Au cœur deDubhe Enginese trouve une idée clé : ledéveloppement axé sur le schéma. Avec un seul fichier de configuration (d.config.ts), les développeurs peuvent définir : Leurs structures de données en chaîne Évènements Erreurs Types personnalisés (même des vecteurs 2D de structures auto-définies !) À partir de là, une commande (pnpm dub schema:gen) génère automatiquement un package Move entièrement structuré et une intégration frontend, avec : Structure de fichiers modularisée Composabilité en chaîne (via des importations depuis les packages publiés par Sui) Configuration, génération, déploiement et prise en charge du frontend Localnet (prêt pour Next.js) C'est vous qui écrivez la logique.Dubhegère le passe-partout. ##* ⏱️ Impact réel : 80 % de code répétitif en moins* Lors d'expériences internes, des projets générés par Dubb ont montré que seulement* 20 % du code*devait être écrit manuellement, le reste étant constitué d'échafaudages générés automatiquement via des schémas. Cela signifie un prototypage plus rapide, moins de bugs et plus de temps pour vous concentrer sur l'essentiel : la valeur fondamentale de votre application  ##Un moteur d'écosystème de développement Dubb ne s'arrête pas aux échafaudages. Movin l'a clairement indiqué : il s'agit d'une infrastructure pour une nouvelle économie des développeurs. Voici comment évolue la communauté Dubb Engine : Subventions sur le gaz :**Pour les nouveaux constructeurs qui expérimentent Dubb Task Bounties :**Comme les « bons premiers numéros » de GitHub, mais avec des récompenses Niveau de gouvernance (D-OS) :**Vote en chaîne pour la priorisation des projets Support Launchpad :**Aider les projets arrivés à maturité à obtenir un financement DApp Staking :**Les utilisateurs peuvent miser des jetons D pour soutenir leurs DApps préférés et voter sur les décisions relatives à la feuille de route Cette boucle de feedback alimente l'ensemble de l'écosystème Sui : plus de développeurs → plus d'applications → plus d'utilisateurs → plus de développeurs.

    5
Nous utilisons des cookies pour vous assurer la meilleure expérience sur notre site Web.
Plus d'infos