EthCC 2: Albert Acebron

okay cool hi everyone um so safe so right um everyone I hope everyone here knows that like writing secure code in solidity is pretty hard like well it's been proved there's been like very like a ton of mistakes like the Dao and the party party wallet and all that stuff like that well that's been proven now um for this there are a couple Solutions and everyone knows them they're like getting a good suit for your contract and using formal methods of verification probably understanding solidity and knowing how your contract works and all that but the thing is like well all these solutions they work well and everyone knows them and all that they're not solutions for people that just got started with selecting so for some people well some some guys which is like read a 20 minute medium post on how to create a centralized Twitter or they just like went through the some chapters of crypto zombies these are not proper Solutions because they require a large time investment or well and they're out of work and essentially they're not viable so there's um agave of a solution that can help people are just like new to salinity game like make and save contracts without requiring a large investment and that's where sales all comes in so same save Soul was born from me trying to teach salinity to all to other people and seeing them fall in the same pitfalls again and again and so I created this and safe Soul essentially is a drop in replacement facility what that means is that essentially you can have like your solidity code and instead of like compiling it with solidity just like compiling with sex so so it's just a normal compiler that essentially works the same way as a lady but it outputs um well the output and tries to fix many pitfalls that are pretty common in this in smart contracts by essentially using save the faults or um well making some decisions that have trade-off for you so you may be wondering well if like such a thing exists that it just like magically fixes your contracts and makes all your contracts secure like this miraculous thing that fix everything or is it not already part of solidity why isn't everyone using it already like well the thing is that um to make these safety guarantees and to like avoid these pitfalls essentially so that it makes several trade-offs that um because of them the the features sensitivity shouldn't be including well features in safe so sorry shouldn't be included in solidity or everyone doesn't have to use them so to explain that better let me look at the case of safe math so for those of you who don't know safe what safe math is essentially a library facility team that um provides and security for what or provide guarantees for the case of overflows around the flows so if some variable in your code and overflows around the flows you just like reverse the whole state so that's pretty good because and you know in other languages people don't really think about what will happen if there's like an overflow and on the flow and then they come salinity they don't think about that either and they create contracts that have vulnerities in them because then that comes an attacker and triggers one of these overflow around the flow and you have like essentially undefined State and bad things happen so it's pretty good for that but the issue is that it can also introduce vulnerabilities in itself so for example someone might go and get your some variable in your contract to a very high number and that means that if everyone like anybody else tries to make some operation that increases the number it's going to trigger an overflow and the whole thing is reverted so essentially you got yourself a contract that's breaked you can do anything with it nobody can do any operation with it because the whole thing is always reverted and well that's pretty bad right because you had a contract that didn't have any vulnerity before you added safe Soul thinking oh I'm gonna solve some stuff essentially now you have like a contract that's vulnerable so the thing with safe soul is that while it's better than just not thinking about um on the flows or on the flows well overflows and the flows and if you're an expert programmer or in solidity you can like think about these cases and craft specialized um edge cases for these so for example if in your contract you can handle like in one second one in one part of the contract the overflows in some way another part of the contract can handle the overflows in some other way and eventually you can craft last a solution that's way better than safe math so um essentially the idea is that safe math is better than just not thinking about those Edge case but it's worse than actually crafting a special edge cases for these things so if state math was to be included in solidity essentially we're taking you would be taking away out of control from um smart contract developers and well that would be bad because that's not what it is for so yeah summer stuff doesn't belong in solidity some stuff that can help people that just got started and isn't well suited for being included in solidity or being used by everyone else because well everyone because um it can take control away and well it's just like not meant for everyone to use so yeah um the way I like to conceptualize the idea of same math is that if so sorry if statement is like training wheels for underflows or on the floor so the ideas are like you start using save masks because it's easy it doesn't require a large investment and makes your contract secure eventually you should be one when you're right crafting like real contracts or like contracted a whole gonna hold like a lot of money and stuff you should you shouldn't use Save math you should like graph your think about the educators of on the floors or overflows and like do they checks yourself and apply your specialized rule that work better for your contract and all that stuff so yeah so I've been talking a lot about what sales is essentially um compiler that makes some trade-offs to help people that are new to the language not not fall in many pitfalls of it but let me talk about what Cecil is not so if it hasn't been clear already it's not a replacement fluidity it does it is not in direct competition with solidity and it's essentially just like uh we're well safe Soul targets a special part of the selected developers like those that just got started or they don't know um many of the pitifuls or many of the subtleties of solidity and for them it's better because it's essentially just like avoids these pitfalls but eventually they just to start using sales because of this but transition to using solidity because that allows you better control so essentially at some point uses of say so should learn solidity properly and transition to the real thing you could call it I guess and yeah the other thing is um it's no Silver Bullet for solid security and using save soul to compile your contracts is not going to make them automatically secure like do anything just like avoid some pitfalls and do some trade-offs that are like well you may argue they are better or worse but yeah so I've been talking about a lot about the idea of the concept of say so and why was he born and all that but what is actually inside safe Zone what happens when you compile it with safe Soul instead of Solitaire wow so one of the features of ceso it has essentially built in safe mode right right so just like code and like do normal sums using the sum operator and all that stuff and and that includes overflow or underflow security so essentially just like reverts whenever there's like or number four on the flow so it's like write all your operations normally and bump you get save money for free on on signed on well unsigned and integers and signed integers which is important because um currently and the open sibling library is only for unsigned live unsigned integers they have like this sign thing well library for sine integers but they put it back into draft mode a few months ago so yeah well say so includes super for both now next um checks on external function called so um what I've been seeing when I'm trying to like teach people solidity is that plenty of times and people don't think about that and the thing is that sometimes if you make an external function call and somebody has already modified the contract calling you has modified the call stack and reaches I think it's 1024 essentially that call that external function call can fail but um you won't get um the you won't get an exception so the whole state of the contract won't be reverted you just get like our tone value of fail or false um well people essentially don't check those and I can lead to a lot of vulnerabilities so for example if you like some contracts sending cryptokitties and a contract that if that contract doesn't check if well if there's like the return value and all that we can get to the case that the contract thinks he has like sent a crypto Kitty and it's internal State reflects that it doesn't have that critical anymore but because the external call has failed he actually hasn't sent the cryptocurity so you have like um mismatch between like the internal State and the real state so that you have like um well that's a vulnerity essentially so big issue so what Cecil does it just like includes um automatic checks on every function call and if something bad happens like that like there's failure on the external call or whatever it just like reverse the whole contract stage so pretty much like safe math but for external function calls now next all right that's a big one well so another thing that I've realized a lot of people Miss is that they usually craft a contract they look at the they might have like only a single payable function and they say all right so I can only get pain well paid through this function or like money only has like this single point of entry into my contract um and they may even have like written um well I don't I remember the name of the function that like allows you to well that is getting cold when you receive a payment and they might have like um written this function so that every payment by like some accepted by them is reverted so they get to the well they think that essentially they can control totally the flow of money coming to their contract so they know exactly how much money is going to be at each stage of their contract or like at each point and that leads them writing code where essentially they have like strict equality checks on balance so for example if balance or required balance exactly equal to one ether or whatever now the issues with that is that some attacker may just send like one way or whatever amount using the self-destruct function and then you have like all these equality checks are wrong because your contract has like just a tiny bit more than what is actually expecting so but your whole contract is and bricked or breaks or whatever now that's pretty easy to fix it's just like you just have to consider the assumption that you can control the flow of money into your contract to be false and transform all these equality checks into greater or equal checks and that just fix it as far as time I were and I have looked into it there's no downside for that so it's kind of like perfect fix now yeah that's like the total opposite of that it's not a perfect fix so I decided to include that as part of say so because consensus in its guide around like contract security and all that and says that that's already been well that's been there's been a lot of misuse going with TX origin because people communicating that all right I can use that for authentication of my contract so like the typical and if TX origin is equal to owner then allow any changes on the contract or something like that and well that leads to a lot of issues like um a contract redirecting flow from that contract to well the contract that checks on TX origin and being able to like impersonate the owner of the contract so they have like admin control of the whole contract and well that's pretty bad essentially a vulnerity um well an easy way to fix that essentially like transform TX origin for message sender which essentially is like the proper way of doing Authentication so the thing about this and like I'm quite on the fence about this feature currently it's implemented but I'll probably um take it away um in a few or like next release depending on the feedback I get on it because um essentially it can lead to some issues with programmers for example reading the reading the documentation and finding out like what the acceleration is and then like getting some expected results because we're actually transforming to message sender so it has like some real drawbacks and actually in the while I haven't seen people using like making this mistake so I don't know how real it is like currently it's in because consensus things it's a really important vulnerity but probably in the future well depending on how people like it or not who might take it away so next thing re-entrancy so in the first versions of sisol um I created a new function like well built-in function that was kind of like revert or require that essentially um you could like put the condition well on transfers you could put like the condition the effects and the transfer them essentially would transform that call into something like well the whole um condition FX transfer pattern so essentially you would solve this one well this one kind which is like that most important according to well I think so type of rental syntax but the thing with that is that kind of like blh's the idea that functions have their parameters evaluated before being called and essentially does away with the idea that drop not safe solid is a drop in replacement because at that point I'm actually adding new things to solidity and asking programmers to make changes to their contracts and all that so right now um it's not part of safe soul but if someone has some idea on how I could at least solve partially re-entrancy using some trade-offs and please come to talk to me later I would really appreciate it I've been thinking on it a lot and no idea how to maintain that without breaking the drop in nature of it oh well now bar resolution um so yeah essentially people write contracts and they Define their variables using the bar keyword and solidity resolves that to some type like the most famous one is like in four Loops it usually revolves resolve to uint8 which is quite small so you have like the the case that an attacker might be able to actually overflow it um essentially breaks your contract so essentially because using bigger types is not really doesn't really incur a much higher cost essentially we resolved the bar keyword and we make like all types not big essentially so that that typical issue that is like people just writing bar and not being resolved to you in date or some really small type and is fixed with that and that links with the next stuff which is essentially yeah so people don't think much about hey what's going to happen if I get like a ton of users of if like people are creating a ton of users or a ton of like or this um variable that looks over an array May well at some point the rate grows larger than 256 slots or something like that and they don't think properly about it and they just like create well use the types are like smaller for the use case and that usually leads to like a ton of Errors down the road because well yeah you have issues com like using safe mode and all that stuff so the easy fix is to just don't think about the cost because using types well bigger types is not that much more costly and actually at some it may be that um it's not more costly at all if because of the way that um well storage is packed inside the evm and stuff so at some point you don't even get any gas advantage but yeah that's like an easy fix for an automatic cost and now this is uh I think this is like a huge issue with solid team and the thing is um nobody expects this and well the issue is that people well in every other language on the sun when you define a variable inside the function which would be called a local variable the volleyball is local right it doesn't alter some other Global variable or something like that and the thing is in solidity if inside the function unified an array drugged or mapping and you don't add like a memory or storage modifier so they actually automatically makes it a storage modifier and that leads to it pointing to the first lot in storage inside solidity and what that means is that essentially if you're writing to the variable you're overwriting some variables that you have stored so Global variables probably so that's a huge issue because you know people come from all languages they're used to local variables being local they come to salinity and boom local variables are not local anymore and they're just like writing to some variable they think that it's just for them function and they're actually overwriting something else and yeah it's it's it's a huge issue for people starting with solidity so the easy fix for that is just like always specified memory or storage and yeah that's pretty much it so yeah um actually currently the sales is working it's released you can check it out on that page it's also on npm a safe soul uh well it's my mid MIT licensed and currently it has not been formally verified so if you want to use it even well it works but is it your own risk I wouldn't recommend using it right now because it hasn't been tested there's probably like some subtle box that I haven't found out but yeah you're free to like go explore look at the code try to run it see see what see what you get and yeah I'll not so yeah um thanks everyone is there oh [Applause] any questions okay oh uh hey thanks for the presentation uh is it a fork of solidity 0.4 and if so have you migrated to 0.5 um currently well it started as a fork and I've like contributed some some pure facility so I know a bit my way around the code base and when I started like using a forecast LED but the thing is I'm not working on it full time so keeping up with the whole well with the stream of comets every day every hour into solidity which is like not buyable for me to like keep keep the fork and like solve all whatever merge conflicts appeared and all that that was almost like a part-time job or something like that and I couldn't keep up with it so I migrated from that to an approach that essentially um takes the ask code well they asked three from like solidity source code operates on that and I like transforms it back into solidity and then that's compiled us already so essentially what say solid is like a transpiler from solidity to solidity yeah so yeah well and are you planning to propose these changes to uh course solidity language maybe with a dash dash safe option um yeah essentially the idea would be to eventually get the merge into solidity that would be pretty awesome but as I said some of these changes they're not well suited for being insulated but yeah that's that's been like something in my mind like actually at some point being able to send a PR on well make it into solidity because that would I mean it would make the whole process for new users really easy uh yeah So eventually well currently my plan is to keep on developing safe soul and when I feel it's mature enough and I've received like a ton of feedback from people using it a lot and I know which features are actually helping which are not and probably add a ton more uh the ideas yeah to send it like move it Upstream into solidity that would be awesome [Applause]