Tác giả: Tia, Techub News
Blockchain hy sinh hiệu suất vì thiết kế phi tập trung của nó, vì vậy việc nâng cao tốc độ thực thi luôn là một trong những vấn đề cần giải quyết gấp. 'Lớp thực thi' của blockchain là phần quan trọng xử lý mỗi giao dịch và thêm nó vào chuỗi. Để tăng tốc độ xử lý, việc nâng cấp trên lớp thực thi đã trở thành một trong những chiến lược cốt lõi, trong đó thực thi song song là một bước đột phá quan trọng.
Các blockchain truyền thống thường xử lý giao dịch theo cá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 các mạng có mật độ giao dịch cao sẽ gây ra tắc nghẽn. Tuy nhiên, thông qua thực thi song song, nhiều giao dịch có thể được xử lý đồng thời, từ đó cải thiện đáng kể hiệu suất thực thi và giảm bớt áp lực trên chuỗi.
Để hiểu rõ hơn về thực thi song song là gì, chúng ta sẽ bắt đầu từ thực thi và lấy Ethereum trong chế độ PBS sau Merge làm ví dụ để giải thích thực thi là gì, đồng thời hiển thị vị trí của thực thi trong toàn bộ vòng đời giao dịch.
Các giai đoạn cụ thể của thực thi giao dịch
Giao dịch vào pool bộ nhớ và được sàng lọc và phân loại: Đây là giai đoạn tiền xử lý giao dịch sau khi giao dịch được gửi, bao gồm sự tương tác giữa Mempool, Searcher và Builder, hoàn thành việc sàng lọc và phân loại giao dịch.
Builder xây dựng khối (nhưng không thực thi): Builder sắp xếp 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à phân loại giao dịch.
Proposer xác minh và gửi khối: Sau khi khối được xây dựng hoàn tất, Builder sẽ gửi đề xuất khối cho Proposer. Proposer xác minh cấu trúc của khối và nội dung giao dịch, sau đó chính thức gửi khối lên mạng để bắt đầu thực thi.
Thực thi giao dịch: Sau khi khối được gửi, các nút thực thi từng giao dịch trong khối. Đây là giai đoạn cập nhật trạng thái quan trọng, mỗi giao dịch sẽ kích hoạt gọi hợp đồng thông minh, thay đổi số dư tài khoản hoặc thay đổi trạng thái.
Người chứng kiến chứng thực: Các xác nhận viên chứng thực kết quả thực thi của khối và gốc trạng thái, và coi đây là sự xác nhận cuối cùng. Điều này đảm bảo tính xác thực và hiệu lực của khối trong lớp thực thi, đồng thời ngăn ngừa sự không nhất quán.
Đồng bộ trạng thái: Mỗi nút sẽ đồng bộ hóa kết quả thực thi 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ào trạng thái cục bộ của mình, sau mỗi giao dịch, nút tính toán và lưu trữ một gốc trạng thái mới, dùng làm trạng thái khởi đầu cho 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ộ hóa dữ liệu theo từng khối và liên tục xác minh các khối và trạng thái. Nhưng để đạt được tính cuối cùng dưới cơ chế POS, các aggregator cần phải tổng hợp chữ ký của các chứng nhân trong mỗi Slot thành một chữ ký hoàn chỉnh và truyền nó đến người đề xuất của Slot tiếp theo, và các xác nhận viên cần phải xác nhận trạng thái của tất cả các khối trong Epoch đó dựa trên số lượng phiếu bầu sau một Epoch, tạo thành một đ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ợ của đa số các xác nhận viên, 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, thực thi xảy ra sau khi Proposer xác minh cấu trúc và nội dung giao dịch của khối mà Builder đã gửi. Quy trình thực thi thực tế cần xử lý từng giao dịch và cập nhật trạng thái của tài khoản hoặc hợp đồng tương ứng. Sau khi tất cả các giao dịch thực thi xong, Proposer sẽ tính toán ra một gốc trạng thái mới (gốc Merkle), đây là tổng kết của kết quả thực thi 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 thi khối bao gồm một loạt các tính toán cần thực hiện trong quá trình chuyển đổi Ethereum từ trạng thái trước đó thành trạng thái tiếp theo, từ việc thực thi mỗi giao dịch đến tính toán gốc Merkle.
Thực thi tuần tự
Đối lập với song song là thực thi tuần tự, tức là cách thực thi tương đối phổ biến trong blockchain hiện nay. Thông thường, các giao dịch sẽ được thực thi theo thứ tự từng bước. Sau khi một giao dịch hoàn thành, Ethereum sẽ cập nhật trạng thái tài khoản và thông tin liên quan (như 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 sinh ra. Sau khi tất cả cây trạng thái tài khoản hoàn tất cập nhật, sẽ hình thành giá trị băm của nút gốc 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 nhận, tiêu đề khối sẽ thực hiện tính toán băm để tạo ra băm khối của khối đó.
Trong đó, thứ tự thực thi của 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 hình thành theo các thứ tự khác nhau sẽ khác nhau.
Thực thi song song
Trong môi trường thực thi 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 theo thứ tự từng giao dịch mà phân bổ giao dịch vào các 'đường dẫn thực thi' khác nhau, để chúng có thể thực thi đồng thời. Thông qua thực thi 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 được thực hiện hoàn tất, các nút sẽ tổng hợp kết quả thực thi (tức là các cập nhật trạng thái bị ảnh hưởng bởi giao dịch) và tạo 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
Vì thực thi song song sẽ xử lý các giao dịch trên các đường dẫn khác nhau cùng một lúc, nên một trong những khó khăn lớn nhất của thực thi song song chính là xung đột trạng thái. Nghĩa là có thể có nhiều giao dịch cùng lúc 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) trong blockchain. Nếu không được xử lý đúng cách, điều này sẽ dẫn đến kết quả thực thi 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ư tài khoản ban đầu là 100.
Nếu chúng ta thực thi tuần tự, kết quả của thứ tự thực thi là xác định:
1. Thực thi giao dịch A trước, sau đó thực thi giao dịch B:
Số dư tài khoản tăng lên 10, trở thành 110.
Tăng thêm 20, cuối cùng trở thành 130.
2. Thực thi giao dịch B trước, sau đó thực thi giao dịch A:
Số dư tài khoản tăng lên 20, trở thành 120.
Tăng thêm 10, cuối cùng trở thành 130.
Trong cả 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 trong thứ tự thực thi giao dịch.
Nhưng trong môi trường thực thi 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 mình:
Giao dịch A đọc số dư là 100, sau khi tính toán cập nhật số dư thành 110.
Giao dịch B cũng đọc 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 các giao dịch thực thi đồng thời, dẫn đến số dư cuối cùng chỉ cập nhật thành 120, thay vì 130, vì các thao tác của giao dịch A và giao dịch B đã 'bao phủ' kết quả của nhau, gây ra xung đột trạng thái.
Các vấn đề xung đột trạng thái này thường được gọi là 'bao phủ dữ liệu', tức là khi giao dịch cố gắng sửa đổi cùng một dữ liệu vào cùng một lúc, có thể sẽ bao phủ 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 vấn đề khác mà xung đột trạng thái có thể gây ra là không thể đảm bảo thứ tự thực thi. Do nhiều giao dịch hoàn thành thao tác vào những thời điểm khác nhau, sẽ dẫn đến thứ tự thực thi khác nhau. Thứ tự khác nhau có thể dẫn đến kết quả tính toán khác nhau, làm cho 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 thi song song của blockchain thường sẽ đưa vào một số cơ chế phát hiện xung đột và hoàn tác, hoặc thực hiện phân tích phụ thuộc giao dịch trước, để đảm bảo chúng thực thi đồng thời mà không ảnh hưởng đến tính nhất quán trạng thái cuối cùng.
Thực thi lạc quan và thực thi xác định
Có hai phương pháp để đối mặt với các vấn đề có thể xảy ra về xung đột trạng thái: thực thi xác định và thực thi lạc quan. Hai mô hình này có sự đánh đổi về hiệu suất và độ phức tạp thiết kế.
Thực thi xác định cần tuyên bố trước việc truy cập trạng thái, các xác nhận viên hoặc sequencer sẽ kiểm tra sự truy cập trạng thái được 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, những giao dịch này sẽ được đánh dấu là xung đột, tránh thực thi đồng thời. Các chuỗi khác nhau cụ thể thực hiện hình thức tuyên bố 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 tắc hợp đồng: Nhà phát triển quy định trực tiếp phạm vi truy cập trạng thái trong hợp đồng thông minh. Ví dụ, việc chuyển nhượng token ERC-20 cần truy cập vào trường số dư của người gửi và người nhận.
Thông qua việc khai báo dữ liệu có cấu trúc trong giao dịch: Thêm các trường chuyên dụng trong giao dịch để đánh dấu việc 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 truy cập trạng thái.
Thông qua khung yêu cầu tuyên bố: Một số khung yêu cầu nhà phát triển chỉ định rõ trạng thái cần truy cập khi gọi hàm
Thực thi lạc quan sẽ xử lý giao dịch một cách lạc quan trước, khi xung đột xảy ra, sẽ thực hiện lại các giao dịch bị ảnh hưởng theo thứ tự. Để tránh xung đột xảy ra càng nhiều càng tốt, cốt lõi của thiết kế thực thi lạc quan là thông qua dữ liệu lịch sử, phân tích tĩnh để nhanh chóng dự đoán và giả định trạng thái. Nghĩa là hệ thống, trong khi chưa hoàn toàn xác minh, giả định một số thao tác hoặc cập nhật trạng thái là hợp lệ, cố gắng tránh chờ đợi tất cả quy trình xác minh, từ đó nâng cao hiệu suất và thông lượng.
Mặc dù thực thi lạc quan có thể tránh xung đột xảy ra bằng cách nhanh chóng dự đoán và giả định một số trạng thái, nhưng vẫn sẽ 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 thi hợp đồng hoặc giao dịch xuyên chuỗi. Nếu xung đột xảy ra thường xuyên, việc thực thi lại có thể làm chậm đáng kể hiệu suất hệ thống và tăng mức tiêu thụ tài nguyên tính toán.
Thực thi xác định thì thông qua kiểm tra phụ thuộc trạng thái trước giao dịch để tránh những tình huống xung đột có thể xảy ra trong thực thi lạc quan, nhưng do cần phải tuyên bố chính xác sự phụ thuộc trạng thái trước khi giao dịch được gửi đi, điều này đặt ra yêu cầu cao hơn cho nhà phát triển, dẫn đến việc tăng độ phức tạp trong thực hiện.
Nghịch cảnh song song EVM
Đối mặt 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ũng 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 cấp, mỗi khi giao dịch sửa đổi dữ liệu 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. Quy trình cập nhật này là đệ quy, tính toán từ các nút lá lên từng lớp cho đến nút gốc. Do băm là không thể đảo ngược, nghĩa là chỉ khi thay đổi dữ liệu ở lớp dưới hoàn thành mới có thể tính toán lớp trên, đặc tính này khiến việc cập nhật song song trở nên khó khăn.
Nếu hai giao dịch thực thi song song và truy cập cùng một trạng thái (như số dư tài khoản), sẽ dẫn đến xung đột các nút cây Merkle. Việc giải quyết xung đột này thường cần 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 trong nhiều nhánh. Điều này không dễ thực hiện với EVM vì nó cần sự đánh đổi giữa song song hóa 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 dẫn.
Solana là thực thi xác định. Trong Solana, mỗi giao dịch cần tuyên bố rõ tài khoản sẽ truy cập và quyền truy cập cần thiết (chỉ đọc hoặc đọc-ghi) khi gửi đi. Thiết kế này cho phép các nút blockchain phân tích trước tài nguyên mà mỗi giao dịch cần truy cập trước khi thực thi giao dịch. Vì các giao dịch đã tuyên bố rõ tất cả các quan hệ phụ thuộc tài khoản trước khi bắt đầu thực thi, 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 thi song song một cách an toàn, từ đó thực hiện lập lịch thông minh, tránh xung đột và do đó thực hiện cơ sở của lập lịch song song.
Vì mỗi giao dịch đã tuyên bố rõ tài khoản và quyền truy cập cần thiết trước khi thực thi, Solana có thể kiểm tra xem có sự phụ thuộc tài khoản nào giữa các giao dịch hay không (mô hình Sealevel). Nếu 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 vào các bộ xử lý khác nhau để thực hiện song song.
Aptos
Thiết kế thực thi song song của Aptos rất khác với Ethereum, nó đã đưa ra một số đổi mới quan trọng về 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ả các tài khoản và trạng thái hợp đồng đượ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ỉ khi có mối quan hệ tham chiếu rõ ràng mới liên kết với nhau. Các đối tượng không có đường dẫn cây chung, không xảy ra cạnh tranh khóa, có thể hoàn toàn song song.
Cấu trúc dữ liệu cơ sở 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ó hình thức cấu trúc cây nhị phân hoàn toàn, hình thức này làm cho đường lưu trữ và đường 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. Thêm vào đó, 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 diễn ra đồng thời.
Aptos là thực thi lạc quan, nó không cần cung cấp trước tất cả các quan hệ phụ thuộc của tài khoản được tuyên bố. Để làm điều này, Aptos sử dụng Block-STM, Block-STM sẽ tận dụng thứ tự giao dịch đã được xác định để ước tính các mối quan hệ phụ thuộc, từ đó giảm số lần dừng lại.
EVM song song
So với song song không phải EVM, EVM song song phải đối mặt với độ khó kỹ thuật lớn hơn khi xử lý phụ thuộc trạng thái, phát hiện xung đột, quản lý gas và cơ chế hoàn tác. Để 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) và cách họ giải quyết các vấn đề này.
Sui
Sui cũng như Aptos, cũng sử dụng mô hình đối tượng để xử lý trạng thái, sử dụng mỗi đối tượng (chẳng hạn như tài khoản, trạng thái hợp đồng thông minh) như một tài nguyên độc lập, những đối tượng này được phân biệt thông qua đị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, những 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, 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 lớp thích ứng bổ sung hoặc cơ chế trừu tượng, để kết nối mô hình đối tượng và mô hình tài khoản EVM.
Trong Sui, việc lập lịch giao dịch sử dụng chiến lược thực thi 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ế hoàn tác để khôi phục 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ác vấn đề về phụ thuộc trạng thái. Mỗi đối tượng như một tài nguyên độc lập, các giao dịch khác nhau có thể thực thi 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ế hoàn tác. Nếu xảy ra xung đột giữa các giao dịch, cần hoàn tác một phần trạng thái, điều này sẽ 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 giống như Sui, Monad cũng áp dụng thực thi lạc quan. Nhưng thực thi lạc quan của Monad trước khi thực hiện giao dịch cụ thể vẫn sẽ dự đoán một số giao dịch có quan hệ phụ thuộc, việc dự đoán chủ yếu thông qua trình phân tích mã tĩnh của Monad để thực hiện. Việc 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 của Ethereum khiến việc truy cập trạng thái rất khó khăn, để làm cho việc thực thi 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 chia theo phân vùng, mỗi phân vùng duy trì một cây trạng thái con của riêng nó. Khi cập nhật, chỉ cần sửa đổi các phần 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 định vị trạng thái trong phân vùng, giảm thiểu sự tương tác giữa các phân vùng.
Tóm tắt
Cốt lõi của song song là nâng cao hiệu suất thực thi trên lớp thực thi bằng cách thực hiện theo nhiều đường dẫn, và để đạt được thực thi theo nhiều đường dẫn, chuỗi cần thực hiện một loạt các cơ chế như phát hiện xung đột và hoàn tác để đảm bảo chúng có thể thực hiện đồng thời 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 ở một mức độ nhất định trên cơ sở dữ liệu.
Tất nhiên, việc nâng cao hiệu suất của lớp thực thi không chỉ giới hạn ở một phương thức song song, các tối ưu hóa trong giai đoạn thực thi còn có thể được thực hiện bằng cách giảm số lượng thao tác đọc và ghi mà một giao dịch cần trên cơ sở dữ liệu. Và việc nâng tốc độ toàn bộ chuỗi liên quan đến nhiều lĩnh vực hơn, bao gồm cả việc cải thiện hiệu suất lớp đồng thuận.
Mỗi công nghệ đều có những điều kiện giới hạn riêng. Song song chỉ là một trong những cách để nâng cao hiệu suất, quyết định cuối cùng về việc sử dụng công nghệ này còn cần xem xét liệu nó có thân thiện với nhà phát triển hay không, liệu có thể hoàn thành mà không hy sinh tính phi tập trung hay không, v.v. Sự tích hợp công nghệ không phải càng nhiều càng tốt, ít nhất là đối với Ethereum, song song không phải là lựa chọn hấp dẫn như vậy, nếu chỉ từ góc độ nâng cao hiệu suất, việc thêm thực thi song song không phải là giải pháp tối ưu cho Ethereum, dù xét từ khía cạnh tính đơn giản hay theo lộ trình hiện tại của Ethereum tập trung vào Rollup.
