Wie interagieren Fähigkeitsbeschränkungen mit dynamischen Feldern in heterogenen Sammlungen?

Question

Ich baue einen Marktplatz auf, der mit mehreren Asset-Typen mit unterschiedlichen Fähigkeitsanforderungen umgehen muss, und ich bin auf einige grundlegende Fragen zum Typensystem von Move gestoßen. Ich möchte verschiedene Asset-Typen in derselben Sammlung speichern, aber sie haben unterschiedliche Fähigkeiten:

Reguläre NFTs: key + store(übertragbar)
key Nur Soulbound-Token (nicht übertragbar)
Benutzerdefinierte Vermögenswerte mit Übertragungsbeschränkungen

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? */ }

Die wichtigsten Fragen:

Anforderungen an die Fähigkeiten: Wird bei der Verwendung dynamic_field::add<K, V>()``Vimmer store zur Kompilierzeit benötigt? Können Wrapper-Typen das umgehen?
Heterogener Speicher: Kann ein einziger Beutel Objekte mit unterschiedlichen Fähigkeiten (key + store + copyvskey + store) speichern und sie zur Laufzeit unterschiedlich handhaben?
Typsicherheit: Da dynamische Felder eine Typlöschung durchführen, wie kann ich die Typsicherheit beim Abrufen von Werten gewährleisten? Nach welchem Muster werden Typmetadaten gespeichert?
Zeugenmuster: Wie funktionieren Fähigkeitsbeschränkungen bei Phantomtypen? Kann ich Asset<Type1>``Asset<Type2>Informationen zum Typ speichern und in derselben Sammlung speichern und zu einem späteren Zeitpunkt extrahieren?

Aufbau eines Systems, in dem NFTs, Soulbound-Token und eingeschränkte Vermögenswerte alle Marktplatzfunktionen benötigen, jedoch mit unterschiedlicher Übertragungssemantik.

Ich habe Wrapper-Typen ausprobiert, mehrere Sammlungen pro Fähigkeitssatz, separate Typ-Metadatenspeicherung. Jede hat Kompromisse zwischen Typsicherheit, Gaskosten und Komplexität.

harry phan · Accepted Answer

You’re running into the core of Move’s type and ability system and you’re absolutely right to raise these questions when designing a heterogeneous marketplace. First, about ability constraints: any value you store using dynamic_field::add() must have the store ability at compile time. This is a hard rule in Move: values without store simply can’t be persisted in storage, whether in dynamic fields, Tables, or similar constructs. Trying to wrap a non-store type in a struct won’t work either—Move is strict here. If even one field lacks store, the entire wrapper loses store too. So unfortunately, there’s no wrapper workaround here. Soulbound assets with only key (and no store) are excluded from any collection that writes to global storage like a Bag or dynamic field. This is well documented in the Move abilities docs. As for storing different asset types in the same collection: if they all implement key + store, then yes, a single Bag can store them, but under the hood, Move doesn’t do real polymorphism. The type must be known at access time, and the Bag must be homogeneous from the compiler’s perspective. This leads to your next question: how do we maintain type safety in dynamic fields? Since Move does type erasure for these collections, it won’t remember what exact type is inside—you need to provide the mapping. One common pattern is to wrap each asset in a struct that includes metadata like a u8 enum or a TypeName, so when you retrieve the object, you inspect the metadata and downcast or handle accordingly. There’s no magic RTTI; you fake it with data discipline. Now about phantom types and witness patterns—these are helpful for compile-time safety but don’t give you runtime introspection. So yes, you can create Asset and have T vary, but every instantiation of Asset must still satisfy the collection’s ability constraints. If you want to store both Asset and Asset in the same place, they must both implement store, and SoulboundToken likely won’t. You’ll need to handle those differently—possibly using references or storing only metadata for non-transferable assets, instead of trying to store the object. In your marketplace design, this means you’re likely looking at a hybrid strategy. For regular NFTs and other transferable assets, you can use dynamic object fields or Bags freely, as long as they conform to key + store. For soulbound assets, which are key only, your best bet is to store references and associated metadata in a parallel metadata Bag, or use a custom listing type that doesn’t store the asset itself but records its existence via ID and supplementary data. It’s more complex, but it gives you the flexibility to enforce transfer semantics properly. References https://github.com/MystenLabs/sui/blob/c7ec9546978b3c52b0c57bbdb9693f5068dd3383/external-crates/move/documentation/book/src/abilities.md https://github.com/sui-foundation/sui-move-intro-course/blob/92bb4986ad91c5ffd01c10c5b0d3bbbfa9d12507/unit-four/lessons/2_dynamic_fields.md

Owen · Answer

1. Do values in dynamic fields always need store? If you want to store the value directly in a dynamic field (e.g., via dynamic_field::add), it must satisfy all the abilities required by the fields type — including store. If V does not have store, you cannot put it into a dynamic field directly. But heres the trick: You can wrap such types inside another struct that has store, even if the inner type doesnt. Example: struct AssetWrapper has store { inner: T, } Even though T only has key, AssetWrapper can be stored because it itself has store. Now you can do: dynamic_field::add(&mut object, key, AssetWrapper { inner: soulbound_token }); This allows you to store both transferable and non-transferable assets under the same abstraction. 2. Can a single Bag store objects with different ability sets? The short answer is: yes, using wrappers and type erasure techniques. But there are tradeoffs. In Move, you can’t directly have a list of multiple concrete types unless they’re wrapped in a generic container. A good approach is to use a wrapper like: struct AnyAsset has store { // Maybe include metadata or witness type info data: Vector, // serialized representation? type_info: TypeInfo, // Type metadata } Or better yet, use a variant-style enum encoding (if supported by your Move dialect): enum AssetType has store { Transferable(NFT), Soulbound(SoulboundToken), Restricted(RestrictedAsset), } However, this requires exhaustive matching and doesnt scale well across modules. So, again: wrapping + dynamic fields + type metadata is more flexible. 3. How to maintain type safety when retrieving? Move performs type erasure in dynamic fields. So once you retrieve a value from a dynamic field, you just get a value of some type V — but you dont know what V is at runtime. To solve this safely, you need to: Store type metadata alongside the value. Use a witness pattern or type tag embedding to reassert type information upon retrieval. Pattern: Store type metadata struct AssetWithMetadata has store { value: T, type_info: TypeInfo, } Then store AssetWithMetadata or AssetWithMetadata in a dynamic field. When you retrieve, check the type_info against the expected type before doing anything unsafe. 4. Witness Pattern & Phantom Types You can absolutely use phantom types as witnesses to encode behavior, like transferability. For example: struct Transferable; // marker type struct NonTransferable; // marker type struct Asset has key, store { id: UID, policy: PhantomData, } Then: type NFT = Asset; type Soulbound = Asset; You can then write logic like: public fun transfer(asset: Asset) { // allowed } public fun transfer(_asset: Asset) { // disallowed abort(); } This gives you compile-time enforcement of transfer rules. But to store both types in the same collection, you’ll still need a wrapper: struct AnyAsset has store { data: Vector, type_info: TypeInfo, } And handle deserialization dynamically based on type_info.

0xduckmove · Answer

Here’s how you can design a Sui Move marketplace that supports both transferable (NFTs, key + store) and soulbound (key only) assets, while maintaining type safety and handling ability constraints. Ability Requirements for Dynamic Fields Yes, V must have store at compile time for dynamic_field::add() and similar collections. store is required for any value to be stored in global storage, including dynamic fields and Tables. Wrapper types cannot work around this: If you wrap a type without store in a struct, the wrapper cannot have store either, because all fields must have store for the struct to have store (source). Heterogeneous Storage in a Bag Bag (or any dynamic field-based collection) can only store types that satisfy the required abilities. For dynamic object fields, the value must have key + store. For dynamic fields, the value must have store. You cannot store a type with only key (e.g., a soulbound token) in a Bag that requires store. This is a fundamental restriction of the Move type system (source). Type Safety and Type Erasure Dynamic fields are type-erased at runtime. You must know the type you want to retrieve at access time. Pattern for type safety: Store type metadata (e.g., an enum or TypeName) alongside the value. Use a wrapper struct that includes both the asset and its type info. When retrieving, check the metadata before casting. Example pattern: Store Listing { asset_type: u8, ... } and use asset_type to determine how to handle the asset. Witness Pattern and Phantom Types Phantom types and the witness pattern help at compile time, not runtime. You can use Asset for different types, but you still need to ensure all T have the required abilities for the collection. At runtime, you cannot extract type info from a phantom type; you must store explicit metadata (source). Marketplace Design for Mixed Asset Types Transferable assets (NFTs): Use key + store, store in dynamic object fields or Bags. Soulbound tokens (key only): Cannot be stored in dynamic fields or Bags that require store. You must handle them separately, e.g., by storing only metadata or references (not the object itself). Custom assets with restrictions: As long as they have key + store, you can store them. If not, you need a separate handling path. All values in dynamic fields or Bags must have store (and key for dynamic object fields). You cannot store types with only key in these collections. Type safety at runtime requires explicit metadata. Phantom types/witness pattern help at compile time, not runtime.

md rifat hossen · Answer

Thank you Xavier.eth for this thoughtful and technical question. Heres my contribution regarding ability constraints and dynamic fields in Sui Move: ✅ Yes, any value (V) used in dynamic_field::add() must have store ability. This is strictly enforced in Move’s compile-time checks. Even wrapping a non-store value inside a struct wont help—if any field lacks store, the whole struct loses it too. ✅ Storing heterogeneous assets with different abilities is possible, but only under the constraint that all assets in the dynamic field/Bags must satisfy the same ability set (typically key + store). 🔒 Soulbound assets with only key ability cant be stored directly in such collections. Instead, you can: Store only metadata (ID, type enum, etc.) Use a parallel mapping like dynamic_field::add for soulbound types. Keep a reference-based registry that tracks soulbound asset listings without storing the full object. 🧩 Phantom types help at compile time only. You’ll still need explicit runtime type metadata for actual retrieval logic. 🚀 Suggested hybrid architecture: Bag for assets with store Map for key-only types AssetWrapper struct with type_id or u8 asset_type for identifying type at runtime Thanks again I look forward to seeing this marketplace evolve — md rifat hossen

24p30p · Answer

If youre building a marketplace that supports multiple asset types with different abilities in Sui Move, the key challenge is how Moves ability constraints interact with dynamic fields and heterogeneous data. You cant directly store values without the store ability, so yes—when you use dynamic_field::add(), the value V must have the store ability at compile time. This means you can’t directly store something like a soulbound token unless it’s wrapped in a type that has store. To work around this, you can use wrapper structs that hold metadata about the asset or a reference ID while satisfying the required abilities. For example, a SoulboundListing wrapper can contain just a reference or metadata, not the full object. For heterogeneous storage, a Bag or Table can only store one type per instantiation, but you can make it work by wrapping assets in an enum-like custom type or using trait-like phantom types to simulate type information. You wont get native polymorphism, but you can track asset types with manual tagging or use the witness pattern, where phantom types and runtime discriminants help you simulate type-level separation. If youre using Asset for each asset type, and both T1 and T2 are phantom, then yes—you can store Asset and Asset in a shared container by type-erasing to a common wrapper. Youll then need to store type info separately (like a type_id field) to correctly match when reading. It’s a balancing act between type safety, gas efficiency, and design complexity. Using separate collections per asset type is the cleanest for safety, but wrapper types and indexed metadata are more scalable when you want flexibility. You’ll need to choose based on whether gas cost or developer simplicity matters more for your use case.

Beitrag

Teile dein Wissen.

Wie interagieren Fähigkeitsbeschränkungen mit dynamischen Feldern in heterogenen Sammlungen?

Antworten

1. `store`Müssen Werte in dynamischen Feldern immer benötigt werden?

Beispiel:

Muster: Typ-Metadaten speichern

Anforderungen an die Fähigkeiten dynamischer Felder

Heterogener Speicher in einer Tasche

Tippsicherheit und Typlöschung

Zeugenmuster und Phantomtypen

Weißt du die Antwort?

Verdiene deinen Anteil an 1000 Sui

Beitrag

Teile dein Wissen.

Wie interagieren Fähigkeitsbeschränkungen mit dynamischen Feldern in heterogenen Sammlungen?

Antworten

1. storeMüssen Werte in dynamischen Feldern immer benötigt werden?

Beispiel:

Muster: Typ-Metadaten speichern

Anforderungen an die Fähigkeiten dynamischer Felder

Heterogener Speicher in einer Tasche

Tippsicherheit und Typlöschung

Zeugenmuster und Phantomtypen

Weißt du die Antwort?

Verdiene deinen Anteil an 1000 Sui

1. `store`Müssen Werte in dynamischen Feldern immer benötigt werden?