Recompensa

Gana tokens por tus contribuciones.

Gana tu parte de 1000 Sui

Gana puntos de reputación y obtén recompensas por ayudar a crecer a la comunidad de Sui.

Publicaciones

Recompensa+15
Xavier.eth301
Jun 17, 2025
P&R expertos
¿Cómo interactúan las restricciones de capacidad con los campos dinámicos en colecciones heterogéneas?
Estoy creando un mercado que necesita gestionar varios tipos de activos con diferentes requisitos de capacidad, y me he planteado algunas preguntas fundamentales sobre el sistema de tipos de Move. Quiero almacenar diferentes tipos de activos en la misma colección, pero tienen diferentes capacidades: NFT normales: key + store(transferibles) Tokens Soulbound: key únicamente (no transferibles) Activos personalizados con restricciones de transferencia 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? */ } Preguntas clave: Requisitos de habilidad: Cuando se usadynamic_field::add(), ¿Vsiempre se necesita store en tiempo de compilación? ¿Pueden los tipos de contenedores solucionar esto? Almacenamiento heterogéneo: ¿puede una sola bolsa almacenar objetos con diferentes conjuntos de habilidades (key + store + copycontrakey + store) y manipularlos de forma diferente durante el tiempo de ejecución? Seguridad de tipos: dado que los campos dinámicos eliminan los tipos, ¿cómo puedo mantener la seguridad de los tipos al recuperar los valores? ¿Cuál es el patrón para almacenar los metadatos de tipo? Patrón de testigos: ¿Cómo funcionan las restricciones de habilidad con los tipos de fantasmas? ¿Puedo AssetAssetguardarlos en la misma colección y extraer la información de tipos más adelante? Construir un sistema en el que los NFT, los tokens de soul bound y los activos restringidos requieran funciones de mercado, pero con una semántica de transferencia diferente. He probado los tipos de contenedores, varias colecciones por conjunto de habilidades y el almacenamiento de metadatos de tipos separados. Cada uno tiene sus ventajas y desventajas entre la seguridad del tipo, los costos de la gasolina y la complejidad.
- Sui
- Architecture
0
0
Recompensa+10
Peera Admin37
May 29, 2025
P&R expertos
¿Por qué BCS requiere un orden de campo exacto para la deserialización cuando las estructuras Move tienen campos con nombre?
¿Por qué BCS requiere un orden exacto de los campos para la deserialización cuando las estructuras de Move tienen campos con nombre? He profundizado en la codificación y decodificación de BCS en Move, especialmente para la comunicación entre cadenas y el procesamiento de datos fuera de la cadena. Mientras estudiaba los ejemplos de la documentación de Sui Move, me encontré con algunos comportamientos que parecen contradictorios y estoy intentando entender las decisiones de diseño subyacentes. Según la especificación de BCS, «no hay estructuras en BCS (ya que no hay tipos); la estructura simplemente define el orden en el que se serializan los campos». Esto significa que, al deserializar, debemos usar peel_*las funciones exactamente en el mismo orden en que se definieron los campos de estructura. Mis preguntas específicas: Justificación del diseño: ¿Por qué BCS exige que los campos coincidan exactamente en el orden de los campos cuando las estructuras de movimiento tienen campos con nombre? ¿No sería más sólido serializar los nombres de los campos junto con los valores, de forma similar a JSON u otros formatos autodescriptivos? Interacción de tipos genéricos: Los documentos mencionan que «los tipos que contienen campos de tipo genérico se pueden analizar hasta el primer campo de tipo genérico». Considera esta estructura: struct ComplexObject has drop, copy { id: ID, owner: address, metadata: Metadata, generic_data: T, more_metadata: String, another_generic: U } ¿Cómo funciona exactamente la deserialización parcial aquí? ¿Puedo deserializar hasta more_metadata e ignorar ambos campos genéricos, o el primer campo genérico (generic_data) bloquea por completo la deserialización posterior? Coherencia entre idiomas: al utilizar la biblioteca JavaScript @mysten /bcs para serializar los datos que consumirán los contratos de Move, qué ocurre si: ¿Reordeno accidentalmente los campos del objeto de JavaScript? ¿La definición de la estructura Move cambia el orden de los campos en una actualización de contrato? ¿Tengo estructuras anidadas con sus propios parámetros genéricos? Implicaciones prácticas: En los sistemas de producción, ¿cómo gestionan los equipos la evolución del esquema BCS? ¿Versionan sus esquemas de BCS o esperan que el orden de los campos de las estructuras sea inmutable una vez implementados?
- Sui
- Move
5
2
Mejor Respuesta
Recompensa+10
Peera Admin36
Mar 05, 2025
P&R expertos
«Errores de verificación de múltiples fuentes» en las publicaciones del módulo Sui Move: resolución automática de errores
Los desarrolladores que trabajan con Sui Move encuentran con frecuencia problemas relacionados con la aparición de varios errores de verificación del código fuente cuando intentan publicar o actualizar los módulos. Estos errores se producen debido a la falta de coincidencia entre las dependencias locales y las de la cadena, lo que provoca errores en las publicaciones y problemas de implementación. A continuación se muestra un ejemplo consolidado de los errores a los que se enfrentan los desarrolladores: 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 Este problema a menudo surge debido a: Las versiones no coinciden entre el entorno de desarrollo local (por ejemplo, la CLI de Sui) y el estado de la cadena. Diferencias en las configuraciones de paquetes entre redes (por ejemplo, Mainnet frente a Testnet). Dependencias faltantes o desactualizadas en el entorno de la cadena. Preguntas clave ¿Cómo podemos automatizar la detección y resolución de estos desajustes de dependencia durante el proceso de publicación? ¿Qué herramientas o scripts se pueden desarrollar para garantizar que las dependencias locales siempre se alineen con sus homólogas de la cadena? ¿Hay alguna forma de agilizar este proceso integrando las comprobaciones de dependencias en las canalizaciones de CI/CD existentes o mejorando el SDK de Sui? Su tarea consiste en proponer una solución que aborde estos desafíos y garantice implementaciones más fluidas y confiables para los desarrolladores de Sui Move. Asegúrese de publicar su solución a continuación.
- Sui
- SDKs and Developer Tools
4
1
Mejor Respuesta