Mở rộng quy mô trong Hegota: sử dụng việc chuyển ETH để neo giữ quá trình thực thi và băng thông.

avatar
Ethereum Research
Bài viết này được dịch máy
Xem bản gốc

Tôi xin cảm ơn Toni Wahrstaetter, Marius Vanderwijden và Parithosh Jayanthi vì những cuộc thảo luận đã dẫn đến báo cáo này.

Bài viết này sẽ phân tích những gì Hegota cần thay đổi để tiếp tục mở rộng giới hạn gas sau sự kiện Glamsterdam. Điểm xuất phát là một quan sát duy nhất: việc chuyển ETH với mức gas 21.000 giới hạn cả hai chiều của khe thời gian.

  • Về khía cạnh thực thi, việc điều chỉnh giá tại Glamsterdam đã đẩy chi phí lên mức tối đa mà giới hạn chuyển nhượng cho phép, ấn định mức thực thi tồi tệ nhất ở mức 100 Mgas/s.
  • Về mặt băng thông, một khối chứa đầy các giao dịch chuyển tiền bản thân nó là một tải trọng dữ liệu (bao bì, chữ ký và các mục BAL) mà không có công cụ định giá nào có thể xử lý mà không tính phí cao hơn 21k.

Do đó, chúng tôi sử dụng khối truyền tải đầy đủ làm khối neo . Chúng tôi tính toán hiệu suất băng thông của nó, tìm ra thời hạn PTC tối đa hóa giới hạn gas, so sánh nó với khối calldata + SLOAD của đối thủ, và sau đó đặt câu hỏi điều này có ý nghĩa gì đối với sự phát triển trạng thái, lịch sử và bộ nhớ.

Những phát hiện chính

  • Giao dịch chuyển 21k ETH neo cả hai phía của khe thời gian. Nó đóng băng quá trình thực thi trong trường hợp xấu nhất ở mức 100 Mgas/giây và thiết lập mật độ byte không thể giảm xuống là ~0,0105 B/gas (221 B mỗi lần chuyển, trường hợp xấu nhất) mà không có công cụ định giá nào có thể vượt qua được. Khối neo lan truyền ở tốc độ ~214 Mgas/giây, vì vậy nó bị giới hạn bởi quá trình thực thi, và việc giải quyết cả hai mức trần ở bộ đệm đối xứng 25% sẽ cho ra ~422M với thời hạn PTC là ~6,4 giây . Chúng tôi coi bộ đệm 25% là một hướng dẫn, không phải là mức sàn cứng, và nới lỏng nó một chút để có được các con số tròn: chúng tôi khuyến nghị 450M ở $D = 6$s , điều này sẽ chạy khối neo ở bộ đệm thực thi trong trường hợp xấu nhất là ~25% và bộ đệm lan truyền là ~11%.

  • Nhiệm vụ định giá lại của Hegota là đưa mọi cấu hình định giá xuống mức đường truyền. Vì chúng ta không thể định giá lại đường truyền mà không chạm đến giới hạn 21k, nên mục tiêu là tạo ra trường hợp xấu nhất ngay từ đầu. Định giá Glamsterdam không đáp ứng được điều này: khối dữ liệu cuộc gọi hỗn hợp + SLOAD nằm ở mức gấp khoảng 2,2 lần đường truyền và giữ hệ thống ở mức khoảng 302M, thấp hơn khoảng 120M so với mức tối ưu. Giải pháp là nâng mức sàn dữ liệu cuộc gọi lên một lần nữa (64 → 96) cộng với phạm vi bao phủ các byte BAL, hoặc giới thiệu một tốc độ dữ liệu cuộc gọi thống nhất duy nhất (~94) — đánh đổi độ phức tạp của cơ chế lấy phạm vi xảy ra sự cố.

  • Dưới ngưỡng chuyển giao, chỉ có những tối ưu hóa hơn nữa mới có thể dịch chuyển điểm tối ưu. Cơ chế định giá có thể cân bằng thành phần tại ngưỡng này nhưng không thể giảm xuống dưới ngưỡng đó. Mỗi lần cải thiện 10% thời gian truyền tải trên mỗi kb sẽ làm tăng giới hạn gas lên khoảng +14–18 triệu, tối đa là 618 triệu. Song song đó, việc cải thiện thời gian thực thi các giao dịch ETH sẽ cho phép các điểm neo thực thi cao hơn, từ đó cho phép giới hạn cao hơn mà không cần thay đổi thời hạn PTC.

Lý lịch

Glamsterdam cung cấp ePBS ( EIP-7732 ), BAL ( EIP-7928 ) và gói định giá lại, bao gồm các EIP định giá dữ liệu 7976 (calldata floor 64/64, standard 4/16) và 7981 (access-list bytes ở mức giá sàn). Việc định giá lại nhắm đến hiệu suất thực thi trong trường hợp xấu nhất là 100 Mgas/giây. Mục tiêu này không thể nâng cao hơn nữa: làm như vậy sẽ yêu cầu định giá lại chi phí gas của một giao dịch chuyển ETH vượt quá 21.000, điều này sẽ làm hỏng chức năng trong một số ví phần cứng. Vì vậy, đối với Hegota, mức neo thực thi 100 Mgas/giây được cố định và khả năng mở rộng bổ sung phải đến từ các tối ưu hóa (cả về thực thi và lan truyền), thay đổi thời hạn PTC và (riêng biệt) từ việc làm cho các hoạt động tính toán quá đắt trở nên rẻ hơn. Tùy chọn cuối cùng được phân tích song song và chỉ xuất hiện trong báo cáo này thông qua một tương tác được ghi chú sau đó.

Các giả định được sử dụng xuyên suốt bài viết:

Tham số Giá trị Ghi chú
Điểm neo thực thi R R 100 Mgas/giây Bị đóng băng bởi giới hạn chuyển nhượng 21k.
Khe cuối T_3 T 3 12 giây
Hạn chót xác nhận khối đèn hiệu T_1 T 1 3 giây Thời điểm bắt đầu truyền tải dữ liệu sớm nhất theo ePBS; so sánh 2 giây và 3 giây vẫn còn bỏ ngỏ.
Bộ đệm an toàn 25% trên cả cửa sổ thực thi và cửa sổ lan truyền Đây chỉ là hướng dẫn, không phải mức tối thiểu bắt buộc; điểm khuyến nghị 450M/6s cho hiệu suất thực thi khoảng 25% / hiệu suất lan truyền khoảng 11%.
Mô hình lan truyền t = 569 + 0,443 \cdot \text{KB} t = 569 + 0,443 ⋅ KB ms (p90, MEV-boost) Từ phân tích kích thước khối trường hợp xấu nhất của Toni; kích thước nén nhanh, được đo sau khi giải phóng ( p_{90} - \min p 90 − min ). Khối chuyển được coi là không thể nén (sau khi nén nhanh ≈ thô)
SLOAD lạnh 3.000 Số liệu sơ bộ của EIP-8038 ; không thay đổi trong Hegota.
Truy cập tài khoản lạnh ( BALANCE ) 3.000 Số liệu sơ bộ của EIP-8038 ; không thay đổi trong Hegota.
Kho lạnh SSTORE 13.000 Số liệu sơ bộ của EIP-8038 ; không thay đổi trong Hegota.
Giá cước Calldata Sàn 64/64, tiêu chuẩn 4/16 EIP-7976/7981
Sự thành lập nhà nước CPSB = 1530 , cố định Thông số kỹ thuật EIP-8037 mới nhất (tham chiếu 150M, 120 GiB/năm)

Bản đồ các nguồn tài nguyên

Việc này giúp sắp xếp các nguồn lực theo loại ràng buộc mà chúng phải tuân theo, vì điều đó quyết định cách mỗi nguồn lực phản ứng với giới hạn khí đốt cao hơn:

Tài nguyên Loại ràng buộc Điều gì sẽ xảy ra ở mức giới hạn cao hơn (giá vé Glamsterdam)? Hành động Hegota
Thực thi Mỗi vị trí, sau D D Thời gian thực thi trong trường hợp xấu nhất tăng theo G G ; được đánh đổi bằng sự lan truyền thông qua D D Không có sự điều chỉnh giá tăng (theo giả định)
Băng thông Tính theo từng vị trí, trước D D Tải trọng trường hợp xấu nhất tăng theo G G ; các byte BAL không được tính phí. Thay đổi nhánh (phần cốt lõi của báo cáo này)
sự phát triển của tiểu bang Tích lũy (đĩa) Tốc độ tăng trưởng tăng theo G vì CPSB cố định . Tái tạo CPSB (mục phân nhánh)
Lịch sử Tổng cộng (đĩa + khẩu phần) Phát triển cùng với G G Điều kiện tiên quyết về ngày hết hạn; xem xét LOGDATA
Ký ức Mỗi giao dịch (RAM) Không tăng theo G G (giới hạn trên mỗi tx bởi EIP-7825 ) Không có

Các phần tiếp theo sẽ đề cập đến sự đánh đổi trên mỗi khe (quyết định giới hạn gas), và chúng ta sẽ quay lại với tổng tài nguyên tích lũy ở cuối.

Khối chuyển tiếp đóng vai trò là khối neo.

Một lần truyền dữ liệu chứa bao nhiêu byte?

Một lần truyền dữ liệu không ghi vào bộ nhớ và không chạy mã lệnh nào, nhưng nó vẫn gửi các byte: bao bì và chữ ký của nó, cộng với các bản ghi mà EIP-7928 lưu giữ cho nó trong BAL.

Một giao dịch chuyển khoản loại 2 có kích thước thực tế khoảng 110 B: chữ ký ( r , s mỗi chữ ký chiếm 32 B, cộng thêm y_parity ) chiếm khoảng 65 B và địa chỉ người nhận 20 byte chiếm khoảng 21 B sau khi được đóng khung RLP, còn lại khoảng 25 B cho nonce, hai trường phí, giới hạn gas, giá trị, ID chuỗi và danh sách truy cập trống. Chúng tôi làm tròn lên 130 B trong bảng như một kích thước gói tối đa trong các loại giao dịch hiện tại.

Đối với BAL, một giao dịch chuyển khoản liên quan đến hai tài khoản (người gửi: số dư + nonce; người nhận: số dư). Vì RLP mã hóa số dư với độ dài tối thiểu (≤ 11 B, giới hạn bởi tổng nguồn cung ETH, không phải 32) và nonce trong khoảng 1–2 B, nên đóng góp cận biên trong trường hợp xấu nhất là khoảng 91 B.

Kịch bản Sự thi công B mỗi lần chuyển khoản \beta_t β t (byte/gas)
Kế toán trường hợp xấu nhất 130 phong bì + 91 BAL 221 0,01052

Mô hình lan truyền được hiệu chỉnh trên các byte sau khi xử lý bằng Snappy , vì vậy chúng tôi ánh xạ 221 byte thô này lên đường truyền bằng cách coi khối truyền tải là không thể nén được (sau khi xử lý Snappy ≈ thô). Điều này đảm bảo an toàn trong trường hợp xấu nhất — chữ ký là các byte ngẫu nhiên mà Snappy không thể can thiệp — và là giả định quan trọng nhất của báo cáo: bất kỳ sự nén thực sự nào chỉ làm nới lỏng giới hạn và nâng cao giới hạn gas có thể đạt được. Việc đo độ dốc byte biên được nén trên các khối được mã hóa thực tế là nhiệm vụ dữ liệu quan trọng nhất mà báo cáo này xác định.

Hạn chót của PTC nên được đặt ở đâu?

Thời hạn D D chia khe thời gian thành cửa sổ lan truyền, từ $T_1 = 3$s đến D D , và cửa sổ thực thi, từ D D đến 12s. Tuân thủ nguyên tắc bộ đệm 25% cho cả hai, giới hạn gas L L là khả thi khi khối neo có thể vừa lan truyền vừa thực thi kịp thời:

L \le 0,75 \cdot R \cdot (12 - D) \qquad \text{(thực hiện)}
L ≤ 0,75 ⋅ R ⋅ ( 12 − D ) (thực thi)
0,443 \cdot \beta_t \cdot \frac{L}{1000} + 569 \;\le\; 0,75 \cdot (D - T_1) \cdot 1000 \qquad \text{(lan truyền)}
0,443 ⋅ β t ⋅ L 1000 + 569 ≤ 0,75 ⋅ ( D − T 1 ) ⋅ 1000 (sự lan truyền)

Trần nhà đầu tiên hạ xuống khi D D di chuyển muộn hơn; trần nhà thứ hai nâng lên. Điểm tối ưu là điểm giao nhau:

Kịch bản D^* D ∗ (s) L^* L ∗ Tải trọng tại L^* L ∗
Kế toán trường hợp xấu nhất (221 B) 6,38 422 triệu 4,44 MB

Mức tối ưu khi neo chuyển khoản, tuân thủ hướng dẫn 25% trên cả hai cửa sổ, là ~422M tại $D \approx 6.4$s . Vùng đệm 25% là một hướng dẫn chứ không phải là mức sàn cứng nhắc, vì vậy chúng tôi nới lỏng nó một chút để đề xuất các con số hoạt động tròn — 450M tại $D = 6$s , di chuyển thời hạn sớm hơn một chút để đánh đổi khoảng không lan truyền lấy giới hạn cao hơn. Vùng đệm thực thi giữ ở mức ~25%; vùng đệm lan truyền hấp thụ sự dịch chuyển, giảm từ 25% xuống ~11% — khối neo sau đó sử dụng ~89% cửa sổ lan truyền thay vì 75%:

Điểm vận hành Bộ đệm thực thi Bộ đệm lan truyền
422M @ 6.38s (tối ưu đối xứng) 25% 25%
450M @ 6s (khuyến nghị) ~25% ~11%

Sự không chắc chắn còn lại nằm ở việc khớp lan truyền (phân vị p90 và phương pháp nhấn mạnh phần đuôi của Toni so với phương pháp bảo thủ \sqrt{n\cdot\text{kích thước}} √ n ⋅ kích thước ) và giả định nén sau khi xử lý nhanh. Những cải tiến về lan truyền (bên dưới) sẽ khôi phục vùng đệm đối xứng 25% ở mức 450M, hoặc đẩy giới hạn lên cao hơn.

Khối đối kháng

Việc bị chặn chuyển khoản không phải là trường hợp tồi tệ nhất.

Khối chuyển khoản neo giữ vị trí, nhưng nó không phải là khối có mật độ cao nhất mà chúng ta có thể xây dựng — \beta_t \approx 0.0105 β t ≈ 0.0105 B/gas là mức sàn, chứ không phải mức trần. Vì chúng ta không thể định giá khối chuyển khoản mà không chạm đến giới hạn 21k, mục tiêu của chúng ta là tạo ra trường hợp xấu nhất bằng cách xây dựng: mọi thành phần mà giao thức định giá phải mang tối đa \beta_t β t byte mỗi gas . Bất kỳ khối nào được định giá trên \beta_t β t sẽ chiếm giữ vị trí trước khối chuyển khoản và kéo L^* L ∗ xuống dưới 422M, vì vậy chúng ta kiểm tra từng khối một.

Mật độ byte của một khối tài nguyên đơn lẻ là dấu vết byte trên mỗi thao tác chia cho chi phí gas của nó, \beta = b/c β = b / c :

  • 1/F 1 / F để lấy dữ liệu cuộc gọi ở tầng đó
  • 32/c 32 / c cho SLOAD nguội (khóa BAL 32 byte)
  • 20/c 20 / c để truy cập tài khoản lạnh như BALANCE (địa chỉ 20 byte)
  • 64/c 64 / c cho SSTORE lạnh (khóa 32 byte + giá trị 32 byte trong BAL)

Khối hỗn hợp bổ sung lượng dữ liệu cuộc gọi giá rẻ nhất có thể — tốc độ tiêu chuẩn 16 gas/byte, lên đến phần vẫn nằm dưới mức tối thiểu 7976 — và lấp đầy phần còn lại bằng các gói SLOAD lạnh:

\beta(F, c) = \frac{1 - 512/c}{F} + \frac{32}{c}
β ( F , c ) = 1 − 512 / c F + 32 độ C

Khi đánh giá thực đơn với mức giá giả định cho Glamsterdam ( SLOAD lạnh 3.000, truy cập tài khoản lạnh 3.000, SSTORE lạnh 13.000, sàn dữ liệu cuộc gọi F = 64 F = 64 ), ta được:

Khối Sự thi công \beta β (B/gas) × đường truyền
Chuyển khoản ETH (neo) 221 B / 21.000 khí 0,01052 1,00×
Kho lạnh SSTORE 64 B / 13.000 0,00492 0,47×
CÂN BẰNG BALANCE 20 B địa chỉ / 3.000 0,00667 0,63×
SLOAD lạnh 32 phím B / 3.000 0.01067 1,01×
Gọi dữ liệu ở tầng 1/F 1 / F , F = 64 F = 64 0,01563 1,49×
Kết hợp 25% dữ liệu cuộc gọi@16 + 75% SLOAD \beta(64, 3000) β ( 64 , 3000 ) 0.02363 2,25×

Những quan sát chính:

  • Chỉ có SLOAD lạnh mới có thể sánh ngang với đường truyền. Một BALANCE lạnh chỉ ghi địa chỉ 20 byte của nó vào BAL với tốc độ 3.000 gas (0,63×), và một SSTORE lạnh ghi một cặp khóa+giá trị 64 byte với tốc độ 13.000 gas (0,47×) — cả hai đều thấp hơn đáng kể. Khóa lưu trữ 32 byte được trả bằng 3.000 gas của SLOAD lạnh là thứ có mật độ byte cao nhất mà truy cập trạng thái có thể thêm vào mỗi gas, đó là lý do tại sao các khối tấn công được xây dựng từ thao SLOAD lạnh.

  • Cold SLOAD về cơ bản nằm trên đường thẳng. Ở mức 3.000 gas, khóa 32 byte của nó cho tốc độ 0,01067 B/gas, cao hơn 1% so với \beta_t β t ; đường thẳng đạt được chính xác tại c = 3{,}041 c = 3,041 .

  • Hai khối dữ liệu được định giá vượt quá giới hạn: dữ liệu cuộc gọi thuần túy (1,49×) và khối dữ liệu hỗn hợp (2,25×). Cả hai đều vượt quá giới hạn do cùng một nguyên nhân gốc rễ — dữ liệu cuộc gọi được định giá thấp hơn giới hạn chuyển giao — nhưng, như chúng ta sẽ trình bày tiếp theo, chúng cần các giải pháp khác nhau.

Đòn bẩy nhỏ nhất: nâng lại mức sàn dữ liệu cuộc gọi.

Khối dữ liệu cuộc gọi thuần túy bị vượt quá giới hạn vì một lý do duy nhất: mức sàn EIP-7976 là 64 gas/byte ngụ ý 1/64 = 0,0156 1 / 64 = 0,0156 B/gas, cao hơn 49% so với \beta_t β t . Cách khắc phục là một hằng số duy nhất — nâng mức sàn lên

F^* = \left\lceil 1 / \beta_t \right\rceil = \lceil 1 / 0.01052 \rceil = \lceil 95.06 \rceil = 96 \text{ gas/byte}
F ∗ = ⌈ 1 / β t ⌉ = ⌈ 1 / 0,01052 ⌉ = ⌈ 95,06 ⌉ = 96 gas/byte

Đây là thay đổi giá dữ liệu dễ thực hiện nhất của Hegota. Tuy nhiên, điều này vẫn không khắc phục được vấn đề khối hỗn hợp. Việc tăng F F làm giảm tỷ lệ dữ liệu gọi giá rẻ (từ 16/64 = 25% xuống 16/96 = 16,7 % ) nhưng phần còn lại của SLOAD lạnh SLOAD tục thêm byte vào BAL, dẫn đến mật độ byte tổng thể là \beta(96, 3000) = 0,0193 β ( 96 , 3000 ) = 0,0193 B/gas. Con số này vẫn cao hơn mức cho phép 1,84 lần.

Trên thực tế, khi F → ∞ , mật độ byte có xu hướng tiến tới 32/c , chính là mật độ khối SLOAD . Điều này có nghĩa là không có mức sàn dữ liệu cuộc gọi hữu hạn nào có thể làm giảm khối hỗn hợp xuống đủ thấp.

Ba cách để chế ngự khu đất hỗn hợp

Điểm nghẽn còn lại là khối hỗn hợp, ở mức 1,84 lần đường truyền. Chúng ta có ba lựa chọn. Hai lựa chọn đầu tiên định giá các byte BAL mà dữ liệu cuộc gọi không thể nhìn thấy, được xếp chồng lên trên mức tăng từ 64 lên 96 vừa được tính toán; lựa chọn thứ ba không định giá BAL và thay vào đó loại bỏ cấu trúc dữ liệu cuộc gọi tốc độ kép mà khối hỗn hợp khai thác.

Phương án 1: Các byte BAL trong mức sàn. Giải pháp hiển nhiên là bắt đầu bao gồm các byte BAL trong tính toán mức sàn. Đề xuất này từ Toni mở rộng mức sàn kiểu 7623 cho mọi byte dữ liệu, bao gồm cả các byte BAL. Mỗi byte có giá sau đó sẽ cho ra tối đa 1/96 byte mỗi gas, mà không thay đổi SLOAD chút nào. Chi phí là một cơ chế tính toán gas mới giúp duy trì bộ tích lũy mức sàn trong thời gian chạy , tác động đến mọi đường dẫn truy cập lạnh. Điều này chỉ tác động đến phía mức sàn, vì vậy người dùng thông thường và quá trình truyền tải 21k không bị ảnh hưởng.

Phương án 2: Phụ phí dữ liệu nội tại. Hoặc, chúng ta có thể thêm một thành phần dữ liệu rõ ràng vào mỗi thao tác đóng góp BAL (truy cập lạnh, lưu trữ lạnh, v.v.). Đây chỉ là các hằng số, cơ chế đơn giản nhất trên mức sàn. Nhưng việc định giá các byte BAL theo cách này thực chất là việc định giá lại quyền truy cập trạng thái. Việc đưa khối hỗn hợp vào đường dây đòi hỏi phải tăng đáng kể chi phí truy cập trạng thái lạnh, điều này không phù hợp với lý luận neo đóng băng mặc dù nó an toàn khi thực thi. Ngoài ra, điều này còn làm sai lệch thêm việc định giá các khối mã lệnh thuần túy, vốn đã nằm dưới đường dây.

Phương án 3: Giá dữ liệu cuộc gọi đồng nhất, không tính phí BAL. Khối hỗn hợp hoạt động vì dữ liệu cuộc gọi có hai mức giá — mức giá tiêu chuẩn rẻ 16 gas/byte, được đẩy lên mức chia sẻ sàn, và mức sàn cao hơn nữa. Nếu chúng ta đặt cho dữ liệu cuộc gọi một mức giá duy nhất p p , nút thắt cổ chai này sẽ biến mất. Mỗi byte dữ liệu cuộc gọi có giá p p , vì vậy khối dữ liệu cuộc gọi bị giới hạn ở mức 1/p 1 / p và việc trộn nó vào một khối trạng thái chỉ làm giảm mật độ. Trường hợp xấu nhất sau đó sẽ quay trở lại hoạt động trạng thái không định giá có mật độ cao nhất, đó là SLOAD lạnh ở mức 32/c 32 / c . Vì vậy, p p chỉ cần ngăn dữ liệu cuộc gọi thuần túy vượt qua SLOAD :

\frac{1}{p} \le \frac{32}{c} \;\Rightarrow\; p \ge \frac{c}{32} \approx 94 \text{ gas/byte} \quad (c = 3{,}000)
1 trang ≤ 32 độ C ⇒ p ≥ c 32 ≈ 94 gas/byte ( c = 3.000 )

Mức này chỉ thấp hơn một chút so với mức sàn 96: việc bỏ mức sàn chỉ thay đổi người trả tiền, chứ không phải tỷ lệ phí. Mức sàn 96 chỉ áp dụng cho các giao dịch có dung lượng dữ liệu lớn, trong khi mức sàn đồng nhất 94 tính phí theo tỷ lệ sàn cho mỗi byte dữ liệu cuộc gọi. Đây là mức tăng khoảng 6 lần so với tỷ lệ tiêu chuẩn 16. Đổi lại, đây là cơ chế đơn giản nhất (một tỷ lệ phí, không tính toán số dư, không sử dụng max() ).

Sự lựa chọn nằm giữa độ phức tạp của cơ chế và phạm vi ảnh hưởng. Phương án 1 có tác động nhỏ nhất đến người dùng — nó chỉ ảnh hưởng đến các khối vượt quá ngưỡng calldata — nhưng nó lại giới thiệu một cơ chế tính phí gas mới. Cả hai phương án 2 và 3 đều chỉ thay đổi các hằng số, nhưng chúng ảnh hưởng đến mọi người dùng của các thao tác ảnh hưởng đến BAL (phương án 2) hoặc mọi người dùng của calldata (phương án 3). Phương án 3 sạch sẽ và dễ bảo vệ hơn phương án 2, vì các thao tác tạo ra byte BAL đã có giá chính xác cho cả việc thực thi và chi phí băng thông của chúng. Khối hỗn hợp chỉ khai thác cấu trúc tốc độ kép của calldata, vì vậy việc loại bỏ nó là một giải pháp trực tiếp mà không cần phải động đến các byte BAL.

Điều gì sẽ xảy ra nếu tốc độ lan truyền nhanh hơn?

Cơ chế định giá có thể cân bằng các thành phần tại đường truyền nhưng không thể giảm xuống dưới mức đó. Vượt quá điểm đó, chỉ có mô hình lan truyền mới có thể thay đổi, thông qua việc tái cấu trúc tải trọng dựa trên mempool (hầu hết các byte tải trọng đã nằm trong mempool của các thiết bị ngang hàng), cải tiến về gossip và cấu trúc liên kết, hoặc phổ biến mã hóa xóa lỗi. Chạy lại quá trình giao nhau trung tâm với độ dốc tốt hơn x% x % :

Cải thiện độ dốc D^* D ∗ (s) L^* L ∗
— (0,443 ms/KB) 6,38 422 triệu
-10% 6.19 436 triệu
-20% 6.00 450 triệu
-30% 5,79 466 triệu
-40% 5,56 483 triệu
-50% 5,32 501 triệu
Chỉ giảm một nửa thời gian xử lý (569 → 285 ms) 6.12 441 triệu

Mô hình này xấp xỉ +14–18 triệu giới hạn gas cho mỗi 10% cải thiện độ dốc , với thời hạn dịch chuyển sớm hơn theo từng bước; độ dốc -20% đạt mức 450 triệu tại $D = 6,0 giây — khôi phục bộ đệm đối xứng 25% ở giới hạn được khuyến nghị — và -50% đạt khoảng 501 triệu tại $D xấp xỉ 5,3 giây. Giảm một nửa chi phí cố định (569 → 285 ms) tương đương với khoảng một phần mười độ dốc (~+19 triệu). Lưu ý rằng các tải trọng truyền tải nặng là hình dạng ít nén nhất (chữ ký là các byte ngẫu nhiên), vì vậy các cải tiến dựa trên nén giúp phần đuôi của kẻ tấn công nhiều hơn là chính khối neo.

Giới hạn cứng của toàn bộ khung này là khả năng thực thi: khi D D tiến đến T_1 T 1 cộng với chi phí cố định, cửa sổ thực thi sẽ bão hòa ở mức ~8,2 giây, tức là 618 triệu ở mức 75% của 100 Mgas/giây. Vượt quá mức đó đòi hỏi phải tăng thông lượng thực thi thực tế, đó là điều mà phân tích song song về việc định giá lại các hoạt động tính toán quá đắt đỏ đề cập đến. Công việc đó liên kết trở lại báo cáo này ở một điểm: việc thực thi rẻ hơn đẩy nhiều giao dịch hơn vào sàn dữ liệu cuộc gọi, vì vậy tỷ lệ xảy ra ở F = 96 F = 96 nên được đánh giá so với chi phí thực thi sau khi định giá lại.

Ảnh hưởng đối với các nguồn lực khác

Tăng trưởng của tiểu bang: tái xác định CPSB

Bản đặc tả EIP-8037 mới nhất sửa lỗi CPSB = 1530 , được tính toán dựa trên giới hạn tham chiếu 150 triệu cho mục tiêu 120 GiB/năm, và hoãn việc tính toán lại cho đến lần phân nhánh tiếp theo. Nếu vẫn giữ nguyên giá trị 1530, tốc độ tăng trưởng mục tiêu ở giới hạn 450 triệu sẽ là khoảng 360 GiB/năm. Sử dụng cách tính toán riêng của bản đặc tả ở các giới hạn mới, ta có:

Điểm vận hành CPSB Khe cắm mới (64 B) Tài khoản mới (120 B) Triển khai 24 KiB
450 triệu ~4.600 294k 551 nghìn 113M khí đốt tự nhiên
501M (độ giãn p2p) ~5.110 327 nghìn 613 nghìn 126M khí đốt tự nhiên

Việc chuyển khoản không bị ảnh hưởng trong cả hai trường hợp, vì chỉ việc tạo tài khoản mới mới phải trả phí gas của tiểu bang, trong chiều không gian riêng biệt với mô hình bể chứa.

Ngoài ra còn có câu hỏi về việc nhu cầu thực tế sẽ phản ứng như thế nào với giới hạn khối cao hơn và CPSB tăng lên. Giá trị cuối cùng có thể sẽ khác đi sau khi chúng ta quan sát cách người dùng thích nghi với nhánh Glamsterdam.

Lịch sử: Không cần định giá lại, nhưng hạn sử dụng trở nên quan trọng hơn.

Lịch sử geth được đo (tiêu đề, nội dung và biên nhận) tăng khoảng 525 MiB/ngày — khoảng 180 GiB/năm — ở giới hạn 36 triệu trong khoảng thời gian từ tháng 5 năm 2024 đến tháng 5 năm 2025 ( thông tin chi tiết hơn tại đây ). Nhân tuyến tính lên 450 triệu sẽ cho kết quả khoảng 2,2 TiB/năm . Con số này đã bao gồm nhật ký, nằm trong biên nhận, nhưng cửa sổ đo lường diễn ra trước khi có BAL, vì vậy số liệu này bỏ qua chúng. BAL (EIP-7928) là kênh lịch sử thứ hai có kích thước tương đương — khoảng 41% số byte của một khối truyền tải, và chiếm ưu thế đối với các cấu trúc nặng về truy cập trạng thái — nhưng EIP-7928 cho phép cắt tỉa các BAL được lưu trữ về gốc băm của chúng, do đó đóng góp bền vững của chúng phụ thuộc vào cửa sổ lưu giữ.

Với tốc độ tăng trưởng lịch sử như hiện tại, việc hết hạn lịch sử luân chuyển (thuộc họ EIP-4444) trở nên quan trọng hơn đối với các nhà xác thực. Tuy nhiên, tốc độ tăng trưởng này vẫn có thể quản lý được, do đó không cần thiết phải định giá lại.

Bộ nhớ: không có gì để làm

Dung lượng bộ nhớ EVM trong trường hợp xấu nhất là dung lượng trên mỗi giao dịch: chi phí mở rộng bậc hai so với giới hạn EIP-7825 sẽ giới hạn một khung hình duy nhất ở mức ~3–4 MB, và bộ nhớ được giải phóng giữa các giao dịch được thực thi tuần tự. Giới hạn khối cao hơn sẽ thêm các giao dịch trên mỗi khối, chứ không phải bộ nhớ đồng thời. Điều này chỉ thay đổi nếu giới hạn 7825 được nâng lên hoặc giá bộ nhớ tuyến tính (EIP-7923/7686) được áp dụng mà không có giới hạn bù trừ.

Tính toán: Điều chỉnh giá giảm

Mặt trái của việc đóng băng mức neo 100 Mgas/s là hầu hết các thao tác hiện nay đều có giá quá cao so với mức đó: thời gian chạy của máy khách trong trường hợp xấu nhất nằm dưới chi phí gas hiện tại, do đó chúng tiêu tốn nhiều ngân sách gas của khối hơn thời gian thực tế chúng thực hiện. Dựa trên kết quả hiệu suất máy khách hiện tại , chúng ta có thể định giá lại khoảng 62 thao tác EVM và biên dịch trước, trong đó 36 thao tác có chi phí dưới 1 gas ở mức neo. Đó là các thao tác số học, bitwise, ngăn xếp và bộ nhớ có chi phí thấp và tần suất cao.

Việc định giá quá cao này đồng nghĩa với việc lãng phí thông lượng. Trên lưu lượng mạng chính , khoảng 12,4% phí gas của khối hiện đang bị lãng phí cho các hoạt động được tính phí cao hơn chi phí thực thi hợp lý. Việc định giá lại theo cách làm tròn số nguyên ( max(⌈exact⌉, 1) ) sẽ giảm con số đó xuống còn khoảng 2,6% .

Mức tăng 10% là tốt, nhưng rất có thể nó không bù đắp được chi phí định giá lại 62 hoạt động. Do đó, khuyến nghị ở đây là không thay đổi chi phí tính toán ở Hegota.

Hegota thực sự vận chuyển cái gì vậy?

# Mục Kiểu
1 Giới hạn khí → ~450M, $D = 6$s Phối hợp xác thực, được kiểm soát ở mức 2–5
2 Dữ liệu cuộc gọi tầng 64 → 96 Một hằng số (7976/7981)
3 Sửa lỗi khối hỗn hợp: Cặp sàn BAL, phụ phí nội tại hoặc giá dữ liệu cuộc gọi đồng nhất (~94) Quyết định cơ chế mở duy nhất
4 Tính toán lại CPSB : 1.530 → ~4.600 (~5.110 ở độ giãn p2p) Một hằng số, theo quy trình của tiêu chuẩn 8037.
5 cải thiện độ dốc/đường dây trên cao p2p Đường không phân nhánh: +14–18M cho mỗi độ dốc 10%, tối đa khoảng ~501M

Hạn chế

  • Tất cả các số lan truyền đều kế thừa sự phù hợp tăng cường MEV p90 của Toni ( 569 + 0,443 \cdot \text{KB} 569 + 0,443 ⋅ KB ms, kích thước nén nhanh, được đo sau khi giải phóng là p_{90} - \min p 90 − min ) và giả định $T_1 = 3$s; cả hai đều là lựa chọn, không phải là điều kiện cho trước. Trọng số \sqrt{n\cdot\text{kích thước}} √ n ⋅ kích thước thận trọng của Toni cho độ dốc lớn hơn (và các phép phù hợp cục bộ / phần trăm cao hơn còn lớn hơn nữa), mỗi phép phù hợp đều kéo điểm tối ưu xuống; các điểm giao nhau di chuyển ~51 triệu mỗi giây của T_1 T 1 và tỷ lệ thuận với độ dốc.

  • Con số byte trên mỗi lần truyền được lấy từ mã hóa độ dài tối thiểu RLP đã được xác nhận, do đó chi phí khung được giải quyết; nhưng mô hình lan truyền của Toni được hiệu chỉnh trên các byte sau khi xử lý nhanh và chúng tôi giả định khối truyền không thể nén được (sau khi xử lý nhanh ≈ 221 B thô). Việc nén đường truyền thực tế và sự tăng trưởng của chiều rộng block_access_index theo số lượng giao dịch vẫn chưa được mô hình hóa và làm thay đổi mọi con số tiêu đề — đặc biệt là việc nén chỉ làm nới lỏng giới hạn và làm tăng L^* L ∗ .

  • Mô hình giao thoa coi việc lan truyền và thực thi là hoàn toàn tuần tự với bộ đệm cố định 25%; việc xử lý song song hoặc xác thực chồng chéo sẽ làm dịch chuyển điểm tối ưu ra ngoài.

  • Các số liệu 8037 tuân theo thông số kỹ thuật hiện hành ( CPSB = 1530 ); kho lưu trữ EIPs cục bộ vẫn chứa bản dự thảo tự động mở rộng quy mô cũ hơn, các số liệu trong đó không áp dụng.

  • Các dự báo lịch sử điều chỉnh sự tăng trưởng lịch sử được đo lường hiện nay (tiêu đề, nội dung, biên lai) một cách tuyến tính với giới hạn khí đốt; sự điều chỉnh quan sát được từ 30 triệu lên 36 triệu gần như tuyến tính, nhưng những thay đổi về thành phần (việc áp dụng khối dữ liệu, kích thước BAL thực tế) sẽ làm thay đổi chúng.


Khu vực:
Layer 1
Hợp Đồng Thông Minh
Modular Blockchain
Nguồn
Tuyên bố từ chối trách nhiệm: Nội dung trên chỉ là ý kiến của tác giả, không đại diện cho bất kỳ lập trường nào của Followin, không nhằm mục đích và sẽ không được hiểu hay hiểu là lời khuyên đầu tư từ Followin.
Thích
87
Thêm vào Yêu thích
17
Bình luận
Nội dung liên quan