"Tam giác Blockchain" tiết lộ những đánh đổi thiết yếu trong thiết kế hệ thống blockchain, cụ thể là khó khăn trong việc đạt được "bảo mật tối ưu, sự tham gia toàn cầu và xử lý nhanh" cùng một lúc. Về chủ đề vĩnh cửu của "khả năng mở rộng", các giải pháp mở rộng blockchain chính thống hiện có trên thị trường có thể được phân loại theo các mô hình, bao gồm:

• Thực hiện khả năng mở rộng nâng cao: Cải thiện khả năng thực thi ngay tại chỗ, chẳng hạn như song song, GPU và đa lõi.
• Mở rộng tách biệt trạng thái: phân vùng ngang của trạng thái / Shard, chẳng hạn như sharding, UTXO, đa subnet
• Mở rộng thuê ngoài ngoài chuỗi: thực hiện bên ngoài chuỗi, chẳng hạn như Rollup, Coprocessor, DA
• Mở rộng cấu trúc tách rời: kiến trúc mô-đun, hoạt động hợp tác, chẳng hạn như chuỗi mô-đun, bộ phân loại chia sẻ, Rollup Mesh.
• Mở rộng đồng thời không đồng bộ: Mô hình diễn viên, cách ly quy trình, dựa trên tin nhắn, chẳng hạn như các tác nhân, chuỗi không đồng bộ đa luồng.

Các giải pháp mở rộng 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 chứng minh zk, kiến trúc không trạng thái, v.v., bao trùm nhiều lớp thực thi, trạng thái, dữ liệu và cấu trúc, hình thành một hệ thống mở rộng hoàn chỉnh "hợp tác đa lớp và kết hợp mô-đun". Bài viết này tập trung vào phương pháp mở rộng chính thống dựa trên tính toán song song.

Song 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 của nó có thể được chia thành năm loại, mỗi loại đại diện cho các mục tiêu hiệu suất khác nhau, các mô hình phát triển và triết lý kiến trúc khác nhau. Độ phân giải của sự song song trở nên tinh vi hơn, cường độ song song tăng lên, độ phức tạp của việc lập lịch tăng lên, và độ phức tạp lập trình cùng với khó khăn trong việc triển khai cũng tăng lên.

• Cấp tài khoản: Đại diện cho dự án Solana
• Tính song song cấp đối tượng: đại diện cho dự án Sui
• Cấp độ giao dịch: Đại diện cho các dự án Monad, Aptos
• Cấp cuộc gọi / MicroVM: Đại diện cho dự án MegaETH
• Song song cấp độ chỉ thị: Đại diện cho dự án GatlingX

Mô hình đồng thời bất đồng bộ ngoài chuỗi, được đại diện bởi hệ thống Actor (Mô hình Đại lý / Actor), thuộc về một mô hình tính toán song song khác. Là một hệ thống nhắn tin chéo chuỗi / bất đồng bộ (mô hình đồng bộ không chặn), mỗi Đại lý hoạt động như một "quá trình đại lý" độc lập đang chạy, nhắn tin một cách bất đồng bộ theo cách song song, dựa trên sự kiện, và không cần lập lịch đồng bộ. Các dự án nổi bật bao gồm AO, ICP, Cartesi, v.v.

Các giải pháp mở rộng quy mô Rollup hoặc sharding nổi tiếng thuộc về các cơ chế đồng thời cấp hệ thống và không thuộc về tính toán song song trên chuỗi. Chúng đạt được khả năng mở rộng bằng cách "chạy nhiều chuỗi/miền thực thi song song" thay vì tăng cường tính song song trong một khối/máy ảo duy nhất. Những giải pháp mở rộng 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 chúng cho một phân tích so sánh các khái niệm kiến trúc.

2. Chuỗi Tăng Cường Song Song Dựa Trên EVM: Phá Vỡ Ranh Giới Hiệu Suất Thông Qua Tính Tương Thích

Kiến trúc xử lý tuần tự của Ethereum đã phát triển trải qua nhiều vòng thử nghiệm mở rộng, bao gồm sharding, Rollup và kiến trúc mô-đun. Tuy nhiên, nút thắt về thông lượng của lớp thực thi vẫn chưa được phá vỡ một cách căn bản. Trong khi đó, EVM và Solidity vẫn là nền tảng hợp đồng thông minh thân thiện với nhà phát triển và có tiềm năng sinh thái mạnh mẽ nhất hiện nay. Do đó, các chuỗi tăng cường song song dựa trên EVM đang trở thành một hướng quan trọng cho vòng tiến hóa khả năng mở rộng tiếp theo, cân bằng giữa khả năng tương thích sinh thái và cải tiến hiệu suất thực thi. Monad và MegaETH là những dự án tiêu biểu nhất trong hướng này, lần lượt xây dựng các kiến trúc xử lý song song EVM nhằm vào các kịch bản có độ đồng thời cao và thông lượng cao, bắt đầu từ thực thi trì hoãn và phân tách trạng thái.

Phân tích cơ chế tính toán song song của Monad

Monad là một blockchain Layer 1 hiệu suất cao được thiết kế lại cho Ethereum Virtual Machine (EVM), dựa trên khái niệm song song cơ bản của pipelining, với việc thực thi không đồng bộ ở lớp đồng thuận và thực thi song song lạc quan ở lớp thực thi. Ngoài ra, Monad giới thiệu một giao thức BFT hiệu suất cao (MonadBFT) và một hệ thống cơ sở dữ liệu chuyên dụng (MonadDB) tại các lớp đồng thuận và lưu trữ, đạt được tối ưu hóa toàn diện.

Pipelining: Cơ chế thực thi song song đa giai đoạn
Pipelining là khái niệm cơ bản của việc thực thi song song Monad. Ý tưởng cốt lõi của nó là phân chia quá trình thực thi của blockchain thành nhiều giai đoạn độc lập và xử lý các giai đoạn này song song, tạo thành kiến trúc ố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, cuối cùng cải thiện 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 được đồng thuận (Consensus), thực thi giao dịch (Execution) và cam kết khối (Commit).

Thực thi bất đồng bộ: Đồng thuận - Tách biệt bất đồng bộ
Trong các blockchain truyền thống, đồng thuận và thực thi giao dịch thường là các quá trình đồng bộ, và mô hình tuần tự này hạn chế nghiêm trọng khả năng mở rộng hiệu suất. Monad đạt được 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ộ." Điều này giảm đáng kể thời gian khối và độ trễ xác nhận, làm cho hệ thống trở nên linh hoạt hơn, quy trình xử lý trở nên chi tiết hơn và việc sử dụng tài nguyên cao hơn.

Thiết kế cốt lõi:

• Quá trình đồng thuận (tầng đồ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 (tầng thực thi) được kích hoạt không đồng bộ sau khi đạt được sự đồng thuận.
• Sau khi hoàn tất đồng thuận, ngay lập tức bắt đầu quá trình đồng thuận cho khối tiếp theo mà không cần chờ đợi việc thực thi kết thúc.

Thực Thi Song Song Lạc Quan
Ethereum truyền thống sử dụng mô hình tuần tự nghiêm ngặt cho việc thực thi giao dịch nhằm tránh xung đột trạng thái. Ngược lại, 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 hiện lạc quan tất cả các giao dịch song song, giả định rằng hầu hết các giao dịch không có xung đột trạng thái.
• Cùng lúc đó, chạy một "Trình phát hiện xung đột" để theo dõi xem các giao dịch có đang truy cập cùng một trạng thái (chẳng hạn như xung đột đọc/ghi) hay không.
• Nếu phát hiện xung đột, các giao dịch xung đột sẽ được tuần tự hóa và thực thi lại để đảm bảo tính chính xác của trạng thái.

Monad chọn một con đường tương thích: thực hiện ít thay đổi nhất có thể đối với quy tắc EVM, đạt được khả năng song song bằng cách hoãn ghi trạng thái và phát hiện xung đột một cách động trong quá trình thực thi, giống như một phiên bản hiệu suất của Ethereum. Sự trưởng thành của nó tạo điều kiện dễ dàng cho việc di chuyển hệ sinh thái EVM và phục vụ như một bộ tăng tốc song song trong thế giới EVM.

Phân tích cơ chế tính toán song song của MegaETH

Khác với vị trí L1 của Monad, MegaETH được định vị là một lớp thực thi song song hiệu suất cao mô-đun tương thích với EVM, có thể hoạt động như một chuỗi công khai L1 độc lập hoặc như một lớp tăng cường thực thi trên Ethereum hoặc như một thành phần mô-đun. Mục tiêu thiết kế cốt lõi của nó là phân lập và phân tích logic tài khoản, môi trường thực thi và trạng thái thành các đơn vị tối thiểu có thể lập lịch độc lập để đạt được khả năng thực thi đồng thời cao và phản hồi độ trễ thấp trên chuỗi. Những đổi mới chính mà MegaETH đề xuất là: Kiến trúc Micro-VM + DAG phụ thuộc trạng thái (Đồ thị không chu trình phụ thuộc trạng thái) và cơ chế đồng bộ mô-đun, cùng nhau xây dựng một hệ thống thực thi song song hướng tới "luồng trên chuỗi."

Kiến trúc Micro-VM: Tài khoản là một luồng
MegaETH giới thiệu mô hình thực thi "một máy ảo vi mô (Micro-VM) cho mỗi tài khoản", làm tách biệt môi trường thực thi và cung cấp đơn vị cách ly nhỏ nhất cho lập lịch song song. Các VM này giao tiếp thông qua tin nhắn bất đồng bộ thay vì các cuộc gọi đồng bộ, cho phép một số lượng lớn VM thực thi độc lập và lưu trữ độc lập, cho phép sự song song tự nhiên.

Đồ thị phụ thuộc trạng thái DAG: Một cơ chế lập lịch được điều khiển bởi các đồ thị phụ thuộc
MegaETH đã xây dựng một hệ thống lập lịch DAG dựa trên các 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ầu theo thời gian thực, mô hình hóa các tài khoản nào được sửa đổi và các tài khoản nào được đọc trong mỗi giao dịch như các phụ thuộc. Các giao dịch không xung đột có thể được thực hiện song song, trong khi các giao dịch có phụ thuộc sẽ được lập lịch theo thứ tự hoặc bị hoãn lại theo một chuỗi topo. Đồ thị phụ thuộc đảm bảo tính nhất quán của trạng thái và việc ghi không lặp lại trong quá trình thực hiện song song.

Thực thi bất đồng bộ và cơ chế gọi lại
MegaETH được xây dựng trên mô hình lập trình bất đồng bộ, tương tự như việc truyền tin bất đồng bộ của Mô hình Diễn viên, giải quyết các vấn đề của các cuộc gọi tuần tự truyền thống trong EVM. Các cuộc gọi hợp đồng là bất đồng bộ (thực thi không đệ quy), và khi gọi hợp đồng A -> B -> C, mỗi cuộc gọi được thực hiện một cách bất đồng bộ mà không bị chặn; ngăn xếp gọi được mở rộng thành một đồ thị cuộc gọi bất đồng bộ (Đồ thị cuộc gọi); xử lý giao dịch = duyệt qua đồ thị bất đồng bộ + giải quyế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 EVM truyền thống bằng cách triển khai bao bọc máy ảo vi mô trên cơ sở tài khoản, lập lịch giao dịch thông qua đồ thị phụ thuộc trạng thái và sử dụng cơ chế thông điệp bất đồng bộ thay vì ngăn xếp gọi đồng bộ. Đây là một nền tảng tính toán song song được thiết kế lại ở tất cả các chiều từ "cấu trúc tài khoản → kiến trúc lập lịch → luồng thực thi", cung cấp một phương pháp mới ở mức mô hình để xây dựng thế hệ hệ thống on-chain hiệu suất cao tiếp theo.

MegaETH đã chọn một con đường tái cấu trúc: hoàn toàn trừu tượng hóa các tài khoản và hợp đồng thành một VM độc lập, và phát hành tiềm năng song song cực kỳ cao thông qua lịch trình thực thi bất đồng bộ. Về 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, giống như một hệ điều hành phân tán siêu cấp dưới khái niệm Ethereum.

Các khái niệm thiết kế của Monad và MegaETH rất khác biệt so với sharding: sharding chia nhỏ blockchain theo chiều ngang thành nhiều chuỗi con độc lập (shards), với mỗi chuỗi con chịu trách nhiệm cho một phần giao dịch và trạng thái, phá vỡ những hạn chế của một chuỗi duy nhất để đạt được khả năng mở rộng ở tầng mạng; trong khi đó, Monad và MegaETH duy trì tính toàn vẹn của một chuỗi duy nhất và chỉ đạt được khả năng mở rộng theo chiều ngang ở tầng thực thi, tối ưu hóa hiệu suất thông qua việc thực thi song song cực kỳ trong chuỗi duy nhất. Hai hướng này đại diện cho hai hướng trong con đường khả năng mở rộng của blockchain: nâng cao theo chiều dọc và mở rộng theo chiều ngang.

Các dự án như Monad và MegaETH tập trung vào các con đường 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. Họ đạt được xử lý song song cấp giao dịch hoặc cấp tài khoản thông qua các kiến trúc Deferred Execution và Micro-VM. Pharos Network, với tư cách là một mạng blockchain L1 song song đầy đủ mô-đun, có một cơ chế tính toán song song cốt lõi được gọi là “Rollup Mesh.” Kiến trúc này hỗ trợ các môi trường máy ảo đa dạng (EVM và Wasm) thông qua sự hợp tác của mạng chính và các Mạng Xử lý Đặc biệt (SPNs), tích hợp các công nghệ tiên tiến như Bằng chứng Không biết (ZK) và Môi trường Thực thi Đáng tin cậy (TEE).

Phân tích cơ chế tính toán song song lưới Rollup:

• Chu trình phi tuyến tính đầy đủ: Pharos tách rời các giai đoạn khác nhau của một giao dịch (chẳng hạn như đồng thuận, thực thi, lưu trữ) và áp dụng cách tiếp cận xử lý không đồng bộ, cho phép mỗi giai đoạn tiến hành độc lập và song song, từ đó cải thiện hiệu quả xử lý tổng thể.
• Thực thi song song với hai máy ảo: Pharos hỗ trợ hai môi trường máy ảo, EVM và WASM, cho phép các nhà phát triển lựa chọn môi trường thực thi phù hợp dựa trên nhu cầu của họ. Kiến trúc máy ảo kép 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à các thành phần chính trong kiến trúc Pharos, tương tự như các mạng con mô-đun, được thiết kế đặc biệt để xử lý các loại tác vụ hoặc ứng dụng cụ thể. Thông qua SPNs, Pharos có thể đạt được phân bổ tài nguyên động và xử lý tác vụ song song, từ đó nâng cao khả năng mở rộng và hiệu suất của hệ thống.
• Cơ chế đồng thuận mô-đun & 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 (như PBFT, PoS, PoA) và đạt được việc chia sẻ an toàn và tích hợp tài nguyên giữa mainnet và SPNs thông qua giao thức Restaking.

Ngoài ra, Pharos đã tái cấu trúc mô hình thực thi từ động cơ lưu trữ cơ sở bằng cách sử dụng cây Merkle phiên bản đa, Mã hóa Delta, Địa chỉ phiên bản và công nghệ ADS Pushdown, ra mắt động cơ lưu trữ hiệu suất cao trên chuỗi khối gốc Pharos Store, đạt được thông lượng cao, độ trễ thấp và khả năng xử lý trên chuỗi mạnh mẽ có thể xác minh.

Tổng thể, 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ộ. Pharos hoạt động như một điều phối viên lập lịch cho sự song song giữa các Rollup, không phải như một bộ tối ưu hóa thực thi cho "song song trên chuỗi," mà thực hiện các nhiệm vụ thực thi tùy chỉnh khác nhau thông qua SPNs.

Ngoài kiến trúc thực thi song song của Monad, MegaETH và Pharos, chúng tôi cũng nhận thấy rằng có một số dự án trên thị trường đang khám phá các con đường ứng dụng của việc tăng tốc GPU trong tính toán song song EVM, điều này đóng vai trò 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 đại diện:

• Reddio là một nền tảng hiệu suất cao kết hợp giữa zkRollup và kiến trúc thực thi song song GPU. Cốt lõi của nó nằm ở việc tái cấu trúc quy trình thực thi EVM, đạt được sự song song gốc ở lớp thực thi thông qua lập lịch đa luồng, lưu trữ trạng thái bất đồng bộ và thực thi các lô giao dịch được tăng tốc bằng GPU. Nó thuộc mức độ song song cấp giao dịch + cấp hoạt động (thực thi đa luồng của các opcode). Thiết kế của nó giới thiệu việc thực thi lô đa luồng, tải trạng thái bất đồng bộ và xử lý song song GPU của logic giao dịch (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à tái cấu trúc động cơ thực thi thông qua kiến trúc song song GPU, được thiết kế đặc biệt cho các kịch bản có thông lượng cao và yêu cầu tính toán cao (như suy diễn AI). SDK đã được ra mắt, cung cấp một mô-đun thực thi có thể tích hợp.
• GatlingX tuyên bố là một "GPU-EVM" và đề xuất một kiến trúc cấp tiến hơn, cố gắng di chuyển mô hình "thực thi tuần tự theo cấp lệnh" của máy ảo EVM truyền thống sang môi trường thực thi song song dựa trên GPU. Cơ chế cốt lõi của nó liên quan đến việc biên dịch động mã bytecode EVM thành các tác vụ song song CUDA, thực thi các luồng lệnh thông qua nhiều lõi GPU, từ đó phá vỡ nút thắt tuần tự của EVM ở mức thấp nhất. Nó thuộc về độ mịn song song theo cấp lệnh (Instruction-Level Parallelism, ILP). So với độ mịn song song "theo giao dịch/cấp tài khoản" của Monad / MegaETH, cơ chế song song của GatlingX gần gũi hơn với các đường tối ưu hóa theo cấp lệnh, tương tự như việc tái cấu trúc cơ bản của động cơ máy ảo. Hiện tại, nó đang ở giai đoạn khái niệm, với một tài liệu trắng và bản phác thảo kiến trúc đã được phát hành, nhưng chưa có SDK hoặc mạng chính.

Artela đề xuất một khái niệm thiết kế song song khác biệt. Bằng cách giới thiệu kiến trúc EVM++ với một máy ảo WebAssembly (WASM), nó cho phép các nhà phát triển thêm và thực thi các phần mở rộng trên chuỗi một cách linh hoạt trong khi vẫn duy trì tính tương thích EVM, sử dụng mô hình lập trình Aspect. Nó lấy độ granularity của các cuộc gọi hợp đồng (Chức năng / Phần mở rộng) làm đơn vị song song tối thiểu, hỗ trợ việc tiêm các mô-đun Phần mở rộng (tương tự như "middleware có thể cắm vào") trong quá trình thực thi hợp đồng EVM, đạt được tách biệt logic, các cuộc gọi bất đồng bộ và thực thi song song ở cấp mô-đun. Nó tập trung nhiều hơn vào 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. Kiến trúc chuỗi song song gốc: Tái cấu trúc thực thể thực thi của VM

Mô hình thực thi EVM của Ethereum đã áp dụng kiến trúc đơn luồng "thứ tự giao dịch tổng thể + thực thi tuần tự" từ khi thiết kế, nhằm đảm bảo tính xác định và nhất quán của các thay đổi trạng thái trên tất cả các nút trong mạng. Tuy nhiên, kiến trúc này có những nút thắt hiệu suất tiềm ẩn 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 được xây dựng trên Cosmos SDK được thiết kế cho thực thi song song từ đầu, mang lại những lợi thế sau:

• Mô hình trạng thái tách biệt một cách tự nhiên: Solana áp dụng cơ chế tuyên bố khóa tài khoản, MoveVM giới thiệu mô hình sở hữu đối tượng, và Sei v2 phân loại dựa trên loại giao dịch để đạt được xác định xung đột tĩnh, hỗ trợ lập lịch đồng thời ở cấp giao dịch.
• Tối ưu hóa đồng thời máy ảo: Engine Sealevel của Solana hỗ trợ thực thi đa luồng một cách tự nhiên; MoveVM có thể thực hiện phân tích đồ thị đồng thời tĩnh; Sei v2 tích hợp một engine khớp lệnh đa luồng và mô-đun VM song song.

Tất nhiên, loại chuỗi song song gốc này cũng đối mặt với những thách thức về tính 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 hoàn toàn mới (như Move, Rust) và bộ công cụ, điều này tạo ra một mứ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ũng phải 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à vòng đời đối tượng, tất cả đều làm tăng ngưỡng hiểu biết và đặt ra yêu cầu cao hơn đối với các mô hình phát triển.

3.1 Nguyên tắc của Solana và Động cơ song song Sealevel của SVM

Mô hình thực thi Sealevel của Solana là một cơ chế lập lịch song song dựa trên tài khoản, đây là động cơ cốt lõi được Solana sử dụng để đạt được việc thực thi giao dịch song song trên 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", nó thực hiện tính đồ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 trong việc triển khai lập lịch đồng thời trên chuỗi trong môi trường sản xuất, và các ý tưởng kiến trúc của nó đã ảnh hưởng đến nhiều dự án tính toán song song tiếp theo, phục vụ như một mô hình tham khảo cho thiết kế song song hiệu suất cao Layer 1.

Cơ chế cốt lõi:

1. Tuyên bố truy cập tài khoản rõ ràng (Danh sách truy cập tài khoản): Mỗi giao dịch phải tuyên bố các tài khoản liên quan (đọc/ghi) tại thời điểm nộp, cho phép hệ thống 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 tập hợp các tài khoản được truy cập bởi hai giao dịch không có giao điểm → chúng có thể được thực hiện song song;
• Xung đột tồn tại → Thực hiện tuần tự 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 đồ thị phụ thuộc.

3. Ngữ cảnh thực thi độc lập (Ngữ cảnh gọi chương trình): Mỗi cuộc gọi hợp đồng hoạt động trong một ngữ cảnh cô lập, không có ngăn xếp chia sẻ, ngăn chặn sự can thiệp giữa các cuộc gọi.

Sealevel là công cụ lập lịch thực thi song song của Solana, trong khi 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). Cùng 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 VM Solana lên các chuỗi mô-đun (như Ethereum L2 hoặc Celestia), sử dụng độ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 mạng chính Solana và di chuyển nó đến kiến trúc mô-đun, biến mô hình "thực thi đồng thời siêu mạnh" của Solana thành Dịch vụ Lớp Thực thi. Do đó, Eclipse cũng thuộc loại tính toán song song.

Cách tiếp cận của Neon là khác biệt; nó giới thiệu EVM để chạy trong môi trường SVM / Sealevel. Nó xây dựng một lớp thời gian chạy tương thích với EVM, cho phép các nhà phát triển sử dụng Solidity để phát triển các hợp đồng chạy trong môi trường SVM, nhưng việc lập lịch thực thi sử dụng SVM + Sealevel. Neon thiên về loại Blockchain Modular hơn là nhấn mạnh vào các đổi mới trong tính toán song song.

Tóm lại, Solana và SVM dựa vào engine thực thi Sealevel, và triết lý lập lịch của hệ điều hành Solana tương tự như lập lịch của kernel, thực thi nhanh chóng nhưng với độ linh hoạt tương đối thấp. Đây là một chuỗi công cộng hiệu suất cao, tính toán song song bản địa.

3.2 Kiến trúc MoveVM: Dựa trên 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ế cho sự an toàn của các tài nguyên trên chuỗi và thực thi song song. 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 như một đối tượng". Tất cả các trạng thái trên chuỗi tồn tại như nhữ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 xem có xung đột trạng thái giữa các giao dịch tại thời điểm biên dịch, cho phép lập kế hoạch song song tĩnh theo đối tượng, và nó đượ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ình sở hữu đối tượng của Sui
Khả năng tính toán song song của Sui xuất phát từ cách tiếp cận mô hình trạng thái độc đáo và cơ chế phân tích tĩnh ở cấp độ ngôn ngữ của nó. Khác với các blockchain truyền thống sử dụng cây trạng thái toàn cầu, Sui đã xây dựng một tập hợp các mô hình trạng thái tập trung vào đối tượng, kết hợp với hệ thống kiểu tuyến tính của MoveVM, cho phép lập lịch song song trở thành một quá trình xác định có thể 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 độc lập, mỗi đối tượng có một ID duy nhất, một chủ sở hữu rõ ràng (tài khoản hoặc hợp đồng) và các định nghĩa kiểu. Những đối tượng này không chia sẻ trạng thái với nhau, cung cấp sự cách ly tự nhiên. Các hợp đồng phải công khai tuyên bố tập hợp các đối tượng có liên quan khi được gọi, tránh các vấn đề về sự kết hợp trạng thái của "cây trạng thái toàn cầu" truyền thống trên chuỗi. Thiết kế này phân chia các trạng thái trên chuỗi thành nhiều đơn vị độc lập, làm cho việc thực thi đồng thời trở thành một tiền đề lập lịch có cấu trúc khả thi.
• 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 dướ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 suy diễn các giao dịch nào sẽ không gây ra xung đột trạng thái thông qua quyền sở hữu đối tượng trước khi các giao dịch được thực thi, từ đó sắp xếp chúng để thực thi song song. So với việc phát hiện xung đột và hoàn tác truyền thống trong thời gian thực, cơ chế phân tích tĩnh của Sui tăng cường đáng kể hiệu suất thực thi trong khi giảm thiểu độ phức tạp lập lịch, điều nà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 dựa trên các đối tượng và kết hợp phân tích quyền sở hữu tại thời điểm biên dịch để đạt được việc thực thi song song cấp độ đối tượng không tốn chi phí và không cần hoàn tác. So với việc thực thi tuần tự hoặc kiểm tra 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ể trong hiệu suất thực thi, tính xác định của hệ thống và việc sử dụng tài nguyên.

Cơ chế thực thi Block-STM của Aptos
Aptos là một blockchain Layer 1 hiệu suất cao dựa trên ngôn ngữ Move, khả năng thực thi song song của nó chủ yếu đến từ khung Block-STM (Bộ nhớ giao dịch phần mềm cấp khối) tự phát triển. Khác với Sui, có xu hướng áp dụng chiến lược "song song tĩnh thời gian biên dịch", Block-STM thuộc về 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ý các tập giao dịch có phụ thuộc phức tạp.

Block-STM chia việc thực thi các giao dịch của một khối thành ba giai đoạn:

• Thực thi suy đoán: Tất cả các giao dịch được giả định là không có xung đột trước khi thực hiện, và hệ thống lên lịch các giao dịch cho nhiều luồng để thực thi đồng thời, ghi lại trạng thái tài khoản mà chúng truy cập (tập đọc / tập ghi).
• Giai đoạn phát hiện và xác thực xung đột: 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 được ghi bởi Tx2), một trong số đó sẽ bị hoàn tác.
• Khôi phục giao dịch xung đột (Giai đoạn thử lại): Các giao dịch xung đột sẽ được lên lịch lại để thực hiện cho đến khi các phụ thuộc của chúng được giải quyết, cuối cùng hình thành một chuỗi cam kết trạng thái hợp lệ và xác định cho tất cả các giao dịch.

Block-STM là một mô hình thực thi động sử dụng "song song lạc quan + thử lại quay lui", phù hợp với các kịch bản xử lý lô giao dịch trên chuỗi phức tạp về trạng thái và logic. Đây là cốt lõi của tính toán song song cho Aptos để xây dựng một chuỗi công cộng đa năng và có khả năng xử lý cao.

Solana là phân phái lập lịch kỹ thuật, giống như một "hạt nhân hệ điều hành". Nó phù hợp với các ranh giới trạng thái rõ ràng và giao dịch tần suất cao có thể kiểm soát, thể hiện phong cách của một kỹ sư phần cứng, và được thiết kế để vận hành chuỗi giống như phần cứng (Thực thi song song cấp phần cứng). Aptos là phân phái chịu lỗi hệ thống, giống như một "công cụ đồng thời cơ sở dữ liệu". Nó phù hợp với các hợp đồng có sự liên kết trạng thái mạnh mẽ và chuỗi gọi phức tạp. Sui là phân phái an toàn tại thời điểm biên dịch, giống như một "nền tảng ngôn ngữ thông minh định hướng tài nguyên". Nó phù hợp với các ứng dụng trên chuỗi có sự tách biệt tài sản và các tổ hợp rõ ràng. Aptos và Sui được dự định để vận hành chuỗi như các kỹ sư ngôn ngữ lập trình, đảm bảo an toàn tài nguyên cấp phần mềm. Ba cái này đại diện cho những con đường triết học khác nhau cho việc thực hiện kỹ thuật của tính toán song song trong Web3.

3.3 Loại Tăng Tốc Song Song Cosmos SDK

Sei V2 là một chuỗi công cộng giao dịch hiệu suất cao được xây dựng trên Cosmos SDK. Khả năng song song của nó chủ yếu được thể hiện ở hai khía cạnh: động cơ khớp lệnh đa luồng và tối ưu hóa thực thi song song ở tầng máy ảo, nhằm phục vụ cho các tình huống giao dịch trên chuỗi tần suất cao, độ trễ thấp, chẳng hạn như DEX sổ lệnh và cơ sở hạ tầng trao đổi trên chuỗi.

Cơ chế song song cốt lõi:

• Công cụ Khớp Lệnh Song Song: Sei V2 giới thiệu một đường dẫn thực thi đa luồng trong logic khớp lệnh, tách rời sổ lệnh khỏi logic khớp lệnh ở mức luồng, cho phép các nhiệm vụ khớp lệnh giữa nhiều thị trường (cặp giao dịch) được xử lý song song, từ đó tránh được các nút thắt đơn luồng.
• Tối ưu hóa đồng thời ở cấp độ máy ảo: Sei V2 đã xây dựng một môi trường runtime CosmWasm với khả năng thực thi đồng thời, cho phép một số cuộc gọi hợp đồng chạy song song với điều kiện rằng trạng thái của chúng không xung đột, và đạt được kiểm soát thông lượng cao hơn kết hợp với cơ chế phân loại loại giao dịch.
• Sự đồng thuận song song kết hợp với lịch trình lớp thực thi: Giới thiệu cơ chế đồng thuận "Twin-Turbo" nhằm tăng cường khả năng tách biệt lưu lượng giữa lớp đồng thuận và lớp thực thi, nâng cao hiệu suất xử lý khối tổng thể.

3.4 Mô hình UTXO Tái tạo Nhiên liệu

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ới cơ chế song song cốt lõi xuất phát từ một mô hình UTXO được cải tiến (Unspent Transaction Output). Khác với 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, điều này vốn có khả năng cách ly trạng thái, giúp dễ dàng xác định các giao dịch nào có thể được thực thi song song một cách an toàn. Thêm vào đó, Fuel giới thiệu một ngôn ngữ hợp đồng thông minh tự phát triển gọi là Sway (tương tự như Rust), và kết hợp nó với các công cụ phân tích tĩnh để xác định xung đột đầu vào trước khi thực thi giao dịch, từ đó đạt được lịch trình song song cấp giao dịch hiệu quả và an toàn. Nó phục vụ như một lớp thực thi thay thế EVM cân bằng giữa hiệu suất và tính mô-đun.

4. Mô Hình Diễn Viên: Một Mô Hình Mới cho Việc Thực Thi Đồng Thời của Các Tác Nhân

Mô hình Actor là một mô hình thực thi song song sử dụng các quy trình tác nhân (Tác nhân hoặc Quy trình) làm đơn vị, khác với tính toán đồng bộ truyền thống với một trạng thái toàn cầu trên chuỗi (các kịch bản như "tính toán song song trên chuỗi" như Solana/Sui/Monad), vì nó nhấn mạnh rằng mỗi tác nhân có trạng thái và hành vi độc lập của riêng mình, giao tiếp và lập lịch thông qua các tin nhắn không đồng bộ. Dưới kiến trúc này, các hệ thống trên chuỗi có thể đồng thời chạy một số lượng lớn các quy trình tách rời, cung cấp 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 tiêu biểu bao gồm AO (Arweave AO), ICP (Máy tính Internet) và Cartesi, đang thúc đẩy sự tiến hóa của blockchain từ một động cơ thực thi đến 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, các tương tác đa nhiệm và việc phối hợp logic phức tạp.

Mặc dù thiết kế của Mô hình Diễn viên có một số điểm tương đồng bề ngoài với Sharding (chẳng hạn như khả năng đồng thời, cô lập trạng thái và xử lý bất đồng bộ), nhưng về cơ bản chúng đại diện cho những con đường công nghệ và triết lý hệ thống hoàn toàn khác nhau. Mô hình Diễn viên nhấn mạnh "tính toán bất đồng bộ đa tiến trình," trong đó mỗi tác nhân (Diễn viên) hoạt động độc lập và duy trì trạng thái riêng, tương tác thông qua một cách tiếp cận dựa trên tin nhắn; trong khi Sharding là một cơ chế để "phân vùng 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 (Shards) xử lý giao dịch. Mô hình Diễn viên 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 khả năng đồng thời, nhưng điểm khởi đầu, mục tiêu và kiến trúc thực thi của chúng 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 máy tính phi tập trung hoạt động 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 trên chuỗi hỗ trợ hoạt động của các tác nhân bất đồ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, sở hữu 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 dựa trên Arweave + một động cơ thực thi dựa trên tin nhắn đa tác nhân;
• Hệ thống Lập lịch Tin nhắn Bất đồng bộ: Các quy trình giao tiếp thông qua tin nhắn, áp dụng mô hình hoạt động bất đồng bộ không khóa, điều này tự nhiên hỗ trợ khả năng mở rộng đồng thời;
• Lưu trữ trạng thái vĩnh viễn: Tất cả trạng thái đại lý, hồ sơ 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 toán hoàn toàn và tính minh bạch phi tập trung.
• Agent-native: Phù hợp cho việc triển khai các nhiệm vụ phức tạp nhiều bước (chẳng hạn như các tác nhân AI, bộ điều khiển giao thức DePIN, các bộ điều phối nhiệm vụ tự động, v.v.), có thể xây dựng một "Coprocessor AI trên chuỗi."

AO theo một cách tiếp cận cực đoan "cơ thể thông minh bản địa + lưu trữ điều khiển + kiến trúc không chuỗi", nhấn mạnh tính linh hoạt và tách rời mô-đun. Nó là một "khung vi hạt được xây dựng trên lớp lưu trữ," với các ranh giới hệ thống cố ý được thu hẹp, 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 đầy đủ chức năng

ICP là một nền tảng ứng dụng on-chain full-stack gốc Web3 được DFINITY ra mắt, nhằm mở rộng khả năng tính toán on-chain đến một 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 miền, và kiến trúc không máy chủ.

Các tính năng kiến trúc cốt lõi:

• Kiến trúc canister (containers như các tác nhân thông minh): Mỗi Canister là một tác nhân thông minh chạy trên Wasm VM, sở hữu 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: Toàn bộ mạng được cấu thành từ nhiều Subnet, mỗi Subnet duy trì một nhóm Canisters và đạt được đồng thuận thông qua cơ chế chữ ký BLS.
• Mô hình gọi không đồng bộ: Các canister giao tiếp với nhau thông qua tin nhắn không đồng bộ, hỗ trợ thực thi không chặn và có tính song song vốn có;
• Lưu trữ Web trên chuỗi: Hỗ trợ hợp đồng thông minh để trực tiếp lưu trữ các trang front-end, với ánh xạ DNS gốc, biến nó thành nền tảng blockchain đầu tiên hỗ trợ truy cập dApps trực tiếp từ trình duyệt.
• Chức năng hệ thống toàn diện: Được trang bị nâng cấp nóng trên chuỗi, xác thực danh tính, ngẫu nhiên phân tán, bộ đếm thời gian và các API hệ thống khác, phù hợp cho việc triển khai dịch vụ trên chuỗi phức tạp.

ICP chọn một nền tảng nặng, tích hợp đóng gói và mô hình hệ điều hành kiểm soát nền tảng mạnh mẽ, với một "Hệ điều hành Blockchain" tích hợp đồng thuận, thực thi, lưu trữ và truy cập. Nó nhấn mạnh khả năng lưu trữ dịch vụ hoàn chỉnh, và ranh giới hệ thống mở rộng thành một nền tảng lưu trữ Web3 đầy đủ.

Ngoài ra, các dự án điện toán song song khác dựa trên mô hình Actor Model có thể tham khảo bảng dưới đây:

V. Tóm tắt và Triển vọng

Dựa trên sự khác biệt trong 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ể được chia thành hai loại chính: chuỗi tăng cường song song dựa trên EVM và chuỗi kiến trúc song song gốc (không phải EVM).

Cái trước đạ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 sâu sắc lớp thực thi trong khi vẫn duy trì tính tương thích với hệ sinh thái EVM/Solidity. Nó phù hợp với các tình huống nơi có mong muốn kế thừa tài sản và công cụ phát triển của Ethereum trong khi cũng đạt được những đột phá về hiệu suất. Các dự án đại diện bao gồm:

• Monad: Đạt được mô hình thực thi song song lạc quan tương thích với EVM thông qua việc ghi chậm và phát hiện xung đột trong thời gian chạy, xây dựng đồ thị phụ thuộc và lập lịch thực thi với đa luồng sau khi đạt được đồng thuận.
• MegaETH: Trừu tượng hóa mỗi tài khoản/hợp đồng như một Micro-VM độc lập, đạt được lập lịch song song cấp tài khoản rất tách rời dựa trên thông điệp bất đồng bộ và đồ thị phụ thuộc trạng thái.
• Pharos: Xây dựng kiến trúc Rollup Mesh hợp tác với mô-đun SPN thông qua các pipeline bất đồng bộ để đạt được xử lý song song cấp hệ thống giữa các quy trình.
• Reddio: Áp dụng kiến trúc zkRollup + GPU, tập trung vào việc 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, nâng cao thông lượng xác minh.

Cái sau hoàn toàn thoát khỏi những hạn chế của khả năng tương thích với Ethereum, 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 khả năng đồng thời hiệu suất cao bản địa. Các phân lớp điển hình bao gồm:

• Solana (Hệ thống SVM): Dựa trên các tuyên bố truy cập tài khoản và lập lịch đồ thị xung đột tĩnh, đại diện cho mô hình thực thi song song cấp tài khoản;
• 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 gian biên dịch và đạt được song song ở cấp độ đối tượng.
• Sei V2 (Cosmos SDK Route): Giới thiệu một engine khớp lệnh đa luồng và tối ưu hóa đồng thời máy ảo trong kiến trúc Cosmos, phù hợp cho các ứng dụng giao dịch tần suất cao.
• Nhiên liệu (kiến trúc UTXO + Sway): Đạt được tính song song ở cấp độ giao dịch thông qua phân tích tĩnh của các tập hợp đầu vào UTXO, kết hợp với một lớp thực thi mô-đun và ngôn ngữ hợp đồng thông minh tùy chỉnh Sway.

Ngoài ra, Mô hình Diễn viên, như một hệ thống song song rộng lớn hơn, xây dựng một mô hình thực thi trên chuỗi với "hoạt động độc lập của nhiều tác nhân + hợp tác dựa trên thông điệp" thông qua một cơ chế lập lịch quy trình không đồng bộ dựa trên Wasm hoặc các VM tùy chỉnh. Các dự án đại diện bao gồm:

• AO (Arweave AO): Một môi trường thực thi đại lý được điều khiển bởi lưu trữ vĩnh viễn, xây dựng một hệ thống vi nhân kernel bất đồng bộ trên chuỗi.
• ICP (Internet Computer): Đạt được khả năng thực thi mở rộng cao không đồng bộ thông qua sự phối hợp của các subnet với tác nhân được container hóa (Canister) như là đơn vị nhỏ nhất.
• Cartesi: Giới thiệu hệ điều hành Linux như một môi trường tính toán ngoài chuỗi, cung cấp một con đường xác minh trên chuỗi cho các kết quả tính toán đáng tin cậy, phù hợp cho các kịch bản ứng dụng phức tạp hoặc tốn tài nguyên.

Dựa trên logic trên, chúng ta có thể phân loại các giải pháp chuỗi công khai tính toán song song chính thống hiện nay vào cấu trúc phân loại như được hiển thị trong biểu đồ dưới đây:

Từ một góc nhìn rộng hơn về việc mở rộng quy mô, sharding và rollup (L2) tập trung vào việc đạt được khả năng mở rộng theo chiều ngang của hệ thống thông qua phân vùng 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 (chẳng hạn như Monad, Sui, Solana) và hệ thống định hướng tác nhân (chẳng hạn như AO, ICP) trực tiếp tái cấu trúc mô hình thực thi để đạt được tính song song bản địa ở cấp chuỗi hoặc hệ thống. Thứ nhất, nâng cao thông lượng trên chuỗi thông qua các phương pháp như máy ảo đa luồng, mô hình đối tượng và phân tích xung đột giao dịch; thứ hai, sử dụng quy trình/tác nhân làm đơn vị cơ bản và áp dụng các phương pháp thực thi dựa trên tin nhắn và bất đồng bộ để cho phép hoạt động đồng thời của nhiều tác nhân. So với nhau, sharding và rollup giống như 'phân phối tải giữa nhiều chuỗi' hoặc 'thuê ngoài cho thực thi ngoài chuỗi', trong khi các chuỗi song song và mô hình tác nhân là về 'giải phóng tiềm năng hiệu suất từ chính động cơ thực thi', phản ánh một hướng tiến hóa kiến trúc sâu sắc hơn.

So sánh Tính toán Song song, Kiến trúc Shard, Tính mở rộng Rollup và Đường dẫn Mở rộng Hướng Tác giả

Cần lưu ý rằng hầu hết các chuỗi kiến trúc song song gốc hiện đã bước vào giai đoạn ra mắt mainnet. Mặc dù hệ sinh thái phát triển tổng thể vẫn còn khó khăn để so sánh với hệ thống Solidity dựa trên EVM, các dự án đại diện cho Solana và Sui, với kiến trúc thực thi hiệu suất cao và sự phát triển dần dần của các ứng dụng sinh thái, đã trở thành các chuỗi công cộng cốt lõi thu hút sự chú ý đáng kể từ thị trường.

Ngược lại, mặc dù hệ sinh thái Ethereum Rollup (L2) đã bước vào giai đoạn "nhiều chuỗi đua nhau ra mắt" hoặc thậm chí "quá tải", các chuỗi tăng cường song song tương thích EVM hiện tại vẫn chủ yếu ở giai đoạn testnet và chưa trải qua xác thực thực tế trong môi trường mainnet. Khả năng mở rộng và sự ổn định của hệ thống vẫn cần được kiểm tra thêm. Còn liệu những dự án này có thể cải thiện đáng kể hiệu suất EVM và thúc đẩy sự tiến hóa sinh thái mà không hy sinh tính tương thích, hay liệu chúng sẽ làm trầm trọng thêm sự phân hóa hơn nữa về thanh khoản và nguồn lực phát triển trên Ethereum, vẫn còn phải xem.

Tuyên bố:

1. Bài viết này được sao chép từ [TechFlow] Quyền tác giả thuộc về tác giả gốc [0xjacobzhao và ChatGPT 4o] Nếu bạn có bất kỳ phản đối nào đối với việc tái bản, xin vui lòng liên hệ Đội ngũ Gate LearnĐội ngũ sẽ xử lý nó nhanh nhất có thể theo các quy trình liên quan.
2. Thông báo: Quan điểm và ý kiến được nêu trong bài viết này hoàn toàn là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. Các phiên bản ngôn ngữ khác của bài viết được dịch bởi đội ngũ Gate Learn, trừ khi có đề cập khác.CổngDưới mọi hình thức, các bài viết đã được dịch không được sao chép, phát tán hoặc đạo văn.