-
Notifications
You must be signed in to change notification settings - Fork 5.3k
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: STATIC_CALL #116
Comments
would there be anyway for a contract to dectect if it was in static mode or not? |
Suppose contract C has code |
Sounds great! On the solidity side, this opcode could be utilized by all calls into functions marked as |
This looks like a good feature to me as well. However, do you think there is a time to do a step back and see our call system from higher perspective? Just to know what design decisions where wrong, what is missing, and where should we go in the future? |
Agree with @chriseth that this nicely matches with what is marked as constant in Solidity and the ABI. Also agree with @chfast that probably quickly adding different call semantics might not be the best approach, when the system could be reviewed in the first place with all the experience gathered so far over the 11 months of public testing. |
So far we have CALL and DELEGATECALL (as far as I can see CALLCODE is useless now that DELEGATECALL exists). DELEGATECALL is essentially a hack that makes an account's code de-facto mutable. I don't think changing CALL is viable given how many contracts are relying on it. I think CALL/STATIC_CALL has precedent because C++ and other languages have a notion of "constant functions"; this is just what is necessary to make constant functions actually constant in a multi-user multi-contract environment where some of the things you're calling may be black boxes. We could also come up with other calling styles (eg. SANDBOXED_CALL in #117, which (in my modified interpretation) adds the restriction that the call can only change state in the destination address). |
This is easy enough to implemen. Why STATIC_CALL rather than CONSTANT_CALL? |
Because the |
Is there a way to call a function without putting that function onto the consensus state of any contract? |
I think this is a step in the right and the wrong direction at once. To gain a lot from this we need a few concepts;
|
On the solidity side we will soon distinguish between functions that do not modify state but can read state and actual pure functions which only depend on their arguments (and not on the state). Adding |
@chriseth seems like we had the same idea: https://www.reddit.com/r/ethereum/comments/5256ht/ethereum_20_mauve_paper/d7jbt9h. See also @vbuterin's answer. |
@chriseth actually, the original proposal above allows the use of |
@axic yes, my comment was about adding both |
Another idea about redesigning the call opcode: Currently, solidity performs a basic check to see whether the called address is at least a contract (it cannot check any further type information, but at least this creates some basic protection). With #150 this makes calls even more expensive on the gas side but not on the resource consumption side. In light of this, it might be good to provide a way to automatically include the |
Replaced by #214 |
If
block.number >= METROPOLIS_FORK_BLKNUM
, then opcode0xfa
functions equivalently to aCALL
, except it takes 6 arguments not including value, and calls the child with aSTATIC
flag on. Any calls, static or otherwise, made by an execution instance with aSTATIC
flag on will also have aSTATIC
flag on. Any attempts to make state-changing operations inside an execution instance with aSTATIC
flag on, including nonzero-value calls, creates, andSSTORE
,SSTOREBYTES
orSUICIDE
operations, will instead throw an exception.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.
The text was updated successfully, but these errors were encountered: