Tối ưu hóa song song EVM: Thảo luận về con đường nâng cao hiệu suất thông qua Reddio
Như mọi người đã biết, EVM là một trong những thành phần cốt lõi nhất của Ethereum, đóng vai trò quan trọng như "động cơ thực thi" và "môi trường thực thi hợp đồng thông minh". Trong một mạng lưới mở được tạo thành từ hàng nghìn nút, cấu hình phần cứng của các nút khác nhau có thể có sự khác biệt lớn. Để đảm bảo rằng hợp đồng thông minh được thực thi nhất quán trên các nút khác nhau, công nghệ máy ảo trở thành giải pháp lý tưởng.
EVM có thể chạy hợp đồng thông minh theo cùng một cách trên các hệ điều hành và 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 đều 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ự với nguyên lý của máy ảo Java JVM.
Các hợp đồng thông minh mà chúng ta thấy trong trình duyệt blockchain đề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 hiện hợp đồng, nó sẽ đọc tuần tự các mã byte này, mỗi lệnh đều có chi phí Gas tương ứng. EVM sẽ theo dõi lượng Gas tiêu thụ trong quá trình thực hiện mỗi lệnh, và lượng tiêu thụ phụ thuộc vào mức độ 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ý các 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à thực thi theo thứ tự đã được xác định. Lý do không sử dụng phương pháp song song là vì blockchain cần đảm bảo tính nhất quán một cách nghiêm ngặt, cùng một tập hợp giao dịch 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 đưa vào các thuật toán lập lịch phức tạp.
Năm 2014-2015, đội ngũ sáng lập Ethereum do thời gian cấp bách đã chọn cách thực hiện tuần tự đơn giản và dễ bảo trì. Tuy nhiên, khi công nghệ blockchain tiến triển và cộng đồng người dùng mở rộng, yêu cầu về TPS và thông lượng ngày càng cao. Sau khi công nghệ Rollup xuất hiện và trưởng thành, những hạn chế về hiệu suất do thực hiện tuần tự EVM đã rõ ràng xuất hiện trên mạng Ethereum lớp hai.
Sequencer là thành phần chính của Layer2, đảm nhiệm tất cả các nhiệm vụ tính toán dưới dạng một máy chủ đơn lẻ. Nếu các module bên ngoài phối hợp với Sequencer đều 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 đoan lớp DA và mô-đun đọc ghi dữ liệu, khiến Sequencer có thể thực hiện tối đa khoảng 2000 giao dịch 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 giao dịch ERC-20, thì giá trị TPS chắc chắn sẽ giảm mạnh. Do đó, việc xử lý giao dịch theo chiều ngang sẽ là xu hướng tất yếu trong tương lai.
Hai thành phần cốt lõi trong 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 hiện 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 một cấu trúc cây có tên là Merkle Patricia Trie làm chỉ mục cơ sở dữ liệu, mỗi lần thực hiện giao dịch EVM sẽ thay đổi một số dữ liệu được lưu trữ trong stateDB, những thay đổi này cuối cùng sẽ được 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 phải nộp trạng thái mới vào cơ sở dữ liệu dưới để xử lý lưu trữ.
Tổng thể mà nói, EVM chịu trách nhiệm giải thích và thực hiện 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ý tất cả các thay đổi trạng thái của 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ể
Các loại giao dịch của Ethereum được chia thành 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 và phí gas thu được cũng rất thấp.
Giao dịch hợp đồng liên quan đến việc gọi và thực hiện hợp đồng thông minh. Khi EVM xử lý giao dịch hợp đồng, nó cần giải thích và thực hiện từng hướng dẫn bytecode trong hợp đồng thông minh, logic của hợp đồng càng phức tạp, số lượng hướng dẫn liên quan càng nhiều, thì 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 chuyển khoản EOA, trong khi các hợp đồng thông minh phức tạp hơn, chẳng hạn như giao dịch trên một DEX nào đó, có thể mất thời gian gấp hàng chục 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á, hoán đổi token, v.v. 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 xử lý giao dịch giữa EVM và stateDB như sau:
Trong thiết kế Ethereum, các giao dịch trong một khối sẽ được xử lý từng giao dịch một theo thứ tự. Mỗi giao dịch 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 một 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ừ stateDB và ghi lại dữ liệu đã thay đổi trở lại stateDB.
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 rễ trạng thái mới. Rễ 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ầu mới sau khi thực hiện khối.
Rõ ràng là có những hạn chế trong mô hình thực thi tuần tự của EVM: các giao dịch phải được xếp hàng và 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, thì các giao dịch khác chỉ có thể chờ đợi trước khi nó được xử lý, điều này rõ ràng không thể tận dụng tối đa tài nguyên phần cứng như CPU, hiệu quả bị hạn chế đáng kể.
Giải pháp tối ưu hóa đa luồng song song của EVM
Thực thi tuần tự và thực thi song song có thể được so sánh với một ngân hàng chỉ có một quầy và 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 lên gấp vài lần, nhưng vấn đề khó khăn là 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 đó, khi chúng được xử lý đồng thời, sẽ xảy ra xung đột. Ví dụ, một NFT chỉ có thể được đúc 1 cái, và giao dịch 1 và giao dịch 2 đều tuyên bố muốn đúc NFT đó, nếu cả hai yêu cầu đều được thỏa mãn, rõ ràng sẽ xảy ra lỗi. Trong thực tế, xung đột trạng thái thường xuyên xảy ra hơn, vì vậy việc xử lý giao dịch song song phải có biện pháp đối phó với xung đột trạng thái.
Nguyên lý tối ưu hóa song song EVM của Reddio
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, được gọi là pending-stateDB. Các chi tiết cụ thể như sau:
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 lúc, các luồng không can thiệp vào nhau. Điều này 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: Phân bổ một cơ sở dữ liệu trạng thái tạm thời độc lập cho mỗi luồng (pending-stateDB). Các luồng thực hiện giao dịch sẽ không sửa đổi trực tiếp stateDB toàn cầu, mà sẽ tạm thời ghi lại kết quả thay đổi trạng thái trong pending-stateDB.
Đồ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, 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 global stateDB. Nếu các giao dịch khác nhau không xảy ra xung đột trạng thái trong quá trình thực hiện, thì có thể hợp nhất các bản ghi trong pending-stateDB vào global stateDB một cách suôn sẻ.
Dự án đã tối ưu hóa cách 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:
Hoạt động đọc: Khi giao dịch cần đọc trạng thái, EVM trước tiên kiểm tra ReadSet trong trạng thái đang chờ. Nếu ReadSet có dữ liệu cần thiết, nó sẽ đọc trực tiếp từ pending-stateDB. Nếu không tìm thấy cặp khóa-giá trị tương ứng trong ReadSet, 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à những thay đổi trạng thái ) sẽ không được ghi trực tiếp vào stateDB toàn cầu, mà trước tiên sẽ được ghi lại vào WriteSet của trạng thái đang chờ. Sau khi thực hiện giao dịch hoàn thành, sẽ thử kết hợp kết quả thay đổi trạng thái vào stateDB toàn cầu thông qua kiểm tra xung đột.
Vấn đề chính của việc thực thi song song là xung đột trạng thái, vấn đề này trở nên rõ ràng hơn khi nhiều giao dịch cố gắng đọc và ghi trạng thái của cùng một tài khoản. Để giải quyết điều 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 sẽ 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ì đượ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 các 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.
Việc tối ưu hóa đa luồng song song 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 các giao dịch có xung đột thấp trong bể giao dịch ( với ít mâu thuẫn hoặc sử dụng cùng một tài nguyên, hiệu suất TPS của các bài kiểm tra so với thực hiện tuần tự truyền thống đã tăng khoảng 3-5 lần. Trong các khối lượng công việc có xung đột cao, lý thuyết là 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 gấp 60 lần.
![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-4966960247a4550afa25f04eaaabbbd8.webp(
Tóm tắt
Giải pháp tối ưu hóa đa luồng EVM của dự án này, 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ư đưa vào cơ chế phát hiện xung đột, chuỗi công khai EVM có thể thực hiện lập trình song song quy mô lớn của giao dịch trong khi vẫn đảm bảo tính nhất quán của trạng thái, giải quyết được nút thắt về hiệu suất do chế độ thực thi 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.
![Lấy Reddio làm ví dụ, giải thích con đường tối ưu hóa EVM song song])https://img-cdn.gateio.im/webp-social/moments-af377193cf86df94c08df49ba217e327.webp(
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
Tối ưu hóa đa luồng EVM: Mở khóa nút cổ chai hiệu suất Rollup
Tối ưu hóa song song EVM: Thảo luận về con đường nâng cao hiệu suất thông qua Reddio
Như mọi người đã biết, EVM là một trong những thành phần cốt lõi nhất của Ethereum, đóng vai trò quan trọng như "động cơ thực thi" và "môi trường thực thi hợp đồng thông minh". Trong một mạng lưới mở được tạo thành từ hàng nghìn nút, cấu hình phần cứng của các nút khác nhau có thể có sự khác biệt lớn. Để đảm bảo rằng hợp đồng thông minh được thực thi nhất quán trên các nút khác nhau, công nghệ máy ảo trở thành giải pháp lý tưởng.
EVM có thể chạy hợp đồng thông minh theo cùng một cách trên các hệ điều hành và 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 đều 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ự với nguyên lý của máy ảo Java JVM.
Các hợp đồng thông minh mà chúng ta thấy trong trình duyệt blockchain đề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 hiện hợp đồng, nó sẽ đọc tuần tự các mã byte này, mỗi lệnh đều có chi phí Gas tương ứng. EVM sẽ theo dõi lượng Gas tiêu thụ trong quá trình thực hiện mỗi lệnh, và lượng tiêu thụ phụ thuộc vào mức độ 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ý các 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à thực thi theo thứ tự đã được xác định. Lý do không sử dụng phương pháp song song là vì blockchain cần đảm bảo tính nhất quán một cách nghiêm ngặt, cùng một tập hợp giao dịch 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 đưa vào các thuật toán lập lịch phức tạp.
Năm 2014-2015, đội ngũ sáng lập Ethereum do thời gian cấp bách đã chọn cách thực hiện tuần tự đơn giản và dễ bảo trì. Tuy nhiên, khi công nghệ blockchain tiến triển và cộng đồng người dùng mở rộng, yêu cầu về TPS và thông lượng ngày càng cao. Sau khi công nghệ Rollup xuất hiện và trưởng thành, những hạn chế về hiệu suất do thực hiện tuần tự EVM đã rõ ràng xuất hiện trên mạng Ethereum lớp hai.
Sequencer là thành phần chính của Layer2, đảm nhiệm tất cả các nhiệm vụ tính toán dưới dạng một máy chủ đơn lẻ. Nếu các module bên ngoài phối hợp với Sequencer đều 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 đoan lớp DA và mô-đun đọc ghi dữ liệu, khiến Sequencer có thể thực hiện tối đa khoảng 2000 giao dịch 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 giao dịch ERC-20, thì giá trị TPS chắc chắn sẽ giảm mạnh. Do đó, việc xử lý giao dịch theo chiều ngang sẽ là xu hướng tất yếu trong tương lai.
Hai thành phần cốt lõi trong 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 hiện 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 một cấu trúc cây có tên là Merkle Patricia Trie làm chỉ mục cơ sở dữ liệu, mỗi lần thực hiện giao dịch EVM sẽ thay đổi một số dữ liệu được lưu trữ trong stateDB, những thay đổi này cuối cùng sẽ được 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 phải nộp trạng thái mới vào cơ sở dữ liệu dưới để xử lý lưu trữ.
Tổng thể mà nói, EVM chịu trách nhiệm giải thích và thực hiện 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ý tất cả các thay đổi trạng thái của 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ể
Các loại giao dịch của Ethereum được chia thành 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 và phí gas thu được cũng rất thấp.
Giao dịch hợp đồng liên quan đến việc gọi và thực hiện hợp đồng thông minh. Khi EVM xử lý giao dịch hợp đồng, nó cần giải thích và thực hiện từng hướng dẫn bytecode trong hợp đồng thông minh, logic của hợp đồng càng phức tạp, số lượng hướng dẫn liên quan càng nhiều, thì 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 chuyển khoản EOA, trong khi các hợp đồng thông minh phức tạp hơn, chẳng hạn như giao dịch trên một DEX nào đó, có thể mất thời gian gấp hàng chục 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á, hoán đổi token, v.v. 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 xử lý giao dịch giữa EVM và stateDB như sau:
Trong thiết kế Ethereum, các giao dịch trong một khối sẽ được xử lý từng giao dịch một theo thứ tự. Mỗi giao dịch 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 một 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ừ stateDB và ghi lại dữ liệu đã thay đổi trở lại stateDB.
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 rễ trạng thái mới. Rễ 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ầu mới sau khi thực hiện khối.
Rõ ràng là có những hạn chế trong mô hình thực thi tuần tự của EVM: các giao dịch phải được xếp hàng và 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, thì các giao dịch khác chỉ có thể chờ đợi trước khi nó được xử lý, điều này rõ ràng không thể tận dụng tối đa tài nguyên phần cứng như CPU, hiệu quả bị hạn chế đáng kể.
Giải pháp tối ưu hóa đa luồng song song của EVM
Thực thi tuần tự và thực thi song song có thể được so sánh với một ngân hàng chỉ có một quầy và 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 lên gấp vài lần, nhưng vấn đề khó khăn là 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 đó, khi chúng được xử lý đồng thời, sẽ xảy ra xung đột. Ví dụ, một NFT chỉ có thể được đúc 1 cái, và giao dịch 1 và giao dịch 2 đều tuyên bố muốn đúc NFT đó, nếu cả hai yêu cầu đều được thỏa mãn, rõ ràng sẽ xảy ra lỗi. Trong thực tế, xung đột trạng thái thường xuyên xảy ra hơn, vì vậy việc xử lý giao dịch song song phải có biện pháp đối phó với xung đột trạng thái.
Nguyên lý tối ưu hóa song song EVM của Reddio
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, được gọi là pending-stateDB. Các chi tiết cụ thể như sau:
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 lúc, các luồng không can thiệp vào nhau. Điều này 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: Phân bổ một cơ sở dữ liệu trạng thái tạm thời độc lập cho mỗi luồng (pending-stateDB). Các luồng thực hiện giao dịch sẽ không sửa đổi trực tiếp stateDB toàn cầu, mà sẽ tạm thời ghi lại kết quả thay đổi trạng thái trong pending-stateDB.
Đồ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, 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 global stateDB. Nếu các giao dịch khác nhau không xảy ra xung đột trạng thái trong quá trình thực hiện, thì có thể hợp nhất các bản ghi trong pending-stateDB vào global stateDB một cách suôn sẻ.
Dự án đã tối ưu hóa cách 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:
Hoạt động đọc: Khi giao dịch cần đọc trạng thái, EVM trước tiên kiểm tra ReadSet trong trạng thái đang chờ. Nếu ReadSet có dữ liệu cần thiết, nó sẽ đọc trực tiếp từ pending-stateDB. Nếu không tìm thấy cặp khóa-giá trị tương ứng trong ReadSet, 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à những thay đổi trạng thái ) sẽ không được ghi trực tiếp vào stateDB toàn cầu, mà trước tiên sẽ được ghi lại vào WriteSet của trạng thái đang chờ. Sau khi thực hiện giao dịch hoàn thành, sẽ thử kết hợp kết quả thay đổi trạng thái vào stateDB toàn cầu thông qua kiểm tra xung đột.
Vấn đề chính của việc thực thi song song là xung đột trạng thái, vấn đề này trở nên rõ ràng hơn khi nhiều giao dịch cố gắng đọc và ghi trạng thái của cùng một tài khoản. Để giải quyết điều 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 sẽ 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ì đượ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 các 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.
Việc tối ưu hóa đa luồng song song 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 các giao dịch có xung đột thấp trong bể giao dịch ( với ít mâu thuẫn hoặc sử dụng cùng một tài nguyên, hiệu suất TPS của các bài kiểm tra so với thực hiện tuần tự truyền thống đã tăng khoảng 3-5 lần. Trong các khối lượng công việc có xung đột cao, lý thuyết là 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 gấp 60 lần.
![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-4966960247a4550afa25f04eaaabbbd8.webp(
Tóm tắt
Giải pháp tối ưu hóa đa luồng EVM của dự án này, 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ư đưa vào cơ chế phát hiện xung đột, chuỗi công khai EVM có thể thực hiện lập trình song song quy mô lớn của giao dịch trong khi vẫn đảm bảo tính nhất quán của trạng thái, giải quyết được nút thắt về hiệu suất do chế độ thực thi 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.
![Lấy Reddio làm ví dụ, giải thích con đường tối ưu hóa EVM song song])https://img-cdn.gateio.im/webp-social/moments-af377193cf86df94c08df49ba217e327.webp(