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
3+10
P&R expertosParaSuiMay 29, 2025¿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
52Mejor Respuesta+10
P&R expertosParaMoveMar 11, 2025Sui Move vs Aptos Move - What is the difference?
Sui Move and Aptos Move - two prominent implementations of the Move programming language. While both are rooted in the same foundational principles, they have diverged significantly in design, execution, and ecosystem development. To better understand their differences, we need to uncover some of their key aspects: How do their runtimes differ? Both Sui and Aptos implement their own custom Move virtual machines (VMs). How does this impact performance, scalability, and developer experience? For instance: Does Sui's runtime optimize for parallel execution differently than Aptos'? Are there notable differences in transaction lifecycle management or gas models? What are the differences between their standard libraries? The Move standard library is a critical component for building smart contracts. However, Sui and Aptos have forked their implementations, leading to divergence: Are there modules or functions unique to one implementation but absent in the other? How do these differences affect common use cases like token creation, NFTs, or decentralized finance (DeFi)? How does data storage differ between them? One of the most significant distinctions lies in how Sui and Aptos handle data storage: Sui uses an object-centric model, where each object has its own ownership and permissions. Aptos, on the other hand, retains a more traditional account-based model similar to Ethereum. How does this impact state management, composability, and gas efficiency? Is it fair to say that Aptos is closer to EVM while Sui is closer to SVM? Some developers argue that Aptos' account-based architecture resembles Ethereum's EVM, while Sui's object-centric approach aligns more closely with Solana's SVM. Do you agree with this analogy? Why or why not? How does this architectural choice influence developer ergonomics and application design? Are there universal packages working for both Sui Move and Aptos Move? Given their shared origins, it would be ideal if some libraries or tools were interoperable across both ecosystems. Are there any existing universal packages or frameworks that work seamlessly on both platforms? If not, what are the main barriers to achieving compatibility? Can one of them be transpiled into another? If a project is built on Sui Move, could it theoretically be transpiled to run on Aptos Move, or vice versa? What are the technical challenges involved in such a process? Are there tools or compilers currently available to facilitate this kind of migration?
- Move
21Mejor Respuesta+10
P&R expertosParaSuiMar 05, 2025«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
41Mejor Respuesta
- Perdí el USDC al transferir de Slush a Binance, ¿algún consejo de recuperación?00
- What happens to blobs after they hit the end epoch?00
- Transferencia de USDC atascada desde el puente OP al SUI01
- What happens to data after the 'end epoch' in Wal framework?01
- ¿Cómo actualizar la clave de un comerciante en ObjectTable cuando cambia en la estructura?00
- 2565
- 1780
- 426
- 426
- 402
- 397
- 369
- 360
- 338
- 328
- Perdí el USDC al transferir de Slush a Binance, ¿algún consejo de recuperación?00
- What happens to blobs after they hit the end epoch?00
- ¿Cómo actualizar la clave de un comerciante en ObjectTable cuando cambia en la estructura?00
- ¿Cuál es la interfaz más fácil para subir manchas de morsa?10
- Configuración de NAS o BAS00