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.

Sign up for GitHub

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

Jump to bottom

New opcode: STATICCALL #214

Merged
merged 12 commits into from
Dec 4, 2017
Merged

New opcode: STATICCALL #214

Changes from 2 commits
Commits
Show all changes
12 commits
Select commit Hold shift + click to select a range
d4a9172
Add STATIC_CALL opcode.
chriseth Feb 13, 2017
3ea17dc
Updated preamble.
chriseth Feb 14, 2017
a23bd30
Rename static_call to staticcall.
chriseth Feb 24, 2017
bee4515
Some clarifications and extensions.
chriseth May 18, 2017
5e0c5f3
Clarify resetting the static flag.
chriseth Jun 1, 2017
2a7e445
Small fixes.
chriseth Jun 16, 2017
2d2d028
Clarify value argument.
chriseth Jul 3, 2017
2da707c
Add log0
chriseth Aug 24, 2017
12257d5
Move static_call.md to eip-214.md
pirapira Nov 20, 2017
b550ed7
Tiny fixes
pirapira Nov 27, 2017
d8f5c84
The status is already Final
pirapira Nov 27, 2017
b1623c2
Update eip-214.md
chriseth Dec 4, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
40 changes: 40 additions & 0 deletions EIPS/static_call.md
View file
Open in desktop
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 <vitalik@ethereum.org>, Christian Reitwiessner <chris@ethereum.org>;
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

Copy link
Member

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?


## Specification

Opcode: `0xfa`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not 0xf5, just after the DELEGATECALL?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@chriseth @vbuterin same question, any reason to skip 5 opcodes?

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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.

Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this now stay at 0xfa? Also, what is the gas cost for this opcode?

Copy link
Member

Choose a reason for hiding this comment

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is SSTOREBYTES an instruction?

Copy link
Contributor Author

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.

Copy link
Member

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.


## 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

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.

Copy link
Contributor Author

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".


## 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