Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Have contracts specify and implement interfaces.
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.
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.
from vyper.interfaces import ( ERC20, # External Contract Type ) # Mostly to inform compiler to do error checks described below implements: ( ERC20, )
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)
Copyright and related rights waived via CC0
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.
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.
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.