laitimes

Ethereum's gas mechanics are described in detail and EIP-7706 is detailed

author:MarsBit

Original author: @web3_mario

Original source: Deep Tide

Introduction: On May 13, 2024, Vitalik released the EIP-7706 proposal, which proposes a complementary solution to the existing gas model, separating the gas computation of calldata from the separate system, and customizing a base fee pricing mechanism similar to blob gas to further reduce the operating cost of L2. The proposal also dates back to EIP-4844 proposed in February 2022, 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 are EIP-1559 and EIP-4844

In the original 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 gas price, normally, since the transaction fees paid by users will be attributed to miners, so miners will decide the order of transaction packaging according to the principle of economic optimality, according to the bidding price, note that this is in the case of ignoring MEV. In the eyes of the core developers at the time, the mechanism faced the following four problems:

l Mismatch between the volatility of transaction fee levels and the consensus cost of transactions: For active blockchains, there is ample demand for transaction packaging, which means that blocks can be easily filled, but this often also means that the overall fees are extremely volatile. 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 higher than when the average gas price is 1 Gwei, which is unacceptable.

Unnecessary latency for users: Due to the hard limit of gaslimit per block, coupled with the natural fluctuations in historical transaction volume, transactions usually wait for a few blocks before being packaged, which 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 demand difference from block to block.

l 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 many cases, users pay high fees.

l Blockchains without block rewards will be unstable: When the block reward from mining is canceled and a pure fee model is adopted, it may lead to a lot of instability, such as incentivizing mining to steal transaction fees "sister blocks", opening more powerful selfish mining attack vectors, etc.

Until EIP-1559 was proposed and implemented, 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 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 not as good as the 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, so that 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:

Ethereum's gas mechanics are described in detail and EIP-7706 is detailed

It can be seen that when the 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 the maximum value of parent_base_fee multiplied by the offset of the total gas usage of the previous block relative to the gas target, and the remainder of the gas target and a constant and 1. 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 state of deflation, which is conducive to the stability of value. On the other hand, Priority fee is equivalent to the user's reward to the miner, which can be set freely, which can allow the miner's sorting algorithm to be reused to a certain extent.

Ethereum's gas mechanics are described in detail and EIP-7706 is detailed

As we move forward to 2021, when the development of Rollups is gradually getting better, we know that both OP Rollups and ZK Rollups mean that some proof data after compressing L2 data needs to be uploaded to the chain through calldata to achieve data availability or directly handed over to the chain for verification. As a result, these rollup solutions face a large gas cost when maintaining L2 finality, and these costs will eventually be passed on to users, so the cost of using most L2 protocols at that time is not as low as expected.

At the same time, Ethereum is also facing the dilemma of block space competition, we know that there is a gas limit for each block, which means that the sum of the gas consumption of all transactions in the current block cannot exceed this value, according to 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 a maximum of about 1.79 MB of data. However, the rollup-related data generated by the L2 sequencer usually has a large data scale, which makes it compete with other main chain users for transaction confirmation, resulting in a smaller transaction volume that can be packed in a single block, which in turn affects the TPS of the main chain.

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 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, which is similar to EIP-1559 in general, but the natural exponential function is selected in the mathematical model, so that it can perform 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 spikes rapidly, the base fee of blob gas will respond more fully, thus 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 the excess_blob_gas is determined by the difference between the total blob gas consumption in the parent block and one 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) greater than 1, the base_fee_per_blob_gas becomes larger, and vice versa.

In this way, for some scenarios that only want to use Ethereum's consensus power to store evidence for some large-scale data to ensure availability, it can be executed at a low cost, and at the same time, it 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 implemented by using versionedHash through exquisite 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 on mainnet, which is the target of 3 blobs (0.375 MB) and a maximum of 6 blobs (0.75 MB) per block. These initial limits are designed to minimize the strain on the network caused by this EIP and are expected to increase in future upgrades as the network demonstrates reliability under larger blocks.

Ethereum's gas mechanics are described in detail and EIP-7706 is detailed

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 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 ratio of the current base fee based on the deviation between the actual gas consumption value in the parent block and the target value.

Ethereum's gas mechanics are described in detail and EIP-7706 is detailed

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, LIMIT_TARGET_RATIOS[1] represents the target ratio of the Blob data class, and LIMIT_TARGET_RATIOS[2] This vector is used to calculate the gas target value corresponding to the three types of gas in the parent block, and the calculation logic is as follows, that is, use the LIMIT_TARGET_RATIOS to divide the gas limit by dividing the gas limit:

The logic of the 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 the 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. 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 it greatly reduces the probability of calldata reaching the gas limit, keeps the usage of calldata in a more consistent state through the economic model, and also eliminates the abuse of calldata. The reason for this design is to clear the way for the development of L2, and with blob data, the sequencer cost is further reduced.