Con đường song song của EVM: từ thực thi tuần tự đến đa luồng

Như mọi người đã biết, EVM là động cơ thực thi cốt lõi của Ethereum, chịu trách nhiệm cho việc thực thi hợp đồng thông minh. Để đảm bảo rằng các hợp đồng thông minh trên các nút khác nhau có thể nhận được kết quả thực thi giống nhau, EVM cung cấp một môi trường ảo thống nhất, giống như máy ảo Java JVM.

Hợp đồng thông minh khi được triển khai lên blockchain sẽ được biên dịch thành mã byte EVM trước. EVM trong quá trình thực hiện hợp đồng sẽ lần lượt đọc các mã byte này, 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 từng lệnh, mức tiêu thụ phụ thuộc vào độ phức tạp của thao tác.

EVM truyền thống xử lý giao dịch theo cách 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à được thực hiện theo thứ tự. Thiết kế này đơn giản và dễ bảo trì, nhưng khi số lượng người dùng tăng lên và yêu cầu về TPS cao hơn, nút thắt hiệu suất của việc thực hiện tuần tự ngày càng rõ ràng, đặc biệt là trong các giải pháp Layer 2.

Ngoài EVM, một thành phần cốt lõi khác trong việc thực hiện giao dịch 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. Mỗi lần EVM thực hiện giao dịch, nó sẽ cập nhật dữ liệu trong stateDB, những thay đổi này cuối cùng phản ánh trong cây trạng thái toàn cầu.

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

1. Các giao dịch trong một khối được xử lý từng giao dịch theo thứ tự.
2. Mỗi giao dịch sử dụng một phiên bản EVM độc lập, nhưng chia sẻ cùng một stateDB
3. Trong quá trình thực thi EVM, liên tục tương tác với stateDB, đọc và ghi dữ liệu.
4. Sau khi tất cả các giao dịch được xử lý xong, sẽ nộp các thay đổi trong stateDB vào cây trạng thái toàn cầu.

Vấn đề chính của chế độ tuần tự này là các giao dịch hợp đồng thông minh phức tạp sẽ chặn các giao dịch khác, không thể tận dụng tối đa tài nguyên phần cứng.

Để giải quyết vấn đề này, một số dự án bắt đầu khám phá các giải pháp tối ưu hóa song song cho EVM. Lấy một dự án Layer 2 làm ví dụ, ý tưởng cốt lõi của nó là phân bổ một cơ sở dữ liệu trạng thái tạm thời cho mỗi luồng (pending-stateDB):

1. Thực hiện các giao dịch khác nhau song song bằng đa luồng
2. Mỗi luồng sử dụng một pending-stateDB độc lập để ghi lại sự thay đổi trạng thái
3. Sau khi tất cả các giao dịch được thực hiện xong, sẽ đồng bộ các thay đổi trong pending-stateDB vào stateDB toàn cầu.

Giải pháp này đã xử lý đặc biệt cho các thao tác đọc và ghi:

• Hoạt động đọc ưu tiên kiểm tra pending-stateDB, nếu không có dữ liệu thì đọc global stateDB
• Các thao tác ghi được tạm thời lưu trữ trong pending-stateDB, không trực tiếp sửa đổi stateDB toàn cầu.

Để tránh xung đột trạng thái, kế hoạch này đã giới thiệu cơ chế phát hiện xung đột:

• Giám sát xem có sự chồng chéo giữa các tập đọc và ghi của các giao dịch khác nhau.
• Đánh dấu các giao dịch liên quan cần thực hiện lại khi phát hiện xung đột

Cuối cùng, hợp nhất nhiều thay đổi pending-stateDB vào stateDB toàn cầu, tạo ra gốc trạng thái mới.

Giải pháp tối ưu hóa song song này có thể tăng TPS lên 3-5 lần trong khối lượng công việc xung đột thấp. Trong trường hợp xung đột cao, lý thuyết có thể đạt được mức tăng 60 lần.

Tổng thể, việc song song hóa EVM là hướng quan trọng để nâng cao hiệu suất của Ethereum và Layer 2 của nó. Thông qua việc thực thi song song đa luồng và các công nghệ như thư viện trạng thái tạm thời, có thể nâng cao đáng kể khả năng xử lý giao dịch trong khi đảm bảo tính nhất quán. Trong tương lai, còn có thể nâng cao hiệu suất của EVM thông qua việc tối ưu hóa hiệu quả lưu trữ và cải thiện chiến lược xử lý xung đột.