Comparemos entre Sui Move y Aptos Move. Estos dos son como hermanos de la familia lingüística Move, pero definitivamente tienen sus propias personalidades:

#** ¿Cómo funcionan? Las diferencias en el tiempo de ejecución: rendimiento, escalabilidad y experiencia del desarrollador**

Tanto Sui como Aptos implementan máquinas virtuales (VM) Move personalizadas, que funcionan como tiempos de ejecución, lo que influye en el rendimiento, la escalabilidad y la experiencia de los desarrolladores.

Las investigaciones indican que Sui Move es como ese amigo que siempre está corriendo para hacer las cosas rápido.Su máquina virtual está diseñada para ser rápida (piense en 0,5 segundos para bloquear una transacción), gracias a algunos trucos sofisticados de ejecución en paralelo con una configuración DAG (por ejemplo, 0,5 segundos, como se indica en Aptos contra Sui contra Movement: Move Blockchains Compareed)

Por el contrario, Aptos emplea una arquitectura lineal con capacidades de ejecución en paralelo, pero su consenso sobre cada transacción puede generar cuellos de botella a gran escala, cuya finalización ronda los 0,9 segundos.

El orden causal de Sui significa que muchas transacciones no requieren un consenso total, lo que reduce la latencia, mientras que Aptos usa AptosBFT, un derivado de HotStuff, lo que garantiza una finalización rápida, pero una sobrecarga computacional potencialmente mayor.

El modelo de Sui incluye un precio de referencia del gas establecido al principio de cada época, basado en las entradas del validador, lo que garantiza la previsibilidad y comisiones bajas (por ejemplo, una comisión de transacción promedio de 0,0001 USD, según Sui frente a Aptos: ¿qué cadena de bloques es la adecuada para usted?.

Bibliotecas estándar: módulos, funciones y casos de uso

Debido a que Sui y Aptos tienen diseños arquitectónicos distintos (SUI se centra en los objetos y trata los activos como objetos transferibles, mientras que Aptos se basa en cuentas y asocia los activos con las cuentas), sus bibliotecas estándar difieren significativamente en estructura y uso.

Creación de un token personalizado

En Aptos, el módulo managed_coin de la biblioteca estándar aptos_framework proporciona una forma sencilla de crear y administrar tokens fungibles. He aquí un ejemplo:

module example::MyToken {
    use aptos_framework::managed_coin;
    use std::signer;

    /// Struct representing the custom token
    struct MyToken has key { }

    /// Initialize the token with name, symbol, decimals, and monitoring option
    public entry fun initialize(account: &signer) {
        managed_coin::initialize<MyToken>(
            account,
            b"MyToken",           // Name
            b"MTK",              // Symbol
            6,                   // Decimals
            true,                // Enable monitoring
        );
    }

    /// Mint tokens to the caller's account
    public entry fun mint(account: &signer, amount: u64) {
        managed_coin::mint<MyToken>(account, amount);
    }
}

Este caso de uso crea un token fungible vinculado a una cuenta, típico en los sistemas basados en cuentas como Aptos.

En Sui, el coinmódulo de la biblioteca estándar sui administra los tokens como objetos. Creas una moneda y usas un TreasuryCapobjeto para acuñar monedas. He aquí un ejemplo:

module example::MyToken {
    use sui::coin::{Self, Coin, TreasuryCap};
    use sui::transfer;
    use sui::tx_context::{Self, TxContext};

    /// Struct defining the custom token type (with `drop` for currency creation)
    struct MY_TOKEN has drop { }

    /// Create a new currency and transfer its TreasuryCap and metadata
    public entry fun create_currency(ctx: &mut TxContext) {
        let (treasury_cap, metadata) = coin::create_currency(
            MY_TOKEN {},         // Token type witness
            6,                   // Decimals
            b"MTK",              // Symbol
            b"MyToken",          // Name
            b"A custom token",   // Description
            option::none(),      // Optional icon URL
            ctx,
        );
        transfer::public_transfer(treasury_cap, tx_context::sender(ctx));
        transfer::public_transfer(metadata, tx_context::sender(ctx));
    }

    /// Mint new coins using the TreasuryCap
    public fun mint(
        treasury_cap: &mut TreasuryCap<MY_TOKEN>,
        amount: u64,
        ctx: &mut TxContext
    ): Coin<MY_TOKEN> {
        coin::mint(treasury_cap, amount, ctx)
    }
}

Cómo acuñar un NFT

Aptos usa el módulo de tokens para administrar los tokens no fungibles (NFT) dentro de las colecciones. A continuación te explicamos cómo crear una colección y crear un NFT:

module example::MyNFT {
    use aptos_framework::token;
    use std::string;
    use std::signer;

    /// Create a new NFT collection
    public entry fun create_collection(creator: &signer) {
        token::create_collection(
            creator,
            string::utf8(b"MyCollection"),       // Collection name
            string::utf8(b"A collection of NFTs"), // Description
            string::utf8(b"https://example.com"), // URI
            true, true, true, true, true, true, true, true, true, // Mutability flags
        );
    }

    /// Mint an NFT within the collection
    public entry fun mint_nft(
        creator: &signer,
        collection: &string::String,
        name: &string::String,
        uri: &string::String
    ) {
        token::create_token(
            creator,
            *collection,
            *name,
            string::utf8(b"Description"), // Token description
            1,                            // Maximum supply (1 for NFT)
            *uri,                         // Token URI
            0, 0, 0,                      // Royalty settings
            vector::empty(),              // Property keys
            vector::empty(),              // Property values
            vector::empty(),              // Property types
        );
    }
}```


 Administrar activos digitales únicos (por ejemplo, obras de arte) dentro de una colección estructurada, común en los sistemas NFT basados en cuentas.

`objects``object`En Sui, los NFT son independientes `transfer`con identificadores únicos, que se administran mediante los módulos y. He aquí un ejemplo:

```rust
module example::MyNFT {
    use sui::object::{Self, UID};
    use sui::transfer;
    use sui::tx_context::{Self, TxContext};
    use std::string;

    /// Struct representing an NFT
    struct MyNFT has key {
        id: UID,
        name: string::String,
        uri: string::String,
    }

    /// Mint an NFT and transfer it to the sender
    public entry fun mint(
        ctx: &mut TxContext,
        name: string::String,
        uri: string::String
    ) {
        let nft = MyNFT {
            id: object::new(ctx),  // Generate a unique ID
            name,
            uri,
        };
        transfer::transfer(nft, tx_context::sender(ctx));
    }
}

Crear y transferir activos únicos (por ejemplo, objetos de colección) como objetos independientes, aprovechando la flexibilidad centrada en los objetos de Sui. Estas diferencias significan que los desarrolladores deben adaptar el código, lo que repercute en el tiempo de desarrollo y en la interoperabilidad de los ecosistemas.

Almacenamiento de datos: modelos centrados en objetos frente a modelos basados en cuentas

Una de las distinciones más importantes es el almacenamiento de datos. Sui emplea un modelo centrado en objetos, en el que cada activo (por ejemplo, tokens o NFT) es un objeto con metadatos, propiedad y permisos, que se almacena en cadena con identificadores únicos ([Modelo de objetos | Documentación de Sui](el modelo https://docs.sui.io/concepts/object-model)).This permite actualizaciones de estado paralelas, lo que mejora la componibilidad y la eficiencia del gas, ya que las transacciones suelen requerir solo una actualización del libro mayor (por ejemplo, la transferencia de un objeto actualiza su estado, no varias cuentas).

Aptos, por el contrario, utiliza un modelo basado en cuentas, similar al de Ethereum, en el que las cuentas poseen recursos en el almacenamiento global, por lo que es necesario actualizar las cuentas del remitente y del destinatario por transacción (Aptos vs. Sui - The Tie).

¿Más cerca de EVM o SVM?

La cuestión de si Aptos está más cerca de EVM (Ethereum Virtual Machine) y Sui de SVM (probablemente Solana Virtual Machine) requiere una aclaración. El modelo basado en cuentas de Aptos se alinea con el de EVM, ya que actualiza los estados de las cuentas por transacción, lo que hace que los desarrolladores de Ethereum lo conozcan (Aptos contra Sui: Comparación de dos cadenas de bloques de capa 1 en crecimiento).

Sin embargo, el modelo centrado en objetos de Sui es único y no se puede comparar directamente con el de SVM, que se basa en cuentas como Solana. Algunos desarrolladores sostienen que Sui se parece a Solana en cuanto a escalabilidad, pero esto tiene más que ver con el rendimiento que con los modelos de datos. Por lo tanto, es justo decir que Aptos está más cerca de la EVM, mientras que el modelo de Sui es distinto, ya que no se alinea con la SVM, lo que desafía la analogía.

Paquetes universales: compatibilidad y barreras

Dados sus orígenes compartidos, la interoperabilidad ideal implicaría paquetes universales. Sin embargo, las investigaciones sugieren que no existen tales paquetes, ya que las diferencias en las bibliotecas estándar y los modelos de datos crean barreras.

Por ejemplo, un paquete que utilice aptos_coin de Aptos no funcionaría en Sui sin reescribirlo para sui: :coin (GitHub - pentagonxyz/movemate: Library of module building blocks for Move). Las barreras incluyen las API específicas de cada plataforma, los modelos de objetos frente a cuentas y las implementaciones de máquinas virtuales divergentes, lo que hace improbable una compatibilidad perfecta sin una adaptación significativa.

Esta es una comparación clara y sencilla entre Sui Move y Aptos Move, que muestra cómo comparten un lenguaje central pero difieren en el comportamiento del tiempo de ejecución, los modelos de datos y los patrones de desarrollo.

🏃 Tiempo de ejecución: velocidad, escalabilidad y flujo de transacciones

El tiempo de ejecución de Sui está optimizado para la ejecución en paralelo mediante un modelo DAG. Muchas transacciones eluden el consenso global gracias al orden causal, por lo que las transferencias simples pueden finalizar en alrededor de 0,5 segundos. Está diseñado para casos de uso de alto rendimiento y baja latencia.

Aptos también admite la ejecución en paralelo, pero utiliza un modelo de consenso de AptosBFT más estricto (basado en HotStuff), por lo que cada transacción pasa por consenso. Esto ofrece mayores garantías de coherencia, pero puede ralentizar un poco las cosas: la finalización dura alrededor de 0,9 segundos.

En resumen: • Sui es más rápido para operaciones sencillas e independientes. • Aptos se inclina más por la coherencia, con un consenso más amplio por impuesto.

🧱 Modelo de datos: centrado en objetos versus centrado en cuentas

Todo el modelo de Sui gira en torno a los objetos. Todo lo que aparece en la cadena (tokens, NFT e incluso paquetes) son objetos con identificadores únicos. Se hace un seguimiento de la propiedad por objeto. Esto significa: • Fácil componibilidad y diseño modular • Una transacción = un cambio de objeto = gas eficiente • Ideal para juegos, NFT y DeFi componibles

Aptos se apega a un modelo basado en cuentas más conocido. Las cuentas poseen recursos estructurados y cada transacción actualiza las cuentas de remitente/receptor. Se parece más a Ethereum: • Familiar para los desarrolladores de Solidity • Fuerte uniformidad de estados • Se adapta mejor a los flujos de tokens tradicionales

Así que: • Sui → Como administrar activos como entidades independientes • Aptos → Como administrar los saldos vinculados al estado de la cuenta

💰 Creación de tokens: TreasuryCap frente a Managed Coin

En Sui, definimos un token como un objeto (MY_TOKEN) y lo acuñamos con un TreasuryCap. La función coin: :create_currency te da un control total sobre los metadatos y la lógica de suministro. Los tokens también son objetos.

En Aptos, se usa el módulo managed_coin. Vincula el token a una cuenta y rastrea el suministro mediante el acceso a los recursos.

Resumen: • Sui → El token es un objeto con UID, vive en cadena • Aptos → El token es un recurso bajo el control de una cuenta

🎨 NFT: colecciones frente a objetos independientes

Los NFT de Aptos se acuñan en colecciones utilizando el token: :create_token, vinculado al almacenamiento de la cuenta.

Los NFT de Sui son objetos independientes con su propio identificador y metadatos. Puedes acuñarlos y transferirlos como cualquier objeto, con total flexibilidad.

Esto significa: • Aptos → Mejor para colecciones seleccionadas • Sui → Mejor para los NFT con permisos y que admiten composición (p. ej., objetos de juegos)

🔧 Experiencia de desarrollador e interoperabilidad • Sui fija el precio de la gasolina una vez por época → barato y predecible • El gas de Aptos es dinámico pero más preciso por trayecto

Pero la interoperabilidad es difícil. La sintaxis de Shared Move no es igual a la de los paquetes compartidos: • aptos_framework: :coin => sui: :coin • La lógica basada en cuentas no se adapta fácilmente a la lógica de objetos

Esta es la razón por la que los paquetes universales aún no existen. Incluso con raíces comunes, las diferencias entre máquinas virtuales y tiempo de ejecución obligan a los desarrolladores a escribir una lógica específica para cada cadena.

🔄 Comparación entre EVM y SVM • Aptos está más cerca de EVM: modelo de cuenta, actualizaciones de estado similares • Sui no se parece mucho a Solana (SVM también se basa en cuentas). Es único, con un diseño que prioriza el objeto

Así que olvídate de las analogías: Sui es única en la forma en que modela los datos y la ejecución.

📦 Cómo gestionan los equipos la compatibilidad

Si estás creando cadenas cruzadas: • Necesitarás adaptadores o módulos independientes por cadena • Herramientas como MoveMate o Pentagon ayudan, pero la interoperabilidad total también implica escribir para cada tiempo de ejecución • Algunos desarrolladores comienzan con Aptos para simplificar y luego pasan a Sui para escalar y aplicar la lógica de objetos

TL; DR — Sui contra Aptos Move

Características: Sui Move; Aptos Move Runtime Parallel, basado en DAG, final de sub-1, consenso BFT, sólida consistencia Modelo de datos: centrado en objetos, basado en cuentas Creación de tokens a través del objeto TreasuryCap A través de managed_coin en la cuenta NFT: objetos independientes que admiten composición, basados en colecciones, vinculados a una cuenta Experiencia de desarrollo Rápido, componible, nuevo modelo Familiar, estable, similar a Ethereum Precio de referencia por TX del modelo de gasolina basado en Epoch Interop Low, necesita una lógica específica para la cadena Lo mismo