Báo cáo sau đây nhằm mục đích tập hợp các dữ liệu, với hy vọng sẽ trở thành nguồn tài liệu giúp ACD đưa ra quyết định về Đề xuất cải tiến Ethereum (EIP)-7907.
Ngoài ra, điều này hy vọng sẽ thiết lập một phương pháp mới để sao lưu các EIP hoặc đề xuất với càng nhiều dữ liệu càng tốt, điều chắc chắn có thể giúp đưa ra các quyết định tốt hơn và sáng suốt hơn khi xác định phạm vi các nhánh phát triển.
Tôi muốn gửi lời cảm ơn đến @rjl493456442 vì PR bổ sung các chỉ số vào Geth và những lời khuyên cũng như sự hỗ trợ của anh ấy trong quá trình thu thập dữ liệu chuẩn, điều này vô cùng hữu ích. Và tôi muốn chuẩn hóa việc này trên tất cả các khách hàng để chúng ta có thể dễ dàng so sánh và thu thập dữ liệu nhằm đưa ra quyết định về việc định giá lại và mở rộng quy mô.
Vấn đề liên quan:** Đề xuất cải tiến Ethereum (EIP)-7907
Ngày: 13/01/2026
Môi trường kiểm chuẩn: Geth (chế độ phát triển) với cơ sở dữ liệu kích thước mainnet (~24 triệu khối), bộ nhớ đệm nội bộ bị vô hiệu hóa.
Cấu hình thử nghiệm: ~18.106 thao tác EXTCODESIZE mỗi Block (tất cả đều là các hợp đồng mã byte khác nhau), ~50 triệu gas
Phần cứng: WD Black SN850X NVMe (8TB)
Tóm tắt
Báo cáo này phân tích hiệu năng của opcode EXTCODESIZE khi đọc các hợp đồng có kích thước bytecode khác nhau (0,5KB đến 64KB) với bộ nhớ đệm mã nội bộ của Geth bị vô hiệu hóa . Điều này thể hiện kịch bản tấn công tồi tệ nhất, trong đó kẻ tấn công triển khai hàng nghìn hợp đồng độc nhất để buộc phải đọc dữ liệu từ ổ đĩa.
Quá trình lặp lại này cũng có chi phí hoạt động thấp nhất có thể nhờ vào việc tạo địa chỉ xác định bằng CREATE2 .
Bạn có thể tìm thêm thông tin về vấn đề này tại:
- Tính năng: Thêm kịch bản extcodesize_setup để triển khai các hợp đồng chuẩn EXTCODESIZE bởi CPerezz · Yêu cầu kéo #161 · ethpandaops/spamoor · GitHub
- feat(benchmark): thêm benchmark kích thước bytecode EXTCODESIZE cho kiểm thử truy cập lạnh bởi CPerezz · Yêu cầu kéo #1961 · ethereum/execution-specs · GitHub
Những phát hiện chính
| Tìm kiếm | Giá trị |
|---|---|
| Khoảng thời gian đọc mã | 107ms - 904ms (đối với khoảng 18.000 lần đọc mã) |
| Phạm vi độ trễ mỗi cuộc gọi | 5,9µs - 49,9µs |
| Điều chỉnh thời gian đọc mã | Tăng trưởng gấp 8,5 lần (0,5KB → 64KB) |
| Thời gian thực thi Block 64KB | ~1006ms |
| Mã được đọc (%) Block Time | 51% (0.5KB) → 90% (64KB) |
| Hiệu năng của Geth so với NVMe thô | 24-51% |
Phán quyết Đề xuất cải tiến Ethereum (EIP)-7907
| Kích cỡ | Block Time | % ngân sách của 1 người | Phán quyết |
|---|---|---|---|
| 24KB (hiện tại) | 535ms | 54% | An toàn |
| 32KB | 685ms | 69% | An toàn |
| 64KB | 1006ms | ~100% | Có thể hoạt động ở mức 60 triệu gas. |
| 128KB+ | Dự kiến 1,5 giây trở lên | >100% | Có thể cần điều chỉnh lại gas . Chúng ta cần thêm dữ liệu sau khi có BALs và ePBS. |
Khuyến nghị: Tiếp tục sử dụng 64KB làm kích thước hợp đồng tối đa mới. Vượt quá 64KB sẽ yêu cầu thu thập dữ liệu mới sau khi các tối ưu hóa của BAL và ePBS được triển khai trên tất cả các máy khách.
Nếu cần định giá lại sau khi thu thập dữ liệu như đã đề cập ở trên, việc định giá đó cũng đòi hỏi phải so sánh với các khách hàng khác cũng như xem xét các mã lệnh EXTCODE* còn lại.
1. Phương pháp luận & Thiết lập tiêu chuẩn so sánh
1.1 Môi trường thử nghiệm
| Tham số | Giá trị |
|---|---|
| Phiên bản Geth | v1.16.8-unstable (với nhiều bản vá lỗi) |
| Cơ sở dữ liệu | Mạng chính đã được đồng bộ hóa (~24 triệu khối) |
| Bộ nhớ đệm Geth | Đã vô hiệu hóa (buộc phải đọc dữ liệu từ ổ đĩa) |
| Kích thước hợp đồng đã được kiểm tra. | 0.5, 1, 2, 5, 10, 24, 32, 64 KB |
| các thao tác EXTCODESIZE | ~18.106 mỗi Block |
| Gas trên mỗi Block | ~50 triệu |
| Các hợp đồng đã triển khai | Hơn 18.100 hợp đồng độc đáo cho mỗi kích thước |
| Số lần lặp trên mỗi kích thước | 8 |
| Phần cứng | Ổ cứng SSD NVMe WD Black SN850X 8TB |
1.2 Thiết kế kịch bản tấn công
Điểm chuẩn này thể hiện cuộc tấn công tồi tệ nhất nhắm vào EXTCODESIZE :
- Hơn 18.100 hợp đồng độc nhất được triển khai cho mỗi kích thước (gây ra lỗi bộ nhớ cache mã)
- Mỗi Block đọc mã bytecode từ tất cả các hợp đồng duy nhất đúng một lần.
- Tỷ lệ truy cập bộ nhớ cache mã: <2% (thực tế đã bị vô hiệu hóa)
- Bộ nhớ đệm trang hệ điều hành được xóa giữa các lần chạy thử nghiệm hiệu năng.
1.3 Đường cơ sở đĩa thô (fio)
Để xác định hiệu năng tối đa về mặt lý thuyết, chúng tôi đã đo lường khả năng thô của NVMe:
| Block Size | IOPS | Xuất lượng | Độ trễ trung bình |
|---|---|---|---|
| 512B | 337K | 172 MB/s | 95 µs |
| 1KB | 320K | 328 MB/s | 100 µs |
| 4KB | 272K | 1,1 GB/giây | 117 µs |
| 24KB | 171K | 4,2 GB/giây | 185 µs |
| 32KB | 155K | 5,1 GB/giây | 204 µs |
| 64KB | 85 nghìn | 5,6 GB/giây | 366 µs |
2. Kết quả so sánh
2.1 Thời gian đọc mã so với kích thước mã byte
Kết luận chính: Thời gian đọc mã tỷ lệ thuận với kích thước mã byte khi bộ nhớ đệm không hiệu quả.
| Kích cỡ | Mã đã đọc (ms) | Tăng trưởng so với 0,5KB |
|---|---|---|
| 0.5KB | 107ms | 1.0x (mức cơ bản) |
| 1KB | 135ms | 1,3 lần |
| 2KB | 142ms | 1,3 lần |
| 5KB | 145ms | 1,4 lần |
| 10KB | 161ms | 1,5 lần |
| 24KB | 428ms | 4.0x |
| 32KB | 584ms | 5,5 lần |
| 64KB | 904ms | 8,5 lần |
Điểm mấu chốt: Thời gian đọc mã tăng gấp 8,5 lần khi kích thước bytecode tăng gấp 128 lần. Đây là sự gia tăng dưới mức tuyến tính (không phải 1:1), nhưng tác động về thời gian tuyệt đối là đáng kể.
2.2 Số byte đã đọc so với thời gian đọc mã (Hệ số tương quan)
Hệ số tương quan dương mạnh (R² ≈ 0,96) xác nhận rằng thời gian đọc mã tỷ lệ thuận với tổng số byte đã đọc khi bộ nhớ đệm không hiệu quả.
2.3 Độ trễ mỗi cuộc gọi
Độ trễ mỗi lần gọi tăng theo kích thước mã byte:
| Kích cỡ | Độ trễ mỗi cuộc gọi | Sự phát triển |
|---|---|---|
| 0.5KB | 5,9 µs | 1.0x |
| 1KB | 7,5 µs | 1,3 lần |
| 10KB | 8,9 µs | 1,5 lần |
| 24KB | 23,7 µs | 4.0x |
| 32KB | 32,3 µs | 5,5 lần |
| 64KB | 49,9 µs | 8,5 lần |
3. Phân tích thời gian thực hiện
3.1 Phân tích thành phần
Việc đọc mã trở thành yếu tố chi phối khi kích thước bytecode lớn hơn:
| Kích cỡ | Đọc mã | Đã đọc tài khoản | Giám đốc Máy ảo Ethereum (EVM) | Ghi vào cơ sở dữ liệu | Khác | Tổng cộng |
|---|---|---|---|---|---|---|
| 0.5KB | 107ms (51%) | 54ms | 34ms | 12ms | 2ms | 209ms |
| 1KB | 135ms (57%) | 53ms | 37ms | 12ms | 1ms | 238ms |
| 10KB | 161ms (59%) | 53ms | 40ms | 12ms | 5ms | 271ms |
| 24KB | 428ms (80%) | 44ms | 46ms | 15ms | 2ms | 535ms |
| 32KB | 584ms (85%) | 38ms | 47ms | 13ms | 3ms | 685ms |
| 64KB | 904ms (90%) | 38ms | 51ms | 12ms | 1ms | 1006ms |
Quan sát: Ở mức 64KB, việc đọc mã chiếm 90% thời gian thực thi Block . Điều này khác biệt đáng kể so với các trường hợp sử dụng bộ nhớ đệm nóng, nơi việc đọc mã chỉ chiếm 8-10%.
4. Phân tích ngân sách Block Time (Trọng tâm Đề xuất cải tiến Ethereum (EIP)-7907)
4.1 Mục tiêu về thời gian so với ngân sách
Sử dụng mục tiêu 1 giây để thực thi Block :
| Kích cỡ | Block Time | % ngân sách của 1 người | Trạng thái |
|---|---|---|---|
| 0.5KB | 209ms | 21% | Tiết kiệm hơn nhiều so với dự toán |
| 1KB | 238ms | 24% | Tiết kiệm hơn nhiều so với dự toán |
| 2KB | 248ms | 25% | Tiết kiệm hơn nhiều so với dự toán |
| 5KB | 252ms | 25% | Tiết kiệm hơn nhiều so với dự toán |
| 10KB | 271ms | 27% | Tiết kiệm hơn nhiều so với dự toán |
| 24KB | 535ms | 54% | Dưới ngân sách |
| 32KB | 685ms | 69% | Dưới ngân sách |
| 64KB | 1006ms | ~100% | Ở mức giới hạn |
Kết luận: Các hợp đồng 64KB khả thi trong điều kiện tấn công tồi tệ nhất ở khối 60 triệu gas . Thời gian thực thi ~1 giây nằm ở giới hạn ngân sách nhưng vẫn chấp nhận được. Lưu ý rằng đây là giới hạn khá thận trọng vì ePBS & BAL có thể sẽ định hình lại những gì chúng ta coi là ngân sách an toàn trong tương lai gần.
4.2 Tốc độ xử lý gas (Phân tích định giá sai)
| Kích cỡ | Gas đã sử dụng | Block Time | Mgas/s |
|---|---|---|---|
| 0.5KB | 49,4 triệu | 209ms | 236 |
| 1KB | 49,4 triệu | 238ms | 208 |
| 10KB | 49,4 triệu | 271ms | 182 |
| 24KB | 49,4 triệu | 535ms | 92 |
| 32KB | 49,4 triệu | 685ms | 72 |
| 64KB | 49,4 triệu | 1006ms | 49 |
Quan sát thấy sự định giá sai: Cùng một chi phí gas , nhưng thời gian thực thi khác nhau gấp 5 lần (236 Mgas/s → 49 Mgas/s). Điều này cho thấy rằng trong điều kiện xấu nhất, các hợp đồng lớn hơn sẽ gây ra chi phí cao hơn một cách không cân xứng cho các trình xác thực.
Ý nghĩa đối với dung lượng 128KB trở lên: Đối với dung lượng trên 64KB, cần điều chỉnh mô hình gas —có thể là chi phí cơ bản cộng với thành phần phụ thuộc vào kích thước.
Hãy lưu ý rằng đây là một phương án khá thận trọng. Bởi vì để "dừng" mạng lưới hoặc "gây tổn hại đáng kể cho các trình xác thực chậm", cần phải thiết lập số lượng hợp đồng gấp hàng trăm lần so với 18.000 hợp đồng duy nhất. Điều này dẫn đến chi phí khổng lồ (chúng ta không thể sử dụng lại chúng vì chúng sẽ được lưu vào bộ nhớ cache sau khi Block đầu tiên được thực thi).
5. Hiệu năng cơ bản của ổ đĩa thô (So sánh hiệu năng Geth và NVMe)
5.1 So sánh hiệu quả
| Kích cỡ | IOPS Geth | IOPS NVMe thô | Hiệu quả | Xuất lượng Geth | NVMe thô | Hiệu quả |
|---|---|---|---|---|---|---|
| 0.5KB | 171K | 337K | 51% | 83 MB/s | 172 MB/s | 48% |
| 1KB | 142K | 320K | 44% | 139 MB/s | 328 MB/s | 42% |
| 24KB | 43K | 171K | 25% | 1,0 GB/giây | 4,2 GB/giây | 24% |
| 32KB | 31 nghìn | 155K | 20% | 979 MB/s | 5,1 GB/giây | 19% |
| 64KB | 20 nghìn | 85 nghìn | 24% | 1,26 GB/giây | 5,6 GB/giây | 23% |
Quan sát: Geth đạt được 20-51% hiệu năng ổ đĩa thô. Khoảng cách này có thể là do:
- Chi phí phát sinh của Pebble/LevelDB (duyệt chỉ mục, bộ lọc Bloom)
- Băm khóa và tra cứu
- Giải mã giá trị
6. So sánh với kịch bản bộ nhớ đệm nóng
6.1 Hiệu năng khi sử dụng bộ nhớ đệm so với khi không sử dụng bộ nhớ đệm
| Kích cỡ | Bộ nhớ đệm ấm | Bộ nhớ đệm lạnh | Chậm lại |
|---|---|---|---|
| 0.5KB | 5,3ms | 107ms | 21x |
| 1KB | 4,4ms | 135ms | 31x |
| 2KB | 4,5ms | 142ms | 32x |
| 5KB | 4,6ms | 145ms | 31x |
| 10KB | 4,7ms | 161ms | 34x |
| 24KB | 4,8ms | 428ms | 89x |
| 32KB | 4,9ms | 584ms | 119x |
| 64KB | 4,9ms | 904ms | 181x |
Kết quả "chi phí cố định" từ các bài kiểm tra hiệu năng bộ nhớ đệm nóng vẫn đúng trong điều kiện hoạt động bình thường. Điều kiện bộ nhớ đệm lạnh đòi hỏi các kịch bản tấn công cực đoan (hơn 18.000 hợp đồng duy nhất).
7. Ý nghĩa đối với Đề xuất cải tiến Ethereum (EIP)-7907 & Các khuyến nghị
7.1 Tóm tắt các phát hiện
- Thời gian đọc mã tỷ lệ thuận với kích thước tệp trong điều kiện bị tấn công (gấp 8,5 lần từ 0,5KB đến 64KB).
- 64KB là khả thi với khối gas 60M — thời gian thực thi trong trường hợp xấu nhất khoảng ~1 giây, nằm trong phạm vi ngân sách.
- Đây là trường hợp xấu nhất tuyệt đối — việc triển khai và duy trì hơn 18.000 hợp đồng độc nhất là không khả thi (bạn cần một bộ hợp đồng mới cho mỗi Block mà bạn muốn thực hiện cuộc tấn công).
- Hoạt động bình thường không bị ảnh hưởng — các kịch bản bộ nhớ đệm nóng cho thấy chi phí cố định khoảng ~5ms
- Việc định giá gas sai lệch đang bị tấn công (thời gian thực thi chênh lệch gấp 5 lần với cùng gas).
7.2 Khuyến nghị Đề xuất cải tiến Ethereum (EIP)-7907
| Hoạt động | Sự giới thiệu |
|---|---|
| Giới hạn 64KB | Tiếp tục - khả thi ngay cả trong trường hợp tấn công tồi tệ nhất. Không cần Đề xuất cải tiến Ethereum (EIP). |
| Giới hạn 128KB+ | Cần đo lại bằng BALs + ePBS |
Có vẻ như chúng ta chỉ cần "giữ mọi thứ đơn giản" và cung cấp cho các nhà phát triển Hợp đồng thông minh một bản nâng cấp tốt về giới hạn kích thước mã mà không cần thay đổi giao thức nào ngoài giới hạn 64kB và việc tăng kích thước mã khởi tạo.
Khi BAL và ePBS được hoàn thiện hơn, chúng ta sẽ có thể dựa vào dữ liệu để đưa ra quyết định tốt hơn về việc định giá lại/hoặc chuyển sang 256kB.
Nhưng việc điều chỉnh giá vào lúc này có vẻ không cần thiết đối với một sản phẩm mà ngay cả trong trường hợp xấu nhất cũng không thực sự cần thiết.
7.3 Tại sao 64KB là chấp nhận được
Tính bất khả thi của cuộc tấn công: Triển khai hơn 18.000 hợp đồng 64KB độc nhất đòi hỏi:
- ~13 triệu gas cho mỗi lần triển khai hợp đồng (32K cơ bản + 64K × 200 gas/byte)
- Hàng trăm khối chỉ để thiết lập
- Chi phí duy trì bề mặt tấn công rất đáng kể.
Block Time nằm trong ngân sách: Ngay cả trường hợp xấu nhất là khoảng 1 giây cũng có thể chấp nhận được đối với các khối gas 60M.
Hiệu quả của bộ nhớ đệm trong thực tế: Các khối mạng chính thực tế tái sử dụng hợp đồng; tỷ lệ truy cập bộ nhớ đệm mã thường cao.
Tăng trưởng dưới tuyến tính: Thời gian gấp 8,5 lần để đạt được mức tăng trưởng kích thước gấp 128 lần cho thấy khấu hao vẫn hữu ích.
