What is the latest EIP-7706 proposed by Vitalik? An article to sort out the current Ethereum Gas mechanism

Original author: Mario's Web3

Introduction: Vitalik released the EIP-7706 proposal on May 14, 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 order of transaction packaging according to the principle of economic optimality and the bid price. 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 for 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 for each block, coupled with the natural fluctuations in historical transaction volume, transactions usually wait for several blocks to be 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:The use of a simple auction mechanism leads to low efficiency in fair price discovery, which means that it will be difficult for users to give a reasonable price, which means that in many cases, users pay high fees.

· Blockchain 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; 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, parent_base_fee is multiplied by the offset of the total gas cost of the previous block relative to the gas target and the maximum value of the modulus of the gas target and a constant plus 1. 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 progresses to 2021, the development of Rollup is gradually entering a good stage. We know that both OP Rollup and ZK Rollup mean that some proof data after L2 data compression needs to be uploaded to the chain through calldata to achieve data availability (Data Available) or directly handed over to the chain for verification. This makes these Rollup solutions face a large gas cost 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 was 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.

To solve this dilemma, 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 proposed 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 only its hash, also known as VersionedHash. In addition, there are two accompanying designs. First, compared with ordinary transactions, the GC cycle of blob transactions is shorter, thus ensuring 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 to make it more stable when 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 react more fully, thereby effectively curbing transaction activity. At the same time, the function has an important feature that 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)

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 consumed 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 capability to store some large-scale data to ensure availability to be executed at a low cost without squeezing the transaction packaging capacity of the block. Taking the Rollup sorter 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 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, namely the target of processing an average of 3 blobs (0.375 MB) per block and a limit of up to 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 off 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 there is a new parameter design, LIMIT_TARGET_RATIOS=[2,2,4], where LIMIT_TARGET_RATIOS[0] represents the target ratio of the execution operation 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 setting 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 30000000 // 4 // 4 = 1875000. According to the current calldata gas calculation logic, each non-zero Byte consumes 16 Gas and zero Byte consumes 4 Gas. Assuming that the distribution of non-zero and zero Bytes in a certain calldata segment is 50% each, it takes an average of 10 Gas to process 1 Byte of calldata. Therefore, the current calldata gas target should correspond to 187500 bytes of calldata data, which is about twice the current average usage.

The benefit of this is that it greatly reduces the probability of calldata reaching the gas limit. The economic model keeps the usage of calldata at a relatively consistent level, while also preventing abuse of calldata. The reason for this design is to clear obstacles for the development of L2, and with blob data, the cost of the sorter is further reduced.

This article is from a contribution and does not represent the views of BlockBeats.

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群： https://t.me/theblockbeats

Telegram 交流群： https://t.me/BlockBeats_App

Twitter 官方账号： https://twitter.com/BlockBeatsAsia