Bài viết được trích dẫn từ: Techub News
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 hiện luôn là một trong những vấn đề cần giải quyết cấp bách. 'Tầng thực hiện' của blockchain là phần xử lý mỗi giao dịch và thêm chúng vào chuỗi. Để tăng tốc khả năng xử lý, việc nâng cao ở tầng 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 trong những đột phá quan trọng ở khía cạnh này.
Các blockchain truyền thống thường xử lý giao dịch từng cái một theo cách tuần tự, điều này làm cho tốc độ giao dịch bị hạn chế rất nhiều, đặc biệt trong các mạng giao dịch dày đặc 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 một lúc, từ đó nâng cao đáng kể hiệu suất 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 điều gì là thực hiện, đồng thời hiển thị vị trí của thực hiện trong toàn bộ vòng đời giao dịch.
Các giai đoạn cụ thể của 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, Người tìm kiếm và Nhà xây dựng, hoàn thành việc lọc và sắp xếp giao dịch.
Nhà xây dựng xây dựng khối (nhưng không thực hiện): Nhà xây dựng 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.
Người đề xuất xác thực và gửi khối: Sau khi khối được xây dựng, Nhà xây dựng sẽ gửi đề xuất khối cho Người đề xuất. Người đề xuất xác thực 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 quan trọng để cập nhật trạng thái, 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 nhận của nhân chứng: Người xác thực chứng nhận kết quả thực hiện 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 tính xác thực và hiệu lực của khối ở tầng 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ộ 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 riêng mình, sau khi thực hiện từng giao dịch, nút sẽ tính toán và lưu trữ một gốc trạng thái mới, được sử dụng làm trạng thái khởi đầu cho khối tiếp theo.
Tất nhiên, đây chỉ là sự đồng bộ trạng thái của giao dịch theo từng khối, để giữ trạng thái mới nhất trên chuỗi, thường thì các nút sẽ đồng bộ dữ liệu từng khối một, và liên tục xác thực các khối và trạng thái. Nhưng để đạt được tính cuối cùng trong 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ý hoàn chỉnh và gửi nó đến người đề xuất trong Slot tiếp theo, và người 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 bầu sau một Epoch, hình 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ợ của đa số các nhân chứng, các 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 giao dịch, việc thực hiện diễn ra sau khi Người đề xuất xác thực cấu trúc và nội dung giao dịch của khối được gửi bởi Nhà xây dựng. 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 tất thực hiện, 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, quá trình thực hiện toàn bộ khối bao gồm một loạt các phép toán cần thực hiện để 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 đến việc tính toán gốc Merkle.
Thực hiện tuần tự
Ngược lại với song song là thực hiện tuần tự, tức là cách thực hiện tương đối phổ biến hiện nay trong blockchain. Thông thường, giao dịch sẽ được thực hiện từng bước theo thứ tự. Khi một giao dịch hoàn tất 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ụ như số dư, dữ liệu lưu trữ hợp đồng) lên cây trạng thái tài khoản, gốc 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 ra một gốc cây trạng thái được gọi là gốc Merkle trạng thái. Sau khi hoàn tất gốc Merkle trạng thái, gốc Merkle giao dịch và gốc Merkle biên bản, tiêu đề khối sẽ thực hiện phép toán băm, tạo ra băm khối của khối đó.
Trong đó, thứ tự thực hiện giao dịch là điều rất quan trọng. Bởi vì cây Merkle là cây nhị phân của các giá trị băm, các giá trị gốc Merkle được tạo ra từ 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 dẫn thực hiện' khác nhau để chúng có thể 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ả các giao dịch hoàn tất thực hiện, 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 mà giao dịch ảnh hưởng đến) để tạo ra một trạng thái khối mới. Trạng thái này sẽ được thêm vào chuỗi 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ì song song sẽ xử lý 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 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 đọc hoặc ghi dữ liệu (trạng thái) giống nhau 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 xác định. 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 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.
Sau đó 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.
Sau đó 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 riêng của chúng:
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 hiện đồng thời, số dư cuối cùng chỉ được 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 đã 'che phủ' kết quả của nhau, dẫn đến 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 giao dịch cố gắng sửa đổi cùng một dữ liệu đồng thời, có thể sẽ 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ể 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 trong những 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 xác định.
Để tránh sự không xác định này, hệ thống thực hiện song song của blockchain thường sẽ giới thiệu một số cơ chế kiểm tra 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 của 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ó những đá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 việc truy cập trạng thái, người xác thực hoặc người sắp xếp sẽ kiểm tra việc 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, sẽ đánh dấu các giao dịch này là xung đột, tránh thực hiện đồng thời. Cách thực hiện cụ thể của các chuỗi khác nhau trong việc tuyên bố trước trạng thái có thể khác nhau, nhưng thường bao gồm các cách 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ụ, chuyển nhượng token ERC-20 cần truy cập trường số dư của bên gửi và bên nhận.
Thông qua cấu trúc dữ liệu giao dịch có khai báo: 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 biên dịch: Trình biên dịch ngôn ngữ cấp 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 nhà phát triển 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ẽ xử lý giao dịch một cách lạc quan trước, 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 xung đột càng nhiều càng tốt, thiết kế cốt lõi của song song lạc quan là dự đoán và giả định trạng thái một cách nhanh chóng 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 cần xác minh hoàn toàn, nhằm tránh 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 bằng cách đưa ra một số dự đoán và giả định nhanh chóng về 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 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 đáng kể hiệu suất của hệ thống và tăng tiêu tốn tài nguyên tính toán.
Song song xác định sẽ kiểm tra phụ thuộc trạng thái trước khi giao dịch để tránh các xung đột có thể xảy ra trong song song lạc quan, nhưng vì cần 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 đối với nhà phát triển, do đó làm tăng độ phức tạp của việc thực hiện.
Vấn đề song song EVM
Đối phó với xung đột trạng thái không chỉ có phân định 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 độ cấu trúc cơ sở dữ liệu chuỗi. Vấn đề xung đột trạng thái trong song song 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 một dữ liệu trạng thái nào đó, gốc băm 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 lớp từ nút lá lên đế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 khi thay đổi dữ liệu của lớp dưới hoàn tất, đặc tính này làm cho 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 (chẳng hạn như số dư tài khoản), sẽ gây ra xung đột trên các nút của cây Merkle. Và giải quyết loại 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 một giá trị gốc băm nhất quán có thể thu được trong nhiều nhánh. Điều này không dễ dàng thực hiện đối với EVM, vì nó cần phải thỏa hiệp giữa việc song song hóa và tính nhất quán của 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, được lưu trữ trong sổ cái, vì vậy 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 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) tại thời điểm 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. Bởi vì giao dịch đã 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, giao dịch nào có thể thực hiện 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à đạt được cơ sở cho việc lập lịch song song.
Vì mỗi giao dịch đã tuyên bố trước 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 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 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 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 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 thường xuyên cầ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, 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. Aptos thì 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ới 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, không xảy ra xung đột khóa, có thể hoàn toàn thực hiện song song.
Cấu trúc dữ liệu cơ bản 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ó cấu trúc cây nhị phân hoàn chỉnh, cấu trúc này làm giảm đáng kể thời gian xác thực. Và mỗi tài khoản có vị trí cố định trong cây, 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 cần phải cung cấp trước tất cả các phụ thuộc của tài khoản được tuyên bố. Để làm điều đó, Aptos sử dụng Block-STM, Block-STM sẽ sử dụng thứ tự giao dịch đã được thiết lập để ước tính phụ thuộc, từ đó giảm số lần ngừng.
EVM song song
So với không phải EVM song song, EVM song song phải đối mặt với những khó khăn kỹ thuật lớn hơn trong việc xử lý phụ thuộc trạng thái, kiểm tra 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) và cách họ giải quyết những vấn đề này.
Sui
Sui cũng giống như Aptos, sử dụng mô hình đối tượng để xử lý trạng thái, lấy mỗi đối tượng (ví dụ: tài khoản, trạng thái hợp đồng thông minh) như một tài nguyên độc lập, các đối tượng này được phân biệt bằng mã nhận dạng 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, nhưng để tương thích với EVM, kiến trúc của Sui đã sử dụng thêm lớp thích ứng hoặc cơ chế trừu tượng để liên kết mô hình đối tượng với 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 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ừ đó 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 giữa các giao dịch, cần quay lại một số 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 không phải EVM song song (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 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ó mối quan hệ phụ thuộc, việ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, 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 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 vùng, mỗi 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 thay đổi các phân đoạ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 xác định trạng thái trong vùng, giảm thiểu tương tác giữa các vùng.
Tóm tắt
Cốt lõi của song song là cải thiện hiệu suất thực hiện của tầng thực hiện bằng cách thực hiện theo nhiều đường dẫn, và để đạt được thực hiện theo nhiều đường dẫn, chuỗi cần thực hiện một loạt các kiểm tra 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 của 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 tầng thực hiện không chỉ giới hạn trong cách thức song song, mà còn có thể thông qua việc giảm các thao tác đọc/ghi tới cơ sở dữ liệu mà một giao dịch yêu cầu. Trong khi đó, việc nâng cao 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 nâng cao hiệu suất của tầng đồ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, quyết định cuối cùng 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 nhà phát triển hay không, 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 càng nhiều càng tốt, ít nhất là đối với Ethereum, song song không thật sự hấp dẫn như vậy; nếu chỉ từ góc độ nâng cao hiệu suất mà xem xét, việc thêm song song đối với 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 trung tâm Rollup hiện tại của Ethereum.
