Bài viết bởi: Tia, Techub News
Blockchain vì thiết kế phi tập trung của nó mà hy sinh hiệu suất, vì vậy việc nâng cao tốc độ thực hiện luôn là một trong những vấn đề cần giải quyết gấp. "Lớp thực hiện" của blockchain là phần xử lý mỗi giao dịch và thêm nó vào chuỗi. Để tăng tốc khả năng xử lý, việc nâng cao lớp thực hiện trở thành một trong những chiến lược chính, và thực hiện song song chính là một bước đột phá quan trọng trong khía cạnh này.
Blockchain truyền thống thường sử dụng phương pháp xử lý giao dịch tuần tự, điều này khiến tốc độ giao dịch bị hạn chế rất nhiều, đặc biệt trong mạng có mật độ giao dịch cao sẽ gây ra tắc nghẽn. Tuy nhiên, thông qua việc thực hiện song song, nhiều giao dịch có thể được xử lý cùng lúc, từ đó tăng cường hiệu suất thực hiện và giảm áp lực trên chuỗi.
Để hiểu rõ hơn về song song là gì, chúng ta sẽ bắt đầu từ việc thực hiện và lấy Ethereum dưới mô hình PBS sau Merge làm ví dụ để giải thích về thực hiện, đồng thời trình bày vị trí của thực hiện trong toàn bộ vòng đời giao dịch.
Các bước cụ thể trong thực hiện giao dịch
Giao dịch vào hồ bơi bộ nhớ và được lọc và sắp xếp: Đây là giai đoạn tiền xử lý sau khi giao dịch được nộp, bao gồm sự tương tác của Mempool, Searcher và Builder, hoàn thành việc lọc và sắp xếp giao dịch.
Builder xây dựng khối (nhưng không thực hiện): Builder xếp hạng các giao dịch có lợi nhuận thành một khối để hoàn thành việc đóng gói và sắp xếp các giao dịch.
Người đề xuất xác minh và nộp khối: Sau khi khối được xây dựng xong, Builder sẽ gửi đề xuất khối đến người đề xuất. Người đề xuất sẽ xác minh cấu trúc và nội dung giao dịch của khối, sau đó chính thức nộp khối lên mạng để bắt đầu thực hiện.
Thực hiện giao dịch: Sau khi khối được nộp, các nút thực hiện từng giao dịch trong khối. Đây là giai đoạn quan trọng của việc cập nhật trạng thái, mỗi giao dịch sẽ kích hoạt cuộc gọi hợp đồng thông minh, thay đổi số dư tài khoản hoặc thay đổi trạng thái.
Nhà chứng kiến chứng thực: Các nhà xác thực chứng thực kết quả thực hiện của khối và gốc trạng thái, và coi đó là xác nhận cuối cùng. Điều này đảm bảo rằng khối trong lớp thực hiện là chính xác và hợp lệ, và ngăn ngừa sự không nhất quán.
Đồng bộ trạng thái: Mỗi nút sẽ đồng bộ kết quả thực hiện của khối (như số dư tài khoản, cập nhật trạng thái hợp đồng, v.v.) với trạng thái cục bộ của nó, sau khi thực hiện mỗi giao dịch, nút sẽ tính toán và lưu trữ một gốc trạng thái mới, để sử dụng làm trạng thái khởi đầu trong khối tiếp theo.
Tất nhiên, đây chỉ là đồng bộ trạng thái giao dịch theo khối, để duy trì trạng thái trên chuỗi mới nhất, trong hầu hết các trường hợp, các nút sẽ đồng bộ dữ liệu theo từng khối và liên tục xác minh khối và trạng thái. Nhưng để đạt được tính cuối cùng dưới cơ chế POS, các tập hợp cần tổng hợp chữ ký của nhà chứng kiến trong mỗi Slot thành một chữ ký hoàn chỉnh và chuyển nó đến người đề xuất của Slot tiếp theo, và các nhà xác thực cần xác nhận trạng thái của tất cả các khối trong Epoch ấy dựa trên số lượng phiếu bầu sau một Epoch, tạo thành điểm kiểm tra trạng thái đồng thuận tạm thời. Khi hai Epoch liên tiếp nhận được sự hỗ trợ chứng kiến từ đa số các nhà xác thực, khối và giao dịch mới đạt được tính cuối cùng.
Từ toàn bộ vòng đời của giao dịch, việc thực hiện xảy ra sau khi người đề xuất xác minh cấu trúc và nội dung giao dịch của khối mà Builder gửi đến. Quá trình thực hiện thực tế cần xử lý từng giao dịch và cập nhật trạng thái của các tài khoản hoặc hợp đồng tương ứng. Sau khi tất cả các giao dịch hoàn thành, người đề xuất sẽ tính toán một gốc trạng thái mới (gốc Merkle), đây là tóm tắt kết quả thực hiện của tất cả các giao dịch trong khối hiện tại và trạng thái toàn cầu cuối cùng. Nói một cách đơn giản, toàn bộ quá trình thực hiện khối bao gồm việc hoàn thành một loạt các tính toán cần thiết để chuyển Ethereum từ trạng thái trước đó sang trạng thái tiếp theo, từ việc thực hiện từng giao dịch cho đến tính toán gốc Merkle.
Thực hiện tuần tự
Đối lập với song song là thực hiện tuần tự, tức là cách thực hiện phổ biến hiện nay trên blockchain. Thông thường, các giao dịch sẽ được thực hiện từng bước theo thứ tự. Khi một giao dịch hoàn thành thực hiện, Ethereum sẽ cập nhật trạng thái tài khoản và thông tin liên quan (ví dụ số dư, dữ liệu lưu trữ hợp đồng) vào cây trạng thái tài khoản, giá trị băm trạng thái tài khoản mới sẽ được tạo ra. Sau khi tất cả cây trạng thái tài khoản hoàn tất cập nhật, nó sẽ hình thành giá trị băm của nút gốc của cây trạng thái được gọi là gốc Merkle trạng thái. Sau khi hoàn thành gốc Merkle trạng thái, gốc Merkle giao dịch và gốc Merkle biên lai, tiêu đề khối sẽ thực hiện tính toán băm, tạo ra giá trị băm của khối đó.
Trong đó, thứ tự thực hiện giao dịch là rất quan trọng. Do cây Merkle là cây nhị phân của các giá trị băm, giá trị gốc Merkle được tạo ra theo thứ tự khác nhau sẽ khác nhau.
Thực hiện song song
Trong môi trường thực hiện song song, các nút sẽ cố gắng xử lý các giao dịch trong khối một cách song song. Không thực hiện theo thứ tự từng giao dịch một, mà phân bổ các giao dịch vào các "đường dẫn thực hiện" khác nhau, cho phép chúng thực hiện đồng thời. Thông qua thực hiện song song, hệ thống có thể xử lý các giao dịch trong khối hiệu quả hơn, nâng cao thông lượng.
Sau khi tất cả các giao dịch hoàn thành thực hiện, các nút sẽ tổng hợp kết quả thực hiện (tức là các cập nhật trạng thái bị ảnh hưởng bởi giao dịch), hình thành một trạng thái khối mới. Trạng thái này sẽ được thêm vào blockchain, đại diện cho trạng thái toàn cầu mới nhất trên chuỗi.
Xung đột trạng thái
Do song song sẽ xử lý giao dịch trên các đường dẫn khác nhau cùng lúc, nên một trong những khó khăn lớn của song song là xung đột trạng thái. Tức là có thể có nhiều giao dịch trong cùng một khoảng thời gian thực hiện các thao tác đọc hoặc ghi trên cùng một phần dữ liệu (trạng thái) trên blockchain. Nếu không xử lý đúng cách, điều này sẽ dẫn đến kết quả thực hiện không chắc chắn. Bởi vì thứ tự cập nhật trạng thái khác nhau, kết quả tính toán cuối cùng cũng sẽ khác nhau. Ví dụ,
Giả sử có hai giao dịch, giao dịch A và giao dịch B, cả hai đều cố gắng cập nhật số dư của cùng một tài khoản:
Giao dịch A: Tăng số dư tài khoản 10.
Giao dịch B: Tăng số dư tài khoản 20.
Số dư ban đầu của tài khoản là 100.
Nếu chúng ta thực hiện theo tuần tự, kết quả của thứ tự thực hiện là xác định:
1. Thực hiện giao dịch A trước, sau đó thực hiện giao dịch B:
Số dư tài khoản trước tiên tăng 10, trở thành 110.
Tăng thêm 20, cuối cùng trở thành 130.
2. Thực hiện giao dịch B trước, sau đó thực hiện giao dịch A:
Số dư tài khoản trước tiên tăng 20, trở thành 120.
Tăng thêm 10, cuối cùng trở thành 130.
Trong hai thứ tự này, số dư cuối cùng đều là 130, vì hệ thống đảm bảo tính nhất quán của thứ tự thực hiện giao dịch.
Nhưng trong môi trường thực hiện song song, giao dịch A và giao dịch B có thể cùng lúc đọc số dư ban đầu là 100 và thực hiện các phép toán của riêng chúng:
1. Giao dịch A đọc thấy số dư là 100, sau khi tính toán cập nhật số dư thành 110.
2. Giao dịch B cũng đọc thấy số dư là 100, sau khi tính toán cập nhật số dư thành 120.
Trong trường hợp này, do giao dịch thực hiện đồng thời, dẫn đến số dư cuối cùng chỉ được cập nhật thành 120, không phải 130, vì các thao tác của giao dịch A và giao dịch B "đè" lên kết quả của nhau, dẫn đến xung đột trạng thái.
Vấn đề xung đột trạng thái này thường được gọi là "đè dữ liệu", tức là khi giao dịch cố gắng cùng lúc sửa đổi cùng một dữ liệu, có thể sẽ đè lên kết quả tính toán của nhau, dẫn đến trạng thái cuối cùng không chính xác. Một loại xung đột trạng thái khác có thể gây ra vấn đề là không thể đảm bảo thứ tự thực hiện. Do nhiều giao dịch hoàn thành thao tác vào các khoảng thời gian khác nhau, sẽ gây ra thứ tự thực hiện khác nhau. Thứ tự khác nhau có thể dẫn đến kết quả tính toán khác nhau, từ đó khiến kết quả trở nên không chắc chắn.
Để tránh sự không chắc chắn này, hệ thống thực hiện song song của blockchain thường sẽ đưa ra một số cơ chế phát hiện xung đột và quay lại, hoặc phân tích phụ thuộc giao dịch trước, để đảm bảo rằng chúng thực hiện song song mà không ảnh hưởng đến tính nhất quán trạng thái cuối cùng.
Song song lạc quan và song song xác định
Có hai cách để xử lý vấn đề xung đột trạng thái có thể xảy ra: song song xác định và song song lạc quan. Hai mô hình này có sự đánh đổi riêng trong hiệu suất và độ phức tạp thiết kế.
Song song xác định cần tuyên bố trước quyền truy cập trạng thái, các nhà xác thực hoặc bộ sắp xếp sẽ kiểm tra quyền truy cập trạng thái đã tuyên bố khi sắp xếp giao dịch. Nếu có nhiều giao dịch cố gắng ghi vào cùng một trạng thái, các giao dịch này sẽ được đánh dấu là xung đột, tránh thực hiện đồng thời. Các chuỗi khác nhau có cách thực hiện cụ thể để tuyên bố quyền truy cập trạng thái trước khác nhau, nhưng thường bao gồm các phương thức sau:
Thông qua quy định quy tắc hợp đồng: Các nhà phát triển chỉ định trực tiếp phạm vi truy cập trạng thái trong hợp đồng thông minh. Ví dụ, chuyển khoản token ERC-20 cần truy cập vào các trường số dư của người gửi và người nhận.
Thông qua khai báo dữ liệu cấu trúc giao dịch: Thêm trường chuyên biệt vào giao dịch để đánh dấu quyền truy cập trạng thái.
Thông qua phân tích trình biên dịch: Trình biên dịch của ngôn ngữ cấp cao có thể phân tích tĩnh mã hợp đồng, tự động tạo ra tập hợp quyền truy cập trạng thái.
Thông qua khai báo bắt buộc của khuôn khổ: Một số khuôn khổ yêu cầu các nhà phát triển phải chỉ định rõ ràng trạng thái cần truy cập khi gọi hàm
Song song lạc quan sẽ lạc quan xử lý giao dịch trước, đợi cho đến khi xung đột xảy ra, sau đó sẽ thực hiện lại các giao dịch bị ảnh hưởng theo thứ tự. Để tránh tối đa tình huống xung đột xảy ra, cốt lõi của thiết kế song song lạc quan là thông qua dữ liệu lịch sử, phân tích tĩnh, v.v. để nhanh chóng dự đoán và giả định trạng thái. Tức là hệ thống giả định rằng một số thao tác hoặc cập nhật trạng thái là hợp lệ mà không xác minh hoàn toàn, nhằm giảm thiểu việc chờ đợi tất cả các quá trình xác minh, từ đó nâng cao hiệu suất và thông lượng.
Mặc dù song song lạc quan có thể tránh xung đột càng nhiều càng tốt thông qua một số dự đoán và giả định nhanh chóng về trạng thái, nhưng vẫn có một số thách thức không thể tránh khỏi, đặc biệt là liên quan đến thực hiện hợp đồng hoặc giao dịch chéo chuỗi, nếu xung đột xảy ra thường xuyên, việc thực hiện lại có thể làm chậm hiệu suất hệ thống một cách đáng kể và tăng mức tiêu thụ tài nguyên tính toán.
Song song xác định thì thông qua kiểm tra phụ thuộc trạng thái trước khi giao dịch để tránh các tình huống xung đột có thể xảy ra với song song lạc quan, nhưng do cần phải tuyên bố chính xác phụ thuộc trạng thái trước khi giao dịch được nộp, điều này đặt ra yêu cầu cao hơn cho các nhà phát triển, từ đó làm tăng độ phức tạp trong việc thực hiện.
Khó khăn trong việc song song EVM
Đối với xung đột trạng thái không chỉ có sự phân biệt giữa xác định và lạc quan, trong quá trình thực hiện song song cụ thể, cần xem xét từ góc độ kiến trúc cơ sở dữ liệu chuỗi. Vấn đề xung đột trạng thái trong song song đặc biệt khó khăn trong EVM dưới kiến trúc cây Merkle. Cây Merkle là một cấu trúc băm phân lớp, sau mỗi lần giao dịch sửa đổi một trạng thái nào đó, giá trị băm gốc của cây Merkle cũng cần được cập nhật. Quá trình cập nhật này là đệ quy, từ các nút lá tính toán lên từng lớp cho đến nút gốc. Do băm là không thể đảo ngược, tức là chỉ có thể tính toán lớp trên sau khi hoàn thành thay đổi dữ liệu ở lớp dưới, đặc điểm này khiến việc cập nhật song song rất khó khăn.
Nếu hai giao dịch thực hiện song song và truy cập cùng một trạng thái (như số dư tài khoản), sẽ gây ra xung đột trong các nút của cây Merkle. Và việc giải quyết xung đột này thường cần một cơ chế quản lý giao dịch bổ sung để đảm bảo rằng giá trị băm gốc nhất quán được nhận được trong nhiều nhánh. Điều này không dễ thực hiện với EVM, vì nó cần phải đưa ra sự đánh đổi giữa việc thực hiện song song và tính nhất quán trạng thái.
Giải pháp song song không phải EVM
Solana
Khác với cây trạng thái toàn cầu của Ethereum, Solana áp dụng mô hình tài khoản. Mỗi tài khoản là không gian lưu trữ độc lập, lưu trữ trong sổ cái, do đó tránh được vấn đề xung đột đường đi.
Solana là song song xác định. Trong Solana, mỗi giao dịch cần phải tuyên bố rõ ràng các tài khoản sẽ được truy cập và quyền truy cập cần thiết (chỉ đọc hoặc đọc/ghi) khi nộp. Thiết kế này cho phép các nút blockchain có thể phân tích trước các tài nguyên mà mỗi giao dịch cần truy cập trước khi thực hiện. Bởi vì các giao dịch đã rõ ràng tất cả các quan hệ phụ thuộc tài khoản trước khi bắt đầu thực hiện, các nút có thể xác định giao dịch nào sẽ truy cập cùng một tài khoản, giao dịch nào có thể thực hiện song song mà không gây ra xung đột, từ đó thực hiện lập lịch thông minh, tránh xung đột, từ đó tạo điều kiện cho lập lịch song song.
Vì mỗi giao dịch đã tuyên bố rõ ràng tài khoản và quyền truy cập cần thiết trước khi thực hiện, Solana có thể kiểm tra xem có mối quan hệ phụ thuộc tài khoản giữa các giao dịch hay không (mô hình Sealevel). Nếu giữa các giao dịch không có tài khoản đọc/ghi chung, hệ thống có thể phân bổ chúng sang các bộ xử lý khác nhau để thực hiện song song.
Aptos
Thiết kế thực hiện song song của Aptos rất khác với Ethereum, nó đã thực hiện một số đổi mới chính trong kiến trúc và cơ chế, chủ yếu thể hiện ở mô hình tài khoản và lưu trữ trạng thái.
Ethereum cần thường xuyên cập nhật cây trạng thái toàn cầu (MPT) khi thực hiện giao dịch. Tất cả trạng thái của tài khoản và hợp đồng đều được lưu trữ trong một cây trạng thái chung, bất kỳ giao dịch nào cũng cần truy cập và cập nhật một phần của cây trạng thái này. Trong khi đó, Aptos chia tài khoản thành các đơn vị trạng thái độc lập, mỗi đối tượng là một cặp khóa-giá trị độc lập, các đối tượng có thể tồn tại độc lập và không ảnh hưởng đến nhau, chỉ liên kết khi có quan hệ tham chiếu rõ ràng. Các đối tượng không có đường đi chung trong cây, không có sự cạnh tranh khóa, có thể hoàn toàn song song.
Cấu trúc dữ liệu nền tảng của Aptos là Jellyfish Merkle Tree. Trạng thái của mỗi đối tượng cuối cùng được lưu trữ trong JMT, như một cặp khóa-giá trị độc lập. Khác với MPT của Ethereum, Jellyfish Merkle Tree có một cấu trúc cây nhị phân hoàn toàn, cấu trúc này làm cho đường đi lưu trữ và đường đi truy vấn của các nút được đơn giản hóa, giảm đáng kể thời gian xác minh. Hơn nữa, vị trí của mỗi tài khoản trong cây là cố định, và các nút trong cây được lưu trữ độc lập, cho phép cập nhật và tìm kiếm nhiều tài khoản được thực hiện song song.
Aptos là song song lạc quan, nó không cần phải cung cấp trước tất cả các mối quan hệ phụ thuộc của tài khoản đã tuyên bố. Để làm điều này, Aptos sử dụng Block-STM, Block-STM sẽ sử dụng thứ tự giao dịch được thiết lập trước để ước lượng phụ thuộc, do đó giảm số lần ngắt quãng.
EVM song song
So với song song không phải EVM, song song EVM đối mặt với độ khó kỹ thuật lớn hơn trong việc xử lý phụ thuộc trạng thái, phát hiện xung đột, quản lý Gas và cơ chế quay lại. Để hiểu rõ hơn về điều này, chúng ta có thể tham khảo một số dự án EVM song song (như Sui, Monad, Canto) cách giải quyết những vấn đề này.
Sui
Sui cũng giống như Aptos, cũng sử dụng mô hình đối tượng để xử lý trạng thái, mỗi đối tượng (ví dụ như tài khoản, trạng thái hợp đồng thông minh) là tài nguyên độc lập, những đối tượng này được phân biệt bằng định danh duy nhất của đối tượng. Khi giao dịch liên quan đến các đối tượng khác nhau, các giao dịch này có thể được xử lý song song, vì chúng thao tác trên các trạng thái khác nhau và sẽ không gây ra xung đột trực tiếp.
Mặc dù Sui sử dụng mô hình đối tượng để quản lý trạng thái, tuy nhiên, để tương thích với EVM, kiến trúc của Sui thông qua các lớp điều chỉnh hoặc cơ chế trừu tượng bổ sung, để cầu nối giữa mô hình đối tượng và mô hình tài khoản của EVM.
Trong Sui, việc lập lịch các giao dịch sử dụng chiến lược song song lạc quan, giả định rằng không có xung đột giữa các giao dịch. Nếu xung đột xảy ra, hệ thống sẽ sử dụng cơ chế quay lại để phục hồi trạng thái.
Sui sử dụng mô hình đối tượng và công nghệ phân lập trạng thái, có thể hiệu quả tránh được vấn đề phụ thuộc trạng thái. Mỗi đối tượng như những tài nguyên độc lập, các giao dịch khác nhau có thể thực hiện song song, từ đó nâng cao thông lượng và hiệu suất. Nhưng phương pháp này có sự đánh đổi là độ phức tạp của mô hình đối tượng và chi phí của cơ chế quay lại. Nếu giữa các giao dịch xảy ra xung đột, cần phải quay lại một phần trạng thái, điều này sẽ làm tăng gánh nặng cho hệ thống và có thể ảnh hưởng đến hiệu suất xử lý song song. So với các hệ thống song song không phải EVM (như Solana), Sui cần nhiều tài nguyên tính toán và lưu trữ hơn để duy trì tính song song hiệu quả.
Monad
Cũng như Sui, Monad cũng áp dụng song song lạc quan. Tuy nhiên, song song lạc quan của Monad vẫn sẽ dự đoán một số giao dịch có mối quan hệ phụ thuộc trước khi thực hiện giao dịch, việc dự đoán chủ yếu được thực hiện thông qua bộ phân tích mã tĩnh của Monad. Dự đoán cần truy cập trạng thái, trong khi cách lưu trữ trạng thái trong cơ sở dữ liệu Ethereum khiến việc truy cập trạng thái rất khó khăn, để làm cho việc thực hiện song song trong quá trình đọc trạng thái hiệu quả hơn, Monad cũng đã tái cấu trúc cơ sở dữ liệu.
Cây trạng thái Monad được phân chia theo phân vùng, mỗi phân vùng duy trì cây trạng thái con riêng của nó. Khi cập nhật chỉ cần sửa đổi các mảnh liên quan mà không cần xây dựng lại toàn bộ cây trạng thái. Thông qua bảng chỉ mục trạng thái nhanh chóng xác định trạng thái trong phân vùng, giảm thiểu tương tác giữa các phân vùng.
Yêu cầu phần cứng nút TPS blockchain Máy ảo Đặc điểm Solana 65,000+ 12 lõi CPU, 256GB RAM, nút xác thực 500GB SSD, nút lưu trữ 1TB SSD, và tốt nhất là dành thêm 500 GB cho hệ điều hành Solana VM Hỗ trợ đồng thời cao, sử dụng Proof of History (PoH), thông lượng rất cao, cơ chế đồng thuận nhẹ Aptos 160,000+ 32 lõi CPU, 64GB+ RAM, 3.0 TB SSD lưu trữ Move VM Dựa trên ngôn ngữ Move, hỗ trợ thực hiện song song, tối ưu hóa thông lượng cao và độ trễ thấp Sui 120,000+ 8 lõi CPU, 128GB RAM, 4 TB NVMe SSD lưu trữ Sui VM Thực hiện song song, dựa trên mô hình tài nguyên, hỗ trợ độ trễ thấp và thông lượng cao Monad 10000+ 16 lõi CPU, 32GB RAM, 2 TB NVMe SSD lưu trữ EVM (lớp tương thích) Hiệu suất song song cao, tối ưu hóa thông lượng thông qua thực hiện bất đồng bộ và thiết kế máy ảo EVM nhẹ Ethereum (sau Merge) 30-100+ 4 lõi CPU, 32GB RAM, 4TB SSD lưu trữ EVM Nền tảng hợp đồng thông minh truyền thống, sau Merge chuyển sang Proof of Stake, vẫn hỗ trợ song song hạn chế
Tóm tắt
Cốt lõi của song song là nâng cao hiệu suất thực hiện của lớp thực hiện bằng cách thực hiện nhiều đường dẫn, và để thực hiện nhiều đường dẫn, chuỗi cần thực hiện một loạt các việc như phát hiện xung đột và cơ chế quay lại để đảm bảo chúng thực hiện song song mà không ảnh hưởng đến tính nhất quán trạng thái cuối cùng và cải thiện cơ sở dữ liệu ở một mức độ nhất định.
Tất nhiên, việc nâng cao hiệu suất của lớp thực hiện không chỉ giới hạn ở một hình thức song song, tối ưu hóa các bước thực hiện cũng có thể được thực hiện thông qua việc giảm thiểu các thao tác đọc/ghi mà một giao dịch cần đến trên cơ sở dữ liệu. Tuy nhiên, việc nâng cao tốc độ toàn bộ chuỗi có phạm vi rộng hơn, bao gồm cả việc nâng cao hiệu suất lớp đồng thuận.
Mỗi công nghệ đều có những điều kiện hạn chế đặc trưng của nó. Song song chỉ là một trong những cách nâng cao hiệu quả, quyết định cuối cùng về việc sử dụng công nghệ này cần xem xét tính thân thiện với nhà phát triển và liệu có thể thực hiện mà không hy sinh tính phi tập trung hay không, v.v. Việc xếp chồng công nghệ không phải lúc nào cũng tốt hơn, ít nhất là đối với Ethereum, song song không hấp dẫn đến vậy, nếu chỉ xem xét từ góc độ nâng cao hiệu quả, việc thêm song song không phải là giải pháp tối ưu cho Ethereum, bất kể từ góc độ đơn giản hay từ lộ trình hiện tại của Ethereum nơi Rollup là trung tâm.
