EVM song song: Giải quyết nút thắt hiệu suất của Ethereum
EVM như là động cơ thực thi 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 cốt lõi nhất của nó. Để đảm bảo rằng các hợp đồng thông minh có thể đạt được kết quả giống nhau trên các nút khác nhau, đáp ứng yêu cầu về tính nhất quán, công nghệ máy ảo đã trở thành lựa chọn tốt nhất. EVM có thể chạy các 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, đảm bảo tính tương thích đa nền tảng.
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 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 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.
Với tư cách là động cơ thực thi cốt lõi, 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 đợ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 tăng lên và công nghệ phát triển, nút thắt hiệu suất của nó ngày càng rõ ràng, đặc biệt là trong Layer2.
Đối với thành phần chính của Layer2 là Sequencer, nếu các mô-đun đi kèm 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. Có những đội ngũ thông qua tối ưu hóa cực độ, khiến Sequencer có thể thực hiện khoảng 2000 giao dịch ERC-20 mỗi giây. Nhưng đối với các giao dịch phức tạp hơn, TPS chắc chắn sẽ giảm đáng kể. Do đó, việc xử lý giao dịch song song 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 có liên quan chặt chẽ đế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 của 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 thực hiện giao dịch, một số dữ liệu trong stateDB sẽ thay đổi, và 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, 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 hiện giao dịch, stateDB sẽ đọc và ghi dữ liệu tài khoản tương ứng. Sau khi thực hiện giao dịch kết thúc, stateDB sẽ nộp trạng thái mới vào cơ sở dữ liệu dưới để thực hiện việc lưu trữ lâu dài.
Tổng thể, 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 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 cùng hợp tác để xây dựng môi trường thực thi giao dịch của Ethereum.
Hạn chế của việc thực hiện tuần tự
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, có tốc độ xử lý nhanh và phí gas thấp. Trong khi đó, 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 cần giải thích và thực thi từng lệnh bytecode trong hợp đồng, độ phức tạp và mức tiêu thụ tài nguyên cao hơn.
Trong chế độ thực thi tuần tự, 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 EVM độc lập, nhưng tất cả các giao dịch đều chia sẻ cùng một stateDB. EVM trong quá trình thực thi cần liên tục tương tác với stateDB, đọc dữ liệu và ghi lại kết quả đã thay đổi.
Điểm yếu rõ ràng của chế độ thực thi tuần tự này là: giao dịch phải được thực hiện theo hàng, 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 tối đa tài nguyên phần cứng, hiệu suất bị hạn chế đáng kể.
Tối ưu hóa đa luồng song song của EVM
Để vượt qua giới hạn của việc thực thi tuần tự, ngành công nghiệp đã đề xuất giải pháp tối ưu hóa đa luồng cho EVM. Giải pháp này tương tự như một ngân hàng có nhiều quầy phục vụ cùng lúc, có thể xử lý nhiều giao dịch đồng thời, nâng cao đáng kể hiệu suất. Tuy nhiên, thách thức chính mà thực thi song song phải đối mặt là vấn đề xung đột trạng thái, cần phải có các biện pháp đặc biệt để đối phó.
Một dự án có ý tưởng tối ưu hóa song song cho EVM như sau:
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 làm ảnh hưởng đến nhau.
Cấp phát cơ sở dữ liệu trạng thái tạm thời độc lập (pending-stateDB) cho mỗi luồng. Khi các luồng thực hiện giao dịch, các thay đổi trạng thái sẽ được ghi tạm thời vào pending-stateDB thay vì trực tiếp sửa đổi global stateDB.
Sau khi tất cả các giao dịch trong khối được thực hiện xong, sẽ lần lượt đồng bộ các thay đổi trạng thái trong pending-stateDB vào global stateDB. Nếu không có xung đột, các ghi chép sẽ được hợp nhất một cách suôn sẻ.
Giải pháp này đã tối ưu hóa 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 Đang chờ, nếu có dữ liệu cần thiết thì đọc trực tiếp; nếu không, thì đọc 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 sửa đổi sẽ được ghi lại vào WriteSet trong trạng thái Đang chờ, sau khi giao dịch hoàn thành sẽ thử hợp nhất vào stateDB toàn cầu.
Để giải quyết vấn đề xung đột trạng thái, cơ chế phát hiện xung đột đã được đưa vào.
Giám sát ReadSet và WriteSet của các giao dịch khác nhau, 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 được coi là xung đột.
Đánh dấu giao dịch xung đột 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 stateDB toàn cầu. Sau khi hợp nhất thành công, trạng thái cuối cùng sẽ được gửi đến cây trạng thái toàn cầu, tạo ra một root trạng thái mới.
Nghiên cứu cho thấy, trong khối lượng công việc xung đột thấp, TPS thực thi song song đã tăng từ 3-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 được tối ưu hóa hoàn toàn 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 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 và ghi cũng như đưa vào cơ chế phát hiện xung đột, đã đạt được 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 được nút thắt hiệu suất của chế độ 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 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 suất lưu trữ, ứng phó với các tình huống xung đột cao, cũng như tối ưu hóa bằng cách sử dụng GPU, nhằm nâng cao hiệu suất của EVM.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
6 thích
Phần thưởng
6
6
Chia sẻ
Bình luận
0/400
down_only_larry
· 7giờ trước
tăng lên V神 cuối cùng cũng đã khai sáng
Xem bản gốcTrả lời0
BlockTalk
· 7giờ trước
Yêu xem thì xem, không thì thôi, tps đã tăng lên.
Xem bản gốcTrả lời0
LiquidityOracle
· 7giờ trước
Lại thổi lên trời
Xem bản gốcTrả lời0
All-InQueen
· 7giờ trước
Cũng có nghĩa là chuyển tiền nhanh hơn?
Xem bản gốcTrả lời0
ProveMyZK
· 7giờ trước
Đợt tối ưu hiệu suất này thuộc về những người chơi hàng đầu.
Xem bản gốcTrả lời0
SmartContractPlumber
· 7giờ trước
Nhìn thẳng vào rủi ro mở rộng, thiết kế cơ chế khóa quá ngây thơ
EVM song song: Bứt phá hiệu suất Ethereum
EVM song song: Giải quyết nút thắt hiệu suất của Ethereum
EVM như là động cơ thực thi 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 cốt lõi nhất của nó. Để đảm bảo rằng các hợp đồng thông minh có thể đạt được kết quả giống nhau trên các nút khác nhau, đáp ứng yêu cầu về tính nhất quán, công nghệ máy ảo đã trở thành lựa chọn tốt nhất. EVM có thể chạy các 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, đảm bảo tính tương thích đa nền tảng.
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 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 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.
Với tư cách là động cơ thực thi cốt lõi, 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 đợ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 tăng lên và công nghệ phát triển, nút thắt hiệu suất của nó ngày càng rõ ràng, đặc biệt là trong Layer2.
Đối với thành phần chính của Layer2 là Sequencer, nếu các mô-đun đi kèm 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. Có những đội ngũ thông qua tối ưu hóa cực độ, khiến Sequencer có thể thực hiện khoảng 2000 giao dịch ERC-20 mỗi giây. Nhưng đối với các giao dịch phức tạp hơn, TPS chắc chắn sẽ giảm đáng kể. Do đó, việc xử lý giao dịch song song 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 có liên quan chặt chẽ đế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 của 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 thực hiện giao dịch, một số dữ liệu trong stateDB sẽ thay đổi, và 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, 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 hiện giao dịch, stateDB sẽ đọc và ghi dữ liệu tài khoản tương ứng. Sau khi thực hiện giao dịch kết thúc, stateDB sẽ nộp trạng thái mới vào cơ sở dữ liệu dưới để thực hiện việc lưu trữ lâu dài.
Tổng thể, 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 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 cùng hợp tác để xây dựng môi trường thực thi giao dịch của Ethereum.
Hạn chế của việc thực hiện tuần tự
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, có tốc độ xử lý nhanh và phí gas thấp. Trong khi đó, 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 cần giải thích và thực thi từng lệnh bytecode trong hợp đồng, độ phức tạp và mức tiêu thụ tài nguyên cao hơn.
Trong chế độ thực thi tuần tự, 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 EVM độc lập, nhưng tất cả các giao dịch đều chia sẻ cùng một stateDB. EVM trong quá trình thực thi cần liên tục tương tác với stateDB, đọc dữ liệu và ghi lại kết quả đã thay đổi.
Điểm yếu rõ ràng của chế độ thực thi tuần tự này là: giao dịch phải được thực hiện theo hàng, 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 tối đa tài nguyên phần cứng, hiệu suất bị hạn chế đáng kể.
Tối ưu hóa đa luồng song song của EVM
Để vượt qua giới hạn của việc thực thi tuần tự, ngành công nghiệp đã đề xuất giải pháp tối ưu hóa đa luồng cho EVM. Giải pháp này tương tự như một ngân hàng có nhiều quầy phục vụ cùng lúc, có thể xử lý nhiều giao dịch đồng thời, nâng cao đáng kể hiệu suất. Tuy nhiên, thách thức chính mà thực thi song song phải đối mặt là vấn đề xung đột trạng thái, cần phải có các biện pháp đặc biệt để đối phó.
Một dự án có ý tưởng tối ưu hóa song song cho EVM như sau:
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 làm ảnh hưởng đến nhau.
Cấp phát cơ sở dữ liệu trạng thái tạm thời độc lập (pending-stateDB) cho mỗi luồng. Khi các luồng thực hiện giao dịch, các thay đổi trạng thái sẽ được ghi tạm thời vào pending-stateDB thay vì trực tiếp sửa đổi global stateDB.
Sau khi tất cả các giao dịch trong khối được thực hiện xong, sẽ lần lượt đồng bộ các thay đổi trạng thái trong pending-stateDB vào global stateDB. Nếu không có xung đột, các ghi chép sẽ được hợp nhất một cách suôn sẻ.
Giải pháp này đã tối ưu hóa 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 Đang chờ, nếu có dữ liệu cần thiết thì đọc trực tiếp; nếu không, thì đọc 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 sửa đổi sẽ được ghi lại vào WriteSet trong trạng thái Đang chờ, sau khi giao dịch hoàn thành sẽ thử hợp nhất vào stateDB toàn cầu.
Để 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 stateDB toàn cầu. Sau khi hợp nhất thành công, trạng thái cuối cùng sẽ được gửi đến cây trạng thái toàn cầu, tạo ra một root trạng thái mới.
Nghiên cứu cho thấy, trong khối lượng công việc xung đột thấp, TPS thực thi song song đã tăng từ 3-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 được tối ưu hóa hoàn toàn 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 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 và ghi cũng như đưa vào cơ chế phát hiện xung đột, đã đạt được 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 được nút thắt hiệu suất của chế độ 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 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 suất lưu trữ, ứng phó với các tình huống xung đột cao, cũng như tối ưu hóa bằng cách sử dụng GPU, nhằm nâng cao hiệu suất của EVM.