Chuỗi khối vì thiết kế phi tập trung của nó đã hy sinh hiệu suất, do đó việc nâng cao tốc độ thực hiện luôn là một trong những vấn đề cấp bách cần giải quyết. "Lớp thực hiện" của chuỗi khối 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 hiệu suất trong lớp thực hiện trở thành một trong những chiến lược cốt lõi, 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.
Chuỗi khối truyền thống thường sử dụng phương thức tuần tự để xử lý từng giao dịch, điều này khiến tốc độ giao dịch bị hạn chế rất lớn, đặc biệt là trong các mạng có tần suất giao dịch cao sẽ gây ra tình trạng 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ý đồng thời, từ đó nâng cao hiệu suất thực hiện một cách đáng kể và giảm áp lực trên chuỗi.
Để hiểu rõ hơn về cái gì là song song, chúng ta sẽ bắt đầu từ việc thực hiện và lấy Ethereum trong chế độ PBS sau Merge làm ví dụ, để giải thích cái gì là thực hiện, đồng thời thể hiện vị trí của thực hiện trong toàn bộ vòng đời giao dịch.
Các khía cạnh cụ thể của việc thực hiện giao dịch
Giao dịch vào 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 gửi, bao gồm sự tương tác giữ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 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à sắp xếp giao dịch.
Proposer xác thực và gửi khối: Sau khi khối được xây dựng xong, Builder sẽ gửi đề xuất khối đến Proposer. Proposer sẽ xác thực cấu trúc 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 hiện.
Thực hiện giao dịch: Sau khi khối được gửi, các nút sẽ 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.
Chứng nhân chứng kiến: Các xác thực viên sẽ chứng kiến kết quả thực hiện khối và trạng thái gốc và coi đó như là xác nhận cuối cùng. Điều này đảm bảo tính xác thực và hiệu quả của khối trong lớp thực hiện và ngăn chặn 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 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 khi thực hiện mỗi giao dịch, nút sẽ tính toán và lưu trữ một trạng thái gốc mới, để 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 đơn vị khối, để duy trì trạng thái mới nhất trên chuỗi, trong điều kiện bình thường, 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 trong cơ chế POS, các aggregator cần 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à chuyển nó đến nhà đề xuất của Slot tiếp theo, và các xác thực viên cần 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 đ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ố xác thực viên, khối và giao dịch mới đạt được tính cuối cùng.
Xét từ toàn bộ vòng đời của giao dịch, việc thực hiện xảy ra sau khi Proposer xác thực cấu trúc khối và nội dung giao dịch mà Builder gửi đến. Quá trình thực hiện thực tế cần xử lý từng giao dịch một 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 được thực hiện xong, Proposer sẽ tính toán một trạng thái gốc mới (Merkle root), đâ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, quá trình thực hiện khối hoàn chỉnh bao gồm một loạt các tính toán cần hoàn thành từ việc 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 mỗi giao dịch đến việc tính toán Merkle root.
Thực hiện theo thứ tự
Đối lập với song song là thực hiện theo thứ tự, tức là phương thức thực hiện khá phổ biến trong chuỗi khối hiện tại. Thông thường, các giao dịch sẽ được thực hiện theo thứ tự từng bước một. Khi một giao dịch hoàn tất, 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ẽ tạo thành giá trị băm gốc trạng thái được gọi là Merkle root. Sau khi hoàn tất Merkle root trạng thái, Merkle root giao dịch và Merkle root biên nhận, tiêu đề khối sẽ được tính toán băm, tạo ra giá trị băm của khối đó.
Trong đó, thứ tự thực hiện 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 tạo thành từ các 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 thực hiện 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 phối các giao dịch vào các "đường thực hiện" khác nhau, cho phép chúng thực hiện đồng thời. Thông qua việc thực hiện song song, hệ thống có thể xử lý các giao dịch trong khối một cách hiệu quả hơn, tăng thông lượng.
Sau khi tất 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 hiện (tức là cập nhật trạng thái bị ảnh hưởng bởi giao dịch), 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 chuỗi khối, đạ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 việc thực hiện song song xử lý các giao dịch trên các đường khác nhau cùng lúc, vì vậy 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 thao tác đọc hoặc ghi trên cùng một phần dữ liệu (trạng thái) trên chuỗi khối. Tình huống này nếu không được xử lý đúng cách 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 lên 10.
Giao dịch B: Tăng số dư tài khoản lên 20.
Số dư tài khoản ban đầu là 100.
Nếu chúng ta thực hiện 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 tăng trước 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 tăng trước 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 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ể đồng thời đọc số dư ban đầu là 100 và thực hiện các phép tính của riêng mình:
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.
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 các 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, chứ không phải 130, vì hoạt động của giao dịch A và giao dịch B "che khuất" 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à "che phủ dữ liệu", tức là khi các giao dịch cố gắng sửa đổi cùng một dữ liệu đồng thời, chúng có thể che 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 loại xung đột trạng thái khác có thể dẫn đến 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 hoạt động trong 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ừ đó làm cho kết quả không chắc chắn.
Để tránh sự không chắc chắn này, các hệ thống thực hiện song song trên chuỗi 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 rằng chúng có thể 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 phương pháp để 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 về hiệu suất và độ phức tạp thiết kế.
Song song xác định cần tuyên bố trước truy cập trạng thái, các xác thực viên hoặc sequencer sẽ kiểm tra 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 việc thực hiện đồng thời. Các chuỗi khác nhau có cách thực hiện khác nhau để tuyên bố truy cập trạng thái trước, nhưng thường bao gồm các hình thức sau:
Thông qua các quy định hợp đồng: Các nhà phát triển trong hợp đồng thông minh quy định trực tiếp phạm vi truy cập trạng thái. Ví dụ, việc chuyển ERC-20 token cần truy cập trường số dư của bên gửi và bên nhận.
Thông qua việc khai báo dữ liệu giao dịch có cấu trúc: Thêm các trường đặc biệt vào giao dịch để đánh dấu 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 khai báo bắt buộc của khung: Một số khung yêu cầu các nhà phát triển chỉ định rõ trạng thái cần truy cập khi gọi hàm
Song song lạc quan sẽ xử lý giao dịch một cách lạc quan trước, đến 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 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. Nghĩa là hệ thống trong trường hợp không xác minh hoàn toàn, giả định rằng một số hoạt động hoặc cập nhật trạng thái là hợp lệ, cố gắng tránh chờ đợi tất 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ể cố gắng tránh xung đột xảy ra 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 việc thực hiện 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 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ực hiện kiểm tra phụ thuộc trạng thái trước giao dịch để tránh các tình huống xung đột có thể xảy ra của 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 gửi, đ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.
Nghịch lý song song EVM
Để xử lý xung đột trạng thái không chỉ có phân loại xác định và lạc quan, trong quá trình thực hiện song song, cần phải 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 là rấ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, sau mỗi lần giao dịch sửa đổi dữ liệu trạng thái, 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ính toán từng tầng từ nút lá lên đế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 ở tầng dưới hoàn tất mới có thể tính toán tầng trên, đặc điểm này khiến việc cập nhật song song trở nên 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ẽ dẫn đến xung đột của các nút cây Merkle. Và giải quyết loại xung đột này thường cần cơ chế quản lý giao dịch bổ sung, đảm bảo rằng có thể đạt được giá trị băm gốc nhất quán trong nhiều nhánh. Điều này không dễ dàng đối với EVM, vì nó cần phải đánh đổi giữa việc 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 sử 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 tuyên bố rõ ràng 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. Thiết kế này cho phép các nút chuỗi khối có thể 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 hiện giao dịch. Bởi vì các giao dịch đã tuyên bố rõ ràng tất cả các mối 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ể an toàn thực hiện song song, từ đó thực hiện lịch trình thông minh, tránh xung đột, tạo cơ sở cho việc lập lịch song song.
Do mỗi giao dịch đã tuyên bố trước 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ó tồn tại mối quan hệ phụ thuộc tài khoản giữa các giao dịch (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 phối chúng tới 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 so với Ethereum, nó đã thực hiện một số đổi mới quan trọng về kiến trúc và cơ chế, chủ yếu thể hiện qua 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 các tài khoản, 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 các 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, không ảnh hưởng lẫn nhau, chỉ khi có quan hệ tham chiếu rõ ràng thì mới liên kết. Giữa các đối tượng không có đường đi cây chung, sẽ không có tranh chấp khóa, hoàn toàn có thể thực hiệ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ư là các cặp khóa-giá trị độc lập. Khác với MPT của Ethereum, Jellyfish Merkle Tree có dạng cấu trúc cây nhị phân hoàn toàn, dạng này giúp đơn giản hóa đường đi lưu trữ và đường đi truy vấn của các nút, 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 nhiều tài khoản cập nhật và tìm kiếm 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 để ước lượng phụ thuộc, từ đó giảm số lần ngừng lại.
EVM song song
So với việc song song không phải EVM, EVM song song phải đối mặt với những thách thức 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ế 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) làm thế nào để giải quyết những vấn đề này.
Sui
Sui và Aptos đều sử dụng mô hình đối tượng để xử lý trạng thái, với mỗi đối tượng (ví dụ: tài khoản, trạng thái hợp đồng thông minh) như là tài nguyên độc lập, các đối tượng này được phân biệt qua các đị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, 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, nhưng để tương thích với EVM, kiến trúc của Sui đã sử dụng một lớp thích nghi bổ sung hoặc cơ chế trừu tượng để 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 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ế hoàn tác để phục hồi trạng thái.
Sui sử dụng mô hình đối tượng và công nghệ cách ly trạng thái, có thể hiệu quả tránh được các vấn đề 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 hiện song song, từ đó tăng cường thông lượng và hiệu suất. Nhưng đánh đổi cho phương pháp này là sự 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 có xung đột giữa các giao dịch, cần phải 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 sử dụng phương pháp song song lạc quan. Nhưng song song 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. Dự đoán chủ yếu được thực hiện thông qua trình phân tích mã tĩnh của Monad. Dự đoán cần truy cập trạng thái, và cách mà cơ sở dữ liệu Ethereum lưu trữ trạng thái khiến việc truy cập trạng thái rất khó khăn, để làm cho quá trình đọc trạng thái trong song song 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 các 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 mình. Khi cập nhật, chỉ cần sửa đổi các phân đoạn liên quan, không cần tái xây dựng toàn bộ cây trạng thái. Bằng cách sử dụng 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 sự tương tác giữa các phân vùng.
Tóm tắt
Điểm cốt lõi của tính song song là nâng cao hiệu suất thực hiện của lớp thực hiện thông qua việc thực hiện theo nhiều con đường, và để thực hiện nhiều con đường, chuỗi cần thực hiện một loạt các cơ chế như phát hiện xung đột và cơ chế hoàn tác để đảm bảo chúng có thể thực hiện song song mà không ảnh hưởng đến tính nhất quán của trạng thái cuối cùng, và cần cải thiện mức độ nhất định của cơ sở dữ liệu.
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 ở phương thức song song, mà còn có thể được tối ưu hóa thông qua việc giảm thao tác đọc và ghi mà một giao dịch cần đối với cơ sở dữ liệu. Tuy nhiên, việc nâng cao tốc độ của toàn bộ chuỗi liên quan đến nhiều khía cạnh hơn, bao gồm cả việc nâng cao hiệu suất của lớp đồng thuận.
Mỗi công nghệ đều có những điều kiện hạn chế riêng. Song song chỉ là một trong những cách nâng cao hiệu suất, việc quyết định có sử dụng công nghệ đó hay không còn cần xem xét liệu nó có thân thiện với các 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. 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 phải là một lựa chọn hấp dẫn như vậy, nếu chỉ xét từ góc độ nâng cao hiệu suất, việc thêm song song vào Ethereum không phải là giải pháp tối ưu, bất kể là từ góc độ đơn giản hay từ lộ trình hiện tại của Ethereum tập trung vào Rollup.