Tác giả: Tia, Techub News
Blockchain đã hy sinh hiệu suất vì thiết kế phi tập trung của nó, do đó 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. 'Lớp thực hiện' 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 khả năng xử lý, nâng cao lớp thực hiện đã trở thành một trong những chiến lược cốt lõi, trong đó thực hiện song song chính là một bước đột phá quan trọng trong lĩnh vực này.
Các blockchain truyền thống thường sử dụng cách xử lý giao dịch từng bước 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 hiện song song, nhiều giao dịch có thể được xử lý đồng thời, từ đó nâng cao hiệu quả thực hiện và giảm bớt áp lực trên chuỗi.
Để hiểu rõ hơn về điều 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 về điều gì là 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 khía cạnh cụ thể của việc thực hiện giao dịch
Giao dịch vào bộ nhớ tạm 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 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 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 minh 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 minh cấu trúc và nội dung giao dịch của khối, 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 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.
Chứng kiến của nhân chứng: các xác thực chứng kiến 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 có tính xác thực và hiệu quả trong lớp thực hiện 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ộ hóa 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à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 gốc trạng thái mới, để sử dụng làm trạng thái ban đầu trong khối tiếp theo.
Tất nhiên, đây chỉ là việc đồng bộ trạng thái của giao dịch theo từng khối. Để duy trì trạng thái trên chuỗi mới nhất, thường thì 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 nhà tổng hợp cần tổng hợp chữ ký của các nhân chứng trong mỗi Slot thành một chữ ký đầy đủ và chuyển nó đến người đề xuất của Slot tiếp theo, và các 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 đó dựa trên số lượng phiếu sau khi qua 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ự ủng hộ của đa số các xác thực, cá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 Proposer xác minh cấu trúc khối và nội dung giao dịch mà Builder gửi. 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 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, Proposer sẽ tính toán ra 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 một loạt các phép tính cần hoàn thành trong quá trình biến Ethereum từ trạng thái trước đó thành 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à phương thức thực hiện phổ biến hiện nay trong blockchain. Thông thường, các giao dịch sẽ được thực hiện từng bước theo thứ tự. Sau 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, tạo ra một băm trạng thái tài khoản mới. Khi tất cả cây trạng thái tài khoản hoàn thành cập nhật, sẽ hình thành băm của nút gốc trạng thái được gọi là gốc Merkle của trạng thái. Sau khi hoàn thành gốc Merkle của trạng thái, gốc Merkle của giao dịch và gốc Merkle của 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 đó.
Và trong đó, thứ tự thực hiện của giao dịch là rất quan trọng. Bởi vì cây Merkle là một cây nhị phân của các giá trị băm, giá trị gốc Merkle hình thành dưới 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 xử lý các giao dịch trong khối một cách song song. Không phải thực hiện từng giao dịch theo thứ tự mà là phân bổ các giao dịch vào các 'đường dẫn thực hiện' khác nhau, để chúng có thể thực hiện cùng một lúc. Thông qua 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, nâng cao thông lượng.
Sau khi tất cả các giao dịch hoàn thành, các nút sẽ tóm tắt 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) 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 thực hiện song song sẽ xử lý giao dịch trên các đường dẫn khác nhau cùng một lúc, do đó 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 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) trên blockchain. Nếu không xử lý đúng cách, điều này có thể dẫn đến kết quả thực hiện không chắc chắn. 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ư ban đầu của tài khoản 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 thêm 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 thêm 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 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 mình:
Giao dịch A đọc số dư là 100, sau khi tính toán cập nhật số dư là 110.
Giao dịch B cũng đọc số dư là 100, sau khi tính toán cập nhật số dư là 120.
Trong trường hợp này, do các giao dịch thực hiện đồng thời, số dư cuối cùng chỉ cập nhật thành 120, chứ không phải 130, vì các thao tác của giao dịch A và giao dịch B đã 'phủ' lên kết quả của nhau, tạo ra xung đột trạng thái.
Vấn đề xung đột trạng thái kiểu này thường được gọi là 'ghi đè dữ liệu', tức là khi một giao dịch cố gắng sửa đổi cùng một dữ liệu cùng lúc, có thể làm ghi đè 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. Bởi vì nhiều giao dịch hoàn thành thao tác ở các thời điểm khác nhau, sẽ tạo 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, hệ thống thực hiện song song blockchain thường sẽ giới thiệu một số cơ chế phát hiện xung đột và quay lại, hoặc phân tích sự phụ thuộc của 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 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 khai báo trước tình trạng truy cập, các xác thực hoặc sequencer sẽ kiểm tra trạng thái truy cập đã được khai báo 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 đó 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 khác nhau trong việc khai báo trạng thái truy cập trước, nhưng thường bao gồm các phương thức sau:
Thông qua quy định hợp đồng: các 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ụ, chuyển khoản 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 khai báo dữ liệu giao dịch có cấu trúc: thêm các trường chuyên dụng vào giao dịch để đánh dấu truy cập trạng thái.
Thông qua phân tích biên dịch: biên dịch của ngôn ngữ bậc cao có thể phân tích tĩnh mã hợp đồng và 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 trước một cách lạc quan, và 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 càng nhiều xung đột càng tốt, cốt lõi của thiết kế song song lạc quan là phán đoán và giả định nhanh chóng về trạng thái thông qua dữ liệu lịch sử, phân tích tĩnh, v.v. 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, để 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ể tránh xung đột xảy ra bằng một số phán đ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 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 đáng kể hiệu suất hệ thống và tăng tiêu thụ tài nguyên tính toán.
Song song xác định tránh được các tình huống xung đột có thể xảy ra trong song song lạc quan bằng cách kiểm tra phụ thuộc trạng thái trước giao dịch, nhưng vì cần phải khai báo chính xác phụ thuộc trạng thái trước khi gửi giao dịch, đ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.
Cạm bẫy song song EVM
Việc xử lý 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 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 là rất khó khăn trong EVM dưới cấu 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 nào đó, giá trị băm gốc của cây Merkle cũng cần phải được cập nhật. Quá trình cập nhật này là đệ quy, tính toán từ các nút lá lên đến nút gốc. Vì băm là không thể đảo ngược, nghĩa là chỉ khi việc thay đổi dữ liệu ở các tầng dưới hoàn thành mới có thể tính toán các tầng trên, đặc tính 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 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 trong nhiều nhánh đều có thể nhận được giá trị băm gốc nhất quán. Điều này không dễ thực hiện đối với EVM, vì nó cần thực hiệ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, được lưu trong sổ cái, do đó tránh được vấn đề xung đột đường dẫn.
Solana là song song xác định. Trong Solana, mỗi giao dịch cần khai báo rõ ràng các tài khoản 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 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 giao dịch. Bởi vì các giao dịch đã khai báo rõ ràng tất cả các 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 và giao dịch nào có thể thực hiện song song một cách an toàn, từ đó đạt được lập lịch thông minh và tránh xung đột, tạo cơ sở cho lập lịch song song.
Do đó, vì mỗi giao dịch đã khai báo cá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 sự phụ thuộc tài khoản giữa các giao dịch (mô hình Sealevel). Nếu không có tài khoản đọc/ghi chung giữa các giao dịch, hệ thống có thể phân bổ chúng cho 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 cả về kiến trúc và cơ chế, chủ yếu tập trung vào mô hình tài khoản và lưu trữ trạng thái.
Ethereum cần cập nhật thường xuyên 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 được lưu trữ trong một cây trạng thái chia sẻ, 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 thông qua việc phân 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 lẫn nhau, chỉ liên kết khi có mối quan hệ tham chiếu rõ ràng. Các đối tượng không có đường dẫn cây chung, sẽ không xảy ra tình trạng cạnh tranh khóa và có thể thực hiện 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, dưới dạng các cặp khóa-giá trị độc lập. Khác với MPT của Ethereum, Jellyfish Merkle Tree ở dạng cấu trúc cây nhị phân hoàn toàn, điều này giúp đơn giản hóa đường dẫn lưu trữ và đường dẫn 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 cập nhật và tìm kiếm của nhiều tài khoản diễn ra song song.
Aptos là song song lạc quan, nó không yêu cầu khai báo trước tất cả các phụ thuộc của tài khoản. Để làm được đ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 sự phụ thuộc, từ đó giảm số lần hủy bỏ.
EVM song song
So với song song không phải EVM, EVM song song gặp nhiều khó khă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ác vấn đề 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) làm thế nào để giải quyết những vấn đề này.
Sui
Sui và Aptos giống nhau, 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 (ví dụ: tài khoản, trạng thái hợp đồng thông minh) như một nguồn 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, 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 và 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 thông qua các lớp điều chỉnh bổ sung hoặc cơ chế trừu tượng để cầu nối 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ế 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ệ cách ly trạng thái, có thể hiệu quả tránh vấn đề phụ thuộc trạng thái. Mỗi đối tượng như một nguồn 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 trade-off của phương pháp này 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 có xung đột xảy ra giữa các giao dịch, cần phải quay lại 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ì hiệu suất song song cao.
Monad
Giống như Sui, Monad cũng áp dụng 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ó phụ thuộc, và 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. Việc dự đoán cần truy cập trạng thái, trong khi cách Ethereum lưu trữ trạng thái trong cơ sở dữ liệu khiến việc truy cập trạng thái trở nên rất khó khăn. Để làm cho việc song song trong quá trình đọc trạng thái hiệu quả hơn, Monad cũng đã cải tiến cơ sở dữ liệu.
Cây trạng thái của Monad được chia theo phân vùng, mỗi phân vùng duy trì 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 phải tái xây dựng 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 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 thực hiện 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 qua nhiều đường dẫn, và để thực hiện được điều này, chuỗi cần tiến hành một loạt các cơ chế như phát hiện xung đột và quay lại để đả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, và cần cải thiện một mức độ nào đó đối với 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 ở một cách thực hiện song song, việc tối ưu hóa giai đoạn thực hiện cũng có thể được thực hiện bằng cách giảm thiểu các thao tác đọc/ghi mà một giao dịch cần tới cơ sở dữ liệu. Và phạm vi nâng cao tốc độ toàn bộ chuỗi còn rộng 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 của nó. Song song chỉ là một trong những cách để nâng cao hiệu suất, cuối cùng quyết định có sử dụng công nghệ này 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. Tầng công nghệ không phải càng nhiều càng tốt, ít nhất, đối với Ethereum, song song không thực sự hấp dẫn đến vậy, nếu chỉ xem xét từ góc độ nâng cao hiệu suất, 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 xem xét lộ trình hiện tại của Ethereum tập trung vào Rollup.
