-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
New opcode: STATICCALL #214
Conversation
It's worth considering if state-changing operations should actually throw, or just be reverted after the call returns; the latter would permit calling operations that would normally create side-effects in a side-effect free fashion. Also, if REVERT is implemented, is STATIC_CALL necessary? You could create an equivalent effect by calling yourself, then calling the target contract, and REVERTing afterwards. |
If they do throw, a VM implementation may choose to be optimised in the That would leave the non-throwing |
EIPS/static_call.md
Outdated
|
||
Opcode: `0xfa`. | ||
|
||
`STATIC_CALL` functions equivalently to a `CALL`, except it takes 6 arguments not including value, and calls the child with a `STATIC` flag on. Any calls, static or otherwise, made by an execution instance with a `STATIC` flag on will also have a `STATIC` flag on. Any attempts to make state-changing operations inside an execution instance with a `STATIC` flag on will instead throw an exception. These operations include nonzero-value calls, creates, `LOG` calls, `SSTORE`, `SSTOREBYTES` and `SUICIDE`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is SSTOREBYTES
an instruction?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was taken from vitalik's draft that assumed another EIP which introduced SSTOREBYTES.
EIPS/static_call.md
Outdated
|
||
## Rationale | ||
|
||
This allows contracts to make calls that are clearly non-state-changing, reassuring developers and reviewers that re-entrancy bugs or other problems cannot possibly arise from that particular call; it is a pure function that returns an output and does nothing else. This may also make purely functional HLLs easier to implement. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess HLL stands for "Haskell-like languages", but maybe not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My guess is that it stands for just "high level language".
EIPS/static_call.md
Outdated
|
||
Opcode: `0xfa`. | ||
|
||
`STATIC_CALL` functions equivalently to a `CALL`, except it takes 6 arguments not including value, and calls the child with a `STATIC` flag on. Any calls, static or otherwise, made by an execution instance with a `STATIC` flag on will also have a `STATIC` flag on. Any attempts to make state-changing operations inside an execution instance with a `STATIC` flag on will instead throw an exception. These operations include nonzero-value calls, creates, `LOG` calls, `SSTORE`, `SSTOREBYTES` and `SUICIDE`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So far we haven't separated words in the mnemonics: CALLCODE
and DELEGATECALL
. Maybe STATICCALL
is more consistent.
I filed an yellow paper PR about this ethereum/yellowpaper#237 |
Changed the name to |
From: https://github.com/ethcore/parity/pull/4851#pullrequestreview-26245124
What should happen in such case? |
Implemented it in Solidity here: https://gist.github.com/axic/fc61daf7775c56da02d21368865a9416 Without language support it is quite expensive as the calldata has to be copied. With language support there are at least two ways:
|
See also EIP 140: REVERT instruction. |
@debris my Yellow Paper PR would also kill dead accounts that are touched during a STATICCALL ethereum/yellowpaper#270 |
great, thanks for clarification! 😄 |
Please renumber as eip-214 and we will merge this as a draft. |
EIPS/static_call.md
Outdated
|
||
|
||
## Motivation | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be filled with something?
EIPS/eip-214.md
Outdated
|
||
## Motivation | ||
|
||
Currently, there is no restriction about what a called contract can do, as long as the computation can be performed with the amount of gas provided. This poses certain difficulties about smart contract engineers: After a regular call, unless you know the called contract, you cannot make any assumptions about the state of the contracts. Furthermore, because you cannot know the order of transactions before they are confirmed by miners, not even an outside observer can be sure about that in all cases. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe ; after
instead of : After
.
EIPS/eip-214.md
Outdated
|
||
Currently, there is no restriction about what a called contract can do, as long as the computation can be performed with the amount of gas provided. This poses certain difficulties about smart contract engineers: After a regular call, unless you know the called contract, you cannot make any assumptions about the state of the contracts. Furthermore, because you cannot know the order of transactions before they are confirmed by miners, not even an outside observer can be sure about that in all cases. | ||
|
||
This EIP adds a way to call other contracts and restrict what they can do in the simplest way. It can be safely assumed that the state of all contracts is the same before and after a static call. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps all accounts
instead of all contracts
.
EIPS/eip-214.md
Outdated
Author: Vitalik Buterin <[email protected]>, Christian Reitwiessner <[email protected]>; | ||
Type: Standard Track | ||
Category: Core | ||
Status: Draft |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now the status should be Accepted.
@axic |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The copyrights need to be abandoned as in other EIPs.
@chriseth do you mind if I add
? |
|
||
`STATICCALL` functions equivalently to a `CALL`, except it takes only 6 arguments (the "value" argument is not included and taken to be zero), and calls the child with the `STATIC` flag set to `true` for the execution of the child. Once this call returns, the flag is reset to its value before the call. | ||
|
||
Any attempts to make state-changing operations inside an execution instance with `STATIC` set to `true` will instead throw an exception. These operations include `CREATE`, `CREATE2`, `LOG0`, `LOG1`, `LOG2`, `LOG3`, `LOG4`, `SSTORE`, and `SELFDESTRUCT`. They also include `CALL` with a non-zero value. As an exception, `CALLCODE` is not considered state-changing, even with a non-zero value. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does the exception for CALLCODE
exist?
To increase smart contract security, this proposal adds a new opcode that can be used to call another contract (or itself) while disallowing any modifications to the state during the call (and its subcalls, if present).
Replaces #116