Olympix workshop

hello hey guys my name is hannie I'm gonna actually step so I don't block this founder of Olympics hey everybody I'm Zach the founding engineer at Olympics um maybe we should switch actually or I I could click it okay cool so today we're gonna take you through hello um web 3 security best practices um okay so this is the s reality of today 16 billion plus has been exploited from uh exploits today and that number continues to go up and why I actually like to switch with you yeah just have a little control over the Pres um and why does the number keep going up okay what's what's going on here well people are treating the web three attack surface like the web two attack surface and that's not the case it's exponentially larger so what do I mean by that there's three this is a different pres see okay there's three things that really stand out to us so the first thing is the mutable nature of code right in web 2 we live and breathe patch redeploy patch redeploy name of the game in web three changing your source code is a completely other animal second reason okay um the transparent nature Web Two we have security V obscurity Web Two we have the luxury of a firewall web three everything is extractable at a source or bite code level so you don't have those Protections in place and the third which of course cuz the wrong prey which always happens third reason is the direct access to liquidity so in web 2 you're a bad actor all right I'm going to get into your system I'm going to steal your data I'm going to sell it on the dark web and then I'll have crypto right web three here's how it works hey Zach you have your protocol I do okay Zach protocol right line 42 oh 80 million in liquidity let's say you're doing big right okay doing really well uh line 42 re-entrancy I will I could have that in my wallet in the matter of hours so this attack surface is can be most lik into like aerodynamic security or medical device security where the stakes are so high so what does that mean it means that the shift and the reason this is happening is because people aren't treating it as such the development methodologies the um tooling that needs to be used needs to be a lot more robust we can't just be relying on a manual audit and this is pre- deployment post deployment um the audit's just one piece of it so how do we do that we could sit and we could say this is all Auditor's fault this huge astronomical number or we could be realistic and say hey even though 90% of audited contracts is 90% of exploited contracts are audited we need to lessen the Reliance on Audits and what does that mean it means owning developer security and actually shifting that responsibility left okay um so today what we're going to do is we're going to go through um what that looks like in ter in terms of what you need to own internally and what you need to do pre- audit so this is going to set you up for Success obviously as someone who has a protocol the most important thing to you is if you're dishing out 25k 50k let's say you're you know big and large and it's 500k and you're going for like a trail bits or something like that you want to know that that isn't going to get exploited or your confidence is going to be very high and when you don't come with the right preparations in place like 100% test coverage um running your own fuzzing and variant testing which Zach's going to take us through a Live technical demo of what you need to do you set yourself up for failure and that's not a good place to be right only hurts the ecosystem so what does this look like internally okay design decision so critical design for Simplicity you do not need I know there are edge cases right let's keep that in mind but you do not need to come up with some crazy new pattern often times there are protocols that are operating and have well tested um simpler design patterns that you can Implement and adopt that's the beauty of the ecosystem right do that if you can you don't have to introduce an attack Vector second we have no um correlation or like we're not we don't work basically we just recommend Foundry because we love it it's a free tool it's incredible it really makes the internal development process seamless in terms of testing your contract the framework's incredible Zach's going to use it for our um live demo and the second is of course you guys already know this but you need to design an emergency stop mechanism um sounds obvious but a lot of teams aren't doing this and this is critical and so I'm just going to read the bottom to you because I think it's just like a hammer it in but the financial nature of crypto really means that every technical flaw is a security risk it's not like web to oh uh like as Zach says make ship things and break break break fast what do you say Zach move fast and break things right I think Zuckerberg says something like that right yeah that's not what we can do here if you move fast and break things your company's gone so we don't have that luxury um okay so now this gets exhaustive right no one likes this but this is the reality of what you have to own okay 100% test coverage if you going for an audit and you have less than 100% line in brand coverage they're going to look at you and they're even the top Auditor's face they're going to say where we have lower confidence in your audit you don't want that okay second fuzz and and variant testing very easy to implement um you can go crazy and like add formal verification and learn Cur go all out but most teams can't do that so let's at least own fuzz and invariant testing which can be made really easy using Foundry um at Olympics we actually have automated fuzz and invariant testing as well as automated unit testing um but you don't need us you can do it on your own if you want if you want to automate it you can too um hack yourself okay so what is the worst case example what does it look like if your company goes down be able to kind of replicate that and try and um create that internally protocol documentation again must have before going to an audit uh keep your inheritance manageable so minimize the depth and width of the inheritance tree uh well tested libraries again another thing there are plenty of beautifully tested battle prooof libraries you can use those most of the time you can be really careful what you implement if it's not in that category you are introducing a lot of risk um and that affects your company that affects your users it's not a joke um events you know known and true make sure to log and then last thing is an instance response plan you need to plan as if you're going to get exploited and know what you're going to do if that's the case so these are again a very exhaustive annoying list Olympics does automate a good portion of that which um we'll try not to shill too much because really the point is hey here's what you need to do so we're not going to take you through Olympics tooling today in our technical demo but we'll show you how to do it and just keep in mind if you implement Olympics tooling it'll split that time in probably like 10% of the time that it would take to do it manually so with that being said I'll shift it over to Zach what's up all right so I'm going to be taking you guys through a little technical demo um and really what I'm going to be talking about is the the major differences in the change in responsibility between the typical web 2 startup and the typical web 3 startup so here I have a contract um just kind of like a random use case I'm not an accountant but um it's a oh wow that's prettyy blurry um but it's a it's a balance sheet so you can imagine maybe like an accountant at a company in housee wants to for some reason use uh a decentralized balance sheet maybe uh it's a global company everybody could have access to it everybody could see it um and there's some you know multiple parties involved so you can imagine a use case but basically the point is we have a contract that's supposed to uh function like a balance sheet and what we have here on the right side uh and this is in Foundry Foundry is a really awesome testing framework um you basically get to write all your tests in solidity which is pretty unique um and you get to represent your tests as contracts as well which is pretty uh you know native feeling which is very nice um but basically what I have here is kind of the starting point of the respons where where the responsibilities of a web to Startup might feel satisfied so I have you know a few tests um I have test for basically all the happy paths to the user stories so you can see in my balance sheet contract I have functions which are basically user interfaces to add an asset remove an asset same thing with liabilities um you know maybe calculate the uh the equity um and yeah these tests basically just go through those user stories and make sure they work and that's basically it and you as a web 2 startup you might say okay I'm done like it works bugs will come up for sure the users will report them and then we'll fix them you know that's how it's supposed to work you know move fast and break things as that guy once said um so I mean yeah like for a lot of startup Engineers this is what it's going to feel like you know a lot of there's a lot there's so many great Engineers who like move from Web Two to web 3 and just this is their experience and um especially if they if they have great experience working at startups that are not crypto startups they'll feel pretty satisfied and they'll feel secure um but it's kind of your responsibility if you're like managing or a CEO or something um to make sure that this is not where it ends because you have to go a lot farther than this um particularly before the audit because you don't want to show up to the audit and this is it you know um they're going to grill it you're just going to have to go get more audits afterwards um they're going to come back to you with with low comp confidence so you don't want that cuz that's like another 50k or something so that's not cool um so what is like the first next thing that the crypto startup must do that the web 2 startup might not need to do um I think and we think at Olympics that that's code coverage so you know of course a lot of web 2 companies are going to have high and 100% code coverage but most of the startups probably won't you know um they'll have the happy paths and they'll call it a day so um just an example here uh again we love Foundry so we do this in Foundry Foundry has a really great let me put this mic down so I can type with two hands nice so okay so we can see I'll just hold it again so we can see that we don't really have full coverage here um and even though we tested all the happy paths we don't have full coverage particularly in like the sad paths so that's where these required statements fail and you can see the yellow here that means it's only hitting one of the branches not both branches of the require um so I have these tests that I commented out but that you know maybe if you're a web two startup you wouldn't feel the need to make these but you really should and um when we put these tests in let's say we spend some more time we write these tests we get full we get full coverage now um and we run the test again we can see that they're failing okay and that's because I have a little bug here this should not be uh less than or equal to it should be strictly less than okay whatever big deal but it is a big deal it's a big deal in crypto whereas might not be in web 2 something like this okay you just fix it whatever in crypto if something like this happens you know um you read about every hack it's like the hacker puts the contract in a weird state that you weren't expecting and that's how they hack you so um you can't really allow for unexpected Behavior anywhere okay so now this is the point of this example is basically um we fix our code by making sure we have Fuller Branch coverage that's basically it um and this is like something that might not be prioritized outside of crypto as much in the startup World okay so first thing make sure you have the highest test coverage full coverage like no excuse not to before you're going into an audit um otherwise you're really just wasting your money okay what's the next thing um the next thing and we're going to stick with Foundry here is the really nice fuzz testing they have in Foundry so I mean now we're starting to get out of the what I would call like the reasonable world of a web two startup trying to ship things quickly you're not going to see much fuzz testing um unless it's like you know something about aerodynamics or whatever uh not like you know when instacart was a baby I'm sure they were not doing this uh so so fuzz testing um Foundry makes this super nice um you can just like your unit tests you can have a contract uh that just implements fuzz tests all you have to do is include the string fuzz in the name of your tests um and that's really it so let me just run this put the mic down actually let me talk about what the fuzz tests are a little bit more before I run them so with fuzz test and Foundry you can have your test function and then build it with parameters and then Foundry will just randomize those parameters and you you can have it run a lot of times you can actually set it in your configuration um and this is cool for a lot of reasons number one it just throws more stuff at your contract okay great this is kind of an obvious reason um you know more situations you might not have thought of uh randomized values another reason is it kind of forces you to use this assume cheat code and what this assume cheat code does is it forces you to think about the constraints and the limitations of your code um so in this case I have asset value is less than 100 ether up here okay that means that I'm considering the system to have a constraint where this function should not be called with anything greater than that value okay that's something maybe I wouldn't have thought about without this um something that this really forces me to think about um another thing is it kind of makes you think of assertions that you might not have thought of otherwise so in this case um what we're doing and what really came to my mind when when you know doing fuzz tests for this balance sheet contract is what if someone you know in one transaction does a lot of actions at the same time and that's why we we fuzz over here like numb assets so this means this person's like adding multiple in one transaction okay great like these are like the types of things that will just make your audit cost more if you don't think about them so just nice to think about um and yeah so let's see so I'm going to run it now okay and they're failing why they're failing because when we were thinking about adding multiple at the same time one thing that came to my mind that was I was forced to think about from the first test was the order in the storage so whereas I might not have thought about the order of the added assets and liabilities adding one at a time in like a unit test that only considers like you know one or a specific situation when you start to fuz you start to fuz on different stuff like the number of assets being added then it starts to make you think about you know um the different things you're fuzzing and the results of them so in this case we're checking is the is the order preserved and it's not okay so let's fix that I have the fixed down here and it's fixed cool okay um and you know not not to show too much but um this stuff can get pretty timec consuming so you know at Olympics we have ai tools that basically automate this um basically know how to use Foundry really well which is cool um basically all you have to do is kind of like make a skeleton contract you make a setup function and then you hit our CLI and it does all the rest it just kind of fills it out so that's like a uh if if you're kind of you know feeling like wow this is just too much work I don't have the time for this like that's uh let us know um Okay cool so that's the fuzz that's the fuzzing tool and the last one that I want to talk about from Foundry is the invariance tool so this is something really cool um really they're both fuzzers the fuzz and invariant tools um but there's a major difference between them the fuzz tool is stateless and the the invariant keyword is stateful but they're both fuzzing so what that means is that in the fuzz test let's say it runs it 300 times you have that in your config um it'll throw the parameters at it and then wipe everything start over throw it again and do that 300 times um with the invariant testing there's a few differences first is that it'll call all the function selectors on your contract so it'll just Spam randomly which functions it's calling uh as well as well as the parameters and it will also uh preserve the state between the calls so um whereas the fuzz keyword in Foundry will uh well it will wipe the contract and then do the next call and do that over and over again the invariant test will preserve the state so it'll throw something at it keep that same contract throw something at it again keep that same contract do that 300 times um and see if your invariant is broken and what that allows for is a really cool you know nice clean syntax that's just an assertion statement and these assertion statements can get quite you know crazy actually um in this case they're all one line it's kind of like the intro to Foundry and variant testing um but you can imagine if you want to checking if you want to check for a lot of things if you want to check like a whole data structure um then you know you can have some pretty beefy invariant um but in this case for this demonstration you know some things that I thought of for the balance sheet where just you know the owner doesn't change uh the total Supply doesn't change these are just kind of like how it was designed um and you can't have negative assets or liabilities okay you know pretty chill um and what that allows for is like just it's it's a few things something I really like about it is that besides from of course like you can write these and then find bugs where they're where they're broken which is you know huge and will save you tons of time and money on your audits um it's also a really good way to communicate with the Auditors it's almost like a coded documentation it's like these things cannot be broken here they are in code um so it really can help the Auditors understand your code better and faster and just less auditing hours means you know less less rounds of audits and and less time at each audit um and yeah so let me do one more thing it's also really good for like introducing new features and refactoring like this is the example I'm going to show you now um let's say you know you have a new feature request where you want people to be able to purchase uh equity in this balance sheet uh and just mint them like the erc20 so someone goes along and adds this um that's not cool because we know that the total Supply is not supposed to change here and that will flag the invariant that total Supply does not change okay um and what can we do to fix this well instead we should have the uh the owner transfer the original or piece of the original 100 uh tokens that were Meed since we know that in this case the design of the contract is that the total Supply is not supposed to change um and yeah so I mean again um not to show too much but we have tools that automate all this with AI um they read your project you you just build a setup function and it'll fill out the contract for you with all this stuff um Works super well so I'd recommend giving you a shot um yeah thank you for listening any questions so you mean the AI is helping like write all the tasks yeah so it's it's um take back um yes so from the user perspective it's like you will uh build a skeleton contract test contract which means you just have the setup function and that kind of tells the AI how it's being deployed and everything um and then it for for unit test they'll just fill it out until you know there's there's sufficient coverage um and for fuzz tests what what it what we do is like uh we convert pre-existing unit tests into fuzz tests so we can identify constants and unit tests and fuzz them um which is a really nice experience because it allows the the developer to kind of stay in the real world and think of real like real non-abstract scenarios with hard-coded values but then the tool will take them fuzz them and uh identify bugs like that and so the developers using this tool are loving it because it's saving them a lot of time and they're still hitting this checklist um so instead of going to the audit without these things in place having lower confidence having to get another audit after they're coming to the audit with these things they're getting it done they're getting it time in sufficient time they're getting incredible results so so that's kind of the promise with Olympics whereas um you can also do it manually you're just adding on that time so you're just spending more time on it and also what's your business model we could definitely take that offline save you time give us money okay great thank you guys oh please thank you um so this is so you automating all the steps that you just walked through manually yes um and the promise here is that I mean does so this doesn't replace like an audit or this is it is not replacing an auditor it's supplementing right so like a lot of teams that we work with are currently getting two or three Audits and most teams wish they could right they wish they could get two or three maybe they can't afford it so instead they're implementing our tooling and getting one instead of two or two instead of three right or you know we've even have some teams working with us and then working with Auditors that do payer vulnerability so it really depends on your budget and where you are but no matter what team you are you need to have this checklist of items and all we do we're telling you like you do this with or without us we don't care but you need to do this right that's what the point of this session is educating you but then if you want to do it with us it's going to take you like a tenth of the time that's basically it uh can we see the Tool uh like we can certainly set up um a live demo sure okay uh not right now but yeah yeah of course we can connect on telegram we can make that happen it basically just works as a CLI you yeah you just make some config you make some setup and then um you get like either a PR or an email uh what a demo do you have a um protocol yeah EP they just just they just uh oh yeah yeah perfect sweet oh that was an awesome presentation I just watched okay cool yeah we'll definitely get you on and also we have a free tool I want to say this too it's our give back to the ecosystem we have a static analyzer benchmarks best on Market you can get it on vs code it's an extension so start with static analysis dip your finger there that's the first step to becoming a security forward Dev and then you need to implement the next steps but static analysis is not invasive while you're writing code you're going to get those notifications if any you know patterns occur that are introducing potential attack vectors it'll let you know free free free use it yeah for for that tool just go to the vs code extension Marketplace and type in the name of my shirt and and then you can download it and then watch the magic happen Okay thank you guys so [Applause] much