About block size: Gas caps and scalability

Author: Toni Wahrstätter

There has been a lot of discussion recently about increasing the gas limit for Ethereum blocks. Some advocate for increasing block sizes based on Moore's Law, some based on personal intuition, some just spreading the word, and still others worried that other chains like Solana will overtake Ethereum in terms of widespread user adoption.

Next, I want to show some charts and data, which may help us make a premise without affecting the decentralization of Ethereum. Make the decision to maximize the gas limit.

Start from the beginning

Unlike Bitcoin, Ethereum does not There is a fixed block size limit, but instead relies on a flexible block size mechanism that is measured in some unit of "gas". In Ethereum, Gas is a unit that measures the amount of computation required to perform an operation, such as a transaction or smart contract. Every operation in Ethereum requires a certain amount of Gas to complete, and each block has a Gas cap, which determines how many operations a block can contain.

In the beginning, in 2015, Ethereum had an upper limit of 5,000 Gas per block. That cap was quickly raised to about 3 million, and then to about 4.7 million later in 2016. With the Tangerine Whistle hard fork (EIP-150) implemented in 2016 as a response to DoS attacks, the gas cap was increased to 5.5 million by repricing various IO-intensive opcodes. After these attacks, miners continued to increase the Gas limit, to about 6.7 million in July 2017, to about 8 million in December 2017, to about 10 million in September 2019, and to about 10 million in August 2020. ; to 12.5 million, and ultimately to approximately 15 million on April 3, 2021.

Since then, pricing for certain opcodes has been further refined with the activation of Spurious Dragon, Byzantium, Constantinople, Istanbul and Berlin hard forks. 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 the Ethereum fee market occurred with the introduction of the London hard fork (EIP-1559) in August 2021. EIP-1559 introduces a base fee that dynamically adjusts over time/block height based on demand for block space. A "target size" was also introduced, setting it to 15 million Gas per block. This target is used to guide the dynamic adjustment of the base fee. If the total amount of Gas used in a block exceeds this target, the base fee for the next block will increase. Conversely, if the total amount of gas used is less than the target, the base fee is reduced. This mechanism aims to create a more predictable fee market and improve user experience by stabilizing transaction overhead. In addition, EIP-1559 also introduced a base fee destruction mechanism, permanently removing that part of Ether from circulation. This enhances the sustainability of the protocol while creating the so-called ultra sound money meme.

Under EIP-1559, there is also a maximum (or "hard cap") Gas limit, which is set to twice the target, which is 30 million Gas. This means that a block can package transactions with a total usage of up to 30 million Gas.

Since then, Ethereum’s block gas cap has remained unchanged, and as of 2024, it is still 30 million gas per block.

Are we ready to increase the block size?

Recently, some people have expressed concerns about Ethereum's gas limit and requested that it be increased. In the latest Ethereum Foundation AMA on Reddit, Vitalik said he was considering the idea of ​​increasing the gas cap by 33% to 40 million. His reasoning is based on Moore's Law, which states that the number of transistors on a microchip doubles approximately every two years, allowing for a corresponding increase in computing power. This principle suggests that network performance, including the ability to process and execute transactions, can also increase over time.

Researchers Dankrad and Ansgar from the Ethereum Foundation also support the idea of ​​increasing the gas cap after evaluating the situation after the Dencun upgrade. Additionally, the Ethereum Foundation’s Pari published a post exploring potential ways to increase the gas cap. Others like Geth's Peter and Marius have expressed concerns about increasing the gas cap, especially without the proper tooling/monitoring in place. These concerns are primarily related to issues such as accelerated state growth, synchronization time, and reorganization block rates.

What is the block size?

Block size can be measured in two ways:

Gas usage

Block size in bytes

Although these two measures are related , but must be considered independently.

For example, a block containing many non-zero calldata bytes may be large in byte size, while the actual Gas usage (per non-zero word section requires 16 Gas) which is probably still relatively small.

Disregarding the compression situation for now, subject to Geth's 128 KB limit for each transaction, the current maximum block that can be achieved Size is approximately 6.88 MB. Such a block will maximize the number of 128 KB transactions packed into it. This actually works out to 55 transactions containing about 130,900 bytes of zero-byte calldata (4 Gas per byte), and one transaction that fills the remaining space. However, after snappy compression, the final size of such a block is about 0.32 MB, which is negligible.

In another case, considering the maximum possible block size, including 15 transactions carrying non-zero byte calldata, the compressed size can reach approximately 1.77 MB.

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

Translator's Note:

In the above paragraphs, With a fixed upper gas limit of 30 M, the author wants to maximize the block size and tries to calculate the maximum size of the block that can be filled.

If you fix the upper limit of gas and make the block size larger, you can only stuff calldata (because bytecodes such as calculation/STORE will not actually be consumed block storage space).

So, to make the block larger, it is nothing more than to fill the transaction with calldata as much as possible. Then, there are two methods: "plug 0 calldata" and "plug 0 calldata". It requires calculation to know which one can make the block size larger. The end result is that the block size of "Sephi0 calldata" is larger.

Based on the premise that the Geth client limits each transaction to a maximum of 128 KB, two examples are calculated below.

case 1: 56 transactions of size 130,900 B (< 128 KB) (all with zero calldata, 4 gas/B): The gas used = 56* (130,900 * 4+21000) = 30497600 > (30 M), so only 55 of the above transactions + 1 transaction smaller than the above transaction can be inserted at most. The corresponding block size is approximately 55*128 = 7040 kB = 6.875 MB. However, since calldata is all 0s, the compressed block size is about 0.32 MB.

case 2: 15 transactions of size 130,900 B (< 128 KB) (all with non-zero calldata, 16 gas/B): Gas used = 15 *(130900 *16+21000) = 31731000 > 30 M. The corresponding block size is approximately 14 *128 = 1792 kB = 1.75 MB ~ 15 * 128 = 1.875 M. However, since the calldata is non-zero, it is not easy to compress, so the compressed block size is about 1.77 MB. )

In terms of this maximum block size, we can identify several factors that affect it:

Gas cap: There is no doubt that the gas cap will affect the maximum block size. The higher the limit, the more data can be crammed into the block.

Pricing of operations and data: The cheaper the gas for an operation, the more operations can be performed within a block. Although operations like  CALLDATALOAD  or CALLDATACOPY  cost 3 Gas and are relatively cheap; other opcodes such as < code>CREATE is more expensive. The more expensive the opcodes used in a block, the less space there is for calldata (or other operations) in that block.

Client restrictions: Although the impact of client restrictions is not so obvious, for example, the Geth client imposes restrictions on each transaction. The 128 kb limit can also affect the final block size. Since the fixed fee per transaction is 21k Gas, the lower the client's per-transaction size limit, the more frequently it will need to pay the fixed fee, thereby "wasting" what could be used for calldata  ; gas. So ultimately, this limit can result in a maximum block size reduction of about 0.07 MB. It should be noted that client restrictions only affect the broadcast of transactions and do not affect blocks that have been confirmed.

First, let’s look at the Gas limit for each block:

Blocks like Ethereum Chain, raising the upper limit of block gas is the most direct and obvious way to expand the capacity. A higher ceiling means more data space. However, this also means that everyone running a full node needs to propagate and download larger blocks. As shown in the figure above, the block size under the "worst case scenario (i.e., the maximum block size calculated previously)" has a roughly linear relationship with the increase in the block Gas upper limit. Such a maximum block size is achieved by creating blocks filled with as many non-zero byte calldata transactions as possible.

Next, let’s look at another influencing factor – Ethereum’s pricing mechanism. In the current example, specifically, the overhead of non-zero bytes calldata  is currently set to 16 Gas:

As shown in the figure above shows that adding non-zero calldata overhead will reduce the block size. In other words, reducing the overhead to, say, 8 Gas per byte doubles the worst-case block size. This is intuitive because lowering the price allows twice the amount of data to be put into the block.

So what happens after EIP-4844 (Proto-Danksharding) goes online?

I won't go into details about 4844 here, as there is good documentation at eip4844.com, but in a nutshell, EIP-4844 introduces something like "sidecar (Sidecar)" structured data type, called blob, each blob can hold about 125 kb of data. The Blob data fee mechanism is similar to EIP-1559, and there is also a "target" used to anchor the number of blobs. In the Dencun hard fork, the target is set to 3 blobs per block and the maximum limit is set to 6 blobs per block. It is worth noting that blob has its own fee market, creating what is called a multi-dimensional fee market. This means that blobs do not have to compete with standard transactions, but are instead decoupled from fees under the EIP-1559 mechanism.

So far, so good. Let’s see how this upgrade affects Ethereum’s average block size.

As of today, the average block size of a beacon chain block compressed using snappy is approximately 125 KB. With 4844, we add another 375 KB per block, thus increasing the current average block size by 4x. If the maximum number of blobs is reached, we essentially increase the current block size seven times.

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

Summary

Ultimately, if we want to increase the current block Gas limit, we need to Conduct thorough research and analysis before implementation. While established entities like Coinbase, Binance, Kraken or Lido node operators can handle exceeding the 40 million block gas cap, independent stakers may have a harder time.

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

In the end, it is relatively easy to build something as large and powerful as Facebook, but it is important not to lose what most of us are after: going Centralization.