Puntos clave
- Los objetos tienen identidad, versión y reglas de propiedad que condicionan su uso.
- Los contratos se publican como paquetes Move que operan sobre esos objetos.
- El diseño debe distinguir activos de un usuario y estado compartido entre muchos participantes.
¿Qué es Sui?
Sui representa los datos y activos on-chain como objetos con una identidad propia. Los contratos establecen cómo se crean, transfieren y modifican. El punto de partida del diseño es el objeto y sus permisos, en lugar de trasladar literalmente el almacenamiento de un contrato EVM.
Este enfoque resulta útil cuando el producto necesita seguir el ciclo de vida de unidades identificables, como entradas, credenciales o elementos de un catálogo digital. La especificación debe aclarar qué acciones conserva el emisor y cuáles corresponden a la persona que controla cada objeto.
Cómo funciona
Cada objeto tiene un identificador y una versión que permite referenciar un estado concreto. La propiedad determina quién puede usarlo en una operación: existen objetos controlados por una dirección, objetos compartidos y objetos inmutables, entre otros casos.
Los paquetes Move contienen los módulos que aplican las reglas sobre esos datos. Las transacciones declaran los objetos que utilizan, por lo que el diseño del estado influye en las dependencias entre operaciones. Un servicio que centraliza todas las escrituras en un mismo objeto compartido necesita pruebas distintas de un flujo con activos independientes. Los módulos definen qué funciones pueden modificar cada objeto y el cliente conserva sus referencias para construir transacciones.
Qué aporta Sui
Sui puede encajar en productos donde la identidad y las reglas de transferencia de un activo son centrales. Permite evaluar inventarios digitales, derechos de acceso y mercados donde cada unidad tiene un ciclo de vida propio.
En Metlabs, la evaluación empieza por dibujar ese ciclo: creación, autorización, transferencia, actualización y retirada. Después se comprueba cómo lo presentan la wallet y el backend. Este trabajo permite identificar qué reglas deben vivir en Move y qué funciones conviene mantener fuera de la red para evitar publicar información innecesaria.
Para una entrada digital, el objeto puede representar su identificador y su estado de uso. El flujo incluye emisión, transferencia permitida y validación de acceso. Las pruebas comprueban que no pueda consumirse dos veces y que la actualización del paquete mantenga las reglas previstas. Si varias operaciones dependen de un registro compartido, conviene medir esa contención antes de atribuir a la aplicación el paralelismo general de la red.
Limitaciones y criterios de elección
Move ofrece un modelo para controlar recursos, pero no sustituye las pruebas de permisos ni verifica por sí solo la lógica comercial. También hay que diseñar las actualizaciones de paquetes y la evolución de los datos sin romper las aplicaciones que los consumen.
Aptos utiliza otra variante y otro entorno de Move; compartir el nombre del lenguaje no hace intercambiables los contratos. Si el proyecto depende de bibliotecas Solidity o integraciones EVM, migrar a Sui amplía el alcance. La ventaja del modelo de objetos debe justificar esa adaptación.





