# Why I think EIP 1559 block variance is nothing to worry about One critique of EIP 1559 that sometimes appears is that because the block size becomes variable, floating in the range [0, 25M] gas instead of always being a clean 12.5M gas, this doubles the load that clients need to handle. The argument further goes that if we decide that clients _are_ capable of handling this higher load, then they should be capable of handling this higher load _all the time_, and so we should just scrap EIP 1559 and instead do the even more useful thing of doubling the block size limit. The core idea behind this thinking is a perception that the primary harms of large block sizes come from the _largest_ blocks that come through a client, and not the average blocks. **I believe that this idea is wrong (and therefore EIP 1559 does NOT cause much higher risk to clients than a fixed gas limit), and this post explains my reasoning**. ### Recap: what are the good reasons to not increase the gas limit to 100M tomorrow? There are three: 1. **Average-case block processing time will increase** from the current ~400 ms to ~3.2s, leading to a number of bad consequences: * Extremely high uncle rates, leading to centralization * Difficulty for all but the most high-powered nodes to stay in sync * Higher resource consumption for even high-powered nodes * Increased delay before resyncing after a brief outage (eg. you have a node on your laptop and you just moved the laptop from home to a coffee shop) 2. **Worst-case block processing time due to DoS attacks will increase**, from the current ~20-80 seconds to a potential ~160-640 seconds. 3. **The storage size growth rate will increase** from the [current ~50 GB per month](https://etherscan.io/chartsync/chaindefault) to ~400 GB per month, resulting in: * Much slower syncing * Much higher storage requirements * Even slower disk processing, because larger databases are slower to access than smaller databases Note one very important observation: **all sub-items in (1) and (3) depend on long-run average usage only, and are not affected by spikes. Hence, to think through the impact of spikes, it suffices to focus on (2)**. ### Argument 1: EIP 2929 already compensates for EIP 1559 EIP 2929's storage access gas cost increases already increase the cost of a worst-case DoS against the chain by 3x. This means that the _combination_ of EIP 2929 with EIP 1559 will in fact _decrease_ the cost of processing a single worst-case block by a net 1.5x compared to the status quo. One natural question to ask is: "well if EIP 2929 is so great then why not just bump up the gas limit to 25M or 37.5M"? This is answered easily: (2) is not the only reason to avoid gas cost increases. Even if DoS issues were completely resolved, all of the items under (1) and (3) continue to be a problem for the foreseeable future. Hence, the extra "slack" that EIP 2929 gives us cannot be used for large block size increases. ### Argument 2: a short-term DoS spike is much less bad than a persistent DoS of the same amplitude If an attacker starts spamming the chain to fill it with maximum-size (2x target) blocks, the gas price increases by 1.125x per block. This increase is exponential: sustaining maximum-size blocks for 5 blocks (~65 seconds) would increase the gas price by ~1.8x, and after 5 minutes the gas price would go up by 15x (and after 10 minutes, 225x!). To sustain the attack, the attacker would have to pay for all these transactions at these massively inflated fees. So the maximum realistic length for an attack is ~5 minutes. What would actually happen if clients receive 5 minutes worth of blocks that each take 20-60 seconds to process? Clearly, the chain would process extremely slowly during that time. There would be a lot of short-range forking. In fact, the forking means that an attacker could even revert the chain after the attack with much less hashpower (eg. ~20%). This is all quite bad. **However, this is VASTLY less bad than an attacker being able to sustain such an attack for eg. an hour or even a day**. Most exchanges and other services already wait longer than 5 minutes for confirmations, and only extremely brittle services would be broken because it's too difficult to send a transaction for 5 minutes, whereas a reversion or a denial of service lasting for hours or days, as the 2016 Shanghai attacks did, could have quite grievous consequences. Hence, the ability to have 25 million gas spikes for 5 minutes is much less risky than having a gas limit of 25 million. ### Argument 3: short-term spikes happen already The Poisson process inherent to proof of work mining already implies some randomness in the times at which blocks are published. **In fact, the randomness alone leads to a 2x spike in chain capacity lasting for five minutes happening roughly once a week!** _(Note: this is a larger number of blocks of the same size instead of the same number of blocks of larger size, but as of this writing I am aware of no evidence or reason to believe that the processing of a single block is "superlinear" in gas consumed)_ Hence, usage spikes are to some degree a known quantity, and the ecosystem so far has managed to simply ignore them.