**Original author** : @Web3 Mario

**Introduction** : Vitalik released the EIP-7706 proposal on May 13, 2024, proposing a supplementary solution to the existing Gas model, separating the gas calculation of calldata, and customizing a base fee pricing mechanism similar to Blob gas to further reduce the operating cost of L2. The related proposals need to be traced back to EIP-4844 proposed in February 2022, which is a long time ago. Therefore, I have consulted relevant materials and hope to make a summary of the latest Ethereum Gas mechanism for everyone to quickly understand.

## Currently supported Ethereum Gas models — EIP-1559 and EIP-4844

In the initial design, Ethereum used a simple auction mechanism to price transaction fees, which required users to actively bid for their own transactions, that is, to set the gas price. Usually, since the transaction fees paid by users will belong to miners, miners will decide the order of transaction packaging according to the principle of economic optimality and the bid price. Note that this is ignoring MEV. At that time, the core developers believed that this mechanism faced the following four problems:

The mismatch between the volatility of transaction fee levels and the consensus cost of transactions: For active blockchains, there is sufficient demand for transaction packaging, which means that blocks can be easily filled, but this often also means that the overall fee volatility is extremely large. For example, when the average Gas Price is 10 Gwei, the marginal cost of the network accepting another transaction in a block is 10 times that when the average Gas Price is 1 Gwei, which is unacceptable.

Unnecessary delays for users: Due to the hard gas limit per block, and the natural fluctuations in historical transaction volume, transactions often wait several blocks before being included, which is inefficient for the network as a whole; i.e. there is no relaxation mechanism that allows one block to be larger and the next to be smaller to accommodate the difference in demand block by block.

Inefficient pricing: The simple auction mechanism results in low efficiency in fair price discovery, which means it is difficult for users to give a reasonable price. This means that in many cases, users pay high fees.

A blockchain without block rewards will be unstable: When the block rewards brought by mining are cancelled and a pure fee model is adopted, it may cause a lot of instability, such as incentivizing the mining of sister blocks that steal transaction fees, opening up more powerful selfish mining attack vectors, etc.

Until the proposal and implementation of EIP-1559, the Gas model had its first iteration. EIP-1559 was proposed by Vitalik and other core developers on April 13, 2019, and was adopted in the London upgrade on August 5, 2021. This mechanism abandons the auction mechanism and adopts a dual pricing model of Base fee and Priority fee, in which the Base fee will be quantitatively calculated through an established mathematical model based on the relationship between the gas consumption generated in the parent block and 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 will be increased, and if it is less than the gas target, the base fee will be lowered. This can better reflect the supply and demand relationship and make the prediction of reasonable gas more accurate, so as to avoid sky-high Gas Prices caused by misoperation, because the calculation of the base fee is directly determined by the system rather than freely specified by the user. The specific code is as follows:

It can be seen that when parent_gas_used is greater than parent_gas_target, the base fee of the current block will be compared with the base fee of the previous block plus an offset value. The offset value is the maximum value of parent_base_fee multiplied by the offset of the total gas fee of the previous block relative to the gas target and the modulo of the gas target and a constant and 1. The logic is similar in the opposite case.

In addition, the Base fee will no longer be distributed to miners as a reward, but will be destroyed directly, so that the economic model of ETH is in a deflationary state, which is conducive to the stability of value. On the other hand, the Priority fee is equivalent to the reward given by users to miners, which can be priced freely, which to a certain extent allows the sorting algorithm of miners to be reused to a certain extent.

As time goes by to 2021, the development of Rollup is gradually getting better. We know that both OP Rollup and ZK Rollup mean that some proof data after L2 data compression needs to be uploaded to the chain through calldata to achieve data availability (Data Available) or directly handed over to the chain for verification. This makes these Rollup solutions face a large gas cost when maintaining the finality of L2, and these costs will eventually be passed on to users. Therefore, the cost of using most L2 protocols at that time was not as low as imagined.

At the same time, Ethereum is also facing the dilemma of block space competition. We know that each block has a Gas Limit, which means that the total Gas consumption of all transactions in the current block cannot exceed this value. According to the current Gas Limit of 30000000, there is a theoretical limit of 30,000,000 / 16 = 1,875,000 bytes, where 16 means that EVM needs to consume 16 units of Gas to process each calldata byte, which means that the maximum data size that a single block can carry is about 1.79 MB. The Rollup-related data generated by the L2 sorter is usually large in size, which causes competition with the transaction confirmation of other main chain users, resulting in a smaller amount of transactions that can be packaged in a single block, which in turn affects the TPS of the main chain.

In order to solve this dilemma, the core developers proposed the EIP-4844 proposal on February 5, 2022, and it was implemented after the Dencun upgrade in early Q2 2024. The proposal proposed a new transaction type, called Blob Transaction. Compared with the traditional type of Transaction, the core idea of Blob Transaction is to add a new data type, namely Blob data. Different from the calldata type, blob data cannot be accessed directly by EVM, but only its hash, also known as VersionedHash. In addition, there are two accompanying designs. First, compared with ordinary transactions, the GC cycle of blob transactions is shorter, thus ensuring that the block data is not too bloated. Second, blob data has a native Gas mechanism. The overall effect is similar to EIP-1559, but the natural exponential function is selected in the mathematical model to make it more stable when dealing with fluctuations in transaction scale, because the slope of the natural exponential function is also a natural exponential function. This means that no matter what state the network transaction scale is in at this time, when the transaction scale soars rapidly, the base fee of blob gas will react more fully, thereby effectively curbing transaction activity. At the same time, the function also has an important feature. When the horizontal axis is 0, the function value is 1.

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

Among them, MIN_BASE_FEE_PER_BLOB_GAS and BLOB_BASE_FEE_UPDATE_FRACTION are two constants, and excess_blob_gas is determined by the difference between the total blob gas consumption in the parent block and a TARGET_BLOB_GAS_PER_BLOCK constant. When the total blob gas consumption exceeds the target value, that is, the difference is positive, e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION) is greater than 1, then base_fee_per_blob_gas becomes larger, otherwise it becomes smaller.

In this way, some scenarios that only want to use Ethereums consensus capabilities to store certain large-scale data to ensure availability can be executed at a low cost without squeezing the transaction packaging capacity of the block. Taking the Rollup sorter as an example, the key information of L2 can be encapsulated into the blob data through blob transaction, and the logic of on-chain verification can be implemented through versionedHash through sophisticated design in EVM.

It should be noted that the current settings of TARGET_BLOB_GAS_PER_BLOCK and MAX_BLOB_GAS_PER_BLOCK impose a limit on the mainnet, namely a target of 3 blobs (0.375 MB) per block and a limit of 6 blobs (0.75 MB) per block. These initial limits are intended to minimize the strain on the network caused by this EIP, and are expected to increase in future upgrades as the network demonstrates reliability with larger blocks.

## Further refinement of the execution environment gas consumption model - EIP-7706

After clarifying the current Ethereum Gas model, lets take a look at the goals and implementation details of the EIP-7706 proposal. The proposal was proposed by Vitalik on May 13, 2024. Similar to Blob data, this proposal strips 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 of calldata is the same as the base fee for blob data in EIP-4844. Both use an exponential function and calculate the scaling ratio of the current base fee based on the deviation between the actual gas consumption value in the parent block and the target value.

It is worth noting that there is a new parameter design, LIMIT_TARGET_RATIOS=[2, 2, 4], where LIMIT_TARGET_RATIOS[0] represents the target ratio of the execution operation class Gas, LIMIT_TARGET_RATIOS[1] represents the target ratio of the Blob data class Gas, and LIMIT_TARGET_RATIOS[2] represents the target ratio of the calldata class Gas. This vector is used to calculate the gas target values corresponding to the three types of gas in the parent block. The calculation logic is as follows, that is, use LIMIT_TARGET_RATIOS to divide the gas limit:

The setting logic of gas_limits is as follows:

gas_limits[ 0 ] must follow the existing adjustment formula

gas_limits[ 1 ] must be equal to MAX_BLOB_GAS_PER_BLOCK

gas_limits[ 2 ] must be equal to gas_limits[ 0 ] // CALLDATA_GAS_LIMIT_RATIO

We know that the current gas_limits[ 0 ] is 30000000, and CALLDATA_GAS_LIMIT_RATIO is preset to 4, which means that the current calldata gas target is about 30000000 // 4 // 4 = 1875000. According to the current calldata gas calculation logic, each non-zero Byte consumes 16 Gas and zero Byte consumes 4 Gas. Assuming that the distribution of non-zero and zero Bytes in a certain calldata is 50% each, it takes an average of 10 Gas to process 1 Byte of calldata. Therefore, the current calldata gas target should correspond to 187500 bytes of calldata data, which is about twice the current average usage.

The benefit of this is that it greatly reduces the probability of calldata reaching the gas limit, and through the economic model, the usage of calldata is kept at a relatively constant state, while also preventing the abuse of calldata. The reason for this design is to clear obstacles for the development of L2, and with blob data, the cost of the sorter is further reduced.