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.