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, đóng vai trò then chốt như "động cơ thực thi" và "môi trường thực thi hợp đồng thông minh". Trong mạng chuỗi công cộng gồm hàng ngàn nút, sự tồn tại của máy ảo cho phép hợp đồng thông minh có thể chạy theo cùng một cách trên các nút với cấu hình phần cứng khác nhau, đảm bảo tính nhất quán của kết quả. Tính tương thích đa nền tảng này tương tự như máy ảo Java JVM.
Hợp đồng thông minh trước khi lên chuỗi sẽ được biên dịch thành mã byte EVM. Khi EVM thực thi hợp đồng, nó sẽ đọc các mã byte này theo thứ tự, mỗi lệnh có một chi phí Gas tương ứng. EVM sẽ theo dõi mức tiêu thụ Gas trong quá trình thực thi lệnh, lượng tiêu 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 thực thi 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. Thiết kế này đơn giản và dễ bảo trì, nhưng khi số lượng người dùng mở rộng và công nghệ phát triển, những điểm nghẽn hiệu suất ngày càng trở nên rõ rệt, đặc biệt là khi công nghệ Rollup trở nên trưởng thành, điều này thể hiện rất rõ ràng trong mạng lớp hai của Ethereum.
Sequencer là thành phần chính của Layer2, đả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 lẻ. Nếu các mô-đun bên ngoài đi kèm đủ hiệu quả, 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 theo chuỗi sẽ trở thành một trở ngại lớn.
Một đội ngũ đã tối ưu hóa cực kỳ các lớp DA và mô-đun đọc ghi dữ liệu, khiến Sequencer có thể thực hiện khoảng hơn 2000 giao dịch ERC-20 mỗi giây. Con số này có vẻ cao, nhưng đối với các giao dịch phức tạp, giá trị TPS chắc chắn sẽ bị 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 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 lần thực thi giao dịch EVM sẽ thay đổi một số dữ liệu trong stateDB, và những thay đổi này cuối cùng 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 kết thúc, stateDB cần nộp trạng thái mới vào cơ sở dữ liệu dưới để thực hiện xử lý lâu dài.
Nói chung, 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 phối hợp 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 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 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. EVM trong quá trình 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 của hợp đồng càng phức tạp, số lượng chỉ thị liên quan càng nhiều, tài nguyên tiêu thụ sẽ 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, chẳng hạn như các 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 trong quá trình giao dịch, đòi hỏi phải thực hiện các phép tính rất phức tạp.
Trong chế độ thực thi tuần tự, quá trình hợp tác giữa EVM và stateDB như sau:
Các giao dịch trong khối được xử lý theo thứ tự lần lượ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 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 và ghi lại dữ liệu đã thay đổi vào stateDB.
Sau khi tất cả các giao dịch được xử lý xong, dữ liệu trong stateDB sẽ được nộp vào cây trạng thái toàn cầu và tạo ra một trạng thái gốc mới.
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 đầy đủ 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 cho EVM
EVM song song giống như một ngân hàng có nhiều quầy, 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 vấn đề khó khăn là vấn đề xung đột trạng thái, cần phải xử lý phối hợp.
Một dự án ZKRollup có ý tưởng tối ưu hóa song song cho EVM 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 đồng thời, các luồng không can thiệp vào nhau, có thể tăng tốc độ xử lý giao dịch lên vài 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 phân bổ một cơ sở dữ liệu trạng thái tạm thời độc lập (pending-stateDB). Khi các 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.
Đồng bộ hóa thay đổi trạng thái: Sau khi tất cả các giao dịch trong một khối được thực thi xong, EVM sẽ lần lượt đồng bộ hóa kết quả thay đổi trạng thái được ghi lại trong từng pending-stateDB vào stateDB toàn cầu. 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 thi, thì có thể hợp nhất các bản ghi trong pending-stateDB vào stateDB toàn cầu một cách suôn sẻ.
Dự án đã tối ưu hóa việc 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 Pending-state. Nếu 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 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 thực hiện giao dịch hoàn tất, sẽ thử 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, cơ chế phát hiện xung đột đã được đưa vào.
Kiểm tra xung đột: 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ì đượ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 đế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.
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 khối lượng công việc xung đột thấp, TPS của bài kiểm tra chuẩn đã tăng từ 3 đến 5 lần so với thực thi tuần tự truyền thống. Trong khối lượng công việc xung đột cao, lý thuyết nếu sử 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 EVM đã 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 từng giao dịch và thực hiện giao dịch song song trên các luồng khác nhau. Bằng cách tối ưu hóa các thao tác đọc và ghi và giới thiệu cơ chế phát hiện xung đột, chuỗi công khai EVM có thể thực hiện giao dịch quy mô lớn mà vẫn đảm bảo tính nhất quán 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 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 Rollup Ethereum.
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 EVM: Nâng cao hiệu quả xử lý giao dịch bằng cách song song đa luồng
Con đường tối ưu hóa song song của EVM
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, đóng vai trò then chốt như "động cơ thực thi" và "môi trường thực thi hợp đồng thông minh". Trong mạng chuỗi công cộng gồm hàng ngàn nút, sự tồn tại của máy ảo cho phép hợp đồng thông minh có thể chạy theo cùng một cách trên các nút với cấu hình phần cứng khác nhau, đảm bảo tính nhất quán của kết quả. Tính tương thích đa nền tảng này tương tự như máy ảo Java JVM.
Hợp đồng thông minh trước khi lên chuỗi sẽ được biên dịch thành mã byte EVM. Khi EVM thực thi hợp đồng, nó sẽ đọc các mã byte này theo thứ tự, mỗi lệnh có một chi phí Gas tương ứng. EVM sẽ theo dõi mức tiêu thụ Gas trong quá trình thực thi lệnh, lượng tiêu 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 thực thi 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. Thiết kế này đơn giản và dễ bảo trì, nhưng khi số lượng người dùng mở rộng và công nghệ phát triển, những điểm nghẽn hiệu suất ngày càng trở nên rõ rệt, đặc biệt là khi công nghệ Rollup trở nên trưởng thành, điều này thể hiện rất rõ ràng trong mạng lớp hai của Ethereum.
Sequencer là thành phần chính của Layer2, đả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 lẻ. Nếu các mô-đun bên ngoài đi kèm đủ hiệu quả, 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 theo chuỗi sẽ trở thành một trở ngại lớn.
Một đội ngũ đã tối ưu hóa cực kỳ các lớp DA và mô-đun đọc ghi dữ liệu, khiến Sequencer có thể thực hiện khoảng hơn 2000 giao dịch ERC-20 mỗi giây. Con số này có vẻ cao, nhưng đối với các giao dịch phức tạp, giá trị TPS chắc chắn sẽ bị 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 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 lần thực thi giao dịch EVM sẽ thay đổi một số dữ liệu trong stateDB, và những thay đổi này cuối cùng 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 kết thúc, stateDB cần nộp trạng thái mới vào cơ sở dữ liệu dưới để thực hiện xử lý lâu dài.
Nói chung, 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 phối hợp 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 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 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. EVM trong quá trình 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 của hợp đồng càng phức tạp, số lượng chỉ thị liên quan càng nhiều, tài nguyên tiêu thụ sẽ 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, chẳng hạn như các 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 trong quá trình giao dịch, đòi hỏi phải thực hiện các phép tính rất phức tạp.
Trong chế độ thực thi tuần tự, quá trình hợp tác giữa EVM và stateDB như sau:
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 đầy đủ 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 cho EVM
EVM song song giống như một ngân hàng có nhiều quầy, 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 vấn đề khó khăn là vấn đề xung đột trạng thái, cần phải xử lý phối hợp.
Một dự án ZKRollup có ý tưởng tối ưu hóa song song cho EVM 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 đồng thời, các luồng không can thiệp vào nhau, có thể tăng tốc độ xử lý giao dịch lên vài 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 phân bổ một cơ sở dữ liệu trạng thái tạm thời độc lập (pending-stateDB). Khi các 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.
Đồng bộ hóa thay đổi trạng thái: Sau khi tất cả các giao dịch trong một khối được thực thi xong, EVM sẽ lần lượt đồng bộ hóa kết quả thay đổi trạng thái được ghi lại trong từng pending-stateDB vào stateDB toàn cầu. 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 thi, thì có thể hợp nhất các bản ghi trong pending-stateDB vào stateDB toàn cầu một cách suôn sẻ.
Dự án đã tối ưu hóa việc 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 Pending-state. Nếu 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 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 thực hiện giao dịch hoàn tất, sẽ thử 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, cơ chế phát hiện xung đột đã được đưa vào.
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 đế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.
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 khối lượng công việc xung đột thấp, TPS của bài kiểm tra chuẩn đã tăng từ 3 đến 5 lần so với thực thi tuần tự truyền thống. Trong khối lượng công việc xung đột cao, lý thuyết nếu sử 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 EVM đã 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 từng giao dịch và thực hiện giao dịch song song trên các luồng khác nhau. Bằng cách tối ưu hóa các thao tác đọc và ghi và giới thiệu cơ chế phát hiện xung đột, chuỗi công khai EVM có thể thực hiện giao dịch quy mô lớn mà vẫn đảm bảo tính nhất quán 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 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 Rollup Ethereum.