Đặc tả số liệu thực thi đa máy khách
Đề xuất ban đầu và tài liệu đặc tả kỹ thuật của @rjl493456442 : Các chỉ số hiệu suất Ethereum được tiêu chuẩn hóa - HackMD
Ý tưởng này được Gary khởi xướng khi anh ấy triển khai tính năng ghi nhật Block chậm trong Geth . Từ đó, tôi nhận thấy tính năng này sẽ vô cùng hữu ích cho nhiều việc như được liệt kê bên dưới và đã hợp tác với anh ấy để chuẩn hóa và hiện thực hóa tầm nhìn này.
Theo tôi, điều này có thể giúp ích cho việc định giá lại và các track ScaleL1 cũng như bloatnet (lĩnh vực tôi đang tập trung nghiên cứu). Tuy nhiên, tôi nghĩ chúng ta có thể làm được nhiều hơn thế.
1. Giới thiệu & Động lực
Lý do sáng kiến này tồn tại
Triết lý đa máy khách của Ethereum là một thế mạnh cốt lõi—nhưng nó cũng tạo ra một thách thức: làm thế nào để so sánh hiệu năng giữa các triển khai khác nhau?
Các chỉ số thực thi được tiêu chuẩn hóa giải quyết vấn đề này bằng cách cho phép:
- So sánh hiệu năng giữa các khách hàng khác nhau — So sánh công bằng, tương đồng.
- Giám sát tình trạng mạng — Xác định các điểm nghẽn trong quá trình thực thi trước khi chúng ảnh hưởng đến Consensus.
- Nghiên cứu giao thức dựa trên dữ liệu — Xác thực các đề xuất Đề xuất cải tiến Ethereum (EIP) bằng dữ liệu thực thi thực tế
- Phát hiện bất thường — Phát hiện các khối bất thường ( gas cao, mô hình truy cập trạng thái phức tạp)
Ví dụ thực tế: Phân tích Đề xuất cải tiến Ethereum (EIP)-7907
Phân tích Đề xuất cải tiến Ethereum (EIP)-7907 chứng minh chính xác lý do tại sao các chỉ số thực thi được tiêu chuẩn hóa lại rất quan trọng.
Sử dụng các chỉ số của Geth, tôi đã đo lường:
- Độ trễ đọc mã : từ 107ms đến 904ms tùy thuộc vào kích thước mã bytecode.
- Chi phí xử lý mỗi cuộc gọi có thể tăng từ 5,9µs lên 49,9µs (tăng gấp 8,5 lần từ hợp đồng nhỏ nhất đến hợp đồng lớn nhất).
- Phân tích quá trình thực thi Block : Tách biệt các thao tác đọc mã, đọc tài khoản, thực thi Máy ảo Ethereum (EVM) và ghi vào cơ sở dữ liệu.
Tất cả những hiểu biết này đã giúp đưa ra quyết định sáng suốt hơn rất nhiều. Nhờ đó, quy trình ra quyết định ACD được tối ưu hóa đáng kể.
2. Các chỉ số cốt lõi
Các chỉ số được sắp xếp thành các danh mục bao gồm toàn bộ vòng đời thực thi Block :
| Loại | Đường dẫn JSON | Sự miêu tả |
|---|---|---|
| Thông tin Block | block.* | Số Block , Hash, gas đã sử dụng, số lượng giao dịch |
| Thời gian | timing.* | Thời gian thực thi, xác thực, cam kết và tổng thời gian tính bằng mili giây. |
| Xuất lượng | throughput.* | Tốc độ xử lý Mgas/giây |
| Đọc tiểu bang | state_reads.* | Các thao tác đọc tài khoản, lưu trữ và mã |
| Bang viết | state_writes.* | Thay đổi tài khoản và lưu trữ |
| Bộ nhớ đệm | cache.* | Tỷ lệ truy cập/không truy cập đối với bộ nhớ đệm tài khoản, lưu trữ và mã. |
Định nghĩa số liệu
| Số liệu | Kiểu | Sự miêu tả |
|---|---|---|
block.number | int64 | Block Height |
block.hash | sợi dây | Hash Block (tiền tố 0x) |
block.gas_used | int64 | Tổng lượng gas tiêu thụ |
block.tx_count | int32 | Số lượng giao dịch |
timing.execution_ms | int64 | Thời gian thực hiện giao dịch |
timing.state_read_ms | int64 | Thời gian dành cho việc đọc trạng thái (tài khoản, khe lưu trữ và mã hợp đồng) |
timing.state_hash_ms | int64 | Thời gian dành cho việc nhắc lại tình hình hiện tại. |
timing.total_ms | int64 | Tổng thời gian xử lý Block |
throughput.mgas_per_sec | float64 | Xuất lượng gas (gas_đã_sử_dụng / thời_gian_thực_hành / 1e6) |
state_reads.accounts | int64 | Tải dữ liệu tài khoản (số dư, Nonce, mã Hash) |
state_reads.storage_slots | int64 | Đọc khe lưu trữ |
state_reads.code | int64 | Mã bytecode của hợp đồng đọc |
state_reads.code_bytes | int64 | Tổng số byte mã đã đọc |
state_writes.accounts | int64 | Cập nhật trạng thái tài khoản |
state_writes.storage_slots | int64 | khe lưu trữ ghi |
state_writes.code | int64 | Ghi mã bytecode hợp đồng |
state_writes.code_bytes | int64 | Tổng số byte mã được ghi |
cache.{type}.hits | int64 | Số lần truy cập bộ nhớ cache cho tài khoản/lưu trữ/mã |
cache.{type}.misses | int64 | Lỗi truy cập bộ nhớ cache (yêu cầu đọc dữ liệu từ cơ sở dữ liệu) |
cache.{type}.hit_rate | float64 | Tỷ lệ trúng đích: (hits / (hits + misses)) * 100.0 |
3. Định dạng JSON Block chậm
Khi thời gian thực thi Block vượt quá Threshold có thể cấu hình (mặc định: 1000ms), máy khách sẽ xuất ra nhật ký JSON có cấu trúc:
{ "level" : "warn" "msg" : "Slow block" "block" : { "number" : 19234567 "hash" : "0x1234...abcd" "gas_used" : 29500000 "tx_count" : 234 } "timing" : { "execution_ms" : 1250 "state_read_ms" : 320 "state_hash_ms" : 150 "commit_ms" : 75 "total_ms" : 1475 } "throughput" : { "mgas_per_sec" : 23.60 } "state_reads" : { "accounts" : 5420 "storage_slots" : 12340 "code" : 890 "code_bytes" : 456000 } "state_writes" : { "accounts" : 234 "storage_slots" : 1890 } "cache" : { "account" : { "hits" : 4800 , "misses" : 620 , "hit_rate" : 88.60 } "storage" : { "hits" : 10200 , "misses" : 2140 , "hit_rate" : 82.68 } "code" : { "hits" : 870 , "misses" : 20 , "hit_rate" : 97.75 } } }Yêu cầu thực địa
| Cánh đồng | Yêu cầu | Ghi chú |
|---|---|---|
level , msg |  | Phải là "warn" và "Slow block" |
block.* | | Tất cả các trường thông tin Block đều bắt buộc |
timing.execution_ms | | Số liệu thời gian cốt lõi |
timing.state_read_ms | | Thời gian dành để đọc trạng thái từ cơ sở dữ liệu/bộ nhớ đệm |
timing.state_hash_ms | | Thời gian dành cho việc ôn lại những sai lầm của Merkle. |
timing.commit_ms | | Thời gian dành cho việc lưu trữ trạng thái |
timing.total_ms | | Thời gian xử lý Block từ đầu đến cuối |
throughput.mgas_per_sec | | 2 Decimal thập phân |
state_reads.* | | Tất cả các bộ đếm đã đọc |
state_writes.* | | Tất cả các bộ đếm ghi |
cache.* | | Cấu trúc lồng nhau với số lần trúng/trượt/tỷ lệ trúng |
4. Tình trạng thực hiện
| Khách hàng | Trạng thái | PR |
|---|---|---|
| Geth | Hoàn thành | #33655 |
| reth | Hoàn thành | #21237 |
| Besu | Hoàn thành | #9660 |
| Tâm trí âm phủ | Hoàn thành | #10288 |
5. Những cải tiến tiếp theo
Mục tiêu trung hạn để phân tích hiệu suất chi tiết hơn:
| Sự cải tiến | Sự miêu tả | Lý do |
|---|---|---|
| Số liệu trên mỗi giao dịch | Thời gian và quyền truy cập của từng cá nhân trong quá trình điều trị. | Xác định các giao dịch cụ thể gây ra sự chậm trễ. |
| Số lượng mã lệnh Máy ảo Ethereum (EVM) | SLOAD, SSTORE, CALL, CREATE, EXTCODECOPY | Hiểu rõ các mô hình thực thi, phát hiện các vectơ tấn công từ chối dịch vụ (DoS). |
| Theo dõi quyền truy cập duy nhất | Tài khoản riêng, khe lưu trữ, hợp đồng | Đo lường sự đa dạng về khả năng tiếp cận của tiểu bang và quy mô tập hợp làm việc. |
| Phân tích trước khi biên dịch | Thời gian biên dịch trước (ecrecover, sha256, modexp) | Xác định các thao tác mã hóa tốn kém |
| Thời điểm Merkle hóa | băm lại cây tài khoản so với cây lưu trữ | Chi phí tính toán gốc của trạng thái xác định chính xác |
| Thống kê bộ nhớ/phân bổ | Mức sử dụng bộ nhớ cao nhất, số lượng bộ nhớ được cấp phát trên mỗi Block | Theo dõi áp lực bộ nhớ để lập kế hoạch tài nguyên |
| Thống kê độ sâu thử nghiệm | Độ sâu duyệt cây trie trung bình/tối đa | Hiểu tác động của việc phình to trạng thái |
| Số liệu thực thi song song | Thống kê về mức độ sử dụng luồng và tranh chấp. | Đối với các triển khai Máy ảo Ethereum (EVM) song song |
| Kích thước nhân chứng | Kích thước dữ liệu nhân chứng Verkle/không trạng thái | Chuẩn bị cho khách hàng không quốc tịch |
| Truy cập lạnh so với truy cập ấm | Phân biệt truy cập lần đầu và truy cập bộ nhớ đệm. | Phân tích gas Đề xuất cải tiến Ethereum (EIP) -2929 |
Bài đăng này không chỉ nhằm mục đích cung cấp thông tin mà về cơ bản là để thu thập phản hồi. Chúng tôi muốn biết thêm những thông tin nào mà các nhóm, nhà nghiên cứu và bất kỳ ai khác có thể trích xuất/biết được. ETC dữ liệu nội bộ từ khách hàng khó thu thập đối với họ...
Ngoài ra, chúng tôi cũng muốn biết mình có thể làm gì với điều này, chúng tôi có một vài ý tưởng, và dưới đây là một số mục tiêu khác mà chúng tôi đã liệt kê. Nhưng chúng tôi tin rằng mọi người sẽ có nhiều ý tưởng hơn chúng tôi.
Cảm ơn.
