Detail EIP-7706 and sort out the latest Ethereum Gas mechanics

Original Author: @Web3 Mario

Introduction: On May 13, 2024, Vitalik released the EIP-7706 proposal, proposing a complementary solution to the existing gas model, separating the gas computation of calldata, and customizing a base fee pricing mechanism similar to Blob gas to further drop the running cost of L2. The related proposal also needs to be traced back to EIP-4844 proposed in February 2022, which is a long time ago, so check out the relevant materials to provide an overview of the latest Ethereum Gas mechanism for you to quickly understand.

The currently supported Ethereum Gas models - EIP-1559 and EIP-4844

In the original design, Ethereum uses a simple auction mechanism to price Money Laundering, which requires users to actively bid for their own transactions, that is, to set a gas price, normally, because the transaction fee paid by users will be vesting than Miner, so the Miner will determine the order of transaction packaging according to the principle of economic optimality, according to the bidding level, note that this is in the case of ignoring MEV. In the eyes of the core developers at the time, this mechanism faced the following four problems:

• Fluctuation in the level of Money Laundering and the consensus cost of transactions: In an active Blockchain, there is sufficient demand for transaction packaging, which means that blocks can be easily filled, but this often also means that the overall fee Fluctuation is extremely high. For example, when the average gas price is 10 Gwei, the marginal cost of the network to accept one more transaction in a block is 10 times that of the average gas price of 1 Gwei, which is unacceptable.
• Unnecessary latency for users: Due to the hard gas limit of each block, coupled with the natural fluctuation of historical volume, transactions usually wait for several blocks to be packaged, but this is inefficient for the overall network; That is, there is no “slack” mechanism that allows one Block to be larger and the next Block smaller to meet the differences in needs that are Block on a case-by-case basis.
• Inefficient pricing: The use of a simple auction mechanism leads to inefficient fair price discovery, which means that it will be difficult for users to give a reasonable price, which means that in very long cases, users pay high fees.
• Block Reward-free Blockchain will be unstable: When the Block Reward brought by Mining is removed and a pure fee model is adopted, it can lead to very long instability, such as incentivizing mining to steal Money Laundering “sister blocks”, opening more powerful selfish mining Attack Vector, etc.

It wasn’t until EIP-1559 was proposed and implemented that there was a first iteration of the Gas model, which was proposed by core developers such as Vitalik on April 13, 2019, and adopted in the London upgrade on August 5, 2021, which abandoned the auction mechanism in favor of a dual pricing model of base fee and priority fee, where the base fee would be based on the gas already generated in the parent Block The relationship between consumption and a floating and recursive gas target is quantitatively calculated through an established mathematical model, and the intuitive effect is that if the usage of gas 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, which can not only better reflect the relationship between supply and demand, but also make the prediction of reasonable gas more accurate. There will be no sky-high gas price due to misoperation, because the calculation of 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, then the base fee of the current Block will be compared with the base fee of the previous Block plus an offset value, and the offset value is taken as parent_base_fee multiplied by the offset of the total usage of the previous Block gas relative to gas target, and the maximum value of the remainder of 1 with gas target and a constant. The reverse logic is similar.

In addition, the base fee will no longer be distributed to Miners as a reward, but will be burned 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, Priority fee is equivalent to the user’s tip to the Miner, and the price can be set freely, which can allow the sorting Algorithm of the Miner to be reused to a certain extent.

As time progresses to 2021, when the development of Rollup gradually enters a better state, we know that both OP Rollup and ZK Rollup mean that some proof data after compression of L2 data needs to be uploaded to the on-chain through calldata to achieve data availability or directly handed over to the on-chain for verification. As a result, these rollup solutions face significant gas costs when maintaining L2 finality, and these costs are ultimately passed on to users, so most L2 protocol usage costs are not as low as imagined.

At the same time, Ethereum is also facing the dilemma of competition between Block short, we know that there is a gas limit for each Block, which means that the total gas consumption of all transactions in the current Block cannot exceed this value, based on the current gas limit of 300000000, there is a theoretical limit of 30, 000, 000 / 16 = 1, 875, 000 bytes, where 16 refers to the consumption of 16 per calldata byte processed by the EVM This means that the maximum long of a single Block can carry data is about 1.79 MB. The rollup-related data generated by the L2 sequencer is usually large-scale, which makes it compete with other mainchain users’ transaction confirmations, resulting in a smaller volume that can be packed in a single block, which in turn affects the TPS of the mainchain.

To address this dilemma, the core developers proposed EIP-4844 on February 5, 2022, which was implemented after the Dencun upgrade at the beginning of Q2 2024. The proposal proposes a new type of transaction called Blob Transaction, which is based on a new data type, Blob data, which is a new data type, Blob data, compared to the traditional type of Transaction. Unlike the calldata type, blob data cannot be directly accessed by the EVM, but only its hash, also known as VersionedHash. In addition, there are two accompanying designs, one is that compared with ordinary transactions, the GC period of blob transactions is shorter, so as to ensure that the block data is not too bloated, and the second is that blob data has a native gas mechanism, which generally presents a similar effect to EIP-1559, but chooses the natural exponential function in the mathematical model, so that it can perform better in stability when dealing with transaction size fluctuations, because the slope of the natural exponential function is also a natural exponential function, This means that no matter what state the network transaction size is in at this time, when the transaction size spikes rapidly, the base fee of the blob gas responds more fully, thereby effectively curbing transaction activity, and the function also has an important feature, when the abscissa 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, while excess_blob_gas is determined by the difference between the total blobs in the parent Block gas and one TARGET_BLOB_GAS_PER_BLOCK constant, when the total blobs gas When the consumption exceeds the target value, that is, when 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, and vice versa becomes smaller.

In this way, for some scenarios that only want to use Ethereum’s consensus ability to store some large-scale data to ensure availability, it can be executed at low cost without crowding out the transaction packaging capacity of the block. Taking the rollup sequencer as an example, the key information of L2 can be encapsulated into blob data through blob transaction, and the logic of on-chain verification can be implemented by using versionedHash through clever design in the EVM.

It should be added that the current TARGET_BLOB_GAS_PER_BLOCK and MAX_BLOB_GAS_PER_BLOCK settings introduce a limit of Mainnet of 3 blobs (0.375 MB) per Block and a maximum of 6 blobs (0.75 MB) per long. These initial limits are designed to minimize the strain on the network from this EIP and are expected to increase in future upgrades as the network demonstrates reliability at larger blocks.

Refines the gas consumption model for the execution environment - EIP-7706

Now that the current Ethereum gas model has been clarified, let’s take a look at the goals and implementation details of the EIP-7706 proposal. The proposal was presented by Vitalik on May 13, 2024. Similar to blob data, this proposal strips the gas model for another special data field, which is calldata. And the corresponding code implementation logic has been optimized.

In principle, the base fee calculation logic of calldata is the same as that of base fee for blob data in EIP-4844, which uses an exponential function and calculates the scaling of the current base fee based on the deviation value of the actual gas consumption value in the parent block from 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 the operation class Gas, LIMIT_TARGET_RATIOS[ 1 ] represents the target ratio of the Blob data class Gas, and LIMIT_TARGET_RATIOS [ 2 ] represents the calldata The target ratio of the class Gas, this vector is used to calculate the gas target values corresponding to the three classes of gas in the parent Block, and the calculation logic is as follows, that is, the gas limit is divisible by LIMIT_TARGET_RATIOS respectively:

The 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 300000000 // 4 // 4 = 1875000, and because according to the current calldata gas calculation logic, each non-zero bytes consumes 16 gas, and zero bytes consumes 4 gas. Assuming that the distribution of non-zero and zero bytes in a certain segment of calldata accounts for 50% each, it takes an average of 10 gas to process 1 bytes of calldata. Therefore, the current calldata gas target should cope with 187500 bytes of calldata data, which is about 2 times the current average usage.

The advantage of this is that the probability of calldata reaching the gas limit is greatly reduced, and the usage of calldata is kept in a more consistent state through economic modeling, and the abuse of calldata is also eliminated. The reason for this design is to clear the way for the development of L2, and with blob data, the sequencer cost is further dropped.