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

New opcode: STATICCALL #214

Merged
merged 12 commits into from Dec 4, 2017
Merged

New opcode: STATICCALL #214

merged 12 commits into from Dec 4, 2017

Conversation

@chriseth
Copy link
Contributor

@chriseth chriseth commented Feb 13, 2017

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

@chriseth chriseth mentioned this pull request Feb 13, 2017
@Arachnid
Copy link
Contributor

@Arachnid Arachnid commented Feb 13, 2017

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.

@axic
Copy link
Member

@axic axic commented Feb 13, 2017

It's worth considering if state-changing operations should actually throw

If they do throw, a VM implementation may choose to be optimised in the STATIC_CALL case as it would not need to keep changes even temporarily. Additionally compilers may not need to verify upfront that state changing operations are used, because that is enforced by the VM.

That would leave the non-throwing STATIC_CALL to be implemented via a mechanism as you've explained.

@pirapira pirapira mentioned this pull request Feb 13, 2017
12 tasks

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`.
Copy link
Member

@pirapira pirapira Feb 14, 2017

Is SSTOREBYTES an instruction?

Copy link
Contributor Author

@chriseth chriseth Feb 14, 2017

This was taken from vitalik's draft that assumed another EIP which introduced SSTOREBYTES.


## 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.
Copy link
Member

@pirapira pirapira Feb 14, 2017

I guess HLL stands for "Haskell-like languages", but maybe not.

Copy link
Contributor Author

@chriseth chriseth Feb 14, 2017

My guess is that it stands for just "high level language".


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`.
Copy link
Member

@pirapira pirapira Feb 17, 2017

So far we haven't separated words in the mnemonics: CALLCODE and DELEGATECALL. Maybe STATICCALL is more consistent.

@pirapira
Copy link
Member

@pirapira pirapira commented Feb 20, 2017

I filed an yellow paper PR about this ethereum/yellowpaper#237

@chriseth chriseth changed the title New opcode: STATIC_CALL New opcode: STATICCALL Feb 24, 2017
@chriseth
Copy link
Contributor Author

@chriseth chriseth commented Feb 24, 2017

Changed the name to STATICCALL, but note that the name is not a consensus-relevant issue ;-)

@debris
Copy link

@debris debris commented Mar 10, 2017

From: https://github.com/ethcore/parity/pull/4851#pullrequestreview-26245124

Also one thing bothers me:
I think currently STATICCALL will kill empty accounts when it touches them - that is arguably a state alteration. Since we don't allow empty accounts to be created any more it shouldn't cause a problem if there are not empty accounts already existing on chain, but nevertheless I think we should either avoid killing empty accounts in such case or clarify that in the specification.

What should happen in such case?

@axic
Copy link
Member

@axic axic commented Mar 17, 2017

Also, if REVERT is implemented, is STATIC_CALL necessary?

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:

  • always include the signature of staticWrapInternal when building the calldata
  • use the same signature as the recipient if available

@cdetrio
Copy link
Member

@cdetrio cdetrio commented Mar 17, 2017

@pirapira
Copy link
Member

@pirapira pirapira commented Mar 23, 2017

@debris my Yellow Paper PR would also kill dead accounts that are touched during a STATICCALL ethereum/yellowpaper#270

@debris
Copy link

@debris debris commented Mar 23, 2017

great, thanks for clarification! 😄

@Arachnid
Copy link
Contributor

@Arachnid Arachnid commented Apr 14, 2017

Please renumber as eip-214 and we will merge this as a draft.



## Motivation

Copy link
Member

@axic axic Apr 23, 2017

Shouldn't this be filled with something?

jo-tud added a commit to ConsenSys/EthOn that referenced this issue Oct 13, 2017
jo-tud added a commit to ConsenSys/EthOn that referenced this issue Oct 13, 2017
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.
Copy link
Member

@pirapira pirapira Nov 20, 2017

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.
Copy link
Member

@pirapira pirapira Nov 20, 2017

Perhaps all accounts instead of all contracts.

EIPS/eip-214.md Outdated
Author: Vitalik Buterin <vitalik@ethereum.org>, Christian Reitwiessner <chris@ethereum.org>;
Type: Standard Track
Category: Core
Status: Draft
Copy link
Member

@pirapira pirapira Nov 20, 2017

Now the status should be Accepted.

@pirapira
Copy link
Member

@pirapira pirapira commented Nov 20, 2017

@axic Requires and Replaces fields are optional. eip-X.md says so.

Copy link
Member

@pirapira pirapira left a comment

The copyrights need to be abandoned as in other EIPs.

@pirapira
Copy link
Member

@pirapira pirapira commented Dec 1, 2017

@chriseth do you mind if I add

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

?


`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.
Copy link

@lithp lithp Dec 4, 2018

Why does the exception for CALLCODE exist?

@ethereum ethereum deleted a comment Apr 19, 2019
@ethereum ethereum deleted a comment Apr 19, 2019
@ethereum ethereum deleted a comment Apr 19, 2019
@ethereum ethereum deleted a comment Apr 19, 2019
@ethereum ethereum deleted a comment Apr 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet