Comparons Sui Move à Aptos Move. Ces deux personnes sont comme des frères et sœurs de la famille linguistique Move, mais elles ont certainement leur propre personnalité :

#Comment fonctionnent-ils ? Les différences d'exécution : performances, évolutivité et expérience du développeur

Sui et Aptos implémentent des machines virtuelles (VM) Move personnalisées, qui leur servent d'environnement d'exécution, influençant les performances, l'évolutivité et l'expérience des développeurs.

Les recherches indiquent que Sui Move est comme cet ami qui se précipite toujours pour faire avancer les choses rapidement.Sa machine virtuelle est conçue pour être rapide : pensez à 0,5 seconde pour verrouiller une transaction, grâce à quelques astuces d'exécution parallèle sophistiquées avec une configuration DAG (par exemple, 0,5 seconde, comme indiqué dans Aptos vs Sui vs Movement : Move Blockchains Comparated)

En revanche, Aptos utilise une architecture linéaire avec des capacités d'exécution parallèle, mais son consensus sur chaque transaction peut créer des goulots d'étranglement à grande échelle, avec une finalité d'environ 0,9 seconde.

L'ordre causal de Sui signifie que de nombreuses transactions ne nécessitent pas de consensus total, ce qui réduit la latence, tandis qu'Aptos utilise AptosBFT, un dérivé de HotStuff, garantissant une finalisation rapide mais une surcharge de calcul potentiellement plus élevée.

Le modèle de Sui inclut un prix du gaz de référence fixé au début de chaque époque, sur la base des entrées du validateur, garantissant la prévisibilité et des frais peu élevés (par exemple, des frais de transaction moyens de 0,0001$, selon Sui contre Aptos : quelle blockchain vous convient ?.

Bibliothèques standard : modules, fonctions et cas d'utilisation

Comme Sui et Aptos ont des conceptions architecturales distinctes (Sui est centré sur les objets, traitant les actifs comme des objets transférables, tandis qu'Aptos est basé sur des comptes, associant des actifs à des comptes), leurs bibliothèques standard diffèrent considérablement en termes de structure et d'utilisation.

Création d'un jeton personnalisé

Dans Aptos, le module managed_coin de la bibliothèque standard aptos_framework fournit un moyen simple de créer et de gérer des jetons fongibles. Voici un exemple :

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);
    }
}

Ce cas d'utilisation crée un jeton fongible lié à un compte, typique des systèmes basés sur des comptes comme Aptos.

Dans Sui, le coinmodule de la bibliothèque standard sui gère les jetons en tant qu'objets. Vous créez une monnaie et utilisez un TreasuryCapobjet pour frapper des pièces. Voici un exemple :

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)
    }
}

Création d'un NFT

Aptos utilise le module de jetons pour gérer les jetons non fongibles (NFT) au sein des collections. Voici comment créer une collection et créer 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
        );
    }
}```


 Gérer des actifs numériques uniques (par exemple, des œuvres d'art) au sein d'une collection structurée, courante dans les systèmes NFT basés sur des comptes.

Dans Sui, les NFT sont autonomes `objects`avec des identifiants uniques, gérés à l'aide des `object``transfer`modules et. Voici un exemple :

```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));
    }
}

Création et transfert d'actifs uniques (par exemple, des objets de collection) en tant qu'objets indépendants, en tirant parti de la flexibilité centrée sur les objets de Sui. Ces différences signifient que les développeurs doivent adapter le code, ce qui a un impact sur le temps de développement et l'interopérabilité de l'écosystème.

Stockage des données : modèles centrés sur les objets et modèles basés sur les comptes

L'une des distinctions les plus importantes concerne le stockage des données. Sui utilise un modèle centré sur l'objet, où chaque actif (par exemple, des jetons, des NFT) est un objet avec des métadonnées, une propriété et des autorisations, stocké en chaîne avec des identifiants uniques (Object Model | Sui Documentation).This le modèle permet des mises à jour d'état parallèles, améliorant ainsi la composabilité et l'efficacité énergétique, car les transactions ne nécessitent souvent qu'une seule mise à jour du registre (par exemple, le transfert d'un objet met à jour son état, pas plusieurs comptes).

Aptos, à l'inverse, utilise un modèle basé sur les comptes, similaire à Ethereum, dans lequel les comptes possèdent des ressources dans le stockage mondial, ce qui nécessite des mises à jour des comptes de l'expéditeur et du destinataire par transaction (Aptos contre Sui - The Tie).

Plus proche d'EVM ou de SVM ?

La question de savoir si Aptos est plus proche d'EVM (machine virtuelle Ethereum) et Sui de SVM (probablement une machine virtuelle Solana) doit être clarifiée. Le modèle basé sur les comptes d'Aptos s'aligne sur l'EVM, mettant à jour l'état des comptes par transaction, le rendant ainsi familier aux développeurs d'Ethereum (Aptos vs Sui : Comparing Two Growing Layer-1 Blockchains).

Le modèle centré sur les objets de Sui est cependant unique et n'est pas directement comparable à SVM, qui est basé sur un compte comme Solana. Certains développeurs affirment que Sui ressemble à Solana en termes d'évolutivité, mais il s'agit davantage de performances que de modèles de données. Il est donc juste de dire qu'Aptos est plus proche de l'EVM, alors que le modèle de Sui est distinct et ne correspond pas à SVM, remettant en question l'analogie.

Packages universels : compatibilité et obstacles

Compte tenu de leurs origines communes, l'interopérabilité idéale impliquerait des packages universels. Cependant, les recherches suggèrent que de tels packages n'existent pas, car les différences entre les bibliothèques standard et les modèles de données créent des obstacles.

Par exemple, un package utilisant aptos_coin d'Aptos ne fonctionnerait pas sur Sui sans une réécriture pour sui : :coin (GitHub - pentagonxyz/movemate : Library of module building blocks for Move). Parmi les obstacles, citons les API spécifiques à la plate-forme, les modèles d'objets par rapport aux comptes et les implémentations divergentes de machines virtuelles, ce qui rend peu probable une compatibilité fluide sans adaptation significative.

Voici une comparaison claire et claire entre Sui Move et Aptos Move, qui montre comment ils partagent un langage de base mais diffèrent en termes de comportement d'exécution, de modèles de données et de modèles de développement.

🏃 Temps d'exécution : rapidité, évolutivité et flux de transactions

Le temps d'exécution de Sui est optimisé pour une exécution parallèle à l'aide d'un modèle DAG. De nombreuses transactions échappent au consensus mondial grâce à l'ordre causal, de sorte que les transferts simples peuvent être finalisés en 0,5 seconde environ. Il est conçu pour les cas d'utilisation à haut débit et à faible latence.

Aptos prend également en charge l'exécution parallèle mais utilise un modèle de consensus AptosBFT plus strict (basé sur HotStuff), de sorte que chaque transaction passe par consensus. Cela donne de meilleures garanties de cohérence, mais peut ralentir légèrement les choses : la finalité se situe autour de 0,9 seconde.

En bref : • Sui est plus rapide pour des opérations simples et indépendantes. • Aptos privilégie davantage la cohérence avec un consensus plus large par province.

🧱 Modèle de données : centré sur l'objet ou centré sur le compte

L'ensemble du modèle de Sui tourne autour des objets. Tout ce qui se trouve sur la chaîne, qu'il s'agisse de jetons, de NFT ou de packages, est un objet doté d'un identifiant unique. La propriété est suivie par objet. Cela signifie que : • Composabilité facile et conception modulaire • Une transaction = un changement d'objet = gaz efficace • Idéal pour les jeux, les NFT et les DeFi composables

Aptos s'en tient à un modèle plus familier basé sur les comptes. Les comptes possèdent des ressources structurées et chaque transaction met à jour les comptes de l'expéditeur/du destinataire. Cela ressemble plus à Ethereum : • Connu pour les développeurs de Solidity • Forte cohérence de l'état • Meilleure adaptation aux flux de jetons traditionnels

Donc : • Sui → Comme gérer des actifs en tant qu'entités autonomes • Aptos → Comme la gestion des soldes liés à l'état du compte

💰 Création de jetons : TreasuryCap contre Managed Coin

Dans Sui, vous définissez un jeton comme un objet (MY_TOKEN) et vous le fabriquez via un TreasuryCap. La fonction coin : :create_currency vous donne un contrôle total sur les métadonnées et la logique d'approvisionnement. Les jetons sont aussi des objets.

Dans Aptos, vous utilisez le module managed_coin. Il lie le jeton à un compte et suit l'approvisionnement via l'accès aux ressources.

Résumé : • Sui → Le jeton est un objet avec un UID, vivant en chaîne • Aptos → Le jeton est une ressource contrôlée par le compte

🎨 NFT : collections et objets autonomes

Les NFT Aptos sont créés dans des collections à l'aide de token : :create_token, lié au stockage du compte.

Les Sui NFT sont des objets autonomes dotés de leur propre identifiant et de leurs propres métadonnées. Vous les fabriquez et les transférez comme n'importe quel objet, en toute flexibilité.

Cela signifie que : • Aptos → Meilleur pour les collections sélectionnées • Sui → Meilleur pour les NFT composables et autorisés (par exemple, les objets de jeu)

🔧 Expérience et interopérabilité pour les développeurs • Sui fixe le prix du gaz une fois par époque → bon marché + prévisible • Le gaz Aptos est dynamique mais plus précis par rapport à la température

Mais l'interopérabilité est difficile. La syntaxe Shared Move n'est pas identique à celle des packages partagés : • aptos_framework : :coin ≠ sui : :coin • La logique basée sur les comptes ne passe pas facilement à la logique objet

C'est pourquoi les packages universels n'existent pas encore. Même avec des racines communes, les différences entre machine virtuelle et environnement d'exécution obligent les développeurs à écrire une logique spécifique à la chaîne.

🔄 Comparaison entre EVM et SVM • Aptos est plus proche d'EVM : modèle de compte, mises à jour d'état similaires • Sui ne ressemble pas vraiment à Solana (SVM est également basé sur un compte). Il est unique, avec une conception axée sur l'objet

Oubliez donc les analogies : Sui est la seule à modéliser les données et leur exécution.

📦 Comment les équipes gèrent la compatibilité

Si vous créez des chaînes croisées : • Vous aurez besoin d'adaptateurs ou de modules séparés par chaîne • Des outils tels que MoveMate ou Pentagon sont utiles, mais l'interopérabilité totale implique toujours d'écrire pour chaque exécution • Certains développeurs commencent par Aptos pour des raisons de simplicité, puis passent à Sui pour la mise à l'échelle et la logique des objets

TL ; DR — Sui contre Aptos Move

Caractéristiques Sui Move Aptos Move Runtime Parallel, basé sur DAG, finalité inférieure à 1, consensus BFT, forte cohérence Modèle de données centré sur les objets et basé sur un compte Création de jetons via un objet TreasuryCap via managed_coin dans le compte NFTs : objets composables autonomes, basés sur des collections, liés à un compte Expérience de développement Nouveau modèle rapide, composable et familier, stable, similaire à Ethereum Prix de référence par TX basé sur l'époque du modèle de gaz Interop Low, nécessite une logique spécifique à la chaîne Idem