Bài viết
Chia sẻ kiến thức của bạn.
+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
Câu trả lời
2Hãy so sánh về Sui Move và Aptos Move.Hai người này giống như anh chị em trong gia đình ngôn ngữ Move, nhưng họ chắc chắn có tính cách riêng:
#** Chúng cuộn như thế nào? Sự khác biệt về thời gian chạy: Hiệu suất, Khả năng mở rộng và Kinh nghiệm của nhà phát triển**
Cả Sui và Aptos đều triển khai các máy ảo Move tùy chỉnh (VM), đóng vai trò là thời gian chạy của chúng, ảnh hưởng đến hiệu suất, khả năng mở rộng và trải nghiệm của nhà phát triển.
Nghiên cứu chỉ ra rằng Sui Move giống như người bạn luôn vội vã xung quanh, hoàn thành công việc nhanh chóng.** Máy ảo của nó được xây dựng để có tốc độ — hãy nghĩ 0,5 giây để khóa giao dịch**, nhờ một số thủ thuật thực thi song song lạ mắt với thiết lập DAG (ví dụ: 0,5 giây, như đã lưu ý trong Aptos vs Sui vs Movement: Move Blockchains So sánh)
Ngược lại, Aptos sử dụng kiến trúc tuyến tính với khả năng thực thi song song, nhưng sự đồng thuận của nó về mọi giao dịch có thể gây ra tắc nghẽn trên quy mô lớn, với thời gian cuối cùng khoảng 0,9 giây.
Thứ tự nhân quả của Sui có nghĩa là nhiều giao dịch không yêu cầu sự đồng thuận hoàn toàn, giảm độ trễ, trong khi Aptos sử dụng AptosBFT, một dẫn xuất của HotStuff, đảm bảo hoàn thiện nhanh chóng nhưng có khả năng chi phí tính toán cao hơn.
Mô hình của Sui bao gồm giá khí tham chiếu được thiết lập vào đầu mỗi kỷ nguyên, dựa trên đầu vào của trình xác thực, đảm bảo khả năng dự đoán và phí thấp (ví dụ: phí giao dịch trung bình 0,0001 đô la, theo Sui vs. Aptos: Blockchain nào phù hợp với bạn?).
Thư viện tiêu chuẩn: Mô-đun, Chức năng và Trường hợp sử dụng
Bởi vì Sui và Aptos có thiết kế kiến trúc riêng biệt — SUI tập trung vào đối tượng, coi tài sản là đối tượng có thể chuyển nhượng, trong khi Aptos dựa trên tài khoản, liên kết tài sản với tài khoản — thư viện tiêu chuẩn của họ khác nhau đáng kể về cấu trúc và cách sử dụng.
Tạo mã thông báo tùy chỉnh
Trong Aptos, mô-đun managed_coin từ thư viện chuẩn aptos_framework cung cấp một cách đơn giản để tạo và quản lý các mã thông báo có thể thay thế. Đây là một ví dụ:
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);
}
}
Trường hợp sử dụng này tạo ra một mã thông báo có thể thay thế được gắn với một tài khoản, điển hình trong các hệ thống dựa trên tài khoản như Aptos.
Trong Sui, coin
mô-đun từ thư viện tiêu chuẩn sui quản lý mã thông báo dưới dạng đối tượng. Bạn tạo ra một loại tiền tệ và sử dụng một TreasuryCap
đối tượng để đúc tiền xu. Đây là một ví dụ:
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 NFT
Aptos sử dụng mô-đun mã thông báo để quản lý các mã thông báo không thể thay thế (NFT) trong các bộ sưu tập. Dưới đây là cách tạo bộ sưu tập và đúc 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
);
}
}```
Quản lý tài sản kỹ thuật số duy nhất (ví dụ: tác phẩm nghệ thuật) trong một bộ sưu tập có cấu trúc, phổ biến trong các hệ thống NFT dựa trên tài khoản.
Trong Sui, NFT độc lập `objects`với các ID duy nhất, được quản lý bằng các `object``transfer`mô-đun và. Đây là một ví dụ:
```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));
}
}
Tạo và chuyển giao các tài sản độc đáo (ví dụ: đồ sưu tầm) như các đối tượng độc lập, tận dụng tính linh hoạt lấy đối tượng làm trung tâm của Sui. Những khác biệt này có nghĩa là các nhà phát triển phải điều chỉnh mã, tác động đến thời gian phát triển và khả năng tương tác của hệ sinh thái.
Lưu trữ dữ liệu: Mô hình lấy đối tượng so với mô hình dựa trên tài khoản
Một trong những điểm khác biệt quan trọng nhất là trong lưu trữ dữ liệu. Sui sử dụng mô hình lấy đối tượng làm trung tâm, trong đó mỗi tài sản (ví dụ: token, NFT) là một đối tượng có siêu dữ liệu, quyền sở hữu và quyền, được lưu trữ trên chuỗi với các ID duy nhất ([Mô hình đối tượng | Tài liệu Sui](mô hình https://docs.sui.io/concepts/object-model)).This cho phép cập nhật trạng thái song song, tăng cường khả năng cấu thành và hiệu quả khí, vì các giao dịch thường chỉ yêu cầu một cập nhật sổ cái (ví dụ: chuyển một đối tượng cập nhật trạng thái của nó, không phải nhiều tài khoản).
Ngược lại, Aptos sử dụng mô hình dựa trên tài khoản, tương tự như Ethereum, trong đó tài khoản sở hữu tài nguyên trong lưu trữ toàn cầu, yêu cầu cập nhật cho cả tài khoản người gửi và người nhận trên mỗi giao dịch (Aptos vs Sui - The Tie).
Gần hơn với EVM hoặc SVM?
Câu hỏi liệu Aptos có gần hơn với EVM (Máy ảo Ethereum) và Sui với SVM (có khả năng là Máy ảo Solana) hay không cần phải làm rõ. Mô hình dựa trên tài khoản của Aptos phù hợp với EVM, cập nhật trạng thái tài khoản cho mỗi giao dịch, làm cho nó quen thuộc với các nhà phát triển Ethereum (Aptos vs Sui: So sánh hai Blockchains Lớp 1 đang phát triển).
Tuy nhiên, mô hình tập trung vào đối tượng của Sui là duy nhất, không thể so sánh trực tiếp với SVM, dựa trên tài khoản như Solana. Một số nhà phát triển cho rằng Sui giống Solana về khả năng mở rộng, nhưng điều này là về hiệu suất hơn là mô hình dữ liệu. Do đó, công bằng khi nói Aptos gần với EVM hơn, trong khi mô hình của Sui khác biệt, không phù hợp với SVM, thách thức sự tương tự.
Gói phổ quát: Khả năng tương thích và rào cản
Với nguồn gốc chung của chúng, khả năng tương tác lý tưởng sẽ liên quan đến các gói phổ quát. Tuy nhiên, nghiên cứu cho thấy không có gói như vậy tồn tại, vì sự khác biệt trong thư viện tiêu chuẩn và mô hình dữ liệu tạo ra rào cản.
Ví dụ: một gói sử dụng aptos_coin của Aptos sẽ không hoạt động trên Sui nếu không viết lại cho sui: :coin (GitHub - pentagonxyz/movemate: Thư viện khối xây dựng mô-đun cho Move). Các rào cản bao gồm các API dành riêng cho nền tảng, mô hình đối tượng so với tài khoản và triển khai VM khác nhau, khiến khả năng tương thích liền mạch khó xảy ra nếu không có sự thích ứng đáng kể.
Dưới đây là một so sánh rõ ràng, không rõ ràng giữa Sui Move và Aptos Move, cho thấy cách chúng chia sẻ ngôn ngữ cốt lõi nhưng khác nhau về hành vi chạy, mô hình dữ liệu và mô hình phát triển.
🏃 Thời gian chạy: Tốc độ, Khả năng mở rộng và Luồng giao dịch
Thời gian chạy của Sui được tối ưu hóa để thực thi song song bằng cách sử dụng mô hình DAG. Nhiều giao dịch bỏ qua sự đồng thuận toàn cầu nhờ vào thứ tự nhân quả, vì vậy các giao dịch đơn giản có thể hoàn tất trong khoảng 0,5 giây. Nó được xây dựng cho các trường hợp sử dụng thông lượng cao và độ trễ thấp.
Aptos cũng hỗ trợ thực thi song song nhưng sử dụng mô hình đồng thuận AptosBFT nghiêm ngặt hơn (dựa trên HotStuff), vì vậy mọi giao dịch đều thông qua sự đồng thuận. Điều này mang lại sự đảm bảo tính nhất quán mạnh mẽ hơn, nhưng có thể làm chậm mọi thứ một chút - độ cuối cùng đạt khoảng 0,9 giây.
Tóm lại: • Sui nhanh hơn cho các hoạt động đơn giản, độc lập. • Aptos nghiêng về sự nhất quán hơn với sự đồng thuận rộng hơn trên mỗi tx.
🧱 Mô hình dữ liệu: Tập trung vào đối tượng so với Tập trung vào tài khoản
Toàn bộ mô hình của Sui xoay quanh các vật thể. Mọi thứ trên chuỗi - mã thông báo, NFT, thậm chí cả gói - là các đối tượng có ID duy nhất. Quyền sở hữu được theo dõi trên mỗi đối tượng. Điều này có nghĩa là: • Khả năng cấu tạo dễ dàng và thiết kế mô-đun • Một giao dịch = một thay đổi đối tượng = khí hiệu quả • Tuyệt vời cho các trò chơi, NFT và DeFi có thể ghép
Aptos gắn bó với một mô hình dựa trên tài khoản quen thuộc hơn. Tài khoản sở hữu tài nguyên có cấu trúc và mỗi giao dịch cập nhật tài khoản người gửi/người nhận. Nó giống Ethereum hơn: • Quen thuộc với các nhà phát triển Solidity • Tính nhất quán của trạng thái mạnh mẽ • Phù hợp hơn với các luồng mã thông báo truyền thống
Vì vậy: • Sui → Thích quản lý tài sản như các thực thể độc lập • Aptos → Giống như quản lý số dư gắn với trạng thái tài khoản
💰 Tạo mã thông báo: TreasuryCap so với đồng tiền được quản lý
Trong Sui, bạn định nghĩa một token là một đối tượng (MY_TOKEN) và đúc nó thông qua TreasuryCap. Hàm coin: :create_currency cung cấp cho bạn toàn quyền kiểm soát siêu dữ liệu và logic cung cấp. Token cũng là đối tượng.
Trong Aptos, bạn sử dụng mô-đun managed_coin. Nó liên kết mã thông báo với tài khoản và theo dõi nguồn cung thông qua truy cập tài nguyên.
Tóm tắt: • Sui → Token là một đối tượng có UID, sống trên chuỗi • Aptos → Token là một tài nguyên dưới sự kiểm soát tài khoản
🎨 NFT: Bộ sưu tập so với các đối tượng độc lập
Aptos NFT được đúc bên trong bộ sưu tập bằng cách sử dụng token: :create_token, gắn với bộ nhớ tài khoản.
Sui NFT là các đối tượng độc lập với ID và siêu dữ liệu riêng. Bạn đúc và chuyển chúng giống như bất kỳ đối tượng nào, với sự linh hoạt hoàn toàn.
Điều này có nghĩa là: • Aptos → Tốt hơn cho các bộ sưu tập được tuyển chọn • Sui → Tốt hơn cho các NFT có thể soạn thảo, được cấp phép (ví dụ: các vật phẩm trò chơi)
🔧 Kinh nghiệm & Interop dành cho nhà phát triển • Sui đặt giá xăng mỗi kỷ nguyên một lần → rẻ + có thể dự đoán • Khí Aptos năng động nhưng chính xác hơn trên mỗi tx
Nhưng interop rất khó. Cú pháp Shared Move không bằng các gói được chia sẻ: • aptos_framework: :coin ≠ sui: :coin • Logic dựa trên tài khoản không dễ dàng chuyển sang logic đối tượng
Đây là lý do tại sao các gói phổ quát chưa tồn tại. Ngay cả với các nguồn gốc chung, sự khác biệt VM/Runtime buộc các nhà phát triển phải viết logic cụ thể theo chuỗi.
🔄 So sánh EVM so với SVM • Aptos gần hơn với EVM - mô hình tài khoản, cập nhật trạng thái tương tự • Sui không hoàn toàn giống Solana (SVM cũng dựa trên tài khoản). Nó độc đáo, với thiết kế đối tượng đầu tiên
Vì vậy, hãy quên đi sự tương tự - Sui đứng một mình trong cách nó mô hình hóa dữ liệu và thực thi.
📦 Cách các nhóm xử lý khả năng tương thích
Nếu bạn đang xây dựng chuỗi chằng: • Bạn sẽ cần bộ điều hợp hoặc các mô-đun riêng biệt cho mỗi chuỗi • Các công cụ như MoveMate hoặc Pentagon giúp đỡ, nhưng sự can thiệp đầy đủ vẫn có nghĩa là viết cho mỗi thời gian chạy • Một số nhà phát triển bắt đầu trên Aptos để đơn giản, sau đó chuyển sang Sui để mở rộng quy mô và logic đối tượng
TL; DR - Sui vs. Aptos Move
Tính năng Sui Move Aptos Move Thời gian chạy Đồng thuận BFT song song, dựa trên DAG, cuối cùng dưới 1 giây, tính nhất quán mạnh mẽ Mô hình dữ liệu Dựa trên tài khoản lấy đối tượng làm trung tâm Tạo token qua đối tượng TreasuryCap Thông qua managed_coin trong tài khoản NFT Các đối tượng độc lập, có thể ghép lại Dựa trên bộ sưu tập, gắn với tài khoản Trải nghiệm nhà phát triển Nhanh chóng, có thể ghép, mô hình mới Quen thuộc, ổn định, giống như Ethereum Mô hình khí đốt Giá tham chiếu trên mỗi TX dựa trên thời đại Interop Low, cần logic cụ thể theo chuỗi Tương tự
Bạn có biết câu trả lời không?
Hãy đăng nhập và chia sẻ nó.