Hành trình tối ưu hóa EVM song song qua góc nhìn Reddio
Tuyển chọn TechFlowTuyển chọn TechFlow
Hành trình tối ưu hóa EVM song song qua góc nhìn Reddio
Tổng quan về cách tiếp cận triển khai EVM song song của Reddio, lớp 2 trên Ethereum.
Chuyên sâu báo cáo Web3Tác giả: Vụ Nguyệt, Geeker web3
Chắc hẳn ai cũng biết, EVM được định vị là "bộ máy thực thi" và "môi trường thực thi hợp đồng thông minh" của Ethereum, có thể nói là một trong những thành phần cốt lõi quan trọng nhất của Ethereum. Blockchain là một mạng lưới mở bao gồm hàng ngàn nút, các thông số phần cứng giữa các nút khác nhau rất lớn. Nếu muốn hợp đồng thông minh chạy ra kết quả giống nhau trên nhiều nút khác nhau, đảm bảo tính "nhất quán", cần tạo ra môi trường giống nhau trên các thiết bị khác nhau, và máy ảo (virtual machine) có thể đạt được hiệu quả này.
Máy ảo Ethereum (EVM) có thể thực thi hợp đồng thông minh theo cách thức giống nhau trên các hệ điều hành khác nhau (như Windows, Linux, macOS) và các thiết bị khác nhau. Tính tương thích đa nền tảng này đảm bảo rằng mỗi nút sau khi thực thi hợp đồng đều thu được kết quả như nhau. Ví dụ điển hình nhất chính là Máy ảo Java (JVM).
Hợp đồng thông minh mà chúng ta thường thấy trên trình duyệt blockchain trước tiên đều được biên dịch thành bytecode EVM, sau đó mới lưu trữ lên chuỗi. Khi EVM thực thi hợp đồng, nó đọc tuần tự các bytecode này; mỗi lệnh tương ứng với bytecode (opCode) đều có chi phí Gas tương ứng. EVM theo dõi lượng Gas tiêu thụ của từng lệnh trong quá trình thực thi, lượng tiêu thụ phụ thuộc vào độ phức tạp của thao tác.
Bên cạnh đó, với tư cách là bộ máy thực thi cốt lõi của Ethereum, EVM xử lý giao dịch theo phương pháp tuần tự, tất cả các giao dịch xếp hàng trong một hàng đợi duy nhất và lần lượt được thực thi theo thứ tự xác định. Lý do không sử dụng cách thức song song là vì blockchain phải nghiêm ngặt tuân thủ tính nhất quán – một loạt giao dịch phải được xử lý theo cùng một thứ tự trên mọi nút. Nếu xử lý giao dịch theo cách song song, sẽ khó dự đoán chính xác thứ tự giao dịch, trừ khi áp dụng thuật toán lập lịch phù hợp, nhưng điều này sẽ khá phức tạp.
Vào các năm 2014-2015, đội ngũ sáng lập Ethereum vì thời gian cấp bách đã chọn phương pháp thực thi tuần tự. Bởi vì thiết kế đơn giản và dễ bảo trì. Tuy nhiên, cùng với sự phát triển công nghệ blockchain và nhóm người dùng ngày càng lớn, yêu cầu về TPS và thông lượng của blockchain ngày càng cao. Sau khi công nghệ Rollup xuất hiện và trưởng thành, điểm nghẽn hiệu suất do EVM thực thi tuần tự gây ra đã bộc lộ rõ ràng trên các lớp Layer 2 của Ethereum.
Sequencer, với tư cách là thành phần then chốt của Layer 2, nhận toàn bộ nhiệm vụ tính toán dưới dạng một máy chủ đơn lẻ. Nếu các mô-đun bên ngoài phối hợp với Sequencer đều có hiệu suất đủ cao, thì điểm nghẽn cuối cùng sẽ phụ thuộc vào chính hiệu suất của Sequencer, lúc này việc thực thi tuần tự sẽ trở thành rào cản lớn.
Đội ngũ opBNB từng cực đại hóa tối ưu hóa tầng DA và mô-đun đọc/ghi dữ liệu, cho phép Sequencer thực thi tối đa khoảng hơn 2.000 giao dịch chuyển khoản ERC-20 mỗi giây. Con số này trông có vẻ cao, nhưng nếu các giao dịch cần xử lý phức tạp hơn nhiều so với chuyển khoản ERC-20, giá trị TPS chắc chắn sẽ giảm mạnh. Do đó, xử lý giao dịch theo hướng song song sẽ là xu thế tất yếu trong tương lai.
Dưới đây chúng tôi sẽ đi sâu vào các chi tiết cụ thể hơn để giải thích rõ ràng hơn về những hạn chế của EVM truyền thống và lợi thế của EVM song song.
Hai thành phần cốt lõi trong thực thi giao dịch Ethereum
Xét ở góc độ mô-đun mã nguồn, ngoài EVM, thành phần cốt lõi khác liên quan đến thực thi giao dịch trong go-ethereum là stateDB, dùng để quản lý trạng thái tài khoản và lưu trữ dữ liệu trong Ethereum. Ethereum sử dụng cấu trúc dạng cây gọi là Merkle Patricia Trie làm chỉ mục cơ sở dữ liệu (danh mục), mỗi lần thực thi giao dịch EVM sẽ thay đổi một số dữ liệu được lưu trong stateDB, những thay đổi này cuối cùng sẽ được phản ánh trong Merkle Patricia Trie (gọi tắt là cây trạng thái toàn cục).
Cụ thể, stateDB chịu trách nhiệm duy trì trạng thái của tất cả tài khoản Ethereum, bao gồm tài khoản EOA và tài khoản hợp đồng, dữ liệu lưu trữ bao gồm số dư tài khoản, mã hợp đồng thông minh, v.v. Trong quá trình thực thi giao dịch, stateDB thực hiện thao tác đọc/ghi dữ liệu tương ứng với tài khoản. Sau khi thực thi giao dịch xong, stateDB cần gửi trạng thái mới vào cơ sở dữ liệu nền (ví dụ LevelDB) để xử lý bền vững (persistent).
Tóm lại, EVM chịu trách nhiệm giải thích và thực thi các lệnh hợp đồng thông minh, thay đổi trạng thái trên blockchain dựa trên kết quả tính toán; còn stateDB đóng vai trò lưu trữ trạng thái toàn cục, quản lý mọi thay đổi trạng thái của tài khoản và hợp đồng. Hai thành phần này phối hợp với nhau tạo nên môi trường thực thi giao dịch của Ethereum.
Quy trình thực thi tuần tự cụ thể
Giao dịch Ethereum được chia làm hai loại: chuyển khoản EOA và giao dịch hợp đồng. Chuyển khoản EOA là loại giao dịch đơn giản nhất, tức là chuyển ETH giữa các tài khoản thông thường. Loại giao dịch này không liên quan đến việc gọi hợp đồng, tốc độ xử lý rất nhanh. Do thao tác đơn giản, phí gas cho chuyển khoản EOA cực kỳ thấp.
Khác với chuyển khoản EOA đơn giản, giao dịch hợp đồng liên quan đến việc gọi và thực thi hợp đồng thông minh. Khi xử lý giao dịch hợp đồng, EVM phải từng lệnh một giải thích và thực thi các lệnh bytecode trong hợp đồng thông minh; logic hợp đồng càng phức tạp, số lượng lệnh càng nhiều, tài nguyên tiêu hao càng lớn.
Ví dụ, thời gian xử lý chuyển khoản ERC-20 khoảng gấp đôi chuyển khoản EOA; đối với các hợp đồng thông minh phức tạp hơn như thao tác giao dịch trên Uniswap, thời gian xử lý dài hơn nhiều, thậm chí có thể chậm hơn chuyển khoản EOA tới hàng chục lần. Điều này là do các giao thức DeFi cần xử lý các logic phức tạp như pool thanh khoản, tính toán giá, hoán đổi token khi giao dịch, đòi hỏi tính toán rất phức tạp.
Vậy trong mô hình thực thi tuần tự, hai thành phần EVM và stateDB phối hợp xử lý giao dịch như thế nào?
Trong thiết kế của Ethereum, các giao dịch trong một khối được xử lý tuần tự theo thứ tự; mỗi giao dịch (tx) đều có một instance độc lập để thực hiện các thao tác cụ thể. Mặc dù mỗi giao dịch sử dụng một instance EVM khác nhau, nhưng tất cả các giao dịch đều phải dùng chung một cơ sở dữ liệu trạng thái, chính là stateDB.
Trong quá trình thực thi giao dịch, EVM cần liên tục tương tác với stateDB, đọc dữ liệu liên quan từ stateDB và ghi dữ liệu đã thay đổi trở lại stateDB.
Chúng ta hãy xem xét từ góc độ mã nguồn cách EVM và stateDB phối hợp thực thi giao dịch:
1. Hàm processBlock() gọi hàm Process() để xử lý các giao dịch nằm trong một khối;
2. Trong hàm Process(), một vòng lặp for được định nghĩa, có thể thấy các giao dịch được xử lý từng cái một;
3. Sau khi xử lý xong tất cả giao dịch, hàm processBlock() gọi writeBlockWithState(), tiếp đó gọi hàm statedb.Commit() để gửi kết quả thay đổi trạng thái.
Sau khi tất cả giao dịch trong một khối được thực thi xong, dữ liệu trong stateDB sẽ được Commit vào cây trạng thái toàn cục (Merkle Patricia Trie) đã đề cập ở trên, đồng thời tạo ra gốc trạng thái mới (stateRoot). Gốc trạng thái là tham số quan trọng trong mỗi khối, ghi lại "kết quả nén" của trạng thái toàn cục mới sau khi thực thi khối.
Chúng ta dễ dàng hiểu rằng điểm nghẽn của mô hình thực thi tuần tự EVM là rất rõ ràng: giao dịch phải xếp hàng theo thứ tự để thực thi; nếu xuất hiện giao dịch hợp đồng thông minh mất nhiều thời gian, các giao dịch khác chỉ có thể chờ đợi cho đến khi giao dịch đó xử lý xong, điều này rõ ràng không tận dụng đầy đủ tài nguyên phần cứng như CPU, hiệu suất bị giới hạn đáng kể.
Giải pháp tối ưu hóa đa luồng cho EVM
Nếu lấy ví dụ trong đời sống để so sánh thực thi tuần tự và thực thi song song, thì thực thi tuần tự giống như ngân hàng chỉ có một quầy giao dịch, còn EVM song song giống như ngân hàng có nhiều quầy. Ở chế độ song song, có thể mở nhiều luồng để xử lý đồng thời nhiều giao dịch, hiệu suất có thể tăng gấp vài lần, nhưng vấn đề nan giải nằm ở xung đột trạng thái.
Nếu nhiều giao dịch cùng tuyên bố sửa đổi dữ liệu của một tài khoản nào đó, khi chúng được xử lý đồng thời sẽ phát sinh xung đột. Ví dụ, một NFT chỉ có thể mint 1 cái, nhưng giao dịch 1 và giao dịch 2 đều tuyên bố muốn mint NFT đó, nếu cả hai yêu cầu đều được đáp ứng thì rõ ràng sẽ xảy ra lỗi. Cần phải xử lý phối hợp tình huống này. Trên thực tế, xung đột trạng thái xảy ra thường xuyên hơn nhiều so với ví dụ nêu trên, do đó nếu muốn xử lý giao dịch theo hướng song song, bắt buộc phải có biện pháp ứng phó với xung đột trạng thái.
Nguyên lý tối ưu hóa EVM song song của Reddio
Chúng ta có thể tham khảo cách tiếp cận tối ưu hóa EVM của dự án ZKRollup Reddio. Tư tưởng của Reddio là phân bổ một giao dịch cho mỗi luồng, và cung cấp cho mỗi luồng một cơ sở dữ liệu trạng thái tạm thời riêng biệt, gọi là pending-stateDB. Chi tiết cụ thể như sau:
1. Thực thi giao dịch song song đa luồng: Reddio thiết lập nhiều luồng để xử lý các giao dịch khác nhau đồng thời, các luồng không ảnh hưởng lẫn nhau. Điều này có thể tăng tốc độ xử lý giao dịch lên gấp nhiều lần.
2. Phân bổ cơ sở dữ liệu trạng thái tạm thời cho mỗi luồng: Reddio phân bổ cho mỗi luồng một cơ sở dữ liệu trạng thái tạm thời độc lập (pending-stateDB). Khi các luồng thực thi giao dịch, chúng sẽ không trực tiếp sửa đổi stateDB toàn cục, mà ghi tạm thời kết quả thay đổi trạng thái vào pending-stateDB.
3. Đồng bộ hóa thay đổi trạng thái: Sau khi tất cả giao dịch trong một khối được thực thi xong, EVM sẽ lần lượt đồng bộ kết quả thay đổi trạng thái được ghi trong mỗi pending-stateDB vào stateDB toàn cục. Nếu trong quá trình thực thi các giao dịch không xảy ra xung đột trạng thái, các bản ghi trong pending-stateDB có thể được hợp nhất thuận lợi vào stateDB toàn cục.
Reddio đã tối ưu hóa cách xử lý thao tác đọc/ghi nhằm đảm bảo giao dịch có thể truy cập đúng dữ liệu trạng thái và tránh xung đột.
-
Thao tác đọc: Khi một giao dịch cần đọc trạng thái, EVM đầu tiên kiểm tra ReadSet của Pending-state. Nếu ReadSet hiển thị dữ liệu cần thiết tồn tại, EVM sẽ trực tiếp đọc dữ liệu từ pending-stateDB. Nếu không tìm thấy cặp key-value tương ứng trong ReadSet, sẽ đọc dữ liệu trạng thái lịch sử từ stateDB toàn cục tương ứng với khối trước đó.
-
Thao tác ghi: Tất cả thao tác ghi (tức là thay đổi trạng thái) sẽ không ghi trực tiếp vào stateDB toàn cục, mà trước tiên ghi vào WriteSet của Pending-state. Sau khi hoàn thành thực thi giao dịch, sẽ thử hợp nhất kết quả thay đổi trạng thái vào stateDB toàn cục thông qua kiểm tra xung đột.
Vấn đề then chốt của thực thi song song nằm ở xung đột trạng thái, điều này đặc biệt nổi bật khi nhiều giao dịch cố gắng đọc/ghi trạng thái của cùng một tài khoản. Vì vậy, Reddio đã đưa ra cơ chế kiểm tra xung đột:
-
Kiểm tra xung đột: Trong quá trình thực thi giao dịch, EVM theo dõi ReadSet và WriteSet của các giao dịch khác nhau. Nếu phát hiện nhiều giao dịch đang cố gắng đọc/ghi cùng một mục trạng thái, sẽ coi là xảy ra xung đột.
-
Xử lý xung đột: Khi phát hiện xung đột, các giao dịch xung đột sẽ được đánh dấu là cần thực thi lại.
Sau khi tất cả giao dịch được thực thi xong, các bản ghi thay đổi trong nhiều pending-stateDB sẽ được hợp nhất vào stateDB toàn cục. Nếu hợp nhất thành công, EVM sẽ gửi trạng thái cuối cùng vào cây trạng thái toàn cục và tạo ra gốc trạng thái mới.
Hiệu quả cải thiện hiệu suất nhờ tối ưu hóa đa luồng là rõ ràng, đặc biệt khi xử lý các giao dịch hợp đồng thông minh phức tạp.
Theo nghiên cứu về EVM song song, trong tải trọng xung đột thấp (ít giao dịch mâu thuẫn hoặc chiếm dụng tài nguyên giống nhau trong pool giao dịch), TPS trong bài kiểm tra chuẩn tăng khoảng 3~5 lần so với thực thi tuần tự truyền thống. Trong tải trọng xung đột cao, về lý thuyết nếu áp dụng tất cả các biện pháp tối ưu hóa thậm chí có thể đạt mức tăng 60 lần.
Tổng kết
Giải pháp tối ưu hóa EVM đa luồng song song của Reddio, bằng cách phân bổ cơ sở dữ liệu trạng thái tạm thời cho mỗi giao dịch và thực thi giao dịch song song trên các luồng khác nhau, đã nâng cao đáng kể khả năng xử lý giao dịch của EVM. Thông qua việc tối ưu hóa thao tác đọc/ghi và giới thiệu cơ chế kiểm tra xung đột, các chuỗi công khai dựa trên EVM có thể đạt được xử lý song song quy mô lớn trong khi vẫn đảm bảo tính nhất quán trạng thái, giải quyết điểm nghẽn hiệu suất do mô hình thực thi tuần tự truyền thống gây ra. Điều này đặt nền móng quan trọng cho sự phát triển tương lai của Rollup Ethereum.
Trong các bài viết tiếp theo, chúng tôi sẽ phân tích sâu hơn các chi tiết triển khai của Reddio, chẳng hạn như cách tiếp tục tối ưu hóa hiệu quả lưu trữ để nâng cao hiệu suất, các giải pháp tối ưu khi xung đột xảy ra nhiều, cũng như cách tận dụng GPU để tối ưu hóa, v.v.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@godrealmx
