Được viết bởi: 0xjacobzhao và ChatGPT 4o
" Bộ ba bất khả thi của blockchain " (Blockchain Trilemma) của blockchain về "bảo mật", " phi tập trung" và "mở rộng" cho thấy những sự đánh đổi cần thiết trong thiết kế hệ thống blockchain, tức là các dự án blockchain khó có thể đạ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. Liên quan đến chủ đề muôn thuở về "mở rộng", các giải pháp mở rộng blockchain chính thống trên thị trường được chia thành các mô hình, bao gồm:
Mở rộng 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 hóa, GPU và đa lõi
Mở rộng cô lập trạng thái: trạng thái chia tách theo chiều ngang/Shard, chẳng hạn như phân mảnh, UTXO, nhiều mạng con
Mở rộng dịch vụ gia Chuỗi ngoài chuỗi: đưa hoạt động thực hiện ra ngoài Chuỗi, chẳng hạn như Rollup, Coprocessor, DA
Mở rộng tách rời cấu trúc: mô-đun mô-đun và hoạt động cộng tác, chẳng hạn như Chuỗi mô-đun , sắp xếp chia sẻ, Rollup Mesh
Mở rộng đồng thời không đồng bộ: Mô hình diễn viên, cô lập quy trình, điều khiển bằng tin nhắn, chẳng hạn như tác nhân thông minh, Chuỗi không đồng bộ đa luồng
Kế hoạch mở rộng blockchain bao gồm: điện 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 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. Đây là hệ thống mở rộng hoàn chỉnh của “sự 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 năng lực dựa trên điện 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 một khối. Theo cơ chế song song, các phương pháp mở rộng có thể được chia thành năm loại. Mỗi hạng mục đại diện cho các mục tiêu hiệu suất, mô hình phát triển và triết lý kiến trúc khác nhau. Độ chi tiết song song ngày càng mịn hơn, cường độ song song ngày càng cao hơn, độ phức tạp của lập trình ngày càng cao hơn và độ phức tạp của lập trình cũng như độ khó của triển khai ngày càng cao hơn.
Song song cấp tài khoản: Dự án tiêu biểu Solana
Song song cấp đối tượng: Dự án tiêu biểu Sui
Song song cấp độ giao dịch: Các dự án tiêu biểu bao gồm Monad và Aptos
Song song cấp độ cuộc gọi / MicroVM: Dự án tiêu biểu MegaETH
Song song cấp độ hướng dẫn: Dự án tiêu biểu GatlingX
Mô hình đồng thời không đồng bộ ngoài Chuỗi được thể hiện bằng Mô hình Actor / Actor. Chúng thuộc về một mô hình điện toán song song khác. Là một hệ thống nhắn tin không đồng bộ/liên Chuỗi(mô hình đồng bộ hóa không theo khối), mỗi Agent là một "quy trình agent" chạy độc lập với nhắn tin không đồng bộ và phương pháp song song theo sự kiện, không yêu cầu lập lịch đồng bộ. Các dự án tiêu biểu bao gồm AO, ICP, Cartesi , v.v.
Các giải pháp mở rộng Rollup hoặc phân mảnh mà chúng ta quen thuộc thuộc về cơ chế đồng thời cấp hệ thống, không phải là điện toán song song trong 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 mức độ song song trong một khối/máy ảo duy nhất. Bài viết này không tập trung vào loại giải pháp mở rộng 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 dựa trên EVM: phá vỡ ranh giới hiệu suất trong khả năng tương thích
Kiến trúc xử lý tuần tự của Ethereum đã phát triển cho đến nay và đã trải qua nhiều vòng thử nghiệm mở rộng như phân mảnh, Rollup và kiến trúc mô-đun, nhưng nút thắt thông lượng của lớp thực thi vẫn chưa được giải quyết 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ó lượng nhà phát triển và tiềm năng sinh thái lớn nhất. Do đó, Chuỗi tăng cường song song EVM, như một con đường chính để cân bằng khả năng tương thích sinh thái và cải thiện hiệu suất thực hiện, đang trở thành một hướng quan trọng cho vòng tiến hóa mở rộng mới. 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 thi bị trì hoãn và phân tích trạng thái, họ xây dựng kiến trúc xử lý song song EVM cho các tình huống đồ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à blockchain Lớp 1 hiệu suất cao được thiết kế lại cho Máy ảo Ethereum (EVM). Nó dựa trên khái niệm song song cơ bản về xử lý đường ống, 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, tại 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 được tối ưu hóa toàn diện.
Đường ống: Cơ chế thực hiện song song đường ống nhiều giai đoạn
Pipelining là khái niệm cơ bản của thực thi song song Monad. Ý 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ý các giai đoạn này song song để tạo thành kiến trúc đường ống ba chiều. Mỗi giai đoạn chạy trên một luồng hoặc lõi độc lập để đạt được khả năng xử lý đồng thời trên nhiều khối, cuối cùng đạt được hiệu quả 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), đồng thuận (Consensus), thực hiện giao dịch (Execution) và gửi khối (Commit).
Thực hiện không đồng bộ: Sự đồng thuận - tách rời thực hiện không đồng bộ
Trên Chuỗi truyền thống, sự đồng thuận và thực hiện giao dịch thường là các quy trình đồng bộ. Mô hình nối tiếp này hạn chế nghiêm trọng mở rộng hiệu suất. Monad thực hiện tính không đồng bộ lớp đồng thuận, tính không đồng bộ ở lớp thực thi và tính không đồng bộ ở lưu trữ 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 linh hoạt hơn, luồng xử lý được phân đoạn hơn và sử dụng tài nguyên hiệu quả hơn.
Thiết kế cốt lõi:
Quá 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 hiện (lớp thực hiện) được kích hoạt không đồng bộ sau khi đạt được sự đồng thuận.
Sau khi quá trình đồng thuận hoàn tất, quá trình đồng thuận khối tiếp theo sẽ được thực hiện ngay lập tức mà không cần chờ quá trình thực thi hoàn tất.
Thực hiện song song lạc quan: Thực hiện song song lạc quan
Ethereum truyền thống sử dụng mô hình tuần tự nghiêm ngặt để thực hiện giao dịch nhằm tránh xung đột trạng thái. Monad áp dụng chiến lược "thực thi song song lạc quan" để cải thiện đáng kể tốc độ xử lý giao dịch.
Cơ chế thực hiện:
Monad sẽ thực hiện tất cả các giao dịch song song một cách lạc quan, giả sử rằng hầu hết các giao dịch không xung đột với nhau.
"Trình phát hiện xung đột" cũng được chạy để theo dõi xem các giao dịch có truy cập cùng một trạng thái hay không (chẳng hạn như xung đột đọc/ghi).
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 hiện lại để đảm bảo trạng thái chính xác.
Monad đã chọn một con đường tương thích: nó thay đổi các quy tắc EVM ít nhất có thể và đạt được tính song song bằng cách hoãn trạng thái ghi và phát hiện xung đột một cách động trong quá trình thực thi. Nó giống như một Ethereum hiệu suất cao của Ethereum. Sự trưởng thành của nó giúp việc di chuyển hệ sinh thái EVM trở nên dễ dàng và là một accelerator 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 định vị L1 của Monad, MegaETH được định vị là lớp thực thi song song hiệu suất cao mô-đun-đun tương thích với EVM. Nó có thể được sử dụ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 (Lớp 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à cô lập và phân tích logic tài khoản, hoàn cảnh thực thi và trạng thái thành các đơn vị tối thiểu có thể 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. Những cải tiến chính được MegaETH đề xuất là: Kiến trúc Micro-VM + DAG (đồ thị phụ thuộc trạng thái không theo chu trình có hướng) và cơ chế đồng bộ hóa mô-đun, cùng nhau xây dựng 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 dưới dạng luồng
MegaETH giới thiệu mô hình thực thi "một máy ảo siêu nhỏ (Micro-VM) cho mỗi tài khoản", mô hình này "phân luồng"hoàn cảnh thực thi và cung cấp đơn vị cô lập nhỏ nhất để lập lịch song song. Các VM này giao tiếp với nhau thông qua tin nhắn không đồng bộ thay vì các cuộc gọi đồng bộ. Lượng lớn máy ảo có thể được thực thi và lưu trữ độc lập, đây là quá trình song song tự nhiên.
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 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ì biểu đồ phụ thuộc toàn cầu theo thời gian thực. Những tài khoản nào được sửa đổi và những tài khoản nào được đọc lần giao dịch đều được mô hình hóa dưới dạng các mối phụ thuộc. Các giao dịch không xung đột có thể được thực hiện trực tiếp song song và các giao dịch có sự phụ thuộc sẽ được sắp xếp theo thứ tự tôpô hoặc bị trì hoãn. Biểu đồ phụ thuộc đảm bảo tính nhất quán của trạng thái và không ghi trùng lặp trong quá trình thực thi song song.
Cơ chế thực thi và điều chỉnh hồi không đồng bộ
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 thông điệp bất đồng bộ của Actor Model, để giải quyết vấn đề về các lệnh 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). Khi gọi hợp đồng A -> B -> C, lần cuộc gọi đều không đồng bộ mà không bị chặn và chờ đợi; ngăn xếp cuộc gọi được mở rộng thành đồ thị cuộc gọi không đồng bộ (Đồ thị cuộc gọi); xử lý giao dịch = duyệt đồ thị không đồng bộ + giải quyết sự 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 luồng đơn EVM truyền thống, triển khai đóng gói máy ảo siêu nhỏ dựa trên tài khoản, lên lịch giao dịch thông qua biểu đồ phụ thuộc trạng thái và thay thế ngăn xếp cuộc gọi đồng bộ bằng cơ chế tin nhắn không đồng bộ. Đây là nền tảng điện toán song song được thiết kế lại ở mọi khía cạnh từ "cấu trúc tài khoản → kiến trúc lập lịch → quy trình thực hiện", cung cấp ý tưởng mới ở cấp độ mô hình để xây dựng thế hệ hệ thống Chuỗi hiệu suất cao tiếp theo.
MegaETH đã chọn con đường tái thiết: tách biệt hoàn toàn các tài khoản và hợp đồng thành các VM độc lập và giải phóng tiềm năng song song tối đa thông qua lịch trình thực hiện không đồng bộ. Về mặt lý thuyết, MegaETH có giới hạn trên song song cao hơn, nhưng cũng khó kiểm soát độ phức tạp hơn. Nó giống như một hệ điều hành siêu phân tán dựa trên khái niệm Ethereum.
Khái niệm thiết kế của cả Monad và MegaETH khá khác biệt so với Sharding: Sharding chia blockchain theo chiều ngang thành nhiều Chuỗi độ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 mở rộng Chuỗi đơn ở lớp mạng; trong khi Monad và MegaETH đều duy trì tính toàn vẹn của Chuỗi đơn, chỉ mở rộng theo chiều ngang ở lớp thực thi và tối ưu hóa hiệu suất thông qua việc thực thi song song cực độ trong Chuỗi đơn. Hai thứ này đại diện cho hướng tăng cường theo chiều dọc và hướng mở rộng theo chiều ngang trong lộ trình 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 các đường dẫn 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 trong 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 thi bị trì hoãn và kiến trúc máy ảo siêu nhỏ (Micro-VM). Pharos Network là mạng blockchain L1 song song, đầy đủ mô-đun , theo mô-đun và cơ chế tính 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ợ nhiều hoàn cảnh máy ảo (EVM và Wasm) thông qua sự cộng tác giữa mainnet và mạng xử lý đặc biệt (SPN) và tích hợp các công nghệ tiên tiến như Bằng chứng không tri thức(ZK) và hoàn cảnh thực thi đáng tin cậy (TEE).
Phân tích cơ chế tính toán song song Rollup Mesh:
Đường ống xử lý không đồng bộ toàn vòng đời: Pharos tách biệt các giai đoạn khác nhau của giao dịch (như đồng thuận, thực thi và lưu trữ) và sử 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 VM kép: Pharos hỗ trợ cả hoàn cảnh máy ảo EVM và WASM, cho phép các nhà phát triển lựa chọn hoàn cảnh thực thi phù hợp theo nhu cầu của mình. Kiến trúc VM kép này không chỉ cải thiện 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 (SPN): SPN là thành phần quan trọng trong kiến trúc Pharos và giống như các mạng con mô- mô-đun chuyên xử lý các loại nhiệm vụ hoặc ứng dụng cụ thể. Thông qua SPN, Pharos có thể phân bổ tài nguyên động và xử lý song song nhiệm vụ, nâng cao hơn nữa mở rộng và hiệu suất của hệ thống.
Sự đồng thuận mô-đun và việc giữ lại: 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 khả năng 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 giữ lại (Restaking).
Ngoài ra, Pharos còn tái cấu trúc mô hình thực thi từ dưới cùng của công cụ lưu trữ thông qua các công nghệ cây Merkle đa phiên bản, mã hóa Delta, định địa chỉ theo phiên bản và đẩy ADS, đồng thời ra mắt công cụ lưu trữ hiệu suất cao trên blockchain gốc Pharos Store, đạt được khả năng xử lý trên Chuỗi có thông lượng cao, độ trễ thấp và có thể xác minh cao.
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ộ. Pharos, với tư cách là một điều phối viên lập lịch cho tính song song của Rollup chéo, không phải là trình tối ưu hóa thực thi "song song trong Chuỗi" mà thay vào đó thực hiện nhiệm vụ thực thi tùy chỉnh không đồng nhất thông qua SPN.
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 nhận thấy có một số dự án trên thị trường khám phá lộ trình ứng dụng tăng tốc GPU trong điện toán song song EVM, như một sự bổ sung quan trọng và thử nghiệm tiên tiến cho hệ sinh thái song song EVM. Trong đó, Reddio và GatlingX là hai hướng tiêu biểu:
Reddio là 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 của nó nằm ở việc tái cấu trúc quy trình thực thi EVM và hiện thực hóa song song hóa 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 lần giao dịch được tăng tốc bằng GPU. Mức độ chi tiết song song thuộc về cấp độ giao dịch + cấp độ hoạt động (thực thi mã lệnh đa luồng). Thiết kế của nó giới thiệu khả năng 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 (CUDA-Compatible Parallel EVM). Giống như Monad/MegaETH, Reddio cũng tập trung vào xử lý song song ở lớp thực thi. 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 và được thiết kế cho các tình huống có thông lượng cao và tính toán chuyên sâu (như suy luận AI). SDK hiện ra mắt , cung cấp mô-đun thực thi tích hợp
GatlingX tự gọi mình là "GPU-EVM" và đề xuất một kiến trúc cấp tiến hơn nhằm di chuyển mô hình "thực thi tuần tự cấp lệnh" của máy ảo EVM truyền thống sang hoàn cảnh hoạt động song song gốc của GPU. Cơ chế cốt lõi của nó là biên dịch động mã bytecode EVM thành nhiệm vụ song song CUDA và thực thi các luồng lệnh thông qua nhiều lõi GPU, do đó phá vỡ tình trạng tắc nghẽn tuần tự của EVM ở cấp độ thấp nhất. Thuộc về mức độ chi tiết song song của tính song song ở cấp độ hướng dẫn (ILP). So với mức độ 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 độ hướng dẫn, gần hơn với quá trình tái cấu trúc cơ bản của công cụ máy ảo. Hiện tại, dự án đang trong giai đoạn ý tưởng, với Sách 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 mainnet .
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 máy ảo WebAssembly (WASM) theo kiến trúc EVM++, các nhà phát triển có thể sử dụng mô hình lập trình Aspect để thêm và thực thi mở rộng trên Chuỗi một cách linh hoạt trong khi vẫn duy trì khả năng tương thích với EVM. Nó sử dụng mức độ chi tiết của lệnh gọi hợp đồng (Hàm/Phần mở rộng) làm đơn vị song song nhỏ nhất, hỗ trợ việc đưa mô-đun mở rộng vào (tương tự như "phần mềm trung gian có thể cắm được") trong thời gian chạy hợp đồng EVM và thực hiện tách rời logic, lệnh 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: 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 luồng đơn "thứ tự giao dịch đầy đủ + thực thi tuần tự" ngay từ khi thành lập, 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ả nút trong mạng. Tuy nhiên, kiến trúc này có những hạn chế về hiệu suất, hạn chế thông lượng và mở rộng hệ thống. Ngược lại, 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 thiết kế riêng để thực thi song song ngay từ thiết kế cấp cơ sở và có những ưu điểm sau:
Mô hình trạng thái được tách biệt một cách tự nhiên: Solana áp 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 để đạt được mục tiêu xác định xung đột tĩnh và hỗ trợ lập lịch đồng thời ở cấp độ giao dịch;
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 đồ thị đồng thời tĩnh; Sei v2 tích hợp một công cụ khớp lệnh đa luồng và một mô-đun VM song song.
Tất nhiên, loại Chuỗi bản địa này cũng phải đối mặt với những thách thức về khả năng tương thích sinh thái. Kiến trúc không phải EVM thường yêu cầu ngôn ngữ phát triển mới (như Move và Rust) và Chuỗi công cụ, gây ra một số chi phí di chuyển cho các nhà phát triển. Ngoài ra, các nhà phát triển cũng cần nắm vững sê-ri các khái niệm mới như mô hình truy cập trạng thái, hạn chế đồng thời và vòng đời đối tượng, đặt ra yêu cầu cao hơn về việc hiểu ngưỡng và mô hình phát triển.
3.1 Nguyên lý động cơ song song Sealevel dựa trên 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 và là công cụ cốt lõi Solana để triển khai thực thi giao dịch song song trong Chuỗi. Nó đạ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 thi đ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 tính năng lập lịch đồng thời trong Chuỗi ở hoàn cảnh sản xuất. Ý tưởng kiến trúc của nó đã ảnh hưởng đến nhiều dự án điện toán song song sau này và là mô hình tham khảo cho thiết kế song song Lớp 1 hiệu suất cao.
Cơ học 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 các tài khoản (đọc/ghi) liên quan khi giao dịch được gửi đi và hệ thống sẽ sử dụng thông tin này để 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 các tập hợp tài khoản được truy cập bởi hai giao dịch không có điểm giao nhau → chúng có thể được thực hiện song song;
Nếu có xung đột, hãy thực hiện tuần tự theo thứ tự phụ thuộc;
Bộ lập lịch sẽ chỉ định các giao dịch cho các luồng khác nhau dựa trên biểu đồ phụ thuộc.
3. Bối cảnh thực thi độc lập (Bối cảnh gọi chương trình): Mỗi lệnh gọi hợp đồng chạy trong một bối cảnh bị cô lập, không có ngăn xếp dùng chung, để tránh nhiễu lệnh gọi chéo.
SealevelSealevel là công cụ lập lịch thực thi song song của Solana và SVM là hoàn cảnh 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 cho hệ thống thực thi song song hiệu suất cao 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 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 di chuyển lớp thực thi Solana (Sealevel + SVM) khỏi mainnet Solana và di chuyển nó sang kiến trúc mô-đun , mô-đun "mô hình thực thi siêu đồng thời" của Solana thành Lớp thực thi dưới dạng dịch vụ. Do đó, Eclipse cũng thuộc thể loại điện toán song song.
Neon có một lộ trình khác, đưa EVM vào hoàn cảnh SVM/Sealevel. Xây dựng lớp thời gian chạy 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 chúng trong hoàn cảnh SVM, nhưng việc thực hiện lập lịch sử dụng SVM + Sealeve. Neon thiên về loại blockchain mô-đun hơn và không nhấn mạnh vào cải tiến điện toán song song.
Tóm lại, Solana và SVM dựa vào công cụ thực thi Sealevel. Triết lý lập lịch hệ điều hành Solana tương tự như trình lập lịch hạt nhân, thực thi nhanh nhưng có tính linh hoạt tương đối thấp. Đây là chuỗi chuỗi công khai song hiệu suất cao.
3.2 Kiến trúc MoveVM: Trình điều khiển tài nguyên và đối tượng
MoveVM là máy ảo hợp đồng thông minh được thiết kế để bảo mật tài nguyên Chuỗi và thực thi song song. Ngôn ngữ cốt lõi Move ban đầu được Meta (trước đây là Facebook) phát triển cho dự án Libra. Nó nhấn mạnh khái niệm "tài nguyên như đối tượng". Tất cả các trạng thái Chuỗi đều tồn tại dưới dạng các đối tượng có 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 hay không, triển khai lập lịch song song tĩnh cấp đối tượng và được sử dụng rộng rãi trong chuỗi công khai 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 bắt nguồn từ phương pháp 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ông giống như 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 kết hợp hệ thống kiểu tuyến tính của MoveVM để biến việc lập lịch song song thành một quy 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à cơ sở của kiến trúc song song Sui . Sui tóm tắt tất cả các 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ó 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à một định nghĩa kiểu. Các đối tượng này không chia sẻ trạng thái với nhau và được cô lập tự nhiên. Khi gọi hợp đồng, tập hợp các đối tượng liên quan phải được khai báo rõ ràng, tránh vấn đề liên kết 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 chia trạng thái trên Chuỗi thành nhiều đơn vị độc lập, khiến việc thực thi đồng thời trở thành điều kiện tiên quyết khả thi về mặt cấu trúc để lập lịch trình.
Phân tích quyền sở hữu tĩnh là cơ chế phân tích thời gian biên dịch được triển khai 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 suy ra 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 giao dịch được thực hiện, do đó sắp xếp chúng để thực hiện song song. So với việc phát hiện xung đột và khôi phục trong thời gian chạy truyền thống, cơ chế phân tích tĩnh của Sui làm giảm đáng kể độ phức tạp của việc lập lịch đồng thời cải thiện hiệu quả thực thi và là chìa khóa để đạt được khả năng xử lý song song xác định, thông lượng cao.
Sui chia không gian trạng thái thành các đối tượng và kết hợp nó với phân tích quyền sở hữu thời gian biên dịch để đạt được khả năng thực thi song song ở cấp độ đối tượng không cần khôi phục và có chi phí thấp. So với việc thực thi tuần tự hoặc phát hiện thời gian chạy của 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 của hệ thống và việc sử dụng tài nguyên.
Cơ chế thực hiện Aptos Block-STM
Aptos là blockchain Lớp 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ừ nền tảng Block-STM (Bộ nhớ giao dịch phần mềm cấp khối) được phát triển độc lập. 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 là cơ chế lập lịch động "đồng thời lạc quan tại thời điểm chạy + khôi phục xung đột", phù hợp để xử lý các tập giao dịch có sự phụ thuộc phức tạp.
Block-STM chia quá trình thực hiện giao dịch của một khối thành ba giai đoạn:
Thực thi đồng thời lạc quan (Thực thi suy đoán): Theo mặc định, tất cả các giao dịch đều không có xung đột trước khi thực hiện. Hệ thống lên lịch các giao dịch song song với nhiều luồng để thực hiện đồng thời và ghi lại trạng thái tài khoản (bộ đọc/bộ ghi) được truy cập.
Phát hiện và xác minh xung đột (Giai đoạn xác thực): Hệ thống xác minh kết quả thực hiện: Nếu có xung đột đọc-ghi giữa hai giao dịch (chẳng hạn như Tx1 đọc trạng thái được ghi bởi Tx2), một trong đó hai giao dịch sẽ được khôi phục.
Các giao dịch xung đột sẽ được khôi phục và thử lại (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 mối 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 đều hình thành một chuỗi gửi trạng thái hợp lệ và xác định.
Block-STM là 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 tình huống xử lý hàng loạt giao dịch trên chuỗi phức tạp về mặt logic và chuyên sâu về Chuỗi thái. Lõi điện toán song song của Aptos là xây dựng một chuỗi công khai có thông lượng cao và tính linh hoạt cao.
Solana là một trường lập lịch trình kỹ thuật, giống như một "hạt nhân hệ điều hành", phù hợp với ranh giới trạng thái rõ ràng, các giao dịch tần suất cao có thể kiểm soát được và có phong cách của một kỹ sư phần cứng, điều hành Chuỗi như phần cứng (Thực thi song song cấp phần cứng); Aptos là một trường học về khả năng chịu lỗi hệ thống, giống như một "công cụ xử lý đồng thời cơ sở dữ liệu", phù hợp với các hệ thống hợp đồng có liên kết trạng thái mạnh và Chuỗi gọi phức tạp; Sui là một trường bảo mật biên dịch, giống như một "nền tảng ngôn ngữ thông minh dựa trên tài nguyên", phù hợp với các ứng dụng trên Chuỗi với sự phân tách và kết hợp tài sản rõ ràng, Aptos và Sui sẽ giống như các kỹ sư ngôn ngữ lập trình và vận hành Chuỗi an toàn như phần mềm (Bảo mật tài nguyên cấp phần mềm). Ba phương pháp này đại diện cho các con đường 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 mở rộng song mở rộng
Sei V2 là chuỗi công khai dựa trên 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 phản ánh ở hai khía cạnh: tối ưu hóa thực thi song song của công cụ khớp lệnh đa luồng (Parallel Matching Engine) và lớp máy ảo, nhằm phục vụ các tình huống giao dịch trên Chuỗi có tần suất cao, độ trễ thấp, chẳng hạn như sổ lệnh DEX, cơ sở hạ tầng sàn giao dịch Chuỗi chuỗi, v.v.
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, phân tách sổ lệnh và logic khớp lệnh ở cấp luồng, do đó các nhiệm vụ khớp lệnh giữa nhiều thị trường (cặp giao dịch) có thể được xử lý song song để tránh tình trạng tắc nghẽn luồng đơn.
Tối ưu hóa đồng thời ở cấp độ máy ảo: Sei V2 xây dựng hoàn cảnh 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 loại giao dịch để đạt được khả năng kiểm soát thông lượng cao hơn.
Đồng thuận song song với lập lịch lớp thực thi: Giới thiệu cơ chế đồng thuận "Twin-Turbo" để tăng cường khả năng tách biệt thông lượng 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 Nhiên liệu tái tạo mô hình UTXO
Fuel là lớp thực thi hiệu suất cao được thiết kế dựa trên kiến trúc mô-đun Ethereum . Cơ chế song song cốt lõi của nó bắt nguồn từ mô hình UTXO (Đầu ra giao dịch chưa chi) được cải tiến. Không giống như mô hình tài khoản của Ethereum, Fuel sử dụng cấu trúc UTXO để biểu diễn tài sản và trạng thái. Mô hình này có tính năng cô lập trạng thái, giúp xác định dễ dàng hơn 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 còn giới thiệu ngôn ngữ hợp đồng thông minh Sway do chính mình phát triển (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 hiện giao dịch, qua đó đạt được khả năng lập lịch song song cấp giao dịch hiệu quả và an toàn. Đây là lớp thực thi thay thế EVM, tính đến cả hiệu suất và mô-đun.
IV. Mô hình diễn viên: Một mô hình mới cho việc thực hiện đồng thời các tác nhân thông minh
Mô hình Actor là mô hình thực thi song song dựa trên các tiến trình tác nhân (Tác nhân hoặc Tiến trình). Khác với tính toán đồng bộ truyền thống về 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 Chuỗi" khác), phương pháp này nhấn mạnh rằng mỗi tác nhân có 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 Chuỗi có thể được chạy đồng thời bởi lượng lớn các quy trình tách biệt, với mở rộng cực kỳ 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 (Internet Computer) và Cartesi, thúc đẩy blockchain từ một công cụ thực thi thành "hệ điều hành 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 nhiệm vụ và điều phối logic phức tạp.
Mặc dù thiết kế của Actor Model có một số điểm tương đồng với Sharding về các tính năng bề mặt (như tính song song, cô lập trạng thái và xử lý không đồng bộ), nhưng về bản chất, cả hai đại diện cho các 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 vào "tính toán không đồng bộ đa quy trình". Mỗi tác nhân (Actor) chạy độc lập, duy trì trạng thái của mình một cách độc lập và tương tác theo cách điều khiển bằng thông điệp. Sharding là cơ chế "phân chia theo chiều ngang trạng thái và sự đồng thuận" chia toàn bộ blockchain thành nhiều hệ thống con (Shard) xử lý giao dịch độc lập. Mô hình Actor giống như một "hệ điều hành tác nhân thông minh phân tán" trong thế giới Web3, trong khi 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 tính song song, nhưng có điểm khởi đầu, mục tiêu và kiến trúc thực hiện 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à nền tảng điện toán phi tập trung chạy trên lớp lưu trữ cố định Arweave . Mục tiêu cốt lõi của nó là xây dựng một hệ điều hành Chuỗi hỗ trợ hoạt động của các tác nhân thông minh không đồng bộ quy mô lớn.
Các đặc điểm 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, có trạng thái độc lập, trình lập lịch và logic thực thi độc lập;
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 phi tập trung dựa trên Arweave + công cụ thực thi điều khiển bằng tin nhắn đa tác nhân;
Hệ thống lập lịch tin nhắn không đồng bộ: Các tiến trình giao tiếp với nhau thông qua tin nhắn, sử 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;
Lưu trữ trạng thái vĩnh viễn: Tất cả trạng thái tác nhân, bản ghi tin nhắn và hướng dẫn đều được ghi lại vĩnh viễn trên Arweave , đảm bảo kiểm toán đầy đủ và tính minh bạch phi tập trung;
Agent-native: Thích hợp để triển khai nhiệm vụ phức tạp gồm nhiều bước (như AI Agent, bộ điều khiển giao thức DePIN, trình lập lịch nhiệm vụ tự động, v.v.) và có thể xây dựng "Bộ đồng xử lý AI Chuỗi".
AO áp dụng lộ trình tối ưu "kiến trúc thông minh gốc + lưu trữ + Chuỗi", nhấn mạnh vào tính linh hoạt và khả năng tách rời mô-đun. Đây là "một khuôn khổ vi hạt nhân trên Chuỗi được xây dựng trên lớp lưu trữ". Các ranh giới hệ thống được thu hẹp một cách có chủ đích, nhấn mạnh vào tính toán nhẹ + cấu trúc điều khiển có thể cấu thành.
4.2 ICP (Internet Computer), nền tảng lưu trữ Web3 đầy đủ
ICP là nền tảng ứng dụng chuỗi đầy đủ Chuỗi Web3 do DFINITY ra mắt. Mục tiêu của nó là mở rộng khả năng tính toán Chuỗi thành trải nghiệm giống như Web2 và hỗ trợ dịch vụ lưu trữ hoàn chỉnh, liên kết tên miền và kiến trúc không máy chủ.
Các đặc điểm kiến trúc cốt lõi:
Kiến trúc Canister (thùng chứa như tác nhân): Mỗi Canister là một tác nhân chạy trên Wasm VM, với trạng thái độc lập, mã 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 Canister và đạt được sự đồng thuận thông qua cơ chế chữ ký BLS;
Mô hình gọi không đồng bộ: Các hộp giao tiếp với nhau thông qua các tin nhắn không đồng bộ, hỗ trợ thực thi không chặn và 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 các trang giao diện người dùng, á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 dApp;
Hệ thống này có đầy đủ chức năng: có các API hệ thống như nâng cấp nhanh Chuỗi , danh tính xác thực, tính ngẫu nhiên phân tán, bộ đếm thời gian, v.v. và phù hợp cho việc triển khai dịch vụ phức tạp trên Chuỗi.
ICP lựa chọn mô hình hệ điều hành nhấn mạnh vào nền tảng, đóng gói tích hợp và kiểm soát nền tảng mạnh mẽ. Nó 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. Nó nhấn mạnh vào 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 nền tảng lưu trữ Web3 đầy đủ.
Ngoài ra, các dự án điện toán song song theo mô hình Actor Model khác có thể tham khảo bảng sau:
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 điện toán song song blockchain có thể được chia thành hai loại: Chuỗi nâng cao dựa trên EVM và Chuỗi kiến trúc song song gốc (không phải EVM).
Giải pháp trước đây, trong khi vẫn duy trì khả năng tương thích với hệ sinh thái EVM/Solidity, đạt được thông lượng cao hơn và khả năng xử lý song song bằng cách tối ưu hóa độ sâu lớp thực thi. Phù hợp với các kịch bản hy vọng kế thừa tài sản và công cụ phát triển Ethereum trong khi vẫn đạt được độ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 việc ghi trễ và phát hiện xung đột thời gian chạy. Sau khi hoàn tất quá trình đồng thuận, biểu đồ phụ thuộc sẽ được xây dựng và tiến hành lập lịch đa luồng.
MegaETH: Tóm tắt từng tài khoản/hợp đồng thành một máy ảo siêu nhỏ độc lập (Micro-VM) và đạt được khả năng lập lịch song song cấp tài khoản tách biệt cao dựa trên truyền thông điệp không đồng bộ và biểu đồ phụ thuộc trạng thái.
Pharos: Xây dựng kiến trúc Rollup Mesh và cộng tác với mô-đun SPN thông qua các đường ống không đồng bộ để đạt được khả năng xử lý song song ở cấp độ hệ thống trên nhiều quy trình.
Reddio: Áp dụng kiến trúc zkRollup + GPU, tập trung vào việc đẩy nhanh 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.
Phần sau hoàn toàn thoát khỏi những hạn chế về khả năng tương thích với 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 khả năng đồng thời hiệu suất cao. Các tiểu thể loại điển hình bao gồm:
Solana(dòng SVM): Dựa trên khai báo quyền truy cập tài khoản và lập lịch biểu đồ xung đột tĩnh, nó biểu diễn một mô hình thực thi song song cấp tài khoản;
Sui / Aptos(dòng 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 gian biên dịch và triển khai tính song song cấp đối tượng.
Sei V2 (tuyến đường Cosmos SDK): Giới thiệu công cụ 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 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ác tập hợp đầu vào UTXO, kết hợp với 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, với tư cách là một hệ thống song song rộng hơn, Actor Model xây dựng mô hình thực thi theo Chuỗi"hoạt động độc lập của nhiều tác nhân + cộng tác dựa trên thông điệp" thông qua cơ chế lập lịch quy trình không đồng bộ dựa trên Wasm hoặc VM 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 vi nhân không đồng bộ Chuỗi dựa trên thời gian chạy thông minh được điều khiển bằng lưu trữ liên tục;
ICP (Internet Computer): sử dụng các tác nhân thông minh được chứa trong container (Canister) làm đơn vị nhỏ nhất và đạt được khả năng thực thi không đồng bộ và mở rộng cao thông qua việc phối hợp mạng con;
Cartesi : Giới thiệu hệ điều hành Linux như một hoàn cảnh điện toán Chuỗi , cung cấp đường dẫn xác minh trên Chuỗi cho kết quả điện 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 tốn nhiều tài nguyên.
Dựa trên logic trên, chúng ta có thể tóm tắt các giải pháp chuỗi công khai chuỗi công khai chính thống hiện nay thành cấu trúc phân loại được hiển thị trong biểu đồ sau:
Theo góc nhìn rộng hơn về việc mở rộng năng lực, Sharding và Rollup (L2) tập trung vào việc đạt được mở rộng theo chiều ngang của hệ thống thông qua phân đoạn trạng thái hoặc thực thi ngoài Chuỗi , trong khi Chuỗi điện toán song song (như Monad, Sui, Solana) và các hệ thống hướng đối tượng (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 gốc trong Chuỗi hoặc ở cấp hệ thống. Phương pháp trước đây cải thiện thông lượng trong Chuỗi thông qua các máy ảo đa luồng, mô hình đối tượng, phân tích xung đột giao dịch, v.v.; phương pháp sau sử dụng các tiến trình/tác nhân làm đơn vị cơ bản, áp dụng các phương pháp thực thi không đồng bộ và dựa trên thông điệp, và thực hiện hoạt động đồng thời của nhiều tác nhân. So sánh mà nói, Sharding và Rollup giống như "chia tải trên nhiều Chuỗi" hoặc "gia công ngoài Chuỗi", trong khi Parallel Chuỗi và mô hình Actor "giải phóng tiềm năng hiệu suất khỏi chính công cụ thực thi", phản ánh hướng phát triển kiến trúc toàn diện hơn.
So sánh giữa tính toán song song với kiến trúc phân mảnh với mở rộng theo cuộn với mở rộng theo diễn viên
Cần lưu ý rằng hầu hết Chuỗi kiến trúc song song gốc đều đã bước vào giai đoạn ra mắt mạng chính. Mặc dù hệ sinh thái nhà phát triển nói chung vẫn khó có thể so sánh với hệ thống Solidity dựa trên EVM, các dự án do Solana và Sui đại diện đã trở thành chuỗi chuỗi công khai cốt lõi thu hút được nhiều sự chú ý từ thị trường do 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.
Ngược lại, mặc dù hệ sinh thái Ethereum Rollup (L2) đã bước vào giai đoạn "hàng nghìn Chuỗi được ra mắt cùng lúc" hoặc thậm chí là "quá tải", các Chuỗi nâng cao dựa trên EVM chính thống hiện tại nhìn chung vẫn đang trong giai đoạn mạng thử nghiệm và chưa thực sự được xác minh trong hoàn cảnh mainnet . Khả năng mở rộng và tính ổn định của hệ thống vẫn cần được thử nghiệm thêm. Liệu các dự án này có thể cải thiện đáng kể hiệu suất EVM mà không ảnh hưởng đến khả năng tương thích và thúc đẩy quá trình chuyển đổi sinh thái hay không, hoặc thay vào đó làm trầm trọng thêm sự khác biệt giữa thanh khoản và nguồn lực phát triển Ethereum , thì vẫn cần thời gian kiểm chứng.
