Hardcode the block gas limit (known as block gas target under EIP-1559) to 12,500,000 gas per block.
Abstract
Ethereum’s block gas limit is currently dictated by block producers and is not enforced when validating blocks in clients. This EIP proposes to hardcode the block gas limit to 12,500,000.
As far I know the reason we can’t increase the block size today is a worst-case-scenario block with a ton of SLOADs, this is something that should be addressed in Berlin, and I’ve seen some talks about increasing the gas limit after Berlin because of it.
Maybe this EIP is a good time to do so? If this EIP get’s accepted it would be included probably around London, with EIP-2929 already merged, maybe we can consider a higher value for the initial hardcoded block gas limit?
The more control miners have over core protocol parameters, the more Ethereum must pay to incentivize their honesty. The main argument for giving miners control over the gas limit is that every update to a hard-coded gas limit requires a hard-fork. But given that Ethereum hard-forks 2-3 times per year anyway, there is no reason not to update it there.
Agreed that it just makes sense to take block size out of the miner control.
I think this is also an important step towards the merge for a couple of reasons:
Control of block size will move from miners to stakers and while we’ve seen miners act responsibly and work well with core devs about block sizes, it’s much less known what stakers will do
Currently mining pools effectively control the block size but solo staking is much more viable and common than solo mining because rewards are paid smoothly even for a single validator. This may make it very difficult to coordinate desired block size changes in the future.
Strongly opposed to a hardcoded constant. Hard forks are irregular. If this proposal had been implemented in Istanbul, the constant would have been 10m, and the gas price would be much higher than it is currently. This constant, like the difficulty bomb, would need to be micro-managed every hard fork, and, in my observation, core developers are very bad at estimating possible throughput.
But I can support removing it from miner control since they have a propensity toward keeping it far below capacity to manage their operating costs. We could consider instead increasing the gas target when it is often exceeded, as that is evidence that miners could handle a higher limit. A higher uncle rate could signal DoS and push down the gas target.
Rapid changes to the gas limit will likely be more difficult to execute, which could be problematic if an urgent situation arise that required changing the gas limit.
I wonder if there is any asymmetry in the direction of rapid changes that may be needed in urgent situations. If so, then the hard target can be one-sided.