Author: @Web3Mario
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 requires 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 transaction packaging order according to the principle of economic optimality and the bid level. 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 cost is extremely volatile. For example, when the average Gas Price is 10 Gwei, the marginal cost to the network of accepting one more 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 limit of the gas limit per block, coupled with the natural fluctuations in historical transaction volume, transactions usually wait for several blocks before being packaged, but this is inefficient for the overall network; that is, there is no "relaxation" mechanism that allows one block to be larger and the next block to be smaller to meet the difference in demand block by block.
Inefficient pricing: Due to the low efficiency of fair price discovery caused by the simple auction mechanism, it will be difficult for users to give a reasonable price, which means that in many cases, users pay high fees.
Blockchains 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 instead adopts a dual pricing model of Base fee and Priority fee. The Base fee will be quantitatively calculated through an established mathematical model based on the relationship between the gas consumption already 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 not only better reflect the supply and demand relationship, but also 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. As for the offset value, it is the maximum value of the modulo 1 of the total gas fee of the previous block relative to the gas target and the gas target and a constant. The logic is similar in reverse.
In addition, the Base fee will no longer be allocated to miners as a reward, but will be directly destroyed, 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 on to 2021, the development of Rollup is gradually getting better. We know that both OP Rollup and ZK Rollup mean that some proof data of L2 needs to be compressed and uploaded to the chain through calldata to achieve data availability or directly handed over to the chain for verification. This makes these Rollup solutions face huge Gas costs 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 is 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 the early second quarter of 2024. The proposal proposes 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 can only access its hash, also known as VersionedHash. In addition, there are two accompanying designs. First, compared with ordinary transactions, the GC cycle of blob transaction is shorter, so as to ensure 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, so that it has better stability in dealing with fluctuations in transaction scale, because the slope of the natural exponential function is also a natural exponential function, which 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 respond more fully, thereby effectively curbing transaction activity. At the same time, the function 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)
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 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.
This allows some scenarios that only want to use Ethereum's consensus capabilities to store certain large-scale data to ensure availability to be executed at a low cost, without squeezing out the transaction packaging capabilities 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 added that the current settings of TARGET_BLOB_GAS_PER_BLOCK and MAX_BLOB_GAS_PER_BLOCK bring a limitation to the mainnet, that is, the average target of processing 3 blobs (0.375 MB) per block and the maximum limit of 6 blobs (0.75 MB). These initial limits are intended to minimize the pressure on the network caused by this EIP, and are expected to increase in future upgrades as the network demonstrates reliability under larger blocks.
Further refinement of the execution environment gas consumption model - 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 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 a new parameter design, LIMIT_TARGET_RATIOS=[2,2,4], where LIMIT_TARGET_RATIOS[0] represents the target ratio of the execution 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 advantage of doing 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 in a relatively constant state, while also preventing the abuse of calldata. The reason for making such a design is to clear obstacles for the development of L2, and with blob data, the cost of the sorter is further reduced.