- Chủ đề
88k Phổ biến
42k Phổ biến
14k Phổ biến
4k Phổ biến
5k Phổ biến
29k Phổ biến
16k Phổ biến
22k Phổ biến
13k Phổ biến
3k Phổ biến
- Ghim
88k Phổ biến
42k Phổ biến
14k Phổ biến
4k Phổ biến
5k Phổ biến
29k Phổ biến
16k Phổ biến
22k Phổ biến
13k Phổ biến
3k Phổ biến
Tối ưu hóa song song EVM: Lấy Reddio làm ví dụ nâng cao hiệu quả xử lý giao dịch
Con đường tối ưu hóa song song của EVM
Như mọi người đã biết, EVM là động cơ thực thi cốt lõi của Ethereum và môi trường chạy hợp đồng thông minh. Là một mạng mở bao gồm nhiều nút, chuỗi công khai phải đối mặt với thách thức về cách thực hiện sự nhất quán trên các thiết bị có thông số phần cứng khác nhau rất lớn. Công nghệ máy ảo cung cấp khả năng giải quyết vấn đề này, cho phép hợp đồng thông minh chạy theo cùng một cách trên các hệ điều hành và thiết bị khác nhau, đảm bảo tính nhất quán của kết quả.
Hợp đồng thông minh sẽ được biên dịch thành mã byte EVM trước khi được đưa lê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 thi từng lệnh, mức tiêu thụ phụ thuộc vào độ phức tạp của thao tác.
Truyền thống, EVM xử lý giao dịch theo cách tuần tự, tất cả giao dịch được xếp hàng trong một hàng đợi duy nhất và thực hiện theo thứ tự đã xác định. Thiết kế này đơn giản và dễ bảo trì, nhưng với sự phát triển của công nghệ blockchain và sự mở rộng của cộng đồng người dùng, yêu cầu về TPS và thông lượng ngày càng tăng. Sau khi công nghệ Rollup trưởng thành, nút thắt hiệu suất của EVM trong việc thực hiện tuần tự trở nên đặc biệt rõ ràng trong mạng lưới Ethereum lớp hai.
Sequencer là một thành phần quan trọng của Layer2, đảm nhận tất cả các tác vụ tính toán dưới dạng một máy chủ đơn. Nếu các mô-đun đi kèm đủ hiệu quả, thì nút cổ chai 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 rào cản lớn. Do đó, việc song song hóa xử lý giao dịch trở thành xu hướng tất yếu trong tương lai.
Thành phần cốt lõi của việc thực hiện giao dịch Ethereum
Ngoài EVM, một thành phần cốt lõi khác liên quan đến việc 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 Merkle Patricia Trie làm chỉ mục cơ sở dữ liệu. Mỗi khi một giao dịch được thực hiện, một số dữ liệu trong stateDB sẽ bị thay đổi, và 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, lưu trữ số dư tài khoản, mã hợp đồng thông minh và các dữ liệu khác. Trong quá trình thực thi giao dịch, stateDB thực hiện việc đọc và ghi dữ liệu của các tài khoản tương ứng. Sau khi thực thi giao dịch kết thúc, stateDB sẽ nộp trạng thái mới vào cơ sở dữ liệu nền tảng để thực hiện lưu trữ lâu dài.
Tổng thể mà nó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 blockchain dựa trên kết quả tính toán, trong khi stateDB là nơi 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 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 thi tuần tự cụ thể
Giao dịch trên 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, có tốc độ xử lý nhanh và phí gas 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 hợp đồng càng phức tạp, số lệnh liên quan càng nhiều, tài nguyên tiêu tốn cũng càng lớn.
Ví dụ, thời gian xử lý chuyển khoản ERC-20 khoảng gấp đôi thời gian chuyển khoản EOA, trong khi các hợp đồng thông minh phức tạp hơn, như các giao dịch trên Uniswap, có thể mất thời gian gấp mười lần so với chuyển khoản EOA. Điều này là do các giao thức DeFi cần xử lý các logic phức tạp như bể thanh khoản, tính toán giá cả, hoán đổi token khi thực hiện giao dịch, yêu cầu phải thực hiện một lượng lớn tính toán.
Trong chế độ thực thi tuần tự, quá trình hợp tác giữa EVM và stateDB như sau:
Bottleneck của chế độ thực thi tuần tự này rõ ràng: các giao dịch phải được xếp hàng thực hiện theo thứ tự, nếu gặp phải 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 triệt để tài nguyên phần cứng, hiệu suất bị hạn chế đáng kể.
Giải pháp tối ưu hóa song song đa luồng EVM
Chế độ thực thi song song có thể mở nhiều luồng để xử lý nhiều giao dịch cùng một lúc, hiệu suất có thể tăng gấp nhiều lần, nhưng đối mặt với vấn đề xung đột trạng thái. Khi nhiều giao dịch cùng tuyên bố muốn sửa đổi dữ liệu của một tài khoản nào đó, sẽ xảy ra xung đột và cần phải tiến hành xử lý phối hợp.
Nguyên lý tối ưu hóa song song
Lấy dự án ZKRollup Reddio làm ví dụ về cách tối ưu hóa song song, các đặc điểm chính của nó bao gồm:
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 cùng một lúc, các luồng không can thiệp lẫn nhau, có thể tăng tốc độ xử lý giao dịch lên nhiều lần.
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ó một cơ sở dữ liệu trạng thái tạm thời độc lập (pending-stateDB). Khi thực hiện giao dịch, kết quả thay đổi trạng thái được ghi lại tạm thời trong pending-stateDB, không sửa đổi trực tiếp stateDB toàn cục.
Đồng bộ trạng thái thay đổi: Sau khi tất cả các giao dịch trong khối được thực hiện xong, từng kết quả thay đổi trạng thái được ghi lại trong pending-stateDB sẽ được đồng bộ lần lượt vào stateDB toàn cầu.
Reddio đã tối ưu hóa việc xử lý các thao tác đọc và ghi:
Hoạt động đọc: Trước tiên kiểm tra ReadSet trong trạng thái Pending. Nếu dữ liệu cần thiết tồn tại, thì đọc trực tiếp từ pending-stateDB; nếu không, thì đọc dữ liệu trạng thái lịch sử từ stateDB toàn cầu tương ứng của khối trước đó.
Hoạt động ghi: Tất cả các hoạt động ghi được ghi lại vào WriteSet trong trạng thái Pending, sau khi giao dịch hoàn thành, sẽ cố gắng hợp nhất kết quả thay đổi trạng thái vào stateDB toàn cầu thông qua kiểm tra xung đột.
Để giải quyết vấn đề xung đột trạng thái, Reddio đã đưa ra cơ chế phát hiện xung đột:
Phát hiện xung đột: Giám sát 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ì coi như xảy ra xung đột.
Xử lý xung đột: Giao dịch xung đột đượ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 được hợp nhất vào stateDB toàn cầu. Sau khi hợp nhất thành công, trạng thái cuối cùng được gửi đến cây trạng thái toàn cầu, tạo ra một gốc trạng thái mới.
Tối ưu hóa song song đa luồng đã nâng cao hiệu suất một cách đáng kể, đặc biệt là trong việc 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 từ 3 đến 5 lần so với việc thực hiện 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 hóa, 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 song song EVM của Reddio đã cải thiện đáng kể khả năng xử lý giao dịch của EVM bằng cách 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. Bằng cách tối ưu hóa các thao tác đọc/ghi và giới thiệu cơ chế phát hiện xung đột, chuỗi công cộng EVM có thể thực hiện 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 nút thắt hiệu suất của mô hình thực thi tuần tự truyền thống. Đ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ó thể thảo luận thêm về các chi tiết thực hiện của Reddio, bao gồm cách tối ưu hóa hiệu suất lưu trữ, các giải pháp tối ưu trong trường hợp xung đột cao, và cách sử dụng GPU để tối ưu hóa.