Title: EIP_4803__Limit_transaction_gas_to_a_maximum_of_2_
Category: EIPs

Author: axic
Date: 2022-02-14T18:42:44.935Z

This is the discussion topic for

Ethereum Improvement Proposals


EIP-4803: Limit transaction gas to a maximum of 2^63-1
Valid transactions must have a reasonable gas limit





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.

Author: axic
Date: 2022-02-14T18:54:22.521Z

@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).

Author: axic
Date: 2022-02-14T22:37:37.989Z

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.

Author: MicahZoltu
Date: 2022-02-16T05:14:31.183Z

axic:

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


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.

Author: axic
Date: 2024-11-27T23:11:56.830Z

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

Author: axic
Date: 2024-11-27T23:14:41.977Z

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

Author: axic
Date: 2024-12-05T15:33:32.827Z

@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.

Author: axic
Date: 2024-12-05T15:36:28.030Z

@shemnon gave a better terminology for the distinction:

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

Author: shemnon
Date: 2024-12-09T16:03:18.545Z

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.

Author: sbacha
Date: 2025-01-13T04:03:59.974Z

Just pointing it out there, there are some legit use cases, such as Convex protocol global shutdown which uses ~22mil gas, see https://github.com/mds1/convex-shutdown-simulation

Author: shemnon
Date: 2025-01-13T16:34:50.476Z

Given Base’s aim for Gigagas/sec I think we need to be prepared for Gigagas (10^9) transactions.  JSON 53 bits gives us 9 Peta gas (10^15), (9 Giga Mega gas).  63 bits gives us 9 Exa gas (9,000 Peta Gas).  Barring pointless memory allocations it should be enough for the next 5-10 years.

Author: wjmelements
Date: 2025-01-15T00:11:56.218Z

Why not 2^64-1? Gas doesn’t need to be a signed integer.

Author: pdobacz
Date: 2025-01-15T09:18:04.992Z

Here is the rationale behind signed: EIP-4803: Limit transaction gas to a maximum of 2^63-1 - #7 by axic, also mentioned in the EIP

Author: wjmelements
Date: 2025-01-15T19:08:47.193Z

This isn’t compelling to me. The signed and unsigned versions are the same number of lines of code. It sounds like this was pushed by someone (perhaps @chfast?) without a solid rationale.

Author: MicahZoltu
Date: 2025-01-16T05:06:48.780Z

Not all languages have unsigned numbers (e.g., JavaScript).
Sometimes there are simplifications to accounting that can be done if you allow negative numbers (there is a place clients already do this in either balance or gas accounting, I forget which).
You may not have an unsigned value for the limit, but you may have an unsigned value that is added to it, and if the limit is unsigned you can end up with needing to do a type conversion during the algebra.

I think the biggest argument though is just that 2^64 doesn’t buy us much compared to 2^63 and even a little bit of a reason to do 2^63 is sufficient to beat that.

Author: chfast
Date: 2025-01-16T09:49:04.623Z

The only difference between signed and unsigned integers in this context currently that with signed integers you can delay the check:
gas -= cost1;
gas -= cost2;
if gas < 0:
   exit();

On the other hand, I’m considering switching to 32-bit variant internally.

Author: wjmelements
Date: 2025-01-16T22:17:11.517Z

MicahZoltu:

Not all languages have unsigned numbers (e.g., JavaScript).


This is the best reason I think. I think Javascript doesn’t even have integers, but java doesn’t have unsigned integers. The lack of unsigned types in some programming languages should be added to the Rationale.



 MicahZoltu:

You may not have an unsigned value for the limit


I don’t understand this part. All of the gas calculations I have done use unsigned longs. Is there a calculation with a negative parameter?



 MicahZoltu:

Sometimes there are simplifications to accounting that can be done if you allow negative numbers


I doubt it.



 chfast:

with signed integers you can delay the check


Out of gas checks should be done eagerly to avoid DoS.