Tóm tắt nhanh
Parallel execution cho phép nhiều transaction chạy đồng thời thay vì tuần tự, tăng throughput đáng kể. Aptos dùng Block-STM (optimistic parallel, conflict-detect-and-retry), Sui dùng Object Model (dependency graph tính trước). Cả hai đều có giới hạn quan trọng: DeFi "hot state" (nhiều tx đụng cùng pool) không thể parallel tốt — đây là lý do throughput thực tế thấp hơn nhiều so với benchmark.
EVM xử lý tuần tự — chỉ dùng 1 core. Block-STM (Aptos) và Object model (Sui) cho phép tx độc lập chạy song song, conflict được detect và retry.
1Parallel Execution Là Gì?
Trong blockchain, sequential execution có nghĩa: transaction trong một block phải chạy theo thứ tự — tx1 xong rồi mới chạy tx2, tx2 xong mới chạy tx3. Lý do: không biết trước tx1 và tx2 có đọc/ghi cùng storage slot không. Nếu chạy song song và có conflict, state sẽ bị sai.
Parallel execution giải quyết vấn đề này bằng cách detect hoặc predict conflict, cho phép transaction không-conflict chạy đồng thời trên nhiều CPU core.
2Tại Sao EVM Mặc Định Sequential?
EVM không có thông tin về read/write set của transaction trước khi chạy. Một Solidity function có thể đọc bất kỳ storage slot nào — compiler và runtime không biết trước. Không biết conflict profile → không thể schedule song song an toàn.
Ethereum và các EVM chain lớn đều sequential execution. Điều này giới hạn throughput vì chỉ dùng được 1 CPU core cho execution, dù server có 64 core.
3Block-STM — Aptos Approach
Block-STM (Software Transactional Memory) là thuật toán parallel execution của Aptos, lấy cảm hứng từ STM trong lập trình concurrent:
- Optimistic execution: Tất cả transaction trong block được chạy song song, giả định không có conflict.
- Conflict detection: Sau khi chạy, hệ thống detect transaction nào đọc storage slot đã bị ghi bởi transaction chạy trước nó (theo thứ tự ban đầu).
- Re-execution: Transaction bị conflict được chạy lại với state đã update. Chỉ re-execute transaction cần thiết, không phải toàn bộ block.
Block-STM hoạt động tốt khi conflict rate thấp — phần lớn transaction không đụng chạm nhau. Với workload thực tế (NFT mint, token transfer giữa account khác nhau), conflict rate thường dưới 10%. Nhưng với DeFi (nhiều swap đụng cùng pool), conflict rate cao → re-execute nhiều → lợi ích giảm.
4Sui Object Model — Deterministic Parallelism
Sui không dùng optimistic approach mà thay đổi fundamentally cách data được tổ chức:
- Mọi tài sản trên Sui là Object với owner rõ ràng (owned object) hoặc accessible bởi ai cũng được (shared object).
- Trước khi execute, Sui compute dependency graph: transaction nào dùng object nào.
- Transaction chỉ dùng owned object (NFT của bạn, coin của bạn) → không cần consensus đầy đủ, có thể execute ngay lập tức và song song.
- Transaction dùng shared object (AMM pool) → cần BFT consensus ordering, sequential với nhau.
Lợi ích: Transaction độc lập (không đụng shared object) có thể finalize trong vài trăm millisecond mà không cần chờ global consensus. Kết quả: throughput rất cao cho workload non-DeFi (game, NFT, payment).
5Hot State Problem — Giới Hạn Thực Tế
Hot state là storage được truy cập bởi nhiều transaction trong cùng block. Trong DeFi, đây là vấn đề không thể tránh:
- Mọi swap trên Uniswap pool X đều đọc và ghi
reserve0vàreserve1của pool X. - Mọi lending action trên Aave đều update cùng utilization rate, interest index.
- Mọi perpetual trade đều update cùng funding rate, open interest.
Nói cách khác: parallel execution tốt nhất cho workload độc lập — game items, NFT, p2p payment, social app. Kém hiệu quả hơn cho DeFi shared state — lending, AMM, perpetuals.
6So Sánh Các Approaches
| Approach | Cơ chế | Blockchain | Tốt cho | Kém cho |
|---|---|---|---|---|
| Sequential | Tx chạy 1 lần, theo thứ tự | Ethereum, BSC, L2 hiện tại | Simplicity, correctness | Throughput |
| Block-STM | Optimistic parallel, retry on conflict | Aptos | Low-conflict workload | DeFi hot state |
| Object Model | Dependency graph pre-compute | Sui | Owned-object tx (game, NFT) | Shared object (AMM) |
| Access List | Developer khai báo storage access | EIP-2929 (partial), Monad | Predictable workload | Dynamic access pattern |
Xem phân tích về MoveVM và parallel execution trong bài so sánh EVM vs WASM vs MoveVM và bài phân tích gốc về L2 Scaling & Interoperability.
7Parallel Execution Trên Ethereum Ecosystem
Ethereum và L2 ecosystem không đứng yên — parallel execution đang được implement ở nhiều lớp:
Monad — EVM Parallelism
Monad là chain đang được xây dựng với mục tiêu explicit: parallel EVM execution. Monad dùng optimistic parallel execution tương tự Block-STM nhưng optimize cho EVM bytecode. Thiết kế bao gồm custom database (MonadDB) với async I/O để giảm storage bottleneck — vì parallel execution làm lộ rõ rằng disk I/O thường là bottleneck thực sự, không phải CPU.
Reth Parallel Execution
Reth (Ethereum client mới viết bằng Rust) đang experiment với parallel block execution cho archive nodes. Không phải parallel transaction execution trong consensus, mà parallel execution để sync chain nhanh hơn — có thể reduce full sync time đáng kể.
Sei V2 — EVM + Parallel
Sei V2 kết hợp EVM compatibility với parallel execution engine. Approach: twin execution environment — EVM transactions và Cosmos transactions chạy song song, với optimistic concurrency control giữa các EVM tx không conflict.
8Đo Lường Hiệu Quả Parallel Execution
Benchmark TPS của chain dùng parallel execution cần context để có ý nghĩa:
| Benchmark type | Ý nghĩa | Cách kiểm tra |
|---|---|---|
| Peak TPS (no contention) | Lý thuyết tối đa với tx không conflict | Token transfer đơn giản, không state share |
| DeFi TPS (high contention) | Thực tế với DeFi workload | Uniswap swap, lending, AMM LP |
| Mixed workload TPS | Realistic production scenario | Mix transfer + swap + NFT + DeFi |
| State growth rate | Sustainability dài hạn | State size sau N tx ở peak TPS |
Chain tuyên bố "65,000 TPS" thường là peak TPS với transfer đơn giản — con số DeFi thực tế thấp hơn đáng kể vì conflict. Khi đánh giá chain, hỏi: "TPS này được đo với workload gì?" là câu hỏi quan trọng nhất.