jakiro
Author: John Otander, core Ethereum developer; Translation: Bitchain Vision xiaozou
This article was inspired by Ethereum’s often answers to Vitalik in recent Reddit AMA.
Vitalik pointed out that it is reasonable to increase Gas Limit moderately, and Gas Limit has not increased in nearly three years, which is the longest time in the history of the agreement.Vitalik also did some simple calculations to increase Ethereum Gas Limit to 40 million.
This article tells why it is difficult to improve Ethereum Gas Limit?Increase the risks posed by Ethereum Gas Limit, as well as related solutions.
1,Gas Limit(Gaslimit)
Gas limit determines the amount of work completed within a block, and therefore determines how many transactions can be executed per block.Improving gas limit will enable Ethereum to handle higher transaction throughput or more complex transactions.The specific gas limit settings have been affected by miners/stakeholders and the limit has been increasing over the years.The following figure is from etherscan.io, showing the historical gas usage (very close to gas limit, all limit increases have been digested by the market).
2,risk
Now increasing gas limit involves several risks.
(1) Leakage block rate
I mentioned in my previous article that the uncle rate is the most discussed indicator when evaluating the increase of gas limit.Now, after the Ethereum merger, there are no unblocks anymore.If we want to know whether the node can handle the current gas limit well, the only way is to see the missing block rate.But this metric is flawed because it only shows the currently undersupplied nodes.It doesn’t provide us with a good metric to show the increase in gas limit, and it only shows the average case, not the worst case that can happen in the attack.
(2) Status Size
The account snapshot of block 18418786 (October 24, 2023) is 10.33GB and the storage snapshot is 76.59GB, so the overall state is roughly 87GB.Block 17419840 (June 6, 2023) has a status of slightly less than 80GB.This means that the status has increased by about 7GB in 4 months, which means about 2GB per month.
If we use 87+ (2*12*# years) to infer, the status will be 111GB in one year and 207GB in five years.The problem here is not the size.Everyone can store so much data, but accessing and modifying this data will become slower and slower.
This is just a snapshot, it is a normal 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) of block 18418786 requires about 180GB.
Therefore, the total space size currently used for state storage is about 267GB.If we increase gas limit, the state size will grow faster.
The problem with state growth is that unlike in the past, we have no clear path to remove state.There are no specific state deadline suggestions that we can quickly implement to get us out of a growing state.
(3) Historical scale
In a 2021 article I mentioned that a full geth node is about 350GB (newly pruned).After about three years, a full getth node (on pbss) is over 900GB.The following figure shows the total accumulated volume of transactions.It is easy to see that transaction volume has more than doubled in three years, from about 980 million to more than 2.2 billion.
With the rise of L2, historical scale has become a bigger problem, as they now (before the 4844 goes live) the way they store data is called data.Block 18418786 has more than 427GB of block, while block 17419840 (also 4 months ago) has 339GB of block, which means 28GB growth in 4 months, which means about 9GB growth per month.We can use 427+ (9*12*# years) to infer this growth, i.e. 535GB after one year and 967GB after five years (again assume linear growth).
Hopefully, this growth will slow down after EIP-4844 is launched, when L2 will stop using CALLDATA to obtain data availability and switch to blobs that expire in a few weeks.
EIP-4444 will solve the historical growth problem, as full nodes no longer need to store all history.Implementing EIP-4444 requires a reliable network to retrieve history, and then we can make the full node stop historical data service.
(4) Synchronous time
Gas limit can affect synchronization time in many ways:
· Full synchronization becomes very slow. It takes more than a week for a getth node to fully synchronize the chain. Other clients have optimized a better fully synchronized mode.
·Simultaneous historical data is slow.Because we need to download more data, synchronizing the historical data part will be slower.
·The snapshot synchronization status is slower because we need to download more statuses.
·Snapshot recovery is slow.Since the pivot point moves during snapshot synchronization, we have many incomplete states on disk that need to be fixed.If pivot moves more frequently and there are more changes per block, then this repair phase will be slowed down.
· The synchronization with the chain will be slower because nodes need to pass more changes to form block headers.
(5) Client diversity
Building a new EL client is a difficult task in itself.There is an additional disadvantage of adding gas limit, which is that it will make it more difficult to build clients and optimize for use by the mainnet.Geth has been developed for more than 10 years and has undergone a lot of optimizations.There may be a opposite view that new clients can borrow from existing clients and no longer make the same mistakes.
However, we have seen the mainnet dilemma of two clients (Execution Specs written in python and EthereumJ written in javascript).This also means that clients written in certain languages are not working now.Due to language overhead and the maturity of the code base, adding gas limit will leave some clients behind.
We see this in KZG, and to get the required performance most clients rely on calling C-KZG (a code base written in C) rather than using libraries written in their chosen language.
(6) Worst case
When considering gas limit, we cannot just look at the general situation.We always have to consider the worst case scenario.Of course, nodes may run well when the chain is at an average load situation, but what happens if the disk I/O of 5 blocks suddenly doubles?
Runtime is not the only metric we need to consider, and if an attacker can take up other resources such as disk I/O, CPU time, or memory, they may force lower-configured machines to offline.Especially after Ethereum merger, running two clients on the same machine, attacking one of them may also make the other client unstable.In the early days of Ethereum merge testing, we have witnessed several times: a memory leak on one client would cause the entire system to crash.
Another worst-case scenario to consider is proof size.As gas limit increases, the potential state changes that may occur between the two blocks also increase.This has an impact on snapshot synchronization discussed earlier, but it also affects the proof 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 send over the network.However, if we want to implement the cross-validation idea of running multiple light clients on the same machine, then proof size is very important.
3, solution
Are we finished like that?Will we keep the upper limit of 30MGas?No!
In a 2021 article, I proposed solutions to the dilemma we were facing at that time.For the full synchronization problem we face in 2021, geth implements snapshot synchronization and snapshots.For pruning and database layout issues, geth implements PBSS.Txpool has become more reliable in handling high transaction loads, and most of the MEV rush transactions are transferred to builders.Many transactions have also moved to L2, which in turn has increased the average size of mainnet transactions.
The only solution that is not implemented is regenesis.Over the years, people’s views have changed a bit, and most people seem to be inclined to use the EIP-4444 historical deadline as a short-term solution to the growth of historical data.For the release of EIP-4444, we need a strong network of historical data service nodes so that history is not lost, even if it is no longer stored by all full nodes (by the way, most bitcoin nodes do not store historical data at all).
We still haven’t found a decent, realistic way to go for a state deadline.
As you saw the attacks before escalating in Shanghai, there are some known attacks that prevent us from raising gaslimit.(As far as I know) All vulnerabilities have been resolved.
At the time of writing, EIP-4844 is being published online.This EIP will increase the storage and I/O requirements of the node.In my opinion, it is safest to wait and see the impact of this change on the mainnet before trying any type of gas limit addition.Once L2 turns to Blob transactions, we should increase the calldata cost (because in my opinion the calldata is undervalued compared to other things that the data needs to be stored).This can also be used as a coercive function for L2 using blobspace.
In short, I would like to remind everyone to be careful when considering improving gas limit, because it will affect many aspects of the node, and some of the effects will be relatively obvious.In related discussions, it is very important to consider the long-term and short-term effects of gas limit changes.
