Author: Giulio Rebuffo Source: Erigon Translator: Shan Ouba, Jinse Finance
The discussion on increasing the Gas throughput of Ethereum is becoming more and more frequent, mainly through increasing the Gas limit or shortening the block generation time. The main argument supporting this claim is that the hardware requirements for running validator nodes have steadily declined over the past four years.
In addition, there are two proposals to increase the Gas limit:
EIP-7782: Reducing the block time of the Ethereum protocol
EIP-7783: Gradually increasing the Gas limit through a "progressive increase" mechanism
This article will analyze the potential performance of bandwidth, computation, and storage requirements in the worst-case and average-case scenarios if the Gas limit is doubled.
A Review of the History of Ethereum's Gas Limit
When Ethereum was launched in 2015, the Gas limit was initially set at 5,000 Gas per block. This limit has since undergone significant changes:
2016: The Gas limit was first increased to around 3 million, and then further increased to around 4.7 million.
After the Tangerine Whistle hard fork, especially with the implementation of EIP-150, the Gas limit was increased to 5.5 million. This adjustment was part of re-pricing certain I/O-intensive opcodes to address Denial of Service (DoS) attacks.
July 2017: The Gas limit was increased to 6.7 million and continued to rise:
December 2017: ~8 million
September 2019: ~10 million
August 2020: 12.5 million
April 2021: 15 million
According to EIP-1559, there is also a maximum (or "hard cap") Gas limit, set at twice the target. This means that a block can contain up to 30 million Gas worth of transactions.
The Gas limit has not been further increased in the past nearly four years.
Is it Time to Revisit the Gas Limit?
To answer this question, we need to analyze the performance of hardware requirements in terms of bandwidth, computation, and storage if the Gas limit is increased to 60 million.
Storage
When considering an increase in the Gas limit, storage is the biggest bottleneck and concern for the Ethereum network. This is due to the historical growth of the Ethereum state and the sustained pressure it puts on validators.
Ethereum has two types of growth:
State growth
Historical growth
State Growth
The Ethereum state, which is the collection of all account balances, smart contract code, and storage, continues to expand as transactions increase and smart contracts are deployed. Since Ethereum's inception, the state size has grown significantly, particularly driven by network congestion, increased transaction activity, and the rise of Decentralized Finance (DeFi) and Non-Fungible Tokens (NFTs). Currently, the state growth is around 2.5 GB per month, or 30 GB per year.
This state growth may lead to the following issues:
Slower disk access times
Increased hardware requirements
However, as of the time of writing, these issues are not particularly significant. The access time difference between storage systems is very small, as the algorithms used for queries typically have logarithmic complexity. Additionally, the storage requirements are not large, as the cost of new hardware is decreasing much faster than the 30 GB per year state growth. Even if the growth were to increase to 60 GB per year, this difference would not be particularly significant, as the technological progress of hardware would still outpace it.
Historical Growth
While the state size growth is a concern, technological progress has significantly reduced hardware costs, alleviating the pressure. Even if the Gas limit is doubled, hardware costs will continue to decline rapidly, making the required hardware increasingly affordable.
It is worth noting that individual stakers will soon need more than 2 TB of storage space to run an Ethereum validator node. This means they will effectively need 4 TB of storage space, as most hardware is sold in powers of 2. Therefore, Ethereum can fully utilize this additional storage space, as validators will need to purchase larger capacity hardware regardless of whether the Gas limit is increased.
Changes in Storage Costs
To demonstrate the exponential decline in storage costs, we can look at the price fluctuations of 1 GB SSD over the past four years. The data shows that the cost of 1 GB SSD roughly halves every two years.
Comparing this trend with the storage and state growth, the difference is very small. Ethereum's growth is currently linear, while hardware cost declines are exponential. This further reinforces the idea that increasing the Gas limit has a relatively small impact on hardware requirements.
Bandwidth
Ethereum's average bandwidth requirement is around 2MB/s; however, this figure is primarily driven by Consensus Layer (CL) data propagation and aggregation. When discussing an increase in the Gas limit, the only concern is the block size.
Currently, the recorded maximum block size is 270 KB, and the current block size after the Deneb upgrade is 75 KB. If this is doubled, the change is equivalent to adding 0.5-2 data blobs, which is an increase of around 2-5% in node bandwidth (input and output) compared to the historical maximum and current average. Therefore, in the average case, this is not a significant change. In fact, the impact of adding 3 blobs would be greater.
Worst-Case: Gas Limit Doubled
In the worst-case scenario, the block size is calculated to be 1.7MB, which would double to 3.4MB (a 50% increase in bandwidth demand). While this is not a small increase, it is still something to be aware of. The reason I don't consider this a large increase is that the cost of such a Denial of Service (DoS) attack would be quite high, and the 50% increase in bandwidth is equivalent to the current average demand, which is already within the consideration range. Additionally, filling a 15 million Gas block repeatedly is very expensive. Therefore, even if an attacker could launch a DoS attack over a few blocks, they would need to spend a significant amount of funds. Furthermore, they would have to compete with other transactions for block space, further increasing the attack cost.
Regardless of how one views these numbers, increasing the calldata cost can completely solve this problem, so I am not concerned about it. Furthermore, if the Gas limit is increased through EIP-7783, these risks are negligible and manageable.
Computation
Computation and block time have never been the issue, but let's take a look.
Average Case
The average block computation time is typically less than 1 second, even for poorly configured machines. Overall, this has never been a bottleneck.
Worst Case
The worst-case scenario is currently unclear and depends on the client. After discussions with some client teams, the consensus is that the only issue is the poor scalability of certain opcodes, such as MODEXP.
However, any DoS attack vectors here can be addressed by re-pricing, and if the Gas limit is increased through EIP-7783, these risks are negligible.
Conclusion
Overall, storage growth is not a bottleneck for increasing the Gas limit, as storage hardware is easy to upgrade. However, bandwidth is a greater threat, as bandwidth expansion is more difficult. Fortunately, through EIP-7783, the risks associated with bandwidth and potential computational increases can be effectively mitigated. Nevertheless, it may be wise to reprice the calldata cost to ensure additional security (although I personally believe this is not necessary).
Personally, I believe that the Gas limit can be increased by 33%, or even doubled, under the gradual increase mechanism of EIP-7783.
Raising the limit through EIP-7782 may be premature, as this could have adverse effects on Distributed Verification (DVT) and SSF. However, once these issues are resolved, shortening the block generation time will undoubtedly be a future trend.
