Two Keys and 21 EIPs of Ethereum Gas Fees

This article was published in the White Plan, author: Li.

The issue of Gas fees is currently one of the most serious problems faced by the Ethereum 1.0 chain. Despite the high computing power of Ethereum, its task capacity is limited due to the structural issues of the blockchain (each full node computes the same data, so tasks compete for the computing resources of a single node). When Ethereum handles a large number of tasks, it can become congested, leading to high Gas fees.

The explosive growth of DeFi applications has exacerbated this phenomenon. It is worth mentioning that, in addition to packaging blockchain transactions, smart contracts are also deployed on the chain, so executing smart contracts on-chain consumes resources. Therefore, almost every step users take in DeFi requires paying Gas fees, which is one of the issues with the Gas model.

Recently, discussions in the Ethereum community regarding EIP-1559 have become more intense, as many mining pools disagree with deploying this proposal. This proposal adjusts the composition of Gas fees; although it cannot solve the problem of high Gas fees, it can improve expectations regarding Gas fees and enhance the overall experience.

Another recent related news is that on March 16, Ethereum developer Philippe Castonguay proposed another proposal, EIP-3382, suggesting that the block Gas limit be fixed at 12,500,000 Gas per block. It also updates block validation rules, stating that if the Gas limit is not equal to 12,500,000, the block is invalid. This aims to reach a consensus on the block Gas limit and not be constrained by miners.

Under the original rules, the block Gas limit was the only data part in Ethereum not determined by node consensus; it was a parameter chosen by miners. He believes this is a key parameter that requires node consensus to avoid sudden harmful changes imposed by a minority of participants on the rest of the network.

There are many proposals like EIP-1559 and EIP-3382 that adjust Gas fees. Since Gas fees play a significant role in the operation of Ethereum, there are many historical stories related to Gas fees. If one browses through all the information about Gas fees, it becomes clear that solving the Gas fee issue is not an easy task.

Today, the White Plan team will provide readers with nearly all relevant information about Ethereum's Gas fees mentioned in the article, including design changes, EIP revisions, etc. We hope you find it useful.

To understand Gas fees, the dynamic images from TXStreet can provide a vivid illustration.

TXStreet visualizes the Ethereum block packaging process as transportation

If we abstract the block packaging process as a car transportation process, we encounter factors such as limited road width and limited car capacity, so the process of getting into the car will involve competition, which can be understood as being awarded to the highest bidder. The average cost will also be "hiked" due to congestion.

The road on which the car travels is a basic resource, requiring payment of a "toll" to cover it, while the Gas fee required for packaging is the "Gas fee." The costs ultimately come from the users, and the Gas fees are used to pay for the "toll." Thus, Gas fees (Gas fees) are the costs for using Ethereum's resources.

The First Key About Gas

The concept of Gas comes from the computing field, and in Ethereum, it can be traced back to the Ethereum Yellow Paper, authored by Polkadot founder Gavin. It is quite alarming that the Ethereum Yellow Paper states that theoretically, the Gas included in a transaction can be any value, as it is meant to cover more transactions, potentially up to 2^256 (which could cover nearly as many transactions as there are atoms in the known universe).

Although the design is infinite, processing power is limited. In Geth version 1.6, Gas calculation switched to using 64-bit values, allowing a single block's Gas limit to accommodate a transaction volume 44 times that of red blood cells in the human body. However, this is theoretical; reality is far from it.

Before this version was confirmed, there was an interesting detail: in the Gas model designed by Vitalik, the Gas fee payment process was defaulted to be within the contract. This means that during the execution of a contract, the balance within the contract would decrease, and if the balance was insufficient due to execution consumption, the contract would pause.

Early Ethereum contracts had built-in deduction settings for execution

Later, Gavin began to participate in Ethereum and modified the Gas payment mechanism, changing it from contract execution payment to sender payment, meaning the person executing the contract pays. Vitalik described this as a shift from "contract payment" to "sender payment," replacing the immediate deduction of a small amount of ETH for each individual transaction step.

Early Ethereum Vitalik and Gavin at a mini hackathon, with the great god in the middle being Jeffrey

This is a relatively easy-to-understand "Gas fee payment." If we dissect the details further, we need to look at the relevant parts of Gas in the Yellow Paper.

Gas is the unit of measurement for all computational work in Ethereum. The more computations you want to perform on Ethereum, the more Gas you need to pay.

This user-pays model helps avoid resource abuse. It can be understood that once developers pay for each operation, they will strive to write code as concisely and efficiently as possible. Additionally, the existence of Gas can prevent attackers from flooding the Ethereum network through invalid operations (hence executing many operations requires spending Gas). One of the EIPs mentioned below increased the Gas value for account access to reduce the likelihood of attacks.

In addition to knowing where to pay Gas, we also need to understand GasPrice and GasLimit.

GasPrice is the price that the transaction sender is willing to pay for each unit of Gas (measured in Wei). The transaction sender can customize the price they are willing to pay for each unit of Gas. Suppose a transaction requires 10 Gas, and the sender is willing to pay 3 Wei/Gas; the total cost of the transaction would be 30 Wei. In our wallets, there are often advanced options to adjust Gas fees.

GasLimit is the maximum amount of Gas that the transaction sender can accept for executing the transaction. If there is no GasLimit, it may lead to the sender's account balance being completely consumed by mistake. GasLimit serves as a safety mechanism to prevent the consumption of all ETH in the account.

Additionally, GasLimit can also be defined as pre-paid Gas. When nodes validate transactions, they first multiply GasPrice by GasLimit to calculate the fixed cost of the transaction. If the sender's account balance is less than the fixed cost of the transaction, the transaction is considered invalid. After the transaction is executed, any remaining Gas is refunded to the sender's account, which is why we often see high Gas estimates when using MetMask to execute contracts, but the final price is not as high.

Contents included in a block

This is the inherent content of a block. In the transaction section, there are 237 transfers and 39 internal contract transactions. If you look at the transactions in detail, you can see more detailed Gas fee expenditures. You can also see that the fuel limit is 12,493,113, which is the part mentioned at the beginning of the article regarding EIP-3382, which limits the Gas limit of each block to 12,500,000. This way, the total rewards obtained in each block will be more controllable.

Regarding the ETH1.0 chain, there is a Gas fee calculation for each opcode. We have extracted the parts with higher prices for readers' reference. The opcode ultimately determines the execution and resource usage of the chain. For example, a basic idea is to create a contract. The cost calculation is as follows:

Inherent cost = Gtransaction + Gtxdatazero * Nzeros + Gtxdatanonzero * Nnonzeros + Gtxcreate

Where:

• Gtransaction = 21,000 Wei
• Gtxcreate = 32,000 Wei
• Gtxdatazero = 4 Wei
• Gtxdatanonzero = 68 Wei (will change to 16 Wei during the Istanbul upgrade)

You can match the following opcodes accordingly.

Gas consumption values corresponding to Ethereum 1.0 chain opcodes

From the above introduction, we can understand that Gas fees arise from the use of Ethereum's on-chain resources. The more computations performed, the higher the Gas fees. In smart contract operations, each individual step requires paying Gas. Additionally, it is worth noting that if the sender sets the Gas price very high, miners will prioritize executing the transaction, as they can choose to package certain transactions first.

21 EIPs Closely Related to Gas Fees

Next, we can take a detailed look at the EIP proposals related to Gas. The proposals are roughly arranged in chronological order.

EIP-5: Adjusting Gas Usage for RETURN and CALL

This EIP makes it possible to call functions that return RETURN strings and other dynamically sized arrays. Currently, when calling another contract/function from within the Ethereum Virtual Machine, the output size must be specified in advance. Fees must also be paid for unwritten memory, making it both expensive and inflexible to return dynamically sized data, rendering it practically unusable. The solution proposed in this EIP is to only pay for the memory actually written during the CALL return.

EIP-150: Changes in Gas Costs for Large IO Operations

• Increases the Gas cost of EXTCODESIZE from 20 to 700.
• Increases the base Gas cost of EXTCODECOPY from 20 to 700.
• Increases the Gas cost of BALANCE from 20 to 400.
• Increases the Gas cost of SLOAD from 50 to 200.
• Increases the Gas cost of CALL, DELEGATECALL, CALLCODE from 40 to 700.
• The Gas cost of SELFDESTRUCT remains at 5000.
  If SELFDESTRUCT hits a newly created account, an additional Gas cost of 25000 will be triggered (similar to CALL).
• Raises the suggested Gas limit target to 5.5 million.

EIP-158: State Clearing

In any case, accounts with a call balance of 0 will no longer consume the cost of 25000 Gas for account creation.

EIP-1108: Reducing Gas Costs for alt_bn128 Precompiles

The current price of elliptic curve computation precompiles is too high. Repricing the precompiles will greatly assist many privacy solutions and scaling solutions on Ethereum. For zk-SNARK-based protocols on Ethereum, EIP-1108 will not only significantly reduce the Gas costs for verifying zk-SNARKs but also help batch multiple zk-SNARK proofs together. This is also a technique that can be used to split monolithic zk-SNARK circuits into batches with smaller individual circuit sizes, making zk-SNARKs easier to construct and deploy.

Currently, the cost of these transactions is about 6,000,000 Gas. This EIP can reduce it to 1,000,000 Gas, making the protocol more practical.

EIP-1283: Gas Adjustment for SSTORE Opcode

This EIP proposes changes to the measurement of the SSTORE opcode to enable new uses of contract storage and reduce excessive Gas costs in places that do not match the working methods of most implementations. This can serve as an alternative to EIP-1087, which attempts to be more friendly to implementations using different optimization strategies for cache changes.

EIP-2028: Reducing Gas Costs for Transaction Data

It is proposed to reduce the Gas cost of Calldata (GTXDATANONZERO) from the current 68 bytes to 16 bytes, supported by mathematical modeling and empirical estimation.

EIP-2200: Structured Definition of Net Gas Measurement

This EIP provides a structured definition of net Gas measurement changes for the SSTORE opcode, enabling new uses of contract storage and reducing excessive Gas costs in places that do not match the working methods of most implementations. This can be seen as a combination of EIP-1283 and EIP-1706.

EIP-2565: ModExpGas Cost

To accurately reflect the actual operational costs of ModExp precompiles, this EIP specifies an algorithm for calculating Gas costs. This algorithm estimates the cost of multiplication complexity and multiplies it by an approximation of the number of iterations required to execute the power operation.

EIP-1559: Changes to the Fee Market of the ETH 1.0 Chain

Ethereum uses a simple auction mechanism to price transaction fees at historical prices. Users send transactions with bids ("Gas prices"), and miners choose the transactions with the highest bids to include. This leads to inefficiencies.

The suggestion in this EIP is to start with a base fee amount, which is adjusted up or down by the protocol based on network congestion. When the network exceeds the target Gas usage per block, the base fee slightly increases, while it decreases when capacity is below the target amount.

Due to the limited variation of these base fees, the maximum difference in base fees between different blocks is predictable. This allows wallets to automatically set Gas fees for users in a highly reliable manner. It is expected that most users will not need to manually adjust Gas fees, even during active network periods. For most users, the base fee will be estimated by their wallets.

EIP-2929: Increased Gas Costs for State Access Opcodes

Increased Gas costs for SLOAD (0x54) to 2100, as well as for the CALL opcode family (0xf1, f2, f4, fA), BALANCE 0x31, and EXT opcode family (0x3b, 0x3c, 0x3f), and 2600 exempt CD (ⅰ) precompiles. Additionally, the SSTORE measurement method can be reformed to ensure proper pricing of the inherent "actual storage load" in these opcodes.

Generally, the main function of opcode Gas costs is to estimate the time required to process that opcode, aiming to make the Gas limit correspond to the time limit required to process blocks. However, storage access opcodes (SLOAD, as well as CALL, BALANCE, and EXT opcodes) have historically been underestimated. After the most severe client errors were fixed in the 2016 Shanghai DoS attack, one of the strategies that attackers used effectively was simply sending transactions that could access or call a large number of accounts.

The proposed EIP increases the costs of these opcodes by about 3 times, reducing the worst-case processing time to about 7-27 seconds. Improvements in database layout involve redesigning clients to read storage directly rather than jumping to the Merkle tree, which will further reduce this situation, although these techniques may take a long time to fully roll out, and even with this technology, the IO overhead of accessing storage will remain substantial.

EIP-1077: Gas Relaying for Contract Calls

A major barrier to adopting DApps is the need for multiple tokens to perform chain operations. Allowing users to sign messages to indicate execution intent, but enabling third-party relayers to execute messages can avoid this issue. Although Ethereum transactions always require ETH, smart contracts can adopt EIP-191 signatures and forward payment incentives to untrusted parties with ETH to execute transactions. Their common format can be standardized, and users can be allowed to pay transaction fees with tokens, providing great flexibility for application developers and potentially becoming the primary way for application users to interact with the blockchain.

EIP-1087: Gas Measurement for SSTORE Operations

This EIP proposes changes to the Gas charging method for EVMSSTORE operations to reduce unnecessary Gas costs and provide new use cases for contract storage.

EIP-1285: Increased GcallstipendGas in CALL Opcode

Gcallstipend increases the fee parameter in the CALL opcode from 2,300 to 3,500 Gas units.

EIP-1380: Reduced Gas Costs for Internal Calls

Reducing the Gas costs for internal calls will greatly benefit smart contract languages like Solidity and Vyper, allowing them to use CALL instead of JUMP for internal operation calls.

EIP-1613: Gas Station Network

By allowing contracts to accept "payment on delivery" and pay for Gas, non-ETH users can access smart contracts (e.g., dapps).

Currently, communicating with dapps requires paying Gas fees in ETH, which limits the adoption of dapps to Ethereum users only. Therefore, contract owners may want to pay for Gas to increase user acquisition or allow their users to pay Gas fees in fiat currency. Alternatively, third parties may want to subsidize the Gas costs of certain contracts. As described in EIP-1077, solutions can allow transactions from addresses that do not contain ETH.

EIP-1930: CALL with Strict Gas Semantics. Revert if Insufficient Gas

Adds functionality to smart contracts to execute CALL using a specific amount of Gas. If this cannot be done, execution should revert.

EIP-2045: Granular Gas Costs for EVM Opcodes

Calculating EVM opcodes (ADD, SUB, MUL, etc.) is generally overestimated compared to the I/O (SLOAD, SSTORE, etc.) used for storage opcodes. Currently, the minimum Gas cost is 1 (i.e., one Gas unit), and the costs of most computational opcodes are close to 1 (e.g., 3, 5, or 8), so the range for potential cost reductions is limited. A new minimum Gas unit, called "granular," is a part of Gas that will expand the range of Gas costs, allowing them to be reduced below the current minimum levels.

EIP-2046: Reduced Gas Costs for Static Calls to Precompiles

Reduces the base Gas cost of STATICCALL to precompiles from 700 to 40. This will allow for more efficient use of precompiles and a total cost below 700 for precompiles.

EIP-2542: New Opcodes TXGASLIMIT and CALLGASLIMIT

Allows smart contracts to access information about the Gas limits of the current transaction and execution framework. With the proliferation of concepts like relaying, meta-transactions, Gas fees, and account abstraction, it becomes crucial for certain contracts to be able to track Gas expenditures with absolute precision.

EIP-3322: Account Gas Storage Opcodes

By moving Gas from blocks with lower demand to blocks with higher demand, it brings Gas supply elasticity and price stability. Unfortunately, this rewards unnecessary state growth. By introducing advanced Gas storage mechanisms, the Gas market will require less storage and computation.

EIP-2780: Reduced Internal Transaction Gas

Reduces the internal transaction cost from 21,000 to 7,000 Gas.

The current internal cost of 21,000 Gas for transactions makes sending ETH very expensive, and the cost for small amounts (tens of dollars) is often prohibitively high. While other EIPs (such as EIP-1559) have also considered changes in Gas prices and first-price auctions, significantly reducing the cost of sending ETH in a safe manner and achieving a larger volume of such transactions would be positive.

The Second Key: Rollup and Gas

The early story of Gas is about the establishment of the Ethereum Gas fee model. Currently, aside from reducing Gas fees, the best way to scale and lower Gas fees is through compressing transaction data.

This is closely related to Rollup.

A simple Ethereum transaction (sending ETH) requires about 110 bytes. However, ETH transfers in Rollup only occupy 12 bytes. Therefore, Rollup could potentially increase the scalability of the underlying chain by about 10 times, and in specific computations, using Rollup could even improve scalability by over 100 times.

This is an absolutely remarkable achievement, which is why Eth2.0 has become a development route centered around Rollup.

Adjusting Gas fees is a long-term concept and process, resulting from the meticulous fixes of countless Ethereum engineers. Simply looking at individual Gas EIP adjustments is insufficient to appreciate the importance of Gas fees and the difficulty of adjusting them. However, it is certain that the ultimate solution to the Ethereum Gas problem will be Eth2.0, so keep an expectant heart.