Introduction: On May 13, 2024, Vitalik proposed EIP-7706, which supplements the existing Gas model by separately removing the gas calculation for calldata and customizing a base fee pricing mechanism similar to Blob gas, further reducing the operating costs of Layer 2. Related proposals also need to be traced back to EIP-4844 proposed in February 2022, which is a long time apart. Therefore, checking related materials, we hope to provide a summary of the latest Ethereum Gas mechanism to facilitate everyone’s quick understanding.

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

In the initial design, Ethereum adopted a simple auction mechanism to price transaction fees, requiring users to actively bid for their transactions, i.e., setting gas prices. Typically, because the transaction fees paid by users go to miners, miners decide the transaction packaging order based on the principle of economic optimality, according to the bidding price, ignoring the situation of MEV. In the view of the core developers at that time, this mechanism faced four problems:

Fluctuation of transaction fee levels does not match the consensus cost of transactions: For blockchains in an active state, there is sufficient demand for transaction packaging, which means that blocks can be easily filled, but this often leads to significant fluctuations in overall fees. 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 ten times higher than when the average Gas Price is 1 Gwei, which is unacceptable.

Unnecessary delays for users: Due to the hard limit of gaslimit for each block, coupled with the natural fluctuation of historical transaction volumes, transactions often have to wait for several blocks to be packaged, which is inefficient for the overall network. There is no “relaxation” mechanism that allows one block to be larger and the next block to be smaller to meet the differences in demand between blocks.

Inefficient pricing: The adoption of a simple auction mechanism has led to low efficiency in fair price discovery, which means that it is difficult for users to give a reasonable price, resulting in many cases where users pay excessive fees.

Blockchain without block rewards will be unstable: When canceling block rewards brought about by mining and adopting a pure fee model, it may lead to many instabilities, such as incentivizing mining “sister blocks” to steal transaction fees, opening up more powerful selfish mining attack vectors, etc.

Until the proposal and implementation of EIP-1559, there was a first iteration of the Gas model. EIP-1559, proposed by Vitalik and other core developers on April 13, 2019, was adopted in the London upgrade on August 5, 2021. This mechanism abandons the auction mechanism and instead adopts a dual pricing model of Base fee and Priority fee. The Base fee is quantitatively calculated based on the relationship between the gas consumption in the parent block and a floating and recursive gas target through an established mathematical model. The intuitive effect is that if the gas usage in the previous block exceeds the predetermined gas target, the base fee is increased, and if it is below the gas target, the base fee is decreased. This can better reflect supply and demand and make predictions for reasonable gas more accurate, preventing exorbitant Gas Prices due to misoperations because 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 inferred that when parent_gas_used is greater than parent_gas_target, the base fee of the current block will be compared to the base fee of the previous block plus an offset value. As for the offset value, it is calculated by multiplying parent_base_fee by the offset of the total gas usage of the previous block relative to the gas target and taking the modulus with gas target and a constant, then taking the maximum value of the result and 1. The logic is similar in reverse.

Additionally, the Base fee will no longer be allocated as a reward to miners but will be directly burned, thereby putting the Ethereum economic model in a deflationary state, which is conducive to value stability. On the other hand, the Priority fee is akin to a tip given by users to miners and can be priced freely, which to some extent can allow the miner sequencing algorithm to be reused.

As time progressed into 2021, the development of Rollups gradually reached its peak. We know that whether it’s OP Rollups or ZK Rollups, it implies the need to upload certain proof data of compressed L2 data to the chain via calldata to achieve Data Availability on-chain, or to be directly verified on-chain. This imposes significant gas costs on maintaining the finality of L2, which are ultimately passed on to users. Therefore, the cost of using most L2 protocols was not as low as imagined at that time.

At the same time, Ethereum also faced the dilemma of block space competition. We know that each block has a Gas Limit, meaning that the total gas consumption of all transactions in the current block cannot exceed this value. Calculating based on the current Gas Limit of 30,000,000, there is theoretically a limit of 1,875,000 bytes, where 16 refers to the gas consumed per calldata byte processed by the EVM. This implies that the maximum data size that can be accommodated in a single block is approximately 1.79 MB. However, the Rollup-related data generated by L2 sequencers typically have a larger data size, which competes with the confirmation of transactions by other main chain users, resulting in a decrease in the number of transactions that can be packed into a single block, thereby affecting the TPS of the main chain.

To address this dilemma, core developers proposed EIP-4844 on February 5, 2022, which was implemented after the Dencun upgrade in the second quarter of 2024. This proposal introduces a new transaction type called Blob Transaction. In contrast to traditional Transaction types, the core idea of Blob Transaction supplements a new data type, namely Blob data. Unlike calldata types, blob data cannot be accessed directly by the EVM but can only access its hash, also known as VersionedHash. Additionally, two accompanying designs are introduced. Firstly, compared to regular transactions, the GC cycle of blob transactions is shorter, ensuring that block data does not become too bloated. Secondly, blob data has a native Gas mechanism. Overall, the effect presented is similar to EIP-1559, but the mathematical model selects a natural exponential function, which performs better in stability when dealing with 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 state of the network’s transaction volume, when the transaction volume rapidly increases, the base fee of blob gas reflects more fully, effectively curbing transaction activity. Additionally, this function has an important characteristic where the function value is 1 when the abscissa is 0.

base_fee_per_blob_gas = MIN_BASE_FEE_PER_BLOB_GAS e*(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)

Where 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 constant TARGET_BLOB_GAS_PER_BLOCK. When the total blob gas consumption exceeds the target value, i.e., the difference is positive, e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION) is greater than 1, and base_fee_per_blob_gas increases, otherwise it decreases.

This allows for low-cost execution in scenarios where only the consensus capability of Ethereum is desired to store large-scale data to ensure availability, without monopolizing the block’s transaction packing capacity. Taking the Rollup sequencer as an example, critical information of L2 can be encapsulated into blob data through blob transactions, and the logic for on-chain verification can be implemented in the EVM through sophisticated designs using versionedHash.

It should be noted that the current setting of TARGET_BLOB_GAS_PER_BLOCK and MAX_BLOB_GAS_PER_BLOCK imposes a limitation on the mainnet, namely a target of processing an average of 3 blobs (0.375 MB) per block and a maximum limit of 6 blobs (0.75 MB) per block. These initial limits are aimed at minimizing the pressure EIP places on the network, and are expected to be increased in future upgrades as the network demonstrates reliability under larger blocks.

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

After clarifying the current Gas model of Ethereum, let’s take a look at the goals and implementation details of EIP-7706 proposal. This proposal was introduced by Vitalik on May 13, 2024. Similar to Blob data, this proposal separates the Gas model for another special data field, namely calldata, and optimizes the corresponding code implementation logic.

In principle, the base fee calculation logic for calldata is the same as the base fee for blob data in EIP-4844, both of which use an exponential function to calculate the scaling factor for 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 a new parameter design, LIMIT_TARGET_RATIOS=[2,2,4], where LIMIT_TARGET_RATIOS[0] represents the target ratio of Gas for execution operations, LIMIT_TARGET_RATIOS[1] represents the target ratio of Gas for Blob data, and LIMIT_TARGET_RATIOS[2] represents the target ratio of Gas for calldata. This vector is used to calculate the gas target values for the three types of gas in the parent block, using the LIMIT_TARGET_RATIOS for integer division on the gas limit as follows:

The setting logic for 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. This means that the current calldata gas target is approximately 30000000 // 4 // 4 = 1875000. Since, according to the current calldata gas calculation logic, each non-zero byte consumes 16 Gas and zero bytes consume 4 Gas, assuming that the distribution of non-zero and zero bytes in a segment of calldata is 50%, the average processing of 1 byte of calldata requires 10 Gas. Therefore, the current calldata gas target should correspond to calldata data of 187500 bytes, approximately twice the current average usage.

The benefit of this approach is to greatly reduce the probability of calldata reaching the gas limit, maintaining calldata usage at a relatively consistent level through the economic model, and preventing abuse of calldata. The reason for this design is to pave the way for the development of L2, coupled with blob data, to further reduce the cost of the sequencer.

Disclaimer：

1. This article is reprinted from [TechFlow]. All copyrights belong to the original author [Web3Mario]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.