Nhìn vào đường dẫn tối ưu hóa EVM song song từ Reddio

Tác giả: Wuyue, Geek web3

Như chúng ta đã biết, việc định vị của EVM Đây là "công cụ thực thi" và "môi trường thực thi hợp đồng thông minh" của Ethereum. Có thể nói đây là một trong những thành phần cốt lõi quan trọng nhất của Ethereum. Chuỗi công khai là một mạng mở chứa hàng nghìn nút. Các thông số phần cứng của các nút khác nhau rất khác nhau Nếu bạn muốn các hợp đồng thông minh chạy cùng một kết quả trên nhiều nút và đáp ứng "tính nhất quán", bạn phải tìm cách trong cùng một môi trường. được xây dựng trên các thiết bị khác nhau và máy ảo có thể đạt được hiệu ứng này.

Máy ảo EVM của Ethereum có thể chạy thông minh theo cách giống nhau trên các hệ điều hành khác nhau (như Windows, Linux, macOS) và các thiết bị Contract, khả năng tương thích đa nền tảng này đảm bảo rằng mỗi nút sẽ nhận được kết quả nhất quán sau khi chạy hợp đồng. Ví dụ điển hình nhất là máy ảo Java JVM.

Các hợp đồng thông minh mà chúng ta thường thấy trong block explorer trước tiên được biên dịch thành mã byte EVM và sau đó được lưu trữ trên chuỗi. Khi EVM thực thi hợp đồng, nó sẽ trực tiếp đọc các mã byte này theo trình tự. Mỗi lệnh (opCode) tương ứng với mã byte có chi phí Gas tương ứng. EVM theo dõi mức tiêu thụ Gas của từng lệnh trong khi thực hiện và mức tiêu thụ phụ thuộc vào độ phức tạp của thao tác.

Ngoài ra, với tư cách là công cụ thực thi cốt lõi của Ethereum,EVM sử dụng thực thi nối tiếp để xử lý các giao dịch. Tất cả các giao dịch được xếp hàng trong một hàng đợi duy nhất và được xử lý như. xác định Thực hiện theo trình tự. Lý do tại sao song song hóa không được sử dụng là vì chuỗi khối phải đáp ứng nghiêm ngặt tính nhất quán và một loạt giao dịch phải được xử lý theo cùng một thứ tự trong tất cả các nút. Nếu quá trình xử lý giao dịch được song song hóa thì rất khó để dự đoán chính xác Giao dịch. thứ tự, trừ khi thuật toán lập lịch tương ứng được đưa ra, nhưng việc này sẽ phức tạp hơn.

Nhóm sáng lập Ethereum từ năm 2014 đến 2015 đã chọn phương thức thực thi nối tiếp do hạn chế về thời gian. Bởi vì nó được thiết kế đơn giản và dễ bảo trì. Tuy nhiên, với sự lặp lại của công nghệ blockchain và cơ sở người dùng ngày càng tăng, blockchain có yêu cầu ngày càng cao hơn đối với TPS và thông lượng. Sau khi công nghệ Rollup xuất hiện và trưởng thành, nút thắt hiệu suất do thực thi nối tiếp EVM gây ra chắc chắn đã bộc lộ. lớp thứ hai của Ethereum.

Trình sắp xếp chuỗi, với tư cách là thành phần chính của Lớp 2, đảm nhận tất cả các tác vụ tính toán dưới dạng một máy chủ duy nhất.Nếu hiệu quả của các mô-đun bên ngoài hợp tác với Sequencer đủ cao, thì nút cổ chai cuối cùng sẽ phụ thuộc vào hiệu quả của chính Sequencer và việc thực hiện nối tiếp sẽ trở thành một trở ngại rất lớn vào lúc này.

Nhóm opBNB đã thực hiện những tối ưu hóa cực độ trên lớp DA và các mô-đun đọc và ghi dữ liệu có thể thực hiện tới hơn 2.000 giao dịch ERC-20. chuyển mỗi giây. Con số này có vẻ 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 chuyển khoản ERC-20 thì giá trị TPS chắc chắn sẽ giảm đi rất nhiều. Vì vậy, việc song song hóa xử lý giao dịch sẽ là xu hướng tất yếu trong tương lai.

Bây giờ chúng ta sẽ bắt đầu với những chi tiết cụ thể hơn để giải thích những hạn chế của EVM truyền thống và những ưu điểm của EVM song song.

Hai thành phần cốt lõi của việc thực hiện giao dịch Ethereum

Tại cấp mô-đun mã,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 cấu trúc cây có tên Merkle Patricia Trie để làm chỉ mục cơ sở dữ liệu (thư mục). Mỗi lần thực hiện giao dịch của EVM sẽ thay đổi một số dữ liệu nhất định được lưu trữ trong stateDB. Những thay đổi này cuối cùng sẽ được phản ánh trong Merkle Patricia Trie (sau này). Được gọi là cây trạng thái toàn cầu).

Đặc biệt, 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 mà nó 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 tài khoản tương ứng. Sau khi giao dịch được thực thi, stateDB cần gửi trạng thái mới tới cơ sở dữ liệu cơ bản (chẳng hạn như LevelDB) để duy trì.

Nói chung, EVM chịu trách nhiệm diễn giải và thực thi các hướng dẫn hợp đồng thông minh cũng như thay đổi trạng thái trên blockchain dựa trên kết quả tính toán, trong khi stateDB hoạt động như một trạng thái toàn cầu storage. Quản lý các thay đổi trạng thái cho tất cả các tài khoản và hợp đồng. Cả hai cộng tác để xây dựng môi trường thực hiện giao dịch của Ethereum.

Quy trình thực hiện nối tiếp cụ thể

Có hai loại giao dịch trong Ethereum, đó là chuyển khoản EOA và giao dịch hợp đồng. Chuyển EOA là loại giao dịch đơn giản nhất, là chuyển ETH giữa các tài khoản thông thường. Loại giao dịch này không liên quan đến các cuộc gọi hợp đồng và được xử lý rất nhanh chóng. Do hoạt động đơn giản nên phí gas được tính cho chuyển khoản EOA là cực kỳ thấp.

Khác với việc chuyển EOA đơn giản, các 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ý các giao dịch hợp đồng, nó phải diễn giải và thực thi từng hướng dẫn mã byte trong hợp đồng thông minh. Logic của hợp đồng càng phức tạp thì càng có nhiều hướng dẫn liên quan và càng tiêu tốn nhiều tài nguyên.

Ví dụ: thời gian xử lý chuyển ERC-20 gấp khoảng 2 lần so với chuyển EOA và đối với các hợp đồng thông minh phức tạp hơn, chẳng hạn như hoạt động giao dịch trên Uniswap , việc này sẽ mất nhiều thời gian hơn và thậm chí có thể chậm hơn 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ý logic phức tạp như nhóm thanh khoản, tính toán giá và hoán đổi mã thông báo trong khi giao dịch và yêu cầu các tính toán rất phức tạp.

Vậyhai thành phần EVM và stateDB hợp tác như thế nào để xử lý các giao dịch ở chế độ thực thi nối tiếp?

Trong thiết kế của Ethereum, các giao dịch trong một khối sẽ được xử lý từng cái một theo thứ tự và mỗi giao dịch (tx) sẽ có một trường hợp độc lập được sử dụng để thực hiện các hoạt động cụ thể của giao dịch. 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, đó là 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 dữ liệu đã thay đổi trở lại stateDB.

Hãy cùng xem xét kỹ cách EVM và stateDB cộng tác để thực hiện các giao dịch từ góc độ mã:

1. >processBlock Hàm () sẽ gọi hàm Process() để xử lý các giao dịch có trong một khối;

< img src=" https://img.jinse.cn/7313550_image3.png">

2. A for được xác định trong Process() chức năng Vòng lặp, bạn có thể thấy các giao dịch được thực hiện từng giao dịch một;

3. Sau khi tất cả các giao dịch được xử lý, hàm processBlock() gọi hàm writeBlockWithState() , sau đó gọi hàm .Commit() đã nêu,gửi kết quả thay đổi trạng thái.

Khi tất cả các giao dịch trong một khối được thực thi, dữ liệu trong stateDB sẽ được đưa vào cây trạng thái toàn cầu (Merkle Patricia Trie) đã đề cập trước đó và một gốc trạng thái mới (stateRoot) sẽ được tạo. Gốc trạng thái là một tham số quan trọng trong mỗi khối. Nó ghi lại "kết quả nén" của trạng thái toàn cục mới sau khi khối được thực thi.

Không khó để chúng ta hiểu rằng điểm nghẽn trong chế độ thực thi nối tiếp của EVM là rất rõ ràng: các giao dịch phải được xếp hàng đợi để thực hiện theo thứ tự. giao dịch hợp đồng mất nhiều thời gian, trước khi nó được xử lý, các giao dịch khác chỉ có thể chờ. Điều này rõ ràng không thể tận dụng hết tài nguyên phần cứng như CPU ​​và hiệu quả sẽ bị hạn chế rất nhiều.

Giải pháp tối ưu hóa song song đa luồng của EVM

Nếu được sử dụng Hãy so sánh việc thực thi nối tiếp và thực thi song song với các ví dụ thực tế. Cái trước được ví như một ngân hàng chỉ có một bộ đếm, trong khi EVM song song được ví như một ngân hàng có nhiều bộ đếm. Ở chế độ song song, nhiều luồng có thể được mở để xử lý nhiều giao dịch cùng một lúc và hiệu quả có thể được cải thiện nhiều lần, nhưng phần khó khăn là vấn đề xung đột trạng thái.

Nếu nhiều giao dịch khai báo ghi lại dữ liệu của một tài khoản, xung đột sẽ xảy ra khi chúng được xử lý cùng lúc, chẳng hạn như Chỉ NFT một cái có thể được đúc và cả Giao dịch 1 và Giao dịch 2 đều tuyên bố rằng họ muốn đúc NFT. Nếu yêu cầu của họ được đáp ứng, rõ ràng sẽ xảy ra lỗi và cần phải phối hợp để giải quyết những tình huống như vậy. Xung đột trạng thái trong hoạt động thực tế thường xảy ra thường xuyên hơn những gì chúng tôi đã đề cập, vì vậy muốn song song xử lý giao dịch thì phải có biện pháp xử lý xung đột trạng thái.

Nguyên tắc tối ưu hóa song song của Reddio cho EVM

Chúng ta có thể thực hiện hãy xem các ý tưởng tối ưu hóa song song của dự án ZKRollup Reddio cho EVM. Ý tưởng của Reddio là phân bổ một giao dịch cho từng luồng và cung cấp cơ sở dữ liệu trạng thái tạm thời trong mỗi luồng, được gọi là đang chờ xử lý-stateDB. Chi tiết cụ thể như sau:

1. Thực hiện song song các giao dịch đa luồng:Reddio thiết lập nhiều luồng để xử lý các giao dịch khác nhau cùng một lúc mà không can thiệp giữa các luồng . Điều này có thể tăng tốc độ xử lý giao dịch lên nhiều lần.

2. Phân bổ cơ sở dữ liệu trạng thái tạm thời cho mỗi luồng: Reddio phân bổ cơ sở dữ liệu trạng thái tạm thời độc lập (đang chờ xử lý -stateDB). Khi mỗi luồng thực hiện một giao dịch, nó sẽ không trực tiếp sửa đổi stateDB toàn cục mà sẽ tạm thời ghi lại kết quả thay đổi trạng thái trong stateDB đang chờ xử lý.

3. Thay đổi trạng thái đồng bộ hóa:Sau khi tất cả các giao dịch trong một khối được thực thi, EVM sẽ thay đổi từng giao dịch đang chờ xử lý- Kết quả thay đổi trạng thái được ghi lại trong stateDB lần lượt được đồng bộ hóa với stateDB toàn cầu. Nếu không có xung đột trạng thái trong quá trình thực hiện các giao dịch khác nhau, các bản ghi trong DB trạng thái đang chờ xử lý có thể được hợp nhất thành công vào stateDB toàn cầu.

Reddio đã tối ưu hóa cách xử lý các hoạt động đọc và ghi để đảm bảo rằng các giao dịch có thể truy cập chính xác dữ liệu trạng thái và tránh xung đột.

·Thao tác đọc: Khi một giao dịch cần đọc trạng thái, EVM trước tiên sẽ kiểm tra ReadSet đang chờ xử lý -tình trạng . Nếu ReadSet hiển thị rằng dữ liệu được yêu cầu tồn tại thì EVM sẽ đọc dữ liệu trực tiếp từ DB trạng thái đang chờ xử lý. Nếu không tìm thấy khóa-giá trị tương ứng (cặp khóa-giá trị) trong ReadSet, dữ liệu trạng thái lịch sử sẽ được đọc từ stateDB toàn cầu tương ứng với khối trước đó.

·Thao tác ghi: Tất cả các thao tác ghi (tức là sửa đổi trạng thái) sẽ không được ghi trực tiếp vào stateDB toàn cục mà trước tiên sẽ được ghi lại trong WriteSet của trạng thái Đang chờ xử lý. Sau khi quá trình thực hiện giao dịch hoàn tất, hãy thử hợp nhất các kết quả thay đổi trạng thái vào stateDB toàn cầu thông qua phát hiện xung đột.

Vấn đề chính khi thực thi song song là xung đột trạng thái, điều này đặc biệt quan trọng 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. Để đạt được mục tiêu này, Reddio đã giới thiệu cơ chế phát hiện xung đột:

·Phát hiện xung đột:Trong quá trình thực hiện giao dịch, EVM sẽ giám sát ReadSet của các giao dịch khác nhau và WriteSet. Nếu tìm thấy nhiều giao dịch đang cố gắng đọc hoặc ghi cùng một mục trạng thái thì đó được coi là 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 thi, các bản ghi thay đổi trong nhiều DB trạng thái đang chờ xử lý sẽ được hợp nhất vào stateDB toàn cầu. Nếu hợp nhất thành công, EVM sẽ cam kết trạng thái cuối cùng với cây trạng thái toàn cầu và tạo ra gốc trạng thái mới.

Sự cải thiện hiệu suất của tối ưu hóa song song đa luồng là rõ ràng, đặc biệt là khi xử lý các giao dịch hợp đồng thông minh phức tạp.

Theo nghiên cứu về EVM song song, trong khối lượng công việc có xung đột thấp (ít giao dịch xung đột hơn trong nhóm giao dịch hoặc các giao dịch chiếm cùng tài nguyên), TPS của điểm chuẩn kiểm tra So với thực hiện nối tiếp truyền thống, nó được cải thiện khoảng 3 đến 5 lần. Trong khối lượng công việc có xung đột cao, về mặt lý thuyết, nó thậm chí có thể đạt tới 60 lần nếu sử dụng tất cả các phương pháp tối ưu hóa.

Tóm tắt

Giải pháp tối ưu hóa song song đa luồng EVM của Reddio , 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 các giao dịch song song trong các luồng khác nhau, khả năng xử lý giao dịch của EVM được cải thiện đáng kể. Bằng cách tối ưu hóa các hoạt động đọc và ghi và giới thiệu cơ chế phát hiện xung đột, chuỗi công khai dựa trên EVM có thể đạt được sự song song hóa các giao dịch trên quy mô lớn trong khi vẫn đảm bảo tính nhất quán của trạng thái và giải quyết tắc nghẽn hiệu suất do chế độ thực thi nối tiếp 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.

Chúng tôi sẽ phân tích sâu hơn chi tiết triển khai Reddio trong tương lai, chẳng hạn như cách nâng cao hơn nữa hiệu quả bằng cách tối ưu hóa hiệu suất lưu trữ và tối ưu hóa khi xung đột là Giải pháp cao và cách sử dụng GPU để tối ưu hóa, v.v.