Vitalik has released the EIP-7706 proposal this week, which provides a supplementary solution to the existing Gas model. This article will further introduce the proposal and explore the changes it will bring to Ethereum.
Background:
Deep Dive: What can we learn from Ethereum L2 in the next step of Bitcoin Layer2 Narrative?
Vitalik released the EIP-7706 proposal on the 13th of this week, proposing a supplementary solution to the existing Gas model. The proposal separates the calculation of gas for calldata and customizes a base fee pricing mechanism similar to Blob gas, further reducing the execution cost of L2.
The related proposal can be traced back to EIP-4844 proposed in February 2022, which is quite a long time ago. Therefore, it is necessary to review the relevant information to provide a summary of the latest Ethereum Gas mechanism for a better 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, which required users to actively bid for their own transactions, i.e., set gas prices.
Usually, since the transaction fees paid by users will be attributed to miners, miners will determine the transaction packing order based on the principle of economic optimality, according to the order of bids, ignoring the MEV situation. At that time, the core developers believed that this mechanism faced four problems:
1. Inconsistency between the volatility of transaction fee levels and the consensus cost of transactions: For an active blockchain, where there is sufficient demand for transaction packing, it means that blocks can be easily filled. However, this often means high volatility in overall costs. For example, when the average Gas Price is 10 Gwei, the marginal cost of accepting an additional transaction in a block on the network 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 gaslimit for each block, combined with the natural fluctuations in historical transaction volume, transactions usually have to wait for several blocks to be packed, 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 demand difference between each block.
3. Inefficient pricing: The adoption of a simple auction mechanism leads to lower efficiency in fair price discovery, which means that it is difficult for users to give a reasonable pricing, and this also means that in many cases, users pay higher transaction fees.
4. The blockchain without block rewards will become unstable: When the block reward from mining is canceled and a simple transaction fee model is adopted, it may cause various instabilities, such as incentivizing the mining of “sister blocks” that steal transaction fees or opening up more powerful selfish mining attack vectors.
Until the proposal and implementation of EIP-1559, there was a first iteration of the Gas model. 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 quantitatively calculated 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, and if it falls below the gas target, the base fee will decrease. This can better reflect the supply-demand relationship and make predictions of reasonable gas more accurate, avoiding exorbitant Gas Prices caused by operational errors, as the calculation of the base fee is determined directly by the system rather than freely specified by users. The specific code is as follows:
[img]
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 obtained 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 value of the remainder with gas target and a constant. The logic is similar in the opposite case.
In addition, the Base fee is no longer allocated as a reward to miners but is directly burned. This puts the economic model of ETH in a deflationary state, which is beneficial to price stability. On the other hand, the Priority fee is equivalent to the tip given by the user to the miner and can be freely priced. This to some extent allows for the reuse of the miner’s sorting algorithm.
As time progressed to 2021, the development of Rollups gradually entered a good phase. We know that both OP Rollup and ZK Rollup mean that certain compressed proof data of L2 needs to be uploaded to the chain through calldata to achieve data availability or be verified directly by the chain. This places a significant gas cost burden on these Rollup solutions when maintaining the finality of L2, which is ultimately passed on to the users. Therefore, at that time, the cost of most L2 protocols 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, theoretically, there is a limitation of 30,000,000/16 = 1,875,000 bytes, where 16 refers to the fact that each calldata byte processed by the EVM consumes 16 units of gas, which means that the maximum data size that a single block can accommodate is approximately 1.79 MB. The Rollup sorter’s related data generated by L2 is usually larger in scale, which leads to competition with other main chain users’ transaction confirmations, reducing the number of transactions that can be packed in a single block and affecting the TPS 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 the beginning of the second quarter of 2024. The proposal introduces a new transaction type called Blob Transaction, which supplements a new data type called Blob data compared to traditional Transaction types. Unlike calldata types, blob data cannot be directly accessed by the EVM and can only be accessed through its hash, also known as VersionedHash.
In addition, there are two accompanying designs. Firstly, compared to regular transactions, the GC period of blob transactions is shorter, ensuring that block data is not excessively bloated. Secondly, blob data has a native gas mechanism, which presents a similar overall effect to EIP-1559 but chooses a natural exponential function in the mathematical model, making it more stable in dealing with fluctuations in transaction volume. Because the slope of the natural exponential function is also a natural exponential function, it means that no matter what state the network transaction volume is in at this time, when the transaction volume rises rapidly, the base fee of blob gas can respond more fully, effectively curbing transaction activity. At the same time, 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)
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 the 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 of scenarios where some larger-scale data is stored on Ethereum for proof of availability using the consensus capability of Ethereum. At the same time, it avoids crowding out the transaction packing capacity of blocks. Taking the Rollup sorter as an example, L2’s critical information can be encapsulated into blob data through blob transactions, and through clever design in the EVM, verification logic can be achieved using versionedHash.
[img]
It should be noted that the current settings of TARGET_BLOB_GAS_PER_BLOCK and MAX_BLOB_GAS_PER_BLOCK have imposed a limitation on the mainnet, which means that the average processing of 3 blobs (0.375MB) per block is the target, and there is a maximum of 6 blobs (0.75MB) limit. These initial limitations aim to minimize the pressure on the network caused by this EIP and are expected to be increased in future upgrades as the network demonstrates reliability under larger blocks.
Further refining the Gas consumption model for the 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, this proposal separates the Gas model corresponding to another specific data field, which is calldata. It also optimizes the corresponding code implementation logic.
In principle, the base fee calculation logic for calldata is the same as that for base fee for blob data in EIP-4844. They both use an exponential function to calculate the scaling factor of the current base fee based on the deviation between the actual gas consumption in the parent block and the target value.
[img]
It is worth noting a new parameter design, LIMIT_TARGET_RATIOS=[2,2,4], where:
LIMIT_TARGET_RATIOS[0] indicates the target ratio of Gas for executing operation types.
LIMIT_TARGET_RATIOS[1] indicates the target ratio of Gas for Blob data.
LIMIT_TARGET_RATIOS[2] indicates 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 by dividing the gas limit by the LIMIT_TARGET_RATIOS. The calculation logic is as follows:
[img]
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. Furthermore, based on 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 certain segment of calldata is 50% each, the average processing of 1 byte of calldata would require 10 Gas. Therefore, the current calldata gas target corresponds to approximately 187500 bytes of calldata, which is twice the current average usage.
The benefit of this design is that it greatly reduces the probability of calldata reaching the gas limit, keeps the calldata usage in a relatively consistent state through the economic model, and also eliminates abuse of calldata. The reason for this design is to smooth the way for L2 development and further reduce the cost with the help of blob data.
[img]
Related reports:
Explanation: Why did the Gas fee for Starknet on Ethereum L2 drop by 99% after the Cancun upgrade?
Gas fee reduced by 90%! V God: Scalability has been achieved, what’s next after Dencun is Verkle Trees and expiration of historical data.
Cancun upgrade completed: Did the Gas fee for Ethereum L2 really decrease significantly? ARB, OP, STRK… How is the price performance?