-
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
Changes from 2 commits
d4a9172
3ea17dc
a23bd30
bee4515
5e0c5f3
2a7e445
2d2d028
2da707c
12257d5
b550ed7
d8f5c84
b1623c2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,40 @@ | ||
## Preamble | ||
|
||
EIP: to be assigned | ||
Title: New opcode STATIC_CALL | ||
Author: Vitalik Buterin <[email protected]>, Christian Reitwiessner <[email protected]>; | ||
Type: Standard Track | ||
Category: Core | ||
Status: Draft | ||
Created: 2017-02-13 | ||
|
||
## Simple Summary | ||
|
||
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). | ||
|
||
## Abstract | ||
|
||
|
||
## Motivation | ||
|
||
|
||
## Specification | ||
|
||
Opcode: `0xfa`. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why not There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I just took that from some draft, I'm fine with any other value. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we will be better off choosing random opcodes. If we try to avoid gaps, we need to sort EIPs in a linear ordering, and more communication is needed. On the other hand, if we allow gaps, no communication is necessary unless there is a collision (or, when one party notices a collision, they can simply change the opcode, so maybe no communicaiton is necessary). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That is true, though I do not feel it is a valid concern currently, since only one CALL opcode is being added in Byzantium. (The other opcodes, revert, returndata* are sorted out). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does this now stay at There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @holgerd77 https://github.com/ethereum/EIPs/pull/214/files#diff-337cc39e057923ec63cd647f0acfb835R31 might answer your questions. |
||
|
||
`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 commentThe reason will be displayed to describe this comment to others. Learn more. Is There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So far we haven't separated words in the mnemonics: |
||
|
||
## 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 commentThe 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 commentThe reason will be displayed to describe this comment to others. Learn more. My guess is that it stands for just "high level language". |
||
|
||
## Backwards Compatibility | ||
|
||
This proposal adds a new opcode but does not modify the behaviour of other opcodes and thus is backwards compatible for old contracts that do not use the new opcode. | ||
|
||
## Test Cases | ||
|
||
To be written. | ||
|
||
## Implementation | ||
|
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?