Translator's Note

Recently, there has been a lot of discussion in the Ethereum community regarding block size and gas limits. This is largely due to Vitalik Buterin mentioning the idea of increasing the gas limit by 33% to 40 million during a recent EF Reddit AMA.

However, are we ready to increase the block size? From an economic perspective, Ethereum's block size is influenced by multiple factors, and each change in these factors will result in a different increase in block size.

This article first explains the definition of block size (the gas limit we usually talk about is different but closely related to the block size measured in bytes). Then, under certain assumptions, it provides a calculation of the worst-case scenario for block size (referring to how large a block can be). Based on this calculation, it analyzes the impact of different variables on block size: gas limit, calldata pricing, and the impact of adding blob transactions on block size.

Block size is closely related to network security and decentralization. The impact of increasing block size is not singular, and better decisions can be made through multi-faceted analysis of variables and trade-offs.

Article by Toni Wahrstätter

Translated by Franci

There has been a lot of discussion recently about increasing the Ethereum block gas limit. Some people advocate for increasing the block size based on Moore's Law, while others rely on personal intuition, spread rumors casually, or worry that other chains like Solana will surpass Ethereum in widespread adoption.

Next, I would like to present some charts and data that may help us make a decision to maximize the gas limit without affecting Ethereum's decentralization.

Starting from the Beginning

Unlike Bitcoin, Ethereum does not have a fixed block size limit but relies on a flexible block size mechanism measured in a unit called "gas." In Ethereum, Gas is a unit that measures the computational effort required to execute operations (such as transactions or smart contracts). Each operation in Ethereum requires a certain amount of Gas to complete, and each block has a gas limit that determines how many operations a block can contain.

Initially, in 2015, Ethereum had a limit of 5,000 Gas per block. This limit was quickly raised to about 3 million, and then later in 2016 to about 4.7 million. With the implementation of the Tangerine Whistle hard fork (EIP-150) in 2016 as a response to DoS attacks, the gas limit was raised to 5.5 million by repricing various IO-intensive opcodes. After these attacks, miners continued to raise the gas limit, reaching about 6.7 million in July 2017, about 8 million in December 2017, about 10 million in September 2019, 12.5 million in August 2020, and finally to about 15 million on April 3, 2021.

Gas usage over time

Subsequently, with the activation of the Spurious Dragon, Byzantium, Constantinople, Istanbul, and Berlin hard forks, the pricing of certain opcodes was further refined. Examples of these refinements include EIP-145, EIP-160, EIP-1052, EIP-1108, EIP-1884, EIP-2028, EIP-2200, EIP-2565, and EIP-2929.

The most significant change in Ethereum's fee market occurred with the introduction of the London hard fork (EIP-1559) in August 2021. EIP-1559 introduced the base fee, which dynamically adjusts based on demand for block space over time/block height. It also introduced the "target size," set at 15 million gas per block, to guide the dynamic adjustment of the base fee. If the total gas used in a block exceeds this target, the base fee for the next block increases. Conversely, if the total gas used is below the target, the base fee decreases. This mechanism aims to create a more predictable fee market and improve user experience by stabilizing transaction costs. Additionally, EIP-1559 introduced a mechanism to burn the base fee, permanently removing that portion of Ether from circulation. This enhances the protocol's sustainability and creates the so-called "ultrasound money meme."

Under EIP-1559, there is also a maximum (or "hard") gas limit set at twice the target, i.e., 30 million gas. This means a block can pack transactions with a total usage of up to 30 million gas.

Gas usage after the London fork

Since then, Ethereum's block gas limit has remained unchanged, still at 30 million gas per block as of 2024.

Are We Ready to Increase the Block Size?

Recently, some people have expressed concerns about Ethereum's gas limit and have called for its increase. In the latest Ethereum Foundation AMA on Reddit, Vitalik mentioned considering the idea of increasing the gas limit by 33% to 40 million. His reasoning is based on Moore's Law, which states that the number of transistors on a microchip roughly doubles every two years, leading to a corresponding increase in computational power. This principle suggests that network performance, including the capacity to process and execute transactions, can also increase over time.

Researcher Dankrad and Ansgar from the Ethereum Foundation also support the idea of increasing the gas limit after evaluating the situation post-Dencun upgrade. Additionally, Pari from the Ethereum Foundation published a post exploring potential ways to increase the gas limit. Others like Geth's Peter and Marius have expressed concerns about increasing the gas limit, especially in the absence of proper tools/monitoring. These concerns are mainly related to issues such as accelerated state growth, sync time, and block reorg rate.

What Is Block Size?

Block size can be measured in two ways:

• Gas usage
• Block size (in bytes)

Although these two measurements are related, they must be considered independently.

For example, a block containing many non-zero calldata bytes may be large in terms of bytes, but the actual gas usage (16 gas per non-zero byte) may still be relatively small.

Without considering compression, the maximum block size currently achievable, while adhering to Geth's 128 KB limit per transaction, is approximately 6.88 MB. This block would maximize the number of transactions packed into 128 KB. The actual calculated result is a block containing about 130,900 bytes of zero calldata (4 gas per byte) for 55 transactions, and one transaction filling the remaining space. However, after snappy compression, the final size of such a block is approximately 0.32 MB, which can be negligible.

In another scenario, considering the maximum potential block size, a block containing 15 transactions with non-zero calldata, after compression, can reach approximately 1.77 MB.

Therefore, as of today, 1.77 MB represents the real block size limit for execution layer blocks.

Translator's Note:

In the paragraphs above, the author attempts to calculate the maximum block size under the condition of a fixed gas limit of 30 million, in order to maximize the block size. If the gas limit is fixed and the goal is to increase the block size, the only option is to pack calldata (because bytecode operations like calculation/STORE do not consume block storage space). Therefore, to increase the block size, the goal is to pack as much calldata into transactions as possible. There are two methods: "pack 0 calldata" and "pack non-zero calldata," and a calculation is needed to determine which method can result in a larger block size. The final result is that "pack non-zero calldata" results in a larger block size.

Based on the premise of Geth client's limit of 128 KB per transaction, the author proceeds to calculate two examples.

Case 1: 56 transactions with a size of 130,900 B (128 KB) each (all containing zero calldata, 4 gas/B): Gas used = 56 * (130,900 * 4 + 21,000) = 30,497,600 > (30 M), so at most, only 55 of the above transactions + 1 smaller transaction can be packed. The corresponding block size is approximately 55 * 128 = 7,040 kB = 6.875 MB. However, since all calldata is 0, the compressed block size is approximately 0.32 MB.

Case 2: 15 transactions with a size of 130,900 B (128 KB) each (all containing non-zero calldata, 16 gas/B): Gas used = 15 * (130,900 * 16 + 21,000) = 31,731,000 > 30 M. The corresponding block size is approximately 14 * 128 = 1,792 kB = 1.75 MB ~ 15 * 128 = 1.875 M. However, since the calldata is non-zero, it is not easily compressible, so the compressed block size is approximately 1.77 MB.

In terms of the maximum block size, we can identify several factors that influence it:

• Gas Limit: The gas limit will affect the maximum block size, which is undeniable. The higher the limit, the more data can be packed into the block.
• Pricing of Operations and Data: Cheaper gas for operations allows more operations to be executed within a block. While operations like CALLDATALOAD or CALLDATACOPY have a cost of 3 Gas, relatively cheap, other opcodes like CREATE are more expensive. The more expensive the opcodes used in a block, the less space is available for calldata (or other operations).
• Client Limit: Although the impact of the client limit is not as obvious, for example, a client like Geth limiting each transaction to 128 KB can also affect the final block size. Since the fixed cost per transaction is 21k Gas, a lower client limit for transaction size requires more frequent payment of the fixed cost, "wasting" gas that could have been used for calldata. Ultimately, this limit can lead to a reduction in the maximum block size by approximately 0.07 MB. It is important to note that the client limit only affects transaction broadcasting and does not affect confirmed blocks.

First, let's take a look at the gas limit for each block:

Impact of Block Gas Limit on Maximum Block Size

For blockchains like Ethereum, increasing the block gas limit is the most direct and obvious way to increase capacity. A higher limit means more data space. As shown in the above image, the block size in the "worst-case scenario" (i.e., the maximum block size calculated earlier) is roughly linearly related to the increase in the block gas limit. By creating blocks packed with as many non-zero byte calldata transactions as possible, this maximum block size can be achieved.

Next, let's look at another influencing factor — Ethereum's pricing mechanism. In the current example, it specifically refers to the current cost set at 16 Gas for non-zero byte calldata:

Impact of Cost per Non-Zero Byte Calldata on Maximum Block Size

As shown in the image above, increasing the cost for non-zero calldata reduces the block size. In other words, reducing the cost to, for example, 8 Gas per byte would double the maximum block size in the worst-case scenario. This is intuitive, as lowering the price allows double the amount of data to be placed in the block.

What about the launch of EIP-4844 (Proto-Danksharding)?

I won't go into detail about 4844 here, as there is excellent documentation on eip4844.com, but in simple terms, EIP-4844 introduces a data type similar to a "sidecar" structure, called a blob, which can hold approximately 125 kb of data. The cost mechanism for blob data is similar to EIP-1559, with a "target" used to anchor the number of blobs. In the Dencun hard fork, the target is set at 3 blobs per block, with a maximum limit of 6 blobs per block. It is worth noting that blobs have their own fee market, creating a so-called multi-dimensional fee market. This means that blobs do not have to compete with standard transactions but are decoupled from the fee mechanism under EIP-1559.

So far, everything is going smoothly. Let's see how this upgrade affects the average block size of Ethereum.

Impact of Adding Blobs on Compressed Beacon Chain Average Block Size

As of today, the average block size of the compressed beacon chain blocks is approximately 125 KB. With 4844, we can add an additional 375 KB to each block, resulting in a fourfold increase in the current average block size. If the maximum number of blobs is reached, we effectively increase the current block size by seven times.

The worst-case scenario block size increases from approximately 1.77 MB to approximately 2.5 MB. This estimate does not take into account the consensus layer (CL) portion of the block. However, in any case, we must be prepared to handle this maximum block size in the event of a DoS attack.

Conclusion

Ultimately, if we want to increase the current block gas limit, thorough research and analysis are needed before implementation. While mature entities like Coinbase, Binance, Kraken, or Lido node operators can handle a gas limit exceeding 40 million, independent stakers may find it more challenging.

Therefore, such a decision must be carefully considered to ensure that we do not sacrifice decentralization.

Finally, building something with large capacity and strong performance like Facebook is relatively easy, but what's important is not to lose what most of us are pursuing: decentralization.

The code for the calculations and charts mentioned above can be found here.

Related Links

Design Logic of EIP-4844 under Modular Structure

• EIP-4488: Transaction calldata gas cost reduction with total calldata limit
• Vitalik's comments on this article: Twitter
• EIP-150 in 2016, Gas cost changes for IO-heavy operations
• EIP-1559: Fee market change for ETH 1.0 chain
• Ultra Sound Money Meme
• Ethereum Foundation 11th AMA
• Testing path for a gas limit increase
• EIP-4844: SHARD BLOB TRANSACTIONS, Proto-Danksharding
• Multidimensional EIP-1559
• Code for the chart analysis in this article: eth-gas-limit-analysis

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。