Về Blob Markets, Điều chỉnh Phí Cơ bản và Tối ưu hóa

Xin cảm ơn đặc biệt Ansgar, Barnabé, Alex, Georgios, Roman và Dankrad về những đóng góp và thảo luận của họ, cũng như Bert, Gajinder và Max về những nỗ lực của họ trong chủ đề này!

Tóm tắt:
Tất cả các cập nhật được đề xuất đều có ý nghĩa về mặt lý thuyết. Chúng ta có nên thực hiện chúng trong Pectra - phụ thuộc.

1. Tăng mức phí blob tối thiểu cho phép khám phá giá nhanh hơn.
2. Tự động hóa phần trăm cập nhật gas blob làm cho nó bền vững hơn về tương lai.
3. Chuẩn hóa gas thừa ngăn chặn một khe gas nơi phí cơ bản blob giảm sau một fork tăng mục tiêu, mặc dù không có gì xấu có thể xảy ra nếu chúng ta không làm điều này.
4. Làm cho tỷ lệ phí cơ bản đối xứng đảm bảo cơ chế vẫn như cũ (tỷ lệ \pm 12.5%±12.5 ở các cực của 0 và 6 blob)

Tôi đề xuất tóm tắt tất cả những thay đổi này trong EIP-7762 và gửi chúng cùng nhau khi chúng ta thay đổi mục tiêu/tối đa từ 3/6 thành 4/6. Nếu chúng ta lo rằng Pectra có thể trở nên quá lớn khi thêm nhiều thay đổi khác, tôi đề xuất chúng theo thứ tự sau với độ quan trọng giảm dần:

1. Tăng số lượng blob.
   a) Làm 4/6, thận trọng, hoặc một cái gì đó như 6/9 nếu chúng ta cảm thấy tự tin hơn.
   b) Gửi EIP-7623 để đảm bảo kích thước tải trọng EL được giảm đáng kể để tạo thêm chỗ cho nhiều blob hơn.
2. Gửi các thay đổi phí cơ bản được mô tả.

Tóm tắt về Cơ chế Phí Blob

Với việc ra mắt EIP-4844, Ethereum đã thêm một chiều mới vào thị trường phí của mình. Blob, đi kèm với phí cơ bản riêng của chúng, cung cấp không gian chuyên dụng cho dữ liệu, cho phép các ứng dụng và rollups đăng thông tin trên chuỗi mà không cần thực thi EVM.
Cấu trúc phí blob được điều chỉnh bởi một quy tắc cập nhật phí cơ bản, xấp xỉ công thức:

base_fee_per_blob_gas = MIN_BASE_FEE_PER_BLOB_GAS * e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)

Trong phương trình này, excess_blob_gas đại diện cho tổng thặng dư sử dụng gas blob so với lượng mục tiêu (TARGET_BLOB_GAS_PER_BLOCK mỗi Block). Giống như cơ chế phí EIP-1559, công thức này tự điều chỉnh: khi lượng gas blob thừa tăng lên, base_fee_per_blob_gas sẽ tăng theo cấp số nhân, điều này làm giảm việc sử dụng quá mức và thúc đẩy lượng thừa trở về mức mà rollups coi là "giá hợp lý".

Quá trình hoạt động như sau: nếu Block N tiêu thụ X gas blob, thì trong Block N+1, excess_blob_gas tăng lên X - TARGET_BLOB_GAS_PER_BLOCK. Kết quả là, base_fee_per_blob_gas cho Block N+1 điều chỉnh theo hệ số e**((X - TARGET_BLOB_GAS_PER_BLOCK) / BLOB_BASE_FEE_UPDATE_FRACTION).

Tham số BLOB_BASE_FEE_UPDATE_FRACTION kiểm soát tốc độ thay đổi tối đa có thể xảy ra đối với phí cơ bản blob. Tỷ lệ này được đặt để đạt được mức tăng và giảm tối đa khoảng 1.125 mỗi Block, dựa trên e**(TARGET_BLOB_GAS_PER_BLOCK / BLOB_BASE_FEE_UPDATE_FRACTION).

Trong đợt triển khai ban đầu, các giá blob được dự kiến sẽ thấp, với những tăng dần cho đến khi thị trường tìm thấy một điểm cân bằng hoặc "giá hợp lý" (tức là khám phá giá). Thị trường phí blob được giới thiệu bởi EIP-4844 tuân theo cấu trúc tương tự như EIP-1559, với một phí cơ bản điều chỉnh động theo nhu cầu.

Đạt đến Điểm "Khám Phá Giá"

Tính đến tháng 11 năm 2024, Ethereum đã đạt đến mức độ nhu cầu mà rollups sẽ ngừng đăng blob bất kể phí cơ bản là bao nhiêu, mà thay vào đó đăng một lượng blob giữ cho phí cơ bản khá ổn định. Mọi người thích gọi đó là giai đoạn "khám phá giá", mặc dù nó chỉ có nghĩa là tại thời điểm cụ thể đó, một mức phí cơ bản X nhất định được coi là giá hợp lý. Tại thời điểm "khám phá giá", rollups sẽ không còn đăng 6 blob mỗi Block mà không xem xét phí blob cơ bản, vì nó không còn là không đáng kể nữa. Tuy nhiên, nhu cầu ngày càng tăng đối với blob mà không có nguồn cung tăng (tức là có nhiều blob hơn) sẽ dẫn đến phí blob cao hơn. Đối với những điều sau đây, xin lỗi khi sử dụng khái niệm đơn giản về "khám phá giá", mặc dù giá cả được khám phá mỗi 12 giây với mỗi khe.

Các Điều Chỉnh Được Đề Xuất và Ưu/Nhược Điểm của Chúng

Nhìn về Fork Pectra sắp tới, có nhu cầu rõ ràng để mở rộng blob (từ 3/6 lên 4/6 hoặc, tinh vi hơn, 6/9), điều này có thể cần các điều chỉnh đối với thị trường phí blob.

Trong các phần sau, tôi sẽ nêu ra 4 thay đổi tiềm năng đối với thị trường phí blob và thảo luận về các lợi ích và thách thức liên quan đến mỗi thay đổi.

1. Điều chỉnh Phí Cơ Bản Tối Thiểu: Một trong những điều chỉnh đơn giản nhất là sửa đổi tham số MIN_BASE_FEE, như Max Resnick đề xuất.
2. Tự động Hóa Phần Trăm Cập Nhật Phí Cơ Bản Blob: Một thay đổi đơn giản để đảm bảo phần trăm cập nhật phí cơ bản blob thay đổi theo số lượng blob mục tiêu.
3. Chuẩn Hóa Gas Thừa: Một đề xuất khác từ Bert Kellerman và Gajinder đề xuất "chuẩn hóa" việc tính toán lượng gas sử dụng thừa.
4. Đối Xứng Hóa Các Cập Nhật Phí Cơ Bản: Một đề xuất để điều chỉnh công thức phí cơ bản.

1. Tăng MIN_BASE_FEE_PER_BLOB_GAS (EIP-7762)

Phí cơ bản blob bắt đầu từ 0 và sau đó tăng dần cho đến khi đạt đến điểm khám phá giá. Mỗi ~6 Block (với 6 blob) thì phí cơ bản sẽ tăng gấp đôi nhưng còn một chặng đường dài để đến mức giá hợp lý, chẳng hạn như 5 gwei. Cho đến khi đạt đến mức đó, giá có thể biến động rất nhiều và rollups thực sự nhận được "quá rẻ" DA.

Tóm tắt

Ưu điểm:

• Khám phá giá "nhanh hơn".
• Ít biến động hơn trong thời gian cung < cầu.

Nhược điểm:

• Cần phải chạm vào giao thức và chúng tôi thường không "tối ưu hóa nhỏ" những thứ không bị hỏng.
• Vì gas dư thừa được đặt lại, chúng ta phải trải qua một giai đoạn khám phá giá một lần nữa, mặc dù bắt đầu ở mức cao hơn, do đó làm ngắn thời gian đó.

Điều này có thể được đơn giản hóa thành "ossification so với tối ưu hóa" và, theo ý kiến của tôi, không có đúng hay sai, mặc dù cá nhân tôi nghĩ rằng KHÔNG chạm vào giao thức cũng có giá trị.

2. Tự động hóa phần cập nhật phí cơ sở blob

Thay đổi này rất đơn giản: Hiện tại, phần cập nhật được đặt thành 3338477, như được chỉ định trong EIP-4844. Người ta đến được với con số đó bằng cách làm \frac{target\_gas}{ln(1.125)}. Nếu bây giờ chúng ta thay thế con số được cứng hóa bằng điều này, chúng ta có thể đảm bảo rằng chúng ta duy trì được mức thay đổi mong muốn \pm 12.5%.

3. Chuẩn hóa gas dư thừa

Đây là một đề xuất nhằm tránh sự sụt giảm mạnh của phí cơ sở sau các fork tăng mục tiêu blob. Để tránh sự sụt giảm đột ngột của phí cơ sở ngay sau khi fork tăng mục tiêu blob, đề xuất này gợi ý điều chỉnh cách chúng ta tính toán gas dư thừa. Bình thường, phí cơ sở nên thay đổi một cách êm ả - chỉ tối đa 12,5% mỗi khe. Bằng cách chuẩn hóa gas dư thừa, chúng ta có thể đảm bảo phí cơ sở vẫn ổn định và không giảm mạnh vượt quá giới hạn dự kiến 12,5% khi mục tiêu tăng, giữ cho các điều chỉnh phí dễ dự đoán và từ từ. Nói một cách đơn giản, thay vì tích lũy gas dư thừa, chúng ta tích lũy gas dư thừa được chuẩn hóa. Theo cách này, số blob mục tiêu không quan trọng.

Tóm tắt

Ưu điểm

• Tránh sụt giảm phí cơ sở sau fork với mục tiêu tăng.
  • Tính dự đoán cao hơn cho người dùng blob

Nhược điểm

• Một "tối ưu hóa nhỏ" tiềm năng khác.

Đối xứng hóa các bản cập nhật phí cơ sở blob xung quanh mục tiêu

Với việc thay đổi mục tiêu sao cho target=\frac{max}{2} không còn đúng nữa, chúng ta thay đổi khoảng cách từ mục tiêu đến min/max. Ví dụ, chuyển sang mục tiêu blob là 4 và max là 6, có chỗ cho 2 blob lên và 4 blob xuống. Bây giờ, với nhiều chỗ hơn ở phía âm so với phía dương, phí cơ sở có thể di chuyển xuống nhanh hơn so với di chuyển lên. Một cách sửa đơn giản là như sau: Trước tiên, chúng ta xác định delta giữa gas đã sử dụng và mục tiêu (giống như chúng ta đang làm bây giờ). Sau đó, chúng ta áp dụng một hệ số tỷ lệ đơn giản là target/(max-target) cho phía có ít chỗ hơn (ví dụ: phía "lên" khi làm 4/6 mục tiêu/max). Hàm calc_excess_blob_gas sẽ trông như sau:

def tính toán khí thừa blob(tiêu đề cha: Tiêu đề) -> int:hệ số tỷ lệ = MỤC TIÊU_BLOB_GAS_PER_BLOCK / (TỐI ĐA_BLOB_GAS_PER_BLOCK - MỤC TIÊU_BLOB_GAS_PER_BLOCK)blob_gas_delta = tiêu đề cha.blob_gas_used - MỤC TIÊU_BLOB_GAS_PER_BLOCKif blob_gas_delta > 0:delta_tỷ lệ = blob_gas_delta * hệ số tỷ lệelse:delta_tỷ lệ = blob_gas_deltakhí thừa blob = max(0, tiêu đề cha.khí thừa blob + delta_tỷ lệ)return khí thừa blob

Tất nhiên, điều này chỉ hoạt động trong những trường hợp max-mục tiêu<mục tiêu

Để hiểu rõ hơn về các tác động của quá trình đối xứng này, hãy cùng xem qua một ví dụ đơn giản:

1. Hãy tưởng tượng chúng ta có ba khe:
   • Hai khe đầu tiên chứa 6 blob mỗi khe.
   • Khe cuối cùng chứa 0 blob.
2. Điều này dẫn đến tổng cộng 12 blob trên 3 khe.
3. Mục tiêu được đặt là 4 blob mỗi block, với tối đa 6 blob.

Điều chỉnh phí cơ bản đối xứng so với không đối xứng:

• Phí cơ bản đối xứng:

  • Phí cơ bản tăng khoảng 12,5% hai lần (cho hai khe 6 blob) và sau đó giảm 12,5% một lần (cho khe 0 blob).
  • Sau những điều chỉnh này, phí cơ bản kết thúc cao hơn so với giá trị ban đầu.

• Phí cơ bản không đối xứng:

  • Phí cơ bản không thay đổi sau chuỗi blob 6-6-0.

Ví dụ này làm nổi bật những lợi ích của điều chỉnh đối xứng:

• Chuỗi blob 6-6-0 đẩy chúng ta đến những cực đoan (sử dụng tối đa theo sau là không có), điều này không mong muốn.
• Lý tưởng là tải nên được phân bổ đều hơn trên ba khe (ví dụ: 4 blob trong mỗi block).
• Phí cơ bản đối xứng ngăn chặn hành vi cực đoan bằng cách "phạt" việc sử dụng không đều (6 blob thay vì 4) nhiều hơn với một phí cơ bản cao hơn, thúc đẩy một tải cân bằng hơn.
• Tất nhiên, người ta có thể cho rằng người dùng blob có thể không quan tâm đến việc đẩy phí cơ bản lên vì họ chỉ cần đăng blob vài lần trong mỗi epoch và do đó không quan tâm đến khe tiếp theo sau khi họ đăng 6 blob. Mặc dù vậy, lập luận này là ngắn hạn.

Tóm lược

Ưu điểm

• Đảm bảo "khám phá giá" diễn ra nhanh như hiện nay.
• Đảm bảo các "cực đoan" (0 và 6 blob) gây ra cùng một tỷ lệ tăng/giảm.

Nhược điểm

• Lại một "vi tối ưu hóa" khác và mọi thứ có thể ổn mà không cần làm điều này.
• Giới thiệu một số phụ thuộc vào đường đi. Ví dụ: nhảy giữa gas\_used= mục tiêu \pm 1\ blob khiến phí cơ bản tăng dần theo thời gian. Hành vi này có thể được khắc phục bằng cách tránh đăng nhiều blob hơn mục tiêu, điều này thậm chí có thể khuyến khích một chiến lược đăng cân bằng hơn.