Package Management for Smart Contracts

[Music] let's see hello everybody I'm Piper I've been working on a lot of things in the etherium ecosystem since the frontier network launched and today today I would like to talk to you about packaging up smart contracts so first let's establish what we mean when we say package management Thank You Wikipedia package management system is a collection of software tools that automates the process of installing upgrading configuring and removing computer programs for a computer's operating system in a consistent manner hopefully that's the last reading from my slides I want to point out the part here that says that it is a system it's a collection of software tools so we're not talking about one thing we're talking about specifications and tooling support and all of these things coming together to allow us to package up a smart contract system so let's take a look at what a smart contract package actually is so at the beginning of this year myself and a number of other framework developers came together and we hashed out what is referred to as ERC 190 this is a spec for how smart contracts can be packaged you can find it in the AP's repo as well as in a dedicated get github repo for this specification so what Air c90 specifies is a format for a JSON document it allows for all of the rest of these bullet points are effectively the same thing it allows for you to create a package that allows other people to deterministically rebuild the assets from that package to verify on chain assets or assets that are included in the package and the packages themselves are designed to be immutable which means once you have a reference to a package that thing can never change out from under you package because the packages ERC 190 packages can include a number of things full source code for the source files assets that have been precompiled ABI for contracts that are included the addresses of actual deployed assets on the blockchain and as well as sort of nitty-gritty data like link references when people are using things like libraries from solidity so that you can actually do verification all the way down the chain we also covered a number of use cases so base things like reusable contracts you can think of like the ERC 20 contracts that ship with the Zeppelin OS sort of normal common patterns like the owned pattern as well as live contracts deployed instances things like that we also made sure that we covered both the theory of main net case which is a place where we don't want to have to trust things and we want to be able to verify everything as well as stuff for private chains places where you're working in an environment where Trust is okay where potentially the packages that you're using are all made by you so you are happy to just trust embedded byte code in them rather than verifying that that matches the source code so let's look at some examples of what a smart contract package actually looks like this should be familiar to anybody who's worked in solidity this is a very standard pattern I'm sure that you can find almost this exact contract in hundreds of different code bases so this is what I call an inheritable contract this contract is not really useful on its own but it is useful when when you when you inherit from it and make use of some of these modifiers this is a very simple version of what this package looks like is a JSON document it defines a couple of bits of metadata and it uses a content addressable URI an IP FS URI to reference the actual source code and then if you pipe that lock file from the previous version by the way IU we use the term lock file it's roughly interchangeable with package then this right here is the actual IP FS URI for that package and in theory with a supporting development tool you can take this and use it to install the owned package now that's a very ugly reference to own it's not a very nice URL way to install things so we'll talk about that in a little bit here so we have a source file we have this lock file which you can also think of as a package and then we can reference it using its own content addressable URI so let's look at what dependencies look like so we can actually extend the owned concept with this transferable contract it depends on the previous example and this is what the lock file is gonna look like for that package it references the other lock file using the build dependency this build dependencies key which makes the the entire dependency tree immutable because everything is using content addressable your eyes we can move on to things like ready-to-use contracts like a ready to go er C 20 contract that can just be used right out of the box here's some we've got two source files here that that are the an abstract version of it and the actual implementation and in this one we actually include some information about the contract types themselves we say this includes the standard token contract there's maybe some meta information included with it like the ABI that allows people to use this package to interact with it and we can also include bits of extra information like the compiled bytecode and the information about the compiler that we used to actually compile this no this is where we get into different use cases if this were a package I was using on the main net then what I'm gonna do is use this compiler information to recompile this and verify that the included bytecode does in fact match the compiled output but in a trusted environment we can actually just use the bytecode embedded in this in this package cool so now let's look at what it looks like if we have a smart contract that's been actually deployed to the blockchain so this is a safe math library it does some underflow and overflow protection and this is what it looks like to package up a smart contract that has a live deployment so we have references to you can see this blockchain URI up here this is how we reference what chain this is deployed to this is also how we support deployments across multiple chains this means that we aren't locked into something like just supporting the main net or just supporting Rob's tenoram predefined set of them you can use this for private blockchains for local test chains anything like that and then within it we actually get a reference to you know which contract did we deploy what address can I find it at and then we've got some convenient stuff which are the transaction that it was deployed with or the block that it was deployed on again these are things that are easy to verify but they're convenient to include in the actual package so with packages we it enables a number of things that we can actually do with these the most obvious is just using them in our code a tool that supports these packages in theory you run some installation command you can see that on the upper left on the upper right here this is what likely results in our file system this should be familiar to people who are used to node development this is much like the node modules directory and then from within our actual code we can import these and use them but there's some really cool other things that we can do so this is the interface from ether scan for how you verify contracts and anybody who's ever tried to verify a complex set of contracts knows some of the pain points of this you have to munch together all of your source code into one file you've got to pick the exact right compiler version you've got a reference if you want to verify multiple contracts you've got to go through this multiple times smart contract packages can replace that entire thing with just a single upload since packages include enough information to verify everything instead of having to manually put all of that information in you could just upload the lock file and either scan can automatically verify every deployed instance of the contract included in that package I also think that this would be useful in wallets this is a pretty common interface for wallets give me the contract address tell me what the ABI and then I will generate an interface and you can interact with it this is often sufficient but it leaves a lot of things desired because you don't really know what you're interacting with you don't know if it's been verified that's sort of sort of thing if we replace this with with a package where you upload a package wallets can still generate the same interface but they can also show you a lot of extra information such as yes this does actually verify whenever I recompile the source code and check it against the byte code or or there is not enough information to verify this or it can even just let you browse the source code but this right here's my favorite idea come with me on a journey to the future where the EVM is everywhere where there are packages for all kinds of things and where the EVM is really fast so I think that EVM packages are capable of being a cross language packaging system and what I mean by that is that we can actually use the EVM implementation natively in our code this is sort of an imagined the Python library here that makes use of some mystical sha seven package and rather than needing and implementation of sha seven and python instead we use the EVM implementation in our code and I think that's really powerful because that means that we can have single well tested battle-tested implementations that are then usable across many different languages so let's talk about the standard library so to talk about the standard library I actually want to back up and talk about packaged indexes this is sort of the like default state of the world right now is that packaged indexes are centralized there's often sort of one centralized system that handles all of the packages for an ecosystem we've got NPM we've got pi PI we've got whatever else is out there but this is what I'd like I'd like everybody out here to have their own packaged index and that is actually really easy with the ethereum blockchain so with a with a reusable implementation of a packaged index contract a contract that manages tracking versions and tracking what packages are available that plus a little bit of tooling integration combined with ens means that we have a very easy system for every team to set up their own packaged index where they are in full control of all of their packages now how this relates to the standard library so and and this is a theoretical way of how you would install this we've got the part on the Left which is handled by the dev framework and the part on the right which is the namespace piece which is handled by ENS so our ecosystem might look like this maybe I've deployed a couple packages to my index maybe the Maker Dow teams and deployed a couple there maybe zeppelins got some there and there's some overlap right like I've got my own version of owned up here I hope that one doesn't overlap safe math I've got my own version of safe math on my side Zeppelin's got they and the idea here is that somebody can then come along and pick and choose out of each of these different indexes which ones they think need to come can come together to form one rich reusable standard library and well it's great that we all get different packaged indexes and we all have our own packaged indexes I think that's the way the standard library can work - it can look a lot like Linux where there's different flavors of the standard library where there's different curators and different people who've picked and choose which packages from which place they think make up the best standard library which means we're not stuck with one packaged index we're not stuck with one standard library but we actually have a lot of choice to pick and choose this can be thought of sort of as the spread a bunch of seeds and see which flowers bloom but I think this has some is very promising for a rich ecosystem of packages so what do we need to make this a reality um so right now we need more support for erc 90 and tooling populous has some basic support in it same with truffled but in we need more tools to support this we need a standard implementation of a package registry something that we can ship around in those tools so those tools can set them up for us and then we need automation for setting these registries up and that's both automation for deploying them as well as automation for getting the ens piece tied together and we need a feature request into solidity and other EVM languages to allow us to inject pre-compiled byte code into the compilation process and the reason for this is that as our package ecosystem grows we're gonna have many different versions of solidity that are required to recompile certain things and in order to require compile a very complex dependency tree that has lots of different versions of solidity we're gonna need to be able to compile all those individually and then slowly combine them together into one big compiled asset so there's gonna be some compiler or if it has to be done but in general most of these pieces are at the 80% mark or more we're very close to this and all of this is about ready to come together thank you [Music]