Core developer: Adjusting block space size requires consideration of multiple factors, and Gas Limit is by no means a parameter that can be adjusted arbitrarily.

Ethereum core developer Marius Van Der Wijden has provided additional considerations regarding Vitalik's proposal to increase block capacity, suggesting that raising Ethereum's block capacity further could introduce many other risks that need to be carefully considered. He recommends waiting for the completion of the EIP-4844 upgrade at the very least. More details.

Vitalik Proposes Increase in Block Capacity

Ethereum founder Vitalik Buterin proposed to raise the current Gas Limit on Ethereum from 3 million to 4 million during a Reddit AMA event held by the Ethereum Foundation, representing a 33% increase. This adjustment is expected to effectively enhance Ethereum's network throughput.

Vitalik also mentioned that Ethereum has not adjusted this parameter for three years, making it reasonable to make appropriate adjustments.

Reddit AMA｜Vitalik Buterin Calls for Gas Limit Increase to Improve Throughput

Background Information

Gas Limit

The Gas Limit, which determines how many transactions a block can accommodate, increasing the Gas Limit will enable Ethereum to handle higher transaction throughput or more complex transactions, thereby increasing block space.

Historically, the Gas Limit has been increasing over the years. The change in Gas Limit closely mirrors historical gas usage, as almost every block is fully utilized by the market.

Node Data Storage

Nodes running the blockchain need to store data on the blockchain. Data can be categorized into:

• State data: Current data, such as the network's accounts, contracts, token parameters. For example, how many tokens Alice currently owns, or the current number of Ethereum accounts.
• History data: Past data beyond state data, which can be considered as a sum of past state data but not directly additive. For example, transaction records of Alice transferring tokens to Bob at a certain point in time.

State data ensures network consensus and is crucial for the efficiency of the virtual machine operation. On the other hand, history data is vital for network security.

Risks of Increasing Gas Limit

State Data Size Expansion

At block height 18418786 on 10/24/2023, the size of the account ledger snapshot is 10.33 GB, while the storage snapshot is 76.59 GB, resulting in an overall state size of about 87 GB. Comparatively, at block height 17419840 on 6/6/2023, Ethereum's state was slightly under 80 GB.

This indicates that the state has grown by approximately 7 GB in the past four months, averaging almost 2 GB per month. At this rate, the network state size will reach 111 GB within a year and 207 GB in five years.

Most devices can store 200 GB of data, but as the amount of data to be reprocessed by the virtual machine increases with every state modification, access and modification speeds will gradually slow down.

This is only the size of the plain state snapshot version; Ethereum clients like Geth need to store state in different forms, such as trie trees, to verify the state root. This data requires around 180 GB at block height 18418786.

Therefore, the total space currently required for state alone is approximately 267 GB. Increasing the Gas Limit will cause this size to grow even faster, hindering node operations.

The issue with state expansion lies in the lack of ways to reduce it. Unlike historical records that can be reduced through expiration or pruning, the state size cannot be easily reduced, similar to being unable to discard account data at will.

State Explosion: The continuous growth of state data will affect the operational efficiency and scalability of the blockchain, and there is currently no good solution.

Increasing Historical Data

In addition to state data, historical data should not be overlooked.

In February 2021, storing complete historical data on a Geth node required about 350 GB, which has now exceeded 900 GB after three years. Ethereum's accumulated historical transaction count has more than doubled in three years, going from around 980 million transactions to 2.2 billion transactions.

With the rise of Layer2 solutions, the growth rate of historical records has become a more significant issue. Rollups store data using calldata, which exceeded 427 GB at block height 18418786, up from 339 GB four months ago at block height 17419840, growing by 28 GB, an average of 9 GB per month.

Unlike state data, there are already many attempts to reduce the growth of historical data.

It is hoped that this growth rate can be effectively slowed down in EIP-4844, as Layer2 will stop using calldata for data availability and move to Blobs that expire weeks later.

Regarding other historical data, the data expiration design proposed in EIP-4444 will address these issues, eliminating the need for full nodes to store all historical records. However, implementing EIP-4444 requires a robust network to retrieve historical records to ensure sufficient data availability.

Ethereum Releases 2024 Roadmap, Continues Advancing Toward a World Settlement Layer

Increased Node Synchronization Time

Increasing the Gas Limit will affect the time required for node synchronization due to multiple factors:

• Full synchronization becomes slower: Currently, Geth nodes require over a week to fully synchronize the blockchain, although other clients have optimized this issue more effectively.
• Decreased speed in syncing historical data: Nodes require more data to download when initially syncing historical data.
• Decreased speed in syncing state data: More data needs to be downloaded each time a node snaps the state.
• Slower snapshot repair (snap healing): As the network operates while the state is snapped, there are some incomplete states that need to be repaired during the state synchronization process, which becomes slower.
• Slower catch-up speed: Nodes need to make more changes to reach the latest state.

Decreased Client Diversification

Establishing new execution layer clients (EL clients) has always been a challenging task. Increasing the Gas Limit would make it more difficult to create new clients or updates.

However, a counterargument is that new clients can learn from existing clients to improve. Yet, challenges have been encountered by two clients, including Execution Specs built on Python and EthereumJS built on JavaScript, which have faced technical difficulties. Increasing the Gas Limit at this point would make it harder for these clients to keep up, potentially leading to their disappearance and the ecosystem losing the ability to use clients in certain languages, ultimately resulting in gradual client centralization.

Similar issues were observed in the process of introducing KZG, where to achieve the required performance, most clients relied on calling C-KZG, a library written in C, rather than using libraries written in their originally chosen languages.

Other Considerations

When considering changing the Gas Limit, one should not only consider normal circumstances but also think about worst-case scenarios.

While the network may operate well when not overloaded, what would happen if transaction volume suddenly doubled for five consecutive blocks? How would the network perform in the next 5 seconds?

Runtime is not the only metric to consider; if an attacker can occupy other resources like disk I/O, CPU, or memory, it may force nodes with lower hardware configurations offline. Particularly after merging, running two clients on the same machine, attacking one client might destabilize the other.

Another consideration is proof size. As the Gas Limit increases, the difference between the states of two blocks should increase. This will not only affect snapshot syncing, as discussed earlier, but also impact light client verification. While this is not a significant issue now due to the large size of merkle-patricia proofs that cannot be sent over the network, it becomes crucial if aiming to run multiple light clients for cross-verification on the same machine.

Are There Solutions?

Expect Further Technological Development

After reviewing the risks mentioned above, does it mean we must always maintain the current Gas Limit? Not necessarily; technological advancements may solve these issues.

In 2021, Ethereum faced many challenges, gradually resolved through technical developments. The issue of full synchronization speed was addressed by Geth implementing snapshot sync, while trimming and database layout problems were tackled by Geth implementing PBSS. Txpool became more robust in handling high transaction volumes, and the MEV issue was temporarily addressed by externally designing transactions to be moved to builders. Many transactions have now shifted to L2, successfully enhancing the overall network performance.

The only solution yet to be implemented is regenesis. Currently, most people seem to support EIP-4444, which adds expiration settings to transaction information as a short-term solution to historical data growth.

However, the development team has not yet found a decent and practical way to trim state data, encouraging anyone interested to join the Ethereum research in this area.

Postponing Gas Limit Increase for Now is More Appropriate

EIP-4844 is currently being tested on the test network, which will increase node storage and I/O settings. Therefore, waiting for this change to be completed on the mainnet before considering any Gas Limit increases is the safest option.

Once the update is complete, if calldata pricing is undervalued, its usage cost should be increased first, adjusting as needed. This can also prompt Layer2 solutions to use blobspace.

Exercise Extreme Caution with Gas Limit

In conclusion, extreme caution should be exercised when considering increasing the Gas Limit, as it affects many different aspects of nodes, some of which are crucial. Both short-term and long-term impacts need to be considered, as Gas Limit is not a parameter that can be adjusted casually.