Prime
Gagnez des jetons pour vos contributions.
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.
Publications
5+15
Questions et Réponses avec des ExpertsXavier.eth313PourSuiJun 27, 2025Échec de la transaction Sui : objets réservés pour une autre transaction
Je rencontre un problème persistant JsonRpcErrorlorsque j'essaie d'exécuter des transactions sur Sui. L'erreur indique que les objets sont réservés pour une autre transaction, même si j'ai implémenté un traitement séquentiel des transactions avec des retards. JsonRpcError: Failed to sign transaction by a quorum of validators because one or more of its objects is reserved for another transaction. Other transactions locking these objects: AV7coSQHWg5vN3S47xada6UiZGW54xxUNhRv1QUPqWK (stake 33.83) 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 J'ai essayé : Exécution séquentielle des transactions (en attente de la fin de la transaction précédente) Ajout de délais de 3 secondes entre les transactions Et j'obtiens toujours la même erreur. Utilisation de Sui RPC pour la soumission des transactions. Le même identifiant d'objet apparaît plusieurs fois dans la liste de verrouillage. Une erreur se produit même avec un séquençage minutieux des transactions. Qu'est-ce qui fait que les objets sont « réservés » pour d'autres transactions ? Comment puis-je vérifier correctement si un objet est disponible avant de l'utiliser dans une transaction ? Existe-t-il des bonnes pratiques pour gérer les verrous d'objets dans Sui ? Cela pourrait-il être lié au calendrier de finalité de la transaction ? Quelqu'un a-t-il déjà rencontré ce problème ? Toute information sur la gestion appropriée des objets dans les transactions Sui serait grandement appréciée !
- Sui
- Transaction Processing
- Move
25+15
Questions et Réponses avec des ExpertsXavier.eth313PourSuiJun 17, 2025Comment 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é.
- Sui
- Architecture
05Meilleure réponse+10
Questions et Réponses avec des ExpertsPourSuiMay 29, 2025Pourquoi BCS exige-t-il un ordre de champs exact pour la désérialisation alors que les structures Move ont des champs nommés ?
Pourquoi BCS exige-t-il un ordre de champs exact pour la désérialisation alors que les structures Move ont des champs nommés ? J'ai approfondi le codage/décodage BCS dans Move, en particulier pour la communication inter-chaînes et le traitement des données hors chaîne. En parcourant les exemples de la documentation de Sui Move, j'ai rencontré un comportement qui semble contre-intuitif et j'essaie de comprendre les décisions de conception sous-jacentes. Selon la spécification BCS, « il n'y a pas de structures dans BCS (puisqu'il n'y a pas de types) ; la structure définit simplement l'ordre dans lequel les champs sont sérialisés ». Cela signifie que lors de la désérialisation, nous devons utiliser peel_*les fonctions exactement dans le même ordre que la définition du champ de structure. Mes questions spécifiques : Justification de la conception : pourquoi BCS exige-t-il une correspondance exacte de l'ordre des champs alors que les structures Move ont des champs nommés ? Ne serait-il pas plus robuste de sérialiser les noms de champs à côté des valeurs, de la même manière que le JSON ou d'autres formats auto-descriptifs ? Interaction entre types génériques : La documentation mentionne que « les types contenant des champs de type générique peuvent être analysés jusqu'au premier champ de type générique ». Considérez cette structure : struct ComplexObject has drop, copy { id: ID, owner: address, metadata: Metadata, generic_data: T, more_metadata: String, another_generic: U } Comment fonctionne exactement la désérialisation partielle ici ? Puis-je désérialiser jusqu'à more_metadata et ignorer les deux champs génériques, ou est-ce que le premier champ générique (generic_data) bloque complètement la poursuite de la désérialisation ? Cohérence entre les langues : lorsque vous utilisez la bibliothèque JavaScript @mysten /bcs pour sérialiser les données qui seront consommées par les contrats Move, que se passe-t-il si : Je réorganise accidentellement les champs de l'objet JavaScript ? La définition de la structure Move change l'ordre des champs lors d'une mise à niveau du contrat ? J'ai des structures imbriquées avec leurs propres paramètres génériques ? Implications pratiques : dans les systèmes de production, comment les équipes gèrent-elles l'évolution du schéma BCS ? Versiez-vous vos schémas BCS ou vous attendez-vous à ce que l'ordre des champs de structure soit immuable une fois déployé ?
- Sui
- Move
53Meilleure réponse+10
Questions et Réponses avec des ExpertsPourMoveMar 11, 2025Sui 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?
- Move
21Meilleure réponse+10
Questions et Réponses avec des ExpertsPourSuiMar 05, 2025« 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.
- Sui
- SDKs and Developer Tools
43Meilleure 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
- 2565
- 1780
- 1056
- 903
- 711
- 536
- 527
- 486
- 415
- 402