Smart Contract Security

[Music] so let's wait for the slide but yeah first it's really nice to be here and I'm thankful to be invited to speak here today so why am I speaking about smart contract security um could be seen as bit ironic for some but actually I've worked for ethereum since two over two years now and actually my job was to prevent hard fors so to say because I was working on consensus tests and working on getting all the clients to sync and vote thousands of tests and would be so bold to say that I prevented a lot of hard Forks in sense of client consensus um and now through recent experiences I learned the hard way um how important smart contact smart contact security is and that's why I wanted to talk about it today see so you know about the da um I was mainly responsible for writing da smart contract so on 17th of June there was an attack robbing 3.5 million ether out of this small contract by using the re-entry exploit um we have heard about this before this conference so I will not go into details how this works but those were the L of code in the Dow itself um basically there was this one function with with reward four which was vulnerable to this exploit so what can we learn from all of this there's a lot of things happen there yesterday and I mean um I will repeat some of them of course but give my personal perspective on some of those things first of all cap smart contracts um it's very early days and we lack experience meaning we just need to learn some lessons before to know which kind of bugs we can do if you just look at the version numbers of the current software you can get a feeling of how early it is some solidity actually has not been released yet as a 1.0 version um froner has been launched for about a year ago so it's all very early days we have a the number of operating decentralized application is also still very low um retail suggested in a blog post that for example right now a cap of about $10 million seems about right um it's it's an individual decision but of course would have been nice if the Dow would have had such a cap um but of course nobody did know that it would rise to such a size so next one former proof verification I will not go into this we have heard about a lot of this yesterday but yes very important topic I hope we make to make continuous progress on this topic invariant checks so basically you can write see that your smart contract has certain invariant such as for the Dow this would have been that the total Supply is smaller than the balance Plus reward tokens and then after every function um you can check if the invance still hold it's reduces of course the risk then this is a interesting topic centralization of course we want to build decentralized application that's our main goal and one of the weaknesses so to say of the Dow was that it was really decentralized that we had no control nobody had any control over it and this was the problem in the in the end because nobody could save the Dow um only the community by doing a hot for which of course it's a horrible option to do so we need to go stepwise from centralization to decentralization if you think about ethereum we had Olympic test net then we had the froner test net where we had those canaries I had one of those keys where basically two out of four keyh holders could more or less switch off the miners um if they would listen to the canaries we had have Homestead that we have this difficulty increase which means we need to have a hard fork in about a year or so and there's only a couple of people able to code up the next version of ethereum so it's also kind of centralized still and we will go step to step to more decentralization um for the Dow that have been creators they have been given a lot of power except of the function split Dow because this was a function meant to as a fail day for malicious creators so that's why they didn't have control over this function couldn't do anything there's all the other Dows Stitcher Dow maker Dow and other Dows in the progress which start centralized and will go into decentralization then question is of course who can control for a dow was some token holders it could be Central trusted authorities and there is more but the slides don't show it up here right now but it could be something like Community multi it could be something like a stake vote that you build in something your smart contract when a certain amount of ether holders vote for it stop something so there are certain ways of controlling this but I think we need to go step by step but also I think it's important that we really want to build decentralized application and do not use the Dows an excuse to only build centralized applications although it's good to start like this I don't think it should end like this we should move forward to full decentralization one day okay let's see if this works yeah as established security patterns meaning learning we didn't know about the call stack depth call stack depth attack we know about the block gas limit so don't have arbitary length Loops um we know about we anti exploit now we know about that Isa sent to a contract without it's possible to send EA to a contract without any contract invocation so even if you use this modifier payable um or you don't use it at any function you try to avoid getting ether as a contract you cannot avoid it because you can use the suicide op codee to transfer ether to a contract without executing any code for example um specify the right amount of gas Z versus C depending on what exactly you want to do you have to be careful with the block time stamp because it can be manipulated transaction origin versus message sender for example can be used for pishing attacks and much more actually it's bad that the slides are not really working because there are links coming up it's just um there are some very good resources one is from the consensus website best smart contractors best PR um best practice of smart contracts or something like this you find on the consensus website it's a really nice overview of all the things we need to learn and what we have learned up to now also the solidity documentation has a section about um security consideration which is very good and very helpful we should as a community learn and put all those things together so we can teach other developers what to look out for let's see if we can get to the next slide yes updatable contracts so the da had a possibility of updating the contract through a vote it did take a two weeks debating time and DOW 1.1 so to say was work in progress but it was too late so I would advise you when you smart when when you write smart contracts to have an option to update them the question is only who can update them in the beginning it can be you of course centralized it can be the token holders if you have some in your application depending on what you're building and again could be a multii maybe a community multi there are different ways of doing this but it's important to have at least this option of being able to update um contracts time delays are also something important when you with when someone can restore ether or to take ether out of a smart contract if you have a time delay this gives an option if you implement that some authority to do something to act in case of The Da there was no such Authority and the least resort was this this awful hot work so therefore if you have time delays and this Authority implemented then this can work nicely together to reduce the risk of your smart contract of course minimal complexity um there are statistics out there which saying there are 15 up to 50 bucks per thousand lines of code for a website it's okay you can fix it but for a smart contract it's really bad so of course we need a much much more security for smart contracts than we need for normal stuff so this also means not everything needs decentralization and needs to be in a smart contract only put in what you really need the core elements of a decentralized application everything else can be maybe in swarm whisper or even other techniques yeah and the other thing is to reuse trusted proven code this can also be dangerous but for example the the standard token contract which was also used in the da which worked just nice um you have the foundation mulc which seems to hold up till now so means also looks safe and maybe there will be even a dow standard framework one day just to reusable safe code this also come with a danger because if then you someone finds a bug in this kind of code it will affect a lot of applications so therefore you also need to be careful with those things but I think we as a community need to build trusted libraries which are reviewed by many of us to for other developers to use let's see if we can get to next side better tools you have heard about formal proof appication we need better compiler warnings um I think this is all work in progress we need improved idees we have seen remix yesterday which looks really nice and promising um we need trusted libraries we need best practices liter which is also work in progress and we also may need some yeah centralization which can be done by master keys so maybe maybe we can do decentralized with Escape hatches or other things which we can use in smart contracts for now as so to say a trusted source of information who can update contracts or do certain things or stop a contract from working so as a conclusion I would say it is very early days and we all need to be very very careful um but I think there is of course a lot of lessons to be learned from this but being here the last couple of days got me really EXC excited to see what came out of this we have a lot of Security Experts from academics we have a lot of media attention a lot of people looking at this looking at the right things developers being much more careful now and it's also nice to see a lot of developers coming up to me and say um you basically saved my project because I had the same bug in there but I could fix it now and so I think a lot of future applications desized applications and smart contracts will avoid all of these issues and we can really move into a pride future although being careful in the beginning and it was really astonishing for me to see how this community is moving on I think this was a really nice um experience to talk to many of you the last couple of days and I also want to say a personal thank you I mean the last couple of month um thank you thank you very [Applause] much yeah it has yeah I can only really say thank you the last couple of months have been as a p as a person for me my personal life also as a company hobble of course but it's only because of the people sitting here because of the lot of Ean community that I can stand here today and give this talk and I just want to say thank you very much yeah thank you really thank you [Music]