Publication
Partagez vos connaissances.
+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<T: key + store>(
marketplace: &mut Marketplace,
asset: T,
price: u64
) { /* ... */ }
// But how to handle soulbound assets?
public fun list_soulbound<T: key>( // 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'utilisation
dynamic_field::add<K, V>()
, en a-t-onV
toujours besoinstore
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 + copy
vskey + 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
Asset<Type1>
et stockerAsset<Type2>
dans 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
Connaissez-vous la réponse ?
Veuillez vous connecter et la partager.
Sui is a Layer 1 protocol blockchain designed as the first internet-scale programmable blockchain platform.
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.

- Owen... SUI+137
1
- 0xduckmove... SUI+55
2
- MoonBags... SUI+50
3
- ... SUIdudley_smith+31
- ... SUI
- ... SUIderiss+15
- ... SUIPluto Dev👽+10
- ... SUIDominikus +10
- ... SUIandreweth.+10
- ... SUIfarshad+10
- Pourquoi BCS exige-t-il un ordre de champs exact pour la désérialisation alors que les structures Move ont des champs nommés ?52
- « Erreurs de vérification de sources multiples » dans les publications du module Sui Move - Résolution automatique des erreurs41
- Comment les contraintes de capacité interagissent-elles avec les champs dynamiques dans des collections hétérogènes ?00