Detailed Explanation of EIP-7706 and the Latest Ethereum Gas Mechanism

IntermediateJun 05, 2024
This article provides a detailed explanation of the principles and implementation details of EIP-7706. This proposal draws on the Blob gas pricing mechanism from EIP-4844 to further reduce the operational costs of Layer 2 (L2). It helps readers quickly understand the latest developments in the Ethereum Gas mechanism.
Detailed Explanation of EIP-7706 and the Latest Ethereum Gas Mechanism

Introduction

On May 13, 2024, Vitalik proposed EIP-7706, suggesting a supplementary plan to the existing Gas model. This proposal isolates the gas calculation of calldata and customizes a base fee pricing mechanism similar to Blob gas, further reducing the operational costs of Layer 2 (L2). The related proposals date back to EIP-4844, proposed in February 2022. Given the significant time gap, this article reviews the relevant materials to provide an overview of the latest developments in the Ethereum Gas mechanism, enabling readers to quickly understand the updates.

Current Supported Ethereum Gas Models: EIP-1559 and EIP-4844

In its initial design, Ethereum adopted a simple auction mechanism to price transaction fees, requiring users to actively bid for their transactions by setting a gas price. Generally, since the transaction fees paid by users go to the miners, miners prioritize transactions based on the highest bids, assuming no Miner Extractable Value (MEV) considerations. Core developers identified four main issues with this mechanism:

Mismatch between transaction fee volatility and consensus costs: For an active blockchain, there is ample demand for transaction inclusion, meaning blocks can easily be filled. However, this also results in significant fee volatility. For instance, when the average Gas Price is 10 Gwei, the marginal cost of adding another transaction to a block is ten times higher than when the average Gas Price is 1 Gwei, which is unacceptable.

Unnecessary delays for users: Due to the hard gas limit per block and natural fluctuations in historical transaction volume, transactions often wait several blocks to be included. This is inefficient for the overall network because there is no flexibility mechanism to allow one block to be larger and the next to be smaller to meet varying block-to-block demand.

Inefficiency in pricing: The simple auction mechanism leads to inefficient price discovery, making it difficult for users to set a reasonable price. This often results in users overpaying for transaction fees.

Instability in a blockchain without block rewards: When block rewards from mining are removed and a pure fee model is adopted, it can lead to instability, such as the creation of “uncle blocks” that steal transaction fees, increasing vectors for powerful selfish mining attacks.

With the introduction and implementation of EIP-1559, the Gas model underwent its first significant iteration. Proposed by Vitalik and other core developers on April 13, 2019, and adopted during the London upgrade on August 5, 2021, this mechanism abandoned the auction model in favor of a dual-pricing model consisting of a Base fee and a Priority fee. The Base fee is quantitatively adjusted through a predetermined mathematical model based on the gas consumption in the parent block relative to a floating and recursive gas target.

Base fee Calculation and Effects: If gas usage in the previous block exceeds the gas target, the Base fee increases; if it falls short of the gas target, the Base fee decreases. This adjustment reflects supply-demand dynamics well and improves the accuracy of reasonable gas predictions, avoiding exorbitant Gas Prices due to misoperation, as the Base fee calculation is system-determined rather than user-specified. The specific code for the calculation is as follows:

From the content, we can infer that when the parent_gas_used is greater than the parent_gas_target, the base fee of the current block will be increased compared to the base fee of the previous block by an offset value. This offset is determined by multiplying the parent_base_fee with the deviation of the total gas usage from the gas target in the previous block, then taking the remainder of the gas target and a constant, and the maximum value between this remainder and 1. Conversely, the logic applies similarly when the parent_gas_used is less than the parent_gas_target.

Additionally, the base fee will no longer be distributed as a reward to miners but will be burned instead. This makes ETH’s economic model deflationary, helping to stabilize its value. On the other hand, the priority fee, akin to a tip from users to miners, can be freely priced, allowing some degree of reuse in miners’ sorting algorithms.

By 2021, Rollup development had entered a mature stage. We know that both OP Rollup and ZK Rollup involve compressing L2 data and uploading some proof data via calldata to the chain for data availability or direct on-chain verification. This leads to significant gas costs in maintaining L2 finality, which are ultimately borne by users, resulting in higher than anticipated costs for most L2 protocols.

Simultaneously, Ethereum faced the challenge of block space competition. Each block has a gas limit, meaning the total gas consumption of all transactions in a block cannot exceed this limit. With the current gas limit set at 30,000,000, theoretically, there is a limit of 1,875,000 bytes (30,000,000 / 16) per block, where 16 units of gas are needed for each calldata byte processed by the EVM, resulting in a maximum data capacity of about 1.79 MB per block. The Rollup-related data generated by L2 sequencers is typically large, creating competition with other mainnet users’ transactions and reducing the number of transactions that can be included in a single block, thereby affecting the mainnet’s TPS.

To address this issue, core developers proposed EIP-4844 on February 5, 2022, which was implemented following the Dencun upgrade in early Q2 2024. This proposal introduced a new transaction type called Blob Transaction. Unlike traditional transactions, Blob Transaction includes a new data type, Blob data, which, unlike calldata, cannot be directly accessed by the EVM but only through its hash, also known as VersionedHash. Additionally, Blob Transactions have a shorter GC cycle compared to regular transactions, preventing block data from becoming too bloated. Blob data also comes with an inherent gas mechanism, similar to EIP-1559, but uses a natural exponential function in its mathematical model, providing better stability in handling transaction size fluctuations. The slope of the natural exponential function is also a natural exponential function, meaning that regardless of the current state of network transaction sizes, the base fee of blob gas reacts more fully to rapid transaction surges, effectively curbing transaction activity. Another key feature is that the function value is 1 when the horizontal axis is 0.

base_fee_per_blob_gas = MIN_BASE_FEE_PER_BLOB_GAS e*(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)

Here, MIN_BASE_FEE_PER_BLOB_GAS and BLOB_BASE_FEE_UPDATE_FRACTION are constants, while excess_blob_gas is determined by the difference between the total blob gas consumption in the parent block and a constant TARGET_BLOB_GAS_PER_BLOCK. When total blob gas consumption exceeds the target value, making the difference positive, e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION) is greater than 1, causing the base_fee_per_blob_gas to increase, and vice versa.

This mechanism allows for low-cost execution of scenarios where Ethereum’s consensus capability is utilized to notarize large data volumes to ensure availability without occupying transaction packaging capacity. For example, Rollup sequencers can use Blob Transactions to encapsulate key L2 information into blob data and achieve on-chain verification through VersionedHash within the EVM.

It should be noted that the current settings for TARGET_BLOB_GAS_PER_BLOCK and MAX_BLOB_GAS_PER_BLOCK impose a limitation on the mainnet, with an average target of processing 3 blobs (0.375 MB) per block and a maximum of 6 blobs (0.75 MB) per block. These initial limits aim to minimize the network stress caused by this EIP, with an expectation to increase these limits in future upgrades as the network demonstrates reliability under larger block sizes.

Refining the Gas Consumption Model for Execution Environments: EIP-7706

After understanding the current Ethereum Gas model, let’s delve into the goals and implementation details of the EIP-7706 proposal. This proposal, put forth by Vitalik on May 13, 2024, aims to redefine the Gas model for a specific data field known as calldata, much like the earlier changes for Blob data. Additionally, the proposal optimizes the corresponding code logic.

Fundamental Concepts

The base fee calculation logic for calldata in EIP-7706 mirrors the base fee calculation for blob data as specified in EIP-4844. Both utilize an exponential function to adjust the base fee based on the deviation between the actual gas consumption and the target value in the parent block.

A noteworthy aspect of this proposal is the introduction of a new parameter design, LIMIT_TARGET_RATIOS = [2, 2, 4]. Here’s the breakdown:

LIMIT_TARGET_RATIOS[0]: Target ratio for execution operation gas.

LIMIT_TARGET_RATIOS[1]: Target ratio for Blob data gas.

LIMIT_TARGET_RATIOS[2]: Target ratio for calldata gas.

These ratios are used to compute the gas target values for the three types of gas in the parent block by dividing the gas limit by the respective ratios.

The gas limits are set as follows:

  • gas_limits[0] follows the existing adjustment formula.

  • gas_limits[1] equals MAX_BLOB_GAS_PER_BLOCK.

  • gas_limits[2] equals gas_limits[0] / CALLDATA_GAS_LIMIT_RATIO.

Given the current gas_limits[0] is 30,000,000 and the CALLDATA_GAS_LIMIT_RATIO is preset to 4, this means the current calldata gas target is approximately:

[ \frac{30,000,000}{4 \times 4} = 1,875,000 ]

According to the current calldata gas calculation logic:

  • Each non-zero byte consumes 16 Gas.

  • Each zero byte consumes 4 Gas.

Assuming an even distribution of non-zero and zero bytes in a segment of calldata, the average gas consumption per byte is 10 Gas. Hence, the current calldata gas target corresponds to approximately 187,500 bytes of calldata, which is about twice the current average usage.

Benefits of the Proposal

This adjustment significantly reduces the likelihood of calldata reaching the gas limit, maintaining calldata usage at a consistent level through economic modeling and preventing abuse. The primary intent of this design is to facilitate the growth of Layer 2 solutions, reducing sequencer costs when used alongside blob data.

In conclusion, EIP-7706 not only refines the Gas model for calldata but also strategically positions Ethereum for the efficient scaling of Layer 2 solutions by controlling and optimizing data-related gas consumption.

Disclaimer:

  1. This article is reprinted from [Web3Mario], All copyrights belong to the original author [Web3Mario]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
  2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
  3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.

Detailed Explanation of EIP-7706 and the Latest Ethereum Gas Mechanism

IntermediateJun 05, 2024
This article provides a detailed explanation of the principles and implementation details of EIP-7706. This proposal draws on the Blob gas pricing mechanism from EIP-4844 to further reduce the operational costs of Layer 2 (L2). It helps readers quickly understand the latest developments in the Ethereum Gas mechanism.
Detailed Explanation of EIP-7706 and the Latest Ethereum Gas Mechanism

Introduction

On May 13, 2024, Vitalik proposed EIP-7706, suggesting a supplementary plan to the existing Gas model. This proposal isolates the gas calculation of calldata and customizes a base fee pricing mechanism similar to Blob gas, further reducing the operational costs of Layer 2 (L2). The related proposals date back to EIP-4844, proposed in February 2022. Given the significant time gap, this article reviews the relevant materials to provide an overview of the latest developments in the Ethereum Gas mechanism, enabling readers to quickly understand the updates.

Current Supported Ethereum Gas Models: EIP-1559 and EIP-4844

In its initial design, Ethereum adopted a simple auction mechanism to price transaction fees, requiring users to actively bid for their transactions by setting a gas price. Generally, since the transaction fees paid by users go to the miners, miners prioritize transactions based on the highest bids, assuming no Miner Extractable Value (MEV) considerations. Core developers identified four main issues with this mechanism:

Mismatch between transaction fee volatility and consensus costs: For an active blockchain, there is ample demand for transaction inclusion, meaning blocks can easily be filled. However, this also results in significant fee volatility. For instance, when the average Gas Price is 10 Gwei, the marginal cost of adding another transaction to a block is ten times higher than when the average Gas Price is 1 Gwei, which is unacceptable.

Unnecessary delays for users: Due to the hard gas limit per block and natural fluctuations in historical transaction volume, transactions often wait several blocks to be included. This is inefficient for the overall network because there is no flexibility mechanism to allow one block to be larger and the next to be smaller to meet varying block-to-block demand.

Inefficiency in pricing: The simple auction mechanism leads to inefficient price discovery, making it difficult for users to set a reasonable price. This often results in users overpaying for transaction fees.

Instability in a blockchain without block rewards: When block rewards from mining are removed and a pure fee model is adopted, it can lead to instability, such as the creation of “uncle blocks” that steal transaction fees, increasing vectors for powerful selfish mining attacks.

With the introduction and implementation of EIP-1559, the Gas model underwent its first significant iteration. Proposed by Vitalik and other core developers on April 13, 2019, and adopted during the London upgrade on August 5, 2021, this mechanism abandoned the auction model in favor of a dual-pricing model consisting of a Base fee and a Priority fee. The Base fee is quantitatively adjusted through a predetermined mathematical model based on the gas consumption in the parent block relative to a floating and recursive gas target.

Base fee Calculation and Effects: If gas usage in the previous block exceeds the gas target, the Base fee increases; if it falls short of the gas target, the Base fee decreases. This adjustment reflects supply-demand dynamics well and improves the accuracy of reasonable gas predictions, avoiding exorbitant Gas Prices due to misoperation, as the Base fee calculation is system-determined rather than user-specified. The specific code for the calculation is as follows:

From the content, we can infer that when the parent_gas_used is greater than the parent_gas_target, the base fee of the current block will be increased compared to the base fee of the previous block by an offset value. This offset is determined by multiplying the parent_base_fee with the deviation of the total gas usage from the gas target in the previous block, then taking the remainder of the gas target and a constant, and the maximum value between this remainder and 1. Conversely, the logic applies similarly when the parent_gas_used is less than the parent_gas_target.

Additionally, the base fee will no longer be distributed as a reward to miners but will be burned instead. This makes ETH’s economic model deflationary, helping to stabilize its value. On the other hand, the priority fee, akin to a tip from users to miners, can be freely priced, allowing some degree of reuse in miners’ sorting algorithms.

By 2021, Rollup development had entered a mature stage. We know that both OP Rollup and ZK Rollup involve compressing L2 data and uploading some proof data via calldata to the chain for data availability or direct on-chain verification. This leads to significant gas costs in maintaining L2 finality, which are ultimately borne by users, resulting in higher than anticipated costs for most L2 protocols.

Simultaneously, Ethereum faced the challenge of block space competition. Each block has a gas limit, meaning the total gas consumption of all transactions in a block cannot exceed this limit. With the current gas limit set at 30,000,000, theoretically, there is a limit of 1,875,000 bytes (30,000,000 / 16) per block, where 16 units of gas are needed for each calldata byte processed by the EVM, resulting in a maximum data capacity of about 1.79 MB per block. The Rollup-related data generated by L2 sequencers is typically large, creating competition with other mainnet users’ transactions and reducing the number of transactions that can be included in a single block, thereby affecting the mainnet’s TPS.

To address this issue, core developers proposed EIP-4844 on February 5, 2022, which was implemented following the Dencun upgrade in early Q2 2024. This proposal introduced a new transaction type called Blob Transaction. Unlike traditional transactions, Blob Transaction includes a new data type, Blob data, which, unlike calldata, cannot be directly accessed by the EVM but only through its hash, also known as VersionedHash. Additionally, Blob Transactions have a shorter GC cycle compared to regular transactions, preventing block data from becoming too bloated. Blob data also comes with an inherent gas mechanism, similar to EIP-1559, but uses a natural exponential function in its mathematical model, providing better stability in handling transaction size fluctuations. The slope of the natural exponential function is also a natural exponential function, meaning that regardless of the current state of network transaction sizes, the base fee of blob gas reacts more fully to rapid transaction surges, effectively curbing transaction activity. Another key feature is that the function value is 1 when the horizontal axis is 0.

base_fee_per_blob_gas = MIN_BASE_FEE_PER_BLOB_GAS e*(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)

Here, MIN_BASE_FEE_PER_BLOB_GAS and BLOB_BASE_FEE_UPDATE_FRACTION are constants, while excess_blob_gas is determined by the difference between the total blob gas consumption in the parent block and a constant TARGET_BLOB_GAS_PER_BLOCK. When total blob gas consumption exceeds the target value, making the difference positive, e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION) is greater than 1, causing the base_fee_per_blob_gas to increase, and vice versa.

This mechanism allows for low-cost execution of scenarios where Ethereum’s consensus capability is utilized to notarize large data volumes to ensure availability without occupying transaction packaging capacity. For example, Rollup sequencers can use Blob Transactions to encapsulate key L2 information into blob data and achieve on-chain verification through VersionedHash within the EVM.

It should be noted that the current settings for TARGET_BLOB_GAS_PER_BLOCK and MAX_BLOB_GAS_PER_BLOCK impose a limitation on the mainnet, with an average target of processing 3 blobs (0.375 MB) per block and a maximum of 6 blobs (0.75 MB) per block. These initial limits aim to minimize the network stress caused by this EIP, with an expectation to increase these limits in future upgrades as the network demonstrates reliability under larger block sizes.

Refining the Gas Consumption Model for Execution Environments: EIP-7706

After understanding the current Ethereum Gas model, let’s delve into the goals and implementation details of the EIP-7706 proposal. This proposal, put forth by Vitalik on May 13, 2024, aims to redefine the Gas model for a specific data field known as calldata, much like the earlier changes for Blob data. Additionally, the proposal optimizes the corresponding code logic.

Fundamental Concepts

The base fee calculation logic for calldata in EIP-7706 mirrors the base fee calculation for blob data as specified in EIP-4844. Both utilize an exponential function to adjust the base fee based on the deviation between the actual gas consumption and the target value in the parent block.

A noteworthy aspect of this proposal is the introduction of a new parameter design, LIMIT_TARGET_RATIOS = [2, 2, 4]. Here’s the breakdown:

LIMIT_TARGET_RATIOS[0]: Target ratio for execution operation gas.

LIMIT_TARGET_RATIOS[1]: Target ratio for Blob data gas.

LIMIT_TARGET_RATIOS[2]: Target ratio for calldata gas.

These ratios are used to compute the gas target values for the three types of gas in the parent block by dividing the gas limit by the respective ratios.

The gas limits are set as follows:

  • gas_limits[0] follows the existing adjustment formula.

  • gas_limits[1] equals MAX_BLOB_GAS_PER_BLOCK.

  • gas_limits[2] equals gas_limits[0] / CALLDATA_GAS_LIMIT_RATIO.

Given the current gas_limits[0] is 30,000,000 and the CALLDATA_GAS_LIMIT_RATIO is preset to 4, this means the current calldata gas target is approximately:

[ \frac{30,000,000}{4 \times 4} = 1,875,000 ]

According to the current calldata gas calculation logic:

  • Each non-zero byte consumes 16 Gas.

  • Each zero byte consumes 4 Gas.

Assuming an even distribution of non-zero and zero bytes in a segment of calldata, the average gas consumption per byte is 10 Gas. Hence, the current calldata gas target corresponds to approximately 187,500 bytes of calldata, which is about twice the current average usage.

Benefits of the Proposal

This adjustment significantly reduces the likelihood of calldata reaching the gas limit, maintaining calldata usage at a consistent level through economic modeling and preventing abuse. The primary intent of this design is to facilitate the growth of Layer 2 solutions, reducing sequencer costs when used alongside blob data.

In conclusion, EIP-7706 not only refines the Gas model for calldata but also strategically positions Ethereum for the efficient scaling of Layer 2 solutions by controlling and optimizing data-related gas consumption.

Disclaimer:

  1. This article is reprinted from [Web3Mario], All copyrights belong to the original author [Web3Mario]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
  2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
  3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.
Start Now
Sign up and get a
$100
Voucher!