Debug First, or Regret Later: an Arsenal of Tools can Build Solid Ethereum Foundatio... | Devcon SEA

[Music] everyone uh my name is Aliso I am a foral verification engineer for runtime verification I do Audits and software development and today I hope to show you a couple of approaches and tools that you can use to protect your systems your smart contracts or regret later uh so uh code is product of human work we are all humans and we all make mistakes uh thankfully we have tools that uh allow us to check and avoid having these mistakes being broadcasted into worse situations we work in blockchain and we all know that it's quite uh dangerous to have potential issues being uh implemented in your contracts you do not want to have the name of your protocol or your company into one of these articles uh B take but I think it's it's pretty bad uh so let's avoid that uh and testing also uh unlike for example uh hacks that originate from private key private Keys being compromised due to social engineering these are quite hard to test but you can actually test for example math mistake exploits uh in your contracts and since 2016 roughly 251 million doll have been lost because because of issues originated from that and these are things that you can test these are things that you can protect yourself against so um which bring us to the question uh what to test how to test when and to that I say you have many options uh it really depends on what you need uh you can test that functionalities off your contract work as expected with unit testing you can if considering that your system uh is composed of many systems by it by themselves you can do integration testing to to make sure that they work as as expected you can fuss to test different values you can formal ver formally verify your code to make sure that it will work work under any condition uh but the thing is ideally they are not supposed to be each in their own boxes they are supposed to be in a huge box they are complimentary to each other uh you should not be picking one and using one you should be using several so uh the other detail that is missing here is that your code is only as good as you make can make it be so your contract will only be safe as you make your codes be as well your tests be as well sorry and to that I say that a really good approach that I like uh talking about is invariant testing this is something that you can use with each and every approach that you're being shown here here in this presentation uh an invariant uh to to understand invariant testing then you the first thing that you have to do is understand what an invariant is so an invariant is something that never changes it's something that remain constant at all times everything has invariance every protocol has invariance every uh uh smart contract has its own invariance you can even abstract them you can think about like an elevator an elevator has its invariance one of them can be uh I'm not going to open the doors if I'm moving and if I'm moving I will not open the doors I can consider I can show these as invariant so another example that I like to show is we all live in Earth and in Earth we have gravity so I'm going to do some invariant testing right now I just tested gravity so this is something that you have to keep in mind when developing your tests and believe me you will make the of your auditor quite hard by doing so uh which bring us to the tools that you can use for testing and I would like to have much more than five minutes to talk about them uh and I bring this right here just to show two things the first one is there is a abundance of tools that you can use to protect protect yourself and your code um the the and we all as developers we have to do our due diligence and learn about them do not uh re restrain yourself from from just learning uh a few try to take a look at them all and the second thing that I would like to talk about is that some of these tools they go hand in hand uh for example you can use bolo to generate test that can be used by Meda andna uh you can use Foundry control and symbolic together to formally verify your code do some fuzzing and visualize the debugging process of your contracts so uh do not be ashamed do not be afraid learn as much as you can and make my life as an auditor harder please uh these are some res resources if you want to check it later and now I'm now taking questions fre okay thank you Alison okay let's give some questions hello hello um uh uh invariance within a probability perhaps people uh expect the universe not to change um but what if it does change and like how should people gauge uh you know invariability in that respect sorry can you repeat the last part how should people gauge invariability um within that respect with regard to probability because the universe can change un Bown St that's true that's true uh but the point of invariance is um they go particularly well when you consider math equations so you can uh the the the the point on defining which environment to use comes from the fact of what you you do don't want to happen in your contract so if you think about uh how your contract is supposed to behave you can think also about things that you don't want it to happen and you can use these things to to to to make inance with regards to how they change that's the the the fun part about them they're not supposed to uh so yeah you you think about what you don't want to change and that's your environment until you actually change the code and the design of your protocol uh I hope this answers your question it's within a context right yes within a context okay thank you for this nice question thank you more questions no okay well thank you again Alison thank you please Round of Applause [Applause]