Vitalik recently released the “EIP-7706” proposal, which provides a complementary solution to the existing Gas model. This article will further introduce the proposal and discuss the changes it will bring to Ethereum.
Background: Bitcoin Layer 2 and Ethereum Layer 2
On the 13th of this week, Vitalik released the EIP-7706 proposal, which proposes a complementary solution to the existing Gas model. Specifically, it separates the gas calculation for calldata and introduces a base fee pricing mechanism similar to Blob gas, thereby reducing the execution cost of Layer 2.
The relevant proposal can be traced back to EIP-4844, which was proposed in February 2022. Therefore, it is necessary to review the relevant information to provide a summary of the latest Ethereum Gas mechanism for a better understanding.
Current Ethereum Gas Models – EIP-1559 and EIP-4844
In the initial design, Ethereum adopted a simple auction mechanism to price transaction fees, which required users to actively bid for their transactions, i.e., set gas prices.
Usually, since the transaction fees paid by users belong to miners, miners determine the transaction packaging order based on the principle of economic optimality, according to the bidding order, disregarding the MEV (Miner Extractable Value) situation. However, the core developers believed that this mechanism faced four main problems:
1. Inconsistency between the volatility of transaction fees and the consensus cost of transactions: In an active blockchain where there is sufficient demand for transaction packaging, it means that blocks can be easily filled. However, this often results in high volatility of overall costs. For example, when the average gas price is 10 Gwei, the marginal cost of accepting an additional transaction in a block is 10 times higher than when the average gas price is 1 Gwei, which is unacceptable.
2. Unnecessary delays for users: Due to the hard limit of gas limit per block and the natural fluctuation of historical transaction volume, transactions usually have to wait for several blocks to be packaged. This is inefficient for the overall network, as there is no “relaxation” mechanism that allows one block to be larger while the next block is smaller to meet the difference in block-by-block demand.
3. Inefficiency in pricing: The use of a simple auction mechanism leads to lower efficiency in fair price discovery. This means that it is difficult for users to provide a reasonable pricing, resulting in many cases where users overpay for transaction fees.
4. Unstable blockchain without block rewards: When the block reward generated by mining is canceled and a pure transaction fee model is adopted, it may cause instability, such as incentivizing mining to steal transaction fees through “sibling blocks” or opening up more powerful selfish mining attack vectors.
Until the introduction 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 abandoned the auction mechanism and adopted a dual pricing model of Base fee and Priority fee.
The Base fee is calculated quantitatively based on the relationship between the gas consumption in the parent block and a floating and recursive gas target using a predefined mathematical model. Intuitively, if the gas usage in the previous block exceeds the predetermined gas target, the base fee will increase; if it falls below the gas target, the base fee will decrease. This approach allows for a better reflection of supply and demand and more accurate prediction of reasonable gas prices, avoiding exorbitant gas prices due to user operational errors. The calculation of the Base fee is determined directly by the system rather than being freely specified by users. The specific code is as follows:
[Image]
It can be seen that when parent_gas_used is greater than parent_gas_target, the base fee of the current block will be increased relative to the base fee of the previous block by an offset value. The offset value is calculated by multiplying parent_base_fee by the offset between the total gas usage of the previous block and the gas target, and taking the maximum of the remainder and 1 when divided by the gas target. The logic is similar in the reverse case.
In addition, the Base fee is no longer distributed as rewards to miners; instead, it is directly burned, which puts the economic model of ETH in a deflationary state, contributing to price stability. On the other hand, the Priority fee is equivalent to the tip given by users to miners and can be freely priced. This, to some extent, allows for the reuse of the miner sorting algorithm.
With the passage of time until 2021, the development of Rollups gradually entered a good phase. We know that both OP Rollup and ZK Rollup require compressing certain proof data of L2 and uploading it to the chain through calldata to achieve data availability or verification on-chain. This imposes a significant gas cost on these Rollup solutions when maintaining the finality of L2, and ultimately transfers these costs to users. Therefore, the cost of most L2 protocols at that time was not as low as imagined.
At the same time, Ethereum also faced 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. Calculated 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 fact that the EVM consumes 16 units of gas for each calldata byte, which means that the maximum data size that can be accommodated in a single block is about 1.79 MB. However, the Rollup sorters typically generate Rollup-related data with larger data sizes, which competes with the confirmation of transactions from other main chain users, reducing the transaction volume that can be packed in a single block and affecting the TPS (Transactions Per Second) of the main chain.
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 introduces a new transaction type called Blob Transaction, which, compared to the traditional Transaction type, supplements a new data type called Blob data. Unlike the calldata type, blob data cannot be directly accessed by the EVM; only its hash can be accessed, also known as VersionedHash.
In addition, two accompanying designs are introduced. Firstly, compared to regular transactions, Blob transactions have a shorter garbage collection (GC) period to ensure that block data does not become too bloated. Secondly, blob data has its own native gas mechanism, which presents a similar effect to EIP-1559 but chooses a natural exponential function in the mathematical model. This makes it more stable when dealing with fluctuating transaction volumes because the slope of the natural exponential function is also a natural exponential function. This means that regardless of the current state of the network’s transaction volume, when the transaction volume surges rapidly, the base fee of blob gas can respond more fully, effectively curbing transaction activity. Additionally, this function has an important characteristic where the 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)
Here, 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 (positive difference), 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 of scenarios where Ethereum’s consensus ability is used to store larger-scale data for availability assurance, while not occupying the transaction packaging capacity of blocks. Taking the Rollup sorter as an example, the critical information of L2 can be encapsulated in blob data through blob transactions, and with clever design in the EVM, verification on-chain can be achieved using versionedHash.
It should be noted that the current settings of TARGET_BLOB_GAS_PER_BLOCK and MAX_BLOB_GAS_PER_BLOCK bring a limitation to the mainnet, namely, the target of processing 3 blobs (0.375MB) per block and a maximum limit of 6 blobs (0.75MB) per block. These initial limitations aim to minimize the pressure imposed on the network by this EIP, and it is expected that they will be increased in future upgrades as the network demonstrates reliability under larger blocks.
Further Refinement of Gas Consumption Model in Execution Environment – EIP-7706
After clarifying the current Ethereum Gas model, let’s take a look at the goals and implementation details of the EIP-7706 proposal. The proposal was put forward by Vitalik on May 13, 2024. Similar to Blob data, the proposal separates the gas model corresponding to another specific 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 the base fee for blob data in EIP-4844. Both adopt 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.
[Image]
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 consumption for execution operations.
LIMIT_TARGET_RATIOS[1] represents the target ratio of gas consumption for Blob data.
LIMIT_TARGET_RATIOS[2] represents the target ratio of gas consumption for calldata.
This vector is used to calculate the gas target values for the three types of gas in the parent block. The calculation logic is as follows, dividing the gas limit by LIMIT_TARGET_RATIOS:
[Image]
Where gas_limits are set 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 30,000,000, and CALLDATA_GAS_LIMIT_RATIO is set to 4 by default. This means that the current calldata gas target is approximately 30000000//4//4=1875000, and because each non-zero byte consumes 16 Gas and each zero byte consumes 4 Gas according to the current calldata gas calculation logic, assuming a distribution of 50% non-zero and 50% zero bytes in a certain calldata segment, the average consumption of 1 byte of calldata is 10 Gas. Therefore, the current calldata gas target corresponds to a calldata data size of 187500 bytes, which is about twice the current average usage.
The benefit of this approach is that it greatly reduces the probability of calldata reaching the gas limit and keeps the calldata usage in a relatively consistent state through the economic model, while also preventing abuse of calldata. The reason for this design is to clear the obstacles for the development of L2 and further reduce the cost in conjunction with blob data.
[Image]
Related Reports:
– Explanation: Why did the Gas fees for Ethereum L2 network Starknet drop by 99% after the Cancun upgrade?
– Gas fees reduced by 90%! Vitalik: Scalability has been achieved, what’s next after Dencun? Verkle Trees and expiration of historical data.
– Cancun upgrade completed: Did the Gas fees for Ethereum L2 really decrease? ARB, OP, STRK… How did the token prices perform?