 Hey everyone, thank you So for those of you who don't know us at Zeppelin, we build technology and provide services to help protect smart contract development We're mostly well known for our security audits But we also have some products and we maintain the open Zeppelin repo of smart contracts So this talk will be divided at first I'm going to review last year since DevCon 2 in terms of how the smart contract ecosystem evolved I'm then going to focus on some new techniques and patterns We've seen a rising in the industry that I'd like to give more visibility to and finally I'm going to talk about some pending challenges in smart contract security and hint into some possible solutions we're working on So let's start with history the dark ages So 2016 was a pretty dark year for smart contract security We've seen some pretty embarrassing hacks in the space. Most of you probably don't remember many of these Except for the Dow but just to get a sense of how the industry was at that moment I want to focus on one of them specifically, which is Rubixie. So Rubixie was a Formalization in a smart contract of a pyramid scheme the original name was dynamic pyromid But apparently the developer didn't think this was a good name for marketing reasons So he renamed it to Rubixie which is much cooler But he forgot to rename the constructor and this made This made it turn into a public function because that's how Solidity works So anyone could call the dynamic pyromid function and become the owner That's gaining gaining the ownership of the contract and being able to steal the the fees from the contract So this seems like a dumb mistake But the same feature from Solidity probably cost the party wallet hack which happened recently and cost like 30 million to be lost to hackers so And in in in May 2016 a picture of SNS wrote a great article calling the community to gather around a building best practices for smart contract development and One month later the Dow hack occurred the contract held roughly 15% of all ether tokens in existence and 50 million dollars were lost and at that time the only solution at the moment was to hard fork the protocol So Ethereum had to hard fork which in turn brought a lot of complications and security problems So it was not a good outcome in the end So at that moment The community was pretty aware that we need to ramp up our security practices and Three months later on September we launched open sapling as a community effort to gather around auditing contracts creating better security practices and Actually gather some smart contracts code to to share a week later I was in Shanghai for DevCon 2 and everyone loved the idea many projects wanted to gather around open sapling and help Build these contracts and since then the project has been growing quite a lot For the past three months. We had more than eight percent a weekly growth, which is the hockey stick figure every Silicon body entrepreneur wants but the truth is we we built something that everyone was wanting and the industry grew a lot since then so It grew with the industry Apart from the community building better tools for smart contract development Ethereum as a platform developed a lot too We've seen the consolidation of the various standards like the ERC 20 Proposal that turned into EIP 20 for token standard also the platform fixed some Security problems like the nasty cold stack attack that was possible before and after EIP 150. It's no longer possible Also solidity the the most popular smart contract language got some cool new features in terms of security The payable keyword that allows to set when a contract cannot cannot receive money require an assert that are really useful for Setting the preconditions and post conditions of our functions Transfer which is a safer way to send money from our contract revert to cancel execution of a function without wasting all the gas I'm pure and you which are the evolution of the constant keyword and allowed to specify If a contract if a function cannot or cannot read or write state from the contract We've also seen the death of Serpent as a language after an audit we did which in which we found eight pretty Serious vulnerabilities which led us to find critical vulnerability in the rep token which allowed any attacker to freeze the contract forever and Made made them have to migrate the rep token to solidity The the serpent language bus deprecated after this tweet from Vitalik And now all the all the efforts around that an alternative language are focused on viper Which is a serpent successor and it's pretty cool. So you should check it out It's not production ready yet, but I hope it gets more attention And more recently with the Byzantium hard fork some Consequences on on security are the addition of big integer modular exponentiation, which allows RSA signature Verifications will see what people come up to with this new tool the addition of the static call opcode Which enables safer calls to untrusted contracts because it makes them not able to modify your storage and the addition of opcodes for data handling and Revert the revert opcode allow for much easier and tighter ways of implementing upgrade ability proxies, which is An ongoing discussion topic in smart contract security So that's what happened and now I want to focus on some new techniques and patterns We've been seeing on our audits and and work with open-separate Well, can you see that? Okay, let's say you're a developer learning solidity So you create your own your C20 token for fun You by using open-separate you can do this pretty easily with like 10 lines of code So you think you want to add something extra to make your token cooler Just for fun You think you want your token to have an extra functionality of being able to lock funds for a certain amount of time And you want to add as little extra gold as possible So a way to do this is to add a lock function a public lock function that Instantly transfer the tokens, but then stores when those tokens should be released and then modifying the standard transfer functions to make them Honor this new extra restriction on that. So let's see how this would look on code We had this I don't know if you can see this but you have this new lock function Which basically calls the standard transfer function and then adds in a in an array of locks for each address When those funds should be released and then what we need to add to that is overriding the standard transfer functions adding this extra restriction where Which via this can transfer modifier which checks the amount of transferable tokens at a certain point in time and enables or disables the transfers and then to implement this Transferable token amount what we do is we iterate over the array of locks for every For for that address and we add up the amount of locked tokens and we we return the total balance minus the locked tokens so in this way Apparently we added a cool new feature to our token and it seems great But it actually has a big problem. Did anyone can anyone tell me what the problem is? Good good. You want a t-shirt? So we have a case of a gassy array as we like to call it The problem with this array is that the length of it is controlled by anyone that can call the lock function Which is in this case is public so you need to see the length of the array as a user input and as you know in security you need to sanitize inputs and Any anyone can call the lock function and create lots of locks in the array of Someone they want to mess with and the array if in this case I tried it and if you add like five thousand locks to an address the gas cost of calling a transfer For that token is so high that it doesn't fit in a block. So the point here is sorry By adding an extra feature we actually introduce a security vulnerability So there's a simple fix for this which is adding an upper bound to the amount of locks for every address but I wanted to Make you think about a different approach to adding features to a tokens which solves this problem in particular And I think it's better for security conceptually So the idea is to leave the token as is don't add any extra functionality and actually implement the Locking functionality as an external contract. So when a user wants to lock tokens for another They instantiate one of these new token time lock contracts which receive the beneficiary address and the release time and then transfers the tokens manually from the from the normal token contract and now if In this case the the previous vulnerability with the gasey array was solved But if there were one vulnerability in this new contract only the users using this extra feature would be affected Whereas with the previous version any vulnerability potentially could affect normal users that didn't want to use the lock function So this is one of the patterns we've seen In terms of improving security in new function design And the point is when you're thinking about adding new features to your contracts really think about the security implications Not always having more features is better because you increase the attack surface I'm for another example of how this is being Implemented in the industry at the beginning of the year most crowd sales were implemented as part of the token code And now most most crowds are implemented as a separate module So it if you think about it doesn't make sense to have all the crowd sale code in the token forever for just two weeks Or two minutes of crowd sale Finally this I want to talk about some the relation between basic security software engineering practices and smart contract security these are very simple stuff, but They are not being applied in in our industry and I think this is basic stuff. We should be doing So first is clear and simple code is always better for security most security problems come from a difference between The programmers intention and what the code actually does So having clear code makes it easier to check the programmers intention and that the code actually does what he wants a Corollary of this is that naming matters. I've seen really really bad naming in many contracts So please take your time and think about naming because it helps increase the security of your code Reuse existing audited code. There's plenty of good libraries out there You can reuse there. You can't imagine how many times we re-audited the same re-implementations of your C20 standard tokens Also, don't copy paste code because if the Code you're using is updated. You don't get the updates and also don't repeat yourself That's also a source of bugs and finally and most importantly Right tests. That's the best way to check that your Assumptions about the code are correct and also if you change the code after the fact you can prevent regression errors So as I was saying all these are basic security I mean software engineering practices that every developer should be doing but in our case our code manages real money so we need to protect it from ninja hackers Stupid users and other developers in our team So I want to talk briefly about the relation between security and trust reduction Let's say you're a freelance Solidity developer and your client requests a capped crowdsale. So you you write this simple contract But then he comes and say oh wait, don't forget. We need to create tokens for the foundation too when the crowdsale finishes So you go sure boss You are You make your crowdsale ownable So it has an owner and a privileged function to mint the foundation's tokens once the cup is reached So only if the cup is reached will it mint tokens? But then your client comes back and says oh wait, but make it trustless. I don't want to be the owner So you remove the privilege function Put it into the by tokens function so that the last investor when the cup is reached means the token For the foundation. This is better, right? It's more trustless but wait now an investor can come after the cup is reached and With this particular code if the message value equals to zero they can continue calling this by tokens getting zero extra tokens But reminting tokens for the foundation ruining the crowdsale the point here is It's not always good to leave Critical vulnerability critical functionality of your contract in the hands of the public. It's sometimes okay It's actually sometimes totally okay to leave really critical stuff from your smart contract in the hands of an owner especially if the If the investors or or users of the contract are already trusting the owner in some other way like giving them money I Wanted to say that So I want I want to end with some open problems that we see in the industry and some ideas. We're working on to solve them I briefly touched upon some of these but one of them is upgrade ability or both in terms of how to upgrade as Mark contract once it has been deployed to the network for like bug fixing or adding extra features Interoperability that is contracts calling Them each other the gas costs of how contracts interact within each other and code application in the blockchain So we recently announced our sampling OS project which tackles these four problems And I'm gonna tell you how we do that or how we plan to do that So for code duplication basically what we're going to do is turning open separately in the library into a non-chain Library where applications can direct directly connect and link contracts to the on-chain version to reduce the payload that needs the bite code That needs to be uploaded to contracts on chain and all the all the tokens that are reusing open several in standard token Implementation they can share the same code on chain and reduce the gas costs of deployment and reduce the amount of storage needed And this kernel will also have an upgrade ability mechanism Via the delegate proxy pattern So that we can do Upgrades to this kernel of really core and important modules From the ecosystem so we find the bug or or we need to improve some of the code from from those core libraries We can do so and possibly fix a production code from smart contracts and of course this this needs a this needs a governance mechanism because Nobody would use some something that is in the hands of a few developers which upgrades are approved And by the way, we we did this the technical research for this We did with the Aragon guys and they've been using the same idea on Aragon OS So you might want to check that out, too Two two other big components of the OS are the scheduler and the marketplace So the scheduler solves the gas the gas problem of smart contract interaction and it comes from the idea that When two contracts interact if you think about who pays for the gas price for those interactions For example a typical example nowadays is a multi-seq contract controlling a crowd sale contract some privilege function for example Finalizing the crowd sale If you think about it the first let's say you have three of five multi-seq the first owner proposes To make the call the second one signs it off and when the third one signs it off The actual operation is executed and all the gas cost of executed that is paid by the third or the last owner of the multi-seq so with the scheduler we're building tools to Enable contracts to request asynchronous operations in the future so a multi-seq could Gather all the signatures and then request someone else to do the actual execution of the operation So with a couple who pays for gas and who is actually approving the calls And this same mechanism also allows for asynchronous programming in general not just this this thing this thing is the gas but enables Smart contracts to to request operations in the future And for the marketplace we are standardizing the way contracts interact with each other so We think that there's a bigger potential for smart contracts when they start interacting more and we see an ecosystem of Contracts interacting and we're standardizing the way a contract can expose its services in terms of I This contract offer this API call for a monthly payment or a one-time fee and you get access to everything or a per call fee And finally part of also part of Zeppelin OS is a set of off-chain tools Which we call the smart contract SDK which are basically CLI tools and web applications to manage Easy more easily your contracts So you can know know more about this it's a completely open source project We encourage everyone to participate in by giving ideas and cold And we can talk about more about this later Finally We love yesterday. We launched solidity capture the flag contest. We're giving away 10k in prices It's a hacking contest like there's a couple of contracts. You need to hack to advance to the next level So if you want to check it out It's it's fun And that is all thank you very much