Lower maximum transaction gas limit

[chfast]

Overwiew

Maximum allowed transaction gas limit is 2⁶³ - 1.

Specification

Any transaction with the gas limit greater than 2⁶³ - 1 should be ignored by a client.

Motivation

Designing Ethereum VM for unrealistic case where amount of gas is greater than 2⁶⁴ is a waste of time.

Allowing the gas counter to fit regular CPU register on 64-bit targets is a big performance win. One more bit is reserved to allow faster overflow detection.

[axic]

Any transaction with the gas limit greater than 2^63 - 1 should be ignored by a client.

Do you mean it should:

• take it as 2^63
• or reject the transaction?

[chfast]

It should reject the transaction. The first option is not possible in my opinion.

[obscuren]

I had been toying with a similar idea and have been playing with an inplementation in the past.

I'll try to dig it up or reimplement (shouldn't be too difficult) and see if I can get some benchmarks done :-)

[chriseth]

An option would be to modify the block gas adjustment scheme to not only have a "min gas" but also a "max gas".

[gcolvin]

I am already changing the interpreter to throw an OutOfGas exception if the gas limit , the memory limit, or the calculations are >=263. This of course violates the spec, but saves a lot of calculation. It is also a practical impossibility to get anywhere near those limits in the real world. Unfortunately, my code fails tests that push the inputs past those limits anyway. The spec should put hard limits on gas and memory -- they can always be changed later as hardware advances. I agree that 263 -1 is a good limit so far as being practically impossible to approach and fast to compute.

[wanderer]

we could add a few more caps as well

• balances cap to 128 integer
• gasPrice cap to 64 bits integer
• gas cap to 64 bits integer

[chfast]

I think codesize and calldatasize can be implementation defined. I'm using size_t in JIT and nobody cares.

[larspensjo]

Using "implementation defined" can in theory lead to consensus failure? If so, there should never be any limitations that are implementation defined?

[chfast]

@larspensjo no. E.g. minimum gas price is user / implementation defined. Transactions with the gas price lower that the minimum are rejected / not mined.

[larspensjo]

I see, thanks!

[gcolvin]

The program counter is another one. Just noticed this in the Go code

        // For optimisation reason we're using uint64 as the program counter.
        // It's theoretically possible to go above 2^64. The YP defines the PC to be uint256. Pratically much less so feasible.
        pc = uint64(0) // program counter

And the C++ interpreter is using a uint64_t as well. Not much sense using a counter for more memory than you can physically address. I'm not sure if testing catches this.

[gcolvin]

2^256-1 =
115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,
639,935
This is 78 digits. Estimates of the numbers of atoms in the visible universe run from 10^70 to 10^80.

[chfast]

@wanderer, I used following caps in EVMJIT successfully:

• block number: 64 bits,
• timestamp: 64 bits,
• gas price: 64 bits (more/less successfully).

I think there are some test cases that use gas price bigger than 64 bits. I can give up this one as gas price seems not to be on critical path (rarely used in contracts).

Never considered using 128-bit integers, wanted to keep the type set small.

How can we formalize the above?

[axic]

The EVM2.0 design sets out the following limits:

Further more we define the following caps on the environmental variables

codesize is capped to a 64 bit integer
calldata size is capped to 64 bits
balances are repesented as a 128 bit little endian unsigned integer
gasPrice is repesented as a 64 bit little endian unsigned integer
gas is repesented as a 64 bit little endian unsigned integer

@gcolvin IIRC if codesize is limited to 64bit, that would put the pc under the same limit

[SergioDemianLerner]

In RSK (a.k.a Rootstock) we've defined the limit to be about 2^62. The reason is that it is much more efficient to compute several additions to the gas counter and then to check for int64 oveflow than to check for int64 overflow after each, when each added value is known to be well below 2^20.
Using this and other optimizations our EVM-compatible VM is 5.8 times faster than get/eth for simple arithmetic computations in loops.

[bobsummerwill]

Thanks for sharing that, @SergioDemianLerner. Much appreciated!

[chfast]

@SergioDemianLerner Can you explain why do you need 2 additional bits to do it instead of one?

[SergioDemianLerner]

There is no need for 2 bits. We use Java that has signed 64-bit integers, so by limiting ourselves to 62 bits we can be sure all operations remain positive, even when they overflow. But we could also check for negative values. For a platform that has 64-bit unsigned arithmetic, limiting the gas to 2^63-1 would be the same.

[chfast]

I think we use signed int64 and check for negatives (however it is not full C++ compliant). Thanks for sharing that.

[chfast]

This was somehow agreed on, by limiting block's max gas limit to 2^63-1. But I'm not sure there is any official EIP expressing that.

[axic]

This is now covered by https://eips.ethereum.org/EIPS/eip-1985. I propose to close this issue, @chfast.