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

Conversation

Projects
None yet
@chriseth
Contributor

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 referenced this pull request Feb 13, 2017

Closed

New opcode: STATIC_CALL #116

@Arachnid

This comment has been minimized.

Show comment
Hide comment
@Arachnid

Arachnid Feb 13, 2017

Collaborator

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.

Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@axic

axic Feb 13, 2017

Member

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.

Member

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 referenced this pull request Feb 13, 2017

Closed

Byzantium changes #229

12 of 12 tasks complete
@pirapira

This comment has been minimized.

Show comment
Hide comment
@pirapira

pirapira Feb 20, 2017

Member

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

Member

pirapira commented Feb 20, 2017

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

@chriseth chriseth changed the title from New opcode: STATIC_CALL to New opcode: STATICCALL Feb 24, 2017

@chriseth

This comment has been minimized.

Show comment
Hide comment
@chriseth

chriseth Feb 24, 2017

Contributor

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

Contributor

chriseth commented Feb 24, 2017

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

@arkpar arkpar referenced this pull request Mar 9, 2017

Closed

Byzantium release #4833

12 of 12 tasks complete
@debris

This comment has been minimized.

Show comment
Hide comment
@debris

debris 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?

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

This comment has been minimized.

Show comment
Hide comment
@axic

axic Mar 17, 2017

Member

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
Member

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

This comment has been minimized.

Show comment
Hide comment
@cdetrio
Member

cdetrio commented Mar 17, 2017

@holiman holiman referenced this pull request Mar 17, 2017

Merged

REVERT instruction #206

@pirapira pirapira referenced this pull request Mar 23, 2017

Closed

Metropolis: static call #270

@pirapira

This comment has been minimized.

Show comment
Hide comment
@pirapira

pirapira Mar 23, 2017

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@debris

debris Mar 23, 2017

great, thanks for clarification! 😄

debris commented Mar 23, 2017

great, thanks for clarification! 😄

@debris debris referenced this pull request Mar 30, 2017

Merged

EIP-116 (214), #4833 #4851

@Arachnid

This comment has been minimized.

Show comment
Hide comment
@Arachnid

Arachnid Apr 14, 2017

Collaborator

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

Collaborator

Arachnid commented Apr 14, 2017

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

@chfast chfast referenced this pull request Apr 21, 2017

Closed

[META] Byzantium implementation progress #4050

17 of 17 tasks complete
Show outdated Hide outdated EIPS/static_call.md
Show outdated Hide outdated EIPS/static_call.md

@mkalinin mkalinin referenced this pull request Aug 25, 2017

Closed

Byzantium release #923

13 of 13 tasks complete

@axic axic referenced this pull request Aug 25, 2017

Closed

Proposal for read only calls #697

jo-tud added a commit to ConsenSys/EthOn that referenced this pull request Oct 13, 2017

jo-tud added a commit to ConsenSys/EthOn that referenced this pull request Oct 13, 2017

@pipermerriam pipermerriam referenced this pull request Oct 20, 2017

Merged

Byzantium Fork Rules #123

9 of 9 tasks complete

@pirapira pirapira referenced this pull request Oct 23, 2017

Open

Apply Byzantium changes #459

0 of 10 tasks complete
Show outdated Hide outdated EIPS/eip-214.md
Show outdated Hide outdated EIPS/eip-214.md
Show outdated Hide outdated EIPS/eip-214.md
@pirapira

This comment has been minimized.

Show comment
Hide comment
@pirapira

pirapira Nov 20, 2017

Member

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

Member

pirapira commented Nov 20, 2017

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

@pirapira

The copyrights need to be abandoned as in other EIPs.

@pirapira

This comment has been minimized.

Show comment
Hide comment
@pirapira

pirapira Dec 1, 2017

Member

@chriseth do you mind if I add

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

?

Member

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

?

@pirapira pirapira merged commit f7be760 into master Dec 4, 2017

@pirapira pirapira deleted the staticcall branch Dec 4, 2017

@aerth aerth referenced this pull request Jun 5, 2018

Merged

HF7 @ 36050 #24

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment