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

VIP: Denote Static Call per Method in Contract Interface Definition #770

Closed
fubuloubu opened this issue Apr 9, 2018 · 1 comment
Closed
Labels
VIP: Approved VIP Approved

Comments

@fubuloubu
Copy link
Member

fubuloubu commented Apr 9, 2018

Preamble

VIP: 770
Title: Denote Static Call per Method in Contract Interface Definition
Author: @fubuloubu
Type: Standard Track
Status: Draft
Created: 2018-04-09

Simple Summary

Current method of defining contract interfaces decides whether to static call all methods based on the usage of the modifiable/static keyword. Suggestion would make this per-method.

Abstract

Currently, to work with external contracts, one must supply a keyword denoting whether to make calls using STATICCALL opcode for ALL methods in a external contract variable, e.g.:
https://github.com/ethereum/vyper/blob/22be6dbae5a767a2d5525deb7cc93c45860e1982/tests/parser/features/external_contracts/test_modifiable_external_contract_calls.py#L14-L18

Current method assumes all methods are state modifiable if modifiable keyword is used when referring to a variable storing that contract's address. This means if you would like to safely interact with a contract that implements multiple methods, only some of which are state changing, you will need to define two variables to do so, or always call read-only methods with a regular CALL opcode.

Proposed method would make this per-method, as detailed in Specification.

Motivation

This increases utility of the contract interface mechanism, and increases transparency into which calls should be made statically, and which are allowed to modify state.

Update per VIP #748 would make this syntax mesh much nicer than it currently will.

Specification

Proposed syntax would be (using Basic ERC20 interface standard):

contract ERC20Basic:
    def balanceOf(_owner: address) -> uint256: static
    def totalSupply() -> uint256: static
    def transfer(_to: address, _amt: uint256) -> bool: modifying
    # Other methods not implemented in interface are not callable

token: ERC20Basic

@constant
@public
def tokenBalance() -> uint256:
    return self.token.balanceOf(msg.sender)

@public
def giveMeTokens():
    self.token.transfer(msg.sender, self.tokenBalance())

We could also change the contract keyword (which is a search/replace for class) into interface, which I think makes the purpose clearer for these external contract interface types.

Backwards Compatibility

Not backwards compatible, modifies syntax for interface definitions

Copyright

Copyright and related rights waived via CC0

@jacqueswww
Copy link
Contributor

Approved, naming is still under consideration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
VIP: Approved VIP Approved
Projects
None yet
Development

No branches or pull requests

2 participants