EIP-8261: Gas limit schedule

[bbusa]

EIP-8261: Gas limit schedule

TL;DR: Make the block gas_limit a hard-fork-scheduled, consensus-enforced parameter. Same pattern as BPO (EIP-7892), but for gas. After activation, the gas limit can only change at a fork — any block with a mismatched gas_limit is invalid.

Removes:

• EL flags (--miner.gaslimit, etc.)
• Validator “preferred gas limit” via engine_forkchoiceUpdated
• gas_limit in builder bids / validator registrations
• The EIP-1559 ±1/1024 per-block gas-limit adjustment rule (base fee, elasticity, and burn are untouched)

Adds:

• gasLimitSchedule (EL) and GAS_LIMIT_SCHEDULE (CL), keyed by fork
• gpo<index> (“Gas Parameter Only”) forks for lightweight, BPO-style gas-limit bumps

Why:

1. Safety — today nothing in protocol stops a popular client default or a few large operators from pushing the network onto an untested gas limit. This makes the safe ceiling a consensus rule, not a social one.
2. Symmetry with blobs — block gas is the last major capacity dial still set by validator-level voting.
3. Smaller trusted surface — drops a gas_limit field plumbed across EL → CL → engine API → bid → relay → proposer.

Trade-off: removes the informal per-validator “vote.” GPO forks give back the agility (fast, narrow-scope) — but explicitly, with EL/CL coordination.

Draft PR: ethereum/EIPs#11644

[wjmelements]

Symmetry with blobs

This moves in the wrong direction. More parameters, such as the blob gas limit, should be voted by the staker rather than decided by core developers, whose interests are different than users and the network. Most core developers don’t even use the network.

The blob only hard forks were introduced because the configuration chosen by the core developers was very wrong, and they wanted a way to tweak it more easily. But if they had let the stakers control it, it would have been fixed automatically.

today nothing in protocol stops a popular client default or a few large operators from pushing the network onto an untested gas limit

And yet it has not been a problem the entire history of the protocol. But if 50%+ of the stake votes to increase bandwidth to the extent that it leaves the slow clients behind, the slow clients should just upgrade. Client diversity can be preserved by making the slow clients faster.

Proposers don’t want to increase the gas limit too high because oversupply will diminish their priority fees. This is a phantom problem because it only happens when a majority of staked capital acts against their own interests.

Let’s also not pretend that core developers are less likely to make mistakes than stakers. Core developers have made numerically more mistakes than stakers when configuring gas limits. Usually their recommendations are overly conservative. Also consider the core developers of other protocols; for example, Bitcoin is governed by small blockers who want to constrict the network. This is a pattern, and if we give them this power, they aren’t going to give it back.

{
  "gasLimitSchedule": {
    "glamsterdam": 60000000,
    "gpo1":        75000000,
    "gpo2":        90000000
  },
  "glamsterdamTime": 1772000000,
  "gpo1Time":        1780000000,
  "gpo2Time":        1788000000
}

Really, what you’re trying to do is increase the gas limit without the consent of the node operators. Your increase schedule is not gradual like the current mechanism, so gaslimit-related problems will emerge suddenly, when a significant chunk of the network is suddenly left behind.

[bbusa]

should be voted by the staker rather than decided by core developers, whose interests are different than users and the network

Could you specify what you mean by different interests? Today they line up roughly:

Average staker’s interest: maximize return on stake.

Core devs’ interest:

• Worst-case block safety — stakers see the average day, devs design for the attack.
• Decentralization — gas limit sets the hardware floor for home validators.
• State growth / sync time — costs everyone who runs a node later, not the proposer.
• P2P stability — block size has to fit under CL gossip limits (~10 MiB).
• Cross-client testing surface — only safe at values all clients have been tested at.
• Long-term health — stakers can exit; the protocol can’t.

configuration chosen by the core developers was very wrong

Care to argue? What value should have been picked? We’re still sitting at 3–4 blobs/block on average.

yet it has not been a problem the entire history of the protocol

There’s a reason. If validators had actually listened to the “pump the gas” sites and tweets, we’d have seen real attacks. The values being advocated were unsafe at the time, and the same is true now. Pushing past ~200M before Glamsterdam could expose catastrophic bugs.

if 50%+ of the stake votes to increase bandwidth to the extent that it leaves the slow clients behind

This isn’t a client limitation, it’s a decentralization limitation. We don’t hold bandwidth back because some client can’t handle it; we hold it back so large parts of the world can stay at head.

Let’s also not pretend that core developers are less likely to make mistakes than stakers

From the average staker’s perspective, long-term chain health simply doesn’t enter the signal. You also argued core devs are being too conservative also priority fee revenue is now dominated by MEV/builder payments, not by congestion from gas-limit underprovisioning. So which decided gas-limit value was actually wrong, and against which metric?

so gas-limit-related problems will emerge suddenly, when a significant chunk of the network is suddenly left behind

That’s exactly why we want a controlled, scheduled mechanism instead of a gradient with no cap. With a schedule we can actually test the target value at devnet/shadowfork scale before it goes live. Under the current model, if validators collectively decided to yolo 500M and then exit, the protocol has no way to stop them.

[eth2353]

1. What if there is a need to quickly lower the gas limit (e.g. in case of another DoS attack)?

   Currently we only need >50% of the network to update their gas limit settings and achieve this. With this proposal we’d need >66% if we actually want to finalize the fork, and with some proposed designs for fast finality we’d need >83%. That seems like a big downside that is only briefly mentioned here:

   In practice the mechanism is used for slow, coordinated changes (EIP-7935 being a recent example), not for rapid response.

   It hasn’t been used for rapid response recently but historically it has been useful.

2. On a high level I strongly dislike the idea of a new fork type.

   Forking represents a source of elevated risk in terms of consensus (I hope we haven’t forgotten Holesky yet) and I believe we should aim to minimize those as much as possible.

   I wouldn’t want to end up in a situation where we have 10 different X-parameter-only-style forks and therefore 10 additional sources of data where disagreement could come from. I know this data is nowadays being verified much better ahead of forks but I still don’t feel quite comfortable with it, there’s always room for error.

3. I would be in favor of a much simpler proposal that sets a per-hard-fork gas limit ceiling above which the gas limit cannot be raised.

   That ceiling should be set optimistically to allow the gas limit to be increased to some degree, if desired, before the next hard fork comes around. If the network desires an even higher limit, well, we’d need to ship a proper fork and that seems ok to me.

   This would remove the risks described in 2) while still achieving the proposal’s primary goal - preventing unsafe gas-limit drift.

[jochem-brouwer]

I don’t think this is the right approach. I agree that we should cap the gas limit. We have seen in the current fork (Fusaka) that certain gas limits are not yet possible because we need for instance updates on the devp2p layer. However, I do not think we should schedule gas forks like this. I think I could agree with a gpo-like forking to raise the gas cap, but not to actually set the gas limit.

The main problem I have is if a DoS attack is going on (and most likely it then means I did a bad job because this should be caught by benchmarks ) then a rapid GPO-style fork should be shipped. I am assuming GPO forks also change chain forkHash. Because of this fork, this is by definition in the future by X time to ensure that nodes can update. This also means that the gas limit is then stuck until time X, which means all nodes have to “survive” this DoS attack and there is nothing they can do. With the gas mechanism of the 1/1024 rule, nodes can immediately start to “downvote” the gas limit, which can be shipped as soft fork and thus does not need emergency fork rollouts.

I think we should always have had a gas limit cap, because I agree with your point that it is allowed by the protocol to upvote the gas limit to whatever the max value is, which is clearly a DoS vector and should be addressed. For Fusaka we would have set this to 60 or 80M for instance.

My main concern is thus that in case of a DoS attack where we want to limit the block resources (via gas limit) there is nothing we can do, we just have to wait until the GPO time has been decided, the clients have released, and then wait until the activation time happens.

For the GPO-cap version I think I would also be fine with the rule that this just defines the maximum, so if we want to do a GPO fork to immediately decrease the gas limit to say half of what it is currently, this is a fine configuration and there thus suddenly could be a big decrease in gas limit at this fork block.

[bbusa]

per hard fork gas limit ceiling

This has already been proposed EIP-3756: Gas Limit Cap .

If we don’t end up doing 8261, I would like to see 3756 or alike EIP to be included to ensure we stay safe.

[potuz]

I agree mostly with @wjmelements. I wouldn’t go as far as saying that core devs have different interests than users and the network. I would also not say that the blob gas limit parameters was a wrong design, in fact the analogy is wrong to start with. The reason we went with BPOs instead of having stakers voting into blob gas limit was precisely that the changes are discrete and at the low numbers we were working on, a simple vote from some pools could suddenly put the chain in jeopardy. One could argue that as the data throughput increases and a single blob increase in the target represents a much lower percentage of the total, we could in principle move to a staker voted system.

The gas limit was historically chosen by miners/validators and I think this is a property we want to keep. Both miners in Pow as well as staking pools and home stakers in Pos have always followed core devs advice on safe limits. It also adds an extra layer of safety over governance capture. It protects ourselves from ourselves. Unfortunately clients have already shifted the status quo by shipping default values before they were chosen and voted by stakers on mainnet. If anything we should revert this trend and let operators choose the gas limit before we ship our clients with them.

[CelticWarrior]

My feeling is that the social aspect of pushing the gas limit was instrumental of getting things to move and put focus back on the L1 scaling which was sorely missing for several years. Not sure I like the idea of removing that social aspect. It has a very important signalling effect.