能力约束如何与异构集合中的动态字段相互作用？

Question

我正在建立一个需要处理具有不同能力要求的多种资产类型的市场，我遇到了一些关于Move类型系统的基本问题. 我想将不同的资产类型存储在同一个集合中，但它们有不同的能力：

-常规 NFT：key + store（可转让） -Soulbound 代币：key 仅限（不可转让） -具有转移限制的自定义资产

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

关键问题：

-能力要求：使用时dynamic_field::add<K, V>()，V``store 编译时是否总是需要的？包装器类型能解决这个问题吗？ -异构存储：单个 Bag 能否存储具有不同能力集（key + store + copyvskey + store）的对象，并在运行时以不同的方式处理它们？ -类型安全：由于动态字段会执行类型擦除，因此在检索值时如何保持类型安全？存储类型元数据的模式是什么？ -见证模式：能力限制如何与幻影类型一起使用？我可以将Asset<Type1>和存储Asset<Type2>在同一个集合中并稍后提取类型信息吗？

建立一个系统，在该系统中，NFT、soulbound 代币和受限资产都需要市场功能，但转移语义不同.

我尝试过包装器类型，每个能力集合有多个集合，单独的类型元数据存储. 每种方法都在类型安全性、燃气成本和复杂性之间进行权衡.

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

BigDev · 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.

帖子

分享您的知识。

能力约束如何与异构集合中的动态字段相互作用？

答案

1. 动态字段中的值总是需要的`store`吗？

示例：

2. 一个包可以存放具有不同能力套装的物品吗？

3. 检索时如何保持类型安全？

模式：存储类型元数据

4. 证人模式和幻影类型

动态场的能力要求

袋子里的异构存储

类型安全和类型擦除

见证模式和幻影类型

你知道答案吗？

赚取你的 1000 Sui 份额

帖子

分享您的知识。

能力约束如何与异构集合中的动态字段相互作用？

答案

1. 动态字段中的值总是需要的store吗？

示例：

2. 一个包可以存放具有不同能力套装的物品吗？

3. 检索时如何保持类型安全？

模式：存储类型元数据

4. 证人模式和幻影类型

动态场的能力要求

袋子里的异构存储

类型安全和类型擦除

见证模式和幻影类型

你知道答案吗？

赚取你的 1000 Sui 份额

1. 动态字段中的值总是需要的`store`吗？