-
Notifications
You must be signed in to change notification settings - Fork 5.3k
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
Comments
why not just add another opcode? |
related, call's with relative gas source #61 |
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. |
I like @gavofyork's idea, where |
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 |
I guess this can be closed now. |
I think we still should create the EIP document (by a PR) with status "obsolated by". |
@Arachnid You nominated this as an "EIPs that should be merged". Can you please share your notes on that here? |
there is a typo, |
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 thecall
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.The text was updated successfully, but these errors were encountered: