Detail EIP-7706 and sort out the latest Ethereum Gas mechanism

Author:++@Web3Mario++

Introduction: On May 13, 2024, Vitalik released the EIP-7706 proposal, which provides a supplementary solution to the existing Gas model by separating the gas calculation for calldata and customizing a base fee pricing mechanism similar to Blob gas, further reducing the operating costs of L2. Related proposals can be traced back to EIP-4844 proposed in February 2022, which is quite some time ago. Therefore, I reviewed relevant materials to provide an overview of the latest Ethereum Gas mechanism for everyone's quick understanding.

Currently Supported Ethereum Gas Models ------ EIP-1559 and EIP-4844

In the initial design, Ethereum adopted a simple auction mechanism for pricing transaction fees, requiring users to actively bid for their transactions by setting the gas price. Generally, since the transaction fees paid by users would go to miners, miners would decide the order of transaction packaging based on economic optimization principles, according to the bid amounts, ignoring MEV. At that time, core developers believed this mechanism faced the following four issues:

• Volatility of transaction fee levels and mismatch with transaction consensus costs: In an active blockchain, there is sufficient demand for transaction packaging, meaning blocks can be easily filled, but this often leads to significant overall fee volatility. For example, when the average Gas Price is 10 Gwei, the marginal cost incurred by the network for accepting another transaction in a block is 10 times that of an average Gas Price of 1 Gwei, which is unacceptable.
• Unnecessary delays for users: Due to the hard limit on gas per block and the natural fluctuations in historical transaction volume, transactions often wait several blocks to be packaged, which is inefficient for the overall network; there is no "relaxation" mechanism that allows one block to be larger while the next is smaller to meet the differing demands of individual blocks.
• Inefficient pricing: The simple auction mechanism leads to low efficiency in fair price discovery, making it difficult for users to provide a reasonable price, which means that in many cases, users end up paying high fees.
• Blockless blockchains will be unstable: When block rewards from mining are eliminated and a pure fee model is adopted, it may lead to many instabilities, such as incentivizing the mining of "sister blocks" that steal transaction fees, opening up stronger vectors for selfish mining attacks, etc.

It wasn't until the proposal and implementation of EIP-1559 that the Gas model underwent its first iteration. EIP-1559 was proposed by Vitalik and other core developers on April 13, 2019, and adopted in the London upgrade on August 5, 2021. This mechanism abandoned the auction model in favor of a dual pricing model consisting of a Base fee and a Priority fee. The Base fee is quantitatively calculated based on a predetermined mathematical model that relates the gas consumption in the parent block to a floating and recursive gas target. The intuitive effect is that if the gas usage in the previous block exceeds the predetermined gas target, the base fee is increased; if it is below the gas target, the base fee is decreased. This approach better reflects the supply-demand relationship and makes predictions for reasonable gas more accurate, preventing exorbitant Gas Prices due to misoperations, as the calculation of the base fee is directly determined by the system rather than freely specified by users. The specific code is as follows:

It can be seen that when parentgasused is greater than parentgastarget, the current block's base fee will be the previous block's base fee plus an offset value, where the offset value is calculated by taking parentbasefee multiplied by the offset of the total gas usage of the previous block relative to the gas target and taking the maximum of the remainder of gas target and a constant with 1. The reverse logic is similar.

Additionally, the Base fee will no longer be distributed as rewards to miners but will be directly burned, resulting in ETH's economic model being in a deflationary state, which is beneficial for value stability. On the other hand, the Priority fee acts as a tip from users to miners, which can be freely priced, allowing some degree of reuse in miners' sorting algorithms.

As time progressed to 2021, the development of Rollups gradually entered a favorable phase. We know that whether OP Rollup or ZK Rollup requires compressing certain proof data of L2 and uploading it to the chain via calldata to achieve data availability or directly verifying it on-chain. This places a significant gas cost on these Rollup solutions when maintaining the finality of L2, and these costs will ultimately be passed on to users. Therefore, at that time, the cost of most L2 protocols was not as low as imagined.

At the same time, Ethereum faced the dilemma of block space competition. We know that each block has a Gas Limit, meaning the total gas consumption of all transactions in the current block cannot exceed this value. With the current Gas Limit set at 30,000,000, there is theoretically a limit of 30,000,000 / 16 = 1,875,000 bytes, where 16 refers to the gas consumed by the EVM for each calldata byte. This means a single block can carry a maximum data size of about 1.79 MB. The Rollup-related data generated by L2 sorters is usually large, which causes competition for transaction confirmations with other main chain users, leading to a smaller number of transactions that can be packaged in a single block, thereby affecting the TPS of the main chain.

To address this dilemma, core developers proposed the EIP-4844 proposal on February 5, 2022, which was implemented after the Dencun upgrade in early Q2 2024. This proposal introduced a new transaction type called Blob Transaction. Compared to traditional Transaction types, the core idea of Blob Transaction is to supplement a new data type, namely Blob data. Unlike calldata types, blob data cannot be directly accessed by the EVM but can only access its hash, also known as VersionedHash. Additionally, there are two accompanying designs: first, compared to ordinary transactions, blob transactions have a shorter GC cycle, ensuring that block data does not become overly bloated; second, blob data has a native gas mechanism, which overall presents effects similar to EIP-1559, but chooses a natural exponential function in its mathematical model, making it perform better in stability when responding to fluctuations in transaction volume. This is because the slope of the natural exponential function is also a natural exponential function, meaning that regardless of the current state of network transaction volume, when transaction volume surges rapidly, the blob gas's base fee responds more fully, effectively curbing transaction activity. Additionally, this function has an important characteristic: when the x-coordinate is 0, the function value is 1.

basefeeperblobgas = MINBASEFEEPERBLOBGAS * e**(excessblobgas / BLOBBASEFEEUPDATE_FRACTION)

Where MINBASEFEEPERBLOBGAS and BLOBBASEFEEUPDATEFRACTION are two constants, and excessblobgas is determined by the difference between the total blob gas consumption in the parent block and a constant TARGETBLOBGASPERBLOCK. When the total blob gas consumption exceeds the target value, i.e., the difference is positive, e**(excessblobgas / BLOBBASEFEEUPDATEFRACTION) is greater than 1, then basefeeperblob_gas increases; otherwise, it decreases.

This allows for low-cost execution in scenarios where some users only wish to utilize Ethereum's consensus capabilities for certain large-scale data to ensure availability, without occupying the transaction packaging capacity of the block. For example, Rollup sorters can encapsulate key information of L2 into blob data through blob transactions and, through clever design in the EVM, utilize versionedHash to implement on-chain verification logic.

It should be noted that the current settings for TARGETBLOBGASPERBLOCK and MAXBLOBGASPERBLOCK impose a limitation on the mainnet, specifically a target of processing an average of 3 blobs (0.375 MB) per block and a maximum limit of 6 blobs (0.75 MB). These initial limits are designed to minimize the pressure this EIP places on the network, and as the network demonstrates reliability under larger blocks, it is expected that these limits will be increased in future upgrades.

Refinement of the Gas Consumption Model for Execution Environment ------ EIP-7706

After clarifying the current Ethereum Gas model, let's look at the goals and implementation details of the EIP-7706 proposal. This proposal was put forward by Vitalik on May 13, 2024. Similar to Blob data, this proposal separates the gas model corresponding to another special data field, which is calldata, and optimizes the corresponding code implementation logic.

In principle, the base fee calculation logic for calldata is the same as that for blob data in EIP-4844, both using an exponential function and calculating the scaling factor for the current base fee based on the deviation between the actual gas consumption in the parent block and the target value.

Notably, a new parameter design, LIMITTARGETRATIOS = [2, 2, 4], where LIMITTARGETRATIOS[0] represents the target ratio for execution operation gas, LIMITTARGETRATIOS[1] represents the target ratio for Blob data gas, and LIMITTARGETRATIOS[2] represents the target ratio for calldata gas. This vector is used to calculate the gas target values corresponding to the three types of gas in the parent block, with the calculation logic as follows, using LIMITTARGETRATIOS for integer division of gas limit:

The setting logic for gas_limits is as follows:

gas_limits[0] must follow the existing adjustment formula

gaslimits[1] must equal MAXBLOBGASPER_BLOCK

gaslimits[2] must equal gaslimits[0] // CALLDATAGASLIMIT_RATIO

We know that the current gaslimits[0] is 30,000,000, and CALLDATAGASLIMITRATIO is preset to 4, which means the current calldata gas target is approximately 30,000,000 // 4 // 4 = 1,875,000. Additionally, according to the current calldata gas calculation logic, each non-zero byte consumes 16 Gas, and zero bytes consume 4 Gas. Assuming a distribution of 50% non-zero and zero bytes in a segment of calldata, the average processing of 1 byte of calldata requires 10 Gas. Therefore, the current calldata gas target should correspond to approximately 187,500 bytes of calldata, about twice the current average usage.

The benefit of this design is that it greatly reduces the probability of calldata reaching the gas limit, maintaining calldata usage at a relatively stable state through the economic model, while also preventing abuse of calldata. The reason for this design is to clear obstacles for the development of L2, in conjunction with blob data, further reducing the costs for sorters.