 Let's see. Hello, everybody. I'm Piper. I've been working on a lot of things in the Ethereum ecosystem since the Frontier Network launched. And 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 AAPs repo as well as in a dedicated GitHub repo for this specification. So what ERC 90 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. Packages at ERC 190 packages can include a number of things, full source code for the source files, assets that have been pre-compiled, 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 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 Ethereum mainnet case, which is a place where we don't wanna 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 bytecode 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's not really useful on its own, but it is useful 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. It is a JSON document. It defines a couple of bits of metadata and it uses a content addressable URI, an IPFS URI to reference the actual source code. And then if you pipe that lock file from the previous version, by the way, we use the term lock file. It's roughly interchangeable with package. Then this right here is the actual IPFS 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 owned. 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 entire dependency tree immutable because everything is using content addressable URIs. We can move on to things like ready to use contracts, like a ready to go ERC 20 contract that can just be used right out of the box. Here's some, we've got two source files here 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. Now, this is where we get into different use cases. If this were a package I was using on the mainnet, 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 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 mainnet or just supporting Robston or some 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 which contract did we deploy, what address can I find to that. 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, 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 EtherScan 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 munge together all of your source code into one file. You've got to pick the exact right compiler version. You've got to refer, 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 EtherScan 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 sort of thing. If we replace this 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 there is not enough information to verify this or it can even just let you browse the source code. But this right here is 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 Python library here that makes use of some mystical SHA-7 package and rather than needing an implementation of SHA-7 in 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 wanna back up and talk about package indexes. This is sort of the default state of the world right now is that package 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 PyPy, 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 package index and that is actually really easy with the Ethereum blockchain. So with a reusable implementation of a package 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 package index where they are in full control of all of their packages. Now how this relates to the standard library, so 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 MakerDAO teams and deployed a couple there, maybe Zeppelin's got some there and there's some overlap, right? Like I've got my own version of owned up here. Nope, that one doesn't overlap, SafeMath. I've got my own version of SafeMath on my side, Zeppelin's got theirs 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 can come together to form one rich reusable standard library. And while it's great that we all get different package indexes and we all have our own package indexes, I think that's the way the standard library can work too. 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 package 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 is very promising for a rich ecosystem of packages. So what do we need to make this a reality? So right now we need more support for ERC 90 and tooling. Populous has some basic support in it, same with Truffle, but 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 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 work that 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. Thank you.