Xin chân thành cảm ơn Toni và Dragan vì những phản hồi và đánh giá!
Tóm tắt
Ethereum đang mở rộng quy mô L1 bằng cách tăng dần Gas Limit Block . Tuy nhiên, việc tăng Gas Limit lên cao hơn đáng kể (ví dụ: mức tăng gấp 100 lần do Dankrad đề xuất ) nhanh chóng gặp phải giới hạn cứng – tốc độ I/O ổ đĩa và tốc độ thực thi CPU. Việc làm nóng trước và danh sách truy cập cấp khối ( BAL ) Đề xuất cải tiến Ethereum (EIP) -7928 loại bỏ hầu hết các tắc nghẽn đọc I/O, chuyển nút thắt cổ chai chính sang chính quá trình thực thi. Trong khi đó, các máy khách hiện tại vẫn thực thi các giao dịch tuần tự, về cơ bản giới Xuất lượng.
BAL ( một ý tưởng mà nhóm chúng tôi cũng đã nghiên cứu hai năm trước đó ) mở khóa khả năng thực thi song song hoàn hảo, tuy nhiên, giới hạn hiệu năng của nó vẫn chưa rõ ràng. Để giải quyết vấn đề này, chúng tôi đã xây dựng một môi trường thực thi thuần túy với:
- trạng thái được tải trước, mô phỏng một môi trường trong đó các tài khoản, khe lưu trữ và mã hợp đồng có liên quan được giải quyết trước thông qua các gợi ý BAL ;
- Người gửi tx đã được khôi phục trước, tận dụng khả năng khôi phục người gửi song song đã được triển khai trong hầu hết các ứng dụng khách;
- Bỏ qua việc tính toán trạng thái gốc, chi phí của việc này có thể được phân bổ cho các khối lớn hơn.
Sử dụng môi trường này, chúng tôi đã đánh giá hiệu năng thực thi song song trên mỗi giao dịch với BAL. Kết quả của chúng tôi cho thấy Xuất lượng thực thi thuần túy vượt quá 10 GigaGas/giây trên một máy tính cá nhân 16 lõi thông thường hiện đại, trong khi máy khách Reth hiện tại chỉ đạt khoảng 1,2 GigaGas/giây trong cùng điều kiện. Điều này cho thấy việc thực thi Máy ảo Ethereum (EVM) có thể mở rộng quy mô gấp nhiều lần so với mức cơ bản hiện tại của máy khách một khi các nút thắt cổ chai đã đề cập ở trên được giải quyết triệt để.
Chúng ta đang ở đâu hôm nay
Ethereum đang tăng Gas Limit từ 45 triệu lên 60 triệu trong bản nâng cấp Fusaka. Giả sử Gas Limit được tăng lên 100 lần, Block kết quả sẽ chứa khoảng 4,5 tỷ gas. Để giữ thời gian xác thực dưới ba giây, các trình xác thực do đó sẽ cần ít nhất 1,5 GigaGas/giây Xuất lượng thực thi. Tuy nhiên, các điểm chuẩn công khai của Base cho thấy các máy khách hiện đại trên phần cứng thông thường chỉ đạt tối đa khoảng 600 MGas/giây. Giới hạn này chủ yếu là do thực thi tuần tự: mặc dù có sẵn CPU đa lõi, nhưng các máy khách hiện tại xử lý các giao dịch tuần tự, khiến hầu hết các lõi không được sử dụng hết công suất.
| Tải trọng Tx | Geth MGas/s | Reth MGas/s |
|---|---|---|
| mô phỏng mạng chính cơ sở | 316,4 | 591,6 |
Khoảng cách giữa hiệu năng hiện tại (~0,6 GGas/s) và hiệu năng cần thiết để mở rộng gấp 100 lần (~1,5 GGas/s) vẫn còn đáng kể — điều này thúc đẩy chúng tôi hướng tới việc thực thi Máy ảo Ethereum (EVM) hoàn toàn song song.
Cách chúng tôi đã làm điều đó
Để nghiên cứu hiệu năng thực thi song song tối ưu mà BAL mang lại, chúng tôi đã xây dựng một môi trường thực thi thuần túy bằng cách loại bỏ tất cả các thành phần không liên quan đến thực thi, cho phép chúng tôi đo lường giới hạn trên thực sự của khả năng song song hóa được hỗ trợ bởi BAL. Tận dụng thiết kế không có GC của Rust, khả năng kiểm soát chi tiết việc lập lịch đa luồng và hiệu năng cao của Reth, chúng tôi đã sửa đổi máy khách Reth và sử dụng revm làm công cụ thực thi Máy ảo Ethereum (EVM) cho thí nghiệm này.
Đơn giản hóa cho mô phỏng thực thi thuần túy
- Toàn bộ trạng thái chuỗi được tải vào bộ nhớ trước (vì chúng ta có thể thực hiện I/O theo lô dựa trên vị trí đọc của BAL).
- Tất cả các giao dịch đều được thực hiện với thông tin người gửi đã được khôi phục (quá trình khôi phục người gửi có thể được thực hiện song song hoàn toàn từ trước).
- Không có thao tác tính toán gốc trạng thái và cam kết cơ sở dữ liệu nào được thực hiện sau khi thực thi (đây là một điểm nghẽn, nhưng không phải là trọng tâm chính của nghiên cứu này).
Công tác kỹ thuật và thiết lập
- Đã sửa đổi máy khách Reth để hỗ trợ việc xuất toàn bộ các phụ thuộc thực thi, bao gồm các khối, BAL, 256 mã băm Block cuối cùng và các trạng thái trước khối được giải quyết từ các gợi ý tập hợp đọc BAL .
- Đã thêm bộ chuyển đổi cho Revm để tải
blockEnv,statevàtxEnv, và để tạo một phiên bản Máy ảo Ethereum (EVM) riêng biệt cho mỗi giao dịch. - Độ chi tiết song song = theo từng giao dịch .
- Cấu hình phần cứng: AMD Ryzen 9 5950X (16 nhân), RAM 128 GB.
- Tập dữ liệu: 2000 khối mạng chính (
#23600500–23602500). - Chỉ số: Gas tiêu thụ mỗi giây = tổng lượng gas đã sử dụng / thời gian mô phỏng thực thi thuần túy.
Bộ công cụ so sánh hiệu năng có sẵn tại đây: 
https://github.com/dajuguan/evm-benchmark
Kết quả
Quá trình đánh giá của chúng tôi bắt đầu bằng việc cân bằng hiệu năng tuần tự cho revm, sau đó dần dần giới thiệu khả năng thực thi song song. Phân tích khả năng mở rộng song song cho thấy độ trễ của các giao dịch chạy lâu nhất tạo thành đường dẫn quan trọng giới hạn tốc độ tăng tổng thể. Để giảm bớt hạn chế này, chúng tôi đã mô phỏng giới hạn gas Block lớn hơn, điều này đã mở khóa khả năng song song đáng kể với BAL. Với 16 Threads và Gas Limit Block 1G, Xuất lượng thực thi thuần túy đạt khoảng ~14 GGas/s .
Căn chỉnh đường cơ sở với quá trình thực thi tuần tự
Chúng tôi đã thử tái tạo kết quả benchmark của Reth trước tiên. Trong một lần chạy tuần tự trên dữ liệu mainnet với thiết lập KZG được tải trước, hiệu năng thực thi thuần túy đạt 1.212 MGas/s.
Kết quả thu được theo trình tự này sẽ đóng vai trò là điểm tham chiếu cho tất cả các thí nghiệm tiếp theo của chúng tôi.
Thực thi song song và các nút thắt cổ chai trên đường dẫn quan trọng
Để đánh giá cả tốc độ tăng hiệu suất thực tế và ảnh hưởng của định luật Amdahl đến tính song song ở cấp độ giao dịch, chúng tôi đã tiến hành các thí nghiệm thực thi song song trên từng giao dịch để định lượng tác động của các giao dịch chạy lâu nhất đến tốc độ tăng hiệu suất có thể đạt được.
Kết quả chi tiết được hiển thị bên dưới (trong đó “độ trễ giao dịch dài nhất” là tổng thời gian thực thi của các giao dịch chạy lâu nhất trong mỗi Block):
| Threads | Xuất lượng (mg gas/giây) | Độ trễ TX dài nhất | Tổng thời gian |
|---|---|---|---|
| 1 | 1258 | 6,06 giây | 33,47 giây |
| 2 | 2460 | 6,04 giây | 17,12 giây |
| 4 | 3753 | 6,10 giây | 10,71 giây |
| 8 | 4824 | 6.00 giây | 8,73 giây |
| 16 | 5084 | 6,04 giây | 8,29 giây |
Nhìn chung, kết quả về khả năng mở rộng phù hợp chặt chẽ với định luật Amdahl: mặc dù Xuất lượng tăng lên khi có nhiều Threads hơn, thời gian thực thi Block bị giới hạn bởi giao dịch dài nhất, chiếm khoảng 70% tổng thời gian thực thi với 16 Threads, giới hạn tốc độ tăng có thể đạt được ở mức khoảng 5 lần thay vì mức lý tưởng 16 lần đối với máy 16 lõi. Điều này cho thấy khả năng mở rộng được xác định bởi các đường dẫn quan trọng trên mỗi khối chứ không phải khả năng tính toán thô.
Hạn chế về đường dẫn quan trọng này có thể được giảm thiểu bằng cách giảm bớt sự chi phối của giao dịch dài nhất, ví dụ như thông qua Đề xuất cải tiến Ethereum (EIP)-7825: giới Gas Limit giao dịch hoặc bằng cách tăng Gas Limit Block — phương pháp được nghiên cứu trong bài viết này.
7928 + Mega Blocks = Khả năng xử lý song song quy mô lớn
Vì các đường dẫn quan trọng trên mỗi khối giới hạn khả năng xử lý đồng thời, chúng tôi đã thử nghiệm với các "khối lớn" có mức gas cao hơn để tăng tính song song. Để mô phỏng điều này, chúng tôi đã thực hiện các giao dịch của nhiều khối mạng chính liên tiếp, cụ thể là một Block lớn hoặc một lô giao dịch, song song, và sau đó chỉ cam kết trạng thái (không thực hiện gì trong thí nghiệm) sau khi tất cả các giao dịch trong lô đã hoàn tất. Điều này giúp tổng hợp nhiều khối thành một đơn vị thực thi lớn duy nhất.
Phân tích song song dưới khối lượng công việc khổng lồ
Chúng tôi đã tiến hành đánh giá một lô 50 khối, mô phỏng mức sử dụng gas trung bình Block là 1.053 MB, với số lượng luồng khác nhau. Kết quả đầy đủ được hiển thị bên dưới:
| Threads | Xuất lượng (mg gas/giây) | Độ trễ TX dài nhất | Tổng thời gian |
|---|---|---|---|
| 1 | 1.440 | 0,50 giây | 29,26 giây |
| 2 | 2.793 | 0,50 giây | 15,08 giây |
| 4 | 5.167 | 0,52 giây | 8,15 giây |
| 8 | 9.095 | 0,54 giây | 4,63 giây |
| 16 | 14.001 | 0,59 giây | 3,01 giây |
Với các khối lớn như vậy, các giao dịch chạy lâu nhất không còn chi phối đường dẫn quan trọng nữa—chúng chỉ đóng góp chưa đến 20% tổng thời gian thực thi với 16 Threads. Xuất lượng lượng tăng gần như tuyến tính với số luồng: với 16 Threads, chúng tôi đạt được 14 GGas/s, nhanh hơn khoảng 10 lần so với thực thi tuần tự và gần với tỷ lệ tuyến tính lý tưởng. Điều này cực kỳ đáng khích lệ. Trong các thí nghiệm của chúng tôi, đường dẫn quan trọng còn lại duy nhất là quá trình biên dịch trước point_evaluation , vốn không dễ dàng song song hóa.
Xuất lượng dưới các mức sử dụng gas Block khác nhau
Để đánh giá khả năng mở rộng của việc thực thi song song khi mức sử dụng gas Block tăng lên, chúng tôi đã thực thi các lô khối liên tiếp trong khi thay đổi kích thước lô Block — số lượng khối được nhóm lại thành một mega Block duy nhất —qua đó mô phỏng mức sử dụng gas Block hiệu quả khác nhau.
| Threads | Kích thước lô Block | Gas Block (M) | Xuất lượng (mg gas/giây) |
|---|---|---|---|
| 16 | 1 | 21 | 5.084 |
| 16 | 2 | 42 | 6.641 |
| 16 | 5 | 105 | 8.814 |
| 16 | 10 | 210 | 10.228 |
| 16 | 25 | 526 | 12.152 |
| 16 | 50 | 1.053 | 14.001 |
| 16 | 100 | 2.106 | 14.887 |
| 16 | 200 | 4.212 | 15.298 |
Khi lượng gas sử dụng cho Block tăng lên, Xuất lượng tiếp tục tăng, nhưng mức tăng song song gia tăng giảm từ khoảng 30% xuống còn khoảng 3% cho mỗi lần tăng gấp đôi lượng gas dụng cho mỗi Block . Khi kích thước lô vượt quá khoảng 50 khối (khoảng 1.053 triệu gas sử dụng Block ), việc tăng thêm lượng gas sử dụng cho Block chỉ mang lại Xuất lượng bổ sung không đáng kể.
Triển vọng
Các thí nghiệm của chúng tôi cho thấy rằng việc kết hợp Đề xuất cải tiến Ethereum (EIP)-7928 với các khối lớn cho phép thực thi giao dịch mở rộng quy mô cực kỳ tốt, đạt được Xuất lượng thực thi thuần túy 14 GigaGas/giây trên bộ xử lý 16 lõi thông thường hiện đại. Tuy nhiên, vẫn còn một số câu hỏi chưa được giải đáp:
1. Khôi phục người gửi
Chúng tôi đã loại bỏ tính năng khôi phục người gửi khỏi tiêu chuẩn hiệu năng thực thi thuần túy. Trong thí nghiệm của chúng tôi, việc kích hoạt tính năng này làm giảm Xuất lượng khoảng 2/3, xuống còn khoảng 5 GigaGas/s trong cấu hình mega-block (1.053 M gas Block ).
Giải pháp khả thi: Khôi phục người gửi bằng GPU.
2. Mô hình định giá gas
Quá trình biên dịch trước point_evaluation và khôi phục người gửi cho các giao dịch 7702 cho thấy hiệu quả gas trên mỗi đơn vị thời gian thấp. Có thể cần xem xét lại giá gas của chúng trong kỷ nguyên Đề xuất cải tiến Ethereum (EIP)-7928.
3. Gas Limit giao dịch
Việc đặt giới hạn gas Block lớn hơn có thể yêu cầu duy trì Gas Limit giao dịch hiện tại để đảm bảo tính song song cao.
4. Đẩy nhanh tiến độ xây dựng BAL
Hiệu năng của trình xây dựng dự kiến sẽ trở thành nút thắt cổ chai chính. Việc cải thiện quá trình xây dựng BAL là điều cần thiết để theo kịp Xuất lượng thực thi thuần túy.
5. Tối ưu hóa việc cam kết trạng thái
Việc cam kết trạng thái là một nút thắt cổ chai lớn khác. Tăng tốc độ tính toán trạng thái gốc và tối ưu hóa việc cam kết cây trie là cần thiết để duy trì khả năng thực thi thông lượng cao.
Các tác phẩm khác
Chúng tôi cũng đã khám phá các chiến lược lập lịch tác vụ khác nhau, ví dụ như ưu tiên các giao dịch tiêu tốn nhiều gas bằng cách sắp xếp chúng theo gas đã sử dụng hoặc Gas Limit, cùng với bộ lập lịch danh sách có thứ tự đơn giản (OLS), trong đó các giao dịch được giữ nguyên thứ tự Block tự nhiên và mỗi giao dịch mới được gán cho lõi khả dụng đầu tiên. Tuy nhiên, khi áp dụng cho dữ liệu mạng chính, việc ưu tiên các giao dịch tiêu tốn nhiều gas chỉ mang lại những cải thiện hiệu suất nhỏ và không ảnh hưởng đáng kể Xuất lượng tổng thể.
Xuất lượng dưới các chiến lược lập lịch khác nhau
Để đánh giá tác động đến Xuất lượng tổng thể, chúng tôi đã so sánh việc ưu tiên lập lịch các giao dịch sử dụng nhiều khí (dựa trên gas sử dụng hoặc Gas Limit) với phương pháp bình phương nhỏ nhất thông thường (OLS).
- Kết quả trên các khối thông thường:
| Threads (Bộ lập lịch) | Xuất lượng (mg gas/giây) | Độ trễ truyền tải dài nhất | Tổng thời gian |
|---|---|---|---|
| 2 (gas đã sử dụng) | 2.726 | 5,70 giây | 15,45 giây |
| 2 (Gas Limit) | 2.728 | 5,68 giây | 15,44 giây |
| 2 (OLS) | 2.460 | 6,04 giây | 17,12 giây |
| 4 (gas đã sử dụng) | 4.401 | 6,09 giây | 9,57 giây |
| 4 (Gas Limit) | 4.321 | 6,18 giây | 9,75 giây |
| 4 (OLS) | 3.753 | 6,10 giây | 10,71 giây |
| 8 (gas đã sử dụng) | 5.455 | 6,15 giây | 7,72 giây |
| 8 (Gas Limit) | 5.426 | 6,13 giây | 7,76 giây |
| 8 (OLS) | 4.824 | 6.00 giây | 8,73 giây |
| 16 (gas đã sử dụng) | 5.643 | 6,03 giây | 7,47 giây |
| 16 (Gas Limit ) | 5.531 | 6,05 giây | 7,62 giây |
| 16 (OLS) | 5.084 | 6,04 giây | 8,28 giây |
- Kết quả trên các khối lớn với gas trung bình mỗi Block là 1053 triệu:
| Threads (Bộ lập lịch) | Xuất lượng (mg gas/giây) | Độ trễ truyền tải dài nhất | Tổng thời gian |
|---|---|---|---|
| 2 (Gas Limit) | 2.732 | 0,53 giây | 15,42 giây |
| 2 (OLS) | 2.793 | 0,50 giây | 15,08 giây |
| 4 (Gas Limit) | 5.114 | 0,54 giây | 8,24 giây |
| 4 (OLS) | 5.167 | 0,52 giây | 8,15 giây |
| 8 (Gas Limit) | 9.082 | 0,57 giây | 4,64 giây |
| 8 (OLS) | 9.095 | 0,54 giây | 4,63 giây |
| 16 (Gas Limit) | 14.181 | 0,63 giây | 2,97 giây |
| 16 (OLS) | 14.001 | 0,59 giây | 3,01 giây |
Phân tích của Toni cho thấy rằng việc ưu tiên các giao dịch có lượng gas lớn có thể vượt trội hơn OLS từ 20–80% trong trường hợp xấu nhất. Tuy nhiên, trên thực tế, khi sử dụng dữ liệu mainnet thực (đại diện cho trường hợp trung bình), sự cải thiện chỉ khoảng 10%, và việc lập lịch theo Gas Limit, gas đã sử dụng hoặc OLS cho thấy sự khác biệt tối thiểu. Trên các megablock, OLS hoạt động gần như giống hệt với việc lập lịch theo giới hạn gas. Những quan sát này cho thấy rằng việc lập lịch giao dịch không phải là nút thắt cổ chai chính; thay vào đó, sự phân phối giao dịch vốn có trên mainnet tạo thành đường dẫn quan trọng.
