Tương lai của mở rộng quy mô: Bản đồ toàn cảnh lĩnh vực tính toán song song Web3
Tuyển chọn TechFlowTuyển chọn TechFlow
Tương lai của mở rộng quy mô: Bản đồ toàn cảnh lĩnh vực tính toán song song Web3
Giải thích chuyên sâu về tính toán song song Web3.
Chuyên sâu báo cáo Web3Tác giả: 0xjacobzhao và ChatGPT 4o
“Tam giác bất khả thi” (Blockchain Trilemma) của blockchain – “bảo mật”, “phi tập trung”, “khả năng mở rộng” – cho thấy sự đánh đổi cốt lõi trong thiết kế hệ thống blockchain, tức là các dự án blockchain rất khó đồng thời đạt được “an toàn tối đa, ai cũng có thể tham gia, xử lý tốc độ cao”. Đối với chủ đề muôn thuở “khả năng mở rộng”, hiện nay các giải pháp mở rộng blockchain phổ biến trên thị trường theo mô hình phân loại bao gồm:
-
Mở rộng tăng cường thực thi: Nâng cao khả năng thực thi tại chỗ, ví dụ như song song, GPU, đa nhân
-
Mở rộng cách ly trạng thái: Phân tách ngang trạng thái/Shard, ví dụ như phân mảnh, UTXO, mạng con đa lớp
-
Mở rộng thuê ngoài ngoài chuỗi: Chuyển việc thực thi ra ngoài chuỗi, ví dụ như Rollup, Coprocessor, DA
-
Mở rộng tách biệt cấu trúc: Mô-đun hóa kiến trúc, phối hợp vận hành, ví dụ như chuỗi mô-đun, bộ sắp xếp chia sẻ, Rollup Mesh
-
Mở rộng đồng thời bất đồng bộ: Mô hình Actor, cách ly tiến trình, điều khiển bởi tin nhắn, ví dụ như tác nhân thông minh, chuỗi đa luồng bất đồng bộ
Các giải pháp mở rộng blockchain bao gồm: tính toán song song trong chuỗi, Rollup, phân mảnh, mô-đun DA, cấu trúc mô-đun, hệ thống Actor, nén bằng chứng zk, kiến trúc Stateless,... trải dài nhiều cấp độ như thực thi, trạng thái, dữ liệu, cấu trúc, tạo thành một hệ thống mở rộng hoàn chỉnh dạng "hợp tác đa tầng, kết hợp mô-đun". Bài viết này sẽ tập trung giới thiệu phương thức mở rộng chủ yếu dựa trên tính toán song song.
Tính toán song song nội chuỗi (intra-chain parallelism), chú trọng đến việc thực thi song song giao dịch/lệnh bên trong khối. Theo cơ chế song song, cách mở rộng này có thể chia thành năm nhóm lớn, mỗi nhóm đại diện cho mục tiêu hiệu suất khác nhau, mô hình phát triển và triết lý kiến trúc khác nhau, lần lượt có mức độ chi tiết song song ngày càng nhỏ, cường độ song song ngày càng cao, độ phức tạp lập lịch ngày càng cao, độ phức tạp lập trình và khó khăn triển khai cũng ngày càng cao.
-
Song song cấp tài khoản (Account-level): Đại diện là Solana
-
Song song cấp đối tượng (Object-level): Đại diện là Sui
-
Song song cấp giao dịch (Transaction-level): Đại diện là Monad, Aptos
-
Song song cấp gọi lệnh / vi VM (Call-level / MicroVM): Đại diện là MegaETH
-
Song song cấp chỉ thị (Instruction-level): Đại diện là GatlingX
Mô hình đồng thời bất đồng bộ ngoài chuỗi, lấy hệ thống tác nhân (Agent/Actor Model) làm đại diện, thuộc một dạng mô hình tính toán song song khác, là hệ thống truyền tin nhắn liên chuỗi/bất đồng bộ (không phải mô hình đồng bộ khối), mỗi Agent hoạt động như một “tiến trình tác nhân độc lập”, thực hiện song song qua tin nhắn bất đồng bộ, điều khiển bởi sự kiện, không cần lập lịch đồng bộ. Các dự án tiêu biểu gồm AO, ICP, Cartesi, v.v.
Còn những giải pháp mở rộng quen thuộc như Rollup hay phân mảnh thuộc về cơ chế đồng thời cấp hệ thống, không thuộc về tính toán song song nội chuỗi. Chúng mở rộng bằng cách “chạy song song nhiều chuỗi/vùng thực thi”, chứ không nâng cao mức độ song song bên trong từng khối/máy ảo đơn lẻ. Các giải pháp mở rộng loại này không phải trọng tâm bài viết, nhưng vẫn sẽ được dùng để so sánh về điểm tương đồng và khác biệt trong triết lý kiến trúc.
Hai, Chuỗi tăng cường song song EVM: Đột phá giới hạn hiệu suất trong sự tương thích
Kiến trúc xử lý tuần tự của Ethereum đến nay đã trải qua nhiều nỗ lực mở rộng như phân mảnh, Rollup, kiến trúc mô-đun, tuy nhiên điểm nghẽn thông lượng ở tầng thực thi vẫn chưa được đột phá căn bản. Tuy vậy, EVM và Solidity vẫn là nền tảng hợp đồng thông minh có cộng đồng nhà phát triển mạnh nhất và tiềm năng sinh thái lớn nhất hiện nay. Do đó, các chuỗi tăng cường song song EVM trở thành hướng đi quan trọng trong đợt phát triển mới về mở rộng, vừa đảm bảo tương thích sinh thái vừa nâng cao hiệu suất thực thi. Monad và MegaETH là hai dự án tiêu biểu nhất trong hướng đi này, lần lượt xuất phát từ trì hoãn thực thi và phân rã trạng thái để xây dựng kiến trúc xử lý song song EVM hướng tới các kịch bản đòi hỏi đồng thời cao và thông lượng cao.
Phân tích cơ chế tính toán song song của Monad
Monad là một blockchain Layer1 hiệu suất cao được thiết kế lại dành riêng cho Máy ảo Ethereum (EVM), dựa trên nguyên tắc cơ bản của xử lý theo luồng (Pipelining), thực hiện thực thi bất đồng bộ (Asynchronous Execution) ở tầng đồng thuận và thực thi song song lạc quan (Optimistic Parallel Execution) ở tầng thực thi. Ngoài ra, ở tầng đồng thuận và lưu trữ, Monad lần lượt giới thiệu giao thức BFT hiệu suất cao (MonadBFT) và hệ thống cơ sở dữ liệu chuyên dụng (MonadDB), nhằm tối ưu hóa toàn bộ quá trình.
Pipelining: Cơ chế thực thi song song theo luồng đa giai đoạn
Pipelining là tư tưởng cơ bản về thực thi song song của Monad, cốt lõi là chia quy trình thực thi blockchain thành nhiều giai đoạn độc lập, rồi xử lý song song các giai đoạn này, tạo thành kiến trúc theo luồng ba chiều, mỗi giai đoạn chạy trên một luồng hoặc nhân riêng biệt, đạt được xử lý đồng thời xuyên khối, cuối cùng nâng cao thông lượng và giảm độ trễ. Các giai đoạn này bao gồm: đề xuất giao dịch (Propose), đạt đồng thuận (Consensus), thực thi giao dịch (Execution) và xác nhận khối (Commit).
Asynchronous Execution: Tách rời bất đồng bộ giữa đồng thuận - thực thi
Trên các chuỗi truyền thống, việc đạt đồng thuận và thực thi giao dịch thường là quy trình đồng bộ, mô hình tuần tự này nghiêm trọng hạn chế khả năng mở rộng. Monad thực hiện “thực thi bất đồng bộ” để đạt được sự bất đồng bộ ở tầng đồng thuận, tầng thực thi và tầng lưu trữ. Điều này giảm đáng kể thời gian khối (block time) và độ trễ xác nhận, giúp hệ thống linh hoạt hơn, quy trình xử lý chi tiết hơn, hiệu suất sử dụng tài nguyên cao hơn.
Thiết kế chính:
-
Quá trình đồng thuận (tầng đồng thuận) chỉ chịu trách nhiệm sắp xếp giao dịch, không thực thi logic hợp đồng.
-
Quá trình thực thi (tầng thực thi) được kích hoạt bất đồng bộ sau khi đạt đồng thuận.
-
Sau khi đạt đồng thuận, ngay lập tức chuyển sang quy trình đồng thuận khối tiếp theo, không cần chờ thực thi xong.
Optimistic Parallel Execution: Thực thi song song lạc quan
Ethereum truyền thống áp dụng mô hình tuần tự nghiêm ngặt cho việc thực thi giao dịch để tránh xung đột trạng thái. Trong khi đó, Monad áp dụng chiến lược “thực thi song song lạc quan”, nâng cao đáng kể tốc độ xử lý giao dịch.
Cơ chế thực thi:
-
Monad sẽ thực thi tất cả giao dịch một cách lạc quan và song song, giả định rằng phần lớn các giao dịch không có xung đột trạng thái.
-
Đồng thời chạy một “bộ phát hiện xung đột (Conflict Detector)” để theo dõi xem các giao dịch có đang truy cập vào cùng một trạng thái nào hay không (ví dụ như xung đột đọc/ghi).
-
Nếu phát hiện xung đột, các giao dịch xung đột sẽ được thực thi lại theo thứ tự tuần tự để đảm bảo tính đúng đắn của trạng thái.
Monad chọn con đường tương thích: thay đổi ít nhất có thể các quy tắc EVM, đạt được song song bằng cách trì hoãn việc ghi trạng thái và kiểm tra xung đột động trong quá trình thực thi, giống như một phiên bản hiệu suất cao của Ethereum, dễ dàng triển khai di chuyển sinh thái EVM, là bộ tăng tốc song song cho thế giới EVM.
Phân tích cơ chế tính toán song song của MegaETH
Khác với định vị L1 của Monad, MegaETH định vị là một tầng thực thi song song hiệu suất cao, tương thích EVM, có thể vừa là một chuỗi công cộng L1 độc lập, vừa là một tầng tăng cường thực thi (Execution Layer) hoặc thành phần mô-đun trên Ethereum. Mục tiêu thiết kế cốt lõi là tách biệt và cấu trúc lại logic tài khoản, môi trường thực thi và trạng thái thành các đơn vị nhỏ nhất có thể lập lịch độc lập, nhằm đạt được khả năng thực thi đồng thời cao và phản hồi độ trễ thấp trong chuỗi. Sáng tạo chính của MegaETH nằm ở: Kiến trúc Micro-VM + DAG phụ thuộc trạng thái (State Dependency DAG) và cơ chế đồng bộ mô-đun, cùng nhau xây dựng nên hệ thống thực thi song song hướng tới “đa luồng trong chuỗi”.
Kiến trúc Micro-VM (vi máy ảo): Mỗi tài khoản là một luồng
MegaETH giới thiệu mô hình thực thi “mỗi tài khoản một máy ảo nhỏ (Micro-VM)”, “đa luồng hóa” môi trường thực thi, cung cấp đơn vị cách ly nhỏ nhất cho việc lập lịch song song. Những VM này giao tiếp với nhau thông qua tin nhắn bất đồng bộ (Asynchronous Messaging), thay vì gọi đồng bộ, hàng loạt VM có thể thực thi độc lập, lưu trữ độc lập, tự nhiên song song.
DAG phụ thuộc trạng thái: Cơ chế lập lịch dựa trên đồ thị phụ thuộc
MegaETH xây dựng một hệ thống lập lịch DAG dựa trên mối quan hệ truy cập trạng thái tài khoản, hệ thống duy trì một đồ thị phụ thuộc toàn cục (Dependency Graph) theo thời gian thực, mỗi lần giao dịch sửa đổi tài khoản nào, đọc tài khoản nào, đều được mô hình hóa thành mối quan hệ phụ thuộc. Giao dịch không xung đột có thể thực thi song song trực tiếp, giao dịch có phụ thuộc sẽ được lập lịch theo thứ tự topo hoặc trì hoãn. Đồ thị phụ thuộc đảm bảo tính nhất quán trạng thái và không ghi trùng trong quá trình thực thi song song.
Thực thi bất đồng bộ và cơ chế callback
MegaETH được xây dựng trên mô hình lập trình bất đồng bộ, tương tự truyền tin nhắn Actor Model, giải quyết vấn đề gọi tuần tự của EVM truyền thống. Việc gọi hợp đồng là bất đồng bộ (không đệ quy), khi gọi hợp đồng A -> B -> C, mỗi lần gọi đều bị bất đồng bộ hóa, không cần chặn chờ; ngăn xếp gọi bị mở rộng thành đồ thị gọi bất đồng bộ (Call Graph); xử lý giao dịch = duyệt đồ thị bất đồng bộ + phân biệt phụ thuộc + lập lịch song song.
Tóm lại, MegaETH phá vỡ mô hình máy trạng thái đơn luồng truyền thống của EVM, đóng gói tài khoản và hợp đồng thành các vi máy ảo riêng biệt, dùng đồ thị phụ thuộc trạng thái để lập lịch giao dịch, và thay thế ngăn xếp gọi đồng bộ bằng cơ chế tin nhắn bất đồng bộ. Đây là một nền tảng tính toán song song được thiết kế lại toàn diện từ “cấu trúc tài khoản → kiến trúc lập lịch → quy trình thực thi”, mang lại ý tưởng kiểu mẫu mới cho việc xây dựng hệ thống chuỗi hiệu suất cao thế hệ tiếp theo.
MegaETH chọn con đường tái cấu trúc: hoàn toàn trừu tượng hóa tài khoản và hợp đồng thành các VM độc lập, giải phóng tiềm năng song song cực đại thông qua lập lịch thực thi bất đồng bộ. Về mặt lý thuyết, giới hạn song song của MegaETH cao hơn, nhưng cũng khó kiểm soát độ phức tạp hơn, giống như một hệ điều hành siêu phân tán dưới triết lý Ethereum.
Triết lý thiết kế của cả Monad và MegaETH đều khác biệt lớn so với phân mảnh (Sharding): phân mảnh cắt blockchain theo chiều ngang thành nhiều chuỗi con độc lập (shards), mỗi shard chịu trách nhiệm một phần giao dịch và trạng thái, phá vỡ giới hạn đơn chuỗi để mở rộng ở tầng mạng; còn Monad và MegaETH đều giữ nguyên tính toàn vẹn của đơn chuỗi, chỉ mở rộng ngang ở tầng thực thi, tối ưu hóa cực đại việc thực thi song song bên trong đơn chuỗi để đột phá hiệu suất. Hai hướng này đại diện cho hai hướng đi trong mở rộng blockchain: tăng cường dọc và mở rộng ngang.
Các dự án tính toán song song như Monad và MegaETH tập trung chủ yếu vào con đường tối ưu thông lượng, lấy nâng cao TPS trong chuỗi làm mục tiêu cốt lõi, đạt được xử lý song song ở cấp giao dịch hoặc cấp tài khoản thông qua thực thi trì hoãn (Deferred Execution) và kiến trúc vi máy ảo (Micro-VM). Trong khi đó, Pharos Network là một mạng lưới blockchain L1 mô-đun, song song toàn bộ stack, cơ chế tính toán song song cốt lõi được gọi là “Rollup Mesh”. Kiến trúc này thông qua sự phối hợp giữa mạng chính và mạng xử lý đặc biệt (SPNs), hỗ trợ môi trường đa máy ảo (EVM và Wasm), đồng thời tích hợp các công nghệ tiên tiến như bằng chứng zero-knowledge (ZK), môi trường thực thi đáng tin cậy (TEE), v.v.
Phân tích cơ chế tính toán song song Rollup Mesh:
-
Xử lý theo luồng bất đồng bộ suốt vòng đời (Full Lifecycle Asynchronous Pipelining): Pharos tách rời các giai đoạn của giao dịch (như đồng thuận, thực thi, lưu trữ) và áp dụng xử lý bất đồng bộ, khiến mỗi giai đoạn có thể thực hiện song song độc lập, từ đó nâng cao hiệu quả xử lý tổng thể.
-
Thực thi song song hai máy ảo (Dual VM Parallel Execution): Pharos hỗ trợ hai môi trường máy ảo EVM và WASM, cho phép nhà phát triển lựa chọn môi trường thực thi phù hợp theo nhu cầu. Kiến trúc hai VM này không chỉ nâng cao tính linh hoạt của hệ thống mà còn cải thiện khả năng xử lý giao dịch thông qua thực thi song song.
-
Mạng xử lý đặc biệt (SPNs): SPNs là thành phần then chốt trong kiến trúc Pharos, giống như các mạng con mô-đun, chuyên dùng để xử lý các nhiệm vụ hoặc ứng dụng loại cụ thể. Thông qua SPNs, Pharos có thể đạt được việc phân bổ tài nguyên động và xử lý song song nhiệm vụ, tiếp tục tăng cường khả năng mở rộng và hiệu suất của hệ thống.
-
Đồng thuận mô-đun và cơ chế tái đặt cược (Modular Consensus & Restaking): Pharos giới thiệu cơ chế đồng thuận linh hoạt, hỗ trợ nhiều mô hình đồng thuận (như PBFT, PoS, PoA), và thông qua giao thức tái đặt cược (Restaking) đạt được việc chia sẻ an ninh và tích hợp tài nguyên giữa mạng chính và SPNs.
Bên cạnh đó, Pharos thông qua các công nghệ như cây Merkle đa phiên bản, mã hóa delta (Delta Encoding), địa chỉ theo phiên bản (Versioned Addressing) và đẩy xuống ADS (ADS Pushdown), tái cấu trúc mô hình thực thi từ底层 engine lưu trữ, ra mắt engine lưu trữ hiệu suất cao gốc blockchain Pharos Store, đạt được khả năng xử lý trên chuỗi thông lượng cao, độ trễ thấp, kiểm chứng mạnh mẽ.
Tổng thể, kiến trúc Rollup Mesh của Pharos thông qua thiết kế mô-đun và cơ chế xử lý bất đồng bộ, đạt được khả năng tính toán song song hiệu suất cao. Pharos, với vai trò là người điều phối mở rộng song song giữa các Rollup, không phải là bộ tối ưu thực thi “song song nội chuỗi”, mà là thông qua SPNs để đảm nhận các nhiệm vụ thực thi tùy chỉnh dị biệt.
Ngoài các kiến trúc thực thi song song như Monad, MegaETH và Pharos, chúng tôi cũng nhận thấy trên thị trường tồn tại một số dự án khám phá con đường ứng dụng tăng tốc GPU trong tính toán song song EVM, như một bổ sung quan trọng và thí nghiệm tiên phong cho sinh thái song song EVM. Trong đó, Reddio và GatlingX là hai hướng đại diện:
-
Reddio là một nền tảng hiệu suất cao kết hợp zkRollup và kiến trúc thực thi song song GPU, cốt lõi là tái cấu trúc quy trình thực thi EVM, thông qua lập lịch đa luồng, lưu trữ trạng thái bất đồng bộ và tăng tốc thực thi lô giao dịch bằng GPU, đạt được sự song song hóa gốc ở tầng thực thi. Thuộc mức độ hạt song song cấp giao dịch + cấp thao tác (thực thi đa luồng opcode). Thiết kế này đưa vào thực thi lô đa luồng, tải trạng thái bất đồng bộ và xử lý logic giao dịch song song GPU (CUDA-Compatible Parallel EVM). Giống như Monad/MegaETH, Reddio cũng tập trung vào xử lý song song ở tầng thực thi, khác biệt ở chỗ tái cấu trúc engine thực thi thông qua kiến trúc song song GPU, được thiết kế riêng cho các kịch bản yêu cầu thông lượng cao và tính toán nặng (như suy luận AI). Hiện đã ra mắt SDK, cung cấp module thực thi có thể tích hợp
-
GatlingX tự xưng là “GPU-EVM”, đề xuất một kiến trúc cực đoan hơn, cố gắng chuyển mô hình “thực thi tuần tự lệnh cấp” truyền thống của EVM sang môi trường chạy song song gốc GPU. Cơ chế cốt lõi là biên dịch động bytecode EVM thành các nhiệm vụ CUDA song song, thực thi luồng lệnh bằng nhiều nhân GPU, từ đó phá vỡ điểm nghẽn tuần tự của EVM ở tầng thấp nhất. Thuộc mức độ hạt song song cấp lệnh (Instruction-Level Parallelism, ILP). So với mức độ hạt song song “cấp giao dịch/cấp tài khoản” của Monad/MegaETH, cơ chế song song của GatlingX thuộc con đường tối ưu cấp lệnh, gần hơn với việc tái cấu trúc tầng thấp của engine máy ảo. Hiện đang ở giai đoạn khái niệm, đã phát hành sách trắng và sơ đồ kiến trúc, chưa có SDK hay mainnet.
Artela thì đề xuất một triết lý song song khác biệt. Bằng cách giới thiệu kiến trúc EVM++ và máy ảo WebAssembly (WASM), cho phép nhà phát triển duy trì tính tương thích EVM đồng thời tận dụng mô hình lập trình Aspect để thêm và thực thi các chương trình mở rộng động trên chuỗi. Với mức độ hạt gọi hợp đồng (Function/Extension) làm đơn vị song song nhỏ nhất, hỗ trợ tiêm module Extension (giống như “middleware có thể cắm”) vào lúc chạy hợp đồng EVM, đạt được việc tách rời logic, gọi bất đồng bộ và thực thi song song cấp mô-đun. Tập trung hơn vào tính kết hợp và kiến trúc mô-đun ở tầng thực thi. Triết lý này mang lại ý tưởng mới cho các ứng dụng phức tạp đa mô-đun trong tương lai.
Ba, Chuỗi kiến trúc song song gốc: Tái cấu trúc bản chất thực thi của VM
Mô hình thực thi EVM của Ethereum từ ban đầu đã áp dụng kiến trúc đơn luồng “toàn bộ giao dịch theo thứ tự + thực thi tuần tự”, nhằm đảm bảo tính tất định và nhất quán của mọi nút trong mạng về việc thay đổi trạng thái. Tuy nhiên, kiến trúc này tồn tại điểm nghẽn tự nhiên về hiệu suất, hạn chế thông lượng và khả năng mở rộng của hệ thống. Ngược lại, các chuỗi kiến trúc tính toán song song gốc như Solana (SVM), MoveVM (Sui, Aptos) và Sei v2 xây dựng trên Cosmos SDK, từ thiết kế tầng thấp đã được tạo riêng cho thực thi song song, có các ưu điểm sau:
-
Mô hình trạng thái tự nhiên tách biệt: Solana sử dụng cơ chế khai báo khóa tài khoản, MoveVM giới thiệu mô hình quyền sở hữu đối tượng, Sei v2 dựa trên phân loại loại giao dịch để đạt định nghĩa xung đột tĩnh, hỗ trợ lập lịch đồng thời cấp giao dịch;
-
Máy ảo được tối ưu cho đồng thời: Engine Sealevel của Solana hỗ trợ thực thi đa luồng gốc; MoveVM có thể phân tích đồ thị đồng thời tĩnh; Sei v2 tích hợp engine khớp lệnh đa luồng và module VM song song.
Tất nhiên, các chuỗi song song gốc này cũng đối mặt với thách thức về tương thích sinh thái. Kiến trúc phi EVM thường cần ngôn ngữ phát triển (Move, Rust) và chuỗi công cụ hoàn toàn mới, gây chi phí di chuyển nhất định cho nhà phát triển; hơn nữa, nhà phát triển còn phải nắm vững một loạt khái niệm mới như mô hình truy cập trạng thái, giới hạn đồng thời, vòng đời đối tượng, v.v., đặt ra yêu cầu cao hơn về ngưỡng hiểu biết và mô hình phát triển.
3.1 Nguyên lý động cơ song song Sealevel của Solana và hệ SVM
Mô hình thực thi Sealevel của Solana là một cơ chế lập lịch song song tài khoản, là động cơ cốt lõi của Solana để đạt được thực thi giao dịch song song nội chuỗi, thông qua cơ chế “khai báo tài khoản + lập lịch tĩnh + thực thi đa luồng”, đạt được đồng thời hiệu suất cao ở cấp độ hợp đồng thông minh. Sealevel là mô hình thực thi đầu tiên trong lĩnh vực blockchain thành công triển khai lập lịch đồng thời nội chuỗi trong môi trường sản xuất, tư tưởng kiến trúc của nó ảnh hưởng sâu rộng đến nhiều dự án tính toán song song sau này, là phạm bản tham khảo cho thiết kế song song Layer1 hiệu suất cao.
Cơ chế cốt lõi:
1. Khai báo truy cập tài khoản tường minh (Account Access Lists): Mỗi giao dịch khi gửi phải khai báo các tài khoản liên quan (đọc/ghi), hệ thống dựa vào đó để xác định xem có xung đột trạng thái giữa các giao dịch hay không.
2. Phát hiện xung đột và lập lịch đa luồng
-
Nếu hai giao dịch không giao nhau về tập tài khoản truy cập → có thể thực thi song song;
-
Tồn tại xung đột → thực thi tuần tự theo thứ tự phụ thuộc;
-
Bộ lập lịch dựa trên đồ thị phụ thuộc để phân bổ giao dịch cho các luồng khác nhau.
3. Ngữ cảnh thực thi độc lập (Program Invocation Context): Mỗi lần gọi hợp đồng chạy trong ngữ cảnh cách ly, không chia sẻ ngăn xếp, tránh can thiệp chéo giữa các lần gọi.
Sealevel là động cơ lập lịch thực thi song song của Solana, còn SVM là môi trường thực thi hợp đồng thông minh được xây dựng trên Sealevel (sử dụng máy ảo BPF). Hai cái này cùng tạo thành nền tảng kỹ thuật cho hệ thống thực thi song song hiệu suất cao của Solana.
Eclipse là một dự án triển khai Solana VM lên chuỗi mô-đun (như Ethereum L2 hoặc Celestia), tận dụng động cơ thực thi song song của Solana làm tầng thực thi Rollup. Eclipse là một trong những dự án đầu tiên đề xuất tách động cơ thực thi Solana (Sealevel + SVM) khỏi mạng chính Solana và di chuyển sang kiến trúc mô-đun, mô-đun hóa “mô hình thực thi đồng thời siêu mạnh” của Solana thành Execution Layer-as-a-Service, do đó Eclipse cũng thuộc nhóm tính toán song song.
Con đường của Neon khác biệt, nó đưa EVM vào môi trường SVM/Sealevel để chạy. Xây dựng một tầng chạy tương thích EVM, nhà phát triển có thể dùng Solidity để phát triển hợp đồng và chạy trong môi trường SVM, nhưng lập lịch thực thi sử dụng SVM + Sealevel. Neon thiên về phạm trù blockchain mô-đun hơn là nhấn mạnh sáng tạo tính toán song song.
Tóm lại, Solana và SVM dựa vào động cơ thực thi Sealevel, triết lý lập lịch kiểu hệ điều hành của Solana giống bộ lập lịch kernel, thực thi nhanh, nhưng tính linh hoạt tương đối thấp. Là chuỗi công cộng gốc hiệu suất cao, tính toán song song.
3.2 Kiến trúc MoveVM: Dẫn dắt bởi tài nguyên và đối tượng
MoveVM là máy ảo hợp đồng thông minh được thiết kế cho an ninh tài nguyên trên chuỗi và thực thi song song, ngôn ngữ cốt lõi Move ban đầu do Meta (trước là Facebook) phát triển cho dự án Libra, nhấn mạnh triết lý “tài nguyên là đối tượng”, mọi trạng thái trên chuỗi đều tồn tại dưới dạng đối tượng, có quyền sở hữu và vòng đời rõ ràng. Điều này khiến MoveVM có thể phân tích trong thời gian biên dịch xem các giao dịch có xung đột trạng thái hay không, đạt được lập lịch song song tĩnh cấp đối tượng, được áp dụng rộng rãi trên các chuỗi công cộng song song gốc như Sui và Aptos.
Mô hình quyền sở hữu đối tượng của Sui
Khả năng tính toán song song của Sui bắt nguồn từ cách mô hình hóa trạng thái độc đáo và cơ chế phân tích tĩnh cấp ngôn ngữ. Khác với blockchain truyền thống sử dụng cây trạng thái toàn cục, Sui xây dựng một mô hình trạng thái dựa trên “đối tượng” (Object-centric model), kết hợp với hệ thống kiểu tuyến tính của MoveVM, khiến việc lập lịch song song trở thành quá trình tất định có thể hoàn thành trong thời gian biên dịch.
-
Mô hình đối tượng (Object Model) là nền tảng kiến trúc song song của Sui. Sui trừu tượng hóa mọi trạng thái trên chuỗi thành các đối tượng độc lập (Object), mỗi đối tượng có ID duy nhất, chủ sở hữu rõ ràng (tài khoản hoặc hợp đồng) và định nghĩa kiểu. Những đối tượng này không chia sẻ trạng thái, có tính cách ly tự nhiên. Khi gọi hợp đồng phải khai báo tường minh tập hợp các đối tượng liên quan, tránh được vấn đề ghép nối trạng thái của “cây trạng thái toàn cục” trên chuỗi truyền thống. Thiết kế này cắt trạng thái trên chuỗi thành các đơn vị độc lập, khiến việc thực thi đồng thời trở thành tiền đề khả thi về mặt cấu trúc.
-
Phân tích quyền sở hữu tĩnh (Static Ownership Analysis) là cơ chế phân tích thời gian biên dịch được thực hiện nhờ hỗ trợ hệ thống kiểu tuyến tính của ngôn ngữ Move. Nó cho phép hệ thống trước khi thực thi giao dịch, suy luận qua quyền sở hữu đối tượng để biết giao dịch nào sẽ không gây xung đột trạng thái, từ đó sắp xếp chúng thực thi song song. So với phát hiện xung đột và hoàn tác trong thời gian chạy truyền thống, cơ chế phân tích tĩnh của Sui nâng cao hiệu suất thực thi đồng thời giảm đáng kể độ phức tạp lập lịch, là chìa khóa để đạt được khả năng xử lý song song tất định và thông lượng cao.
Sui chia không gian trạng thái theo đơn vị đối tượng, kết hợp phân tích quyền sở hữu thời gian biên dịch, đạt được thực thi song song cấp đối tượng hiệu suất thấp, không cần hoàn tác. So với thực thi tuần tự hoặc phát hiện thời gian chạy truyền thống, Sui đạt cải thiện đáng kể về hiệu suất thực thi, tính tất định hệ thống và hiệu suất sử dụng tài nguyên.
Cơ chế thực thi Block-STM của Aptos
Aptos là một blockchain Layer1 hiệu suất cao dựa trên ngôn ngữ Move, khả năng thực thi song song chủ yếu bắt nguồn từ framework Block-STM (Block-level Software Transactional Memory) do tự phát triển. Khác với Sui thiên về chiến lược “song song tĩnh thời biên dịch”, Block-STM thuộc cơ chế lập lịch động “đồng thời lạc quan thời gian chạy + hoàn tác xung đột”, phù hợp xử lý tập giao dịch có quan hệ phụ thuộc phức tạp.
Block-STM chia thực thi giao dịch trong một khối thành ba giai đoạn:
-
Thực thi đồng thời lạc quan (Speculative Execution): Tất cả giao dịch mặc định không xung đột trước khi thực thi, hệ thống lập lịch song song giao dịch vào nhiều luồng để thử thực thi đồng thời, ghi lại trạng thái tài khoản truy cập (tập đọc/tập ghi).
-
Phát hiện và xác minh xung đột (Validation Phase): Hệ thống xác minh kết quả thực thi: nếu hai giao dịch có xung đột đọc ghi (ví dụ Tx1 đọc trạng thái bị Tx2 ghi), thì hoàn tác một trong hai.
-
Hoàn tác và thử lại giao dịch xung đột (Retry Phase): Giao dịch xung đột sẽ được sắp xếp thực thi lại, cho đến khi giải quyết xong phụ thuộc, cuối cùng tất cả giao dịch tạo thành một chuỗi cam kết trạng thái hợp lệ và tất định.
Block-STM là mô hình thực thi động “song song lạc quan + hoàn tác thử lại”, phù hợp xử lý lô giao dịch trên chuỗi có mật độ trạng thái cao, logic phức tạp, là cốt lõi tính toán song song để Aptos xây dựng chuỗi công cộng hiệu suất chung cao, thông lượng cao.
Solana là phe lập lịch kỹ thuật, giống “kernel hệ điều hành”, phù hợp giao dịch tần số cao ranh giới trạng thái rõ ràng, kiểu kỹ sư phần cứng, muốn chạy chuỗi như phần cứng (Hardware-grade parallel execution); Aptos là phe dung sai hệ thống, giống “động cơ đồng thời cơ sở dữ liệu”, phù hợp hệ thống hợp đồng có ghép nối trạng thái mạnh, chuỗi gọi phức tạp; Sui là phe an toàn biên dịch, giống “nền tảng ngôn ngữ thông minh tài nguyên”, phù hợp ứng dụng trên chuỗi tách biệt tài sản, tổ hợp rõ ràng; Aptos và Sui giống kỹ sư ngôn ngữ chương trình, muốn chạy chuỗi an toàn như phần mềm (Software-grade resource security). Ba cái này đại diện cho các con đường hiện thực công nghệ tính toán song song Web3 dưới các triết lý khác nhau.
3.3 Mở rộng song song Cosmos SDK
Sei V2 là một chuỗi công cộng hiệu suất cao giao dịch xây dựng trên Cosmos SDK, khả năng song song chủ yếu thể hiện ở hai khía cạnh: động cơ khớp lệnh đa luồng (Parallel Matching Engine) và tối ưu thực thi song song ở tầng máy ảo, nhằm phục vụ các kịch bản giao dịch trên chuỗi tần số cao, độ trễ thấp như DEX sổ lệnh, hạ tầng sàn giao dịch trên chuỗi, v.v.
Cơ chế song song cốt lõi:
-
Động cơ khớp lệnh song song: Sei V2 đưa đường dẫn thực thi đa luồng vào logic khớp lệnh, chia tách sổ lệnh và logic khớp lệnh theo cấp độ luồng, khiến nhiệm vụ khớp lệnh giữa nhiều thị trường (cặp giao dịch) có thể xử lý song song, tránh điểm nghẽn đơn luồng.
-
Tối ưu đồng thời cấp máy ảo: Sei V2 xây dựng một môi trường chạy CosmWasm có khả năng thực thi đồng thời, cho phép một số lời gọi hợp đồng chạy song song nếu không xung đột trạng thái, kết hợp cơ chế phân loại loại giao dịch để đạt kiểm soát thông lượng cao hơn.
-
Đồng thuận song song phối hợp với lập lịch tầng thực thi: Giới thiệu cơ chế đồng thuận “Twin-Turbo”, tăng cường tách rời thông lượng giữa tầng đồng thuận và tầng thực thi, nâng cao hiệu quả xử lý khối tổng thể.
3.4 Fuel, người tái cấu trúc mô hình UTXO
Fuel là một tầng thực thi hiệu suất cao được thiết kế theo kiến trúc mô-đun Ethereum, cơ chế song song cốt lõi bắt nguồn từ mô hình UTXO cải tiến (Unspent Transaction Output). Khác với mô hình tài khoản của Ethereum, Fuel dùng cấu trúc UTXO để biểu thị tài sản và trạng thái, mô hình này tự nhiên có tính cách ly trạng thái, dễ dàng xác định giao dịch nào có thể thực thi song song an toàn. Ngoài ra, Fuel giới thiệu ngôn ngữ hợp đồng thông minh tự phát triển Sway (giống Rust), kết hợp công cụ phân tích tĩnh, có thể xác định xung đột đầu vào trước khi thực thi giao dịch, từ đó đạt lập lịch song song cấp giao dịch hiệu quả và an toàn. Là tầng thực thi thay thế EVM cân bằng hiệu suất và mô-đun hóa.
Bốn, Mô hình Actor: Phạm trù mới về thực thi đồng thời tác nhân
Mô hình Actor là một phạm trù thực thi song song lấy tiến trình tác nhân (Agent hoặc Process) làm đơn vị, khác với tính toán đồng bộ trạng thái toàn cục truyền thống trên chuỗi (cảnh tượng “tính toán song song trên chuỗi” như Solana/Sui/Monad), nó nhấn mạnh mỗi tác nhân có trạng thái và hành vi độc lập, giao tiếp và lập lịch thông qua tin nhắn bất đồng bộ. Trong kiến trúc này, hệ thống trên chuỗi có thể do hàng loạt tiến trình tách rời chạy đồng thời, có khả năng mở rộng và dung sai bất đồng bộ cực mạnh. Các dự án tiêu biểu bao gồm AO (Arweave AO), ICP (Internet Computer) và Cartesi, đang thúc đẩy blockchain tiến hóa từ động cơ thực thi thành “hệ điều hành trên chuỗi”, cung cấp hạ tầng gốc cho AI Agent, tương tác đa nhiệm và biên đạo logic phức tạp.
Mặc dù thiết kế mô hình Actor có nét tương đồng bề mặt (như song song, cách ly trạng thái, xử lý bất đồng bộ) với phân mảnh (Sharding), nhưng về bản chất hai cái này đại diện cho hai con đường kỹ thuật và triết lý hệ thống hoàn toàn khác nhau. Mô hình Actor nhấn mạnh “tính toán bất đồng bộ đa tiến trình”, mỗi tác nhân (Actor) chạy độc lập, duy trì trạng thái độc lập, tương tác theo cách thức điều khiển bởi tin nhắn; còn phân mảnh là một cơ chế “phân chia ngang trạng thái và đồng thuận”, chia toàn bộ blockchain thành nhiều hệ thống con độc lập xử lý giao dịch (Shard). Mô hình Actor giống như “hệ điều hành tác nhân phân tán” trong thế giới Web3, còn phân mảnh là giải pháp mở rộng cấu trúc cho khả năng xử lý giao dịch trong chuỗi. Cả hai đều đạt được song song, nhưng điểm khởi đầu, mục tiêu và kiến trúc thực thi khác nhau.
4.1 AO (Arweave), siêu máy tính song song trên tầng lưu trữ
AO là một nền tảng tính toán phi tập trung chạy trên tầng lưu trữ vĩnh viễn Arweave, mục tiêu cốt lõi là xây dựng một hệ điều hành trên chuỗi hỗ trợ chạy quy mô lớn các tác nhân bất đồng bộ.
Đặc điểm kiến trúc cốt lõi:
-
Kiến trúc Process: Mỗi tác nhân được gọi là một Process, có trạng thái độc lập, bộ lập lịch độc lập và logic thực thi độc lập;
-
Không có cấu trúc chuỗi: AO không phải là một chuỗi, mà là tầng lưu trữ phi tập trung Arweave + động cơ thực thi điều khiển bởi tin nhắn đa tác nhân;
-
Hệ thống lập lịch tin nhắn bất đồng bộ: Process giao tiếp qua tin nhắn (Message), áp dụng mô hình chạy bất đồng bộ không khóa, tự nhiên hỗ trợ mở rộng đồng thời;
-
Lưu trữ trạng thái vĩnh viễn: Mọi trạng thái tác nhân, bản ghi tin nhắn, lệnh đều được ghi vĩnh viễn trên Arweave, đảm bảo tính kiểm toán hoàn toàn và tính minh bạch phi tập trung;
-
Native Agent: Phù hợp triển khai nhiệm vụ đa bước phức tạp (như agent AI, bộ điều khiển giao thức DePIN, bộ biên đạo nhiệm vụ tự động, v.v.), có thể xây dựng “Coprocessor AI trên chuỗi”.
AO đi theo con đường “tác nhân gốc + điều khiển bởi lưu trữ + kiến trúc không chuỗi” cực đoan, nhấn mạnh tính linh hoạt và tách rời mô-đun, là “khung vi nhân trên chuỗi dựng trên tầng lưu trữ”, cố ý thu hẹp biên giới hệ thống, nhấn mạnh cấu trúc điều khiển nhẹ + có thể kết hợp.
4.2 ICP (Internet Computer), nền tảng lưu trữ Web3 toàn stack
ICP là nền tảng ứng dụng toàn stack gốc Web3 do DFINITY ra mắt, mục tiêu là mở rộng khả năng tính toán trên chuỗi đến trải nghiệm kiểu Web2, và hỗ trợ lưu trữ dịch vụ đầy đủ, liên kết tên miền và kiến trúc không máy chủ.
Đặc điểm kiến trúc cốt lõi:
-
Kiến trúc Canister (container là tác nhân): Mỗi Canister là một tác nhân chạy trên Wasm VM, có trạng thái độc lập, mã và khả năng lập lịch bất đồng bộ;
-
Hệ thống đồng thuận phân tán subnet (Subnet): Toàn bộ mạng gồm nhiều Subnet, mỗi subnet quản lý một nhóm Canister, đạt đồng thuận thông qua cơ chế chữ ký BLS;
-
Mô hình gọi bất đồng bộ: Canister giao tiếp qua tin nhắn bất đồng bộ, hỗ trợ thực thi không chặn, có tính song song tự nhiên;
-
Lưu trữ web trên chuỗi: Hỗ trợ hợp đồng thông minh lưu trữ trực tiếp trang front-end, ánh xạ DNS gốc, là nền tảng blockchain đầu tiên hỗ trợ trình duyệt truy cập dApp trực tiếp;
-
Chức năng hệ thống đầy đủ: Có API hệ thống như nâng cấp nóng trên chuỗi, danh tính được xác thực, ngẫu nhiên phân tán, bộ đếm thời gian, v.v., phù hợp triển khai dịch vụ phức tạp trên chuỗi.
ICP chọn phạm trù hệ điều hành nền tảng nặng, đóng gói一体化, kiểm soát nền tảng mạnh, có “hệ điều hành blockchain” tích hợp đồng thuận, thực thi, lưu trữ, truy cập, nhấn mạnh khả năng lưu trữ dịch vụ đầy đủ, mở rộng biên giới hệ thống thành nền tảng lưu trữ Web3 toàn stack.
Bên cạnh đó, các dự án tính toán song song khác theo mô hình Actor có thể tham khảo bảng sau:
Năm, Tổng kết và triển vọng
Dựa trên sự khác biệt về kiến trúc máy ảo và hệ thống ngôn ngữ, các giải pháp tính toán song song blockchain có thể chia thành hai loại lớn: chuỗi tăng cường song song hệ EVM và chuỗi kiến trúc song song gốc (phi EVM).
Loại trước trên cơ sở giữ tương thích sinh thái EVM/Solidity, thông qua tối ưu sâu ở tầng thực thi, đạt thông lượng cao hơn và khả năng xử lý song song, phù hợp với các kịch bản muốn kế thừa tài sản và công cụ phát triển Ethereum đồng thời đạt đột phá hiệu suất. Các dự án tiêu biểu bao gồm:
-
Monad: Thông qua trì hoãn ghi và phát hiện xung đột thời gian chạy, đạt mô hình thực thi song song lạc quan tương thích EVM, xây dựng đồ thị phụ thuộc sau khi đạt đồng thuận và lập lịch thực thi đa luồng.
-
MegaETH: Trừu tượng hóa mỗi tài khoản/hợp đồng thành vi máy ảo độc lập (Micro-VM), dựa trên truyền tin nhắn bất đồng bộ và đồ thị phụ thuộc trạng thái, đạt lập lịch song song cấp tài khoản tách rời cao độ.
-
Pharos: Xây dựng kiến trúc Rollup Mesh, thông qua phối hợp giữa dòng xử lý bất đồng bộ và module SPN, đạt xử lý song song cấp hệ thống xuyên quy trình.
-
Reddio: Áp dụng zkRollup + kiến trúc GPU, tập trung vào tăng tốc quá trình xác minh ngoài chuỗi zkEVM thông qua tạo batch SNARK, nâng cao tỷ lệ thông lượng xác minh.
Loại sau hoàn toàn thoát khỏi giới hạn tương thích Ethereum, từ máy ảo, mô hình trạng thái và cơ chế lập lịch để thiết kế lại phạm trù thực thi, nhằm đạt khả năng đồng thời hiệu suất cao gốc. Các nhóm con điển hình bao gồm:
-
Solana (hệ SVM): Dựa trên khai báo truy cập tài khoản và đồ thị xung đột tĩnh để lập lịch, đại diện mô hình thực thi song song cấp tài khoản;
-
Sui/Aptos (hệ MoveVM): Dựa trên mô hình đối tượng tài nguyên và hệ thống kiểu, hỗ trợ phân tích tĩnh thời biên dịch, đạt song song cấp đối tượng;
-
Sei V2 (tuyến đường Cosmos SDK): Trong kiến trúc Cosmos đưa vào động cơ khớp lệnh đa luồng và tối ưu đồng thời máy ảo, phù hợp ứng dụng giao dịch tần số cao;
-
Fuel (kiến trúc UTXO + Sway): Thông qua phân tích tĩnh tập đầu vào UTXO đạt song song cấp giao dịch, kết hợp tầng thực thi mô-đun và ngôn ngữ hợp đồng thông minh tùy chỉnh Sway;
Bên cạnh đó, mô hình Actor như một hệ thống song song tổng quát hơn, thông qua cơ chế lập lịch tiến trình bất đồng bộ dựa trên Wasm hoặc VM tùy chỉnh, xây dựng phạm trù thực thi trên chuỗi “nhiều tác nhân độc lập chạy + hợp tác điều khiển bởi tin nhắn”. Các dự án tiêu biểu bao gồm:
-
AO (Arweave AO): Dựa trên runtime tác nhân điều khiển bởi lưu trữ vĩnh viễn, xây dựng hệ thống vi nhân bất đồng bộ trên chuỗi;
-
ICP (Internet Computer): Lấy tác nhân container hóa (Canister) làm đơn vị nhỏ nhất, thông qua phối hợp subnet đạt thực thi bất đồng bộ khả mở rộng cao;
-
Cartesi: Đưa hệ điều hành Linux làm môi trường tính toán ngoài chuỗi, cung cấp đường dẫn xác minh trên chuỗi cho kết quả tính toán đáng tin cậy, phù hợp các kịch bản ứng dụng phức tạp hoặc nặng tài nguyên.
Dựa trên logic trên, chúng ta có thể khái quát các giải pháp chuỗi công cộng tính toán song song chủ lưu hiện nay thành cấu trúc phân loại như biểu đồ sau:
Xét từ góc nhìn mở rộng tổng quát hơn, phân mảnh (Sharding) và Rollup (L2) tập trung vào mở rộng ngang hệ thống thông qua phân chia trạng thái hoặc thực thi ngoài chuỗi, trong khi các chuỗi tính toán song song (như Monad, Sui, Solana) và hệ thống định hướng Actor (như AO, ICP) trực tiếp tái cấu trúc mô hình thực thi, đạt song song gốc trong chuỗi hoặc ở tầng hệ thống. Loại trước nâng cao thông lượng trong chuỗi thông qua máy ảo đa luồng, mô hình đối tượng, phân tích xung đột giao dịch; loại sau lấy tiến trình/tác nhân làm đơn vị cơ bản, dùng cách thức điều khiển bởi tin nhắn và thực thi bất đồng bộ để đạt chạy đồng thời đa tác nhân. So sánh, phân
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
