Tối ưu hóa song song EVM: Chìa khóa để vượt qua nút thắt hiệu suất

Như mọi người đã biết, EVM là một trong những thành phần cốt lõi quan trọng nhất của Ethereum, được định vị là "một động cơ thực thi" và "môi trường thực thi hợp đồng thông minh". Do chuỗi công khai là một mạng mở chứa nhiều nút, sự khác biệt về tham số phần cứng giữa các nút là rất lớn. Để đảm bảo rằng hợp đồng thông minh có thể đạt được kết quả giống nhau trên nhiều nút, đáp ứng yêu cầu "tính nhất quán", công nghệ máy ảo có thể xây dựng cùng một môi trường trên các thiết bị khác nhau.

EVM có thể chạy hợp đồng thông minh trên nhiều hệ điều hành và thiết bị theo cùng một cách, khả năng tương thích đa nền tảng này đảm bảo rằng mỗi nút sẽ nhận được kết quả nhất quán sau khi thực hiện hợp đồng. Điều này tương tự như nguyên lý của máy ảo Java JVM.

Các hợp đồng thông minh mà chúng ta thấy trên trình duyệt chuỗi khối đều được biên dịch thành mã byte EVM trước, sau đó được lưu trữ trên chuỗi. Khi EVM thực thi hợp đồng, nó sẽ đọc các mã byte này theo thứ tự, mỗi lệnh đều có chi phí Gas tương ứng. EVM sẽ theo dõi mức tiêu thụ Gas trong quá trình thực hiện mỗi lệnh, lượng tiêu thụ phụ thuộc vào độ phức tạp của thao tác.

Với tư cách là động cơ thực thi cốt lõi của Ethereum, EVM xử lý giao dịch theo cách tuần tự, tất cả các giao dịch được xếp hàng trong một hàng đợi duy nhất và được thực hiện theo thứ tự đã xác định. Lý do không áp dụng cách xử lý song song là vì blockchain cần phải đáp ứng nghiêm ngặt tính nhất quán, một lô giao dịch cần phải được xử lý theo cùng một thứ tự trên tất cả các nút. Nếu xử lý giao dịch theo cách song song, rất khó để dự đoán chính xác thứ tự giao dịch, trừ khi có sự can thiệp của các thuật toán lập lịch phức tạp.

Nhóm sáng lập Ethereum vào năm 2014-2015 vì lý do thời gian cấp bách, đã chọn thiết kế phương thức thực thi tuần tự đơn giản và dễ duy trì. Tuy nhiên, khi công nghệ blockchain phát triển và số lượng người dùng mở rộng, yêu cầu về TPS và khả năng xử lý ngày càng cao. Sau khi công nghệ Rollup trưởng thành, các nút thắt về hiệu suất do thực thi tuần tự EVM đã trở nên rõ ràng trong mạng lưới lớp hai của Ethereum.

Sequencer là thành phần chính của Layer2, đảm nhiệm tất cả các tác 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 có hiệu suất đủ cao, thì nút thắt cuối cùng sẽ phụ thuộc vào hiệu suất của chính Sequencer, lúc này việc thực hiện tuần tự sẽ trở thành một trở ngại lớn.

Một nhóm đã tối ưu hóa cực độ lớp DA và mô-đun đọc ghi dữ liệu, giúp Sequencer có thể thực hiện tối đa khoảng 2000 giao dịch chuyển ERC-20 mỗi giây. Con số này có vẻ rất 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 ERC-20, thì giá trị TPS chắc chắn sẽ giảm mạnh. Do đó, việc phân cấp xử lý giao dịch sẽ trở thành xu hướng tất yếu trong tương lai.

Tiếp theo, chúng ta sẽ đi sâu vào những hạn chế của EVM truyền thống và những lợi thế của EVM song song.

Hai thành phần cốt lõi trong việc thực thi giao dịch Ethereum

Trong cấp độ mô-đun mã, ngoài EVM, một 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, được sử 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 cây được gọi là Merkle Patricia Trie làm chỉ mục cơ sở dữ liệu. Mỗi lần thực thi giao dịch, EVM sẽ thay đổi một số dữ liệu trong stateDB, những thay đổi này cuối cùng sẽ phản ánh trong cây trạng thái toàn cầu.

stateDB chịu trách nhiệm duy trì trạng thái của tất cả cá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 được 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 hiện giao dịch, stateDB sẽ đọc và ghi dữ liệu của các tài khoản tương ứng. Sau khi thực hiện giao dịch kết thúc, stateDB cần nộp trạng thái mới vào cơ sở dữ liệu dưới để xử lý lâu dài.

Nói chung, 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, trong khi stateDB đóng vai trò là bộ lưu trữ trạng thái toàn cầu, quản lý sự thay đổi trạng thái của tất cả các tài khoản và hợp đồng. Cả hai cùng hợp tác xây dựng môi trường thực thi giao dịch của Ethereum.

quá trình thực hiện tuần tự cụ thể

Giao dịch Ethereum được chia thành 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, không liên quan đến việc gọi hợp đồng, tốc độ xử lý rất nhanh, phí gas thu được cực thấp.

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 EVM xử lý giao dịch hợp đồng, cần giải thích và thực thi từng lệnh bytecode trong hợp đồng thông minh. Logic của hợp đồng càng phức tạp, số lệnh liên quan càng nhiều, thì tài nguyên tiêu tốn càng lớn.

Ví dụ, thời gian xử lý chuyển khoản ERC-20 gấp khoảng 2 lần chuyển khoản EOA, trong khi những hợp đồng thông minh phức tạp như các thao tác giao dịch trên một DEX có mã số ( mất nhiều thời gian hơn, có thể chậm hơn chuyển khoản EOA đến mười mấy 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ư hồ thanh khoản, tính toán giá cả, trao đổi token khi giao dịch, yêu cầu phải thực hiện rất nhiều tính toán.

Trong chế độ thực thi tuần tự, quá trình EVM hợp tác với stateDB để xử lý giao dịch như sau:

Trong thiết kế Ethereum, các giao dịch trong một khối sẽ được xử lý theo thứ tự từng giao dịch một, mỗi giao dịch đều có một phiên bản độ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 các phiên bản EVM khác nhau, nhưng tất cả các giao dịch đều chia sẻ cùng một cơ sở dữ liệu trạng thái stateDB.

Trong quá trình thực hiện 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ừ đó và ghi lại dữ liệu đã thay đổi trở lại stateDB.

Từ góc độ mã, quy trình hợp tác thực hiện giao dịch của EVM và stateDB như sau:

1. processBlock)( hàm gọi Process)( để xử lý các giao dịch trong một khối.

2. Process)( hàm được định nghĩa một vòng lặp for, giao dịch được thực hiện từng bước.

3. Sau khi tất cả các giao dịch được xử lý xong, hàm processBlock)( gọi hàm writeBlockWithState)(, sau đó gọi hàm statedb.Commit)( để cam kết kết quả thay đổi trạng thái.

Khi tất cả các giao dịch trong một khối đã được thực hiện xong, dữ liệu trong stateDB sẽ được gửi đến cây trạng thái toàn cầu và tạo ra một trạng thái gốc mới. Trạng thái gốc 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ầu mới sau khi thực hiện khối.

![Lấy Reddio làm ví dụ, trình bày con đường tối ưu hóa EVM song song])https://img-cdn.gateio.im/webp-social/moments-404bb55ec4d21fe81783881149ac0ad6.webp(

Rõ ràng rằng mô hình thực thi tuần tự của EVM có những điểm nghẽn: các giao dịch phải được thực hiện theo thứ tự, nếu có 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, không thể tận dụng tối đa tài nguyên phần cứng như CPU, hiệu suất bị hạn chế khá nhiều.

Giải pháp tối ưu hóa đa luồng song song EVM

So sánh giữa thực thi tuần tự và thực thi song song, cái trước giống như một ngân hàng chỉ có một quầy, trong khi EVM song song giống như một ngân hàng có nhiều quầy. Trong chế độ song song, có thể mở nhiều luồng để xử lý nhiều giao dịch cùng lúc, hiệu suất có thể tăng gấp nhiều lần, nhưng vấn đề phải đối mặt là vấn đề xung đột trạng thái.

Nếu nhiều giao dịch đều tuyên bố muốn sửa đổi dữ liệu của một tài khoản nào đó, thì khi xử lý đồng thời sẽ phát sinh xung đột. Ví dụ, một NFT chỉ có thể được đúc một cái, và giao dịch 1 và giao dịch 2 đều muốn đúc NFT đó, nếu cả hai yêu cầu đều được đáp ứng, rõ ràng sẽ xảy ra lỗi. Trong thực tế, xung đột trạng thái thường xảy ra thường xuyên hơn, do đó việc xử lý giao dịch song song phải có biện pháp ứng phó với xung đột trạng thái.

![Lấy Reddio làm ví dụ, trình bày con đường tối ưu hóa EVM song song])https://img-cdn.gateio.im/webp-social/moments-fc9301b18b6299dc8f792e68961977cd.webp(

) Nguyên lý tối ưu hóa song song EVM của một dự án nào đó

Một dự án ZKRollup nào đó có ý tưởng tối ưu hóa song song cho EVM là phân bổ một giao dịch cho mỗi luồng, và cung cấp một cơ sở dữ liệu trạng thái tạm thời trong mỗi luồng, gọi là pending-stateDB. Chi tiết cụ thể như sau:

1. Thực hiện giao dịch song song đa luồng: 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 làm ảnh hưởng đến nhau, có thể tăng tốc độ xử lý giao dịch 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: Mỗi luồng được phân bổ cơ sở dữ liệu trạng thái tạm thời độc lập ###pending-stateDB(. Khi luồng thực hiện giao dịch, không trực tiếp sửa đổi stateDB toàn cầu, mà tạm thời ghi lại kết quả thay đổi trạng thái trong pending-stateDB.

3. Đồng bộ trạng thái thay đổi: Sau khi tất cả các giao dịch trong một khối được thực hiện xong, EVM sẽ lần lượt đồng bộ kết quả thay đổi trạng thái được ghi lại trong mỗi pending-stateDB vào stateDB toàn cầu. Nếu trong quá trình thực hiện các giao dịch khác nhau không có xung đột trạng thái, thì có thể dễ dàng hợp nhất các bản ghi trong pending-stateDB vào stateDB toàn cầu.

![Lấy Reddio làm ví dụ, trình bày con đường tối ưu hóa EVM song song])https://img-cdn.gateio.im/webp-social/moments-c62d7268de0c9ada677dc15618b1e024.webp(

Dự án đã tối ưu hóa việc xử lý các thao tác đọc và ghi, đảm bảo rằng giao dịch có thể truy cập đúng dữ liệu trạng thái và tránh xung đột:

Đọc thao tác: Khi giao dịch cần đọc trạng thái, EVM trước tiên kiểm tra ReadSet của trạng thái đang chờ. Nếu ReadSet có dữ liệu cần thiết, nó sẽ trực tiếp đọc từ pending-stateDB. Nếu ReadSet không có cặp khóa-giá trị tương ứng, nó sẽ đọc dữ liệu trạng thái lịch sử từ stateDB toàn cầu của khối trước.

Hoạt động ghi: Tất cả các hoạt động ghi ) tức là thay đổi trạng thái ( không được ghi trực tiếp vào stateDB toàn cầu, mà trước tiên được ghi vào WriteSet của trạng thái đang chờ. Sau khi giao dịch hoàn thành, thông qua kiểm tra xung đột cố gắng hợp nhất kết quả thay đổi trạng thái vào stateDB toàn cầu.

Vấn đề chính của việc thực thi song song là xung đột trạng thái, đặc biệt khi nhiều giao dịch cố gắng đọc và ghi trạng thái tài khoản giống nhau. Để giải quyết vấn đề này, cơ chế phát hiện xung đột đã được giới thiệu:

Kiểm tra xung đột: Trong quá trình thực hiện 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 cố gắng đọc và ghi cùng một mục trạng thái, thì sẽ được coi là xảy ra xung đột.

Xử lý xung đột: Khi phát hiện xung đột, giao dịch xung đột sẽ được đánh dấu là cần thực hiện lại.

Sau khi tất cả các giao dịch được thực hiện xong, nhiều bản ghi thay đổi trong pending-stateDB sẽ được hợp nhất vào stateDB toàn cầu. Nếu việc hợp nhất thành công, EVM sẽ gửi trạng thái cuối cùng đến cây trạng thái toàn cầu và tạo ra một trạng thái gốc mới.

![Lấy Reddio làm ví dụ, trình bày con đường tối ưu hóa EVM song song])https://img-cdn.gateio.im/webp-social/moments-75575d5ea4bfa2edcc71ad93d3277caf.webp(

Tối ưu hóa song song đa luồng có sự cải thiện đáng kể về hiệu suất, đặc biệt là khi xử lý các giao dịch hợp đồng thông minh phức tạp. Nghiên cứu cho thấy, trong tải công việc xung đột thấp, TPS của các bài kiểm tra chuẩn tăng 3-5 lần so với thực thi tuần tự truyền thống. Trong tải công việc xung đột cao, lý thuyết nếu áp dụng tất cả các biện pháp tối ưu, thậm chí có thể đạt được mức tăng 60 lần.

Tóm tắt

Giải pháp tối ưu hóa đa luồng EVM nêu trên, thông qua việc phân bổ thư viện trạng thái tạm thời cho mỗi giao dịch và thực hiện giao dịch song song trong các luồng khác nhau, đã nâng cao đáng kể khả năng xử lý giao dịch của EVM. Bằng cách tối ưu hóa các thao tác đọc và ghi cũng như giới thiệu cơ chế phát hiện xung đột, chuỗi công khai EVM có thể đạt được sự song song hóa quy mô lớn của giao dịch trong khi đảm bảo tính nhất quán của trạng thái, giải quyết các nút thắt về hiệu suất do mô hình thực hiện tuần tự truyền thống mang lại. Điều này đã đặt nền tảng quan trọng cho sự phát triển trong tương lai của Ethereum Rollup.

Các hướng nghiên cứu trong tương lai bao gồm: tối ưu hóa hiệu suất lưu trữ để nâng cao hiệu suất, các giải pháp tối ưu để đối phó với tình huống xung đột cao, và cách tận dụng GPU để tối ưu hóa.

![Lấy Reddio làm ví dụ, trình bày con đường tối ưu hóa EVM song song])https://img-cdn.gateio.im/webp-social/moments-6274c33f6c958750df5cf3e53949b7fb.webp(