Tác giả gốc: @Web3 Mario

Giới thiệu: Vào ngày 13 tháng 5 năm 2024, Vitalik đã đưa ra đề xuất EIP-7706, đề xuất một giải pháp bổ sung cho mô hình gas hiện có, tách biệt tính toán gas của calldata và tùy chỉnh cơ chế định giá phí cơ bản tương tự như Blob gas để Thả hơn nữa chi phí vận hành của L2. Đề xuất liên quan cũng cần được truy nguyên từ EIP-4844 được đề xuất vào tháng 2 năm 2022, tức là cách đây long thời gian, vì vậy hãy kiểm tra các tài liệu liên quan để cung cấp tổng quan về cơ chế Khí Ethereum mới nhất để bạn nhanh chóng hiểu được.

Các mô hình Ethereum Gas hiện đang được hỗ trợ - EIP-1559 và EIP-4844

Trong thiết kế ban đầu, Ethereum sử dụng cơ chế đấu giá đơn giản để định giá Rửa tiền, đòi hỏi người dùng phải chủ động đặt giá thầu cho các giao dịch của chính họ, tức là đặt giá gas, thông thường, vì phí giao dịch mà người dùng trả sẽ Quyền sở hữu hơn Người khai thác, vì vậy Người khai thác sẽ xác định lệnh đóng gói giao dịch theo nguyên tắc tối ưu kinh tế, theo mức đấu thầu, lưu ý đây là trường hợp bỏ qua MEV. Trong mắt các nhà phát triển cốt lõi vào thời điểm đó, cơ chế này phải đối mặt với bốn vấn đề sau:

• Biến động về mức độ Rửa tiền và chi phí đồng thuận của các giao dịch: Trong một Blockchain hoạt động, có đủ nhu cầu đóng gói giao dịch, có nghĩa là các khối có thể dễ dàng lấp đầy, nhưng điều này cũng thường có nghĩa là Biến động phí tổng thể là cực kỳ cao. Ví dụ: khi giá gas trung bình là 10 Gwei, chi phí cận biên của mạng để chấp nhận thêm một giao dịch trong một khối gấp 10 lần so với giá gas trung bình của 1 Gwei, điều này không thể chấp nhận được.
• Những Trễ không cần thiết cho người dùng: Do giới hạn gas cứng của mỗi khối, cùng với sự biến động tự nhiên của khối lượng lịch sử, các giao dịch thường chờ đợi một số khối được đóng gói, nhưng điều này không hiệu quả cho toàn bộ mạng; Đó là, không có cơ chế "chùng xuống" nào cho phép một Khối lớn hơn và Khối tiếp theo nhỏ hơn để đáp ứng sự khác biệt về nhu cầu được Khối trên cơ sở từng trường hợp cụ thể.
• Định giá không hiệu quả: Việc sử dụng cơ chế đấu giá đơn giản dẫn đến việc phát hiện giá hợp lý không hiệu quả, có nghĩa là người dùng sẽ khó đưa ra mức giá hợp lý, điều đó có nghĩa là trong trường hợp rất long, người dùng phải trả phí cao.
• Blockchain miễn phí Khối phần thưởng sẽ không ổn định: Khi Khối phần thưởng do Khai thác mang lại bị loại bỏ và mô hình phí thuần túy được áp dụng, nó có thể dẫn đến sự bất ổn rất long, chẳng hạn như khuyến khích khai thác để ăn cắp Rửa tiền "khối chị em", mở khai thác ích kỷ Vectơ tấn công mạnh hơn, v.v.

Mãi đến khi EIP-1559 được đề xuất và triển khai, mới có một lần lặp lại đầu tiên của mô hình Gas, được đề xuất bởi các nhà phát triển cốt lõi như Vitalik vào ngày 13 tháng 4 năm 2019 và được thông qua trong bản nâng cấp London vào ngày 5 tháng 8 năm 2021, từ bỏ cơ chế đấu giá để ủng hộ mô hình định giá kép phí cơ bản và phí ưu tiên, trong đó phí cơ bản sẽ dựa trên gas đã được tạo ra trong Khối mẹ Mối quan hệ giữa tiêu dùng và mục tiêu gas nổi và đệ quy được tính toán định lượng thông qua một mô hình toán học đã được thiết lập và hiệu ứng trực quan là nếu việc sử dụng gas trong Khối trước vượt quá mục tiêu gas định trước, phí cơ bản sẽ tăng lên và nếu thấp hơn mục tiêu gas, phí cơ bản sẽ được hạ xuống, điều này không chỉ phản ánh tốt hơn mối quan hệ giữa cung và cầu mà còn làm cho dự đoán hợp lý gas chính xác hơn. Sẽ không có giá gas cao ngất trời do hoạt động sai, bởi vì việc tính phí cơ bản được xác định trực tiếp bởi hệ thống chứ không phải do người dùng tự do chỉ định. Mã cụ thể như sau:

Có thể thấy rằng khi cha mẹ \ gas \ _used lớn hơn cha mẹ \ gas \ _target, thì phí cơ bản của Khối hiện tại sẽ được so sánh với phí cơ sở của Khối trước cộng với giá trị bù đắp và giá trị bù đắp được lấy làm cha mẹ \ _base \ _fee nhân với phần bù của tổng mức sử dụng của Khối gas trước đó so với mục tiêu gas và giá trị tối đa của phần còn lại của 1 với mục tiêu gas và hằng số. Logic ngược lại cũng tương tự.

Ngoài ra, phí cơ bản sẽ không người theo lệnh long được phân phối cho các thợ mỏ như một phần thưởng, mà sẽ được đốt trực tiếp, do đó mô hình kinh tế của ETH ở trạng thái giảm phát, có lợi cho sự ổn định của giá trị. Mặt khác, phí Ưu tiên tương đương với tiền boa của người dùng cho Người khai thác và giá có thể được đặt tự do, điều này có thể cho phép Thuật toán phân loại của Người khai thác được tái sử dụng ở một mức độ nhất định.

Theo thời gian tiến tới năm 2021, khi sự phát triển của Rollup dần đi vào trạng thái tốt hơn, chúng tôi biết rằng cả OP Rollup và ZK Rollup đều có nghĩa là một số dữ liệu bằng chứng sau khi nén dữ liệu L2 cần được tải lên on-chain thông qua calldata để đạt được tính khả dụng của dữ liệu hoặc bàn giao trực tiếp cho on-chain để xác minh. Do đó, các giải pháp tổng hợp này phải đối mặt với chi phí gas đáng kể khi duy trì tính cuối cùng của L2 và các chi phí này cuối cùng được chuyển cho người dùng, vì vậy hầu hết chi phí sử dụng giao thức L2 không thấp như tưởng tượng.

Đồng thời, Ethereum cũng đang phải đối mặt với tình thế tiến thoái lưỡng nan về cạnh tranh giữa các Khối short, chúng tôi biết rằng có một giới hạn gas cho mỗi Khối, điều đó có nghĩa là tổng mức tiêu thụ gas của tất cả các giao dịch trong Khối hiện tại không thể vượt quá giá trị này, dựa trên giới hạn gas hiện tại là 3000000000, có giới hạn lý thuyết là 30.000.000 / 16 = 1.875.000 byte, trong đó 16 đề cập đến mức tiêu thụ 16 trên mỗi byte calldata được xử lý bởi EVM Điều này có nghĩa là long tối đa của một Khối có thể mang dữ liệu là khoảng 1,79 MB. Dữ liệu liên quan đến rollup được tạo bởi trình sắp xếp L2 thường có quy mô lớn, khiến nó cạnh tranh với các xác nhận giao dịch của người dùng Chuỗi chính khác, dẫn đến một khối lượng nhỏ hơn có thể được đóng gói trong một khối duy nhất, do đó ảnh hưởng đến TPS của Chuỗi chính.

Để giải quyết vấn đề nan giải này, các nhà phát triển cốt lõi đã đề xuất EIP-4844 vào ngày 5 tháng 2 năm 2022, được thực hiện sau khi nâng cấp Dencun vào đầu quý 2 năm 2024. Đề xuất đề xuất một loại giao dịch mới gọi là Giao dịch Blob, dựa trên kiểu dữ liệu mới, dữ liệu Blob, là kiểu dữ liệu mới, dữ liệu Blob, so với loại Giao dịch truyền thống. Không giống như kiểu calldata, dữ liệu blob không thể được truy cập trực tiếp bởi EVM, mà chỉ có Hàm băm của nó, còn được gọi là VersionedHash. Ngoài ra, có hai thiết kế đi kèm, một là so với các giao dịch thông thường, thời gian GC của giao dịch blob ngắn hơn, để đảm bảo rằng dữ liệu khối không quá cồng kềnh và thứ hai là dữ liệu blob có cơ chế gas gốc, thường thể hiện hiệu ứng tương tự như EIP-1559, nhưng chọn hàm mũ tự nhiên trong mô hình toán học, để nó có thể hoạt động ổn định tốt hơn khi xử lý biến động kích thước giao dịch, vì độ dốc của hàm mũ tự nhiên cũng là hàm mũ tự nhiên, Điều này có nghĩa là bất kể kích thước giao dịch mạng ở trạng thái nào tại thời điểm này, khi kích thước giao dịch tăng đột biến, phí cơ bản của blob gas phản ứng đầy đủ hơn, do đó hạn chế hiệu quả hoạt động giao dịch và chức năng cũng có một tính năng quan trọng, khi abscissa là 0, giá trị chức năng là 1.

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

trong đó MIN \ _BASE \ _FEE \ _PER \ _BLOB \ _GAS và BLOB \ _BASE \ _FEE \ _UPDATE \ _FRACTION là hai hằng số, trong khi dư thừa \ _blob gas được xác định bởi sự khác biệt giữa tổng số blob trong Khối gas mẹ và một hằng số TARGET \ _BLOB \ _GAS \ _PER \ _BLOCK, khi tổng số blob gas Khi mức tiêu thụ vượt quá giá trị mục tiêu, nghĩa là khi chênh lệch dương, e \ * \ * (dư thừa \ _blob \ gas / BLOB \ _BASE \ _FEE \ _UPDATE \ _FRACTION) lớn hơn 1, thì cơ sở \ _fee _per \ _blob gas trở nên lớn hơn và ngược lại trở nên nhỏ hơn.

Bằng cách này, đối với một số kịch bản chỉ muốn sử dụng khả năng đồng thuận của Ethereum để lưu trữ một số dữ liệu quy mô lớn để đảm bảo tính khả dụng, nó có thể được thực hiện với chi phí thấp mà không lấn át khả năng đóng gói giao dịch của khối. Lấy trình tự tổng hợp làm ví dụ, thông tin chính của L2 có thể được đóng gói thành dữ liệu blob thông qua giao dịch blob và logic xác minh on-chain có thể được thực hiện bằng cách sử dụng versionedHash thông qua thiết kế thông minh trong EVM.

Cần nói thêm rằng cài đặt TARGET \ _BLOB \ _GAS \ _PER \ _BLOCK và MAX \ _BLOB \ _GAS \ _PER \ _BLOCK giới hạn Mạng chính là 3 blob (0.375 MB) mỗi Khối và tối đa 6 blob (0.75 MB) mỗi long. Các giới hạn ban đầu này được thiết kế để giảm thiểu sự căng thẳng trên mạng từ EIP này và dự kiến sẽ tăng lên trong các nâng cấp trong tương lai khi mạng thể hiện độ tin cậy ở các khối lớn hơn.

Tinh chỉnh mô hình tiêu thụ gas cho môi trường thực thi - EIP-7706

Bây giờ mô hình Ethereum gas hiện tại đã được làm rõ, chúng ta hãy xem các mục tiêu và chi tiết thực hiện của đề xuất EIP-7706. Đề xuất được Vitalik trình bày vào ngày 13/5/2024. Tương tự như dữ liệu blob, đề xuất này loại bỏ mô hình gas cho một trường dữ liệu đặc biệt khác, đó là calldata. Và logic triển khai mã tương ứng đã được tối ưu hóa.

Về nguyên tắc, logic tính phí cơ sở của calldata giống như phí cơ sở cho dữ liệu blob trong EIP-4844, sử dụng hàm mũ và tính toán tỷ lệ phí cơ sở hiện tại dựa trên giá trị sai lệch của giá trị tiêu thụ gas thực tế trong khối mẹ so với giá trị mục tiêu.

Cần lưu ý một thiết kế tham số mới, LIMIT \ _TARGET \ _RATIOS = [ 2, 2, 4 ], trong đó LIMIT \ _TARGET \ _RATIOS [ 0 ] đại diện cho tỷ lệ mục tiêu của lớp hoạt động Gas, LIMIT \ _TARGET \ _RATIOS [ 1 ] đại diện cho tỷ lệ mục tiêu của lớp dữ liệu Blob Gas và LIMIT \ _TARGET \ _RATIOS [ 2 ] đại diện cho calldata Tỷ lệ mục tiêu của lớp Gas, vectơ này được sử dụng để tính gas giá trị mục tiêu tương ứng với ba lớp gas trong Khối mẹ và logic tính toán như sau, nghĩa là giới hạn gas chia hết cho LIMIT_TARGET_RATIOS tương ứng:

Logic của gas_limits như sau:

gas_limits[ 0 ] phải tuân theo công thức điều chỉnh hiện có

gas_limits[ 1 ] phải bằng MAX_BLOB_GAS_PER_BLOCK

gas_limits[ 2 ] phải bằng gas_limits[ 0 ] // CALLDATA_GAS_LIMIT_RATIO

Chúng ta biết rằng gas_limits[ 0 ] hiện tại là 30000000 và CALLDATA_GAS_LIMIT_RATIO được đặt trước thành 4, có nghĩa là mục tiêu gas calldata hiện tại là khoảng 3000000000 // 4 // 4 = 1875000 và vì theo logic tính toán gas calldata hiện tại, mỗi byte khác 0 tiêu thụ 16 gas và 0 byte tiêu thụ 4 gas. Giả sử rằng việc phân phối các byte khác không và không trong một phân đoạn calldata nhất định chiếm 50% mỗi byte, phải mất trung bình 10 gas để xử lý 1 byte calldata. Do đó, mục tiêu gas calldata hiện tại sẽ đối phó với 187500 byte dữ liệu calldata, gấp khoảng 2 lần mức sử dụng trung bình hiện tại.

Ưu điểm của việc này là xác suất calldata đến giới hạn gas giảm đáng kể và việc sử dụng calldata được giữ ở trạng thái nhất quán hơn thông qua mô hình kinh tế và việc lạm dụng calldata cũng được loại bỏ. Lý do cho thiết kế này là để dọn đường cho sự phát triển của L2 và với dữ liệu blob, chi phí trình tự được giảm hơn nữa.