Publication
Partagez vos connaissances.
+10
Sui 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
Réponses
1Comparons 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 coin
module de la bibliothèque standard sui gère les jetons en tant qu'objets. Vous créez une monnaie et utilisez un TreasuryCap
objet 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.
Connaissez-vous la réponse ?
Veuillez vous connecter et la partager.
Move is an executable bytecode language used to implement custom transactions and smart contracts.
Gagne ta part de 1000 Sui
Gagne des points de réputation et obtiens des récompenses pour avoir aidé la communauté Sui à se développer.

- ... SUI0xduckmove+860
- ... SUIHaGiang+559
- ... SUIharry phan+514
- ... SUIMoonBags+493
- ... SUIBenjamin XDV+483
- ... SUIMeaning.Sui+418
- ... SUI