EthCC 2: Dennison Bertram

hello is it is it on hi everyone um thank you for coming today so my name is Denison Bertram I'm with Zeppelin today's talk is going to be about upgrade driven development which is building modular secure upgradable smart contract applications so Zeppelin so what are we going to talk about today first we're gonna talk a little bit about who we are at Zeppelin open Zeppelin's secure modular libraries upgradability why it's important how does it work EVM packages what are they and what problem do they solve and what opportunities they offer an upgrade during development which is architecting modular systems and finally our latest product zip kit which sort of ties everything that we're offering together so a little bit about us Zeppelin we build tools for developers and operators of security centralized systems you may know us we help companies secure their systems by performing security audits we're the creators of open Zeppelin battle-tested framework of reusable smart contracts for aetherium and other EVM ball chains were the creators of Zeppelin OS a framework for creating and managing upgradable smart contracts and Zeppelin a complete toolkit for developers so first open Zeppelin so you probably mostly know open Zeppelin we're well known for creating audited contracts that follow ERC standards you can see here some information about the traction that we have on that we had 400,000 total downloads in 2018 we recently passed half a million so it keeps on moving up that's pretty awesome in this space right that's great our weekly downloads is 16,000 346 currently and we have nearly 7,000 stars on github so as a metric that's nice this is something that's really important to us in the community and we see that people like what we're doing that what we're building is helping other projects and the developers use it right this is important so a little bit about open Zeppelin we have thorough code reviews we have 100% test coverage it's audited and of course in formal review by the community and if you ever do find something please get in touch with us we're really happy to like hear from the community and have that participation so upgrade ability and upgrade ability is kind of a hot topic it's been a hot topic for a little while and tends to be a bit of contentious so we're gonna go over it and a little bit of detail on what we're talking about so basically upgradability is for the obvious right you can fix bugs you can add features you can develop faster and you can be more awesome right and this is important right so we love this model this is from xkcd my motto is move fast and break things and we tend to think about that when we think about like development and our sort of field but of course moving fast and breaking things is a horrible idea for what we do right like you you want to move as slowly as possible and you don't want to break anything right so I'm not gonna read this whole thing but this is a great quote from the morning paper basically it's talking about the challenges of developing smart contract applications when you are creating an application that you have to get right the first time that is going to run in an adversarial environment that anyone can call with any variables of their choosing arguments of their choosing and there's no legal recourse if something goes wrong right like if they Bork your system you're just exactly so the main part of that that's really wacky for us as developers is the idea that you can never change it right like the idea that we are gonna build singular monolithic applications that are gonna function today they're gonna function tomorrow and they're gonna function for the next hundred years without any updates without any upgrades without any change in what we expect our users to have is kind of wild right like that is impressed upon us by the the system that we're using but that's kind of a crazy idea so to give you a little example here just gonna walk through it I'm not gonna get too technical but basically here my contracts right my wallet it's initialize Abul and we have a function and initialize their initialize is a special function in Zeppelin OS which replaces the use of constructor functions for some technical reasons that I won't get into right now but so let's say this is your contract right you do it using Zeppelin OS the process of deploying is you add your contract to your project you push the source code the bytecode actually to the network and then you create an instance of it and then you have my wallet version 1.0 right it's awesome it's great it come fills all the needs that you had when you originally built your software first time around but let's say now you want to add features to it right so in this case we go back to our my our my wallet contract and we add a new function right in this case withdraw right pretty simple when we go ahead and we use Zeppelin OS 2 first we push the code the byte code to the network and then we update our wallet which links it to our new implementation of the logic note we have the same address right there right like that hasn't changed so we have the same address we have the same storage state we have the same balance but we have new code right my wallet version 2.0 ladies and gentlemen right but there's a particular reason why I've chosen this picture right and I'll get into that a little bit later I don't know how many of you know this car but this car is really famous for some particular particular aspects about it we'll get into so first of all how does this work the most important thing is to understand this is not magic right this is not a magical process this is not a black box and this is not a huge behemoth of code that enables this sort of functionality what we're using is transparent proxies and I love this quote one of our colleagues came up with this but thank you Mario but our implementation is in another address right so the way this works I'll go into just a high-level overview of this is basically we're using a proxy which proxies your call using delegate call to the logic right and the important part of this what this means is your proxy is keeping you the storage right because your proxy when you delegate call through our proxy or your proxy in this case you are calling the logic function in the context of the proxy so the storage is always there it's not in the logic right so if you have an e rc 20 contract as your your logic right and you you let's say you deploy it and you say okay this is gonna be Denison's token right you deploy its Denison's token if i were to call the logic contract directly you would say i'm Denison's token but if you were to call it through a proxy contract right it wouldn't say anything until i initialize it through the proxy contract so through the proxy contract I call it Denison's other token right I'm using the same logic but the proxy keeps its own storage it has its own state so what does that mean right that means because we are using implementations right our proxy is pointing to where it delegates our contract calls we can change that right so we can tell a proxy hey this was my wall at version 1 and this is my wall in version 2 and we can simply change where we're pointing to so now in this case when the proxy is calling my wallet version 2 it still has all the storage from the proxy right so all the stores the name of your ERC 20 contract it's all there it's not in the logic contract right so we can point that around as much as we want so same state this is the important part same state new logic right amazing right this is great stuff I'm going to talk about this in a technical way on Friday so please come by it's a little bit early but we're gonna actually do a live coding workshop we're gonna go through this on a technical level I'll explain it in more depth and show you exactly how it works and we'll go through it so if you're interested you can sign up it's at friday little early but it's at consensus take that link just sign up and then you know we probably won't have too much time for technical questions here so you'd really be able to like rip me apart there so EVM packages so if you think about what I just showed you there's probably something that's slightly obvious right well maybe not entirely obvious but if we have a proxy and that's what's keeping state and we're just using the logic in the logic contract right that means we can create as many proxies to this logic as we want right because the storage is always in the proxy it's always calling it in the context of itself right everyone in this case has their own instance of the logic contract so if that's an e rc 20 right proxy one that might be Dennison's ERC 20 a proxy two might be someone else's so we can share the same logic but we don't share state right not commingling our state so this is example of different tokens right you can make as many years C 20 tokens as you want and we only deploy we only deploy the ERC 20 logic once so EVM packages are a feature of Zeppelin OS and something that we're working on it sort of falls into the realm of the research being done on doing package management but what we can do what Zeppelin OS allows you to do is allows you to build a project where we keep track of the iterations of your code right so let's say this is a RC 20 version 1 and then you create your C 20 version to remember when we do that commands offs push this code is living on chain right this is already deployed we don't have to redeploy that Zeppelin or less allows you to iteratively build packages where you say hey this is my first version of this contract here's my second version and this is deployed on chain so that allows people who are using your EVM package to choose which version of your code they're using right so this allows you to do something really powerful this allows you to deploy code it early update add features and the people who are linking to it whether it's your project itself or other people that you're sharing publicly they can choose the implementation that they link to right so what problem are we solving here potential cost savings right if you have a contract that's doing a factory functions or a factory contract contract factory where you are just deploying contracts over and over that gets really expensive if you're deploying a million instances under your C 20 why are you paying to deploy any RC 20 every time our proxies are very lean they're very cost effective so if you just deploy the proxies right you have an enormous potential gas savings security this reduces bugs because you're linking to on chain code right you can verify this code on chain you can see the source code what you currently do and something we highly discourage in the open Zeppelin libraries is people tend to copy and paste from github right and sure that's a quick and easy way to get yourself in ERC 20 token that's an also a quick and easy way to really mess something up right so one of the things that you can do with this now is you can have secure repositories of code right you can have instances of code that you know are safe and when you deploy another ERC 20 you know that you're deploying the same audited smart contract that everyone else is using right so you add to your safety we can create composable smart contracts now right so something that people do with open Zeppelin is they do a lot of inheritance right you inherit from the Year C 20 and then you add functions and features to it something that we saw a lot during the ico boom was people were taking the ERC 20 specification inheriting from it adding functions to manage the crowd sale pay out dividends this type of thing right but the moment you do that you lose those security guarantees right because we don't know what's happening inside your code you don't know when you're introducing bugs and also you're mixing your commingling purposes right your commingling focus of your code right the ERC 20 token that should be responsible for securing your digital assets right that should be responsible for securing your tokens that is not supposed to be selling itself in a crowd sale right like that's another type of functionality and that's what we saw a lot happening with the opens up in libraries people were inheriting from them right now we can do composability now you can link to these contracts on chain and call them as you would a normal contract but now you don't have those fears about mixing the type of functionality that you're supposed to be getting private code libraries a project can only link to whitelisted code so this is maybe you're on a side chain and you have a large organization around the world developing maybe you have a repository of verified whitelisted code that your developers can use right like you don't want a situation where a developer is copying pasting from github late at night just to get something done you can say hey if you need it e rc xx this is our enterprises verified ERC 20s you have to use this code but it goes beyond that right maybe it's data structures we have a some of our partners have created data structures as EVM packages so you maybe you're linking to doubly linked lists live peers created a doubly linked list EVM package so you can say hey we need a data structure for our contract that goes beyond what you can get with traditional arrays or solidity data structures right but you can say we're using this verified instances of a data structure and long term we're looking forward to a rich world of shareable code right we're looking forward to the idea of what what NPM did for the JavaScript ecosystem we would like to see that happening in the solidity in the etherium ecosystem as well if p.m. is also a very well known project and that's the same kind of idea what we're trying to do is get people to share code so our development can be faster so we can be more welcoming to new developers so we can be more accessible right so open Zeppelin ETH is an instance well it's a version of our open Zeppelin solidity contracts we already have the ERC 20 year C 721 payment slitter splitter and token vesting deployed so you can link to those already and we've updated the open Zeppelin contracts to be compatible with Zeppelin OS right so all of these will work out of the box so upgrade driven development right what are we talking about with this traditionally when we've been building these smart contracts we've been thinking about single entities that we're building now and they'll never change and they'll be immutable and there's a real value proposition for that right we're not saying that nothing should be unafraid of all if applications can be upgraded however the question that we always get and is very important is who decides when and what to upgrade right this is a big question so important is in this with evm packages with upgradability upgradability can has little governance as necessary or desired or as much right this is something you get to decide in the EVM packages that I showed a few slides ago we can't upgrade your code for you right as somebody points to your code no one else can upgrade them against their will right this is something that each developer each user can decide so looking back our app version 1.

0 right version 2.0 but of course we know what's gonna happen right if you do that overnight surprise this is what your new application looks like to users people of course they freaked out right so governance is really an important topic here and there's a reason why I chose this car right this car it looks sweet it looks amazing but when it came out I don't want to say it sucked but there were a lot of really important problems with it right for example that window in the front there right like right there that was how you got in and out of the car but the seat was so reclined that it wasn't possible for you to get out of the car by yourself someone actually had to pull you out of the car to get you out right so the designers right in this case you can think of yourself as the app developers you think sweet everybody's gonna love this but maybe they're not maybe are gonna introduce bugs maybe you're gonna introduce other problems so for governance I don't know how well you can see this clearly but what we have here is so here's the proxy right but you can use multi SIG's you can use dows you can use voting contracts to control these proxies these don't have to be things that just the developer has control over if you think of something like a game right a blockchain game where you have three different components you have the thing that stores the users tokens you have the gameplay and then you can have some sort of interface for external applications right those three things can all be upgradeable if you build them as EVM packages they can all be composable right you can keep the functionality separated and isolated and the governance mechanisms that you can use for it can vary based on what the deeds are right maybe the interface is something that the developers of the company should be responsible for dealing with right maybe you trust them to handle the interface maybe there's a Dow that organizes and controls the the playing the game mechanics right the players get to decide how their game is gonna be playable in the future and then maybe no one can upgrade the tokens right maybe the ERC 20 is fixed forever but it also means is you can do selective upgrade ability now right and that's what I just mentioned right you can choose what piece of your application can be upgraded how it can be out upgraded and you can use things like EVM packages and composability to separate the parts of your application so maybe in the future version 3 of your app looks something more like this right so if you start abstracting out these aspects maybe the users get decide with the tires on their car app car app look like maybe they get decide how the car drives or what sort of engine it is right maybe they have the ability to choose all these different versions than that so something that this brings up then of course in the governance is the idea of trust and this is kind of like a nice quote users generally trust tinder to match them with hookups right and I'm sure some people in the audience here use tinder but the question is do you trust tinder with the messages you send to the people you hook up with right and that's an interesting paradigm because up until now your trust in applications has been binary it's been monolithic if you agree to use Facebook you have to trust Facebook completely with all aspects if you use tinder you have to trust tender completely with all aspects and we know that not all aspects of Facebook are good custodians of our trust in the same way right we trust them to update our pictures we don't trust them with the content of the pictures or social network or a graph so upgrade different development trusts no longer needs to be monolithic for our applications right we no longer have to build applications where we were requesting all-or-nothing trusts from our users we can now involve our users in this discussion in this process so upgrade different development this is something I'm working on it's a work in progress I really appreciate feedback but it's an iterative process right that builds on the idea that you you create something you put it in production you upgrade it right just the same way you do test-driven development which has become the norm you do upgrading different amount driven development you pass tests but the ultimate test is how do the users use it right because in that slide way back before we're doing something really special we're developing software in an adversarial environment we are we have no control and no recourse right there's no unit tests that are gonna really test how users use your application in the real world there's no unit tests that are gonna show you how your application plays nice with all the other applications on the blockchain right so it upgrade different realm is also design consideration that when building upgradable software on immutable networks users have different expectations of us right you may be building a simple game but you may be holding someone's life savings in that game at the same time right that's different from candy crush right if candy crush loses all your gems nobody gets hurt maybe people are a little bit hurt inside right like but nobody gets hurt but we're building games we're building simple applications that can really hurt people right it is the understanding that the shape of the networks that we build on our fluid and require robust non fragile software right like move fast and break things that's great but you got to be able to fix it too right if you break something and you swallow up millions of dollars of somebody's money you got to fix that as well you have to have that ability but you have to have the proper governance for that as well software can be abstracted into areas of upgradability responsibility and governance we went over that that's the composability of smart contracts right and something that comes up a lot now is that as we see more people moving to side chains the cost effectiveness goes up right before in some of these cases right you might say hey I'd love to compose my software but that's gonna add a lot to my costs well now if you're developing a loom if you're developing on X I if you're dwelling on side chains right maybe that's not so much of an issue anymore right we've seen in the past couple years this drive to move as much application functionality engine allottee off chain right and what is that done in some ways it's made our creativity and solving problems go up but in some ways it's made the software that we've create become less creative on the blockchain right there's things that we can't do on the blockchain because of that but now especially with side chains we can and so users can participate in the shape and design of the software they use right so that's something I went over before right you can involve your users in this testing process you can involve this users in this governance process so finally we exact kit and Zep kit is our latest offering and Zep kit is an all-in-one tool kit right Zeppelin RS it includes well not all that stuff but the problem that we're trying to solve with Zep kit is if you're getting started with an app today if you're doing the hackathon this weekend there are too many options right for what you wanted to build and develop on we have too much boilerplate or you have to do too much before you can actually launch something and test sotas test something there's too much friction and there's simply too many pieces in the ecosystem right now and a big problem that is not all the pieces work right and not all the pieces are interoperable so when you're getting started there's a lot of friction to going from zero to an app so we're trying to do is that kit is we're trying to reduce this friction and this is a new offering so we're really looking for feedback and input to add things that people are looking for it includes open Zeppelin as evm package so you already have that in there you already have open Zeppelin zeppelin OS keeps track of EVM packages so you already have the ability to deploy a or C 20s which are already on the main net if upgradable smart contracts of Zeppelin OS we include in Fuhrer you have a token API key already in Zep kit so you can deploy right away you don't have to go through the friction of like signing up and getting a token API key we have truffle to compile and test your smart contracts reactant Trimble to build usable and friendly interfaces and we're adding things more and more right so we just had a announcement yesterday regarding our cooperation with tableau key and the gas-station network these are things that we're looking to build in we're looking to hear from developers what they want to have you know one-click access to when they're developing so they can get started so show me what you got that's basically like go out there build stuff you know try things right experiment with things these are these are new ideas they're kind of crazy certainly upgradability has been in the community for a while but it's really discussion of how do we make this something that we use join our forum if you email me you can get a copy of these slides also on Friday we're going to be doing the live coding workshop so you'll be able to come and really like tear me apart I don't know how much time left for questions here and of course your high rating we're really moving fast right now and we're hiring aggressively so please drop it email two jobs at supple in solutions if you're interested we're looking for a wide variety of profiles because we're building some awesome stuff and we want you guys to be part of that so thank you [Applause] questions my question is really simple will we ever have proxy contracts without the interfaces can you be more specific yes I mean I've been working on a period of a pre credible contract and I see that a limit as a limitation we have to on the proxy counter to define the interface right because then with the delegate course you have to specify the function under the hood so the question is could we have a fullback function maybe in the proxy contract able to redirect to the call to a proper function implementation talk to you more about that cuz I I think I understand it one way but maybe maybe you mean in a different line certainly you can call arbitrary functions with the proxy well let's talk after I'd like to understand better what you mean yes right nice eloquent talk what so with an ether scan it's really hard to audit and browse the code from projects that use upgradeable contracts and imagine it's gonna get it way more difficult when you have tons of functions from a bunch of different proxies so what's a good way of reading a live contracts source code if it uses that win OS that's a great question I'm so glad you asked coming actually in a future version of the Zeppelin OS I believe in two point three there's the ability to verify contracts with Eastern or scan directly from Zeppelin OS so you put in your ether scan API key and then Zeppelin OS will verify the code on either scan so yeah that's something we're concerned about and we're making sure that we have support for I'm not really familiar with the latest development of the Zeppelin noise but I'm familiar with ERC 1538 with a transparent I'm talking and familiar I'm not if you are familiar with ERC 1538 transparent proxies basically what do is for each function calls they look up a table which delegates to use for each member function so you do have similar functionalities or how can a proxy basically divide its goal between different delegates so I think you're talking about there I I didn't look at this in depth but I think you're talking about there is an EIP that talks about doing upgradability on a function level right um so definitely Zeppelin looked at that so I believe that name of that was the V table implementation that we looked at initially when we were investigating upgradability they did decide against it for a couple reasons which I don't know offhand I think it had to do with the fact that it's a little bit more cumbersome to do it's certainly a process of process that you can do I'm not entirely sure if that necessarily gives you an advantage over the composability of EVM packages in and of itself right like if you have a contract that's dealing with specific type of function right that you've isolated into just its its functionality then if you're changing a function inside of that like pack of functions maybe you're better off creating just an entirely new implementation than just upgrading per function basis but yeah oh yeah that's true that's true um we definitely thought about that there were some discussions that I wasn't a part of about that we could certainly talk about it more I think so far that hasn't really been a problem you certainly could abstract your contracts into smaller pieces but I get what you mean you get around the the limit I would love that we have a future where smart contracts are all that big though that means we're building great software cool thank you so much for coming and once again on Friday if you want to tear me apart we'll have a live code thank you