Santiago Palladino: OpenZepplin | ETHDenver

so what I want to do now is introduce someone who's working on a very crucial function and piece of the etherium ecosystem smart contracts to paraphrase my friend Piper Marion smart writing smart or smart contracts is a lot like writing code for the Space Shuttle if something screws up it can screw up in a very very large way with negative repercussions for interested parties and you know we've seen this so over and over again so our next speaker is Santiago with open Zeppelin open Zeppelin is a smart contract security function or a service that's aiming to fix a lot of these issues before they happen so let's give it up for him thanks for the intro guys thank you for being here okay Jaime okay hello can you hear me okay okay perfect well thank you all for coming well my name is Santiago I work at Zeppelin we're consulting and auditing firm we have been working with many of the folks here actually we have worked with the ogor priests mommies we've been working with the people from storge brave golem and few others and besides our auditing services we also work on open sampling which is what we'll be reviewing today and we're also working on supporting OS as you can see on my t-shirt which is the upcoming project we're working with we'll discuss it by the end of this talk so well first of all what is open suppling what has been already quite a good intro but basically it's a set of reusable smart contracts open source generate purpose for you to bootstrap your project and build on top of them and get for free a lot of features which are already reviewed under DT and contributed by the community the focus in opens a plane is in security which is also basically the main drive behind open setting the reason why opens up when came to exist I'm not sure if you guys are familiar with the list their butts basically a compilation of famous hacks on on solid smart contracts which account for several several millions of dollars so basically the idea of open supplying is to provide a secure base a secure set of smart contracts for you to build a top on them to try to prevent this kind of hacks by providing a secure base for you to build their projects on top so open sibling was presented about a year and half in DEFCON two with the idea to try to address this kind of problems since then adoption has been skyrocketing we have around 3,000 weekly downloads of the framework we have a very very active slack community with around 300 people weekly it's not just regarding open 17 development but you can also find discussions on general etherium development blockchain development it's actually very very active community or welcome to join we account for about 4.5 billion u.s. dollars that are currently running on the 3m blockchain using open selling contracts this is basically just some of the projects that we know that make use of open Zeppelin the total market cap combined and the project the rap on github right now has about a hundred contributors actually we'll be very happy if during this hackathon after this Kassadin we can also count some of you guys among that set ok so what is the design guidelines behind open Zeppelin well first and foremost security which was the driver behind the framework and what what actually motivated us to build it the idea is to make sure that every single line of code is thoroughly reviewed ID secure for you to use and the next goal of the framework is for it to be simple not as simple as in easy but simple made easy we want to make sure that it's modular that it's clear to use that it's contract has a very defined responsibility we basically believe that clear code and that's also we're naming matters comes in that code also leads to secure codes that if it's clear what each of your contracts and each of your functions is doing then it's easier for you to write something secure everything in open zip line is of course totally tested has quite a large suit of unit test that the trainer never commits and good they're also runtime assertions to make sure that all preconditions all environments on the contracts that are deployed there hold you also notice that even though we have about 200 different contributors the code style is pretty consistent the code base is pretty uniform and also all major releases are audited and we're also working with external auditors to have audits on every single release even though we Arnold it firm ourselves we believe that it's not a good practice for the same company being behind the development and the auditing of the same product so let's get started open so point is distributed as an NPM package so installation is just via NPM please please don't copy paste the contracts don't attempt to modify them directly don't go directly into master and github and copy/paste whatever you find make sure you're always working with the release if you just stumble into github and copy whatever you find you may find an intermediate version that it's not that secures will like to be always always work with the with the latest release basically the way open sibling works is by having a set of base contracts from which from which you can extend and basically they will provide different features to your contract or you can extend from one of the different verticals we have so you don't have to re-implement everything yourself canonical example would be if you want to build your own crowd with your own token rather than implementing all the functionality from scratch you only need to extend from you don't see anything you only need to extend from crowd-surf contracts or rear-seat 20 contracts and basically sprinkle whichever other functionalities you want to add let's say you want to have a token that can be post but UK you can actually inherit from possible which will add try it for a small contract to be post in case of an emergency we'll actually deep dive into all of this during this talk but basically so you have an idea it's a set of smart contracts from which you can extend and override as needed if you want to implement custom functionality so let's go into the code Rica multi reference so basically the first thing we have been open sibling is a library called safe math for those of you who don't know all that if medic operations on solidity are unchecked meaning that if you are adding two integers and it's overflows it will simply wrap around and you will never know same happens create division or division such ok same happens with multiplication same happens with abstraction so it's a good practice rather than using directly the earth medic operations in solidity to use one of these wrappers that basically execute the operation and check that there hasn't been an overflow so we provide the safe map library which actually the implantation is very simple just executing a function and make sure it's okay there you will see there are methods for all the form based health medications usage is pretty simple let's say you have a contract that performs regular medical operations what you want to do is just add the using keyword in solidity that allows you to call the library methods directly on that object and just use one of whatever they are admitting method you need it ideally you should not have any plus signs or minus signs or your code you should be delegating everything to save math to make sure that you're not in the risk of falling into an overflow what else well nowadays tokens are pretty much everywhere on the theorem ecosystem the most widely adopted standard is ear TLC 20 if you want to roll out your own ear see 20 standard you basically need to implement all those methods basically for gathering what's the total supply of the token querying the bands of someone transferring approving transfers and a few more so opens happening already shapes with a thoroughly reviewed employee station of the year sea chantey token meaning if you want to implement your own token you only need to extend from standard token and basically define how the token is going to be initially set up the most simple example is you define an initial supply and assign that supply to you basically the owner that the person could deploy the contract of course using this you can build whatever else you want but this is pretty much one of the easiest flavors of smart of year c20 token that you can deploy usage is straightforward you just deploy the token you can put the balance you can transfer you can transfer balance from the owner to different recipients so you can distribute around the token and then well as you can see if you create the once afterwards you'll see that that's indeed decreased this is basically regular JavaScript code with I think weight helpers to try to hide it bit from the promises you will see a bit of this on the code that will share a train about 10 minutes or so so open sublime not just has an implementation for your C 20 we also have implementation for year season 21 which are non fungible tokens non-fan Chabot I mean identifiable tokens one of the most known examples the cryptic it is also land from the decentraland project the idea is that well one Kitty is different from another Kitty because it may have blue eyes brown eyes whatever it is so it's not fungible meaning that you can just trade one Kitty for another because they're unique and we love each of them in different ways your CX 27 is basically an extension for your C 20 this is a fungible token it adds some transfer and Co helpers in case you want to execute an operation and we also on the lookout for rather a piece that we want to that we want to implement and add to the open sibling framework actually if you stumble upon a propose so that you can see it's worthwhile to be added to the library you're more than welcome to open an issue start the discussion and ultimately send up or send a pull request to open sibling so we can add your code your implementation of the of the EIP to the library so what else we also have what tokens are one of the verticals we provide we also have different aspects within the library I think of aspect us basically traits or features that you want to add to your smart contract a very simple example would be an honorable contract this actually is part of the honorable contract that you will find an open sapling so let's say that you have a contract and you only want certain operations to be executed by you by whoever is deemed the owner of the contract you only need to extend from ownable and from there you'll be able to use a modifier for the functions that you want to decorate and sing okay these functions should only be called by the owner of the contract the way to leverage these things to solid it is multiple inheritance so you'll need to extend from all the traits that you want to add here's my contract for instance let's say you have a mental token mental means that you basically have a method to generate more tokens on the go the way this is implemented actually straightforward you just add a method that you call you say hey I want to mint this may tokens for this guy and it gets automatically add to the balance this of course needs to be a public method if you want to call it from outside the contract thing is you don't want anyone to calling into a contract and generating more tokens of a as they go so you only need to extend from from ownable and not the only owner modifier to a method that way only you will be able to bulk it we provide many different aspects on the library regarding ownership while we have the owner block we just reviewed claimable inheritable which are basically few modifications on the ownable concept all the way up to a broad based access control in which you can defend and which you can define different roles and different accesses for them on your smart contract we also have a pool payments implementation basically if you want to transfer either to someone in a three-room it's a good practice to implement it as an a sync payment and I think payment the idea is that as soon as you are executing a transfer to a different address transfer of ether specifically code gets executed on that contract and that code could throw could abort could interrupt your application flow so it's a good practice instead of actually sending ether to assign ether to that address so they can later come in and claim it that's typically defined as a pool payment or an async payment their helpers in opens are going to implement that you just rather than transfer you async transfer the method to the beneficiary so they can later come and basically claim it we also provide some lifecycle trades there is a possible implantation you want in case you want as the owner to pause execution of its Marc contract case something has gone wrong also a destructive implementation basically tool to call suicide on it the last vertical we're going to talk about the crowd chills which actually are very common perhaps even too common nowadays on the 300 system and come very coupled with with tokens the idea for a crowd sale contract is basically to receive ether and send tokens back to the beneficiary a typical interface would look something like this a crowd said that runs through a period of time defined sank change rate from ether two tokens and sense all collective all collected funds to a specific wallet and provides a default payable function where anyone that cents ether are ultimately going to receive the tokens back allows to buy chalk and some behalf of someone else and provide some basic information on whether the caocao has finished or not usage again is straightforward you can deploy the open selling crowd sale contract directly you will be able to query it for how much funds have been raised so far and as you can see well on the fourth line where you send the transaction we actually send ether to that you can then query the token balance associated to that crowd cell from the beneficiary and you can see that they actually get a specific amount of tokens back from based on the amount of ether that they have sent we're going to share all this code with you in just a couple of minutes now typically you will want to customize your crowd so you don't want to penning a crowd so you want to modify its behavior in certain point so because the contract provides certain internal methods that you can basically override or extend to add your custom functionality you can basically choose what's going to be your your token contract that's going to be used you can define how many tokens exactly will be allocated for each purchase you can define when a purchase is valid such as where investor is wait-listed or there's a minimum amount of funding in the purchase and you can also define how funds are going to be ultimately collected let's say you don't want to forward funds immediately but you want to hold them until you hit a minimum target or you want to send them to different wallets as you collect them basically you can override all the functionality the way it works is straightforward you just set up your cross your contract and you override in this case the token amount method that will allow you to specify a different amount of tokens for whoever is making a purchase this example let's say you want to throw extra 20% to whoever has purchased so you can just modify the calculation on your token amount from the rate times they were contributed to with an additional multiplier also you can extend from some crowd cell flavors that are already implemented such as card krauser refundable crawl so we have a capped refundable and finalized double the first of them allows you to execute custom functionality when the crowd sale ends such as minting tokens for a team of foundation a capped crowd so which basically stop as soon as a certain amount of letters has been collected and the refundable crowd cell which allows you to define a minimum goal so that it's not reached all investors can try claim they're either back we're also working on different flavor more flavors that will be coming on the next release and the one after that a weight whitelist of a crowd sale where you can define a set of vetted investors who should only be the ones that access the crowd sale mostly for kyc purposes possible Krauser in case you want to stop collecting funds at some point in case something has gone wrong a cup spur users which investor can contribute up to a certain amount of money and the pre means it crowd sale so rather than minting on the go you provide the crowd cell with a token that has already been minted and you just use the krauser to distribute those tokens among your investors so the idea now is actually to take about 15 minutes or so so you guys on your own computers can work on an exercise we have set up a sample republish a day you're in second but what you will find there is an already set up transfer project you only you only need to clone it run NPM install NPM test to make sure everything is okay and you'll basically find a crowd sing a token contract with some extension points defined and some tests skipped as well the idea is for you guys to implement the necessary code for those tests to pass the idea would be to work grunting bone your sister contributors so let's say that you get a purchase where with a certain amount of either let's say someone contributes over five either you want to send an additional number of tokens you want to mint additional tokens for the owner for the crowd so once it finishes so let's say twenty percent of all the tokens are have been sold you want to mint in addition for the foundation for the owner for whoever it is and also if you want to jump into a whitelist implantation we already have one in the making but it's actually good practice to work on defining okay when a purchase is valid and trying to check different criteria one of them could be having a set of pre-approved investors sorry here on this URL you will find the repo that you can clone and basically get all them for me all all the code array setup so you don't have to work on the bootstrapping Europe of your project you can also feel free to use this repo for your hackathon project later everything is taken care of for you so you can easily start hacking tests and make sure that everything is working properly will take about 15 minutes or so yeah I know it says 20 down there but okay between 15 and 20 minutes so you guys can Huck will also take questions during that during that time and don't go anywhere because we will wrap up after five minutes we present which will be the prices will be a wording for usage of open Zeppelin during the hackathon and we'll also be presenting the project that we're working on which is basically Zeppelin a ways and well all the things we're working on later so please guys start hacking and in the meantime if you have any questions raise your hand we'll be happy ants to answer and if you want someone if you need help actually with the actually hands-on exercise just let us know the several of us around here that can go around and help you and get set up we have met we have manual so I'm pretty much there are quite a few people around here experienced on the framework so I'm sure they can provide help ok guys if you have any questions or we'll we'll be here taking them okay so we'll have a question on what's the rationale behind let's see er see actual 827 which is the a proven code basically for many applications you want to use your tokens as form of payment if you want to say so so what you typically do in your C 20 is you send an approval to a smart contract that is going to provide a service could be an exchange could be service provider whatever it is and then you call a function on that smart contract say okay please do that for me that's my contract is going to take your tokens after you have done the approval and execute some logic that means that you need two different transactions for doing that the first two the token contract for the approval the other one to the service provider for execution the idea behind the approve unco is you just send one transaction to the token contract saying okay I'll locate this much money to this contract and then call him saying hey these guys wants to execute these days for that right now an extension for sin 21 I know there's a 21 going around I'm not sure if it adds that there is work on that it's keep an eye on your CH 21 not exactly a 27 but yeah it will include stuff like that that allow you to basically validate the transaction execute code upon a transaction yeah there are actually many different flavors of 8:27 some of them does actually require execution require for a function to be implemented you also have 777 which is a stander which is getting a lot of traction which is not backwards compatible with your C 20 so the ones you want to look at are the ones listed here 777 and 821 thank you welcome the question was if opens everything provides some voting functionalities and the answer is unfortunately not well that would be awesome too we are you planning to add something like that I mean we are always hoping for contributions to the framework so if you build something this weekend you're very welcome to submit a pull request another question if you have a standard token that you want to burn for say like a 721 token like decentraland manna did something like that I think is there a way using meta mask or something to pay with your standard token to a smart contract accept accepting that standard token instead of aetherium okay yeah basically what you need to do is build your own that that it's going to send a transaction to the token contract instructing it to either burn or transfer to another contract that it's going to take care of the burning but still you will need to have some meter in your account to actually pay for the gas to execute the transaction there is an EIP I think it's 826 that is working on basically signing transactions and delegating them to someone else for execution so if you have a standard token you actually don't need any gas to perform the transaction you basically pay a fee to someone else to execute the transaction on your behalf so they pay the gas furnace the transaction and they get choke ins as a reward that's 826 it's still under development we're actually working on that quit the folks from you know welcome okay folks will wrap up will still be around here in case you have any questions with hacking but basically we make a quick wrap-up and present what we are working now so the idea after open Zeppelin the project we are working on is selling OS you can get free sibling always t-shirts on our booth the idea basically is to write now with open Zeppelin what you need to do is you basically extend from the contract and you deploy them you deploy your own versions on chain the idea is to have as I said we called it a kernel of unchain libraries which you can basically depend on for your small contract so rather than deploying the entire contract each time you want to make a deployment on chain you just reuse the code that's already deployed saving you a lot of gas and making sure that of code that is already available there so instead of deploying a complete contract you just deploy a little bit of your contract that basically is going to delegate your codes on the unchained library the idea is for these libraries to be upgradable meaning that if we want to add a feature we detect a bug or an issue on them and we need to be fixed we need them to be fixed we have an upgrade ability mechanism so that the contracts you have deployed can automatically call a different backing library with a different code of course having the keys to that upgrade it's quite a security risk it's a single point of failure so the upgrade ability mechanism of course is going to be obtained is going to be managed by the centralized governance system we also want to provide alternative execution models we'll be rolling out a scheduler for you to be able to run a sync operations to execute operations without having to pay for the gas on providing a bounty even setting up a marketplace so that different service providers can have their interface easy to use directly from Zeppelin OS and we're also aiming to provide off chain tooling to support all of this so it's actually easy to get started and get up and running integrating with all the contacts that are already deployed simply in OS right now it's a prototype stage we're evaluating different uh credibility and governance mechanism for the MVP you can find more at Zeppelin no waste at all you have a link to our blog post white paper and basically all the information you need to get acquainted with the project right now as I was saying our project our focus is in the upgrade ability part and of course reusing code directly on chain will be also be awarding prices for folks in the hackathon basically we'll be awarding three different prices one of them is best use of open Zeppelin the other one is best contribution to open Zeppelin so if you're writing something and you think it's a good idea would be a good addition to the to the framework you're welcome to open a poll request to it and that will also be a candidate for one of the prices in the Kaka phone and we'll also be awarding a prize for the best prototype on several nos if you are more interested in this remember to go to several nos to talk you'll also find the link to the github which is Zeppelin OS labs you can see what we have been working on and you can propose different app readability versions or whatever you think would be an interesting contribution following the white paper you we have something more we'll be awarding crypto collectibles starting tomorrow so those of you who stopped by our booth besides getting a free t-shirt you may even get a free crypto collectible if you convince us that you're going to build something awesome using open sample in starting tomorrow just drop by our booth and you'll be able to get an open simple and collectible okay so now we're finally finished and again if you have any questions regarding your starting project or open sapling itself just let us know you have all our contact information there well thanks a lot Oh have a good lunch [Applause]