Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Send all gas in call #90

Closed
chriseth opened this issue Apr 5, 2016 · 9 comments
Closed

Send all gas in call #90

chriseth opened this issue Apr 5, 2016 · 9 comments

Comments

@chriseth
Copy link
Contributor

chriseth commented Apr 5, 2016

Function calls usually provide all available gas to the callee because it is extremely hard if not impossible to come up with a good estimate of how much gas the callee will need.

At he same time, this mechanism relies on actual gas costs inside the EVM and is very fragile:

The amount of gas left can be retrieved via the gas instruction - the problem is that some gas is already spent again between this instruction and the actual call, most notably the gas for the call instruction itself (which can even vary depending on its arguments).

The usual way to cope with this is to subtract a certain constant from the value of the gas instruction (this constant includes the costs for performing this subtraction...).

This is of course all very fragile and means that if we ever increase the gas costs of the instructions call, gas, sub or of pushing constants, we will break existing contracts.

Furthermore, sometimes some gas has to be retained by the caller because it cannot efficiently estimate how costly the call opcode itself will be.

This is less an actual EIP but more a request for ideas about how to handle that situation.

Possibility 1: Use the special case of 2**256-1 gas to mean "all available gas". This would at least make future contracts more flexible.

Possibility 2: Change the semantics of push1 50 gas sub call (similar for other constants) to mean "all available gas" regardless of the result of the actual computation. That should at least keep the intended semantics of existing contracts.

@wanderer wanderer added the EIP label Apr 14, 2016
@wanderer
Copy link
Member

why not just add another opcode? call_all_gas or something?

@wanderer
Copy link
Member

related, call's with relative gas source #61

@wanderer wanderer added the EVM label Apr 14, 2016
@gavofyork
Copy link

dislike possibility 2; it would introduce an extremely opaque meaning to a particular opcode string.

there's also possibility 3: the gas limit given is capped at the amount of gas remaining. this is a similar to possibility 1, but simpler as it doesn't introduce a constant (2^256-1) or a conditional, but merely a trivial "limit" operation.

@chfast
Copy link
Member

chfast commented May 30, 2016

I like @gavofyork's idea, where call(G, ...) means call(min(G, gas), ...). With the current gas limit of 2^63-1 it is enough to use call(2^63-1, ...) to always use all available gas.

@karalabe
Copy link
Member

karalabe commented Sep 2, 2016

Another bit more flexible alternative (if we're going with the constant approach) is to interpret 2-s complement as the amount of gas to retain. So 2^256-1 would mean 0 to retain (essentially the original proposal), but it would also allow me to specify 2^256-1 - 21000 to send all the gas, except the 21K. This could be useful to guarantee that no matter what an external contract does, the caller still has some minimum gas to meaningfully finish its execution.

@chriseth
Copy link
Contributor Author

I guess this can be closed now.

@chfast
Copy link
Member

chfast commented Jan 17, 2017

I think we still should create the EIP document (by a PR) with status "obsolated by".

@fulldecent
Copy link
Contributor

@Arachnid You nominated this as an "EIPs that should be merged". Can you please share your notes on that here?

@u2
Copy link

u2 commented Jul 26, 2018

there is a typo, At he same time, should be At the same time. @chriseth

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants