Vyper: VIP: Interfaces

[fubuloubu]

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]

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]

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]

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]

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]

Phase2:

• Allow External Calls using interfaces.
• Optional importing of JSON ABI signatures.

[fubuloubu]

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

[jacqueswww]

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

[fubuloubu]

@jacqueswww have the docs been updated?

[jacqueswww]

Yes, they have! :)