Khám Phá Nút Thắt Hạn Chế Thực Thi Chuỗi Của EVM Và Tối Ưu Hóa Song Song
Như đã 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 trong những thành phần quan trọng nhất của Ethereum. Trong mạng blockchain công cộng được cấu thành từ nhiều nút, để đảm bảo rằng các hợp đồng thông minh có thể nhận được kết quả thực thi nhất quán trên các nút khác nhau, công nghệ máy ảo đóng vai trò rất quan trọng.
EVM có thể thực thi hợp đồng thông minh theo cách thống nhất trên nhiều 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 thi hợp đồng. Điều này tương tự với cách hoạt động của máy ảo Java JVM.
Thông thường, hợp đồng thông minh sẽ được biên dịch thành mã byte EVM trước, sau đó được lưu trữ trên chuỗi khố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 tương ứng với một chi phí Gas cụ thể. 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ụ cụ thể phụ thuộc vào độ phức tạp của thao tác.
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 đơn và được thực hiện theo thứ tự đã xác định. Lý do chọn phương pháp tuần tự thay vì song song là để đáp ứng nghiêm ngặt yêu cầu nhất quán của blockchain, đảm bảo một nhóm giao dịch được xử lý theo cùng một thứ tự trên tất cả các nút.
Trong khoảng thời gian 2014-2015, đội ngũ sáng lập Ethereum đã chọn cách thực thi tuần tự đơn giản và dễ bảo trì do thời gian cấp bách. Tuy nhiên, 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. Đặc biệt, sau khi công nghệ Rollup phát triển và áp dụng, những hạn chế về hiệu suất do thực thi tuần tự EVM đã trở nên rõ rệt hơn trong mạng lưới lớp hai của Ethereum.
Là một thành phần quan trọng của Layer2, Sequencer đảm nhận tất cả các nhiệm vụ tính toán dưới dạng một máy chủ đơn. Nếu các mô-đun bên ngoài kết 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 đội ngũ đã tối ưu hóa cực kỳ cho 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 chuyển ERC-20 mỗi giây. Con số này có vẻ rất cao, nhưng đối với các giao dịch phức tạp hơn, giá trị TPS chắc chắn sẽ giảm mạnh. Do đó, việc xử lý giao dịch song song 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 thi 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 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 lần thực hiện 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 giao dịch hoàn tất, stateDB cần nộp trạng thái mới vào cơ sở dữ liệu tầng dưới để xử lý lưu trữ.
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à kho 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 cùng 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ể
Các loại giao dịch của Ethereum được chia thành hai loại: chuyển nhượng EOA và giao dịch hợp đồng. Chuyển nhượng 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 rất thấp.
So với giao dịch thông thường, giao dịch hợp đồng liên quan đến việc gọi và thực thi hợp đồng thông minh. EVM khi xử lý giao dịch hợp đồng cần giải thích và thực thi từng chỉ thị bytecode trong hợp đồng thông minh, logic hợp đồng càng phức tạp, số lượng chỉ thị càng nhiều, tài nguyên tiêu tốn cũng sẽ càng nhiều.
Ví dụ, thời gian xử lý chuyển khoản ERC-20 khoảng gấp đôi so với chuyển khoản EOA, trong khi các hợp đồng thông minh phức tạp hơn, như các hoạt động giao dịch trên một DEX, có thể mất thời gian gấp mười lần 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, v.v., trong quá trình giao dịch, đòi hỏi 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 diễn ra 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 có một thể hiện riêng biệt để thực hiện các thao tác cụ thể. Mặc dù mỗi giao dịch sử dụng các thể hiệ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 trạng thái gốc mới. Trạng thái gốc là một 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, chế độ thực thi tuần tự của EVM có những điểm nghẽn rõ rệt: các giao dịch phải được thực hiện theo thứ tự xếp hàng, nếu có một 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, hiệu suất bị hạn chế đáng kể.
Giải pháp tối ưu hóa đa luồng song song của EVM
Nếu so sánh bằng ví dụ trong cuộc sống, thực thi tuần tự 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ể được cải thiện gấp nhiều lần, nhưng cần giải quyết 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 đó, sẽ xảy ra xung đột khi xử lý đồng thời. Ví dụ, một NFT chỉ có thể được đúc 1 cái, trong khi 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 hơn, vì vậy việc xử lý 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 một dự án nào đó
Một dự án ZKRollup 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. 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 một lúc, các luồng không can thiệp vào nhau, có thể tăng tốc độ xử lý giao dịch gấp 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 (pending-stateDB) cho mỗi luồng. Các luồng khác nhau khi thực hiện giao dịch sẽ không trực tiếp sửa đổi 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ộ thay đổi trạng thá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 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 giao dịch có thể truy cập dữ liệu trạng thái một cách chính xác 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 của trạng thái đang chờ. Nếu trong 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 tương ứng của khối trước.
Hoạt động ghi: Tất cả các hoạt động ghi (tức là các thay đổi trạng thái) sẽ không được ghi trực tiếp vào stateDB toàn cầu, mà sẽ được ghi lại trước vào WriteSet của trạng thái đang chờ. Sau khi giao dịch hoàn tất, sẽ thực hiện kiểm tra xung đột và sau đó thử kết hợp 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 là 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 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 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ì 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 hoàn tất, nhiều bản ghi thay đổi trong pending-stateDB sẽ được hợp nhất vào global stateDB. Nếu việc 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ầu và tạo ra trạng thái gốc mới.
Tối ưu hóa song song đa luồng có ảnh hưởng đáng kể đến hiệu suất, đặ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 các khối lượng công việc có xung đột thấp, TPS trong các 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 các khối lượng công việc 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 tới 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âng cao đá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 hoạt động đọc-ghi và giới thiệu cơ chế phát hiện xung đột, chuỗi công cộng EVM có thể đạt được khả năng song song hóa quy mô lớn trong giao dịch mà vẫn đả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 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 tảng quan trọng cho sự phát triển trong tương lai của Ethereum Rollup.
Trong tương lai, có thể tiếp tục khám phá cách 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 trong trường hợp xung đột cao, cũng như cách tận dụng GPU để tối ưu hóa.
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.
9 thích
Phần thưởng
9
3
Chia sẻ
Bình luận
0/400
LeverageAddict
· 07-20 10:07
Lại có người làm song song rồi, giống như vị thế L2 của tôi cũng bị kẹt.
Tối ưu hóa song song EVM: Vượt qua nút thắt trong thực thi tuần tự để nâng cao hiệu suất Layer2
Khám Phá Nút Thắt Hạn Chế Thực Thi Chuỗi Của EVM Và Tối Ưu Hóa Song Song
Như đã 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 trong những thành phần quan trọng nhất của Ethereum. Trong mạng blockchain công cộng được cấu thành từ nhiều nút, để đảm bảo rằng các hợp đồng thông minh có thể nhận được kết quả thực thi nhất quán trên các nút khác nhau, công nghệ máy ảo đóng vai trò rất quan trọng.
EVM có thể thực thi hợp đồng thông minh theo cách thống nhất trên nhiều 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 thi hợp đồng. Điều này tương tự với cách hoạt động của máy ảo Java JVM.
Thông thường, hợp đồng thông minh sẽ được biên dịch thành mã byte EVM trước, sau đó được lưu trữ trên chuỗi khố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 tương ứng với một chi phí Gas cụ thể. 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ụ cụ thể phụ thuộc vào độ phức tạp của thao tác.
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 đơn và được thực hiện theo thứ tự đã xác định. Lý do chọn phương pháp tuần tự thay vì song song là để đáp ứng nghiêm ngặt yêu cầu nhất quán của blockchain, đảm bảo một nhóm giao dịch được xử lý theo cùng một thứ tự trên tất cả các nút.
Trong khoảng thời gian 2014-2015, đội ngũ sáng lập Ethereum đã chọn cách thực thi tuần tự đơn giản và dễ bảo trì do thời gian cấp bách. Tuy nhiên, 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. Đặc biệt, sau khi công nghệ Rollup phát triển và áp dụng, những hạn chế về hiệu suất do thực thi tuần tự EVM đã trở nên rõ rệt hơn trong mạng lưới lớp hai của Ethereum.
Là một thành phần quan trọng của Layer2, Sequencer đảm nhận tất cả các nhiệm vụ tính toán dưới dạng một máy chủ đơn. Nếu các mô-đun bên ngoài kết 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 đội ngũ đã tối ưu hóa cực kỳ cho 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 chuyển ERC-20 mỗi giây. Con số này có vẻ rất cao, nhưng đối với các giao dịch phức tạp hơn, giá trị TPS chắc chắn sẽ giảm mạnh. Do đó, việc xử lý giao dịch song song 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 thi 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 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 lần thực hiện 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 giao dịch hoàn tất, stateDB cần nộp trạng thái mới vào cơ sở dữ liệu tầng dưới để xử lý lưu trữ.
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à kho 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 cùng 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ể
Các loại giao dịch của Ethereum được chia thành hai loại: chuyển nhượng EOA và giao dịch hợp đồng. Chuyển nhượng 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 rất thấp.
So với giao dịch thông thường, giao dịch hợp đồng liên quan đến việc gọi và thực thi hợp đồng thông minh. EVM khi xử lý giao dịch hợp đồng cần giải thích và thực thi từng chỉ thị bytecode trong hợp đồng thông minh, logic hợp đồng càng phức tạp, số lượng chỉ thị càng nhiều, tài nguyên tiêu tốn cũng sẽ càng nhiều.
Ví dụ, thời gian xử lý chuyển khoản ERC-20 khoảng gấp đôi so với chuyển khoản EOA, trong khi các hợp đồng thông minh phức tạp hơn, như các hoạt động giao dịch trên một DEX, có thể mất thời gian gấp mười lần 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, v.v., trong quá trình giao dịch, đòi hỏi 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 diễn ra 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 có một thể hiện riêng biệt để thực hiện các thao tác cụ thể. Mặc dù mỗi giao dịch sử dụng các thể hiệ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 trạng thái gốc mới. Trạng thái gốc là một 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, chế độ thực thi tuần tự của EVM có những điểm nghẽn rõ rệt: các giao dịch phải được thực hiện theo thứ tự xếp hàng, nếu có một 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, hiệu suất bị hạn chế đáng kể.
Giải pháp tối ưu hóa đa luồng song song của EVM
Nếu so sánh bằng ví dụ trong cuộc sống, thực thi tuần tự 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ể được cải thiện gấp nhiều lần, nhưng cần giải quyết 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 đó, sẽ xảy ra xung đột khi xử lý đồng thời. Ví dụ, một NFT chỉ có thể được đúc 1 cái, trong khi 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 hơn, vì vậy việc xử lý 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 một dự án nào đó
Một dự án ZKRollup 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. 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 một lúc, các luồng không can thiệp vào nhau, có thể tăng tốc độ xử lý giao dịch gấp 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 (pending-stateDB) cho mỗi luồng. Các luồng khác nhau khi thực hiện giao dịch sẽ không trực tiếp sửa đổi 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ộ thay đổi trạng thá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 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 giao dịch có thể truy cập dữ liệu trạng thái một cách chính xác 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 của trạng thái đang chờ. Nếu trong 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 tương ứng của khối trước.
Hoạt động ghi: Tất cả các hoạt động ghi (tức là các thay đổi trạng thái) sẽ không được ghi trực tiếp vào stateDB toàn cầu, mà sẽ được ghi lại trước vào WriteSet của trạng thái đang chờ. Sau khi giao dịch hoàn tất, sẽ thực hiện kiểm tra xung đột và sau đó thử kết hợp 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 là 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 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 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ì 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 hoàn tất, nhiều bản ghi thay đổi trong pending-stateDB sẽ được hợp nhất vào global stateDB. Nếu việc 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ầu và tạo ra trạng thái gốc mới.
Tối ưu hóa song song đa luồng có ảnh hưởng đáng kể đến hiệu suất, đặ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 các khối lượng công việc có xung đột thấp, TPS trong các 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 các khối lượng công việc 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 tới 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âng cao đá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 hoạt động đọc-ghi và giới thiệu cơ chế phát hiện xung đột, chuỗi công cộng EVM có thể đạt được khả năng song song hóa quy mô lớn trong giao dịch mà vẫn đả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 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 tảng quan trọng cho sự phát triển trong tương lai của Ethereum Rollup.
Trong tương lai, có thể tiếp tục khám phá cách 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 trong trường hợp xung đột cao, cũng như cách tận dụng GPU để tối ưu hóa.