Consideration of Multiple Factors is Required when Adjusting Block Space Size: Gas Limit is not a Paramater that can be Adjusted Arbitrarily, says Core Developer
Ethereum Core Developer Marius Van Der Wijden’s Response to Vitalik’s Proposal to Increase Block Capacity
Summary:
Van Der Wijden believes that increasing the block capacity of Ethereum will bring many risks and should be carefully considered. He suggests waiting for the completion of the EIP-4844 upgrade.
Contents:
Toggle
Vitalik proposes increasing block capacity
Background Knowledge
Gas Limit
Node storage data
Risks of increasing Gas Limit
Expansion of state data size
Increase in historical data
Increase in node synchronization time
Decrease in client diversity
Other considerations
Are there any solutions?
Expectation for further technological development
Currently, it is more appropriate not to increase Gas Limit
Gas Limit needs to be treated with extreme caution
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, so a moderate adjustment is reasonable.
Advertisement – Continue reading below
(Reddit AMA | Vitalik Buterin calls for increasing Gas Limit to improve throughput)
The Gas Limit determines how many transactions a block can accommodate. Increasing the Gas Limit would allow Ethereum to process a higher transaction throughput or more complex transactions, thereby increasing block space.
Historically, the Gas Limit has been increasing over the years. The actual gas usage closely matches the Gas Limit changes, as almost every block is fully utilized by the market.
Gas usage history
(Data source)
Running a blockchain node requires storing data on the blockchain, which can be divided into two categories:
State data:
Current data, such as the current accounts, contracts, and token parameters on the network. For example, the number of tokens Alice currently owns and the number of Ethereum accounts.
Historical data:
Past data, which is the complete data outside of state data. It can be seen as the sum of past state data (but not directly aggregated). For example, transaction records of Alice transferring tokens to Bob at a certain moment.
State data ensures network consensus and needs to be constantly read during virtual machine operation to determine network efficiency. On the other hand, historical data is crucial for network security.
At block height 18,418,786 (October 24, 2023), the size of the account ledger snapshot is 10.33GB, and storing the snapshot requires 76.59GB, resulting in a total state size of approximately 87GB. At block height 17,419,840 (June 6, 2023), the Ethereum state was slightly smaller than 80GB.
This indicates that the state has grown by approximately 7GB in the past four months, with an average growth of nearly 2GB per month. At this rate, the network state size will reach 111GB within a year and 207GB in five years.
The problem lies not in the size of the network state itself, but in the access speed. Almost any device can store 200GB of data, but when the virtual machine modifies the state, more data needs to be reprocessed, resulting in slower access and modification speeds.
This is only the size of the plain state snapshot version. The Ethereum client Geth also needs to store the state in different forms (such as trie trees) to verify the state root. This data requires approximately 180GB at block height 18,418,786.
Therefore, the total space required for the state alone is about 267GB. If Gas Limit is increased, this size will grow faster, which is unfavorable for node operation.
The problem with state expansion is that there is currently no way to reduce it. Unlike historical records, which can be reduced through expiration or pruning, the state size cannot be easily reduced, just like it is impossible to arbitrarily discard account data.
State explosion: The continuous growth of state data size will affect the operational efficiency and scalability of the blockchain, and there is currently no good solution.
In addition to state data, don’t forget about historical data.
In February 2021, the storage size of a Geth node with complete historical data was about 350GB (after pruning), and it has already exceeded 900GB after three years. The number of accumulated Ethereum historical transactions has more than doubled in three years, from approximately 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 problem because Rollups store data in calldata. At block height 18,418,786, the size of calldata exceeds 427GB, which is 28GB larger than the size at block height 17,419,840 four months ago. The average monthly growth is 9GB.
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 the growth rate can be effectively slowed down in EIP-4844 because Layer2 will stop using calldata to achieve data availability and will transition to blobs that will expire weeks after the data is generated.
Regarding other historical data, the data expiration design proposed in EIP-4444 will address these issues, and full nodes will no longer need to store all historical records. However, implementing EIP-4444 requires a robust network to retrieve historical records and ensure sufficient data availability.
(Ethereum releases 2024 roadmap, continues to move forward with the world settlement layer)
Raising the Gas Limit will have multiple factors affecting the time required for node synchronization:
Full synchronization becomes slower: Currently, it takes more than a week for Geth nodes to fully synchronize the blockchain, but other clients have 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 snap healing: Since the network is still operating when the state is snapped, there will be some incomplete states that need to be repaired during state synchronization, and this repair process will become slower.
Slower catch-up speed: Because nodes need to make more changes to reach the latest state.
Creating 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 a counter-argument that new clients can learn from existing clients and do things better. However, two clients, including Execution Specs (built on Python) and EthereumJS (built on JavaScript), have encountered technical difficulties. Increasing the Gas Limit at this time will make it harder for these clients to keep up and may eventually lead to their disappearance, resulting in a lack of clients in certain languages and gradual centralization of clients.
This issue has also been observed recently during 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 preferred languages.
When considering changing the Gas Limit, it is not only necessary to consider normal situations but also the worst-case scenarios. If the network is not overloaded, nodes may work fine. But what happens if the transaction volume doubles for five consecutive blocks? How will the network perform in the next five 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 offline. This is especially true when two clients are running on the same computer, and attacking one client may destabilize the other.
Another consideration is proof size. As the Gas Limit increases, the state changes between two blocks should be more significant. 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 merkle-patricia proofs are 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 above risks, does it mean that we should always keep the current Gas Limit? Not necessarily. Technological progress may solve the above problems.
In the past in 2021, Ethereum faced many problems but gradually found solutions through technological development. The issue of full synchronization speed was addressed through the implementation of snapshot synchronization in Geth. Regarding pruning and database layout issues, Geth implemented PBSS, and Txpool became more powerful in handling high transaction volumes. The MEV issue was temporarily addressed by externally shifting 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 is regenesis. Currently, most people support EIP-4444, which adds a deadline for transaction information as a short-term solution to the growth of historical data.
However, the development team has not yet found a decent and practical way to prune state data, and it encourages anyone interested to join the Ethereum research in this area.
EIP-4844 is currently being tested on the test network and will increase node storage and I/O settings. Therefore, it is safest to consider any type of Gas Limit increase only after this change is completed on the main network.
Once the update is completed, the price of calldata should be increased as it is currently undervalued, and actions should be taken based on the situation. This can also encourage Layer2 to use blobspace.
In conclusion, when considering increasing the Gas Limit, caution is necessary as it affects many different aspects of node operations, 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 arbitrarily adjusted.
EIP-4444
EIP-4844
ethereum
gas
client
scaling
Further reading
EigenLayer connects Cosmos and Ethereum ecosystems, creating more value?
Ethereum releases 2024 roadmap, continues to move forward with the world settlement layer
