Web3 Parallel Computing Track Panorama: Giải pháp tốt nhất để mở rộng quy mô gốc?
Tác giả: 0xjacobzhao và ChatGPT 4o"
Bộ ba Blockchain" về "bảo mật", "phi tập trung" và "khả năng mở rộng" của blockchain cho thấy sự đánh đổi thiết yếu trong thiết kế hệ thống blockchain, tức là các dự án blockchain khó đạt được "bảo mật cực cao, mọi người đều có thể tham gia và xử lý tốc độ cao" cùng một lúc. Để đáp ứng chủ đề vĩnh cửu về "khả năng mở rộng", các giải pháp mở rộng quy mô blockchain chính thống trên thị trường được phân chia theo các mô hình, bao gồm:
- Mở rộng quy mô tăng cường thực thi: Cải thiện khả năng thực thi tại chỗ, chẳng hạn như song song, GPU và đa lõi
- Mở rộng quy mô cách ly trạng thái: Chia trạng thái/phân đoạn theo chiều ngang, ví dụ: phân đoạn, UTXO và nhiều mạng con Mở
- rộng quy mô thuê ngoài ngoài chuỗi: Đặt khớp lệnh ngoài chuỗi, chẳng hạn như rollup, Chia tỷ lệ tách rời cấu trúc đồng xử lý và DA
- : Kiến trúc mô-đun và hoạt động cộng tác, chẳng hạn như chuỗi mô-đun, trình sắp xếp trình tự được chia sẻ, Rollup Mesh
- Mở rộng đồng thời không đồng bộ: Mô hình tác nhân, cách ly quy trình, điều khiển thông điệp, chẳng hạn như tác nhân, chuỗi không đồng bộ đa luồng
Giải pháp mở rộng quy mô blockchain bao gồm: tính toán song song trên chuỗi, rollup, sharding, mô-đun DA, cấu trúc mô-đun, hệ thống actor, nén bằng chứng zk, kiến trúc không trạng thái, v.v., bao gồm nhiều cấp độ thực thi, trạng thái, dữ liệu và cấu trúc, đồng thời là một hệ thống mở rộng quy mô hoàn chỉnh của "cộng tác đa lớp và kết hợp mô-đun". Bài viết này tập trung vào các phương pháp mở rộng quy mô làm chủ đạo điện toán song song.
Tínhsong song trong chuỗi, tập trung vào việc thực hiện song song các giao dịch/hướng dẫn trong khối. Theo cơ chế song song, các phương pháp mở rộng quy mô của nó có thể được chia thành năm loại, mỗi loại đại diện cho một mục tiêu theo đuổi hiệu suất, mô hình phát triển và triết lý kiến trúc khác nhau, và độ chi tiết song song ngày càng mịn hơn, cường độ song song ngày càng cao, độ phức tạp của lập trình ngày càng cao, độ phức tạp của lập trình và độ khó thực hiện cũng ngày càng cao.
- Account-level: Đại diện cho dự án
- Object-level: Đại diện cho dự án Sui
- Transaction-level: Đại diện cho dự án Monad, Aptos
- Call-level / MicroVM : MegaETH cấp độ hướng dẫn :
- GatlingX
Mô hình đồng thời không đồng bộ off-chain, được thể hiện bởi Mô hình Actor / Actor, thuộc một mô hình tính toán song song khác, là hệ thống tin nhắn chuỗi chéo/không đồng bộ (mô hình đồng bộ hóa không khối), mỗi tác nhân chạy độc lập như một "quy trình tác nhân", tin nhắn không đồng bộ ở chế độ song song, theo hướng sự kiện, không lập lịch đồng bộ, các dự án đại diện như AO, ICP, Cartesi, v.v.
Sơ đồ rollup hoặc shard scaling nổi tiếng thuộc về cơ chế đồng thời cấp hệ thống, không phải tính toán song song trong chuỗi. Chúng đạt được khả năng mở rộng quy mô bằng cách "chạy song song nhiều chuỗi/miền thực thi", thay vì tăng tính song song trong một khối/máy ảo. Loại giải pháp mở rộng quy mô này không phải là trọng tâm của bài viết này, nhưng chúng tôi vẫn sẽ sử dụng nó để so sánh những điểm giống và khác nhau trong các khái niệm kiến trúc.
2. Chuỗi tăng cường song song EVM: Phá vỡ ranh giới hiệu suất trong khả năng tương thích
Kể từ khi phát triển kiến trúc xử lý nối tiếp của Ethereum, nó đã trải qua nhiều vòng nỗ lực mở rộng quy mô như sharding, rollup và kiến trúc mô-đun, nhưng tắc nghẽn thông lượng của lớp thực thi vẫn chưa được phá vỡ về cơ bản. Nhưng đồng thời, EVM và Solidity vẫn là nền tảng hợp đồng thông minh có cơ sở nhà phát triển và tiềm năng sinh thái nhất. Do đó, chuỗi tăng cường song song EVM đang trở thành một hướng quan trọng cho một vòng mở rộng và phát triển mới như một con đường quan trọng có tính đến khả năng tương thích sinh thái và cải thiện hiệu suất thực thi. Monad và MegaETH là những dự án tiêu biểu nhất theo hướng này, bắt đầu từ việc thực hiện trì hoãn và phân tách trạng thái tương ứng, để xây dựng kiến trúc xử lý song song EVM cho các kịch bản đồng thời cao và thông lượng cao.
Phân tíchđiện toán song song của MonadMonad
là một blockchain Layer1 hiệu suất cao được thiết kế lại cho Máy ảo Ethereum (EVM), dựa trên khái niệm song song cơ bản về đường ống, với Thực thi không đồng bộ ở lớp đồng thuận và đồng thời lạc quan ở lớp thực thi Thực hiện song song) 。 Ngoài ra, ở các lớp đồng thuận và lưu trữ, Monad đã 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) tương ứng để đạt được tối ưu hóa từ đầu đến cuối.
Đường ống: Cơ chế thực thi song song đường ống nhiều giai đoạn
Đường ống là khái niệm cơ bản của thực thi song song Monad và ý tưởng cốt lõi của nó là chia quá trình thực thi của blockchain thành nhiều giai đoạn độc lập và xử lý song song các giai đoạn này để tạo thành kiến trúc đường ống ba chiều, mỗi giai đoạn chạy trên các luồng hoặc lõi độc lập để đạt được xử lý đồng thời giữa các khối. Kết quả là tăng thông lượng và giảm độ trễ. Các giai đoạn này bao gồm: Đề xuất, Đồng thuận, Thực hiện và Cam kết.
Thực thi không đồng bộ: Đồng thuận - Thực thi được tách rời không đồng bộTrên các
chuỗi truyền thống, đồng thuận và thực thi giao dịch thường là các quy trình đồng bộ và mô hình nối tiếp này hạn chế nghiêm trọng việc mở rộng quy mô hiệu suất. Monad triển khai lớp đồng thuận không đồng bộ, lớp thực thi không đồng bộ và lưu trữ không đồng bộ thông qua "thực thi không đồng bộ". Giảm đáng kể thời gian chặn và độ trễ xác nhận, giúp hệ thống có khả năng phục hồi hơn, xử lý phân đoạn nhiều hơn và sử dụng tài nguyên.
Thiết kế cốt lõi:
- Quy trình đồng thuận (lớp đồng thuận) chỉ chịu trách nhiệm sắp xếp các giao dịch và không thực hiện logic hợp đồng.
- Quá trình thực thi (lớp thực thi) được kích hoạt không đồng bộ sau khi sự đồng thuận hoàn tất.
- Sau khi hoàn thành sự đồng thuận, nó sẽ bước vào quá trình đồng thuận của khối tiếp theo ngay lập tức, không cần đợi quá trình thực hiện hoàn tất.
thi song song lạc quan: Thực thi song song lạc quanEthereum truyền thống
áp dụng mô hình nối tiếp nghiêm ngặt để thực hiện giao dịch nhằm tránh xung đột trạng thái. Mặt khác, Monad áp dụng chiến lược "thực thi song song lạc quan" để tăng đáng kể tốc độ xử lý giao dịch.
Cơ chế thực thi:
- Monad thực hiện song song tất cả các giao dịch, giả sử rằng hầu hết các giao dịch đều không có trạng thái và không có xung đột.
- Đồng thời chạy "Trình phát hiện xung đột" để theo dõi xem có cùng trạng thái (ví dụ: xung đột đọc/ghi) được truy cập giữa các giao dịch hay không.
- Nếu phát hiện xung đột, giao dịch xung đột sẽ được tuần tự hóa và thực thi lại để đảm bảo rằng trạng thái là chính xác.
Monad đã chọn một con đường tương thích: di chuyển càng ít quy tắc EVM càng tốt, đạt được tính song song bằng cách trì hoãn trạng thái ghi và tự động phát hiện xung đột trong quá trình thực thi, giống như một phiên bản hiệu suất của Ethereum, với mức độ trưởng thành giúp dễ dàng di chuyển sang hệ sinh thái EVM và là một bộ tăng tốc song song trong thế giới EVM.
Độ phân giải cơ chế tính toán song song của MegaETH
khác với định vị L1 của Monad và MegaETH được định vị là lớp thực thi song song hiệu suất cao mô-đun tương thích với EVM, có thể được sử dụng như một chuỗi công khai L1 độc lập, như một lớp tăng cường thực thi hoặc thành phần mô-đun trên Ethereum. Mục tiêu thiết kế cốt lõi của nó là giải cấu trúc logic tài khoản, môi trường thực thi và cách ly trạng thái thành đơn vị nhỏ nhất có thể được lên lịch độc lập để đạt được khả năng thực thi đồng thời cao và khả năng phản hồi độ trễ thấp trong chuỗi. Sự đổi mới quan trọng do MegaETH đề xuất là kiến trúc Micro-VM + DAG phụ thuộc trạng thái (đồ thị phụ thuộc trạng thái có định hướng và không tuần hoàn) và cơ chế đồng bộ hóa mô-đun cùng xây dựng một hệ thống thực thi song song cho "phân luồng trong chuỗi".
Kiến trúc Micro-VM: Tài khoản là luồng
MegaETH giới thiệu mô hình thực thi "một micro-VM cho mỗi tài khoản", "luồng" môi trường thực thi và cung cấp một đơn vị cách ly tối thiểu để lập lịch song song. Các máy ảo này giao tiếp với nhau thông qua nhắn tin không đồng bộ thay vì các lệnh gọi đồng bộ và một số lượng lớn máy ảo có thể được thực thi độc lập, lưu trữ độc lập và song song một cách tự nhiên.
DAG phụ thuộc trạng thái: một cơ chế lập lịch dựa trên đồ thị
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 và hệ thống duy trì biểu đồ phụ thuộc toàn cầu trong thời gian thực, và tài khoản nào được sửa đổi và tài khoản nào được đọc cho mỗi giao dịch đều được mô hình hóa thành các phụ thuộc. Các giao dịch không có xung đột có thể được thực hiện trực tiếp song song và các giao dịch phụ thuộc sẽ được lên lịch và sắp xếp tuần tự hoặc hoãn lại theo thứ tự tô pô. Biểu đồ phụ thuộc đảm bảo tính nhất quán của trạng thái và ghi không trùng lặp trong quá trình thực thi song song. Cơ
chế thực thi và gọi lại không đồng bộ
MegaETH được xây dựng dựa trên mô hình lập trình không đồng bộ, tương tự như truyền thông báo không đồng bộ của Mô hình Actor, để giải quyết vấn đề của các cuộc gọi nối tiếp EVM truyền thống. Các lệnh gọi hợp đồng là không đồng bộ (thực thi không đệ quy) và khi hợp đồng A -> B -> C được gọi, mỗi lệnh gọi là không đồng bộ mà không chặn chờ đợi; Ngăn xếp cuộc gọi được mở rộng thành một biểu đồ cuộc gọi không đồng bộ; Xử lý giao dịch = duyệt qua đồ thị không đồng bộ + giải quyết phụ thuộc + lập lịch song song.
Nói chung, MegaETH phá vỡ mô hình máy trạng thái đơn luồng EVM truyền thống, triển khai đóng gói máy ảo vi mô trên cơ sở từng tài khoản, thực hiện lập lịch giao dịch thông qua các biểu đồ phụ thuộc vào trạng thái và thay thế ngăn xếp cuộc gọi đồng bộ bằng cơ chế nhắn tin không đồng bộ. Đây là một nền tảng điện toán song song được thiết kế lại từ đầy đủ các khía cạnh của "cấu trúc tài khoản→ kiến trúc lập lịch trình → quy trình thực thi", cung cấp một ý tưởng mới ở cấp độ mô hình để xây dựng một hệ thống on-chain hiệu suất cao thế hệ tiếp theo.
MegaETH đã chọn con đường tái cấu trúc: nó hoàn toàn trừu tượng hóa các tài khoản và hợp đồng thành các máy ảo độc lập và giải phóng tiềm năng song song cuối cùng thông qua lập lịch thực hiện không đồng bộ. Về mặt lý thuyết, MegaETH có giới hạn song song cao hơn, nhưng nó cũng khó kiểm soát độ phức tạp hơn và nó giống như một hệ điều hành siêu phân tán theo khái niệm Ethereum.
Monad và MegaETH Cả hai đều có các khái niệm thiết kế khác nhau so với sharding: sharding theo chiều ngang chia blockchain thành nhiều chuỗi con độc lập (shard), mỗi chuỗi chịu trách nhiệm cho một phần giao dịch và trạng thái, phá vỡ giới hạn chuỗi đơn và mở rộng quy mô tại lớp mạng; Mặt khác, cả Monad và MegaETH đều duy trì tính toàn vẹn của chuỗi đơn, chỉ mở rộng quy mô theo chiều ngang ở lớp khớp lệnh và thực hiện các đột phá tối ưu hóa song song ở giới hạn của chuỗi đơn. Cả hai đại diện cho hai hướng: tăng cường theo chiều dọc và mở rộng theo chiều ngang trong con đường mở rộng blockchain.
Các dự án điện toán song song như Monad và MegaETH chủ yếu tập trung vào lộ trình tối ưu hóa thông lượng, với mục tiêu cốt lõi là cải thiện TPS trên chuỗi và đạt được xử lý song song cấp giao dịch hoặc cấp tài khoản thông qua thực hiện trì hoãn và kiến trúc micro-VM. Pharos Network là một mạng blockchain L1 song song mô-đun, full-stack và hệ thống điện toán song song cốt lõi của nó được gọi là "Rollup Mesh". Kiến trúc này hỗ trợ môi trường máy đa ảo (EVM và Wasm) thông qua sức mạnh tổng hợp của mạng chính và mạng xử lý đặc biệt (SPN), đồng thời tích hợp các công nghệ tiên tiến như bằng chứng không kiến thức (ZK) và môi trường thực thi đáng tin cậy (TEE).
Phân tích điện toán song song Rollup Mesh:
Đường- ống không đồng bộ toàn vòng đời: Pharos tách các giai đoạn khác nhau của giao dịch (chẳng hạn như đồng thuận, thực thi và lưu trữ) và áp dụng xử lý không đồng bộ để mỗi giai đoạn có thể được thực hiện độc lập và song song, do đó cải thiện hiệu quả xử lý tổng thể.
- Thực thi song song máy ảo kép: Pharos hỗ trợ cả môi trường máy ảo EVM và WASM, cho phép các nhà phát triển chọn môi trường thực thi phù hợp với nhu cầu của họ. Kiến trúc máy ảo kép này không chỉ làm tăng tính linh hoạt của hệ thống mà còn tăng khả năng xử lý giao dịch thông qua thực thi song song.
- Mạng xử lý đặc biệt (SPN): SPN là các thành phần quan trọng trong kiến trúc Pharos, tương tự như các mạng con mô-đun được thiết kế để xử lý các loại tác vụ hoặc ứng dụng cụ thể. Với SPN, Pharos cho phép phân bổ động tài nguyên và xử lý song song các tác vụ, nâng cao hơn nữa khả năng mở rộng và hiệu suất của hệ thống. Modular
- Consensus & Restaking: Pharos giới thiệu một cơ chế đồng thuận linh hoạt hỗ trợ nhiều mô hình đồng thuận (chẳng hạn như PBFT, PoS, PoA) và cho phép chia sẻ an toàn và tích hợp tài nguyên giữa mainnet và SPN thông qua giao thức restaking.
Ngoài ra, Pharos xây dựng lại mô hình thực thi từ lớp dưới cùng của công cụ lưu trữ thông qua cây Merkle đa phiên bản, Mã hóa Delta, Địa chỉ phiên bản và công nghệ ADS Pushdown, đồng thời ra mắt Pharos Store, một công cụ lưu trữ hiệu suất cao cho blockchain gốc, để đạt được thông lượng cao, độ trễ thấp và khả năng xử lý on-chain mạnh mẽ có thể xác minh.
Nhìn chung, kiến trúc Rollup Mesh của Pharos đạt được khả năng tính toán song song hiệu suất cao thông qua thiết kế mô-đun và cơ chế xử lý không đồng bộ.
Ngoài các kiến trúc thực thi song song của Monad, MegaETH và Pharos, chúng tôi cũng quan sát thấy rằng có một số dự án trên thị trường khám phá lộ trình ứng dụng của tăng tốc GPU trong điện toán song song EVM, như một bổ sung quan trọng và thử nghiệm tiên tiến cho hệ sinh thái song song EVM. Trong số đó, Reddio và GatlingX là hai hướng tiêu biểu:
- Reddio là một nền tảng hiệu suất cao kết hợp kiến trúc thực thi song song zkRollup và GPU, và cốt lõi của nó nằm ở việc xây dựng lại quy trình thực thi EVM và thực hiện song song gốc của lớp thực thi thông qua lập lịch đa luồng, lưu trữ trạng thái không đồng bộ và thực thi các lô giao dịch được tăng tốc bởi GPU. Độ chi tiết song song ở cấp độ giao dịch + cấp độ hoạt động (opcode thực thi đa luồng). Nó được thiết kế để giới thiệu thực thi hàng loạt đa luồng, tải trạng thái không đồng bộ và logic giao dịch xử lý song song GPU (EVM song song tương thích CUDA). Giống như Monad / MegaETH, Reddio cũng tập trung vào xử lý song song ở lớp thực thi, với sự khác biệt là công cụ thực thi được xây dựng lại thông qua kiến trúc song song GPU, được thiết kế cho các tình huống thông lượng cao và tính toán chuyên sâu như suy luận AI. GatlingX,
- tự gọi mình là "GPU-EVM", đề xuất một kiến trúc triệt để hơn nhằm cố gắng di chuyển mô hình "thực thi nối tiếp cấp lệnh" của các máy ảo EVM truyền thống sang môi trường thời gian chạy song song GPU. Cơ chế cốt lõi là tự động biên dịch mã byte EVM thành các tác vụ song song CUDA và thực hiện luồng lệnh thông qua đa lõi GPU, để phá vỡ nút cổ chai tuần tự của EVM ở mức thấp nhất. Độ chi tiết song song thuộc về Instruction-Level Parallelism (ILP). So với độ chi tiế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 về đường dẫn tối ưu hóa cấp lệnh, gần với quá trình tái cấu trúc cơ bản của công cụ máy ảo. Nó hiện đang trong giai đoạn khái niệm, với một sách trắng và bản phác thảo kiến trúc đã được xuất bản, và chưa có SDK hoặc mainnet nào.
Artela đề xuất một khái niệm thiết kế song song, khác biệt. Với sự ra đời của máy ảo WebAssembly (WASM) kiến trúc EVM++, các nhà phát triển được phép tự động thêm và thực thi các tiện ích mở rộng trên chuỗi bằng cách sử dụng mô hình lập trình Aspect trong khi vẫn duy trì khả năng tương thích EVM. Nó sử dụng độ chi tiết của lệnh gọi hợp đồng (Chức năng / Mở rộng) làm đơn vị song song tối thiểu và hỗ trợ việc tiêm các mô-đun Mở rộng (tương tự như "phần mềm trung gian có thể cắm được") khi hợp đồng EVM đang chạy, để đạt được sự tách rời logic, gọi không đồng bộ và thực thi song song cấp mô-đun. Chú ý nhiều hơn đến khả năng kết hợp và kiến trúc mô-đun của lớp thực thi. Khái niệm này cung cấp những ý tưởng mới cho các ứng dụng đa mô-đun phức tạp trong tương lai.
3. Chuỗi kiến trúc song song gốc: Mô hình thực thi EVM của Ethereum, bản thể thực thi của máy ảo được tái tạo
,đã áp dụng kiến trúc đơn luồng "lệnh giao dịch đầy đủ + khớp lệnh nối tiếp" kể từ khi bắt đầu thiết kế, nhằm đảm bảo tính chắc chắn và nhất quán của các thay đổi trạng thái cho tất cả các nút trong mạng. Tuy nhiên, kiến trúc này có một nút thắt cổ chai tự nhiên về hiệu suất, hạn chế thông lượng hệ thống và khả năng mở rộng. Ngược lại, các chuỗi kiến trúc điện toán song song gốc như Solana (SVM), MoveVM (Sui, Aptos) và Sei v2 được xây dựng trên Cosmos SDK được điều chỉnh để thực thi song song từ thiết kế cơ bản và có những ưu điểm sau:
- Tách các mô hình trạng thái tự nhiên: Solana sử dụng cơ chế khai báo khóa tài khoản, MoveVM giới thiệu mô hình sở hữu đối tượng và Sei v2 dựa trên phân loại loại giao dịch. Phán đoán xung đột tĩnh được thực hiện và lập lịch đồng thời cấp giao dịch được hỗ trợ.
- Máy ảo được tối ưu hóa cho tính đồng thời: Công cụ Sealevel của Solana hỗ trợ thực thi đa luồng; MoveVM có thể thực hiện phân tích biểu đồ đồng thời tĩnh; Sei v2 tích hợp công cụ khớp đa luồng với mô-đun VM song song.
Tất nhiên, loại chuỗi song song bản địa này cũng phải đối mặt với thách thức về khả năng tương thích sinh thái. Các kiến trúc không phải EVM thường yêu cầu các ngôn ngữ phát triển mới (chẳng hạn như Move và Rust) và chuỗi công cụ, có chi phí di chuyển nhất định cho các nhà phát triển. Ngoài ra, các nhà phát triển cần nắm vững một loạt các 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 các yêu cầu cao hơn để hiểu ngưỡng và mô hình phát triển.
3.1 Nguyên lý động cơ song song Sealevel của Solana và SVM
Mô hình thực thi Sealevel của Solana là cơ chế lập lịch song song tài khoản, là công cụ cốt lõi được Solana sử dụng để thực hiện việc thực hiện các giao dịch song song trong chuỗi và đạt được tính đồng thời hiệu suất cao ở cấp độ hợp đồng thông minh thông qua cơ chế "khai báo tài khoản + lập lịch tĩnh + thực hiện đa luồng". Sealevel là mô hình thực thi đầu tiên trong lĩnh vực blockchain triển khai thành công lập lịch đồng thời nội chuỗi trong môi trường sản xuất và ý tưởng kiến trúc của nó đã ảnh hưởng đến nhiều dự án điện toán song song tiếp theo và là mô hình tham chiếu cho thiết kế song song Layer 1 hiệu suất cao.
Cơ chế cốt lõi:
1. Danh sách truy cập tài khoản rõ ràng: Mỗi giao dịch phải khai báo tài khoản liên quan (đọc/ghi) khi gửi và hệ thống sẽ 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 không có giao điểm giữa các nhóm tài khoản được truy cập bởi hai giao dịch→ chúng có thể được thực hiện song song;
- Có một xung đột→ thực hiện nối tiếp theo thứ tự phụ thuộc;
- Bộ lập lịch phân bổ các giao dịch cho các luồng khác nhau dựa trên biểu đồ phụ thuộc.
3. Ngữ cảnh gọi chương trình: Mỗi cuộc gọi hợp đồng chạy trong một ngữ cảnh biệt lập mà không có ngăn xếp chia sẻ để tránh nhiễu cuộc gọi chéo.
Sealevel là công cụ lập lịch thực thi song song của Solana, trong khi SVM là một 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). Cùng với nhau, chúng tạo thành nền tảng kỹ thuật của 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 các máy ảo Solana lên các chuỗi mô-đun như Ethereum L2 hoặc Celestia, tận dụng công cụ thực thi song song của Solana làm lớp thực thi rollup. Eclipse là một trong những dự án đầu tiên đề xuất tách lớp thực thi Solana (Sealevel + SVM) khỏi mainnet Solana và di chuyển nó sang kiến trúc mô-đun và đầu ra mô-đun của "mô hình thực thi siêu đồng thời" của Solana là Execution Layer-as-a-Service, vì vậy Eclipse cũng thuộc thể loại điện toán song song.
Tuyến đường của Neon thì khác, nó giới thiệu EVM để hoạt động trong môi trường SVM / Sealevel. Xây dựng một lớp runtime tương thích với EVM, các nhà phát triển có thể sử dụng Solidity để phát triển hợp đồng và chạy trong môi trường SVM, nhưng việc thực hiện lịch trình sử dụng SVM + Sealeve. Neon nghiêng nhiều hơn về danh mục Modular Blockchain hơn là đổi mới điện toán song song.
Nói chung, Solana và SVM dựa vào công cụ thực thi Sealevel và triết lý lập lịch dựa trên hệ điều hành của Solana tương tự như bộ lập lịch hạt nhân, nhanh nhưng tương đối không linh hoạt. Nó là một chuỗi công khai điện toán song song, hiệu suất cao gốc.
3.2 Kiến trúc MoveVM: Tài nguyên và đối tượng MoveVM
là một máy ảo hợp đồng thông minh được thiết kế để bảo mật tài nguyên on-chain và thực thi song song, và ngôn ngữ cốt lõi của nó, Move, ban đầu được phát triển bởi Meta (trước đây là Facebook) cho dự án Libra, nhấn mạnh khái niệm "tài nguyên là đối tượng" và tất cả các trạng thái on-chain tồn tại dưới dạng đối tượng, với quyền sở hữu và vòng đời rõ ràng. Điều này cho phép MoveVM phân tích liệu có xung đột trạng thái giữa các giao dịch trong thời gian biên dịch hay không và thực hiện lập lịch song song tĩnh cấp đối tượng, được sử dụng rộng rãi trong các chuỗi công khai song song gốc như Sui và Aptos.
Mô hìnhsở hữu đối tượng của SuiKhả
năng tính toán song song của Sui bắt nguồn từ cách tiếp cận độc đáo của nó đối với mô hình hóa trạng thái và phân tích tĩnh cấp ngôn ngữ. Không giống như các 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 lấy đối tượng làm trung tâm dựa trên "đối tượng", hoạt động với hệ thống kiểu tuyến tính của MoveVM để làm cho lập lịch song song trở thành một quá trình xác định có thể được hoàn thành tại thời điểm biên dịch.
- Mô hình đối tượng là nền tảng của kiến trúc song song của Sui. Sui trừu tượng hóa tất cả các trạng thái trên chuỗi thành các đối tượng riêng biệt, mỗi đối tượng có một 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. Các đối tượng này không chia sẻ trạng thái với nhau và vốn bị cô lập. Hợp đồng phải khai báo rõ ràng tập hợp các đối tượng liên quan khi nó được gọi, tránh vấn đề ghép nối trạng thái của "cây trạng thái toàn cầu" on-chain truyền thống. Thiết kế này chia trạng thái on-chain thành nhiều đơn vị độc lập, làm cho việc thực hiện đồng thời trở thành tiền đề lập lịch khả thi về mặt cấu trúc. Phân
- tích quyền sở hữu tĩnh là một cơ chế phân tích thời gian biên dịch được thực hiện với sự hỗ trợ của hệ thống kiểu tuyến tính của ngôn ngữ Move. Nó cho phép hệ thống lên lịch các giao dịch được thực hiện song song bằng cách suy ra giao dịch nào không có xung đột trạng thái thông qua quyền sở hữu đối tượng trước khi chúng được thực thi. So với khả năng phát hiện xung đột và khôi phục của thời gian chạy truyền thống, cơ chế phân tích tĩnh của Sui giúp giảm đáng kể độ phức tạp của lập lịch đồng thời cải thiện hiệu quả thực thi, đây là chìa khóa để đạt được thông lượng cao và khả năng xử lý song song xác định.
Sui phân chia không gian trạng thái trên cơ sở từng đối tượng, kết hợp với 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 với chi phí thấp, không cần khôi phục. So với việc thực thi nối tiếp hoặc phát hiện thời gian chạy của các chuỗi truyền thống, Sui đã đạt được những cải tiến đáng kể về hiệu quả thực thi, tính xác định hệ thống và sử dụng tài nguyên.
Cơ chếthực thi Block-STM của AptosAptos
là một blockchain Layer1 hiệu suất cao dựa trên ngôn ngữ Move và khả năng thực thi song song của nó chủ yếu bắt nguồn từ khung Block-STM (Bộ nhớ giao dịch phần mềm cấp khối) tự phát triển. Không giống như chiến lược "song song tĩnh tại thời điểm biên dịch" của Sui, Block-STM thuộc cơ chế lập lịch động "đồng thời lạc quan trong thời gian chạy + khôi phục xung đột", phù hợp để xử lý các tập hợp giao dịch có phụ thuộc phức tạp.
Block-STM chia việc thực hiện giao dịch của một khối thành ba giai đoạn:
- Thực thi đầu cơ: Tất cả các giao dịch đều không có xung đột theo mặc định trước khi thực hiện và hệ thống lên lịch giao dịch song song với nhiều luồng để cố gắng thực hiện đồng thời và ghi lại trạng thái tài khoản (tập đọc/ghi) được truy cập bởi chúng.
- Giai đoạn xác thực: Hệ thống xác minh kết quả thực thi: nếu có xung đột đọc-ghi giữa hai giao dịch (ví dụ: Tx1 đọc trạng thái được ghi bởi Tx2), một trong số chúng sẽ được khôi phục.
- Giai đoạn thử lại: Các giao dịch xung đột sẽ được lên lịch lại cho đến khi các phụ thuộc của chúng được giải quyết và cuối cùng tất cả các giao dịch tạo thành một trình tự gửi trạng thái hợp lệ, xác định.
Block-STM là một mô hình thực thi động của "song song lạc quan + khôi phục và thử lại", phù hợp với các kịch bản xử lý hàng loạt giao dịch trên chuỗi chuyên sâu và phức tạp về mặt logic, đồng thời là lõi tính toán song song để Aptos xây dựng một chuỗi công khai có tính linh hoạt cao và thông lượng cao.
Solana
là một trường lập lịch trình kỹ thuật, giống như một "nhân hệ điều hành", phù hợp với ranh giới trạng thái rõ ràng, giao dịch tần suất cao có thể kiểm soát được, là phong cách kỹ sư phần cứng, để chạy chuỗi giống như phần cứng (Hardware-grade parallel execution); Aptos là một hệ thống chịu lỗi, giống như một "công cụ đồng thời cơ sở dữ liệu", phù hợp với các hệ thống hợp đồng có khớp nối trạng thái mạnh và chuỗi cuộc gọi phức tạp. Aptos và Sui giống như các kỹ sư ngôn ngữ lập trình, và bảo mật tài nguyên cấp phần mềm đại diện cho lộ trình triển khai kỹ thuật của điện toán song song Web3 theo các triết lý khác nhau.
3.3 Cosmos SDK Parallel Scaling
Sei V2 là một chuỗi công khai giao dịch hiệu suất cao được xây dựng dựa trên Cosmos SDK và khả năng song song của nó chủ yếu được phản ánh ở hai khía cạnh: công cụ đối sánh đa luồng (Parallel Matching Engine) và tối ưu hóa thực thi song song của lớp máy ảo, được thiết kế để phục vụ các tình huống giao dịch trên chuỗi tần suất cao và độ trễ thấp, chẳng hạn như sổ lệnh DEX, hạ tầng sàn giao dịch trên chuỗi, v.v.
Cơ chế song song cốt lõi:
- Công cụ khớp song song: SEI V2 giới thiệu một đường dẫn thực hiện đa luồng vào logic khớp lệnh, tách sổ lệnh chờ và logic khớp ở cấp độ luồng, để các tác vụ khớp giữa nhiều cặp giao dịch có thể được xử lý song song và tránh tắc nghẽn đơn luồng.
- Tối ưu hóa đồng thời cấp máy ảo: Sei V2 xây dựng môi trường thời gian chạy CosmWasm với khả năng thực thi đồng thời, cho phép một số lệnh gọi hợp đồng chạy song song mà không có xung đột trạng thái và hợp tác với cơ chế phân loại giao dịch để đạt được kiểm soát thông lượng cao hơn.
- Lập lịch trình lớp thực thi và đồng thuận song song: Cơ chế đồng thuận được gọi là "Twin-Turbo" được giới thiệu để tăng cường thông lượng và tách rời giữa lớp đồng thuận và lớp thực thi, đồng thời cải thiện hiệu quả xử lý khối tổng thể.
3.4 UTXO Model Reformer Fuel Fuel
là một lớp thực thi hiệu suất cao được thiết kế dựa trên kiến trúc mô-đun của Ethereum và cơ chế song song cốt lõi của nó có nguồn gốc từ mô hình UTXO được cải tiến (Đầu ra giao dịch chưa sử dụng). Không giống như mô hình tài khoản của Ethereum, Fuel sử dụng cấu trúc UTXO để đại diện cho tài sản và trạng thái, vốn đã bị cô lập theo trạng thái, giúp dễ dàng xác định giao dịch nào có thể được thực hiện song song một cách 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 (tương tự như Rust), kết hợp với các công cụ phân tích tĩnh, để xác định xung đột đầu vào trước khi các giao dịch được thực hiện, để đạt được lập lịch song song cấp giao dịch hiệu quả và an toàn. Đây là một lớp thực thi thay thế EVM cân bằng giữa hiệu suất và mô-đun.
4. Mô hình tác nhân: Mô hình mới về thực thi đồng thời
của các tác nhân Mô hình tác nhân là một mô hình thực thi song song dựa trên tác nhân hoặc quy trình, khác với tính toán đồng bộ truyền thống của trạng thái toàn cục trên chuỗi (Solana / Sui / Monad và các kịch bản "tính toán song song trên chuỗi" khác), nhấn mạnh rằng mỗi tác nhân có một trạng thái và hành vi độc lập, đồng thời giao tiếp và lên lịch thông qua các thông báo không đồng bộ. Theo kiến trúc này, hệ thống on-chain có thể được chạy đồng thời bởi một số lượng lớn các quy trình được tách rời với nhau, đồng thời có khả năng mở rộng mạnh mẽ và khả năng chịu lỗi không đồng bộ. Các dự án đại diện bao gồm AO (Arweave AO), ICP (Internet Computer) và Cartesi, đang thúc đẩy sự phát triển của blockchain từ một công cụ thực thi thành một "hệ điều hành trên chuỗi", cung cấp cơ sở hạ tầng gốc cho các tác nhân AI, tương tác đa tác vụ và điều phối logic phức tạp.
Trong khi thiết kế của Mô hình Actor tương tự như phân mảnh về các đặc điểm bề ngoài (ví dụ: song song, cách ly trạng thái và xử lý không đồng bộ), cả hai về cơ bản đại diện cho các lộ trình 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 không đồng bộ đa quy trình", trong đó mỗi tác nhân chạy độc lập, duy trì trạng thái độc lập và tương tác theo cách điều khiển thông điệp. Mặt khác, Sharding là một cơ chế "phân mảnh ngang của trạng thái và sự đồng thuận", chia toàn bộ blockchain thành nhiều hệ thống con (phân đoạn) xử lý các giao dịch độc lập. Actor Model giống như một "hệ điều hành tác nhân phân tán" trong thế giới Web3, trong khi sharding là một giải pháp mở rộng cấu trúc cho khả năng xử lý giao dịch trên chuỗi. Cả hai đều đạt được tính song song, nhưng có điểm khởi đầu, mục tiêu và kiến trúc thực thi khác nhau.
4.1 AO (Arweave), một máy tính siêu song song trên lớp lưu trữAO
là một nền tảng điện toán phi tập trung chạy trên lớp lưu trữ vĩnh viễn Arweave, với mục tiêu cốt lõi là xây dựng một hệ điều hành on-chain hỗ trợ hoạt động của các tác nhân không đồng bộ quy mô lớn.
Các tính năng kiến trúc cốt lõi:
- Kiến trúc quy trình: Mỗi tác nhân được gọi là một quy trình, với trạng thái độc lập, bộ lập lịch độc lập và logic thực thi;
- Không có cấu trúc blockchain: AO không phải là một chuỗi, mà là một lớp lưu trữ phi tập trung + công cụ thực thi theo hướng tin nhắn đa tác nhân dựa trên Arweave;
- Hệ thống lập lịch tin nhắn không đồng bộ: Các quy trình giao tiếp với nhau thông qua tin nhắn, áp dụng mô hình hoạt động không đồng bộ không khóa và hỗ trợ mở rộng đồng thời một cách tự nhiên.
- Lưu trữ trạng thái vĩnh viễn: Tất cả các trạng thái tác nhân, bản ghi tin nhắn và hướng dẫn được ghi lại vĩnh viễn trên Arweave, đảm bảo khả năng kiểm tra đầy đủ và tính minh bạch phi tập trung.
- Agent-native: Nó phù hợp để triển khai các tác vụ nhiều bước phức tạp (chẳng hạn như tác nhân AI, bộ điều khiển giao thức DePIN, bộ điều phối tác vụ tự động, v.v.) và có thể xây dựng "bộ đồng xử lý AI trên chuỗi".
AO đi theo con đường cuối cùng là "agent native + trình điều khiển lưu trữ + kiến trúc không chuỗi", nhấn mạnh tính linh hoạt và tách rời mô-đun, đồng thời là một "khung microkernel trên chuỗi được xây dựng trên lớp lưu trữ", với ranh giới hệ thống được thu hẹp một cách có chủ ý, nhấn mạnh tính toán nhẹ + cấu trúc điều khiển có thể kết hợp.
4.2 ICP (Internet Computer), một nền tảng lưu trữ Web3 full-stackICP
là một nền tảng ứng dụng on-chain full-stack gốc Web3 do DFINITY ra mắt, với mục tiêu mở rộng sức mạnh tính toán on-chain đến trải nghiệm giống như Web2 và hỗ trợ lưu trữ dịch vụ hoàn chỉnh, liên kết tên miền và kiến trúc serverless.
Các tính năng kiến trúc cốt lõi:
- Kiến trúc Canister (container làm agent): Mỗi canister là một agent chạy trên Wasm VM với trạng thái, mã độc lập và khả năng lập lịch không đồng bộ;
- Hệ thống đồng thuận phân tán mạng con (Subnet): Toàn bộ mạng bao gồm nhiều mạng con, mỗi mạng con duy trì một tập hợp các hộp và đạt được sự đồng thuận thông qua cơ chế chữ ký BLS.
- Mô hình gọi không đồng bộ: Canister giao tiếp với Canister thông qua các thông báo không đồng bộ, hỗ trợ thực thi không chặn và có tính song song tự nhiên.
- Lưu trữ web on-chain: Nó hỗ trợ các hợp đồng thông minh để lưu trữ trực tiếp các trang front-end, ánh xạ DNS gốc và là nền tảng blockchain đầu tiên hỗ trợ trình duyệt truy cập trực tiếp vào dApps;
- Hệ thống có đầy đủ các chức năng: Nó có các API hệ thống như nâng cấp nóng trên chuỗi, xác thực danh tính, tính ngẫu nhiên phân tán và hẹn giờ, phù hợp với việc triển khai dịch vụ on-chain phức tạp.
ICP chọn mô hình hệ điều hành của nền tảng nặng, đóng gói tích hợp và kiểm soát nền tảng mạnh mẽ, đồng thời có "hệ điều hành blockchain" tích hợp sự đồng thuận, thực thi, lưu trữ và truy cập, nhấn mạnh khả năng lưu trữ dịch vụ hoàn chỉnh và mở rộng ranh giới hệ thống thành nền tảng lưu trữ Web3 toàn diện.
Ngoài ra, các dự án điện toán song song của các mô hình Actor Model khác có thể được tham khảo bảng sau:
5. Tóm tắt và triển vọngDựa
trên sự khác biệt giữa kiến trúc máy ảo và hệ thống ngôn ngữ, các giải pháp điện toán song song blockchain có thể được chia thành hai loại: chuỗi tăng cường song song EVM và chuỗi kiến trúc song song gốc (non-EVM).
Trên cơ sở giữ được khả năng tương thích của hệ sinh thái EVM/Solidity, hệ sinh thái trước đây đạt được thông lượng cao hơn và khả năng xử lý song song thông qua tối ưu hóa chuyên sâu lớp thực thi, phù hợp với các tình huống muốn kế thừa tài sản Ethereum và các công cụ phát triển đồng thời đạt được những đột phá về hiệu suất. Các dự án tiêu biểu bao gồm:
- Monad: Triển khai mô hình thực thi song song lạc quan tương thích với EVM thông qua ghi trì hoãn và phát hiện xung đột thời gian chạy, xây dựng biểu đồ phụ thuộc và lên lịch thực thi sau khi hoàn thành sự đồng thuận.
- MegaETH: Trừu tượng hóa từng tài khoản/hợp đồng thành một máy ảo nhỏ độc lập và triển khai lập lịch song song cấp tài khoản được tách rời cao dựa trên nhắn tin không đồng bộ và biểu đồ phụ thuộc vào trạng thái.
- Pharos: Xây dựng kiến trúc lưới rollup để đạt được xử lý song song cấp hệ thống trên các quy trình thông qua các đường ống không đồng bộ và mô-đun SPN.
- Reddio: Sử dụng kiến trúc zkRollup + GPU để tăng tốc quá trình xác minh ngoài chuỗi của zkEVM thông qua việc tạo SNARK hàng loạt và cải thiện thông lượng xác minh.
Sau này hoàn toàn loại bỏ những hạn chế về khả năng tương thích của Ethereum và thiết kế lại mô hình thực thi từ máy ảo, mô hình trạng thái và cơ chế lập lịch để đạt được tính đồng thời hiệu suất cao gốc. Các lớp con điển hình bao gồm:
- Solana (SVM): mô hình thực thi song song cấp tài khoản dựa trên yêu cầu truy cập tài khoản và lập lịch biểu đồ xung đột tĩnh;
- Sui / Aptos (hệ thống MoveVM): Dựa trên mô hình đối tượng tài nguyên và hệ thống kiểu, nó hỗ trợ phân tích tĩnh tại thời điểm biên dịch và thực hiện tính song song cấp đối tượng.
- Sei V2 (Cosmos SDK route): giới thiệu công cụ khớp đa luồng và tối ưu hóa đồng thời máy ảo trong kiến trúc Cosmos, phù hợp với các ứng dụng giao dịch tần suất cao.
- Nhiên liệu (kiến trúc UTXO + Sway): Song song cấp giao dịch thông qua phân tích tĩnh của bộ đầu vào UTXO, kết hợp lớp thực thi mô-đun với ngôn ngữ hợp đồng thông minh tùy chỉnh Sway;
Ngoài ra, là một hệ thống song song tổng quát hơn, Mô hình Actor xây dựng mô hình thực thi trên chuỗi của "hoạt động độc lập đa tác nhân + cộng tác theo tin nhắn" thông qua cơ chế lập lịch quy trình không đồng bộ dựa trên Wasm hoặc máy ảo tùy chỉnh. Các dự án tiêu biểu bao gồm:
- AO (Arweave AO): Xây dựng hệ thống microkernel không đồng bộ on-chain dựa trên runtime agent điều khiển lưu trữ liên tục;
- ICP (Internet Computer): sử dụng tác nhân container (Canister) làm đơn vị nhỏ nhất để thực hiện không đồng bộ và có khả năng mở rộng cao thông qua điều phối mạng con.
- Cartesi: Giới thiệu hệ điều hành Linux như một môi trường điện toán ngoài chuỗi để cung cấp đường dẫn xác minh trên chuỗi cho các kết quả tính toán đáng tin cậy, phù hợp với các tình huống ứng dụng phức tạp hoặc sử dụng nhiều tài nguyên.
Dựa trên logic trên, chúng ta có thể tóm tắt sơ đồ chuỗi công khai điện toán song song chính thống hiện nay thành một cấu trúc phân loại như thể hiện trong hình sau:
Từ góc độ mở rộng rộng hơn, sharding và rollup (L2) tập trung vào việc mở rộng theo chiều ngang thông qua phân mảnh trạng thái hoặc thực thi ngoài chuỗi, trong khi các chuỗi điện toán song song (ví dụ: Monad, Sui, Solana) và các hệ thống hướng tác nhân (ví dụ: AO, ICP) trực tiếp xây dựng lại mô hình thực thi và đạt được tính song song gốc trong chuỗi hoặc tại lớp hệ thống. Trước đây cải thiện thông lượng nội 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, v.v.; Sau này lấy quy trình/tác nhân làm đơn vị cơ bản và áp dụng các chế độ thực thi không đồng bộ và điều khiển thông điệp để đạt được hoạt động đồng thời nhiều tác nhân. Ngược lại, sharding và rollup giống như "chia tải thành nhiều chuỗi" hoặc "thuê ngoài chuỗi", trong khi mô hình chuỗi song song và actor đang "giải phóng tiềm năng hiệu suất từ chính công cụ thực thi", phản ánh sự phát triển kiến trúc kỹ lưỡng hơn.
Điện toán song song so với Sharding Architecture so với Rollup Scaling so sánh đường dẫn mở rộng theo định hướng tác nhân
Cần chỉ ra rằng hầu hết các chuỗi kiến trúc song song gốc đã bước vào giai đoạn ra mắt mainnet, mặc dù hệ sinh thái nhà phát triển tổng thể vẫn khó so sánh với hệ thống Solidity của hệ thống EVM, nhưng các dự án được đại diện bởi Solana và Sui, với kiến trúc thực thi hiệu suất cao và sự thịnh vượng dần dần của các ứng dụng sinh thái, đã trở thành chuỗi công khai cốt lõi mà thị trường rất chú ý.
Ngược lại, mặc dù hệ sinh thái Ethereum Rollup (L2) đã bước vào giai đoạn "10.000 chuỗi cùng một lúc" hoặc thậm chí là "dư dung", nhưng chuỗi tăng cường song song EVM chính hiện nay nhìn chung vẫn đang trong giai đoạn testnet và chưa được xác minh bởi môi trường mainnet thực tế, và khả năng mở rộng quy mô và độ ổn định hệ thống của nó vẫn cần được kiểm tra thêm. Vẫn còn phải xem liệu các dự án này có thể cải thiện đáng kể hiệu suất EVM và thúc đẩy bước nhảy vọt về sinh thái mà không phải hy sinh khả năng tương thích hay chúng có thể phân biệt hơn nữa tính thanh khoản và tài nguyên phát triển của Ethereum hay không.