Vitalik proposes to increase Ethereum Gas Limit: what are the risks?

Author: John Otander, Ethereum core developer; Translation: Golden Finance xiaozou

This post was inspired by Ethereum evangelist Vitalik’s answer in a recent Reddit AMA.

Vitalik pointed out that a moderate increase in Gas Limit is reasonable. Gas Limit has not been increased for nearly three years, which is the longest period in the history of the protocol. Vitalik also made some simple calculations to increase the Ethereum Gas Limit to 40 million.

This article explains why it is difficult to increase the Gas Limit of Ethereum? Risks caused by increasing Ethereum Gas Limit, and related solutions.

1, Gas Limit (Gas limit)

Gas limit determines the amount of work completed within a block, and therefore determines how many transactions can be performed per block. Increasing the gas limit will allow Ethereum to handle higher transaction throughput or more complex transactions. Historically, the specific gas limit setting has been influenced by miners/stakers, and the limit has been increased over the years. The picture below is from etherscan.io and shows the historical gas usage (very close to the gas limit, all limit increases have been absorbed by the market).

2, risk

Now increasing the gas limit involves several risk.

(1) Missing block rate

I was before As mentioned in the article, uncle rate is the most discussed indicator when evaluating gas limit increases. Now, after the Ethereum merge, there are no uncle blocks anymore. The only way we want to know whether a node is handling the current gas limit well is to look at the leakage block rate. But this metric is flawed because it only shows nodes that are currently under-supplied. It doesn't give us a good indicator of how the gas limit increases, and it only shows the average case, not the worst case scenario that could happen in an attack.

(2) status size

Block 18418786 ( The account snapshot on October 24, 2023 is 10.33GB, and the storage snapshot is 76.59GB, so the overall status is roughly 87GB. The state of block 17419840 (June 6, 2023) is slightly less than 80GB. This means that the state has grown by approximately 7GB in 4 months, which is approximately 2GB per month.

If we use 87+(2*12*# years) to extrapolate, the status after one year will be 111GB ​​and after five years it will be 207 GB. The issue here isn't size. Everyone can store so much data, but accessing and modifying that data becomes slower and slower.

This is just a snapshot, a general state. Geth also needs to store this state in a different form in order to verify the state root. Another form of state storage (trie node) for block 18418786 requires approximately 180GB.

Therefore, the total space size currently used only for state storage is approximately 267GB. If we increase the gas limit, the state size will grow faster.

The problem with state growth is that, unlike in the past, we have no clear way to remove state. There are no specific state deadline recommendations that we can implement quickly to get us out of the growing state.

(3) Historical scale

In my 2021 It was mentioned in an article that a full geth node is about 350GB (newly pruned). After about three years, a full geth node (on pbss) exceeds 900GB. The chart below shows the total cumulative volume of trades. It is easy to see that transaction volume has more than doubled in three years, from approximately 980 million transactions to over 2.2 billion transactions.

With the rise of L2, historical scale has become a bigger issue because the way they store data now (before 4844 came online) is calldata. Block 18418786 has a block size of over 427GB, and block 17419840 (also 4 months ago) has a block size of 339GB, which means a growth of 28GB in 4 months, which is approximately 9GB per month. We can extrapolate this growth as 427+(9*12*# years), which is 535GB after one year and 967GB after five years (again assuming linear growth).

Hopefully this growth will slow down after EIP-4844 goes live, at which point L2 will stop using CALLDATA for data availability and switch to using CALLDATA in a few weeks Expired blob.

EIP-4444 will solve the history growth problem because full nodes no longer need to store all history. Implementing EIP-4444 requires a reliable network to retrieve history before we can enable full nodes to stop serving history data.

(4) Synchronization time

Gas limit in many Aspects can affect synchronization time:

· Full synchronization becomes very slow, one geth node takes more than a week to fully synchronize the chain, and other clients Better full sync mode has been optimized.

· Synchronizing historical data is relatively slow. Because we need to download more data, the historical data synchronization part will be slower.

· Snapshot synchronization status is slower because we need to download more status.

· Snapshot recovery is slow. Since the pivot point moves during snapshot synchronization, we have a lot of incomplete state on disk that needs to be repaired. If the pivot moves more frequently and there are more changes per block, this repair phase will be slower.

· Since nodes need to go through more changes to form the block header, synchronization with the chain will be slower.

(5) Client Diversity

Build a The new EL client is a huge undertaking in itself. Increasing the gas limit has the additional disadvantage of making it more difficult to build clients and optimize them for mainnet use. Geth has been in development for over 10 years with extensive optimizations. There may be a counter-argument that new clients can learn from existing clients and not make the same mistakes again.

However, we have seen mainnet woes with two clients (Execution Specs written in python and EthereumJ written in javascript). This also means that clients written in certain languages ​​now won't work. Limited by language overhead and the maturity of the code base, increasing the gas limit will leave some clients behind.

We also see this with KZG, in order to get the required performance, most clients rely on calling C-KZG (a code written in C code base) rather than using a library written in their chosen language.

(6) Worst case scenario

Considering gas When limiting, we cannot just look at the general situation. We always have to consider the worst case scenario. Sure, the nodes may be running fine when the chain is under average load, but what happens if the disk I/O suddenly doubles for 5 blocks in a row?

Run time is not the only metric we need to consider. If an attacker can occupy other resources, such as disk I/O, CPU time or memory, they may Force lower configured machines offline. Especially after the Ethereum merger, running two clients on the same machine, attacking one client may also make the other client unstable. In the early days of Ethereum merge testing, we witnessed several situations where a memory leak in one client would crash the entire system.

Another worst-case scenario to consider is proof size. As the gas limit increases, the potential state changes that can occur between two blocks also increase. This has an impact on the snapshot synchronization discussed earlier, but it also affects the attestation size of the execution layer light client. Now this is not a big deal, the proof of the merkle-patricia tree is too big to be sent over the network. However, if we want to implement the cross-validation idea of ​​running multiple light clients on the same machine, then the proof size will be very important.

3, solution

Are we done? ? Will we always keep the 30MGas cap? no!

In one of my 2021 articles, I proposed a solution to the dilemma we faced at the time. For the full sync issues we face in 2021, geth implements snap sync and snapshots. For issues of pruning and database layout, geth implements PBSS. Txpool became more reliable in handling high transaction loads and most of the MEV front-running transactions were moved to builders. Many transactions have also been moved to L2, which in turn has increased the average size of mainnet transactions.

The only solution that has not been implemented is regenesis. Opinions have changed a bit over the years, and most people seem to be leaning toward the EIP-4444 historical period as a short-term solution to historical data growth. For the release of EIP-4444, we need a strong network of historical data serving nodes so that history is not lost even if it is no longer stored by all full nodes (BTW, most Bitcoin nodes do not store historical data at all) .

We still haven't found a decent, realistic way to limit status.

As you saw in the attack before the Shanghai upgrade, there are some known attacks that prevent us from increasing the gaslimit. All bugs (to my knowledge) have been resolved.

At the time of writing, EIP-4844 is being released on the testnet. This EIP will increase the node's storage and I/O requirements. In my opinion, waiting to see the impact of this change on mainnet is the safest thing to do before attempting any type of gas limit increase. Once L2 moves to blob transactions we should increase the calldata cost (because in my opinion calldata is underpriced compared to other things the data needs to be stored). This also serves as a mandatory function for L2 to use blobspace.

In short, I would like to remind everyone to be careful when considering increasing the gas limit, because it will affect many aspects of the node, and some effects will be relatively obvious. In related discussions, it is important to consider the long-term and short-term effects of gas limit changes.