Vitalik Buterin: Why I'm Not Worried About EIP-1559's Variable Block Capacity

This article was published on ETH Chinese Station, author: Vitalik Buterin.

One criticism of EIP-1559 is that the block size is variable, fluctuating in the range of [0, 25M] rather than being a fixed gas limit of 12.5M, which means clients need to handle double the load. This argument further evolves into the idea that if we believe clients can handle such high loads, then they should be able to handle such high loads at any time, and it would be better to abandon EIP-1559 and directly do something more useful—double the block size limit.

The core idea behind this thought is that the primary danger of large blocks comes from those maximum blocks processed by clients, rather than the average block size. I believe this idea is wrong (thus the risks posed by EIP-1559 to clients are not higher than those of a fixed gas limit mechanism), and here are my reasons.

Revisiting: What are the reasons not to immediately raise the gas limit to 100M?

Three reasons:

1. Block processing time under normal circumstances will increase

From the current approximately 400 ms to about 3.2s, which will bring many negative consequences:

• Very high uncle block rate, leading to centralization

• All nodes except the most powerful ones will struggle to stay in sync

• Even the most powerful nodes will require significantly more resource consumption

• There will be longer delays before resynchronization after a brief power outage (for example, if you are running a node on a laptop and need to move your computer from home to a café)

2. Due to DoS attacks, in the worst case, block processing time will be extended, from the current 20~80 seconds to possibly 160~640 seconds.

3. The storage growth rate will increase

From the current approximately 50 GB/month to about 400 GB/month, which will lead to

• Much slower synchronization speed

• Much higher storage requirements

• Slower disk processing speed, as access speeds for large databases will be slower than for small databases

Please note: All content under reasons 1 and 3 applies only to long-term normal usage scenarios, not those affected by peaks. Therefore, if considering the impact of peak periods, focusing on reason 2 is sufficient.
Argument 1: EIP-2929 has already compensated for the shortcomings of EIP-1559

EIP-2929 has increased the gas cost for storage access operations, raising the gas consumption required for the worst-case DoS attacks by 3 times. This means that EIP-2929, in conjunction with EIP-1559, actually results in a net reduction of 1.5 times in the gas consumption required to process blocks in the worst case compared to now.

A natural question arises here: "If EIP-2929 is so good, why not directly raise the gas limit to 25M or 37.5M?" The answer is simple: reason 2 is not the only reason to avoid an increase in gas consumption. Even if the DoS issue could be completely resolved, the problems under reasons 1 and 3 will still exist in the foreseeable future. Therefore, the additional slack provided by EIP-2929 cannot be used to significantly increase block capacity.

Argument 2: For the same level of DoS attack, the drawbacks caused by short-term peaks are far less than those caused by long-term attacks

If an attacker launches an attack on the chain, filling blocks with garbage data at the maximum block capacity (twice the target capacity), the gas price for each block will increase by 1.125 times. This increase is exponential: continuously generating 5 full blocks (about 65 seconds) will cause the gas price to rise by 1.8 times, and after 5 minutes, the gas price will rise by 15 times (225 times after 10 minutes). To sustain the attack, the attacker must pay all transaction fees at these wildly increasing prices. Therefore, a realistic attack can last about 5 minutes.

What happens if the client receives the blocks generated during these 5 minutes (each requiring 20~60 seconds of processing time)? Clearly, during this time, the chain's processing speed will become very slow. There will be many short-range forks. In fact, forks mean that the attacker can still roll back transactions on the chain with a small amount of hash power (for example, about 20%) after the attack. This is a very bad situation.

However, this is much better than an attacker being able to sustain an attack for an hour or even a day. Most transactions and other services currently waiting for confirmation have already exceeded a 5-minute wait time, and only extremely fragile services would be destroyed because it is too difficult for them to send a transaction in 5 minutes, while rollbacks or denial of service could last for hours or even days, as seen in the 2016 Shanghai attack incident, which caused very serious consequences.

Therefore, sustaining a peak of 25 million gas for 5 minutes is much less risky than a gas limit of 25 million.

Argument 3: Short-term peaks have already occurred

The inherent Poisson process of proof-of-work mining means that there will be randomness in block releases. In fact, just the randomness alone leads to a peak of double chain capacity once a week, lasting five minutes.

Note: This is caused by a large number of blocks of the same capacity rather than a small number of large-capacity blocks, but to my knowledge, there is no evidence or reason to believe that the gas consumed for processing a single block grows superlinearly.

Therefore, to some extent, using peaks is a known quantity, and the ecosystem has so far been able to ignore its impact.