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.