Author: @Web3Mario

Introduction: Vitalik released the EIP-7706 proposal on May 13, 2024, proposing a complementary scheme to the existing gas model, dropping out the gas calculation of calldata, and customizing a base fee pricing mechanism similar to Blob gas to further reduce 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 make an overview 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 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, usually, because the transaction fee paid by the user will be vesting than the Miner, so the Miner will determine the order of transaction packaging according to the principle of economic optimization, 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:

There is a mismatch between the Fluctuation of the Money Laundering level and the cost of the transaction Consensus:* For active Blockchain, the packaging demand for the transaction is sufficient, which means that the Block can be easily filled, but it also often means that the overall cost is extremely Fluctuation. For example, when the average gas price is 10 Gwei, the marginal cost of the network to accept another 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 limit of gaslimit per Block, coupled with the natural Fluctuation of historical volume, transactions often wait a few Block before being 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. A Blockchain without Block Reward will be unstable: When the Block Reward brought by the Mining is removed and a pure fee model is adopted, it can lead to very long instability, such as incentivizing mining to steal the "sister block" of the Money Laundering, opening a more powerful selfish mining Attack Vector, etc.

Until EIP-1559 was proposed and executed, there was a first iteration of the Gas model, EIP-1559 was proposed by Vitalik and other core developers on April 13, 2019, and adopted in the London upgrade on August 5, 2021 fee will be based on the gas consumption generated in the parent Block and a floating and recursive gas The relationship between the target is quantitatively calculated through an established mathematical model, and 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 gas target, the base fee will be lowered, which can better reflect the relationship between supply and demand. It can also make the prediction of reasonable gas more accurate, and there will be no sky-high gas price caused by 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 the gas target, and the maximum value of the remainder and 1 of the 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 directly burned, 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, which can be freely priced, which can allow the sorting Algorithm of the Miner to be reused to a certain extent.

With the advancement of time to 2021, when the development of Rollup gradually entered a better situation, 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 large gas costs when maintaining L2 finality, and these costs will eventually be 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 EVM processing each calldata Bytes consume 16 units of gas, which means that a single Block can carry about 1.79 MB of data long. The rollup-related data generated by the L2 sequencer usually has a large data scale, which makes it compete with other mainchain users' transaction confirmations, resulting in a smaller volume of transactions that can be packaged in a single block, which in turn affects the TPS of the mainchain.

To address this dilemma, core developers submitted a proposal for EIP-4844 on February 5, 2022, which was implemented after the Dencun upgrade at the beginning of Q2 2024. The proposal proposes a new transaction type called Blob Transaction, which is supplemented with 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 transaction is shorter, so as to ensure that the Block data is not too bloated, and the other is that blob data has a native Gas mechanism, and the overall effect is similar to EIP-1559, but the natural exponential function is selected in the mathematical model, so that it performs better in terms of stability in response to 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 soars 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, and excess_blob_gas is determined by the difference between the total blobs in the parent Block gas consumed by one TARGET_BLOB_GAS_PER_BLOCK constant, when the total blobs gas 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.

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, and will not crowd 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 realized by using versionedHash through ingenious 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.

Re-refinement of the execution environment gas consumption model - 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 corresponding to 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 between the actual gas consumption value and the target value in the parent block.

It is worth noting a new parametric design, LIMIT_TARGET_RATIOS=[2,2,4], where LIMIT_TARGET_RATIOS[0][1]Indicates the target ratio of the operation gas, LIMIT_TARGET_RATIOS[2]Indicates the target ratio of the blob data class Gas, which is LIMIT_TARGET_RATIOSThis vector is used to calculate the gas target value corresponding to the three classes of gas in the parent Block, and the calculation logic is as follows, that is, LIMIT_TARGET_RATIOS is used to divide the gas limit by dividing the limit:

The logic of setting gas_limits is as follows:

gas_limits[0]The existing adjustment formula must be followed

gas_limits[1]Must be equal to MAX_BLOB_GAS_PER_BLOCK

gas_limits[2][0]Must be equal to gas_limits // CALLDATA_GAS_LIMIT_RATIO

We know the current gas_limits[0]is 30000000, 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. For example, if the distribution of non-zero and zero bytes in a certain segment of calldata accounts for 50% each, the average processing of 1 byte of calldata consumes 10 gas. Therefore, the current calldata gas target should cope with 187,500 bytes of calldata data, which is about twice 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 drop the development of L2, and with blob data, the sequencer cost is further reduced.