EIP-4803: Limit transaction gas to a maximum of 2^63-1

EIPs EIPs core
1

This is the discussion topic for

This is a follow up of ACD#120 where it was agreed to follow up the EIP-2681 and split more of EIP-1985 content into individual EIPs.

2

@chfast suggested to further reduce this limit to 2^31-1, because it would allow removing the “call depth check” from the EVM.

The call depth is limited to 1024, but the Tangerine Whistle hardfork introduced EIP-150 with the “63/64th rule”. That rule makes it not realistic to exhaust the 1024 limit with the current and historical block gas limits. However having 2^31-1 would allow removing it entirely – or in practice combine the various checks into a few branches.

A CALL costing 1 gas would allow 1138 call depth, while 4 gas would terminate after 1021 depth. Note that a call currently costs as at least 100 gas (EIP-2929).

1 Like
3

For historical reference, this proposal was also discussed in 2017. There was a suggestion for 2^62-1 as a limit there.

Additionally, here it was suggested to explicitly enforce this on the block level too. It is unlikely to be worth it, given the strict rules about increasing the block gas limit.

4

2^31-1 would also fit into the integer space of a double, which means you could store this value in a JavaScript number without fear of running into rounding errors.

2 Likes
5

Proposed discussing this on the next ACDE: Execution Layer Meeting 201 · Issue #1197 · ethereum/pm · GitHub

6

There is a somewhat related EIP being proposed: Eip 7825: Transaction Gas Limit Cap

This proposes a much stricter limit (30 Mgas vs. 2^63-1 or 2^31-1) and has a different motivation, but has a similar effect. I am not sure it is applicable from genesis, but my hunch is that EIP-4803 is applicable.

For the EVM perspective EIP-4803 makes a lot of sense as a hard limit, but could make sense having EIP-7825 as a soft limit on the tx/block level. Perhaps these two could be discussed together on ACDE.

cc @Giulio2002

1 Like
7

@matt regarding your question on ACD, from the rationale:

2^63-1 vs 2^64-1

2^63-1 is chosen because it allows representing the gas value as a signed integer, and so the out of gas check can be done as a simple “less than zero” check after subtraction.

The check can be as simple as with signed numbers:

gasAvailable -= cost
if gasAvailable < 0:
  raise OOG

(In theory this also allows processing multiple instructions and checking OOG once – this is not realistic given we need to stop at the exact OOG spot)

When working with unsigned numbers:

if gasAvailable < cost:
  raise OOG
gasAvailable -= cost

geth currently uses uint64, and with the EIP they do not need to change that, however they can, and use a check like above, which could be cheaper on most CPUs.

@chfast since you had a strong preference for the signed version, let me know if you have anything to add.

8

@shemnon gave a better terminology for the distinction:

  • EIP-4803 is the parsing limit
  • EIP-7825 is the configuration limit
9

I think we should give strong consideration to the JavaScript limit of 2^53-1.

My reasoning is that traces are often in JSON, and ensuring that gas values will fit into a JSON number will simplify generation and consumption of those traces.

That allows for over 9 quadrillion gas (9,007,199,254,740,991) in a transaction, which at 1 MegaGas/sec would take over 285 years to execute. At 1 TeraGas/Sec that is still 104 days.

Unless there is existential change to the model of a transaction or what amount of work 1 unit of gas provides then this amount of gas should be sufficient for any reasonable block size.