Пост
Поделитесь своими знаниями.
+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
Ответы
2Давайте сравним Sui Move и Aptos Move. Эти двое похожи на братьев и сестер из языковой семьи Move, но у них определенно есть свои особенности:
#Как они себя чувствуют? Различия во времени выполнения: производительность, масштабируемость и удобство разработчиков
Как в Sui, так и в Aptos реализованы специальные виртуальные машины Move (ВМ), которые служат средой выполнения, влияя на производительность, масштабируемость и удобство работы разработчиков.
Исследования показывают, что Sui Move похож на друга, который всегда спешит и быстро справляется со своими задачами.**Виртуальная машина создана для быстрой обработки транзакций (например, 0,5 секунды, как описано в статье Aptos vs. Sui vs. Movement: Move Blockchains Compared: Move Blockchains Compared)
Напротив, Aptos использует линейную архитектуру с возможностью параллельного выполнения, но консенсус в отношении каждой транзакции может привести к возникновению узких мест при масштабировании, так что окончательная обработка составляет около 0,9 секунды.
Применяемый в Sui принцип причинно-следственной последовательности означает, что по многим транзакциям не требуется полного консенсуса, что позволяет сократить время ожидания, а Aptos использует AptoSBFT, производную HotStuff, которая обеспечивает быструю доработку, но потенциально увеличивает вычислительные издержки.
Модель Sui включает базовую цену на газ, устанавливаемую в начале каждой эпохи на основе данных валидатора, что обеспечивает предсказуемость и низкие комиссии (например, средняя комиссия за транзакцию в размере 0,0001 доллара США), согласно Sui vs. Aptos: какой блокчейн подходит вам?).
Стандартные библиотеки: модули, функции и варианты использования
Поскольку Sui и Aptos имеют разные архитектурные решения (Sui ориентирован на объекты и рассматривает активы как передаваемые объекты, а Aptos основан на учетных записях и связывает активы с учетными записями), их стандартные библиотеки значительно различаются по структуре и использованию.
Создание собственного токена
В Aptos модуль managed_coin из стандартной библиотеки aptos_framework обеспечивает простой способ создания взаимозаменяемых токенов и управления ими. Вот пример:
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);
}
}
Этот вариант использования — создание взаимозаменяемого токена, привязанного к учетной записи, что типично для систем, основанных на учетных записях, таких как Aptos.
В Sui coin
модуль стандартной библиотеки sui управляет токенами как объектами. Вы создаете валюту и используете TreasuryCap
объект для чеканки монет. Вот пример:
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)
}
}
Майнинг и NFT
Aptos использует модуль токенов для управления невзаимозаменяемыми токенами (NFT) в коллекциях. Вот как создать коллекцию и создать 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
);
}
}```
Управление уникальными цифровыми активами (например, произведениями искусства) в структурированной коллекции, что характерно для систем NFT на основе учетных записей.
`objects``object`В Sui NFT работают автономно, имеют `transfer`уникальные идентификаторы и управляются с помощью модулей и. Вот пример:
```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));
}
}
Создание и передача уникальных активов (например, предметов коллекционирования) в виде независимых предметов с использованием объектно-ориентированной гибкости Sui. Эти различия означают, что разработчикам приходится адаптировать код, что влияет на время разработки и совместимость экосистем.
Хранение данных: объектно-ориентированные модели и модели, основанные на учетных записях
Одно из наиболее важных различий заключается в хранении данных. Sui использует объектно-ориентированную модель, в которой каждый актив (например, токены, NFT) представляет собой объект с метаданными, правами собственности и разрешениями, хранящийся в блокчейне с уникальными идентификаторами ([Object Model | Sui Documentation](модель https://docs.sui.io/concepts/object-model)).This позволяет параллельно обновлять состояние, улучшая компоновку и эффективность использования газа, поскольку транзакции часто требуют обновления только одного реестра (например, передача объекта обновляет его состояние, а не несколько учетных записей).
Aptos, наоборот, использует модель, основанную на учетных записях, аналогичную Ethereum, где учетные записи владеют ресурсами в глобальном хранилище, что требует обновления учетных записей отправителей и получателей за каждую транзакцию (Aptos vs. Sui — The Tie).
Ближе к EVM или SVM?
Вопрос о том, ближе ли Aptos к EVM (виртуальной машине Ethereum), а Sui — к SVM (вероятно, виртуальной машине Solana), требует уточнения. Модель Aptos, основанная на учетных записях, соответствует модели EVM, обновляя состояние счетов в каждой транзакции, что делает ее знакомой разработчикам Ethereum (Aptos и Sui: сравнение двух растущих блокчейнов первого уровня).
Однако объектно-ориентированная модель Sui уникальна и не сравнима напрямую с SVM, которая, как и Solana, основана на учетных записях. Некоторые разработчики утверждают, что Sui похожа на Solana по масштабируемости, но дело скорее в производительности, чем в моделях данных. Таким образом, можно с уверенностью сказать, что Aptos ближе к EVM, в то время как модель Sui отличается от модели SVM, что противоречит аналогии.
Универсальные пакеты: совместимость и барьеры
Учитывая их общее происхождение, идеальная совместимость предполагает использование универсальных пакетов. Однако исследования показывают, что таких пакетов не существует, поскольку различия в стандартных библиотеках и моделях данных создают барьеры.
Например, пакет, использующий aptos_coin от Aptos, не будет работать на Sui без переписывания на sui: :coin (GitHub — pentagonxyz/movemate: библиотека строительных блоков модулей для Move). К препятствиям относятся API-интерфейсы, специфичные для конкретных платформ, модели сравнения объектов и учетных записей и разные реализации виртуальных машин, поэтому полная совместимость без существенной адаптации маловероятна.
Вот наглядное сравнение Sui Move и Aptos Move, показывающее, что они используют один и тот же основной язык, но отличаются поведением во время выполнения, моделями данных и шаблонами разработки.
🏃 Время выполнения: скорость, масштабируемость и поток транзакций
Среда выполнения Sui оптимизирована для параллельного выполнения с использованием модели DAG. Из-за случайного упорядочения по многим транзакциям не удается достичь глобального консенсуса, поэтому простые переводы могут быть завершены примерно за 0,5 секунды. Он создан для сценариев использования с высокой пропускной способностью и малой задержкой.
Aptos также поддерживает параллельное выполнение, но использует более строгую модель консенсуса AptoSBFT (основанную на HotStuff), поэтому каждая транзакция проходит через консенсус. Это дает более надежные гарантии согласованности, но может немного замедлить процесс — окончательность составляет около 0,9 секунды.
Вкратце: • Sui быстрее выполняет простые и независимые операции. • В Aptos все больше внимания уделяется согласованности и достижению более широкого консенсуса по каждому налоговому органу.
🧱 Модель данных: объектно-ориентированная или ориентированная на учетную запись
Вся модель Суи вращается вокруг объектов. Все в блокчейне — токены, NFT и даже пакеты — представляют собой объекты с уникальными идентификаторами. Право собственности отслеживается по каждому объекту. Это означает: • Простота компоновки и модульная конструкция • Одна транзакция = одна смена объекта = эффективный газ • Отлично подходит для игр, NFT и компонуемого DeFi
Aptos придерживается более привычной модели, основанной на учетных записях. Учетные записи владеют структурированными ресурсами, и каждая транзакция обновляет учетные записи отправителей/получателей. Это больше похоже на Ethereum: • Знакомо разработчикам Solidity • Высокая согласованность состояния • Лучше подходит для традиционных потоков токенов
Итак: • Sui → Как управлять активами как самостоятельными организациями • Aptos → Например, управление балансами в зависимости от состояния счета
💰 Создание токенов: TreasuryCap или управляемая монета
В Sui вы определяете токен как объект (MY_TOKEN) и чеканите его через TreasuryCap. Функция coin: :create_currency дает вам полный контроль над метаданными и логикой поставок. Токены — это тоже объекты.
В Aptos вы используете модуль managed_coin. Он привязывает токен к учетной записи и отслеживает поставки через доступ к ресурсам.
Резюме: • Sui → Token — это объект с UID, который живет в блокчейне • Aptos → Токен — ресурс, контролируемый учетной записью
🎨 NFT: коллекции и отдельные объекты
NFT Aptos создаются в коллекциях с использованием токена: :create_token, привязанного к хранилищу учетных записей.
Sui NFT — это автономные объекты со своим идентификатором и метаданными. Вы создаете и переносите их, как и любой другой объект, с полной гибкостью.
Это значит: • Aptos → Лучше для тщательно отобранных коллекций • Sui → Лучше подходит для компонуемых и разрешенных NFT (например, игровых предметов)
🔧 Опыт разработчиков и взаимодействие • Sui устанавливает цену на газ один раз в эпоху — дешево и предсказуемо • Газ Aptos динамичен, но более точен в пересчете на таксовую стоимость
Но взаимодействие сложное. Синтаксис Shared Move не соответствует общим пакетам: • aptos_framework: :coin ÷ sui: :coin • Логику, основанную на учетных записях, нелегко перенести в объектную логику
Вот почему универсальных пакетов пока не существует. Даже несмотря на общие корни, различия между виртуальной машиной и средой выполнения вынуждают разработчиков писать логику, специфичную для цепочки.
🔄 Сравнение EVM и SVM • Aptos ближе к EVM — модель учетной записи, аналогичные обновления состояния • Sui не совсем похож на Solana (SVM также основан на учетных записях). Она уникальна, ее дизайн ориентирован на объекты
Так что забудьте об аналогиях — компания Sui уникальна в том, как моделирует данные и выполняет их.
📦 Как команды обеспечивают совместимость
Если вы создаете кроссчейн: • Для каждой цепочки вам понадобятся адаптеры или отдельные модули • Такие инструменты, как MoveMate или Pentagon, помогают, но полное взаимодействие по-прежнему означает написание текста для каждой среды выполнения • Некоторые разработчики для простоты используют Aptos, а затем переходят на Sui для масштабирования и объектной логики
TL; DR — ход «Суди против Аптоса»
Функция: Судьба и фильм «Аптос» Параллельное выполнение, работа на основе DAG, окончательность до 1 секунды, консенсус BFT, высокая согласованность Модель данных, основанная на объектно-ориентированной учетной записи Создание токена с помощью объекта TreasuryCap Через managed_coin в учетной записи NFT: автономные, компонуемые объекты на основе коллекции, привязанные к учетной записи Опыт разработчиков Быстрая, легко компонуемая, новая модель Знакомая, стабильная, похожая на Ethereum Ориентировочная цена газовой модели Epoch в расчете на каждый таксометр Interop Low, нужна логика, специфичная для цепочки, та же
Знаете ответ?
Пожалуйста, войдите в систему и поделитесь им.