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: Interfaces #885

Closed
fubuloubu opened this issue Jun 9, 2018 · 9 comments

Comments

@fubuloubu
Copy link
Member

@fubuloubu fubuloubu commented Jun 9, 2018

Preamble

VIP: 885
Title: Interfaces
Author: @fubuloubu
Status: Draft
Created: 2018-06-09

Simple Summary

Have contracts specify and implement interfaces.

Abstract

We need a succinct way of describing how our contracts implement interfaces that is intuitive and easy to understand, so that we can do pretty standard things like write compliant tokens.

Motivation

Currently there is no way for contracts to actually import an interface, only use standard ones we define. When we add the capability to import, we will very soon need a way to actually have a contract implement them.

Specification

from vyper.interfaces import (
    ERC20, # External Contract Type
)

# Mostly to inform compiler to do error checks described below
implements: (
    ERC20,
)
  • Compiling this contract will raise an UnimplmenetedInterface Error if any standard ERC20 function (totalSupply(), balanceOf(), transfer()) is unimplemented.
  • Compiling this contract will raise a UnimplmenetedInterface Warning for each optional ERC20 function (approve(), allowance(), transferFrom()) that is unimplemented.
  • Compiling this contract will raise an UnimplmenetedInterface
  • Compiling this contract will raise an IncorrectInterface Error if the interface is not implemented correctly.
  • Compiling this contract will raise a UnusedEvent Warning for each event defined in an interface that is not triggered in a function.

Imports from files

The vyper compiler (bin/vyper) should know how to import custom defined interfaces, which are read from the compilers execution path (pwd).

import one as One
implement: One

Which will read the one.vy contract file and make the given interface is implemented.

External contract calls

Interface should also be able to be used to make external contract calls e.g.

from vyper.interfaces import ERC20

token: address(ERC20)
# ...
@public
def test(addy: address, to: address):
     ERC20(addy).transfer(to, msg.value)

Backwards Compatibility

implements is backwards compatible.
Adding events in contract definition is backwards compatible.

Copyright

Copyright and related rights waived via CC0

@ben-kaufman

This comment has been minimized.

Copy link
Contributor

@ben-kaufman ben-kaufman commented Jun 10, 2018

I think that’s an interesting proposal. As Vyper doesn’t allow for inheritance nor imports but maybe interfaces (which have no functionality - just guidelines) can be a good use case for that.
I’m not 100% sure imports are needed (unless it’s a precompiled interface) which leads me to the next question, should we have precompiled interfaces as well?

@fubuloubu

This comment has been minimized.

Copy link
Member Author

@fubuloubu fubuloubu commented Jun 10, 2018

std in my example would probably be a group of a few "standards" such as ERC20, ERC223, etc. (Maybe Plasma?) internal to the compiler.

Vyper has no current use for imports, this is the most obvious thing that requires it. The next step from defining a standard library is to allow importing packaged interfaces using ethPM from registries such as Zeppelin, Aragon, etc.

Finally, importing these from your own project would be very helpful (e.g. header files in C), and enable slightly more complex smart contract systems to built up where each contract can talk to each other using interfaces.

I do think when we figure out whatever extension model works for us, that will be another use case for imports (e.g. my composed types proposal), but these three work for now and are broadly useful in and of themselves.

Note: This VIP is restricted to these three use cases.

@ben-kaufman

This comment has been minimized.

Copy link
Contributor

@ben-kaufman ben-kaufman commented Jun 10, 2018

Sounds good to me.
My concern with importing code is the possibility of unknowingly importing malicious code. But of course with interfaces that’s not the case.
So I think the use cases you detailed can be very good.

@fubuloubu

This comment has been minimized.

Copy link
Member Author

@fubuloubu fubuloubu commented Jun 10, 2018

Yeah, the extension aspect of things is really tricky, it definitely opens up a whole new vector for malicious code and overall can reduce auditability if used poorly. But if used well, only with pieces of code that have been well audited (import through packages or including in the compiler) or as a part of your internal smart contract system (if used sparingly), it can enable a wider amount of use cases without compromising security and readability.

@jacqueswww jacqueswww referenced this issue Jun 18, 2018
1 of 8 tasks complete
@jacqueswww jacqueswww added the Approved label Jun 18, 2018
@fubuloubu fubuloubu added this to To do in Release Candidate! Jan 24, 2019
@fubuloubu fubuloubu added this to To do in Fix the Beta via automation Jan 28, 2019
@fubuloubu fubuloubu removed this from To do in Release Candidate! Jan 28, 2019
@jacqueswww

This comment has been minimized.

Copy link
Collaborator

@jacqueswww jacqueswww commented Jan 28, 2019

Phase2:

  • Allow External Calls using interfaces.
  • Optional importing of JSON ABI signatures.
@fubuloubu fubuloubu removed this from To do in Fix the Beta Jan 28, 2019
@fubuloubu fubuloubu added this to To do in Release Candidate! via automation Jan 28, 2019
@jacqueswww jacqueswww moved this from To do to In progress in Release Candidate! Feb 26, 2019
@jacqueswww jacqueswww moved this from In progress to Done in Release Candidate! Mar 4, 2019
@fubuloubu

This comment has been minimized.

Copy link
Member Author

@fubuloubu fubuloubu commented Mar 4, 2019

@jacqueswww is Phase 2 complete? I think we should wait to close until it is all done.

@jacqueswww

This comment has been minimized.

Copy link
Collaborator

@jacqueswww jacqueswww commented Mar 4, 2019

Yep it's done, just a doc fix and we can close.

@fubuloubu

This comment has been minimized.

Copy link
Member Author

@fubuloubu fubuloubu commented Apr 4, 2019

@jacqueswww have the docs been updated?

@jacqueswww

This comment has been minimized.

Copy link
Collaborator

@jacqueswww jacqueswww commented Apr 4, 2019

Yes, they have! :)

@jacqueswww jacqueswww closed this Apr 4, 2019
@fubuloubu fubuloubu removed the discussion label Aug 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
3 participants
You can’t perform that action at this time.