Ethereum core developer Marius Van Der Wijden provides insights on Vitalik’s proposal to increase the block capacity
Summary
There are various considerations to take into account when considering increasing the block capacity of Ethereum. Van Der Wijden believes that raising the block capacity could bring many risks and therefore, it is necessary to think carefully about this decision. He suggests waiting for the completion of the EIP-4844 upgrade.
Table of Contents
Toggle
Vitalik proposes increasing the block capacity
Background knowledge
Gas Limit
Node storage data
Risks of increasing Gas Limit
Expansion of state data size
Increase in historical data
Increased node synchronization time
Decreased client diversity
Other factors to consider
Are there any solutions?
Hoping for further technological development
Currently, it is more appropriate not to increase the Gas Limit
Gas Limit needs to be carefully considered
Ethereum founder Vitalik Buterin proposed increasing the current Gas Limit of Ethereum from 3 million to 4 million during the Ethereum Foundation’s Reddit AMA event. This represents a 33% increase and is expected to effectively improve Ethereum’s network throughput.
Vitalik also mentioned that Ethereum has not adjusted this parameter for three years and that it is reasonable to make appropriate adjustments.
Advertisement – Please scroll down for the rest of the content
(Reddit AMA | Vitalik Buterin proposes increasing Gas Limit to improve throughput)
The Gas Limit determines how many transactions a block can complete. Increasing the Gas Limit would allow Ethereum to process higher transaction throughput or more complex transactions, which means increasing the block space.
Looking at the history, the Gas Limit has been increasing for many years. The Gas Limit changes closely match the historical gas usage because almost every block is fully utilized by the market.
Historical gas usage
(Data source)
Running a blockchain node requires storing data on the blockchain, but the data can be divided into two categories:
State data:
Current data, such as the current accounts, contracts, and token parameters in the network. For example, how many tokens Alice currently owns and how many accounts Ethereum currently has.
Historical data:
Past data, which is the complete data excluding the state data. It can be imagined as the sum of past state data (but not directly added together). For example, the transaction record of Alice transferring tokens to Bob at a certain moment.
State data ensures consensus in the network and is constantly read during virtual machine operation, which determines the efficiency of the network. On the other hand, historical data is crucial to ensuring network security.
At block height 18,418,786 (October 24, 2023), the size of the account ledger snapshot is 10.33 GB, and the storage of snapshots is 76.59 GB, resulting in an overall state size of approximately 87 GB. At block height 17,419,840 (June 6, 2023), the Ethereum state was slightly less than 80 GB.
The state has grown by approximately 7 GB in the past four months, averaging nearly 2 GB per month. At this rate, the network state size will reach 111 GB within a year and 207 GB in five years.
The problem is not the size of the network state itself, but the access speed. Almost any device can store 200 GB of data, but the more data the virtual machine needs to regrasp when modifying the state, the slower the access and modification speed will become.
This is only the size of the plain state snapshot version. Ethereum client Geth also needs to store the state in different forms (such as trie trees) to verify the state root. These data require approximately 180 GB at block height 18,418,786.
Therefore, the current total space required for the state alone is approximately 267 GB. If the Gas Limit is increased, this size will grow faster, which is detrimental to the operation of nodes.
The problem with state expansion is that there is currently no way to reduce it. Unlike historical records, which can be reduced in size through expiration or pruning, the state size cannot be easily reduced, just like it is not possible to arbitrarily discard account data.
State Explosion: The continuous growth of state data size will affect the performance and scalability of the blockchain, and there is currently no good solution.
In addition to state data, we must not forget about historical data.
In February 2021, the storage size of a Geth node with complete historical data was approximately 350 GB (trimmed), and it has exceeded 900 GB after three years. The accumulated number of historical transactions on Ethereum has more than doubled in three years, from about 980 million to 2.2 billion transactions.
Accumulated number of Ethereum transactions
(Data source)
With the rise of Layer2, the growth rate of historical records has become a bigger issue because Rollups store data in calldata format. Its size exceeded 427 GB at block height 18,418,786, and four months ago, it was 339 GB at block height 17,419,840, with an average monthly growth of 9 GB.
However, historical data is different from state data, and there have been many attempts to reduce the growth of historical data.
It is hoped that with EIP-4844, this growth rate can be effectively slowed down because Layer2 will stop using calldata to achieve data availability and transition to blobs that will expire weeks later.
As for other historical data, the data expiration design proposed in EIP-4444 will solve these problems, and full nodes will no longer need to store all historical records. However, implementing EIP-4444 requires a powerful network to retrieve historical records and ensure sufficient data availability.
(Ethereum releases 2024 roadmap, continues to move towards a world settlement layer)
Increasing the Gas Limit will have multiple factors affecting the time required for node synchronization:
Slower full synchronization: Currently, Geth nodes take more than a week to fully synchronize the blockchain, but other clients have already optimized this issue.
Slower synchronization of historical data: When nodes initially synchronize historical data, they need to download more data.
Slower synchronization of state data: More data needs to be downloaded each time a node snapshots the state.
Slower snapshot healing: Since the network is still operating when the state is snapshot, there are some incomplete states that need to be repaired during state synchronization, which slows down the repair process.
Slower catching up: Nodes need to make more changes to reach the latest state.
Building new execution layer clients (EL clients) is already a challenging task, and increasing the Gas Limit will make it even more difficult to create new clients or update existing ones.
However, there is also an argument that new clients can learn from existing clients and do things better. However, there have been difficulties encountered in the development of two clients, Execution Specs (built on Python) and EthereumJS (built on JavaScript). Increasing the Gas Limit at this time will make it more difficult for these clients to keep up and eventually disappear, making the ecosystem unable to use clients in certain languages, resulting in gradual centralization of clients.
This issue has also been observed recently in the introduction of KZG. To achieve the required performance, most clients rely on calling C-KZG (a library written in C) instead of using libraries written in their chosen languages.
When considering changing the Gas Limit, it is not enough to only consider the usual situations. The worst possible scenarios also need to be taken into account. What will happen if the network is not overloaded and suddenly the transaction volume doubles for five consecutive blocks? How will the network perform in the next 5 seconds?
Runtime is not the only indicator to consider. If an attacker can occupy other resources such as disk I/O, CPU, or memory, it may force nodes with lower hardware configurations to go offline. This is especially true when two clients are running on the same computer, and attacking one client may cause instability in another client.
Another factor to consider is the proof size. As the Gas Limit increases, the difference between state changes between two blocks should be greater. This not only affects snapshot synchronization, as discussed earlier, but also affects the verification of light clients. Currently, this is not a big problem because the proof size of merkle-patricia is already too large to be sent over the network. However, if we want to achieve cross-verification of multiple light clients running on the same machine, proof size becomes important.
After considering the risks mentioned above, does it mean that we should always keep the current Gas Limit? Not necessarily. Technological advancements may solve these problems.
In the past in 2021, Ethereum faced many issues, but they were gradually resolved through technological development. The problem of full synchronization speed was addressed by Geth’s implementation of snapshot synchronization. The issues of pruning and database layout were solved by Geth’s implementation of PBSS. Txpool became more powerful in processing high transaction volumes. The MEV problem was temporarily resolved by external designs that moved transactions to builders, and now many transactions have moved to Layer2, successfully increasing the overall network performance.
The only solution that has not been implemented yet is regenesis. Currently, it seems that most people agree with EIP-4444, which sets a deadline for transaction information, as a short-term solution to the growth of historical data.
However, the development team has not found a decent and practical way to trim the state data, and encourages anyone interested to join the research related to Ethereum in this aspect.
EIP-4844 is currently being tested on the test network and will increase node storage and input/output settings. Therefore, it is safest to consider any type of Gas Limit increase after this change is completed on the mainnet.
Once the update is completed, the price of calldata should be underestimated, and its usage cost should be increased before taking any further action. This can also encourage the use of blobspace by Layer2.
In conclusion, caution should be exercised when considering increasing the Gas Limit, as it affects many different aspects of the nodes, some of which are important and require consideration of both short-term and long-term impacts. Gas Limit is not a parameter that can be adjusted arbitrarily.
EIP-4444
EIP-4844
ethereum
gas
clients
scaling
Related reading
EigenLayer connects the Cosmos and Ethereum ecosystems, creating more value?
Ethereum releases 2024 roadmap, continues to move towards a world settlement layer