Upper bound for block gas limit

[chriseth]

In the near future, we cannot expect that transactions that require more than 2**63 gas will be practically verifiable because they will either take too much time or too much memory. This means that for all practical reasons, code that deals with gas costs can be done with 64 instead of 256 bit arithmetics, which is much faster on present architectures. During our EVM performance analysis that is currently underway, we noticed that gas requirement calculations use up a considerable amount of execution time and thus, large improvements could be achieved.

The only problem with this is that the block gas limit can be moved up as far as 2**64 in about a month if all miners cooperate and then it could be possible to include a transaction that has a start gas of more than 2**64 and potentially even use up all of the gas at a gas price of 0.

In order to prevent this rather theoretical problem, we should change the block gas limit adjustment formula to not only include a minimum value but also a maximum value of 2**63-1.

The reason to choose 2**63-1 over 2**64-1 is that overflow calculations are much easier to perform if we know that valid gas values always fit 63 bits.

[tscs37]

I'm unsure if this is an issue outside of a gasprice of 0.

Even with Ether was near worthless and gas practically free, 2**63-1 gas will still cost an insane amount, which will either disincentivize even considering these transactions or cost the sender a lot of economic value for a effect that lasts at best one block.

Another issue is that we simply can't know that we won't ever hit this limit and rather than imposing an artifical limit that we think of as good, I'd rather let the system take care of this organically.

A quick check reveals that sending this transaction will cost about 9.223.372.000.000 ether if the gas price is 1 szabo. Even if the gasprice dropped to 1 wei, it would still cost about 9,2 ether.

And it would only work shortly, as miners have incentive to increase blocksize further to earn more fees from other transactions.

[gcolvin]

@eyecikjou567 Tim, I'm not sure what you mean by "let the system take care of this organically." What we don't want to do - as implementers, is pay the price for 256-bit arithmetic when 64-bit is almost certain to suffice. Do you disagree?

[tscs37]

Limiting gas price calculation to 64bit is still somewhat silly and imposes a limit on the system.

Rather than risking a debate later on wether 64bit gas price calculations are enough, the system should use gas costs to disincentivize such gas costs to begin with.

Nodes and miners are free to use any number of bits for calculations but should always be ready to do full 256bit price calculations if they become necessary. This ensures that the software is immediately future-proof without having to panic later.

To prevent transactions trying to use that much gas in the first place, a gas price of 0 should be blocked by nodes as default however. As long as the gas price is >0 there need is no need to implement limitations on gas usage.

[gcolvin]

OK. I'll worry about it when machines other than supercomputers have address spaces larger than 64 bits.

[Nashatyrev]

+1

[axic]

I'd say this can be closed when #1985 is merged.

[axic]

@chriseth are you OK closing this in favour of #1985 (https://eips.ethereum.org/EIPS/eip-1985)? (It has a link to this issue.)