DeFi Security 101 2023: Full Day, 14 July

Transcript

foreign [Music] [Music] [Music]

foreign [Music] thank you [Music] [Music]

foreign [Music] [Music] [Music] remember [Music]

[Music] foreign [Music] [Music] [Music] [Music]

thank you [Music] [Music] [Music] thank you [Music] foreign

[Music] [Music] foreign foreign

foreign [Music] [Music] [Music]

thank you foreign [Music] foreign

[Music] foreign foreign

foreign [Music]

come on [Music] foreign [Music] [Music]

foreign [Music] [Music] thank you [Music] [Music]

[Music] [Music] [Music] thank you [Music] [Music]

foreign [Music] foreign

[Music] [Music] [Music]

foreign [Music] good morning so we're going to start off the programming for d5101 but before that given that this is the first session we would like to welcome you all to the D5 security Summit which is going to happen well it's technically starting now but well technically starting tomorrow but today is the 101 so hopefully all of you are going to stay back for the summit as

well and I'm Rajiv I am the founder and organizer at securium and the first session is a CTF right so if if you look at the agenda we have a maze X which is a capture the flag event so hopefully all of you are prepared to participate in it so let's uh Dive Right In a quick quick note about securium so securium the mission of securium is to educate and evaluate the security of ethereum right so that's the origin of securium security and ethereum as simple as that

and it started as you may have heard of securium from its boot camp initiatives which started in Q4 of 2021 and since then we've been doing a whole bunch of different initiatives so Amaze X is our CTF but we're really known for the boot camp initiative that's entirely online so what is securium securium is an online community entirely on Discord really of people who are interested in ethereum security and specifically smart contract security right

so why do we need this so when securium was created about two years ago even back then well we we obviously have ethereum we have billions of dollars of value right in thousands of protocols on ethereum and all these are secured only by hundreds of experts right so if you look around I mean all you you're all the experts that we are really relying on to secure these protocols and that's not enough right we need more people for various reasons so that is really the mission of

securium we want to increase the number of experts in the space we want to welcome people from the web 2 security space we want to welcome people in the web 3 space already who are developers and who want to you know get into security or you know get better at security because ultimately security is best done shift left so we want all the protocols to actually Implement all the security while they develop the protocols right so that is really the mission of securium so it's all about scaling security how are we doing that at securium

so we started off in 2021 as a three-month boot camp we called it Epoch zero so that was a three-month boot camp there was new content people uh you know many of you uh well some of you may have seen that but since then from 2022 so for more than a year for about 18 months we've been running the online boot camp and this is what we call as Epoch Infinity so it's an always running boot camp it's all online you can join our discard you can see the QR code there we already have some of the content some of it is already outdated but there you know many of you are producing fantastic

content about ethereum about the various changes to it about the various layers about smart contracts I mean there are so many patterns that are changing about all the security hacks the vulnerabilities so all that content is there we need more but you know there's there's a lot more coming up so as part of the boot camp people read those content they join the securing community on Discord and what happens on a sort of a Cadence is the first one is the race what's a race very simply it's a monthly online smart contract security quiz it's free it's open to everyone you know

you can join the Discord there are announcements about when the next race is going to be and who designs these races so when it started off it was me but then the whole of last year we have got fantastic mentors in securium many of them are speaking today and you know at DSS in the next two days so these mentors are taking their valuable time they come and they help design a race and if you haven't seen one of these it's a very simple 200 lines of smart contract code that has bugs in it intentionally right these are just synthetic examples and

the idea is to help people learn about various aspects of smart contact security right so people look at it during the race and it's a very small short race it's it's not like a two-day thing it's just 16 minutes we have a thing with powers of two so it's 16 minutes and there are eight questions right so very short quiz and people take it the answer is all multiple choice there's no you know writing answers I mean it's unlike a CTF it's it's very it's theoretic in that sense so people do these races and we've been having um more than 200 people take these races every month again it's free it's open to anyone right so you just have to jump on

the Discord see the announcements uh register there's a window and then you get an access code that's it after that you can participate in all these races there's one every month right and what happens after that so there's a leaderboard that is published and uh you you know you can opt in for receiving an nft that shows exactly what race you finished how much did you score how many people with all the details so that's cool and then for a few of the races we have a corresponding care right so the top people from the races maybe the top 16 top 32 they are invited to uh care that happens in the following

month and that care can be different but it's typically uh in the form of a workshop and there securium has collaborated with uh you know the leading projects in the space Sartorius spearbert Sherlock Taylor bits most recently verities so we invite people only the top people from that race so if you're at the top 16 in that race and if there is a workshop happening then you get invited you get to learn uh whatever is happening during that Workshop that happens for a week and that is you know that may be a tool it may be about fuzzing it may be um sort of like an audit we had we had some of that a long time ago but most

recently it's all been focused on the tools and fuzzing and various other static analysis tools so that that is what care is so Epoch Infinity is really um the races and the cares happening you know in tandem right so that's that is what the boot camp is but today we are here as aquarium we are a team and we're going to um be hosting the CTF and we have some distinguished alumni from securium who are going to be talking about the various CTF challenges so if you have your laptops please feel free to open them up and get started as

they explain the various challenges so with that I'll hand it over to Eugene thank you hello to all um before starting I just want to say the Wi-Fi password is TSS all uppercase 2023 and uh exclamation mark just in case you could also ask everything anything to us we are volunteers here or you could see us in the Pink t-shirts or magenta okay um so well my name is Eugene I started this security journey in the security boot camp

um has been for me it's like six years ago but it wasn't really that long time ago um so yeah we are here um I'm doing like uh full-time this this full-time like do it competitive about it some you know having fun learning new things um you could ask me anything I had built a few of this challenge um and I think you I hope you get fun of it hi uh it's a pleasure to be here on stage um similar to Eugene my name is Lucas I start out in this space thanks to securium I had no idea about smart contract programming I have no idea

about the issues that security had in these smart contracts and yeah start out with securium Epoch zero and I did this part time doing my PhD in Applied Mathematics and now I also do audits sometimes at Spirit which is one of our sponsors so it's very nice to be part of the family and all thanks to the boot camp so please if you never joined I think it's a very nice experience because you get to learn a lot you get go to these conferences and meet a lot of people and yeah again please enjoy the challenges we made for you and if you've got if you've got any questions please

feel free to ask well thank you Lucas hi everyone I was good to see so many faces at 9 15 in the morning on Friday uh so my name is Pablo and I'm mostly a ux researcher but I've been in the infosec community for quite a long now like penetration testing with team and so on I'm currently building a spear without and as you know like we'll be hot in this CTF if you want please do take it and feel free to ask us questions I'm sure that you will learn a lot of interesting stuff and there is please go ahead hello during a Dev connect trustex also in

Devcon and I have been I'm a evm security researcher and I have been doing a contest encoder enough for tertora and hackathons and please don't be shy if you have any questions please approach us thank you hello I'm lared uh yeah I'm a master student in computer science I'm from Germany yeah I also volunteered at trustex last year um yeah and I've been doing some internship at Sigma Prime

um yeah just having fun in the in the space yeah and the last guy so I think I Ali is missing because he's busy on the entrance um so okay let's start with the first challenge okay this is uh the CDF instruction sorry so we got the eight different challenges uh three of them are easy you should be able to crack it without any trouble if you know regular solidity uh you got uh there's gonna be a three-day competitions um if you are it depends depending on your skill is how many and how many times you got uh it's how many how do you do it uh B good always ask for us

for help and after that there's gonna be a red app and 30 minutes for explanation and solutions um okay I think so some important D5 Concepts that we are going to treat will defy and smart contract programming concept that we are going to treat during these challenges are first the most important the erc20 token standard um think about the functions think about the ABI of the erc20 think about how the state is handled in these in this standard also flash loans think about how they can impact State how one can

modify balance how can that impact other protocols then create and create two up codes some of you know some of you may know these are used to deploy smart contracts and they function under the hood in very different ways they're used for different scenarios so research how how they work and what are the implications of those differences then automatic market makers you know it's probably the most fundamental building block of D5 we have several several different types we are not going to go very deep in here so as a hint if you're familiar with

unique swap V2 that'll be good okay if not take a look at it take a look at the constant product formula and then again the most famous vulnerability in the space re-entrency attacks I I don't think I have to explain that in depth but for those who don't know re-entrancy attack is a computer science Concept in which a process is interrupted by another calling process of the same nature so which implications does that have in smart contracts what can you do with it what can you break with it that is really important then lending protocols in D5 you may be familiar from several famous

hacks let's say for example mango markets for example has been a very a very tough one it has it was a lending protocol so make sure to research how lending protocols work in D5 that'll give you good hints to solve the challenges and finally Oracle manipulation and collateral liquidation for those of you like me initially who are not really who were not familiar with the economic side of things and check out what Oracle manipulation is what what collateral is what liquidation means and how all these elements play together in in smart contract security so now we can start off with an

explanation of the first challenge Eugene please okay so the first challenge is uh mainly you choose to warm up uh it's a simpler C20 token uh if you know you don't know what this energy 20 token uh perhaps you should start doing that it's more one of the more basic things that you could build um the the main goal here is that you have to recover 1000 m e that's the name of the token the symbol and redeemed into it again to avoid further losses uh the contract to hack is just magic it um so the concepts that you should consider here is uh that this token is

pretty similar to wet you could deposit you could withdraw um you could it has an extra functionality to burn tokens and that's all uh it's basic on a recent hack that were lost like a couple of million of dollars so take in mind that this should this simple but it happen in reality um the next challenge is at first sight could be pretty similar um it's mainly a modern Eid um it's a contract that has locked 1000 it and you have to rescue the those funds um

to be honest I don't want to give any spoiler but just take in mind that it's pretty similar to it it has some extra functionality you could always check the for hints into into the readme just be worried if you open in a plain text editor you will see the hints so be aware of that the third challenge they'll Index this destruction the funny effect that initially the description of this challenge was made by Chad gbt but it was a little bit reduced because it was too much and the purpose for this

challenge is um to outline that the code on the blockchain is not immutable and a couple of months ago due to this uh due to this there was a hack done to a very like uh famous and uh two very famous protocol that's how fun so my challenge one of my one of my challenges is called s operation rescue policy token so the what is happening here is that tokens are stuck at an unclaimed address so and there's a factory contract that

deploys some smart wallets right so the goal is to get access to the unclaimed address and recovered tokens no you will not you'll not have to break the elliptic curve to find out the private key it's simpler right um so the concepts that we're going to treat here are the create two op code the way to create terministic addresses and how message sender behaves under different contexts right so here for example you can see a pseudocode line that outlines how create2 works that's a big hint and you know below you have a diagram of interactions that I think if you think about who's the caller and

what what is message sender in each context I'll give you some good hints to solve this challenge so Eugene please okay um so the first challenge that I present were easy this one is a bit more complex um it's also a bit more fun to do because it's small it's mainly um an RC 3626 bulb if you're not familiar with that it's just about where where you deposit token and you meet new tokens um so the main goal here is that Alice and Bob had got funds in danger you have

to rescue them you will start with uh with almost no no eater so it's gonna be a bit trigger you have to to concatenate different attack vectors um yes right the next challenge is safe here it's about Flash loans mainly um yeah there's a DVI protocol in the center which combines two basic concepts flash loans and the decks um yeah so depositors can earn fees it's like your basic default protocol um

your goal is to drain at least 100 Youth and you only start with a little uh yeah so you need to combine those two concepts yeah to drain the pool and yeah that's one one contract and uh just for those who might not be familiar but I guess most of you are where the flashlight is here's a basic concept um yeah so the main idea of a flash loan is that it's all happening like in one transaction yeah and it also uses the EFC in 3156 standard which yeah just to use the standardized approach of using flash loans

so yet another challenge regarding addresses and Cones this call this one is called Crystal Dao it's inspired by a big Fiasco that happened with some optimism tokens if you may be familiar with um speak hint so here we have a factory that deploys ERC 1167 clones of a doll treasury contract and the admin can execute arbitrary logic as long as they provide this signature that shows that they are the admin right and the admin is set on deploy right the goal is to recover the tokens that are stuck at the treasury because somehow the signature of the admin is not working right so a

contracts that you'll have to hack are is a crystal dial contract so for for context Concepts that are going to be treated here is the ERC 1176 minimal proxy standard EIP 712 signatures very important and the way the EC recover function works right here you have a small small small simple diagram of how ERC 1176 minimal proxy work and last but not least if you already got to this challenge then you are a beast and congratulations and this one

I'm not gonna spoil it a lot but it may be related to Market manipulations so if you already see uh what was this one about so Oracle price manipulation and also there might be some collateral liquidation involved there might be so Mev involved but if you're already here and you pass this one then props to you uh looking forward to you guys to solve all of this if you cannot solve any of them then please come to us we will give you hints because our job here is to help you and I think Rajiv has something else to add I want these are the concepts that these slides will also be uploaded on the GitHub so you will be able to browse through them once again

thanks Pablo so yeah um so all these distinguished security alumni design design the CTF challenges but we also had the help from Patrick who is one of the security mentors we had help from tincho who is another security mentor and stir me who is also one of securium's alumni they reviewed the CTF made sure that there are no obvious bugs and so thank you really for all the feedback so with that we are ready to hack um the QR code in the center is the one

for the GitHub repo for this uh you know for the CTF and then we have the telegram channel on the right so please feel free to use that if you have any questions and this is open for the whole three days so work on the challenges if you have any questions ask us um Ali and all of us will be on the channel monitoring it so if you have if you get stuck or if you have any other questions so please feel free and uh Ali that was it right um we just wanted to share the links uh here are the links for the Discord the GitHub and the telegram and

um that's that's about it cool and yeah so as as an incentive we have special Pro apps made for the CTF so if you participate if you would like to get one then please reach out to Lucas so he has the QR codes for that and uh thanks to the DSs organizers the top 16 participants at the CTF will be receiving a free ticket to the next DSS in 2024 right so that's that's going to be we don't know the details of that but you know we are hopefully sure that uh it will happen so

hopefully that is a good incentive as well yeah so reach out to us the main thing GitHub repo and the telegram channel for any questions so we're already there so join and hack away thank you [Applause] um so we do have we do have time so if you start looking at the repo if you have any questions in the next 15 minutes we're all here so just Reach Out and we do have microphones for any

questions so yeah okay okay any questions on this so far

oh so are people able to scan the QR code

and look at the repo yeah doesn't work did the QR code work for anyone it did okay looks like it's the one in the center yeah or Discord is not working uh sorry yeah ignore that yeah so ignore the QR code on the left so that that is stale so the one in the

center is what is useful for today but yeah we'll we'll post the updated one later or you could just Google securium and hop on yeah one more sorry can you pass the mic oh yeah there is no um lib in the repo for the forge

for the install there is no sub module okay here's the smithing Foundry dependency that is true yeah we messed up something by deleting the comments okay um we'll fix it okay

so again so the CTF is open for the entire duration of DSs feel free to hack on it whenever you get time you know tonight during the talks when you take a break and use the telegram channel for any q a and yeah any other questions or troubleshooting on the GitHub or anything else related to the CTF challenges for now [Music]

foreign [Music]

[Music] [Music] foreign [Music] [Music]

foreign [Music] [Music] thank you [Music] foreign

[Music] foreign [Music] thank you

[Music] foreign [Music] quick announcement

so if there are any speakers who are speaking in the later sessions today please just come and talk to one of us identify yourself so we know you're here and uh we can stick to the schedule are there any speakers for d5101 here do we have Nat Nation from trail of bits do we have anyone from Sigma Prime you run

diligence okay thanks [Music] thank you

[Music] foreign [Music] um so

hello oh sorry so for the issues we had an issue copying the challenges from the old repo to the new repo I've just done a push it should be working by now anyways there's someone was very kind to point out the the fixes on the telegram group so uh thank you so much uh yeah make sure to to clone again the latest state of the repo okay if there are any any further issues please tell us on the telegram and we'll we're ready we'll be ready to fix them okay [Music]

[Music] [Music] foreign [Music] [Music]

[Music] [Music] thank you um if we open a safari tab oh

[Music] [Music] foreign

sounds like I don't think good morning so for people who are

joining us now and may have missed the presentation what what happened was we just announced the CTF that Capture the Flag contest so for people who are interested to join there are two just ignore the Discord QR code the the one in the center is the QR code for the GitHub that has this repo for the CTF and all the challenges and the readme does a fantastic job of explaining all the challenges and what what is supposed to be done and if you have any questions please join the telegram channel that the QR code that is shown to the right so that is something that the securium all of us will be monitoring for the

next three days and if you have any questions on the CTF if you get stuck if you have installation issues technical questions on the challenges please feel free to ask us over there thanks [Music] foreign [Music]

foreign foreign

[Music] [Music] [Music] foreign [Music]

any issues so far please reach out we're constantly looking at the telegram group okay remember if there is more issues regarding dependencies or how the repo is built consider yourself a hacker because that's the first step that's the challenge zero that making everything work thanks [Music]

[Music] foreign [Music] [Music] [Music]

thank you [Music] foreign [Music]

[Music] foreign [Music] [Music]

foreign foreign

[Music] [Music] [Music] foreign [Music]

foreign [Music] [Music] [Music]

foreign [Music]

foreign [Music] [Music] [Music]

foreign [Music] [Music]

[Music] possible [Music] [Music] [Music]

[Music] thank you [Music] [Music]

[Music] foreign [Music] [Music]

[Music] foreign

[Music] so we're gonna switch to the next session on today's agenda and for all of you who are participating or who started looking at the CTF like we said you can reach us at on the telegram channel that we shared and hopefully you've already got the GitHub but if you don't then reach out to any of the volunteers who have these t-shirts on like this for for the CTF for for any other questions

so thank you thank you Rajiv for the Fantastics in the second way home team for the Fantastic introduction to the CTF and also helping us the volunteer team for the whole device security Summit uh well this as you some of you know this event last was started started last year and it's a recurring event and last year we had an opportunity to have Netherland chin from 12 bit doing the security track for us and we agreed to do it again is a leader in the security research she is working on on basically all their

security their security tools and kidna are at least listen and others and she's gonna present right yep things and also if you have questions about Wi-Fi other things please ask us there's extra room that you can use for eating but we prefer that you stay here for a moment so that and but the other in this room you cannot have food but in the other room you can have food uh maybe we'll see later I think there's a their workshop by the Jocelyn from trail of beat and also from by Thomas from Satora and Ernesto from bgd maybe you want to sit there or you can sit here

it's probably better you sit here but it's a bit less comfortable with the laptop thanks [Music] all right um so yeah I'm Nat I'm from Trail a bit and today I'm going to be talking about how to write safe smart contracts and

kind of the um I'm just gonna close keys to the key is to writing safe code a little bit about me I'm Nat um if you want me to find if you want to find me on Twitter my handle is here um at trailer bits I'm a security researcher so that means I do security reviews I work on tooling and I get to attend conferences like these to show what kind of how we're using tooling and

kind of talk about the public resources that we have available just to make sure that they're as accessible and as available as possible um personally I I'd love to climb things I like to fall off things and generally that means I'm falling off rocks just around the world on the trailer bit side um we tend we like to try to essentially help people build safe software um what that means is we do a lot of research and engineering and r d based on how to make sure that code is as safe as possible um but that means that everything that we learn from our research feeds into

the creation and the development of our tools which are all open source um you'll probably be familiar with a few of our tools and like our kind of skill set um Slither Echidna Medusa and a few others that a few other tools that help essentially make that developer experience a little better so I did say it was a bit of a climbing nerd um in climbing generally rock climbing without protection is kind of a life and death situation if you're climbing without bouldering mats or you're climbing without clips and carabiners it's something that's considered fairly risky

the safety considerations that we consider in rock climbing are very similar to that of how to think about like smart contract security we work really hard essentially to try to solve either man-made problems or natural problems but a little bit of beta which is essentially tips and tricks on how to get up a route goes a very long way to actually understanding and solving a problem so in this particular comic the the bottom beta in the bottom it basically tells you in order to climb a route to either grow taller or just be better at climbing which obviously is

probably not the best advice if we tie the concept of beta back into kind of smart contract security and Security in general um there is a parallel around like for example a stack Overflow question um and like the solution if you consider asking a question on stack Overflow the beta is basically the answer it doesn't necessarily matter what this question is even asking um but we're going to be talking about I think I skipped uh we're going to be talking about how to write safe code and how to write safe contracts

the beta here is probably going to be fairly self-explanatory and kind of something that should be easy to follow along with um and the whole goal of this is to create kind of somewhat of a framework and some more understanding around what would help security researchers in understanding your code base and what would help with making sure your code base has doesn't have bugs while you're developing so essentially allow you to catch your bugs as early as possible so in climbing we also have this concept we have this concept of a start hold this is where you start with your

problem this is where you start with your climb generally this is marked with a start marker like this so in this particular problem you have to start with four four limbs on that big Square volume and you have to essentially jump over to the others this defines essentially what is the end and what is the beginning of your root so in order to start let's figure out where exactly we should start this is an interesting um concept because specifications even though they're probably the dullest to write are the most important to have for

your code by figuring out where you're going there's a much better chance that you're able to determine how your code is not working properly when you create specifications this should include information like what are you actually trying to build what kind what who your users are and how your users are going to end up using your code and especially how your code is intended to be used outlining these mean that you're not necessary you have a Target to reach having these means you have a Target to

reach and it also means that you have the ability to know what future Implement what future features you might want in your code and what future areas you want to extend your code in so in terms of what a good specification should include there's there's a whole lot of information that could go in these specs um and so this is kind of a highlight of what would be the most important generally when we're writing code we make a lot of assumptions around your code is only supposed to work under certain conditions or a user calls your function with a certain input range or the

endpoint or the caller of your contracts is supposed to be a certain address if you are writing down all of the specific all of the assumptions that you're making and including that in your specifications it means it's much easier in the future for someone to be able to read all those assumptions and understand when this code is supposed to work and what is supposed to happen if those assumptions don't actually hold we'll be coming back to ways that we can verify that the assumptions actually hold and there's a multitude of ways that that can be done but having those those assumptions and having that in your specification

um is going to go a long way to actually understanding um what code you actually want to check and what your what you want your code to do more specifically the other benefit of writing down all of your assumptions is that you're then also able to identify all of your edge cases and cases in which your functions are supposed to work so if you have an idea of how your function or how your code is supposed to work under the proper inputs then your you should be more able to actually analyze the edge cases and cases that are fall outside of that if in the case that you do have any mathematical computation and kind of

assumptions proving any kind of formula is going to be very useful to actually verify to actually check that your math works as you intend one common thing that we see generally is just that the there's an assumption that like a math function is supposed to work under certain inputs but that doesn't actually hold for the entire subset another thing that should be included in in these specifications is how a user is supposed to interact with your system so having a list of features and functionality that a user can perform is one thing but also having

the full call stack between what if what function a user calls and what functions in different checks get invoked after that is going to be very useful to actually check that you're doing a all of the data validation that you need to do and B checking that you're actually making all the state changes that you need to make so that ties into Data validation assumptions as well by that we mean if your function is callable by and only by like an only owner modifier than what other checks that you what other checks you do you

need to make based on the other inputs that are coming in for all of the functions where you have even publicly callable functions with like arguments um are you actually doing the proper data validation that needs to be done another aspect that's important to outline is when your code is actually supposed to work so when is your code reverting and when is it when it should be successful by writing down all of the cases in which your code is actually expected to revert that allows you to have a better mental model of your

architecture and allows you to see essentially end to end if your system is interact if you're interacting with your system in one way how what impact does that have on your code base and on the other side specifying when your code base is or when your function caller Etc is expected to not revert outlining these is not just important for implementing automated testing um but is incredibly important for actually understanding how your code is expected to work going more into kind of um the the code side

um having that spec um on all of your publicly callable or all in all of your functions um is useful just because you're able to specify essentially what um understand what the function does what are the inputs that are expected to come in and what are the expected return values from that you have a much better idea of per function what is expected to happen um this is one thing that's it sounds very easy and especially if you have a small code base it may be easier to do but as your code base grows having Nat spec is going to be even more important to actually identify how each of how all of your functions work together and

isolating logic in between those different functions so similar to user flows um another thing that a good specification should have is creating user guides essentially a user guide is outlining how a user is expected to interact with your system if they're going to be specifying for example slippage values how are they defining um how are they determining like what slippage value to choose and kind of examples in terms of how how to choose these inputs the benefit of this is that once you have

um all of this this whole list of what a good spec has it means from a review perspective and from a developer perspective you know what your code does and that assumption is the most important once you have it all written down it's it becomes a lot more concrete as to what the code is expected to do so the the benefits is basically you know what your code is supposed to do and you know it's how it's supposed to work so it's not just you know my code implements a liquidity pool and it does swaps that's a bit too vague to actually verify that it has no or to check that it has no bugs if you have these

detailed specifications it's much much more easy to essentially determine what the impacts are so that brings up an interesting question because if we're writing down everything um as we're creating these specs it doesn't necessarily mean that our spec is is with something that we create once um and then leave it as is the assumptions that um we essentially essentially are making for like writing this code is generally something that changes with time is where you know adding new functionality as we're making new changes to the code base making sure that that spec is up to date and essentially updated every time

you change code in the same way that a unit test should be written for every time every function you add is a way that you can make sure that that spec is always live and always reflects essentially your your most recent changes as well as your most recent assumptions there's generally a confusion um with especially code bases where we have outdated documentation and new code then is your code the single source of Truth and if it is how there's there's it's very unclear how to verify how your new code is expected to work in comparison to previous versions that are

documented so that's quite a lot about specifications and that's one tool that we can use to essentially be able to help us make essentially identify what assumptions we've made on our code and make sure that those are explicit but there's a lot more tooling that can be used to help us make sure that we've we're actually making sure that our code is safe so also with climbing we have this concept of tooling as well generally on really big walls we'll have like ropes carabiners anchor points where essentially you can see on the picture

on the right there's just an insane amount of rope and gear all of these all all of these tools are basically used in order to keep climbers safe if they fall they'll end up dangling in mid-air but they're not going to the ground similarly we have to these kinds of tooling with blockchain security as well one thing with Tooling in specific is there we should be making use of this these tools whenever we're writing new code you don't want your anchor points to look broken and in pieces like this unit testing is one of those anchor points that that can essentially help

you determine not with your in combination with your specs how your code works and what is it supposed to do and does it actually do what you intended to so it's an interesting conversation to have because you need your specs first you need to essentially identify what your expected behavior is and then you need to identify essentially what is the happy path in terms of if a user is going to interact with your system what are the the how is your system expected to work under the proper inputs under the assumption where everything works and the user inputs like all the correct

inputs um the unit test should essentially be testing that entire flow for all of your functions but it should also be testing the unhappy path so this would be if your function is either reverting or not working correctly is it reverting in the right places is it under inputs that are malformed or incorrect does that have any impact on the system with your specs once you've written down all of your assumptions it then becomes very easy to identify what your edge cases are edge cases being cases where you may not have considered

maybe the upper bound of like a un256n like the lower bound um generally we recommend that everyone's testing the full range of inputs so they're testing essentially the expected um input range as well as the edge cases in the unexpected range another thing that is definitely beneficial in unit testing is having at least minimum 100 statement and Branch coverage the benefit of this is that you're able to essentially check your system under the inputs that you've provided so this helps you

um if like you can specify you know certain inputs certain checks that you want the code base to hold true and under those cases um this 100 statement and Branch should help with essentially checking against those specific input ranges the then the benefit of unit testing becomes there are we we should be able to find use unit testing to find um how the spec is different from the actual code um from the spec we should essentially have those list of expected behavior and assumptions and from the code we should be able to check those

another thing is it does force you to write testable code in that it forces you to separate logic into smaller like unit tests into smaller functions that you can easily pick up and test logic against this is beneficial because you can then do unit tests against individual functions and then you can pick up like integration tests with different modules as long as you're updating code these unit tests should be being these unit tests should be written alongside this code it means every time you're writing like a new function you should be checking like the in the

correct input ranges the edge cases and making sure you're hitting that expected coverage this also the benefit of this also means that in the future if you're changing your code you're refactoring um it future proofs you from reintroducing that bug in the future if you do actually reintroduce that bug um your system will essentially tell you that there is like a unit test failure the whole goal of unit testing and these tools in general is basically to identify bugs as they're being introduced during the development process as opposed to thinking about security at the very end there are however limitations of unit

testing and this is generally in that the the coverage of your tests are only as good as the inputs that you've actually tested against so if you're um for example your function works against you a un256 and you've tested maybe a smaller subset of that bound if you're not testing the lower bound or the upper bound those unit tests are not really conclusive so even if you have a 100 statement coverage on that kind of function not testing those extra edge cases means that this that unit testing isn't able to uncover bugs in those areas uh the other thing of course is that it

doesn't test Integrations between components so if you're if you have a D5 protocol set up you're integrating with multiple other D5 protocols um unit testing is not going to help you identify either how there are deviations in like expected Behavior with those external calls but it's just going to tell you essentially per function it's going back a little bit to climbing um generally with climbing hole we have a series of climbing holds and a jug essentially the best hold that you can get on a route it's the one where you if you're trying to jump in mid-air those

are the jugs or the holds that you're aiming for obviously as you get more and more challenging and challenging routes then you you essentially get into to the bottom part where it gets smaller and smaller and it gets harder to actually hold on to so this is how a jug would be used generally a jump we love them just because they make our lives much easier they make it they make Roots much easier to climb and they're basically like monkey bars but maybe a different shape so in a similar way static analysis is

basically your jug it's your automatic bug finder if you were to imagine like security researchers or Auditors going through code and just maintaining like a growing list of vulnerabilities like going through wrecked news and writing down pretty much all of the breast all of the reasons for previous hacks and identifying like smart contract best practices the accumulation of these essentially determines would give you like a for example a list of like all the ways that protocols have been hacked or like functions have behaved incorrectly if we consider Slither Slither is

basically taking that huge list and applying analysis on your code base all statically so it's basically looking out for any kind of best practices within your code base and especially any kind of violations so we could go through that manually and probably a lot of the time sometimes people do um but one benefit of Slither is that if you're running on a code base it can essentially tell you instances where reentrancy might be possible it's not going to tell you this is 100 exploitable because that's not something that static analysis can do but what it can do it tells you what might be a problem

and so the previous example here is output from Slither action so this is integrated into the GitHub CI platform and what this basically shows is a is a code snippet where and it outlines a potential area where re-entrancy might be possible as security researchers and developers this would be our chance to go in and actually check whether is it making an external call is it handing off execution flow to someone else that kind of thing so again Slither is going to analyze your code statically which means it's

just going to check against the best practices but it's not necessarily going to tell you that something is a hundred percent exploitable right now it matches 87 best practices or detectors to essentially determine and find these vulnerabilities so that brings up an interesting question because once we have Slither findings what do you actually do with it um if it's currently exploitable and it's currently a problem that should be a sign that you should just fix your code um essentially if it's for re-entrancy add a non-reenchant guard or use checksfx

interactions pattern if the code can potentially be exploitable in the future due to like governance updates or some other code upgrade that might be possible then that would be a case in which you would want to document and make sure that it's explicit that any kind of code update in the future will essentially make will have these impacts on the system so similar to unit testing it also Slither also has its pros and cons it runs quite quickly on code bases which means that it gives us quite a quick view of what might go wrong and it tells

you what looks wrong but it's not going to tell you what is exploitable um it's going to tell you um there are violations of best practices but it's not going to specifically say this is exploitable in this way it requires human interaction to go in triage and determine whether what the impacts are so in climbing we also have this concept of a Crux this is the hardest part of a move or root this is the part where you usually have to fight the most um this is essentially the the most

challenging part of climbing and in the blockchain security world this is basically fuzzing fuzzing will stress your code with random inputs so kind of like a cat on a keyboard or a monkey on a keyboard it's basically in like for example that function that takes in a un256 instead of being defined by the input range of a unit test fuzzing essentially going to Generate random pseudo-random values in order to test the breadth of how that function works um fuzzing does also force you to identify how your system is expected to

work through the creation of system and variants in some ways you can think of fuzzing as a robot unit testing in that the fuzzer is going to determine what are the inputs to check but as a developer as a researcher our goal is to essentially Define encode what are those assumptions that we've made on how the code is expected to work um the other area of fuzzing is that it can be slightly different more difficult to actually set up an end-to-end infrastructure and especially as you get into more complicated bugs can be difficult to get stood up so in terms of tooling we have Echidna

which is our open source smart contract fuzzer and it will automatically generate inputs for your functions so determine based on the properties that you define or those assumptions that we were talking about in the documentation section those are essentially converted into code and then Echidna runs on a code base to determine a is it possible for those assumptions to be violated but also if violated what inputs actually cause that violation the benefit of fuzzing is that it provides more complex bugs and quite a large quite an interesting subset of

bugs that may not have been uncovered through unit testing and it can help us better with determining those edge cases generally it's considered more complete as unit testing but the setup and and this the setup and the getting stood up with contracts can be a little bit more difficult so going back a little bit to climbing generally before we hop on a route we're doing a bunch of rope checks safety checks belay checks making sure that we're all tied in making sure all our ropes are in and basically after all of that the comic ends with I don't want to climb this route anymore but we can

still climb the route um tying this back to the blockchain safety side one thing to keep in mind is that blockchain or Security in general is a continuous process so it's not something that you should be doing all your development and then thinking about security it should be something that you're essentially thinking about security as you're writing code generally as a practice write everything down even assumptions that you think might not actually be relevant in the future having those written down in any form is going to be very useful that means adding unit tests as you're adding functions running Slither as you're adding new code

determining and identifying invariance as you're building out your code base and then running fuzzing tests and making sure that those properties hold so we're right at time if you want to learn more this QR code is basically a link to securecontracts.com and this provides a lot more information around development guidelines incident response plans and how to create them more guidance on how to get a kidney stood up and examples of what those code bases look like and way more So yeah thank you [Applause]

thanks Nat for the wonderful insights so hope everyone is ready to climb the slippery slope of blockchain security um so if do people have questions for that we have a few minutes anyone just please raise your hands and we'll pass pass over the microphone thank you very much for a very clear and precise presentation can you just clarify just a little bit more on the 100 statements what what kind of statements would be expected to be written about the smart contract as opposed to what's in the specification um statement coverage is basically that

you've hit every single line that your unit test has adequately covered every single line of your code whereas Branch coverage if you have like an if statement the branch coverage may not be like there may not be an else statement but you should be checking you should have a unit test that exists for that else case so by having that unit test that 100 unit test coverage basically gives you um somewhat of a check a sanity check that your system behaves correctly under that input we have time for maybe one more question thanks for the presentation and uh is

the rattle tool being actively developed right now the one which works on the bytecode the rattle tool rattle tool from uh trail of bits um the rattle rated oh um yes so rattle was created um quite a while ago for um yeah for CSG analysis I think there are some changes that we've been making but it's slowed down a little so that's one of our tools that doesn't have as much contribution

fantastic thank you NAD let's please thank the speaker again so we now have a coffee break for the next 15 minutes so please head downstairs it's on the ground floor and there are signs to the food room where you'll find coffee and please make it back up here by 11 20. we are going to have Sorry by 11 10 so we're going to have um yaroslav from surtora talking about formal verification testing your code on arbitrary States so we have 10 minutes feel free to go grab a cup of coffee and be back thank you

thank you [Music] [Music] foreign [Music]

[Music] [Music]

foreign [Music] [Music] [Music] [Music] foreign

[Music] [Music] foreign [Music] [Music] foreign

[Music] foreign [Music] foreign

[Music] foreign

[Music] [Music] [Music] [Music] foreign [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

foreign [Music] thank you [Music]

[Music] [Music] foreign [Music] [Music]

[Music] thank you [Music] foreign [Music] foreign [Music]

[Music] [Music] [Music] thank you foreign [Music]

[Music] foreign [Music] next talk in five minutes thank you [Music] foreign

[Music] [Music] [Music] [Music]

foreign [Music] [Music] [Music] foreign

[Music] [Music] foreign [Music] [Music] welcome

[Music] back foreign [Music]

foreign [Music] [Music] [Music] foreign

[Music] foreign [Music] [Music] thank you all right welcome back

hope you had a good coffee break so the next speaker is yaroslav bendik who's a researcher from sultura and he's going to be talking about testing your code on arbitrary States AKA formal verification please give a warm welcome to yarislav thank you thank you for the introduction uh can you hear me you can hear me right um so uh I want to basically show you how you can use formalification to improve the security of your code um I'm sure that we have heard about many bugs that have appeared they might have appeared in small contracts they might have appear in big contracts in many cases they're a lot to losing

millions of US dollars but it's not just about money the contracts are losing trust of the community Factor issues and I think we all agreed that uh we're going to get rid of a box we're going to prevent bugs from being exploited from being even appeared in the smart contracts and the question is how to achieve this there are many techniques that are usually used like testing fuzzing everything you know these techniques these techniques are actually used also in other areas of software development process so like testing is used in almost every software company right but in this talk we are not talking about these classical techniques we are talking about formal verification and from notification might not be so

well known and it might not be so widely used it is the case but I hope that after this talk uh you will see that it has some value and it can be beneficial to use it especially in the area of D5 so what is formal verification there are many definitions this is one from Wikipedia and it says that formal verification is the act of proving or disproving correctness of algorithms with respect to certain formal specification using some formal methods of mathematics important parts here are proving or disproving this basically means that you should get some guarantee mathematical guarantee that there are no bugs but what does it mean no bugs this is the

other part of the definition formal specification you need to properly without any ambiguity Define what are the properties that you want to verify then you verify it so if you write wrong specification and you run sample modification it's just there's no no bugs might not be the case because you might have wrong specification so you need to write specification and then you can apply the formal verification and the specification is not written in English it has to be precise okay so um there are many myths and claims about formalification maybe we have heard about these I don't know how much you know actually about foreign can be only used to prove things

or that the artist problem is computational meaning that formal irrigation does not scale for real programs okay because you are really providing this guarantee there are no bugs like no execution can lead to your back another claim um you get a bulletproof code if you run from verification or claims that formula replication can replace auditing or testing or that you apply for verification once at the end you are done you recall and then you verify so these are some claims maybe myths and during this talk I will try to shed some light on this and uh yeah the river is the reality at the end of this talk good

um there are many existing tools that are using some kind of formal methods this slide is showing just some of them and you can classify this into two groups one can be called proof assistance and basically these tools are for instance Isabel Daphne cook cake uh they can be used to prove very interesting properties of your program but on the other hand the user has to be very experienced so you need to know how to use these tools you basically go over your code we are providing some lemmas about individual instructions internal functions in the code and then we can prove complicated stuff but it takes a lot of time okay and if you change your

code you need to adjust the improve so very powerful tools but hard to use uh on the other side we have a fuzzing and static analysis tools so these tools are easier to use they are running quite quickly the user does not need to really know how these tools works and yeah if you change your code you can just run it through again and it gives you some quick answer but these tools are limited in some sense they can give you some positive sorry false positive or false negative answers meaning like they tell you there is a bug but it might not be a real bug or they might miss it back they are not exhaustive okay and at our company we are developing

something called certain approver they are trying to be somewhere in between so basically our Tool uh should give you the guarantee that there's no back but the hard part is that the user does not need to know from a verification but the user needs to write a specification so you really need to understand the underlying contract and you need to properly specify all the behavior and only possible bugs that might happen you don't need to say like Alex is stealing one thousand eaters okay but you specify some properties I will show you some examples later so in the rest of the talk uh I will illustrate how formal orientation can be

implemented following the example of certain program the input of our tool is your program and some specification and the output is either a execution of the program that violates the specification or you get some mathematical guarantee that there's no violation and since this problem for modification is quite hard we are really checking every possible executionary program then sometimes you time out this problem is really hard we are trying to find the box or give you the proofs but sometimes the time out it can happen so uh two things to explain now how to write a specification and how does

little work so let me start with the specification um this is a simple uh solid smart contract example um there's back in this example so let me just explain this this code with some mapping are called balances so this is basically like storing the information about balance of internal users or the smart contract and then we have these two functions transfer take some address from and some others too and some amount and it should transfer the amount and then we have another function balances off we just takes some address and tells you the balance on that address and then the question is what is wrong about this uh about this function transfer

so let's just explain how it works we require that the from account has at least amount which makes sense if you want to transfer that amount and then you compute the new balance from the New Balance to store it to some variables then you upgrade your balances using these two variables so what is wrong can we see some back in this function we'll think of wrong right so uh this is actually back that appeared already several times and I'm showing this one because one of our

customers just introduced this back uh in their like it was not in production it was during the development this customer is using our tool so they are writing some specification and running a tests during CI okay so we have a row that can catch this back that's why I'm talking about this one and yeah debug is that uh if you send money to yourself you can increase your balance and yeah it's because you first compute the New Balance like you're adding the amount and then you decrease your bonds but then you override it again so I hope you can see this Behavior okay another question is uh how can you find this back using R2 so as I said you need to write a specification and this

specification might not be saying that when you send some money to yourself you will increase your balance it might be saying something else but it should reveal this back okay so here's the rule that was used in the CI tests um what is the rule so our specification consists of several rules every rule is like a single piece of specification you want to verify with Hardware okay this rule is called the sum of form and two balances stay the same so basically it is saying that if you execute the transfer function then the sum of balances before the execution and after the execution is the same so no tokens Can appear basically or disappear um how does it work

um you say that you have some address too and you have some amount you are not saying what is amount we are not saying what is the address just that we have some address and some some amount then you say that you have some uh environment e what does it mean this basically represents the solidity Global variables like message sender message value block timestamp okay so we are basically saying we are at some state of this smart contract we have some amount we have some others too then we compute the sum of balances of message sender and two okay by calling the solidity functions and then we call the transfer so we are transferring amount from message sender

to two and then we check that the new sum of these two balances is the same as before the transfer and our tool is basically checking if there is like any assignment to to amount e that violates this assertion okay there is one in this case not just one their money okay and then Alice is one of these examples because the initial sum of Alice is 14 like 7 plus 7 and then after the um transfer it becomes 24. so this rule will be violated and it can get you to understanding this kind of example okay

um let me show you another example so this is something like a generic uh boiler applied how to write specification your specification language so typically it goes like this um you said that you are at some state of the contract so you have some like message sender message value um you have some storage State you do not say what is the current state of research storage then we can have some requirements some assumptions about the message sender for instance or about this storage so you might for instance require that there are at least 10 accounts in your smart contract okay energy sum of balances is lower than 100 you can have some assumptions then you invoke some function from solidity and this function might return some

value some X for instance then you can have some requirements some assumptions about the result of this execution like assumptions about X or assumptions about the storage that was changing because of the location of the function then you can call another function for instance maybe using the same e variable maybe you can Define new variable so you have like two people that are calling this smart contract and they are somehow interacting and then again you can require something about the execution of that function and at the end you have one assertion or maybe with more assertions that are talking about the effects of the execution of the function like in case of Alice okay this sum has not

changed so you kind of like arbitraryological reasoning about the effects of the interrogations of the functions and yes I said before R2 check this for arbitrary value of e arbitrary values of you know state of the smart contract but before the requirements that you provide uh and this is not not everything uh our verification language can you know allow you to do more crazy stuff so you can Define some Hooks and goes these are basically um you can modify the underlying solid code so whenever we invoke some function you can go uh count invocations or functions or you can summarize some functions meaning you can

override some functions in solidity which might be very useful for instance if you are verifying some property that does not depend on some function you just override its functioning just say this is something simple I don't care what this function does okay you can use quantifiers like for every LS there is some John that does something if Alice or I don't know uh you can have a muffins meaning we are not limited to you 256 you can have arbitrary numbers and many other features and actually tonight we have a session of automor uh so this is all about the specification from my side today I would be happy to answer some questions or talk later but uh now uh let's see how the tool actually works

um so this picture summarizes the steps that we do during the verification and I will now go individually over these steps and just tell you briefly something about them the first step is that we um Integrity solidity and we compare it to event bytecode and the reason is that different compilers produce different bytecodes they might behave differently with respective specification and sometimes the compilers even contain some bugs and we've actually identified some bugs that are fixed also because of us we are very proud of this but the important information is that we need to verify the byte code that is uploaded to the blockchain to make sure that you know device order is used by our customer

and uh I might be saying like this is something not nice it's not nice so there's some drawback and the drawback is that if you find a violation or the specification we need to show to the user what is the valuation like what is the execution of the smart contract so we need to map it back from the byte code to the solidity and this might be hard another issue is that the byte code is uh complicated it's not easy to read it is using so many basic instructions and this code is really hard to automatically analyze and we are trying to automatically analyze the program so even bytecode is not good for us and hence in the next step we take this bytecode and we convert it to our custom program representation

and we call this one uh three address codes I'm not sure maybe I've heard about some three horoscopes before and uh yeah is our custom one and um basically the three horoscope is using only small number of unique instructions and it's quite simple which means that it's easy to analyze and also if you can translate another language like Solana maybe two or three hours code you can run R2 on it so there are other animations of this good [Music] um other part of the input is the specification so basically we also take

the specification and we somehow merge it with the byte code and form together the three others code the program representation and we take the assumptions from the specification put these associations to the tech program and then actually it's about trying to find sorry trying to reach and violate an assertion in data program this is the verification task now okay uh what is the next step um we have this stack program that represents the input basically and now we try to analyze it and simplify it using some static analysis so the goal is uh yeah identify useful information so for

instance we run some pointer analysis for example if you have some two functions in some cases we can identify this that these two functions do not touch the same memory so they do not interact with each other and this can really simplify the verification process because you know there is no interaction between these two functions or we do a program slicing also explain this on an example sooner meaning that you kind of you and 256 variable meaning so many possible values perhaps this variable is actually bounded in your program it's always between 0 and 10. if you get this information the verification is much easier because you don't need to assume so many combinations of values of

variables so we reveal very important information about the program I will also try to simplify it we change it so that it's like you know suitable shape for the following pipeline now the slicing example I don't know if you know what is program slicing so a very small example uh we have a program with two structures X and Y both have internal variable f x f is one y f is two then we change the value of YF to the three and then we have this assertion that XF is one now let's say that this is the specification okay the assertion is the specification and you can see that this holds I mean it's trivial program but the program slicing the program slicing

is about observing that the value of y does not matter it does not affect the assertion so you can basically remove this part from the program and you can work with just with this program it's equivalent program with respect to the specification so we are trying to do automatically these simplifications of the program before we continue with the following pipeline um good Next Step so uh we have this three hours code it's a program it's really nice it's simple and now we generate something that we call verification condition so what is verification condition it's a logical formula you can imagine

like a mathematical formula some equations over some variables is satisfiable if and only if you can violate the specification and also the variable summaries format is somehow correspond to where I was only solidity and so if you get a like satisfying assignment of that formula you actually get execution of this smart contract that shows you the evaluation I'll show you an example later but the question is okay how do we build this formula let me state it in English so reformer says that uh there exists initial values of variables of the program such as after execution of that program with those variables with those values you value the

assertion okay if this formula is true then you have the execution that balance the specification we are done um right but this is English we need to use some some logic here uh the important properties I have said you need to ensure this mapping back to solidity so the like variables that will appear in the formula earlier have to correspond to variable from the program and you'll also need to some encode the execution like which branches are taken in the program which functions are called you need to import all of these so how do you turn the program into logical formula that's the question uh the answer is uh you don't have so much time so answer is very simple

and that's because the 3rs code is almost a formula so uh let me explain this code means that you are using only three instructions per uh sorry three addresses per instruction so they are very simple okay uh second thing uh it's in a so-called static single assignment form this means that you cannot change values of variables in your program but we want to do that right so if you want to increase X by 5 you create a new variable X1 and you say that X1 is X1 sorry X Plus 5. and yeah this now looks like a logical formula

like mathematical formula because you are not changing values of variables they have like a unique value very unique like given value you can express the value of variable in different ways but it's like one value so assignments in the program looks like logical formulas right uh what else do we have several other instructions for instance branching so you have some condition if C then do Branch a LS do Branch b these are implications logical implications every condition holds then we perform a what is a maybe some assignments logical formulas right so this works and yeah then we also need to deal with loops and some assumptions some assertions I will not cover these

but basically you can convert all the instructions from three years code to logical formulas and somehow compose them and then you form the sentence from the previous slide and you check it that's the idea okay uh so uh what is the next step in the next step we take this verification condition and we convert it to something called smt so smt stands for a satisfiability module Theory and the theory might be integers reals it might be using non-linear operations linear operations so basically uh and then there are tools there are syllables

there are solving like these problems expressed in SMD that was the difference between verification condition and smt in the verification connection we we do not say how we represent the numbers if we use bit vectors or if you use integers and yeah in the smt we do and there are many solvers you are trying to somehow combine them communicate with them run these followers in parallel so this is basically about maybe verification condition is algorithm smt solving might be program that solves your verification condition this at our company but I will not go into details about the SMD solving it's a different chapter

okay uh so we are getting to the end of the pipeline you successfully run the verification and you either have a proof or you have a back okay uh are we done no we are not done definitely not done um so what happens if you find another example this is an example of a report that our tool is providing so let me explain uh this is a report from the uh RS example like the trans server you can send money to yourself okay on the right hand side you will see all the rows that you have verified in this case you're just dealing with one rule on the right hand side you can show the values of variables for me specification

so remember in the rule you just Define some variables but then the tool is trying to find some values of these variables that would value the assertion okay so here you can see the uh message sender you can see the two they are the same it's some Alice and you are sending a five I'm almost five and this sum was 14 meaning that analysis Burns was seven at the start of the at the start of the computation okay so this helps you understand a bit what was happening and then we have this called race so basically in the code race we first tell you what was the initial value of the storage what was the massive Center and so on and then we performed the actions from the specification from the

solidity and then we have the assertion so what can you see here um this storage so initially we had just one user in the account it was just this LS airbrush was seven and then if we Zoom a bit um you can for instance see what was happening during transfer with the balance is mapping so we have loaded three times seven then we have a start two because we have you know yeah remove the M15 and then we have start 12 which was the like wrong wrong original right this was evaluating the specification and this is how Alice got from 7 to 12 by just invoking the

transfer function this helps you to understanding kind example so uh are we done do you understanding of example in this case yes in general no and in practice the issue is that uh you might get the country somewhere it's not real and I have said that this should not be happening from verification it might if your specification is wrong because you need to specify what is the state of your contract so for instance if you're saying that the sum of balances never drops to zero but you do not say that it's not initially at zero then you can travel like valid specification so you need to specify correctly okay uh good uh so we are closing the maps now um phone notification is used for uh

proving things it can be used to prove things but it's also very good at finding box violations uh second myth the biggest problem is to compute it sometimes we time out but the biggest problem is to try the specification this is really hard uh modification but it takes some effort through verification produces bulletproof code no you need to write the right specification okay it's all about specification for notification replaces everything it does not it's something else the floor notification should be done just once at the end no way you should just just use both okay uh this is my almost closing slide

uh we hope that the community will start using our tool actually the computer is already using our Tool uh we are organizing several competitions uh where you can actually join us you can start writing the specification we can give you some money if you write some specification that catches sandbox this might be real box might be injected bugs there's a way how you can start using our tool how you can align online specification and for instance it can also help you to deal with this HD flag that we have just started today you can use certain approver to solve these challenges and finally it's not just about competitions actually we have this something called pay as you go but it's

like a title version you can start using our tool without paying any money just use it try to find some valuations this is QR code please try it and if you have any questions reach me out I'll be happy to talk thank you [Applause] thank you Eros love that was some fantastic insights into formal verification so we've run out of time for this session but yaroslav from suratura is going to be around for the whole weekend DSS so if you have any questions I'm sure you have a lot of questions on formal verification so please reach out to Yaris love he'll be around so thank you

thank you everyone [Applause] great so we have uh another exciting talk now it's by Dimitri and Richard from Sigma Prime they're going to be talking about protecting contract upgradability through sound proxy pattern usage so please give a warm welcome to Dimitri and Richard [Applause] oh yeah perfect thanks babe

cool um yeah okay I think we're ready uh Hey guys my name is Dimitri I'm a blockchain security engineer at Sigma Prime uh this is my colleague Richard we work in the same area basically uh looking at security issues in DPI protocols and evm compatibles uh smart contracts as well as non-evm stuff like client implementations So today we're going to talk about sound proxy usage uh and uh yeah basically we'll cover what is a proxy transparent versus your ups proxies and some best practices when it comes to implementation okay thanks so um what is a proxy well

one of the key attributes of an ethereum or ethereum style blockchain is that basically once you've deployed your code your core your code doesn't change there is one quite one specific exception but for the most part this holds true once you've deployed your contract your code isn't going to be modified it's not going to change you can't change it even if you want to and this has some upsides and some downsides the main upside of course is that because your code isn't going to change people can trust your code not to change which is useful if they're going to put a lot of money or valuable tokens into your code um but it has the downside that if your code has a problem maybe a bug maybe a security issue is discovered then you can't modify it and you can't also

upgrade to add new features so proxying is a system which gets around this it doesn't directly change your code it works by sort of borrowing code from other contracts which we will get into so let's imagine we've got a proxy contract here this is contract P or proxy and the proxy doesn't have much uh code of its own it has a variable telling us where we're going where the code we're interested in actually exists and in my example here that is inside contract a um here is contract a full of lovely code so this is the code that you would write or the project developer would write

um that's the code we're interested in and proxy contract p is going to sort of borrow it P um does contain code as well of course but it's just the code to make a proxy work uh so to have an example we've just got a very simple set of code in a here we've got a variable called number and then we've got one function which gets it and returns it and another function which changes it and it works like this proxies work like this you call the function you're interested in on the proxy and then like I say it sort of borrows the code from the other contract as in this example so the the function there only exists in contract a and contract P

sort of borrows the code from a and then it runs it using contract P's own contract address and it sets it in its own storage right if you notice inside contract P there we've got number equal three so we've set the variable inside P's own storage even though the code was from a and we can imagine you can sort of duplicate this out so imagine we had another proxy contract just the same as P but we've called it Q it's also using the code at a and you could then call the function on queue as well um and as you can see because it's using its own storage we've got a different value of number in the um storage of Q and the storage of a remains untrained unchanged we could if we wanted call it

directly on a like that and we're then modifying the storage of a this is a different type of operation it's the sort of more basic operation right and this is called a standard call when we're talking about proxy is one of the key Concepts to know about is that there are these two types of calls going on a standard call and a delegate call now a standard call as the name implies is the sort of call that you're used to the calls that funk that contracts generally make to each other if nothing else is going on the calls that uh users make into contracts are standard calls and they use the everything of the contract so that's called contracts code

the called contract storage they're called contracts address the other type though that proxies use and and other code can use as well it's a delegate call so this uses so this is the sort of borrowing step that I'm talking about this is um using the code of the contract that you're calling but your own storage your own address the callers storage and the caller's own address and so you get this sort of what I'm describing is borrowing the code and if we go back this is just a diagram of everything that we've already seen um and I've just put the different call types onto the diagram so contract a the last thing we did is at the top there

that red arrow that's just a standard call into contract a modifying its own storage then at the bottom left the you've got the proxy flow going up that diagonal on P and it starts with a standard pull into p and then sort of behind the scenes if you will contract P makes a delegate call into contractor a um to use its code and running with its own storage and address um so if we go back to where we were before we've got rid of Q let's move a over and now let's say that we want to upgrade right so if we want to upgrade what we do is we create a new contract um but no down in contract P note where that red ring is we've changed our

variable we're no longer using the code a we're using the code at B and if we look at the code of b b is just the same as a but we've added this very simple function which is just returning double of that stored variable and just getting rid of a there just to tidy up and then if we call that function our new function on P again it goes over it borrows the code from B just as it did before it's borrowing the new code that we've added note that it's running though again with P storage so it's setting that using the value of number that we set previously actually using the code of a completely different contract right it was contract A's code that set that variable in P storage and now we're you're doing

operations on it using the code of B and that's the basic idea of upgrading cool um yeah so uh Richard's basically talked you through how the logic of most uh proxy contracts work uh I'll just quickly discuss two very common implementations uh so we have transparent and uh Universal upgradable proxy standard uh just abbreviated to UPS and uh yeah basically uh we'll just do one like small unofficial like kind of bit of advice uh we'd kind of prefer you to be a bit skeptical of other variants of these proxy contracts just because they kind of add complexities uh

only use them if you are absolutely certain you need to like based on some specific use case uh so transparent versus UPS so talking about what the similarities are first uh essentially they like Richard said they deal with storage in the proxy contract they deal with a delegate call based logic and they refer to a logic contract in order to actually update storage and actually uh process kind of function logic uh so in terms of the differences well it really is dependent on how the upgrade occurs so in transparent proxies the upgrade logic is handled within the

proxy contract uh using a standard call so just a regular function call whereas on on the UPS side uh contracts basically uh are forwarding all calls using delegate call so it's the actual implementation contract that handles the upgrade process so if we kind of zoom in a little bit more so in transparent proxies we need an admin user or a contract that's whitelisted the admin user will call this uh particular fallback function and in doing so the transparent proxy knows that this should be something that is an upgrade process because the admin would only ever call it during upgrade

on the UPS side it's forwarding all calls to the logic contract so Access Control needs to be implemented within the actual implementation contract so basically since the uh so on the transparent side this is kind of a diagram kind of depicting this uh basically we have the admin user calls the proxy contract uh the proxy contract doesn't need to forward any calls to the logic contract instead it just updates its internal storage slot for where the implementation contract is and it will just change it from logic one to logic two any subsequent user calls will be forwarded to the next logic contract so

that kind of basically solves your upgradability problems so if you needed to change your logic one contract for something else future calls will get forwarded to logic 2. uh so on the UPS side we have something similar but uh because all uh calls get forwarded the logic contract needs to decide if this is supposed to be a valid user calling the upgrade process uh then it uh will trigger a storage slot change in the proxy contract and then the next logic two will be what other users are interacting with when all the calls that they are making get ported to the implementation side so um I was like initially kind of super confused about

proxies when I first started uh understanding where the upgrade process actually really helps differentiate between the two so it helps you kind of determine which proxy you should use now it is worth mentioning that there is some gas overhead in the transparent side and that's because they need to account for the uh the logic changes uh or deciding whether the admin is available user or not to be calling the upgrade logic so yeah you UPS contracts are typically a little bit uh have a little bit less gas overhead and kind of zooming in to that for the transparent side we can see this is actually the gas overhead that I'm

talking about so it's quite like a bit of a complex logic in terms of whether a user is able to upgrade or not the key line really is just under the function call just checks that the message sender is the admin or not uh and yeah basically uh all other calls would just get forwarded to the fallback function if the user isn't the admin it's worth mentioning here that this call this logic this small gas overhead is actually called on every single interaction with a proxy so let's have a look at the UPS side and see how that compares

so it's much leaner this is only called when an upgrade is happening so it minimizes the gas usage uh yep and without any extra on UPS side of things we will talk about some best practices with implementation so when it comes to best practices proxy contracts might not seem complicated but it's because a lot of the logic's already been kind of abstracted away and it's easy that to like change a few things and kind of end up in a more complex situation again so we kind of recommend you basically to basically don't use upgrade logic if you

don't need it don't use complex unnecessary proxy patterns when they aren't required and don't create your own version of a proxy when you can use the eips that have already been built and tested so often proxy patterns are kind of neglected like a developer will build their Suite of smart contracts kind of implement proxy patterns without kind of maybe considering whether it's necessary or not but just because it's on Trend and yeah sometimes that can have some genuine security issues as a result yeah okay so then we need to talk about Constructors so

um Constructors kind of don't really work with proxies and the reason for this is because of how Constructors work Constructors although in in a bit of solidity code they do look a lot like a function they're not really a normal function at all they just run when you deploy the contract and then the code is basically just thrown away so the Constructor doesn't hang around as a callable function the way that all the other functions do which means that you can't write a Constructor in your logic contract and then call it with the from the proxy contract

and you also can't really do that sort of thing in the proxy very easily because of course all of your the stuff that you use Constructors for which is sort of starting configuration all that stuff tends to be kind of defined in the logic contracts all of your complicated variables and your mappings and structs and all this sort of stuff it's all over there in the logic contract and so not very accessible from the proxy so the solution that we have is this thing called an initializer function and then an initializer is just a normal function and that you write in the logic contract and it's designed to be called by the

proxy to do the job of a Constructor um it's they're often called initialize or have names like that they don't have to be called that sort of thing and but that's how that's how they work they're called during the proxies deployment usually um to do that initial configuration using all the advantages of being able to code it within the logic contract but it they create dangers and complications of their own one of the biggest issues with an initializer is that it's still sitting there on your logic contract and it's possible for somebody to attack you by just initializing your logic contract directly right no proxy

business just they just directly call the initializer and initialize it and you know often they can't do that much harm this way but you still don't want people poking around in your logic contract anyway it's it's not a good situation generally and there are some dangers like catastrophically they could potentially self-destructure a logic contract which is obviously not good so the main defense against this in solidity if you're using the open Zeppelin proxy libraries is this you call this function here this internal function disable initializers disable initializers um tells your logic contract that it's been maximally initialized and you might be thinking hold on didn't you just say

that we don't use Constructors here and now here's a Constructor that's true um but the reason why we're using construction here is we're actually not dealing with proxies this this is protecting the logic contract from being directly called itself and interacted with as a contract normally which is why this very limited Constructor that just shuts down the initializer is useful uh yeah so uh another thing worth mentioning is uh basically setting up and initializing in one transaction so uh in proxy deployment well in proxy deployment and maintenance usually we have one action which is the actual

deployment where we release the proxy into the real world and then the second action is initializing it uh like Richard mentioned uh so the thing is if this is handled in two separate transactions uh as some of you may be aware transactions can get reorganized or malicious users can insert their own transaction in the middle so this basically allows for someone to front run initialization by initializing your contract for you so not ideal to avoid this uh basically we recommend you just do deployment and initialization in one transaction sometimes there's complexities around

this where you may run out of gas doing both in one transaction then you need to think about how you're going to implement Access Control in order to split them across transactions to make sure a user can't just come in and front run one of your initialization transactions uh kind of talking about the risk of not doing this basically a malicious user could kind of take over your contract or potentially yeah mess around with the values that you would pass into the initialization right yeah and we also have one little Pitfall here which is that it's possible to use both transparent and a uups

pattern together probably by accident they're not actually mutually exclusive and they are actually sort of technically compatible they don't break each other um but it's probably not what was intended most likely it would happen because maybe you start with transparent and then without realizing sort of install a UPS logic contract or perhaps as misuse of a sort of automated installation tool somebody might accidentally set up both and they will seem to work well they will work the danger really is just because it's probably not done intentionally there's an a much higher risk of human error here maybe the transparent proxies admin gets forgotten

about um and maybe get sort of comes into the hands of somebody else in the future and doesn't an unwanted upgrade something like that yeah I'd like to just add a quick point on this um without mentioning who it was this uh was a quirky misconfiguration we found in the real world on one of our client engagements um so it's kind of easy to not consider what kind of framework you're using for proxy deployment and what the default values as to which proxy it's using so it's worth checking that depends on what program work you use uh so yeah basically another thing to mention is uh

as Richard kind of mentioned with delegate core logic uh your forwarding kind of control of a proxy contract to some other contract so uh basically this sensitive op code called delegate call is basically directly acting on the proxy contract so it can take over certain storage slots and it can even self-destruct the proxy contract so it's really important to only pass in a contract that has been vetted uh so code that you actually trust uh yeah and without uh further Ado I think that's uh if best practices uh any questions

just about actually let me just give you the microphone recorded yeah so thanks so much to the talk um just add one question the transparent versus UPS so I remember seeing on like the open zap plane library and the docs and they had this like official recommendation to switch over to UPS so I'm kind of curious what might have proximate to be like so opinionated um is it just a gas overhead is it just you know one less contract to worry about um like because you don't need to proxy admin for UPS or if there's any other reason yeah those are good those are good reasons I mean the fact that you've got a slight gas overhead on

every single call is a perfectly good reason to prefer it the other reason I've heard put us an advantage of eups is that you can shut down the um upgrade ability if you want to if you ever want to you can modify upgrade to a uups but you can sorry upgrade the uups contract to one that doesn't have upgrade ability at all but with a transparent proxy because the upgrade ability is baked into the proxy itself you can never remove the code you could try to make the admin unaccessible but you can't remove that code entirely and sort of lock it in Forever in a way that everybody can see is locked okay I think that makes sense thanks so

much okay all right we have time for one other question sorry who was it I didn't quite catch the name of your company of Sigma Prime Sigma Prime okay thank you okay that was an easy one okay I think we're no we got one okay uh thanks for the talk uh what are your thoughts about the diamond proxy standard I kind of see that a lot now so uh depending on these two proxies would

you recommend going for that I think there are advantages but happy to hear your thoughts um yeah that's a good question without kind of uh kind of adding any negative negativity towards some certain particular Dev decisions I do see that as an extremely complex pattern and not necessary if you don't need it for the most part it really solves being able to split contracts across different like basically circumventing size limitations and there's other ways we can do this so uh yeah I think unless absolutely necessary probably you could just stick to your UPS or transparent

okay all right okay one last question thank you what's the use case where one would use both transparent and ups at the same time that would be a mistake okay an easy mistake to do though yeah okay thank you very much okay thanks very much great let's thank the speakers Dimitri and Richard [Applause] all right all uh really important topics

so we have the last session but uh before before lunch and another really interesting one for uh all the people here so this is uh the road to becoming a web 3 security specialist by Iran honig from consensus diligence please welcome Iran [Applause] let me just get set up oops

interesting background awesome uh oh sure no I gotta stay here um thanks for the introduction yeah so uh I'm gonna be speaking a little bit about the road to becoming a web free security specialist um to give a little bit of background I myself started my journey uh on web 3 security by implementing mithril uh symbolic execution engine for the evm this is maybe a little bit of an unconventional way to start uh out doing

security things and it's also well does work it works really well it might not be the most efficient way so today I want to talk about like how you can design your own your own like pathway or road to becoming a security specialist what things you need to look out for and also kind of like what not to focus on like what's the important things and what's not the important things so kind of what I want you to do is not waste all of your time doing like only reading blog posts all the time and never actually trying to do anything related to security all right well that doesn't work

oh okay unfortunately the picture is not working let me see if I can fix that real quick okay nope fingers crossed now it's black okay okay awesome pictures yay

techniques Improvement for the talk okay so very simply put there's going to be two parts to this talk how do you get there and how do you stay there and it's interesting how kind of getting to be a security specialist is very similar to staying there like the types of things you focus on end up being the same in the end um although maybe the activities are slightly different in your approach as well okay so first how to get there um which makes chronological sense um I think that uh it's very easy to focus on the wrong things when you just get started I feel like personally like eighty percent of the information you

need to learn to become a security specialist it's just like the basics like how the solidity work um how does the evm work uh but there's a key thing here is not enough to just know like how to deploy a smart contract or or it's not enough to know like that op codes use gas and like did you kind of know how things work on a high level but not really When anybody asks you real questions like you got to know these little details about the evm that are very important and I think so there's a short quote on this slide here from Five Elements of Effective Thinking which is a very short book but I think

is very much worth reading and one of the things so this is a book written by some mathematicians that teach math in a university and they figured out like what are the patterns that students have that make them succeed at math and those things actually work like pretty generically for learning in general and so one of the things is that what sets the Specialists apart from the common crowd is a very deep understanding of like the material so in the book there's an example of a violin player being really really good and a

very simple piece of music even though in practicing this over and over even though it's very simple like they would get so much better at it and in doing so become a much better violinist and I think the same is true for defy security like if you have a in insanely thorough understanding of the evm or solidity this is it just gives you information at the time you need it to find bugs that others would have missed and I think to to give you like um oh no uh to give you like a kind of a benchmark for how deep I think you should go by with learning the basics is

I think you should know most of defy architecture better than the developers themselves um and this is kind of a very vague Benchmark because it's just impossible to Define anything um yeah and essentially what you're learning here is security agnostic so you're not necessarily thinking about security or learning about security when you learn these Basics like you can play around with Huff or build your own symbolic execution engine maybe build a fuzzer building tools is like an interesting way of getting to learn something deeply um you are not necessarily thinking about

how to exploit smart contracts using the evm but just building that knowledge and that knowledge on its own will pay its dividends later on all right so there are so many ways that you can go about like building the basics learning setting up your basic knowledge I think like there's tons of blog posts out there projects um there's so many road maps on on GitHub you know with all the links uh there's a couple of coupons out there um I think it's difficult to go wrong uh if anything don't stay reading the same kind of blog post too long like there's

also like a little bit of a rabbit hole like you gotta understand things deeply but if you focus only on learning the UVM and nothing else that's maybe also not a good user for your time and so I have a little spoiler here too so towards the end of the presentation um I said of kind of like this interesting thing of uh content curation essentially of different blog posts and road maps that you might be able to use on your journey uh but more on that later all right so I think the first part is building the foundation like foundational knowledge of just the environment the second part

and probably the part that sounds the most sexy and interesting is the attacker mindset um and this term is often used without any definition uh people just throw it around oh you gotta think like an attacker uh I don't know what's it even mean so to me the attacker mindset is a couple of things um on the one hand it's like these thinking patterns that are both innate and come from experience that allow you to just take an idea and mess with it so this is also something interesting and

why I put in lead web 2 hackers I have full confidence that a lead web 2 hacker that's built these mental models of how to play around with ideas in such a way that you can they can see the perspective that the developers don't have to actually see if there's something possible with the system that wasn't intentional um this is uh here's another book by mathematicians um called how to solve it way older I think is like early last century um

and this book also describes how or the difference between students and experienced mathematicians and it's it in in one of the early chapters it shows like a simple like puzzle really um where you had to connect like multiple dots like maybe you know the game where you have two red dots two green dots two blue dots and you got to connect them all without crossing the lines and this was an interesting example because um ex or the author explains how mathematicians have this because of their practice like in their toolbox their mathematicians attackers mindset

they have this kind of thing where um I think he called it the the like the concept of isomorphism like they instantly in their brain map the configuration of dots to a different like uh format where it's very easy to connect all the dots and I think a phenomenal phenomenon like this is exactly what the attacker mindset is is like the ability of your brain or your experience really to take something and play around with it look at it from different angles that allow you to find issues um that said I think there's more to it I think

[Music] um wait yeah that's going to be on the next lecture okay so I don't think um you can build a universal infallible attacker mindset like it's not perfect like um everybody is kind of unique in how they built their experience and this is kind of why everybody wants multiple actors to look at their project because they'll just find different things this also means you'll miss things inevitably this is just yeah a problem of Being Human I guess although AI is also miss almost everything for now also it takes a very

long time to really build these parts of your tool set like building a good attacker mindset uh will take you quite a Time okay so how do you even build this um I think so I was talking to a couple people the other day about security training like how do you get to become a very good auditor and one of the things that came out of this discussion or what we talked about is what's happening around code Arena so and Sherlock or this type of contest model and I think

and so the phenomenon phenomenon that we see happening that is so great for building your attacker mindset is the ability to have what's commonly called deliberate practice so you have the ability to try your hand at a real smart contract like you try your hand at auditing and and this is the important part you have a feedback loop I don't know what the timeline is two weeks to a couple months later where you can actually check back and see what you missed and I think this is the most important thing to do when you're like kind of starting out is this part like

you try your hand at it and then review what you missed and that kind of deliberate practice will allow you to build up like these these kind of expertise and it's important to to go over the issues that you missed and then see kind of why you missed them and kind of make a general pattern for yourself that allows you to find this bug in the future so I wrote down imitate and make your own like just looking at boundary reports or whatever something like this figuring out how the bug actually happened so maybe the oilerberg was like

a liquidation event with some some environmental situation uh that made it vulnerable so oh no um so you can look at this and think like hey liquidations are probably very difficult to implement and in this case there's like these environmental factors where you can instantly make a position liquidatable you can look at this veteran and think hey so what if I like go out and search for situations where you have positions that can be liquidated where I can create them and instantly make them degradable like this is a very

interesting and vulnerable pattern and orders definitely not the first to to make this mistake so yeah once you have this you have kind of this additional tool in your attacker mindset toolbox and you can continue and over time you also develop these General more generalized mental patterns okay how to stay there so what do you do when you actually achieve being a security specialist which is still a pretty vague term it's pretty much the same I think the thing that most like smart Auditors do is and not even to stay a smart auditor

just because they're interested it's like just keep exploring so once you're into solidity smart contracts you have like understand them pretty well now go and look at Cairo or something else and I think in all of this it's very important to keep going for that deep understanding so one of the topics for today um maybe one or two talks I'm not sure is kind of like using fussing and doing property based testing there's kind of a couple levels of depth that you can go here um you can first learn how the tool works like how do you set things up how do you do a fuzzing campaign all that

fun stuff and you can start finding bugs but I feel like this is still like a sphere or fairly superficial type of understanding and I would recommend you to like play around with the tool itself and actually try to figure out how it's doing the fuzzing because once you get to a point where you actually understand how the different fuzzers work how Foundry Works how the Echidna fuzzer works you actually achieve something that's going to help you also you use the tools better because all these tools have flaws like there's just certain things that are very difficult for fuzzers to do and there's certain ways of going about writing properties that make a lot of sense if you know how

things work um and this type of understanding is just not available to you if you just do the basic tutorial and use it although over time of course like you'll build a better understanding as you use it but I would just go deep down the rabbit hole I enjoy the rabbit hole and then continue so to build the attacker mindset I think it's important to kind of build this feed of information and I think there's kind of two prongs to this so um or this is at least what I I look at um on the one hand there is the

like stream of bug Bounty reports and postmortems and I think these are probably some of the most interesting because these are the bugs that other Auditors and developers missed um and so it's important for you to also know about them so that you don't miss them next time um it's also usually a stream of like critical bugs uh that are super interesting uh and worth checking out but I think it's also worth not sticking to just this uh the cool hacks like whoa 10 million 100 million got hacked I want to know how it works

um I think it's also pretty much worth checking out audit reports from like or reports from code Arena cool and um added reports from some of the top auditing firms like just scroll through them and see if there's any type of bug that you haven't looked for before that you think you might have missed I think like a quick skim of a couple of other reports every week or every month and then just taking a few and Diving a little bit deeper on those issues definitely worth your time and it's important to also do these because there's always new things in security

and these are going to be kind of the bugs that Auditors are looking for right now so if you don't know about these you'll be one of the Auditors that lets us get into production into the first class of bugs um so yeah I would definitely do both and then the other thing is practice so um yeah brains are very slow to optimize although if you practice use a particular type of thinking a whole bunch it starts to optimize really well so the more time you spend hacking and thinking and playing around with ideas and systems looking at them from

different perspectives the easier this will become for you and I guess the faster and the more bugs you'll find okay so how does this learning and approach reflect in practice I feel like auditing in a way or finding bugs is all about just asking questions so here I hope it's readable I think it is uh is a sequence of questions um in a situation that kind of highlights which parts are this foundational knowledge and this and which parts are the attacker mindset so um

this is Loosely based on the URL hack not really like a couple details don't match up but it's just to highlight this this idea okay so the first part is like asking the right question so this is that attacker mindset like knowing which questions to ask um so in this case um it's like you know to ask for like to see if there's a situation where an attacker might be able to turn a profit doing a liquidation and so the answer to the question is also important and in this case you'll have to look at the code um

so again so in this case I'm assuming yes that's possible second question it's very important to make the profit instantly if you can make a profit and it takes you months it's not very interesting from a security perspective so this is also kind of the attacker mindset then another code understanding answer um and eventually you have this question of okay um I got to send these two transactions and um is it possible that someone might mess with my attack so this is like also the attacker mindset like is someone gonna hack you will you try to hack this

thing um and the answer is going to be yes potentially here and that's part of that foundational knowledge like knowing what guarantees you have when you submit a transaction um through through the mempool or even like what are the conditions that you have when you submit it through flashbots because flashbots has a lot of edge cases and interesting pieces as well where you might think oh I just submitted and nobody knows about my transaction nobody can sandwich it or whatever this isn't always the case it's not that simple like and that's why it's very important to have that foundational knowledge um

yep all right so I'll make the short pants and Quest so one thing I did is like there's a lot of content out there it can be a lot so uh I thought it would be cool to do this thing called which I called passing quests it's Loosely derived from other things as well um it's kind of these bite-sized Adventures based on curated content from all over like content from people in this room right now as well um you do some research like a bit of learning couple blog posts and then there's objectives with um what I call like real goals so they first class has you going out to D5 protocol figuring out how other

protocols might integrate with it and then you figure out what all the edge cases are that other protocols might need to look into and this and then you can write a blog post about this that will be pretty cool and useful this is a very cool like objective I feel like is it something that Auditors do pretty much every day paths are like a more curated set of quests so like you want to do ZK auditing and there's a couple quests in that way here's a QR code um I hope it works I put the first one live um let me know what you think I hope you like it [Applause]

great advice from Iran so we have time for a few questions to everybody agrees nice all right I um what about using AI to discover pattern for for learning uh I mean AI is pretty good at learning pattern you know to find attacks or exploits so I tried a couple of things to like I like giving treasuryptity an

audit report or a bug report and then and I said yo can you distill like the essence of this bug and it's very bad at this like it always it's it always either loses details and then writes something that's not related to the bug in the report or it keeps too many details like for example it's specif like starts talking about very specific components of the system and how they work together and then it gives recommendations for how those components shouldn't work together um but in such a way that it's really not that useful for you to as a generic description of that type of vulnerability so I don't know maybe my problems

engineering game isn't good enough but I feel like this part are like distilling information doesn't work that well yet GPT something more emulations in it's like a tool for nope I found that some time ago but I didn't use it much but basically they are agent so you simulate your protocol and they are agents like AI agent you know that try to interact protocol and it's a little bit like you can build I suppose it's possible to uh in the same way you know we we teach

uh AI to play uh go or chess you know we can teach AI to it's a goal of the system to do security checks or to do economic modeling I think it's used for economic modeling and testing protocols yeah it can be used for whatever for so I think agent-based simulations very useful um I think there's a quote I forgot who's from like all models of wrong but some are still useful um so this is for for economic modeling you can add like figure out like parameters uh do parameter tuning kind of make predictions about how people

would will interact with it um from a security perspective in terms of simulation and I I think fuzzing is more of what you're looking for who's agent-based simulations are about seeing what median or like what the performance is under normal load and security is about what but what if it's not normal what if someone does something you don't expect and fuzzers are like better geared towards figuring out like what things the code does not expect and kind of triggering those those weird behaviors although there's some interesting applications in like crypto Economic Security and figuring out the stability of economic systems where

agent-based simulations are definitely very powerful and useful excellent so let's uh thank the speaker Iran for all the excellent advice and feel free to reach out to him he's going to be around uh hopefully the later part of the afternoon as well so with that we come to the end of the first session so hopefully all of you have survived the next part is lunch which is downstairs there is a food room which you would have seen during the coffee break so there's a lot of space there's also the adjacent Garden outside area so please feel free to go have lunch that's critical part of d5101 as well and we

will see you back at 1 40 so it's it's roughly an hour's break and please be back we have a fantastic session starting with uh tincho from the red Guild who's going to talk about getting started in smart contact security so see you later [Applause] [Music]

thank you [Music] thank you [Music] [Music]

[Music] foreign [Music] [Music] [Music] thank you foreign

[Music] [Music] [Music] foreign [Music]

[Music] [Music] foreign [Music] [Music]

foreign [Music] thank you

[Music] thank you [Music] foreign [Music]

foreign foreign [Music] foreign [Music] [Music]

[Music] foreign [Music] [Music] [Music]

foreign foreign

[Music] [Music] foreign [Music]

[Music] [Music] foreign [Music] [Music] foreign

[Music] [Music] [Music] [Music]

thank you foreign [Music] [Music] [Music]

[Music] [Music] foreign [Music]

[Music] [Music] thank you [Music] [Music]

foreign [Music] foreign [Music] thank you

[Music] thank you

[Music] foreign [Music]

[Music] foreign [Music] [Music] [Music] [Music]

[Music] [Music] [Music] foreign [Music] [Music] [Music]

[Music] [Music] thank you [Music] [Music]

foreign [Music] [Music] [Music] foreign [Music]

[Music] [Music] thank you [Music] foreign [Music]

foreign [Music] [Music] foreign

[Music] [Music] foreign [Music] [Music] [Music]

[Music] [Music] [Music] foreign [Music] [Music]

[Music] [Music] [Music] foreign [Music] foreign [Music] [Music]

[Music] [Music] foreign [Music] [Music]

foreign [Music] foreign

[Music] thank you

[Music] foreign [Music] foreign

[Music] [Music] thank you [Music]

foreign [Music] [Music] [Music] thank you [Music]

[Music] foreign [Music] [Music] [Music]

[Music] [Music] foreign foreign [Music]

foreign [Music] [Music] thank you foreign

[Music] [Music] [Music] [Music]

thank you [Music] thank you [Music]

[Music] foreign thank you

[Music] [Music] foreign

[Music] [Music] all right [Music] foreign

[Music] [Music] thank you foreign

[Music] [Music] [Music] thank you

[Music] [Music] thank you

foreign [Music] [Music] foreign

[Music] foreign

[Music] foreign [Music]

thank you [Music] [Music] foreign [Music]

[Music] foreign [Music] [Music] [Music]

thank you [Music] foreign [Music]

[Music] foreign foreign

should start again in a few minutes thank you foreign

[Music] [Music] [Music]

[Music] foreign [Music] [Music] thank you [Music] foreign

[Music] [Music] foreign [Music] thank you

[Music] all right [Music]

foreign [Music] [Music] [Music] thank you great good afternoon

so hopefully everyone had a good lunch and uh we'll make sure you won't fall asleep because we have a fantastic session planned for this afternoon starting with the dincho from the red Guild who's going to be talking about getting started in smart contract security so please give tin show a very big hand [Applause] thank you let's see okay

cool nope perfect so nice to be here hi everyone um I'm tincho I'm a security researcher um I've been working here in this place for quite some years already I used to be a smart contract auditor I also created the mulnerable if I perhaps some of you played it um if you haven't please play it and now I'm working on the red Guild which is a collective of security researchers and it's emerging um that we are trying to create public goods for the security community and we do application security research and educational advocacy so this part is

like educating and sharing what we know right um the talk is it says how to get started in smart contract security I will derail a lot and please bear with me um I didn't want the the title of the talk to limit me too much but hopefully you will get some ideas on how to get started and Jonah was talking earlier in the previous talk and he probably gave some more specific advice on how to get started I wanted to compliment his talk in in another way try to share more about values and purpose and and why I think this is this is important and hopefully this advice will help you get started and are also getting started but keep going okay it's not only

important for you to be here today learning about all of this cool stuff but I so wish that next year you will also be here as well you will be there or you will be speaking here right we really want you to contribute to the space and we want you to to be part of it right so John if you're in the security Community we are trying to make things uh better and we really need you this talk is about that get started but please also please keep going on it um my secret sauce for keep going is with purpose okay um this a real thing to contribute here in web free security I really think that the technology can have an impact in the

world I might be too optimistic about it I don't care um but I really think that this is the main thing that has uh kept me in the space through all of these years and hopefully I can share some of that with you okay so this a real sense of belongingness a real sense that you can help shape the industry um that you can have purpose in working in web 3 security and you can keep going at it right so you can keep contributing with three security is quite different some of you that I've been talking to you already at lunch um you come from web 2 security perhaps and you will find out that if you want to get started well you will find that there are many different things in web 3 security of course there are similar

things but in word free security there might be other things that are not quite similar okay shot for example I personally really believe in the technology and that's for me why I really joined the space to try to protect that right you will find a lot of these the systems that you that you're about to start reviewing the channel to start learning from our public are open source that's not as common in in other parts of the industry right you can get really deep into many parts of the system because lots of it is public lots of is open source you the the code is there for you to explore right and anybody anybody can join right it's you from home that you can actually

see these systems deployed you can see smart contracts on the blockchain for example nobody who you are nobody where you come from no why no like you don't care about your actual background anybody can actually come and contribute and try to make this ecosystem more secure right and there is a double-edged sword because if anybody can join the good people can join and the bad publication right so there are lots of people with um not that many good intentions in the ecosystem um right so anybody can join that's good but that also means that lots of factors are getting into a scene and of course there's billions of tbls at risk all

right and you can actually look at the blockchain and see how much money is stored in there this is very uncommon in other places you in other parts of I know website security you might not know exactly how much money you are actually protecting and investor security you might realize that well it's quite clear how much value you are protecting right if you only want to speak out value in financial terms it's a good purpose is fine whatever by why should you care right um we all come from different backgrounds we will have like different histories I personally I come from Latin America and I think that the technology has a way to

propose a different approach to things to create more fair social coordination mechanisms uh to create more transparent mechanisms to give access to financial um systems that in the traditional World many people don't have access to I've seen cases where crypto is really a saving line for many families for many friends and I really believe that I wanted to protect that technology okay hopefully this talk also gets you started in in the same line right not only care about like the stars and the followers and engagements and whatever but there's really something meaningful that you can contribute back um

and hopefully in the next year you will be here and you will continue contributing to this ecosystem in such a way purposes obviously not enough okay so that's why many people are tackling this problem of physical security line with free security in general from many places there are many actors who are involved all of these are ways in which people are organizing themselves to contribute you have people working alone you have consulting firms whatever like such as a traditional auditing shops you have people doing crowdsource security you have doubts you have um hacker collectives you have internal security teams you have Educators you

have Advocates there's lots of people really contributing to ecosystem in really meaningful ways right you can be one of those you can really participate in one of these um organizations or even create your own whatever but we really want you to to be with us all of these organizations have created a lot of these resources that we see today right in the early days if you were part of the ecosystem you may have realized that we didn't have many things well today we do have lots of learning resources that you will find online and in crypto Twitter everybody's sharing uh challenges and spoke debug stuff and newsletter and conferences like today roadmaps there are a lot of resources that you can learn from okay is

everything out there and you can actually learn from that and also contribute back a lot of it uh everything is cool everything is fine but there is something going on right so a lot of these these resources seems like they work to some extent but why is it that hacks keep happening right there's something missing that we need to continue working in all of this right so we haven't won yet we want we will never win but we really need you to continue with us right so you can have an impact you can contribute lots of that stuff um and I want you to have that mindset when you are getting started right you shouldn't be just a passive consumer of all these things and all all of the

information that these actors are providing to ecosystem you can really raise your voice and lift your hand and contribute something meaningful knowing always that we won't secure it all okay now we know is that we can miss vulnerabilities hacks we continue happening but if you at least know that we can make the application layer for example uh a little bit more resilient so that even if hacks keep happening we can actually recover from vulnerabilities we can actually um have these applications not always be like hacked in this application not always be damaging the legitimacy of the space right I don't I really don't want the

next D5 hack to be heard in the whole legitimacy of the web 3 space right so we as a as a community need to continue working on making all these processes far more resilient so that we can always grow Stronger by everything that happens um it's not only smart contracts right so what is actually the application layer money this I know this is a 101 so many of you might not be familiar with what do I mean by the application layer well it's these things like sitting on top of the base like right sitting on top for instance on top of the ethereum blockchain if you want to dive deeper into it you might say that and well there's this front-end stuff and then you have the smart contracts and you might consider that the application layer

um so in this case would be anything sitting on top of the ethereum virtual machine and the blockchain and the consensus mechanism and that kind of things to some extent I would agree but that would be kind of oversimplifying it because I think the application layer is growing more and more and more complex um not only you will be seeing smart contract stuff right so it's not only about like securing a single smart contract or paying attention to one line of solid article yeah that's fine but there's all of these components surrounding smart contract these days that are actually really really important as well uh I could just name provide a second name indexers Oracle soft change services signers like many components around the smart contracts

and it's also keeping in mind that what you do on a smart contract is fine but yeah there's lots of things in which you can actually contribute to the whole application layer right application layer actually looks like this these days um it's not too much like this but actually looks like so you have like these little components here on top of each other and stable many of them vulnerable if one gets attacked then many are hurt as well um so it does feel far more fragile than the base layer right um so that's that's the thing that I think that we need to solve somehow um in particular with smart contracts for you for those of you that are not

that familiar with what does it mean for a smart contractor we will know well you will see that there are attackers actually not going through the whole flow of the application layer but sometimes they can actually just exploit directly and the smart contract code that is deployed on the blockchain that you can do that as an attacker with one or more transactions right sorry about that um what I wanted to just to mention a few keywords for you to take home on on what you will be dealing with when we are discussing smart contract security for example so in this case you will be dealing with denial of service Theta funds price manipulations integration issues business logic Fields step corruption so there's lots of things to learn from right and you won't be

learning everything in this Summit you really need to do your homework you really need to start step by step as Jonah said in the in the last talk um really getting deep into many of this kind of attacks or vulnerabilities of threats that we have in the ecosystem and little by little you will be gaining experience and you will become more familiar with a all of the things that you as a security researcher perhaps need to be aware of okay and this is what you will look like in Namaz more or less um perhaps another month but on day one you will be looking at goals in day 35 you will be far crazy um it's weird that this thing of actually looking at goals on a screen

has become so popular these days it's rather I don't know how but it has somehow is fancy to be looking at color and trying to find vulnerabilities which is cool kind of nerdy but it's cool um but please don't go too crazy on it right so stay healthy um yes you will have older energy all the momentum after their Summit but take it slowly have patience there's lots of things to to start with lots of things to learn from um so take care okay we really want you to be here with us next year um so yeah go slowly please if you don't like smart contracts you can do many other things okay so yes you can get started with smart contract

security and that would be awesome but if you want to keep going there are other things with that you can do um and Jonah in the last talk also mentions similar things at some point you might get bored our smart contract security and you want to do something else does that mean that you need to leave the ecosystem and not do anything else no I don't think so okay many of us that have some experience um of little by little been looking at other things beyond smart contracts so I why am I telling you this because you will get started but if you want to continue working in the ecosystem just know that there are many open opportunities for you okay it's not only about solidity stuff there are many

things in one ways in which you can contribute just a very limited list of things that you can do and I won't mention them all but we are maturing as a community as a security community in web 3 and I believe that if you don't do a smart contact security you can check out many of the things and throughout the summit you will see many many talks related to security and with free security that are not strictly related to Smart contract security okay so you will see many experts and know about Olympic things and you can reach out to them and you can talk to them and you can actually push them to share their experience with you okay so use this Summit also for that take advantage

of this guiding that we are having in the next few days I think it's quite important to to also open your minds knowing that you are contributing to a little thing and there are many other Professionals in the space also working to secure stuff that perhaps it's not just smart contracts right many of the I don't know bounties that you see and contests that you see on Twitter and what's hitting the headline the headlines it's just about vaccine smart contracts but know that there are many professionals that you might not know of but that you should respect but because they are actually contributing to many of these things behind the scenes okay so please reach out to them say thanks and uh and get in touch and try to learn a lot from them as much as you can

probably just wrapping up I think these are really offered on the table and that you have here on the summit and as you get started these small contract security as I said at the beginning you might just focus on the on the followers that you have on the legs that your latest posts got in Twitter you might just focus on where you make it to the to the top of the leaderboard and that is run by money that you want or whatever you can take that offer if you want to everybody has their own history some background and interests and that's totally respectable I think that's another offer on the table and that you can also take which is like meaningfully contribute to ecosystem

knowing that they are professionals working at this that we really care for the technology and the possibilities that are converting to the world and you can also contribute in that way and hopefully that that's the offer on the table that you take and that's what keeps you going that purpose is what's what is keeping you going throughout the days and throughout the years while you contribute to two or three security you can actually help save the industry we're in a nation industry um we haven't had the final word on it I think lots of people in this room will have different opinions and and we try to do things in many different ways and that's super valuable as long as we are

really meaningfully contributing back to the ecosystem trying to make lasting contributions that we can all learn from that we can assure that will last for many years not forever but for many years and we can actually all together hopefully in this room make a space a little bit safer that's the offer on the table I want you to really contribute back I want you to not only be a passive consumer everything that you see or Empower yourself to know that with what you're learning this Summit you can take all of that digest that and create your own things and meaningfully contribute back with things that are lasting for the ecosystem I think that's the way to get started in smart contract security I didn't want to share about road maps or specific links

or whatever you will find lots of lots about that and indeed hovering Twitter and whatever um I just wanted to share um a more broader perspective on why I think that you should get a start in smart contract security and get going at it I'm tincho I work at direct deal thank you very much [Applause] thank you tinko now we have a couple of minutes for questions and answers you can make comments feedback say that I'm wrong you can also reach out to me like later

and yes yes please yes sure so um team of yeah I would say a security Collective we are three people right now we don't mainly application security research which means essentially backhanding for example so we go after projects that we think matter in in this case for ethereum ecosystem that really are a language ethereum's vision and that contribute meaningfully to to ethereum's long-term game so we try to protect those by doing back hunting and what we learned from that we know we

don't keep it to ourselves we try to share all of that with the community um with educational articles with videos and participating in events with workshops creating them will now edify and contributing challenges to that so that's our way to contributing back to ecosystem right I think that many in the lots of people in like there's lots of people with that are very technical and highly skilled in ecosystem but as a community we are missing this bridge with the with the beginners or with the with the real users another guild we try to produce uh valuable educational content that can be seen as a public good so hopefully one day the security research work that we do can be seen as

a public good contribution to ecosystem right now we are funded by ethereum Foundation but hopefully in the future many years in the space we'll see value in what we do and can also fund us he's my partnering crime other questions comments okay cool people thank you very much for listening see you later [Applause] such an inspirational talk thank you so much for your perspectives tin show thank you all right so we have a few more minutes

but uh I guess the next speaker is ready so uh please welcome Anton from chain security he's going to be talking about uh well a deep dive into defy invariance examples and challenges so please give Anton a warm welcome uh so we can you connect me it's just password sir I can I mean I don't want to I mean

foreign [Music] okay and it's in the wrong slide one

second uh right uh hello my name is Anton I'm from chain security uh yes we are started in 2017 and keep going as a like and yeah we are quite long in the game so to say and the team rotation is surprisingly low so we are almost all the same people keep doing Audits and securing the easy room I mean we are I think it is still somewhere fifth place on the yeah

ethereum Foundation back Bounty leaderboard and yeah we are trying to secure whoever comes to us for advice and also of trying to find bugs in our like say free time you know maybe some people know about read-only re-entrances this was kind of discovered by one engineer of ours and yes uh I mean the previous speaker told like it's really hard to navigate this field in terms right and here I want you to tell about this kind of mental model like we are sort of where initially a spin-off of eth tour University it's name is finally

looking but it means like something like Federal University of Switzerland but basically one of the things that I believe like developers and Auditors no matter what you do I mean I think anybody who is more or less involved is called gun profit a lot is this kind of mental models how to deal with complexity how to deal with a codes that is hard to reason about and one of them is like invariance so I mean in nutshell like what you see is like a definition of invariant it's just some property of a uh you know case program but it's a smart contract that is always true right so one of the such

kind of really intuitive properties that you might maybe see first time is that maybe total supply of your C20 token if you have experience with your C20 tokens is equal to some of balances right this kind of makes sense to do because you don't want to have like tokens imbalances but not accounted in total Supply right so here I want to use a bit more complex example like it's compound compound V2 I think actually it's I would say not so popular nowadays I really don't know how they're doing but uh like we started long ago and when honestly we started in 2017 uh most of the audience most of the

contracts we reviewed this was like here c20s this was big complexity in most places and then like with style like when people sort uh sort about this composibility of tokens they started to think how we can create systems as utilize this underlying simple Primitives like here C20 tokens what we can do with them and yes exactly compound is a thing that you can do with uh primitive here C20 tokens it's basically landing and borrowing platform so you have here uh die this is like a stable coin I'm going to use this as an

example of that's kind of a token that compound will be using and then C die is basically a token that compounds creates internally when you want to when you are landing the die to compound right I'm gonna show later why they're doing so like but so to say you can say that dye is some external token and C die is a token native to compound itself and of course like there's going to be either it's a native token uh yeah you're as well gonna see why we use it okay now like once we saw like these three basic blocks let's first go into the first part of our like compounds dive in right

and I'm going to just display in a system and then like after I explain my first steps I'm gonna try to show you how you can kind of abstract the complexity out of this complex quite a complex Behavior with quite small and simple formulas that's easy to understand okay first it's in compound I told you it's Landing and boring platform what is landing Landing it's uh you can say a process right when a party some lender it could be you with your Ledger wallet or metamask or whatever you're using you have some Diet tokens lying around and you basically want to give them give them to give the get the yields right I

mean if you know the to this this is exactly why people are lending they either pull putting it into some liquidity pools or something to make the kind of capital work right and like if you see it's usually if you put them inside so this is you're going to call like Supply this kind of Step if you're supplying tokens in exchange you're getting C die right this is like a virtual talking so to say that represents your like position inside this compound system right and after a while time goes and you actually want to get your gains from the compound right USA yes I'm done with the farming

compound like I won't actually need dye because die you can use for many other things like uh withdrawing from exchanges centralized ones and actually like combined Pizza sort of soil not and this time how compound works why you actually incentivize to give your tokens to compound is because you'll get more right you see here you get like 105 tokens and not the initial uh hungry that you have to put like so this time uh like when you'll be withdrawing this is processor the code you will get more and this is I would say one of the simplest invariants that you can kind of

check when you are doing audits or as a developer when you're writing a code right and like a bit more complex example but in the same nature of invariant is that price of diet to see Diamond this time should be monotonically increasing right so there should not be moments like when CDI is not like let's say I put a hunger die and I give I Got Back 40 CDI there should not be if it's draw over I'm actually getting less a die right I mean is this is compound invariant it's not doesn't hold for all kind of protocols

you're going to deal with I mean even for example I know certain who works his hour in their case there is some potential like rebasing that actually permits this balance to go down but in general as a general rule like this shouldn't happen in most landing borrowing platforms and this like exchange rate of uh you can say diet or C die like or any other token to like internal share that represents the stock and should always go up yes now we're gonna go on other side of this compound is borrowing borrowers are exactly the parties who want to get like the color truth the tokens that you have deposited

and they are expected to return more for like ability to use uh to use your tokens right in this case we basically cannot use die again like to get to borrow from compound we need to use another type of collateral in this case we're going to choose like a native easer right and as example here borrower can supply collateral is either as I told and get back he can get a die like a token that I told you that's more usable than maybe for his needs the easier right and his either is not burnt it's not he didn't lose his either when he deposited the

borrower he actually later can uh repay and repay with some extra fee right extra percent on top and get his collateral back right so this is like a replay uh in this case uh you can see like we are returning a bit more die right and this basically just to spoiler you like and people who know this it's like quite obvious profits of lenders I come from borrowers right this is uh like system itself doesn't print new diet right it's only can kind of redistribute what lenders uh of what

borrowers kind of have to put on top right and invariant for this is quite simple as well it's a repaid amount it should be more than borrowed amount right that you want to assume you want to borrowers to pay for ability to use your your die right other type of collateral that lenders had put into the system uh yeah and uh like if you just paraphrase this what we wrote here like this is actually the same exact equation uh but we just are adding extra components there because uh there exists actually certain term like prices right you don't want to give hundred either if

collateral if either only costs uh 50 die in if you use some other exchange right it will be really bad deal for a compound as a protocol right you don't want to kind of distribute assets without uh like proper backing so that's you want to be sure that borrower at least puts enough funds for like incentive to repay right and the result like uh the previous repayment was a borrower amount basically results that uh like collateral uh multipliable price would be more than you're boring right this is like invariant for like repayment and actually like uh yeah I touched the

business so I could repay you should be incentivized to repay and exactly uh what happens if let's say we have at this moment uh I don't know this I can I have not introduced full variables so people who know maybe says it's not a possible situation like like die is usually one-to-one with a US dollar right and for let's say one either I can get hungry die right that is limit of a situation and exactly if price becomes for whatever reason 50 right it's much less than actually uh actually the amount of dye currently borrower owns borrower has no incentivized to repay so he will be actually not repaying right and this is

um like not good for protocol right because as we supper previously we want lenders to be sure that they are money are working they are like accumulating fees and so on and we don't want them to be like uh not happy and lose their tokens right that's why basically there exists another party called Liquidators and Liquidators are like a party that can repay adapt uh at like assuming like prices they are like developing um developing with some uh like let's go it's a function over time right uh you at some moment know that like the

borrower doesn't have enough uh like enough collateral to repay the depth right and this moment like in compound something starts something some process starts that is called like uh liquidation auction and it allows Liquidators to like basically liquidate the borrowers position by repaying die you see like he needs to return what borrower has borrowed at some like smaller price and as a return he gets a collateral collaterals that potentially can worse more right and like invariant that you want to

establish in this case is like to make sure that Liquidator is uh has all the incentive to uh like liquidate position is that basically uh the like like a contribute formula it's quite big collateral amount multiplied by price of collateral uh multiply like coloraturization ratio I'm gonna tell us a bit later it's more than borrowed the mountains price so in our case collateralization ratio it's the factor that resulted in borrowers amount here not to be hungry but to be 80. uh why it's 80 is because you exactly want to have a save Gap save Gap like in time in which Liquidator can

come and liquidate your position and for that exact reason for Hungry USD tokens you're not getting hungry this examples that we had before they're technically like no protocol works like that I think characterization ratio of one is a thing but it's quite a rare thing in most cases you will get something like 0.8 in this case which basically means that borrower cannot fully utilize uh value of his collateral he can only do it partially but as a result protocol gets sort of like a guarantee you can say that if price of collateral drops below the kind of collateralization ratio time

price of collateral times the amount of collateral then basically third parties like Liquidators can come and replace the depth they are really motivated to do so because they actually you can see getting like either is 99 right but wait I think I have a type of there because you could they should only repay 80 die and not 99 yeah sorry about that because you're not paying full price you can actually like pay only what the borrower owes yes and like prices can be different there is on chain off chain but more or less it's always like some function over time and this is great security uh

considerations needs to be put into what exact price each protocol needs to put but more or less like you can say the heuristics is such that you want to be able for Liquidators to be fast enough to liquidate the positions what if they don't liquidate there's like bad adapt as a term exists that exactly if like for example borrower has borrowed 99 die but Liquidator repaint only 9 die right this nine die will be considered as like a bad debt it's basically protocols users really have like a special pools to protect from Bad

depths like they are basically funneling parts of their like protocol fees into the special pool that in case if they like accumulate that depth they can repay certain risks right but in general they never want to have any bad debts on any of their borrowing or lending positions right and there is a huge effort put into like analyzing what exact culturalization ratios needs to be in each system if it's more not Security in like the devices but it's still Security in devices but it's more like economic parameters and not like software codes that can be broken right

okay and yes uh for like this desired invariants that you would like to hold is that culturalized amount multiplied by price of collateral price in this case you can say it's like indoors right and multiplied by cauterization ratio should be borrowed amount and price this is the old formula that you saw and basically what it like really means is that uh like intuition behind it it's it's kind of one of the things hard to get is you all see this formulas and uh with time intuition starts to build up and here intuition is that basically what borrower puts in should be less valuable

than what he gets out right and yeah this is I think uh enough for boring we can now go for connecting both pieces of the puzzle together it's landing and borrowing so there's lenders who come and who die there is borrowers who come and um like get die and put another a set as a collateral and later there we pay and their repayments go and basically result in profits of lenders right and yeah this invariant if you like sum up stuff on the left side on the right side

on the left side it should be equal right because the inflow of a system assumes there is no like protocol fees it should be like Net Zero and it is like borrowed Supply Plus board repaid borrows uh should be equal to uh provided Supply Plus collected fees right so this is what I told to you working the very beginning that's value doesn't appear from nowhere right compound doesn't mean either compound doesn't mean die and it's like basically a borrow where some people put their assets some people take it but Barrel is full only because some people put it there and Barrel is not empty because

people have not taken everything out right so this is how you can have like an intuition behind like what this formula means right um okay why you need to know about all this invariants and uh like what do they actually have to do with like writing code or like auditing code or many things and this is exactly that you need to utilize these things for first testing second like even if you just writing code or looking at code you need to consider the things for each function it and it's honestly it's up a lot of a process like instead of looking like okay what's can happen with the system which is

basically formalize this invariant and just you go function by function and check like does this function [Music] break invariant or it's actually a good and maintains it right and in this case in many cases like invariants are like something that you can test only if you do the top of the pyramid it's like if you do like system-wide test in rare cases like you can do like invariant testing for and test like even unit testing I think there was a much of good talks like you know by Trello bits who told like about this test and that you

need to go for not only 400 statement coverage but also to go for like meaningful tests that tests and one thing of you can do meaningful is testing variance of your system um yes there's also a bunch of other more fancy ways than like regular tests to test the invariance one of the ways is what I'm personally like fun of is like property-based testing yeah I showed some examples how that of libraries and like Builder tools that can help you with the like writing such tests I mean python is brownie Foundry is like where you can write test

directly in solidity uh truffle it's a bit harder there's like only fast check exist so far as I know but nevertheless like property best tests are really good I'm gonna tell you later what exactly as it is but stateful testing is another variant of property-based testing but where you like maintain a state and form a verification and monitoring is kind of uh super Advanced kind of testing technique but it gives you the most guarantees and if you want to go the Last Mile and basically be sure that you're safe it's maybe like exactly what as a protocol

developer you want to do monitoring is like more if something bad happens you have a way to basically pull the like stop and like prevent system from being like abused but it's not most likely the way you want to deal with the kind of problems in your system because this is like a lost Resort kind of system uh okay and regarding property based testing I kind of mentioned it but actually I should have reordered slides uh that's basically if you consider a unit test for like something like a deposit function usually you just run one value through it and you just see if it's like passes or fails maybe you have

after deposit you're actually doing some query sense like us asking smart contract if the state is okay right if like if I want to deposit I want to see that something total collateral in the system has increased right and this is basically your properties that you're testing property based testing is pretty much the same but uh you are for like bombard charging your uh like Union test with many many random inputs right and you're still checking all the same properties but just not on one input but on many many different inputs it's still like a good uh I think it's not from Turtle it's not like to limit basically

if you're using really big integer values or really small integer wherever there is this basically Corner cases that you want to capture but in the in the in general this is like really good uh testing technique and yields in my life experience a lot of results surprisingly with little time invested sort of especially like for us Audis are 10 bounded and it's always trade-off between like testing the clients code and like looking at code ourselves yep I think I'm done with them on time uh yeah I guess questions if anybody has there's a question

thank you for the talk I was wondering about the property based testing how do you choose do Corpus that is used for injecting uh sorry what do you choose the Corpus like in on the next slide you have like 110 and I was wondering about the Corpus and also the seeds that generate maybe yes okay um so this is like a really depends on Library um I mean you can for example tell you about black brownie that's basically uh you're writing testing like in Python and there is a like well established library in Python code like hypothesis that basically uh allows you to annotate certain input argument of your

test as uh parameterize test with a certain strategy a strategy you can specify minimum value maximum where you sit that's exactly like where it can be specified and then this test will be basically run multiple times and it will be every time like a random value from this parameters of your strategy picked yeah I mean I guess it really depends on like libraries right I don't know what's Foundry honestly doing there I can only like speak about brownies just because I looked really into internals but more or less I think there is a standard this is the way of how things you are doing is the same like you basically have a

special way to write the in like a testing library that certain tests needs to be uh needs to receive random inputs you know I don't know if it's answers yes I was wondering about how to optimize actually the good choice of Corporations oh this is like really really good question okay good uh so like in my experience it's um like you know for a given function that this function somehow mutates the state right and this uh like mutations of States they are usually and you can end up in a bunch of new other states but for example if you have uh let's say

in our case whatever like deposit function you can have deposits that would say makes your characterization ratio healthy again right or it makes your cultural Insurance here unhealthy like if you maybe like withdrawing right so you basically in my experience it's best to look a given function and see what can be possible results right and then maybe even if I can Target the values such a way that you say okay please I want to deposit exactly enough assets with some random parameterization around it so my characterization ratio becomes

one right something like that and then you kind of sort of uh you can say trying to fuzz around edge cases right you you most likely from like system you know like edge cases let's say like even transfer functions like you know maybe critical Parts is like when you're trying to transfer more assets than somebody like the somebody has right or you're trying to Mint really really big value right this is where usually problems can happen right and yeah it's really like protocol specific yeah you can uh like say for my students will have like really one hard property we had to fast and they're like exactly was I

could say uh uni swap will be free kind of system where you could uh when you're swapping you can swap and cross the tick or you can swap and like not cross the tick right and then you were exactly trying to uh give all this values as a pool of arguments to get from right and we've basically wrote a property that we're testing that okay if I'm crossing the tick liquidity should drop if I'm not crossing the tick liquidity should stay the same right and this will basically helped us to kind of find some problems yeah hi um on the previous slide where it said um formal verification how does

that differ from the others or is it like an umbrella term did you mean something more specific oh yes sir I guess uh yeah I mean it's it's really like a white term but what it results is um you are having usually like high level specification of your programming system right it's maybe like I want to create a token and in token you can like mint and burn right this is like in plain English I have a specification and Next Step you do you are formalizing this planning specification into formulas there's usually some like special languages how you can express your properties exactly like for example for tokens you

can a single extra toward you talk like you can have uh this kind of rules that tell you if user a transfers hundreds like X tokens to user B balance of user a should be decreased by tokens and burns of user B should be increased right so this kind of formalization happens and then afterwards uh there is like different ways how you can basically uh create a model of your contracts right it's basically you can say Mass formulas instead of the real real byte code right and your former verification basically checks that your specification together with code is something that makes sense right because

it's really like for modifications the strongest of them all because in all previous values and like here we are still poking dots in our like State pace of all possible input values that you can put into this deposits right it's like you ain't it's two to the 256 right it's like too much you're never gonna have it like you can't do it if like University collapses and so on right basically former verifications is kind of tool that allows you to kind of really know that your function depends good on all widths of your arguments or to say right how it does it because they're using

like symbols and formulas instead of the real values yes thank you what are the difference between the first testing and the property testing which testing stateful and property or property testing and first testing what are the difference fast testing it's actually almost the same there is like I think uh like there are many people who kind of especially like in science who are

really let's say Zeal is about the terms so fasting usually in the returns means like you are doing Black Box fuzzing meaning that you don't have idea about internal representation you don't have idea about internal properties property testing is basically fuzzing but you have idea about what exactly system is built off I guess I told you like you have idea about possible Transitions and you try to like basically guide your fuzzing into this edge cases right this is basically it and it's in most cases people use them interchangeably and I think if you open like Foundry documentations they basically have fast

testing and then the next but the HTML link has property best testing results kind of synonyms I would say in crypto Community thank you thanks for the talk could you please discuss the applicability and acceptability of monitoring and also what exists in terms of tools for this uh yeah I mean we had the experience with some monitoring uh I think we like worked with Forte a bit and like try to see how that works I mean the only problem with monitoring in my opinion is that

hackers are really proficient about the ways how you can like deploy transactions right or you can execute code in many cases there is like um Mev Services it can be used to basically uh execute transaction such a way that you see it only if it's already happened right this in most cases too late but in some cases if protocol is specially designed uh with a ways where like for example you are limiting throughput of tokens from uh like from optimism to mainnet like for example maker has said for their like teleporter contract and then in this case if you if

you monitor like some properties that what amount of tokens has been moved you may have like some like alerts to save you bad things happen but in most cases uh like people don't in my experience don't Design Systems where they have this pull the plug kind of uh safeguards right and as well like in in some cases like you can see people okay we have monitoring tools hack happen and they say okay we detect is the hack right button in reality it's like a bit too late so yeah it's it's really uh Works only if you design your system around monitoring right if

you really put a lot of like this what's a rate limiting uh things around or you pull put this kind of circuit breakers uh then like if you detect you can circuit break basically okay I think this is my take on it thank you okay good thank you Anton thank you thanks Anton

the next speaker please welcome Jocelyn from trail of pets who's going to be speaking about fuzzing building secure contracts how to fast like a pro welcome Jocelyn thank you [Applause] foreign

okay hey everyone so this is going to be a workshop we are going to have a couple of exas we are going to go through um if you already want to to take all the material you can take the query card or go through this website um you will see you will see five exercise I'm not expecting us to go through all of them if we can go through maybe three other exercises it's already good given the time we have uh let's say if you want to you know yeah if you like challenge or if you already fast go for it we have two spare tickets for the security Summit so if you go through the five exercise and you don't have a ticket to the summit just let us know okay today we are going to talk about

property-based testing that we are introduced in the previous talks and we are going to have an end zone in our approach on how to develop environment and how to use furthering to develop more secure contracts my name is Russell Feist with me um Natalie chin and Justin Jacob from 12 bits if you have any question about our company about what we are doing don't hesitate to let us know Natalie already introduced us this morning so I will skip this part so today we are going to focus on kind of trying to understand how to find bugs in a in a contract how to find vulnerabilities what are the different type of Technique we can use and we're going to focus on the specific technique

which is property-based technique as well you guessed let's say you have this piece of code you have two functions a function to buy token and a function that computes some price and you want to find bugs in in this example don't try to look new too much there is a bug there but we will see it like later uh how can you find vulnerabilities on a high level you really have four techniques that you can use the first one is unit test manual analysis fully automated tool and semi-automatic tool unit test I'm hoping that you are all aware of you know what they are basically you create a concrete example and you are trying to you know test it with different platform other art

foundry whatever you know works for you here it's a good technique it works well because it's well understood by a developer but from a security standpoint it's not going to protect you against vulnerability we actually have data that highlights there is no correlation between having good unit test coverage or unit testing you know development and the likelihood of having critical vulnerability in the code base and so we run for that is that most of the time when you are going to develop unit test you are going to use them to trigger a happy pass so things that should behave the way you know like you are intended to do why vulnerability usually usually relies on kind of edge case that's why you should still do unit tests but

they're not going to be enough the second technique oh yeah just an example of unique test the second technique is manual version for this usually it requires specific set of skills specific mindset and specific expertise usually for manual review you are going to ask security auditing teams such as trailer base or you know any of our competitors to look at your code and you know try to find when updated this uh somewhere benefit you will be able to catch any type of vulnerability you will have like a large curve image but it does also some limitation the first one uh it's kind of done on a kind of on the snapshot of your code base it's time consuming it's worth of intensive next technique you can use you can use

fully automated tool usually this type of techniques rely on static analysis or analysis like static analysis they are going to look for pattern for common vulnerability that are well known in the space and they are going to thrive in our ability to find vulnerability like that you might know Slither which is a static analyzer for solidity if you don't know we are actually of a GitHub action which is called sitar action where you can just add this to your CI every time you do a peel request it's going to look for common vulnerability and it will help you know to try Azure results this is really powerful and it's open source and it's free the last kind of type of technique

we call them semi-automated analysis because then you need a human interloop you need someone to help the tool to to know what you know they are looking for and one of the main known technique for that but we kind of discussed in the previous talk is called property based technique base testing and we are going to see what it is and how to do it with a Kindle okay so as I mentioned um as a precursor in the previous talk um

when we refer to fuzzing we're essentially stressing the program with random inputs which means at a high level it would be like a monkey on a keyboard or a cat on a keyboard and essentially throwing random inputs into your smart contracts and seeing how your system behaves it's fairly fuzzing in general is fairly well used in traditional software security and you can see that through the use of like for example AFL and Gophers generally these um generally these platforms are testing for crashes so they're looking for are there opportunities in which malformed input can cause a program to crash and

therefore cause unexpected Behavior that's not exactly what we're going to be testing with smart contracts because there are there is no concept of crashing instead we're looking at property-based testing so this is when you take some of the assumptions that you've made on your code base and you apply it through property-based testing by defining invariance the fuzzer is basically going to Generate random inputs call your smart contracts and check whether the output in the states are actually correct and whether there are deviations from what is expected in general fuzzing can also be considered as unit testing on steroids

because you're not only limited by the input that you've specified but you have the the fuzzer comes with additional features to essentially generate different input so in terms of what is an invariant and what and how are we able to actually use fuzzing to integrate and invariant is basically something that always has to be true it's something that regardless of what a user does with your code base and how your code base works this property is supposed to hold true within your code base for any state change so the easiest example would be for the

erc20 token that a user's balance should never exceed total Supply if this property is violated then it means there's probably something as an error within like the mint function or maybe something with an arithmetic this property tells us that if there is a violation that there is an underlying bug in our code base so this is where Echidna is used we use it fairly heavily in Audits and it's used very much in mature code bases it's basically used to generate those random inputs so that we can call Smart contracts and call those functions and

see whether properties are intended to hold so from essentially the invariance that we create we're writing them into solidity into something that Echidna can understand and therefore run randomized inputs on to check whether there are potential invariant or property violations so this is one example of smart contract code and this is just the typical this is just a standard token it's got total Supply it's got balances and it's got a transfer function so if we specify that the property invariant

is essentially we are able to Define it as an Echidna function the Echidna test is going to Generate random inputs to see whether a property violation is possible so in terms of what the property actually is um we were essentially we should be determining um what code to put within the Echidna invariant to determine whether total Supply and the balances assumption assumptions actually hold if a kidney is able to break this then it means Echidna has essentially found a set of inputs that breaks those invariants

so pass it to Johnson for exercises thank you okay um as I mentioned it's a end-on session so we are going to see a couple of exercises and we are going to you know help you to write invariant in solidity and to tell them in with the kingdom before we go around for like the setup do you have any question regarding property-based testing regarding fuzzing in general Okay so you can go on this website hi everyone customer question

um do you know what's the difference between the property based testing and the mutation testing okay usually mutation testing um each refers to a technique where you are going to change the unit test so you have like you know a set of unit tests and you are going to introduce change in your test or in your function to see if the unit test pass or doesn't pass kind of like the idea of mutation testing usually is going to rely on trying to evaluate how good your unit tests are here's the films because here we are going to Define invariant and we're

going to see using very not old or doesn't hold so mutation testing usually more used to test the quality of your unit test here it to test the invariant of the system okay thanks we have a tool which is called necesses that does mutation testing if you are curious okay what time is it so let's take 15 minutes to go through this classical size so if you go here now you can just follow the Rings okay until freedom

and we are going to go you know we're going to go over if you have any questions with the setup or if anything is not working [Music]

[Music] foreign [Music] [Music] [Music]

foreign [Music] foreign [Music] [Music] [Music]

foreign [Music] foreign

[Music] foreign

[Music] [Music] foreign [Music]

foreign thank you

[Music] foreign [Music]

[Music] foreign [Music] foreign because of Peugeot it's going to be spotted in the next release so you need to use a salty version B for 0.8.20 and you can use subseas select to easily switch between them

let's give it three additional minutes and we'll go through the answer foreign [Music]

[Music] foreign this was a Target and assuming you can see you know just by looking at the card that there is an abuse bag here we are using uncheck on the outlet medic operations so there is no

order for protection otherwise what you can easily do like an underflow when you transfer the funds but how can you you know without even looking at the card how can you try to find this type of box and here um the property that we want to try to see if it's invariant that no one should have more than the total Supply if you deploy the contract and you say like the initial balance is ten thousand and there is no mean function the total Supply is ten thousand and no uh the invaliant property is exactly that the user should not have more than 10 000 as you can see here hunting which is really straightforward that you can Define the

invariant in solidity everything is in solidity it's just a function with like that we're doing a Boolean like a condition and this condition is our environment if you want a canal on that it's going to say yes I can I can break this invariance here is a sequence of transaction to trigger and to which like this is condition and it's just a call to transfer with ten thousand and some number and yeah obviously it's because of the underflow here is there any questions regarding the first exercise how many of you manage who have echina winning

okay how many of you managed to finish the third exercise okay so let's go to the second one here we are going to try to have a system where you can pause the system you drop the ownership and we're going to use akina to see if we can unpause the system so let's take yeah let's take 15 minutes again so 25. then it will be also on YouTube

sure so can you tell us a bit more about how Echidna Works uh underneath like does it just realize what the functions are and calls them in a random order with random inputs for example in this case with the pause and pause I guess you just write this invariant saying uh make sure the contract is not imposed and then it would just try out to dispose and post functions by itself so it's going to try all the function of the contract there are some heuristic for example we do construct constant extraction so we are going to use heater to look at the code find some interesting variable and feed that to a keynote so that it's not fully random it's random with some realistic under the wood it does

coverage so it's going to look at you know what are the different what are the different aware of the code that are reached by the transaction and it's going to use this information to determine which uh like mutation to apply so it's it's not fully random it's one Dom with some realistics so for example for the previous situation with the transfer we only care about the balances and not the pause and pause mechanism there is a way to guide the kid not to say yes this is the only thing you should use try to break it with that yes there is a configuration file so you can say okay just call file function or just call this function like if you have a really large you know code base and you want kind of an hour of the

search you can do that with a with a configuration file all right thank you any additional question foreign

[Music] foreign [Music] [Music]

foreign [Music] [Music] foreign [Music] [Music]

thank you foreign [Music] thank you foreign

foreign foreign

[Music] [Music] [Music]

foreign [Music]

[Music] foreign foreign

[Music] foreign [Music] [Music] [Music]

[Music] [Music] Christmas foreign [Music] [Music]

[Music] thank you foreign

thank you foreign

foreign okay

foreign foreign [Music]

foreign all right

[Music] foreign [Music] foreign

[Music] foreign [Music] okay just to get a quick overview how many of you managed to finish like the second exercise oh way more on the first one congratulations okay

so here we have a contract with multiple function we have a feature where the owner can pause and unpause the system and there is only another modifier and and so on so the question here is can we deploy the system in a way that the contract is pause you drop the ownership you put it to the other zero so there is no more owner the system is paused can you unpause it and here again the properties and variants is going to be described in solidity it's simply this function so it's a function that we're doing a Boolean and the Boolean is a condition is pause is

equal to true foreign yeah so um I thought we had to write a test that narrows it to you can't call resume essentially because in the test you're calling paused at the start and if you're saying

is forces true is always true then it's not going to be true initially until paused is called and then ownership is right now so okay if I understand correctly and then correct me if I'm wrong um you you mean that to check if regime can be called was well I just thought that was what the exercise was oh okay okay um I guess the test is not the contract that's like a user and the use you're you're saying the expected Behavior as the user can deploy the contract cool pause and then renounce ownership and you're testing that it can't be unpaused

um but that test is saying is saying that it's always paused from the start but if that makes sense uh like so okay like here the scenario is that you deploy the contract you call pause so you process system yeah because I'm seeing this as like separate from like this test contract I'm seeing as separate from the token okay so there's any no returns here so test again inherit from token so your inner or the functionality more for like Foundry tests you you have like a setup and I was thinking the Constructor is like set up but you're

actually saying like that's the Constructor of the token yes and all right yeah okay fondue typically would have a setup function where you do like the initialization we do support uh these kind of a let's create an API I have a couple of slides later on so you can also use setup function and do it that way that makes sense yeah yeah that makes sense okay um okay where I was yes so here the environment is just the solidity function is always closed uh if you weren't on it it will call two different functions and it will break

the invariance here just to remember we did not look at like the different function we don't maybe we don't even know there is like a resume function uh we just say I want to have this invariant and what's going to happen is that Akinator is going to deploy this contract is going to call all the different functions available in the contract transfer pause and pause whatever is going to try all of them and in between every curve is going to call the Echidna function so the environment it's going to see if it's holding and here what it does is that it does two curl one call to honor one call to resume and after that when it covers the invariants the environment is working why the environment is broken so this is

kind of like a hold style of vulnerability where people well like in all versions of solidity you are defining the Constructor with the name of the contract and here there's a typo the contract is called ownership and the function is called owner so owner is a function available for everyone anyone can become the owner and then everyone can unpause the system this type of vulnerability don't happen anymore but it's just to give you like a kind of a should not happen anymore but just to give you like an Insight of the type of invariant that require multiple transactions to be broken do you have any question regarding the second exercise

um yeah so regarding the functions you call is it like brute force or do you have any strategy on doing this so as I mentioned previously it's random but with some realistic and one of the realistic is are using the coverage so it's going to look at you know like you make a new transaction with a different function are you covering new card yes no and based on that is kind of a feedback group to know you know where where to kind of prioritize but part of it is still London

I think there is like a can you please go back to the previous slide I mean it's a related question to the previous one so in this case owner doesn't take a parameter but let's say let's say that an owner would take an address yeah and the owner is set to the address in that case would I could not still be able to pass message or sender to the owner and still be able to find the bug yes um typically as I mentioned like you know it's going to try one dummy value for the parameter but in addition to that there are some heuristic and one of the realistic for address for like the type address it is going to use all the addresses that are known within the execution so your honor any contracts that you deploy or things

like that and what about interactions where uh you know a specific function needs to be called a few times and another function and a little complex interaction so uh I mean does Echidna try those also or yes it's like here here there is two transaction but you can go for like further five six seven something that can happen also is that you call 20 transaction you break the invariant and then you know as a strategy where it's going to try to reduce the the call so that it's a bit easier to debug so you might break it the first time by calling 20 function but that link it is going to try to say okay maybe I just need to call 10 of them and I'll leave this process okay thank you

okay you know the question um that is sometimes difficult in order to have a good insight and and and and to go to go behind is how to define good invariants like the example we just saw the invariant was pretty straightforward and you know very simple but when you are like in front of a code base the environment might be more complex so how how can you kind of Define and how can you understand them and I think the best process is travel iterative approach start really small the first environment that you are going to describe for your contract should not break like the first invariant should be something really straightforward that

should not break it should be something just to kind of uh get used to the cut base and get used to like the the system you should first Define the invariant in English don't try directly to write them in solidity uh you know open a markdown open a text editor whatever works for you and start to you know think about them in plain English like while the system is supposed to do then vitamin solidity and iterate your nakina does it work does it not break if it works either you found a bug or maybe your environment is wrong maybe like you know you made assumption about the code base and the assumption that you add was not correct so that's why you need this interactive approach and that's why trying small is usually better because you will move

complexity uh as I mentioned you know start early on even even before it's kind of like a powering shift even before starting to curd like if you're a developer before even starting to cut your your contract you can you can think about what the system is supposed to do and this will help you you know like down the line um so it's really like a process of thinking about what the system is supposed to do just to give you some example if you have uh now with magic Library if you have like you know a fixed Point arithmetic or something like that then you can think about 1000 arithmetic properties that you you should have uh commutative identity inverse and so on so you have like a couple of math

related ingredients should offer most of the properties then you are something that can be more complex with a supply which you know we already saw uh then you can start thinking about some function for example transfer what the transfer is supposed to do uh the transfer is supposed to decrease your amount right and it's supposed to increase the amount of the receiver if you go and you define an invariant that does that you will realize that this is actually false because one of the edge scale is that if you do a self-transfer if you do reception or you don't decrease your balance your balance is going to stay constant now this is just an example of invent that might seems trade for a

while but actually there are a lot of edge care then things to consider when you are building on this type of things something to consider also a situation where the system should revert so our bottom Force so it's also important to you know create event on things that should not happen in that way so if you have a transfer and you don't have enough funds as well you should revert our transfers depending of your implementation yeah kind of two categories of invariant you are going to a function leveling variant so those are going to be invariant related to the execution of a specific function most of the time not all but most of the time they can be stateless invariants or you don't

manipulate the state and those are usually the simplest to test because you can just look at the specific function and you can just focus on that then you have system level invariance so in variants that must be true for any function within the contract the balance Supply the balance of the user not not being greater than the total Supply is one of these examples so it's not just with respect to specific function but it's it's switched back to the system as a word now how to do that in practice for function level in variance a simple and simple technique is just you anyway the

target you name it the function you create a function that you want to test and you can use for example assertion to to check so you can say here it has a commutative INB and you test it is equal to BNA invariant might have more complexity in the sense that you might need a complex initialization maybe you're going to try something that requires five different contracts and then you need to deploy the five different contracts for that although you can do everything in solidity or you can also leverage you need test to do that we have an additional tool which is called etheno it's just going to reply your unit test and help the failure for that

okay if we go back to the example at the beginning of the presentation if you remember we have this contract we have two functions a buy function which is going to check if you have enough money and means some token and a valid buy function that is stateless and just going to try to see if you provide enough token and enough ether to to buy it here you have to function by which is stateful valid by which is stateless here again start with the simplest one valid by start with the stateless what environment can we have here one simple one we like simple is that if you send zero ether you should not be

able to have any token out of it so you can Define this as a session so you call the you call the function you say I'm sending more than one you call valid by this should never be twitch like this should always fail because you are trying to buy something with zero if you want this with the key now it's going to tell you actually you can do it with one and the reason for that is if you look a bit more closely to the formula here you have a division and then a multiplication if the number of token is below 10 the division is going to root on zero because it is going to run down so the

amount of Airtel that you have to send is going to be zero so for any token from one to nine we can basically buy that for free does it make sense any question I have hinted a bit the session model so in echina we have what we call Api so we have three way to define invariant we have the Boolean properties that we saw with the first exercise we are the assertion that we quickly saw um sorry we quickly saw with like the previous slide and we also supported up

from the API the dub Foundry is mostly the same as a Boolean property but you have this setup function and so on yeah Boolean properties where we deserve them assertion you just add additional answer to the code base and app Foundry that you are aware of so for the next exercise we are going to go on exercise four we are not going to do the exercise 3 today and here we are going to use our session board so we're going to try property where instead of using Akin something something function we are going to use a session and let's take

10 minutes ish for this one any question this one would you mind going to yeah the example test thank you this one okay the slide also in the GitHub if you actually need them do you have any questions regarding this one okay just okay I have a question yeah

so you mentioned system level assertions and let's assume in the case with the balances you write the test and just make a transfer and make sure the balance is either increase or decrease is there a way to do this subsequently like many more times do these transfers away outside of just running a for Loop and just doing a bunch of like does that make sense I want basically to do a lot of transfers but the state is maintained after each of them so it's what was already happening here um like you are going to Define an invariant where like you know like the after of the execution like the stage should be which like this invariant

should be true Aquino is going to try multiple code if you remember on the previous example on angular size 2 akina was calling two function it was calling owner and then resume I think so here I cannot could also called if you have a transfer function you cannot might call transfer one time two times three times ten times it's just going to randomly try different combination okay perfect so let's say in a case like a landing protocol and so on it would just just try a like a random number of iterations of random number of things and it would just see if at some point reaches an inconsistency that's correct um there's a notion if you look at the configuration of a sequence length

basically it's a number of curl before the state is rated to the beginning like for example if you say the sequence length is 1000 it's just going to try one thousand call and at some point you just visit the system to like the initial state okay thank you and is there a way to kind of uh Target its inputs to something for example like it's in uh Forge I think you basically can limit the inputs in some ranges so the best way to do that is to do input filtering and solidity we have some tutorial and insecure contract about that and we have some helper in a repo which is called properties

basically you use modulo so you know like if you want to kind of uh narrow the input from an integer to like 100 to 1000 you can use module operation you take like the uint use modular operation so that uh otherwise your teachers can be between the sponge and so that the further doesn't waste time you can also use require you can just say you know like require this input to be that number but require which will waste uh like results from the further because transaction will work okay yeah thank you [Music]

[Music] foreign foreign

foreign [Music] [Music] foreign

[Music] foreign foreign

foreign Okay so

here's a goal was to use a session and we were trying to you know break the transfer function so here we inherate from the token we call Super Auto transfer to call like the function we want to test and we Define on layout using assertion so here's our session is that you know it does it has increased um and yeah if you end up with a kid now it's going to break even variants uh because of the back I'm going to go a bit quickly because we are running out of time uh one thing you can also notice when you use a session is that you can keep that session in your curl if you want uh additional you know onshine Safeguard this will allow you to have

like invariant and post condition within your contract it's going to co to you know cost more gas and it can be complex enough bugs so keeping your contract only a session that you have a strong confidence in it and four thing that are not too complex quickly there is a notion of multiple contract and composability or the example we are mostly on one contract but you may be like your system is using five or six different contracts for that you can use a specific flag which is all contract if you do that instead of focusing on filling one contract ekina is actually going to call all the function of all the different contract if you are looking for composer ability bug that's very useful

a couple of additional exercise I'm not going to go through uh but you know feel free to go through and after this day there are many additional tool and technique that you can do to check in variants uh there are other like Bernie dark Foundry they might be easier to use but in practice it might not be as powerful we have been using a kid now for more than five years in a different audit and we spend a lot of time making it efficient um a lot of other technique based on formal methods such as formal verification the technique are useful they are powerful but they have a lot of drawback they are complex to use they are time consuming there is this quote from the runtime verification CEO

basically saying that you need almost 10 times or nine time uh the resource to do formal verification on your code base versus what you need for developmental it's really intensive in comparison to selling that you can as you as you saw use pretty quickly a lot of advantage that I did not cover we have some functionality where for example you can try to look for transactions that are going to consume more gas if you are looking for you know complex Loop or things like that you can do differential fuzzing where you try to apply on two different uh implementation of the same logic you can do Unchained phasing so you can provide an address and an FPC node and the keynote is going to try to First based on a state which

is existing on chain and so on and so on it's free and open source obviously Just for information we are actually writing we are rewriting akina and go it's called Medusa it's not as much as the keynote it's kind of on an MVP phase but if you are curious and you like to experiment with new tool feel free to go through it okay I hope that you enjoyed this session to learn more about our environments and property based technique you can go to secure contract we have the properties repo where we have defined existing invariants for different protocol but you can already reuse and just Import in your contract you know you should start thinking about

invariant starting English and then try in solidity out of curiosity who here is going to try again on his next project perfect and if you have any questions feel free to let me know [Applause] thank you you selling for your workshop and now we have a 10 minutes time for well-deserved coffee break the next week will start at 4 20.

um yes the next big taco starts at 4 20. thank you um foreign

[Music] [Music] [Music] [Music] foreign [Music] [Music]

[Music] thank you [Music] thank you [Music] [Music]

thank you foreign [Music] [Music]

thank you [Music] foreign

[Music] foreign

[Music] foreign [Music] foreign

[Music] [Music] foreign [Music]

foreign [Music] yes but that is

ah what is this thing okay excuse me it's uh now time time to get uh back to place to see it and enjoy our next talk um from Ernesto uh buado from bgd labs and Tomer ganor from Satora it's a workshop 90 minutes kind of motion

should I do something you should find me if I am use this for my life is it fun if I use this yeah I mean I use this foreign

yeah uh hello everybody so I'm Ernesto I say he introduced I'm from BD labs and today I will be doing like a drawing talk slash workshop with Tomer from from sartora let me kind of work together uh so first a bit of what exactly is bgd Labs because sometimes it's a bit confusing so be Labs is is a team that I co-created which which can be considered like a bit of a spin-off from the habitat from the

other protocol so for a bit of background before I I co-created the Ved Labs I was a CTO at companies which was the the team that developed the double protocol like from the B1 version B2 currently B3 and then uh at the end of 2022 like following like the decentralization of of basically everything even of the organization and I I decided like to to create a separate team a development team and from beginning of 2023 so more than one year no from beginning of 2022 sorry

more than one year ago we actually have been the we passed like a proposal on the avidau to to be like the the official live development team doing providing services today to the Dow data daily so yeah this is the what is what is video labs and and which is the relation with with other so uh Wow first of all like a bit of like the the style of the of my talk I I I saw and like I mean this is the device security submit so the big majority of of the doll for what I see are are coming for from the top Security

Professionals that we have here uh I'm not really like uh like a security professional like I know certain things about security I think at this stage but I'm on the development side purely so um basically that is the idea of the of the of the join call talk that I will explain with my my experience like with the formal verification liking uh quiet production protocol we could call a like Abe and um and then like tomorrow will go into details like of exactly like uh how it really works in the practice like on the on the different projects somewhere like

uh sartora rules are are applied into into double protocol so so yeah my will be more like a high level View and and insights yeah so uh first of all like uh some com misconception is that like Abby is like this liquidity protocol on where people just goes the positive scholateral ball against or some others just deposit the multiple tokens and earn yield on on them actually it's a bit more complex than that and a bit there is quite more variety apart from that so yeah there is

the liquidity protocol and that is the the thing that we have is more more well known for but apart from that there is like a governance system launching system of smart contracts like to vote and to actually take decisions on the on the other protocol itself of the liquidity and yeah there is like oh there's like in sentence management like for which is quite separate from the protocol itself but connected to it so whenever like somebody wants to give incentives for using and the liquidity protocol there is also like uh the so-called safety module which is a method of protection like if anything will go wrong on the liquidity protocol hopefully not the safety model on where

like Abby holders stake could actually be a slash to to cover a potential loss and uh yeah the last last piece is a stable coin that actually will be live tomorrow I think if the depending on when the proposal payload gets executed but but yeah this is the last addition so uh to to the whole ecosystem so as you can see like a basically almost all the parts of the defy password or even almost blockchain applications like were touched and they are covered by by Abby one way or another sure yeah this is more about like the

yeah the insights of how exactly like um security is is managed in other how is our approach and especially how how it evolved over time because this yeah we are doing this live for already I think in three years live since 71 and things have really changed I would say the same as with the security ecosystem itself so uh as the big majority I think is aware like this is important is before deploying smart contests as uh once once the protocol is live obviously there is

um way more stuff to dig into account but before deploying starting as Marcon that's what what exactly do we do like what we did like in in Abu back in the days what we are doing now in bgd labs and so we just start with testing with testing I I yeah I think almost everybody familiar I'm referring with unit testing like with certain integration testing of the of different uh independent systems of smart contractors sometimes not smart contests like so let's say the classical testing in software as everybody understands I think the peer review is pretty important like so internally the team whatever is the team like because with this with the

centralization sometimes is not exactly the same team but there is always like steps on where what you're really good of each other and to check that everything is as it should be uh the security reviews which yeah a lot of people call them like manual audits at the moment and this is basically let's say snapshot a reviews of external parties which are experts in security and yeah you once you think that the the code is ready peer review a finish testing is robust ideally everything a new forward or you engage likes on third party uh

security auditor that that will like review everything and and check that nothing was nothing was forgotten or there is no go back and the final piece is the so-called form verification and yeah it's important to to highlight that I'm just using like the informal way the formal verification concept to refer like mainly to what we are more familiar with and what we really use that is like the the sartora property check so a bit of also background of from where it comes like the the relation

between Avenger first uh well it actually starts with it before of the first step of ibv2 um but B2 was the first formal step so back in the days when also tour I think was starting um they were reviewing like multiple live smart contests out there and one of the ones that checked in detail even if Abby didn't really asked was like the Apple smart contracts and well first of all like they found like some some interesting stuff and second like that the the approach that they brought to the table was quite different like to to

everything that we were doing before which nowadays maybe doesn't seem so special like but back in the days like when running Ivy one and especially when when rb1 was really growing to to big numbers like we were just really looking for everything that that you can imagine in terms of security so after after this initial contact let's say uh with rb2 we already like when I was like on on Lobby on the Genesis team like we engaged with with alike for for basically like a review and also like for formal formal verification to apply their technology of property checking on the on the other protocol in this case the liquidity

product uh this continued with rv3 more or less the same so like property checking but to the new iteration of the protocol and things we got like even more interesting with uh I think yeah for sure like more than one year ago when uh sartora the same as with big relapse like engaged directly with the with the Abdullah which basically with the smart contracts holding the holding the permissions and the funds of the system um four services like this to the dial and basically obviously to the to the

development contributors to to the dove itself sure now yeah I think a bit of of the context so how exactly that is the core here like how exactly do we tackle like formal verification and property checking on online MBA labs so first of all like is it's important to understand like why with C value like on applying um property checking not only like what do we do so rb1 B2 and and three a they are pretty complex system let's say so not really like comparable with some

other traditional software I will say but the the nature like the open Nature like the the type of accounting that it has tokenization different types of flows of user flows and basically everything that is built on top and makes it pretty complex like um to even to reason about so the quite a quite typical thing that I say is that when we develop like rb1 and we release W1 I think we learn like 50 about wb1 once like it was running not so much about the imbalance but in terms of like how people was using rb1 then

because of this complexity and precisely because you don't even know how people is using the is going to use the system or how like I know different other smart contractors are completely are built on top is not really easy right to to just do traditional testing and especially be sure that your your testing will cover uh will cover all the cases and you will not have any problem and you will sleep at night when when you have like yeah 50 million dollars in the platform then obviously um we thought about fasting that I think it was just playing like in the two or three previous previous talks and for us

like we even we even implemented on rb1 like a really small engine of uh kind of us in let's say that we call scenarios and the idea was like to well if you don't you at least need to replicate certain conditions certain scenarios on the on the protocol that you envision and and test based on that and be able to generate those kind of scenarios automatically less not not exactly but automatically so we experiment a bit with that but yeah it gave us what we found during development problems using these scenarios it gave us way more confidence that is true but at the end of the day like we were not not completely happy

with with that because still like you you always have this insecurity that you don't really know how it's gonna get use your protocol out there then another point is that yeah we did multiple audits of on rb1 we did more on our way to more on rv3 and still like we kept seeing the seeing the same that is like the security reviews even from the top participants like on that I think a lot of them are around here like they were missing something and and not really missing because the war was not well done when we notice that it's just not so easy

to to notice which like this really edge cases and then yeah so formal verification a one of the main things of formal verification is that it catches certain types of bugs I mean it catches basically a lot of or the majority of the bugs depending on the code base but even with well-tested code bases like and and well audited code bases still it keeps it it catches like some bugs that are pretty dark I will call it dark I refer that like you don't really think in that direction when you while you are developing like a system another point of of why formal

verification is that um well good practices within an early field like defy lack of or smart contract developments like they are always not so so good hours at the beginning for sure were not the best and improved a lot and the moment that we are starting in like incorporating formal verification to our code we we immediately noticed that we started thinking on having a better documentation better specification in some cases like we were yeah we were doing some kind of technical paper apart from certain white paper but it's not exactly the same because you are not really defining the the specification of the code just the

high level idea of what is the system and the for me the the most important of of all is that former verification is a tool that allows you to protect against the what you don't know so they don't know and this is like the a quite critical point especially like in a system like also you will have like malicious entities like trying to exploit A system that holds a lot of user funds all the time in a completely open environment and with in some cases not so much chances like of having a solution one once the event happens so this is incredibly invaluable that if

you have if you can have any tool that gives you some yeah predictability that it doesn't matter what happens on top but the system should be safe always and you don't know what could happen so yeah it feels like there's the the holy trial here like formal verification and it should be applied by all the systems for everything and so on but well not exactly like that at least from our perspective so you can apply formal verification um yeah I think almost any smart contract out there because at the end of this is a way of like checking that your specification and the code that you

write are the same like kind of the same but I think it was mentioned in the in the previous in the previous talk that if you try to do formal very formally verify like any system like in a big percentage of the of the cases like first of all like the effort is incredibly High which translate in in cost of all types and well I mean at least from our experience in some cases it gives value but in gives less value than in some others so a bit of like a like Like rules of thumb of where we actually see like formal

verification methods in practice like shining so if the if the system is having accounting and with this like I mean tokens like or liquidity Protocols of any kind usually is is quite a good idea and this is this is for the simple reason that it testing accounting sometimes is I mean you can test accounting but certain edge cases like this not so easy to test them and former verification can really like tell you it's impossible that you will reach this kind of accounting problem and that is yeah it just simplifies a lot of other things

then um whenever like there is like a complex in and outflow of of assets of uh and in this case like mainly the five protocols and this form verification is also quite quite useful because um you can Define like the properties based on how is the balance at certain point how should be how it should never be and and everything built upon those yeah another another type of systems this is a bit more abstract but uh what I call asymmetric systems and this is quite here it shines quite a lot and to put an example like other is a really

asymmetric system uh even if it has a lot of symmetric pieces like so what I mean is that on average you have like a borrow site you have a deposit side and you have a collateral side but then you have you can have situations somewhere like uh the same like an user deposit certain amount of tokens uh and another user deposit the same amount of tokens but one activates it as collateral and the other disables it as collateral so is basically it that creates an asymmetry of the system and when you combine those those asymmetries like with them borrowing Dynamics or with liquidation Dynamics or with flash loan

Dynamics and then it becomes incredibly difficult to to even understand what happens sometimes and and for sure to create like the the scenarios that I mentioned before to simulate the condition somewhere some backward up sticky and then yeah when whenever like a system respects understand this is like the most clear use case I will say because um yeah basically the property checking can be tried once more or less and then like whenever you inherit from for for the implementation of that standard like erc20 you can and and you put some custom logic you can plug the property

checking existing already of your C20 and then add or customize your life or for your own thing so examples like of real systems on where like I can I can boot that like for verification helps so rv3 for sure and there it shines really important um sdkr will be 1.5 basically it's like the it's a token and it represents like the state tab on this backstop model we can call it the app safety module um SDK both of them I mean obvious the perfect example because it it groups all

the previous things that I mentioned uh sdkave is basically an accounting system it has it has also Stream flow and outflow a bit asymmetric to and yeah then yeah we did like some some wrappers mark on the DLC for six to six uh for yeah for the token so far like they talking so far we have this peculiarity that they grow in Balance so whenever somebody deposits an asset and there is yield like the balance of a tooke of your A2 Congress uh different to some other Implement if like compound where the value grows and not the balance so we will a wrapper that transforms

between both of them and given that is really heavy on accounting this is the key here like the former verification is is quite useful or yeah another another example is like the other token itself because I will explain a bit more later but it's an upgradable took like and it has like both in Dynamics like delegation Dynamics so like it's also having multiple types of accounting but I will go more in detail after then what is not true nice let's say with formal verification uh any content that has like

purely arbitrary logic obviously is difficult to prove how it should be the behavior because anything can happen so this is not even so much about like the formal verification itself is that you intentionally want to the system to be General so it's pretty difficult to try to limit or verify that the system is not General because it's by Design so that is pretty obvious then Crossing [Music] Crossing systems with this I refer that the is the sign that you do something on chain one network one and that reflects via some kind of preaching in the middle

in network 2. in this case is I mean it can be long like and it's useful but for just the setup that you need to do and how you connect the the two networks like it it is a bit more complicated like to get formal verification like in a perfect way because it's more design like for uh like a system in isolation to start with and then yeah when whenever like there is like a certain really small developments like in the case of other every time that uh like a governance proportion needs to be submitted and passed that is like a executable payload like so usually it's not so so useful

like to to formally verify or property check the payload itself it could be useful like and and it is useful like to do the same uh on the system that will get affected but um not really on the on the pillow yeah and as examples of this uh so we build like on like this RBM standard Bridge which is basically a contradon where like you put a tokens of ethereum and it wraps them and bridges it to to start it and so this is purely Crossing as you can imagine and is more

challenging we did like formal verification with retora but yeah it was more challenging than the others B3 this I will explain more extensively just after but well this is challenging by itself because it combines the big majority of the steps that I say that are made difficult formal verification uh yeah and and certain proposal payloads on on the other governance like is the point of small developments not so much not so much reason to formally verify that

but something really important about formal verification is that and I think together with the be secure about the the unknown I would say this is the the one that changes the most for for us in practice is the scenes we are like applying these techniques like we I feel that we understand better our code and we understand better our system because I mean it's a consequence of the good practices too like you kind of get Force like to have them Less overheads on the property side you get forced like to Define natural language properties first of all so the moment that you start reasoning in terms of properties like it opens to

discussions with the even internally with the team and that leads you to to really understand better your system yeah and now like for to to finish my part like before a timer takes over like uh we have two examples and the idea is that I will present from the development side like how exactly the the system is uh and then tomorrow will go with some specific properties that they that were written like uh from the from the specific cage so yeah first of all like the the one I mentioned before that is it will be by

the way like a good example like another this just more challenging so the first is like the perfect one which is uh another token upgrade that we are planning to do and that we develop like the the code already so to refresh with the about what what is what has a special like uh just a token so token but is is upgradable by the Dao by the smart contents of the avadao itself M because of this

yeah I mean and as as it is about into like at least until now like it requires like to have like the the so-called snapshots of balance like and also snapshots of Delegation because you can delegate your voting power to somebody else so uh due to this like um basically on every transfer of the other two and you need to do charting snapshots like which is boating a snapshot but also like for the call proposition power so it makes it like quite quite gas expensive like the the token itself and this hopefully could be optimized um

with governance B3 and I I will play emulator but the the idea is that the the system doesn't require anymore like a snapshot from the token to consider boating balance of an user at any point of time uh M because of that like obviously we decided that I to remove the the snapshot and make it cheaper like the the transfer of the token because it just doesn't give anybody to have more space so what actually to take into account is that I participated like on on the development of the first version of the other token time time ago and now I also participated on the on the new version

of the other token M before we were not applying formal verification now we are applying so what exactly changed your life for us so first of all is that the the writing of the properties like is what I said before like it made a big change for us like because even while we were developing the system uh now on this new version uh from almost the very beginning like we were thinking on first on the properties and also like even the edge cases that were detected by other systems properties like so that that made like a big big change like on improving the quality of the of the development process

then another thing is like that the it kind of compresses the tests like if we can call it that way so the idea is that if you want to you have yeah pretty complex token that has delegation that has balance and that it has like a lot of different combinations of uh of how how those fields are so if you want to really test it like you need you need to have a huge test through it and like I'm simulate different scenarios and so on but in the case of the token is pretty straightforward let's say to to have like a property checking that is like with one property like you can cover like and have the same utility that like 100 tests like of different kind of

scenarios buying a bit the the inputs let's say just did uh yeah and the well the last is that for sure you give us way more uh confidence on accounting which when you look things into perspective like is is pretty important because you have like a token that is upgradable so we for example like um do modification of this even of the storage layout in this case and all of these will control the abeda which in turn controls the whole other thing so the moment that you don't have like good confidence on on what you are doing is not really a comfortable position like to the to develop with

then on the other side let's see which is like the a bit more complex side of the of of the formal verification we have the double government V3 which is radically different to the to the previous East so what is exactly governance between so governance V2 is like I explained yes the smart contrast where people votes on proportional pillows if they pass they get executed and that creates like any kind of effect on the Ave on the ecosystem in the case of government 3 there is still exactly the same so a voting system of smart contacts with execution but well different to B2 B2 was running

completely on ethereum that is where the Abba token lives and then using like some some bridging to bridge decisions for change where obvious but now like Abby Governor V3 is cross-ching internally what that means is that the proposals can be created wherever like they need to be executed then or ethereum acts like a settlement layer um which has like the security but then voting doesn't happen actually on on ethereum it happens like on let's say cheaper networks because voting was really expensive and it was like a big big

barrier so basically you have like this flow that this from Network a that goes to ethereum that then goes maybe to network B to both a proposal then it comes back to ethereum and so so on and so forth yeah the this is not not so important in this context but it's based on storage proofs and that is how we do this um how we move the voting to another uh to another network based on the balance of ethereum and the most important part like a in regards of for modification is a pretty complex State machine going to to the technicality so you have like a proposed life cycle and and then you have

proposal created then is not active then it goes like on boating stay but that is already in another chain then it comes back like this is a pretty complex steel machine a steel like what exactly like it also improved like on our processes and how we see that in these improvements are so the verification of these State transitions like of the state machine like they become they became well more solid clearly because as you can imagine if you have like seven states and you want to properly test them uh you need to simulate like the

different jumps from state to from one state to another like and all the combinations of those or majority of the combinations uh yeah and with formal verification it's a bit simpler like because we have like pretty big imbalance on the system the Tomer will will command I think so we just don't need to test so much stuff ah then a as we have the property checked on like on during the development process is not just something that gets done at the end this in practice like allow us to discover bugs like while we were developing uh he will also claim but like in typical cases that you create a PR and you did some changes that seem completely safe and then property

checking yes it puts the signal that you actually broke everything yeah and then this is actually quite quite important and and people tend to it's not too simple to see but when you develop like something that has so many components like apple governance V3 and you are reasoning in quite high level like on the on the development process you tend to oversee like things on the low level like at least I is something that I I I saw multiple times like not only on this so property checking as it is quite basic if if he's properly done of course but as it is quite basic like

on on what exactly you define on the invariance um when some problem appears is pretty low low level and and and basically that's like a like a seat belt let's say the the against your high level recently and this is pretty important so here an example is the yeah sometimes you forget about like the youth management like and there is maybe so much keys that it could be really problematic and you don't really think about it because it's maybe an edge case that most probably will never happen and and these kind of things but the property just detects it because it breaks an invariant and then

you can follow the flow and actually you can improve the system just to cover the case [Music] so a bit of summary like of the high level from the development perspective so on on Apple like we try to use the formal verification but not just like a hammer to to apply everywhere but we kind of think quite a lot on where we should and where we should not specialize in terms of of priorities for example or projects because we have a bunch of them um understanding of the code is just

game changing like yeah basically if you start to to write the properties like in in a document you don't need any tool you don't need anything you you will for sure understand the way better your code that young just jump into solidity um dart box like so yeah some type of bugs are difficult to see even if you are the best developer out there yeah but but the form verification just helps um and yeah I mean good practices like it's just a side effect what I mentioned on on the initial point and the most important one again is this is like quite quite local for Abby but for

anybody that is building a protocol that defy protocol especially that plans to scale from personal experience I think I I recommend that you apply all the tools that make you be more confident because there will always be like on open finance like a new there will always be some malicious actors even if they are not the majority and and well like having full confidence that nothing bad will happen is fundamental and yeah that's it now tomorrow we'll go to the nitty-gritty details first of all thank you Ernesto

um Anthony I'm a tech leader sartora and I'm going to show you how to use a CVL to improve Security in the oven when protocols like oven um okay let's start so what is even CVL so CVL is a language that is a syntax that is a solidity like solidity it's really like to help developers write properties and for their code and that should be more intuitive for developers because it's similar to solidity um why do we use CVL and we use CVL to find to write tests that find all of the

states all of the possible edge cases and that might happen as an Ernesto said and we don't let us to avoid some state that we think about and then we know that we are covered and how do we do it we formalize the property in Civil Right in Civil Wars we will see right now and we run with the code the the developer the the code through the code we run it through approver and then and we get a result from the approver um the results might be one of one of the results either we get a verified which is a green check mark which is

pretty fun to get and which means that everything is correct and everything is fine and there is no there is no initial State there is nothing that the malicious actor can do to break your code to break your assertion that you wrote in the in in the in the CVL or you might get a violation and when you get a violation it's a red X it's a pretty annoying and what it means is there is some states with some inputs that breaks the property and the the proverb shows us exactly what is that site and show us step by step what happens and to to help us to find the exact bug that breaks the property so

um in this talk talk we'll review some properties that we want the protocol they have a token to have and see how to write them in CVL and what the results that we get when we run them on the other token code and later of course also the governance okay yeah so first before you start writing properties and we need to think what event do we want the code to to have what properties do we need and and as also said it's an erc20 and so first we need some simple erc20 properties and for example um the transfer function as in any erc20

would expect them with expect it to preserve the sum of the sender and the receiver the sum of the balances if I I have some X tokens X other tokens and and Ernesto is why other tokens I transfer him my entire amount the sum before we before the transaction is X Plus Y and after it it should always be X Plus y can be greater than it it can be less because if I transfer him tokens then tokens wouldn't disappear and shouldn't create out of thin air also would expect for example that the sum of all balances of all of the users should be less or equal to the total supply of tokens in the system and which I think is pretty good property and also a user can transform more funds than

they have and then the imbalance which also it's a pretty simple erc20 property and to be more specific about the other token there are there are more properties that we have such as the delegate function that we want that that it will delegate the power correctly between users if if someone delegate their part of someone else it should increa decrease the first user increase the the receipt the delicate T and truly influence any other user so there is no this hidden address that might still of a part of your evolving power or someone that you steal from some specific address and because you we run on all possible States and all possible inputs

we know that there is no Edge case specific address that might do any of those things so this is a civil rule which describes the first property the the sum should be preserved when we transfer tokens the sum of the both of the users balances the sender and the recipient and so let's go over it and see and see what what's what's here so first we have on the first line we have the name of the rule and we have two parameters the address two and the un256 amount the address might be any any possible address in in evm any value it's not not limited to anything and also the amount

the amount is any any possible amount so that means that if there is this specific amount of specific addresses to break something we go over all of them so it can't avoid us then we have the N variable which means that we start here from any possible State and any possible initial State and and the transaction that we will run in a few lines in the transfer can have any message sender it can have any message value any block timestamp any block number anything so if there is some specific input that might break or might and we might miss here we run on all of them so we can't miss it then we save on the side the sum of the

balances of the sender and the recipient the message sender and the recipient the two and we call the transfer function um and then we just assert then the sum of the balance or the sum of balances after and the sum of answers before stays exactly the same so this is a pretty simple rules in simple property that would expect of anything else it wanted to have those property so um of course we run this rule when development and everything was evalued wait I just and and this is what you get when you write a good property you see the green check mark everything is correct everything is valid and it's it's pretty you can be happy that you've

proven it after we do that we integrate the spec with the CI and whenever there is a PR for the from the development team they just automatically run the rules on the new version of the code and then we just verify again that it will still hold in some cases it might not happen and then we found either and we have an issue either with the code and with a new code and then it means that something is broken there so that exact rule was integrated in in bgsd lab in CI and among other roles of course but that

specific one just broke recently on one of their PRS and what happened there is that we noticed that there are a red X which is of course dead and red is for bad and we can see this violation let's just click on it let's see red and and we can see here that this assertion broke and the sound this assertion book is false right so here which we have this assertion the sum of balances before the transfer was 40 42 and after it was 44 which means that the sum of balances increased and when it happened let's

take a look on the side on the variables and we can see that the two address here and the message sender here are the same right yeah the same what it mean in in the code there was a bug that if someone send money to themselves transfer money to themselves they just get an extra money for free so if this in this case the the message centers transfer themselves one amount one and they just got an extra one a token so it means that if if this code was deployed it wasn't but if it was deployed then anyone can just gain infinite amount of other token they have to have at least one but then they can have as much as they want you can just

double themselves for forever and which is a bad bad thing to might happen especially in a governance token um and of course after the fix we can just rerun the rules and then get the green Checkmate check mark again and then we know that it doesn't happen anymore okay um some other property that we have more specific to the other token and to the governance part is the Integrity of delegate delegate function what should happen there is that we have a a delegates to B we expect that A's voting power will decrease B's voting power will increase and all other users

shouldn't be influenced by this delegation because if a and b haven't been delegating to anyone previously then the fact that I am delegating to someone else that I haven't done against anyone in some and the fact that I haven't been dedicated to anyone and then I started again to him no no one else would receive or lose um a voting power because of that operation so let's see how to write a rule for that and we will go over it it's a bit long but the government part by part and see exactly how simple is it it is okay so the start is in the start we have Alice Bob and Charlie and a b and c so Alice Bob and Charlie

can be any address um as I said before any possible address can be there so we can't miss any Edge case if there is a specific you know it's a specific address that might break something a malicious actor or something it it's also go over the all of them so especially that also and then we start from any possible State we require we want that Alice will be the message center of the transaction because later here we see that we call the delegate function we want Alice to initiate that transaction and also the ones that Alice Bob and Charlie will be different than one

another because Charlie is the one that represents the third party user who doesn't know the wizard doesn't know anything and just doesn't shouldn't lose or gain anything from this delegation analysis Bob can be the same the same person because if someone delegate to themself doesn't have a meaning and for our rule currently and then we expect that Alice and Bob don't delegate to anyone this is this part the bottom require that there is a Alice delegating to someone or is someone we require that they don't delegate to anyone and then we just save some data on the site so we can compare it later we save the Alice's balance Bob's balance and then we save

the Alice voting power both voting power and Charlie's voting power and later we will have the assertion on it so so we need currently to save the the the the the data before so we can compare it later then we call delegate with a with one specific requirement that Alex is the message sender Alice is the one that's initiating this transaction but the message value specifically here because it's an unpayable function the message value has to be zero but the message value the block block number the block time step can be anything so if there is a specific maybe there will be a specific time in which something will break even all of those guys that we cover because it's unconstrained it can be anything and then after we call the delegate

function this related delegate function then we again save the Alice Bob's entirely voting powers and we check four assertions that if one of them break we have a counter example we have something that's broke what we expect is that Alice voting power will decrease both of the file will increase and we expect also that Bob will be the delegate of Alice and that is another function that we have in the would you give your voting power to so Bob should be the one and that Charlie didn't close they didn't get anything so Charlie's voting power stage is exactly the same so um when we run this this role let's see what happens right should pass

but it fails what failed here let's check which assertion failed the third assertion failed here you see there is false here the one that checks that Bob is the legacy of Alice white failed so we can check here the rule parameters we can check here on the side that Bob in this example is zero why is this important because in the other token whenever you delegate to zero it's a special address whenever you delegate to up to zero then it means as if you delegate to yourself so although you're not delegating to yourself from the system perspective you are the login to yourself so Alice Ali says um delegate is herself so then Bob is not

her delegated so that breaks um which is not not good it means that we missed this Edge case when we wrote the the rule we should have prevented the system from even thinking prevent from this provert to even think about this this option so what is missing here so what do we miss in the beginning what should have required we should have required that Ali's love and Charlie are not zero because if there was a zero address we know that zero others can initiate transaction and they can't vote they can't do anything so it doesn't even make sense that Alice Baba Charlie will be zero address so when we require it as following then the rule verifies

and everything works and we got the green check mark yeah where where because if Alice was the zero address then technically it doesn't break this this example can't happen because we know that Alice Bob and Charlie are not the same so if Bob's needs to be zero to break the to break the code then then we already required if Bobby zero the analysis for show not zero and also Charlie and okay so to prevent these counter

example specifically this case that we know this isn't correct we don't need to record no need to require that Ali specifically is not zero but because we know that this case is not interesting for us and we just we we we can see that oh so when it's zero something breaks and we we know already it's not interesting case so we prevent those cases for event turn up because we know it around feasible cases so we just prevent them let's say in advance because we know it's a safe assumption um okay so those are the two examples on the other token and now let's go to the governance V3 and let's see how we can use CVL to improve the security in governance risk-free and so

let's review some of the properties that we want the governance especially to have and see how to translate them to CVL and run them and see the results okay so [Music] um okay so which properties would we expect the system to have the governance with three to have and we have an invariant and then invert of the system that if a payload doesn't exist so it's greater than the payload counter as I said before the there are payloads and they live in in some other chain and we we have the payload candle

that states how many proposals were created up until now so any payload ID which is further than the counter so it doesn't exist yet should have a null state or a struct of the state of the of them of the proposal and the state should be null because it doesn't exist yet so it doesn't make sense and it won't want to be zero what we know and so let's see how how do we do it well first we need to to understand what are invariants how do we prove them so modern invariance inverted the property that should always hold um in some tokens it might be that let's say the balance of zero is always zero because they prevent transferring and

minting to zero and in this case I want the the environment that some for any proposal ID that doesn't exist yet and we want the state their state to be now to be zero and and how do we do it how do we improve invariant so what we do is we do an induction so we have the the base of the induction that we call the Constructor and then we check whether the invariant holds or not so if the invariant hold for after the Constructor then we have the first step and because we have the base of the induction then what we do is we start from any arbitrary state but we require that the invariant the condition was

already true and then we call any function with any inputs any possible function any any possible function that the contract has and we give it all possible inputs that might happen ever in any any message sender any block timestamp any let's say they have four parameters two addresses one unit and one pool we we give it all of the input all of the possible inputs and then we check that the we assert that the condition is true again so after the function that is true again and if it's true again then we know that whenever we start with the invariant being correct we will end up at the end at the environment being correct again so because we know at the base the base of the induction we know that it was

correct after the Constructor and then we do we we have proven that whenever it was correct it will remain correct after any function with any inputs that means that it's correct forever because we start from from it being correct after the Constructor and then no matter what we do it's keep keep being correct always so now we can we can assume that it's correct because we're improve proven that is correct always so no matter what we can assume it so why I'm explaining this to you because now we can understand what is the meaning of this statement so um this is an invariant that represents exactly this property that non-existing payloads have in another state

the non-existing part is here because the uh let's start it's an invariant keyword and this is the the type of thing first there was a rule now it's an invariant and then this is the name and then you have the uint40 the ID the payload ID so if the payload ID is greater than the payload count here the left-hand side of the statement and that implies that the payload the payload state will be none which is pretty simple a way to show to prove that no matter what there couldn't be let's say any payload that's in the future that will be allocated next or sometimes in the future it can't be already

initialized with something it should always start with none which makes sense because none is the enum of zero so in a VM usually it will start a zero from the beginning but here we can prove that there is no way to backtrack or something and so this is this invariant is we proved it and now we can use it when I say use it what do I mean I mean that for the next rule we will use the invent will require the invariant and see that it helps us to prove um the the rule so another property that we want to have in the governance V3 and is that whenever a proposal as Ernesto said there are a

pretty complex State machine for the proposals they are the the non-state that we showed before we have the created with the active we have the queued executed and we have also a um canceled and we have expired a lot of states and the state machine is pretty complex but we want to to describe a simple property that it covers many many cases and not just um have a lot of tests that checks when I start in this case and then I call some functions some specific function with some specific input it doesn't break yeah but I want to prove that no matter what if I get to the cancel that

expired or executed Estates and I can't go out from that state it's a terminal state so whenever we go in we cannot go out ever not even to one from the other we can't if I get canceled we can go even to expire to execute it we just stuck there forever same as the for the expirator of the executed which makes sense let's say that we have some proposal that says let's let's pay from someone that the Dow decide to pay for someone and then that proposal is executed we don't want it there to be exist any function with any input that somehow can make this that proposal to be not executed yet which is called queued and then you can just pay them

again it's not a good a good thing that happened in the also if you have some proposal that's expired we don't and we know oh that is expired we don't know we know that it won't happen in the future ever because it's expensive let's let's say maybe maybe there is a proposal that is that says let's pay for someone and it's expired so we will just create another proposal that we will actually pay them and then and then we pay we execute it so we paid them but then let's say that there is some way to make it unexpired the first one so then we can make it unexpired then then pay them again so this also doesn't make sense so we want those states to be terminal if something happened we want to be sure

that we can't leave those things this is why this this environment is so important and and it came up while discussing with vgd about what they expect the court to hold and and this is one of their values we came up together one of the properties we came up together and let's see how do we write it in CVL so um this is a parametric rule which is a before we saw a specific wall with the delegate and specifically with the transfer and we had one function one specific function that had any input we started any possible State we call a specific function in the with any input and then we saw that the assertion pass

then we had an invariant that starts in any possible State and then it called any function with any input and then check that that specific condition holds still now we have a parametric wall which we start in some state in in any state that that the requires are correct about it then we call any function with any input so again any external function of public function and that the contract had we can call it and then and then we can run a certain and be sure that the assert always holds so here we start with a method F this this part is the parametric function here

okay so the method f is n can be any function the args as they are represented any parameters and we have the uint40 which is the payload ID and we require and then we require invariant which means that we tell to the to the prover we say okay so we already proven this property we know that if the ID is greater than the count then then it means that the state should be none which help us to prove it because without this invariant this property can be proven because for a specific example that let's say that the next proposal ID the next the next one the one that we will Define right now and will start

somehow without this invariant as expired or as canceled and then we propose a new proposal which go over this proposal so then its state will become created which is not which was canceled before and then it become created so we CA we we we left the canceled State and we entered the created state which doesn't make sense because it shouldn't happen so the way we prevent those cases is by proving that it can't happen and then requiring it so now we know that it doesn't happen next we have the require this require is is exactly as I said before we need to start in in a state in which the the state is either executed

canceled or expired and if we started in that state it's one of them then um we call the is that any function with any parameters any message any image message value any any block timestamp block number message sender anything so there isn't a it's a hidden embed actor a hidden address that has the um authority to do whatever he wants or to to somehow roll back transaction or proposals it's it checks everything so any message under anything and then we just sample the after State and we assert as I said before equal to the state after this is a pretty a pretty simple rule

after we go over any each part of it and see that that they are pretty simple here we just Define the state here we require the invariant that if it's the idea is too greater than the count it's uh it should be none and then that we start in in a state in which it's executed canceled or expired and run the function and assert the assert that it's the same so after we do it we get evaluation so and this is a revelation let's go over first the green Parts with the good parts so for all of the functions as you see here that there's a green check mark it means that we were able to prove it so no many no no matter what initial

State we had and what parameters they put in to any of those functions they cancel payload they get payment a capable of State any of those function functions no matter the input the the condition the assault doesn't break but for the function update executors the the search the assertion broke it went from expired to queued which means that there might be a case in which we have an expired um we have a proposal which is expired then we call this function there are some inputs to this function that that will change the state from expired to queued which means that um as we would assume at least I think

it's reasonable to assume that if a proposal is expired if a pair is expired it means that we can't run it in the future right that is the meaning of expired let's say you have a milk in the fridge and it's expired you assume that it can be unexpired and then you can drink it again because it's it's expired already um but now here we see that it might be unexpired and it makes it to be cute with Cube means that someone can run it and execute it and which is not not good for for the system and and not good in general um okay so what we learned today um we learned that what CVL even is so

it's a language for for developers that it's already like that we can write rules in intuitive way and that is will help you secure your code is exhaustiveness and in finding bugs that we can check all of the states the exhaustiveness part and finding bugs we saw from the CI integration that will never whatever you do if you integrate it in your CI the rules run again on your code on your new code and you just you can know for sure that no matter how small change how many small chances you've made even if you change one one function one line one one if statement

something might break so then when after the rules run away over it you know that there are no initial State no inputs to any function that will break those properties and you know that it's correct um this is why you should integrate civil into your CI and we also saw how solidity and how CVL and sorry our CVL rules and civil invariants look like and the reason I'm saying solidity so much because they look pretty much like solidity they are pretty similar um thank you [Applause] any questions

from someone yes does the proverb support a reasoning about large multi-contract systems as a single state and okay so as long as the it's on one chain then we you can have a large state of multiple contracts yeah you can have it and the initial state will have any state of all of the conflicts or any one of them can have any state and then when you call functions between them then the contract will interact one another and influence the state of one another if the function should do it of course and then yeah it works

anyone else yeah thank you hi uh how you handle with timeouts and especially timeouts with for example division okay guys how you handle the timeouts when you run rules and got timeouts yes so also we can get timeouts of course it's something that might happen so if we have a timeouts there are two options and either we try to um have more requires and more environment require more invariance so the state will be more simpler for for

the approver so let's say that you want to prove something there are a lot of possible States but if we have many invariants that of course they are correct then it will Narrows out the possible State the realm of possible States but still only the valid States so that helps to narrow out some of the possible inputs and make the approval run faster and prevents times out timeouts and also if if let's say all hope is lost and you try to write all of the environments that you can add and you can also summarize some functions which means that you can use I didn't touch that feature but you can also take a function a solidity function and replace it with civil implementation or CVL a civil

implementation of that function which will run faster in the proverb and then it will make the the times that time out from from the division or from something else to have less likelihood to happen any other questions okay thank you a lot [Applause] foreign

and it will start soon okay

[Music] [Music] thank you [Music]

I'll just ask Ed oh what's the password it's amazing I'll send it again foreign

[Music] foreign [Music]

thank you [Music] [Music]

foreign foreign [Music] [Music]

foreign foreign [Music] [Music] [Music]

foreign [Music] [Music] foreign

[Music] [Music] thank you [Music] [Music]

my check it's working you go ready hey folks uh welcome to my talk hello now we'll be talk from madid Gupta from polygon thank you uh thanks for the intro so hey everyone I am Motel Gupta I lead security and smart contracts at polygon and if anyone doesn't know polygon works on scaling ethereum we are building layer 2 Solutions powered by ZK uh Tech and validium to scale up ethereum today I'm gonna talk a little bit about how to hack a D5 protocol and obviously

how to protect yourself from those attack vectors I'll demo it as well with uh perhaps the most famous hack the Dow hack where it all started really and then if we have time I'll let anyone propose their code that we can do live testing on so if you any any of you have written any code recently keep it ready so to get started uh let's talk about what makes a D5 protocol and what the weak points are so there are really two Pathways to attack a D5 protocol one is the Smart contracts uh themselves and the other part is the traditional security side so before I move on one

thing like I was gonna have slides but my dog ate my slide so no slides for now so I'll go ahead without slides and I'll cover both parts a little bit the traditional side and the non-traditional side day trading from when I say tradition I mean web 2 and non-traditional is web 3. traditional side is something which has been overlooked in this space a lot but we see like The Bigs hacks hacks that are happening are more on the traditional side than the web 3 side a good solid example would be multi-chain which like they literally released their story today if anyone hasn't read their tweet it's hilarious go ahead and read it read

it the etldr is that multi-chain claimed to be an MPC bridging protocol but turns out all the MPC nodes were running in this one guys Cloud Server so it was basically one guy running multiple nodes and then that guy got picked up by the Chinese government the team lost contact with it and they had no idea what to do uh with the servers now so this guy's sister steps in and handles them but then the Chinese not the Chinese government someone moved funds from the protocol to some other address allegedly the Chinese government since that guy is under their control and then this sister tried to White hack

it and got into the into his uh into the brother's laptop opened their cloud account or whatever and move the funds somewhere else uh surprise what next day the sister goes missing as well apparently picked up and now all of the money is gone and nobody has no idea where the money is you can guess where the money is but it's an interesting story of a bunch of failures if we go down they failed at multiple steps one the first step is firstly why did an MPC protocol had all of their servers in one single guy's account so that's one traditional security failure has nothing to do with blockchains then the other failure is why did that guy's sister have access to

their computer like great object like you are securing millions of dollars and just your random family member can access everything uh then their like emergency response plan or whatever uh system moves funds to her own address voila like how successful that was uh she also gets picked up so bunch of cascading failures there but moving on from there other attacks in the space the big ones the Ronin Bridge attack another uh traditional attack which was Ronin was another Bridge a multi-party bridge but they were a five by nine multisig basically not a multi-stick but a five by nine MPC protocol the problem with them was similar four of those five

were running on basically one uh Center one server or one collection of servers and those servers had access to the fifth server for whatever reason so the attacker only compromised one devops employee of that company who had access to all the four servers and those four servers had access to the fifth server and voila everything on again there are many traditional security failures here one is four servers on the same uh like Cloud account or whatever and then second Vector would be four servers having access to the fifth server then the server has been accessible by a devops employee and then the devops employee following pray to these

phishing attacks another traditional security failure and a bunch of these so a collection of these traditional security failures led to these hacks if any one of the levels would have been fine they would have been fine security is all about having layers of security so those are some examples of radiation now we'll move to some more blockchain site where it is mainly things on the blockchain itself on the smart contract side you manipulate the smart contract to do what you want and voila you have free money so not free but almost free money uh there are numerous examples of these as well the one of the biggest ones uh recently that happened was Nomad Bridge

so Bridge seems to be a good team here a lot of bridges getting hacked these days but Nomad had uh logic issue in that a bug that got slipped uh during Audits and that led to an hack uh unfortunately we don't have much time to go into the details of that but similarly another big one that happened recently was Euler so uh Avila was oil is not a bridge so that's something unique about them but what Euler did was they added a function which is arguably not as useful to the code to increase the functionality but guess what that function had a critical bug so some key lessons here one is like if you're working with smart contracts and big chunks of money avoid changing

code and avoid adding features that maybe are not necessary uh because these features may end up resulting in hacks like this Euler did six audits but they still got wrecked and the reason is like one first of all these upgrades maybe were not necessary they were taking additional risk every upgrade you do is additional risk but also the fact that despite six audits overall there was only one audit done on the final code on the last upgrade so saying six audit it's maybe a misleading word like only one company audited the buggy code and it's very easy to slip through so those are some examples but now let's imagine from our scenario as an attacker

how would you attack this so uh if you're going the traditional Parts there are like a bunch of guidelines and tutorials already uh you would probably start with finding attack vectors you can attack so centralized point of failures it might be multi said keyholders it might be MPC servers it might be hot servers holding keys for exchanges something like that and then you would probably try to go do fishing that is the most easy attack path right now uh so uh for on the counter you you should do fishing awareness training for your employees so then don't fall prey for it but you would likely go down a fishing route or a social engineering route you can also try pen testing uh the regular good old stuff getting into

the server but most these days that path is usually usually closed off so you have to go the social Parts humans are really the weakest link in security you can secure company uterus reliably securing humans reliably is super hard just get them drunk and it's game over so that's very hard part which you would attack but now let's also move a Step Beyond uh let's get into the D5 things let's get into the web 3 stuff which is arguably more interesting and arguably more accessible um and easier if you just have the right knowledge and you are looking at the right place at the right time you can do

it and similarly like from a security point of view from the reverse people have to understand that as a security person I have to get it right every single time I can't let any bug go through any of my things but as a as an attacker I only need to attack one weak point I only care about one so although from a security person I have to make sure I secure every single bit the attacker only has to look at the critical pieces and exploit what they can they don't need to go through the whole piece and that's the main strategy both to doing audits to prevent these attacks and also to attacking a protocol if you start auditing a whole protocol

if you want to attack it you won't make it uh so far you just need to focus on the key bits um I think I'll showcase it with a live demo if I can figure out how to exit the full screen I know I press something else okay anyone knows how to exit full screen on Mac or switch tabs anyone anyone anyone okay no search open and not this one

now I have full screen I don't know maybe a functional and I clearly don't use Mac I'm a Linux guy oh we got it thanks okay we won't go full screen this time we'll stay here so this is the Dao repo original contracts that got wrecked we'll go through these have been a long time since I looked at this code so bear with me but let's go through it so if you are trying to attack uh any smart contract really what you will do is first of all open the service code if it's available which it is here and then we'll go through uh the code

and look for most critical pieces so first of all I'm just glancing through the code for some highlights and make sure I'm at the right file and once I verify that I'm on the right file it seems like it big enough code should be the right pace uh and like basically you have all of this code here uh you can from an attacker perspective so I'm really now looking at this from an attacker's perspective I don't know anything about this code base let's say so I look at the source code I find the most interesting file I open it and then what I find for is value transfer where is value being transferred so to find that you look for a few things in D5

smart or solidity smart contracts one is the transfer function which literally means transfer value one would be the send function in solidity which transfers ether one would be the dot call function in solidity which makes arbitrary call and can also pass ether one would be approve function which is used in erc20s and so on so these are the critical points um from where we'll walk backwards so we'll let's start finding these things and if I can find how to search for it okay I found it yes um so let's go with uh dot transfer okay this is a different keyboard than qwerty

okay so let me also add okay I can't find the opening braces so we'll search through this okay there's one transfer function here which is sending it it is taking tokens from the user and sending it to zero so that's not very useful for us we want to take the uh we want the contract to send us the tokens not not send itself the tokens so we'll move forward same thing this is an internal function we'll skip over uh super transfer not very useful no no no so basically as an attacker that's what you do you go through uh

these pieces just looking at where the value is being transferred and so far I've been through the whole contract transfer is not transferring any value so I'll go with call next go really fast if I could find the opening braces but [Music] um okay not good okay this one is interesting so this one obviously transfers value of P amount uh to the recipient now this is one value transfer and all let's notice where it's happening it's happening and execute proposal so um I guess so one thing you should also

do which I didn't do is if you are trying to attack something read like a brief overview of the of what the contract does so you know what you are looking for and what is the expected functionality the Dao as name suggests is um was uh it has features of governance it's an autonomous Dao so it has features like executing a proposal proposing a proposal and things like that so this is proposal execution this is uh definitely one way to attack it but a proposal if it has to be executed it needs to pass through governance so uh governance will need to approve this and then only then we can get funds from it so if if I have to exploit this I will go start now I found a one Value Place now I'll keep walking backwards

now how can I execute this value transfer by having the vote pass how to get the vote pass uh get the governance through it so I will start looking into how can I manipulate the governance to get my votes here most likely in this scenario I will not end up as a positive result because we have knowledge that this was not the attack Victor that was used on the Dow so I won't spend much time here but I would have gone reverse from here if I was actually looking for an attack to see if there is any path I can enter and then walk back down so we'll go to the next call this is withdraw this is interesting I'll come back to this but let's see what else we

have we have new contract uh new contract is not too interesting either because this is blocked here so withdraw is the most interesting bit so withdraw is used by token holders to withdraw their funds and we know uh this was the attack Vector that was used to hacked it out so we have some pre-existing knowledge but we'll follow the same process now we found a value value transfer in the contract one critical bit and we know if we we can break this we will have our funds let me figure out if I can zoom in this screen probably not

so we'll stick around okay I found it I think I think that's open maybe this way yeah it's fine okay it won't hopefully people can see it now you can go maybe one more okay so withdraw is the most important bit we found the value transfer here so what this line says is uh transfer all money transfer this much amount of money to the user that's all it does now

we see like how is this money coming where is this money coming from so it's uh the money is coming from your balancer user needs to have an actual balance and then Pro rata based on their balance they get the balance out of the contract so if I hold five shares or five balance then actual balance by total Supply so basically you can imagine like I get my balance back from this contract simplifying it so it checks for your balance and then sends you the money uh this line not uh very useful we can ignore uh we are we assume we are not blocked by the voting so uh now you have to have some solidity knowledge as well uh to find these issues uh which is a precursor if you

want to get into D5 but once you have the basic knowledge you can see something that is wrong here you'll only see it if you know what call does and what call does is is it passes over the execution flow to the uh coli so message sender here I'm making a call to the message sender that hey knock knock here are your funds and now you do whatever you want with these funds in most cases and in the expected case here the person or the message sender will take the funds and say okay thanks for the funds now you can do whatever you want I don't want to do anything else with these that's the expected use case but what this message sender can also do is be

malicious so it can when it gets the call and it gets the fund uh it will say okay thanks for refunds and I have the control now you can go buy and now since I have the control it will go back to this contract called the withdraw function again and uh innocently go there uh knock the bank and say hey I have this balance can you give me the money I hold and the bank would go here check hey okay this guy has some balance here here's your money go and then you'll get the money you'll get the control you'll go back to the bank again maybe to a different branch knock again say hey I have balance in your bank can you give me the money and uh the uh like cashier would be like okay let me check

your balance okay you have some balance here's your money go and the issue here if you have seen is the bank is not updating the user's balance it's just giving it the giving them the money uh here they do update the balance but they updated down here later uh balance message and equal to zero so they do update it but they update it after giving the money to the user so you have this uh like weird Edge case in between weird time in between where you have already gotten the money from the contract or from the bank but the information hasn't been propagated uh to other places yet the other branches of the bank don't know this yet so you you are basically exploiting it by

re-entrancing you take the funds once you get the control you go back to the contract you ask for funds again and the contract will give you again because it doesn't know that it hasn't updated its state yet the information has not been processed yet um it's like a concurrency problem in web 3 of in web 2 world uh if you do it in a bank it won't work as soon as you take out money all of the branches of the banks will know okay your balance has reduced they'll reduce it before giving you the money maybe make you wait two days before giving you the money but they'll reduce it first uh which we failed to do here we give the money first and then we're like okay we trust the user we'll reduce it where is he gonna run but yeah he ran back to us

took more money so this is one practical example and one specific bug you can look up in D5 smart contracts just start looking for Value transfer go back from it how did this value transfer happen and try to hijack the process at any stage if you can hijack here or the parent function or the parent function doesn't matter once you hijack you just follow the path and you take the money out so this is how you start now imagine like this doesn't work like I go through everything none of the these uh like value transfers are really exploitable so what do you do then then you have two choices either move to the next Target there are plenty

of fishes in the sea or you go deeper now when you go deeper so yeah the first stage the value transfers you have verified they are all fine the second you would do is uh try to see where it's integrating where the external input is coming and try to attack that so if it's a uh D5 protocol which may be using oracles see we can Target that and do some price manipulation you can do maybe uh like a uni Pool price manipulation sandwich attacks and things like that so you go a Step Beyond if you can't find a hack here you go one step um overboard and you try to manipulate A system that this uh protocol is depending on and it has wrong

assumptions about that system and if that doesn't work out then you probably have to do a full audit if you still want to attack this or you can go for a different contract obviously we are talking about bug bounties we are finding bug bounties here there is no hack we are suggesting so you'll just open E Minify find the other protocol and try to find a bug Bounty there so that's uh the Dow hack and one practical example now do I have time I have a few minutes anyone has any contract of theirs that they want me to go live okay that is too big to go live uh in 10 minutes any simpler one I would say

not really so maybe I can just talk about the polygon Bridge a little bit since you brought it up and not maybe the polygon Bridge I'll talk about bridges in general because that's a very interesting topic and we see Bridges keep getting hacked again and again and again and again so it's clearly something people haven't figured out how to do properly not everyone at least so in bridges I really see them uh that they are of three types one is a decentralized bridge which derives its security from the parent chain so a bridge basically Bridges token from chain a to chain B and in most cases there would be a major chain chain a and a child chain chain B like uh if you talk about polygon Z KVM the major chain

is ethereum and the child chain ZK AVM uh which is a layer two so a decentralized bridge that we have here derives its security from uh ethereum completely the only two ways to attack it is either find a code vulnerability a logic vulnerability or just attack ethereum so the way it works in broad sense is that you generate proofs of something happening on one chain and then you verify those proofs all automatically on the other chain and once you verify that I moved my token to the bridge contract on the parent chain then the child contract here can release tokens so it's it's all proof based you

have a proof something happened on chain a if it can be proven on chain B it will give you the funds so there is no centralization risk no centralized party you can generate your own proofs you can submit your own proofs and so on the only possible bug vectors here are really like attacking ethereum let's say is a hypo and is assumed to be not possible right now so the only attack Vector that remains here is implementation risk if there is a bug in the smart contracts which can exploit this which is a very valid issue so you have to be careful about it but these are generally believed to be the most secure Bridges and good example as I mentioned is the polygon ckvm

Bridge here the other type the second type of bridges are the MPC Bridges the multi-party compute Bridges here usually there is a set of nodes which uh pass message from one chain to another and if majority of the nodes agree then the message is bridged uh here like the nodes can be in config of two by three like the harmony Bridge which got wrecked uh like five by nine uh like the Ronin Bridge which got hugged uh like multi-chain which I would say one by one which again got hacked and so on so there are like these MPC protocols and the way they work is you do transaction on one chain these nodes look at the

transaction they are running uh the nodes of these genes and they once a transaction happens they post it on the second chain they say hey this one transaction happened on there so we should do the corresponding bridging if enough nodes post the same message then it's actually executed and the bridging happens so it's basically a voting mechanism in theory it can also be secure for two reasons one is technically it's easier to implement than the decentralized bridge so the risk of smart contract uh hack here is lower and as we have seen the MPC bridges that have been hacked have mostly been hacked via the traditional exercises the smart contract hacks have not really affected them

because it's relatively easy thing to build uh so on the traditional side uh obviously if you do a two by three like MPC or if you do a five by nine MPC if you do a one by one MPC it's not secure you need to go higher uh polygon POS Bridge is a mix between MPC bridge and a decentralized bridge in the sense that there still are proofs but they are mess the message passing happens in an MPC layer and for that we have 100 validators uh not one three or nine so there are many uh decentralized validators and we are not the ones that are running all of these validators they are run by the public in a decentralized fashion so that's a much more secure and

harder to break away so that's one type of bridge in this bridge the attacking vectors are really the traditional side if you can break the MPC if you can get into the servers that are running these nodes it's all yours and this is what we have seen in the past so if you are running a bridge of this type make sure you pay attention to your traditional security make sure your key management is secure make sure you have a high ratio of MPC and then you would likely be fine the third type of bridges are really the centralized ones which are like just one entity for example you put money in binance on orbitrum and you withdrawing on ethereum you have essentially Bridge money from arbitrum to ethereum but you used a

centralized Bridge which was balanced uh here all of the security depends on the traditional security practices of Finance Key Management hot hot wallets and so on there is no smart contract involved it's all traditional security another so another example of this would be the Avalanche Bridge actually Avalanche bridge is an eoa actually it has no on-chain multisig or anything um it's one by one eoi but off chain they have an MPC algorithm which is I think three by four or four by four so arguably not sufficient but at least something and they do it on Intel STX so it's uh it's relatively secure Tech wise although they can bump up the MPC

numbers and that would be really appreciate if anyone from Avalanches healing so those are decentralized bridges I would say if you want to attack those or if you want to secure those then again you have to focus on traditional security 100 make sure your key management is safe make sure you are not storing secrets and plain text on your hot servers running in some devops account make sure access to those servers is also secure make sure your devops employees are properly trained for fishing awareness and things like that so you don't get tricked and these are basically like the three types of bridges and three different security mechanism there for the decentralized bridges just make sure your application

is secure get a bunch of audits get bug bounties live get these audit contests done by Sherlock code Arena and these companies get a lot of independent reviewers look at it uh have a lot of fuzzing let you can try for formal verification using Satora but most importantly just have an open security mindset and have good test cases most of the things can be caught by test cases honestly I'm just having an open mind then the other side uh the middle layer where you have traditional security as well as smart contracts you have to do both so these are the bridges that most often get hacked you have to be secure on these smart contracts which is

relatively easy to do and you have to be secure on this uh traditional security side the only saving grace here is that it's all very common very documented there are known best practices so you can just follow the best practices and be done with it and the first one did centralized Bridges like maybe just stop building them if you are building them then make sure your traditional security is fine and then you'll be fine it will all be happy we'll all be happy no more hacks and we'll all live happily after and that was a quick short talk if anyone wants to reach out to me then they can reach out my contact details

are on my blog modet dot blog I can find the letters here but you get the idea oh I managed to type it not right still but yes you can contact me through my blog and happy to talk thanks everyone thank you any questions [Applause] anything anything about attacking a D5 Bridge D5 protocol or security or polygon anything that we don't do we keep it there thanks for the great

talk my question was also uh on chain attacks on Bridges like Nova protocol for instance yes the issue was synchronization of Merkel root yeah on either side so how do you try to model that also into account yeah so that would fall in the uh like decentralized Bridges category so it's more a smart contract risk slash software risk if there is a buggy software then obviously you are going to lose money and it's super complex to actually build and secure these Bridges which people underestimate and say like decentralized bridges are the best guess in theory they are the best but they are also the hardest to secure from a code point of view so that's why I said you need a

good developers who understand security and will build this thing ground up with security in mind you need them to write good test cases you want fuzzing in there you want to get in some formal verification if you can although it's hard for these complex cases you want to do good audits with reputable vendors you want a good bug Bounty program polygon has a very successful bug Bounty program we offer bounties of over a million dollar and we have had very very very interesting findings through that which all Auditors missed so yeah just those are the ways to secure it so just a follow-up question uh in case you said Euler example that adding another function creates this security Threat

Vector how can we modelize in real time let's say we want to change the protocol using a new proposal how can we modalize it is there possibility to let's say there is formal verification other aspects yeah so a couple of things there one is like uh if you have to do it then there are ways uh like for continuous integration one is obviously your test cases uh should all always be passing if you go formal verification route with Satora you can have the same rules be verified every time and um like you just get audits ideally from the same people so have the whole context but in the first place to

be honest you would try to not upgrade a contract unless it's absolutely mandatory so upgradability is a double-edged sword I like upgradability because it allows you to get out of sticky situation if you find a bug in a contract you can upgrade it you can save your life but I don't like upgradability when it's used to add a new tiny feature then it it's always about risk management whenever you add a feature you're taking on risk and you have to ask yourself is that feature worth the additional risk or not often times at least for me it might not be worth the risk hi there um my question is concerning the future of like what's next

um a few years ago we had cross-atomic swaps now we have the new innovation of bridges what in your opinion it's going to be so groundbreaking that comes in the next few years yeah sure so that's a very big question for me there are two things here one is like I I really believe in a multi-chain future not the protocol but multi-chain in the sense there are many different independent genes that will live at the same time but I do not really believe in a cross chain future I don't think uh people will be moving funds uh like doing transactions on Two Chains atomically I'm not a big fan of that just because the because of the complexity of that and I like to compare this with the real

world so there are many I like to think of chains As Cities there are many major cities in the world right now and you can go from one city to another using a flight or maybe a bridge age if they are close enough so you can there it's a multi-city world you can go across different cities but you can't have your leg in Two Cities at the same time it's just not possible it's super complex so I like to think of it as analogy I use and the other thing I'm really bullish on and I think it's gonna be big is uh ZK uh scaling technology because scaling is a big bottleneck for our take to grow if we can solve this we will immediately have lots of new interesting use cases

that are just not viable right now because it's too expensive if you look at internet internet was never free internet is still not free but it's affordable enough that nobody cares how much it's costing every time you open a web page the website host is paying money to their web host to serve you the page the data on internet still costs money but nobody cares every website is free to browse every user has an internet pack they don't pay per website visit or anything like that just because it's so cheap that it can be bundled together and that's where I think ZK Tech will take us the transactions would be so cheap that everyone would would just use blockchains without worrying about costs

for your talk and uh now is uh time for our next speaker [Applause] um it occurred to Barry with the talk can code be trusted all right everybody give me a minute to figure out the setup here actually I can put it on this side let's see I'm just trying to figure out

all right just change some display settings here one second mirror all right that worked all right so here we are I guess I'll briefly introduce myself um I'm Kurt Berry currently just an independent security researcher doing Audits and such um I did spend four years as a core protocol debit maker Dao where I led most things related to security um so I guess that's that's why I'm here

to talk at you today I'll talk to you I feel if you have a question feel free to put your hand up even during the talk but we'll have time at the end too and so I'm going to start a bit philosophically so can code be trusted and first let's motivate you know why is that an interesting question so the whole crypto space is founded on you know not trusting things that aren't code right like this is the headline that's referenced in the Genesis block of Bitcoin um you know alluding to you know the kind of unfairness of the existing Financial system where arbitrary decisions are are made by people that you know many people who are affected by them you know don't have really a lot of

input too and so you know if these things like trust code not Central Bankers code is law I mean we all know how that one's been going of course but you know the web 3 has really founded on the idea of you're going to trust the code and not something else um and the question is broader than that too because you know software is beginning to underpin all aspects of Our Lives you know like when you fly on an airplane that airplane is actually mostly flown by software these days the pilots have very little they have to do manually and in fact you know in the military they often just fly planes you know just completely automated but you know regulations prevent that for uh

consumer things but but can we trust all that code right it's it's everywhere around us and as you might imagine this question has been asked before and I'm assuming most people have probably read this essay at some point so this is uh Ken Thompson inventor of Unix and didn't any other computer science things and he has this great essay well it's actually a his Turing Award acceptance talk Reflections on trusting trust and let me just remind you or describe to you for the first time sort of very tricky things he described about why it's hard to trust code I won't go through the whole thing because that would take too long but the

core idea is this is that compilers are often written in the language that they compile you know for example like the C compiler will be written in C and so you can insert this undetectable back door into the compiler binary as follows you have basically two if statements one that's going to be you know inserting a back door into some Target program you know think like the Unix login shell or something and then you'll also have an if statement that's inserting this back door into the compiler and you know this is a little tricky to do but it turns out it's possible right because basically because you can write programs that output themselves that's a possible thing to do

and so if you have the this version of the compiler you feed it into a non-malicious compiler binary it's going to spit out a different compiler binary that will always insert the back door even when you take the back doors out of the source code right so it's just got this you know really pernicious property that unless you're like actually disassembling the compiler bytecode and figuring out that it's you know doing this back door thing in special cases you know this is just sort of propagate and even if it's compiling non-malicious source code you know it's producing malicious things and you say well is this even relevant like to like defy you know like solidity uh you know uh solidity compiler is not written in

solidity yet you know maybe someday but let me just give another thing to think about the go compiler is actually written and go right and you know go ethereum is the most common execution environment so right what if you're what if your target like you know is Geth and then you know you can imagine it's like well when a very particular address uh interacts with like some smart contract system just give them all the funds or meant that address infinite eth and this can be sitting out there living on the nodes and even if you've you know tested formally verified audited etc etc your uh smart contract you know the notes could be compromised

and you can have problems in any number of other layers of the stack right um so I and actually just this is a fun trivia Ken Thompson actually was hired by Google and worked on go so like maybe he's decided to to do his trick I I should mention that original his original essay kind of concludes by like well it's really really hard to trust code so maybe you still have to trust people um and he actually had a lot of things like calling for like prosecution of hackers in there and anyway it's an interesting historical thing to read um if you haven't but the Inconvenient Truth is that you don't really even need fancy Trojan

Horse compiler binary supply chain attacks to have difficulty trusting code because we programmers just write bugs all the time right it happens right so so can you trust code and the problem you face is you know you want to produce a reliable system from unreliable components nothing has a zero percent failure rate programmers compilers blockchain clients the software the physical infrastructure right it can all fail and so what you need to mitigate all these different hazards you need multiple orthogonal techniques um where you're it's like these layers of Swiss cheese each one is imperfect

but if you get enough of them lined up you can get the risk you know as low as you want um and so for example if we were really truly worried about a go ethereum Trojan Horse there are a bunch of things that you know can get in the way of that one is just the compiler supply chain if you think about this would be pretty hard to actually pull off in practice um you know especially like in an open source environment um you know you basically have to find a way to start Distributing your your compiler binary like you probably do it but it would take some effort all right and then we have redundancy of like there are multiple client implementations and not all of them are written and go right so now you have to attack all the clients they're like really you know

durably you know break the network assuming not everyone is running the same one um you know you can actually do fuzz testing even symbolic execution of the goatherium client and see like oh is it correct right like because you know this is redundancy right you're using something that's you know written in some other language or it's at least not backdoored and you can see that you can use that to get some more confidence and then ultimately there's like the social layer fall back that will deter and attempt to execute this attack because you know there'd be a very concerted effort to find and punish the malicious actor and you know okay it's it's not code but it is a thing that contributes to safety like you can't ignore the social layer because ultimately like the code even if we're trusting the code

we're all agreeing to trust the code right you know you can't escape that at the end of the day so you know my personal take on this as well you can never trust code completely you can get close enough in most practical situations and depending obviously on the criticality of the application you need more and more effort to get close enough and so the the really interesting question though is like how and this is the part where I'll get a little defy specific I I realize I'll probably say a lot of things that were said earlier today but I'm going to try to say it all like at once and hopefully that's beneficial because a big challenge I observe in this space is you know developers come in and they

don't have like experience with critical software components they're used to like web services or something and where you make a mistake find some 500s reserved just ship a new version and and everything's good but here it's like you know once you deploy your code is in some cases completely immutable in other cases very hard to change and you know it only takes one hack to have an irreversible you know multi-billion dollar loss and so you know it's really all in like the mindset and the processes and putting it all together into a complete package right there's there is no like Silver Bullet right like you've heard about formal verification today and that's great but it's not the only thing you need right

so forgive me a little bit for being a little bit playing with words a bit and abusing terminology to make this pyramid but I wanted to have a pyramid because I think it helps kind of conceptualize what's the most important part and at the very bottom I'm putting like philosophy which is by which I mean your mindset towards the code above that comes processes then I've put testing as its own thing although you could argue testing is a process too but testing is you know it's such a big topic it deserves its own place above that I'm putting what I call verification which I'm going to basically that's where some of the abuse of of word language comes in here

some of some of the things in verification some people might argue are really testing but for me it's like kind of the testing that I'm referring to with testing is testing that happens during development and this is verification of like the code is basically done we think we've tested it and now we're going to make sure you know it really does what we think it should do and then finally there's this operational step because once code is deployed you know it's not risk-free even though you've hopefully reduced the risk and you need to be monitoring it and responding to issues so let's go through these a little bit all right so the philosophies you know how are you approaching software development right what's your mindset um you know how are you thinking about the problem so for one thing you need to know your trade-offs right web3 it's

hard to upgrade hard to recover from incidents and so that means you know you need to have that in mind from the start you need to be modeling your threats you know what what's in scope like if you're a smart contract developer maybe you're like it's not my job to defend against the you know compiler uh Geth Trojan Horse all right like I'm just going to assume that the other things that we talked about are going to take care of that you know like like what do you want to prevent um you know you want to prevent funds from being stolen you want to be preventing funds from being locked et cetera uh I like to emphasize the safety first mindset I say safety not security because safety is a superset of security right like security means there's a malicious hacker you know doing

something bad but smart contracts can have bugs that just make funds get locked no hacker needed and users care just as much you know no matter how they lose the money right and that's what really matters um I'd like to emphasize here every defy project should have at least someone focused on Safety and Security right if if there's one founder that's you if there's like a non-technical and Technical founder it's the technical co-founder right if there's one engineer that engineer is also that you know the person who owns security right it's it's not a separate function it's part of the job and you know another philosophy that I've kind of touched on already is like the risk never goes to zero although it can get lower with time and usage right if you have a contract that's not changing

and it's got a lot of tvl the more it's longer it sits there and doesn't get hacked you know that increases your confidence in it that's nice but confidence never really goes to 100 you know ossification is a goal I think in web three you know ever like we did just said at the end of his talk every time you upgrade something that's a risk and you want to not do that and ideally you eventually stop although you know different applications have different needs and you know a big one that is kind of very specific to code is preferring locality and minimizing dependencies because every dependency you have is something else that can go wrong every non-locality by which I mean like you have to go to some other function in some other file and for them from there you have to go to some other functions

of other file makes it harder to understand the code and so having code that's easy to understand maybe that's the real principle that's how I should have phrase this like make the code as easy to understand as possible because you know ultimately that's going to make it easier for you to find bugs or not write them in the first place all right so moving up the pyramids you know now you have your processes and so how do you actually do the development that now that you know how you're approaching it so you should really start with kind of a specification of the system prior to implementation and you know depending on what it is maybe this is just a natural language paragraph maybe it's a full formal spec that you can use later to do formal verification but but either way you want to have some some level of

intent and know what you're trying to achieve before you start because otherwise you may make some mistakes and have to go back and do it all again um code review is obviously a critical process you know at maker we use kind of like the four eyes principle of you know two people have to sign off on every PR you can do something different but you know you should as a metric probably be spending more time reviewing code than writing code in web3 checklists are are great I know they're very boring but they're great and you should use them so post-mortems right when something goes wrong doing an analysis of it deciding what you know how you can improve your process so you have a process Improvement feedback loop right that's critical

I'm red teaming where you take someone from your team or even outside to really try to adversarially think about the code is a great process to have and then like phased or gradual rollouts are another good process to practice you know like how do you deploy do you just like let things ramp up to Max tvl immediately or do you know a hundred thousand a million you know Etc all right so then moving up to testing all right so first of all like full unit test code coverage is basically table Stakes right you should know your code paths you know list them out make a finite State Machine model or control flow graph whatever you have to do and just make sure you're testing every code

path right like you you wouldn't believe how easy it is to miss them if you aren't like attentive to it if you're integrating with deployed contracts which is very common you know all good development Frameworks support RPC tests where you can actually test the integration with the Live code and even live state of the blockchain and you know do that too uh and and then a good thing with testing is to Define and test system level properties not just individual function behaviors you know this connects to what I mentioned earlier about having a specification right so the specification is good it might already spit out some properties for you to test and then those properties can feed through into later stages of say formal verification I'm including fuzzing here with testing

if you do it correctly it's extremely powerful and it's the nice thing about it is like it's it's tractable for pretty much anything you know some sometimes if you have very very complicated code it'd be hard to formally verify you know the tools might have timeouts or something but you know fuzzing um you know you have to be smart about shaping the inputs for example to get good results from it sometimes but you know I I think it's really an underutilized tool actually especially for like mathematical routines um respond very well to fuzzing and there are a lot of those in defy another thing with testing is you should just always mutate your code maybe manually or using automation if you can and just make sure the tests actually

fail like you know even someone like me who's been writing code for you know quite a while an embarrassing length of time you know I'll write a test and then I'll go change the code and well the test still passes right um you know if it can happen to me it can happen to you so and if you can have automated mutation testing like that's even better but you know this is just a basic you know hygiene thing make sure your tests actually test things which relatedly you know you should have code when when you have code review code reviewers should look at the test too like don't just assume that someone wrote complete coverage you know look at the test see if you can think of any gaps right because you know sometimes it

might be easier to spot a gap in the tests than to actually see a mistake in the code all right so then moving up so my my slight abuse of language here I apologize for so verification I again think I'm thinking things that act sort of on the system as a whole or when you're basically done with the development process um which formal methods you can actually apply as you go along although that can be a little expensive if you end up changing the code a lot but you know formal verification you know I I think you've heard at least one talk about that today maybe several so I won't beat on it too much but you know it's it's very powerful you know it can find bugs that say are very hard for fuzzling to find if it requires like a very specific

input you know like the classic example of something that formal verification is a good use for I mean just the process of thinking through formally verifying your code is is very valuable economic modeling so this would be like doing numerical simulations of how your system performs um you know under various say path conditions and financial markets um there you can do that yourself in like a spreadsheet or you could get a company like Gauntlet to do it um you know it depends on your needs you don't some of these you know when you get up here to the higher levels of the pyramids you don't necessarily need every one of them for every project so like you don't necessarily need to do economic modeling all the time but it can be really useful all right finally we come to audits which I'm trying to

contribute to changing some terminology in the ecosystem that we should really be calling these reviews or assessments like in fact when I do an audit like and I write a report I actually it says you know assessment not audit because audit is like a specific thing in other contexts where it's really like a checklist and this is more more qualitative thing that doesn't make guarantees but you know you notice audits you know come after all the other stuff which a lot of times audits are the first thing people think of in web3 or Security reviews it's like no you really should have done a lot before that um and if you have really really good code you shouldn't need five audits you know you should need one or two unless you have a really complex system and then maybe it's Justified or

if you have a really big budget as well then just get all the audits why not um so then testnet deployments are great obviously do them you know get users there to to try them I mentioned phased rollouts is like I think a process as well but this is part of this I think verification process of making sure the system works once you've created it so you know whitelisted Alphas gradual usage limit increases Etc all right and now like the very highest level which I actually this one is a central sorry so that's maybe an inconsistency in the pyramid but you've got to mitigate the risk of the code once you've got it deployed so that means having a bug Bounty program so that people are incentivized to tell you about your bugs and not hack you you should be monitoring things if you have parameters

that need to be set you know you need to maybe have controls and procedures around that good documentation um be aware of execution environment changes right on ethereum we have immutable code but mutable semantics uh always fun when like the gas schedule changes and now your hard-coded gas limit doesn't work anymore and potentially more fun things like their their nerfing self-destruct pretty soon you know a sad face and then have a plan for incident response you know you know know how you're going to run the incident I'm not going to go into how you would do that here but you can like look up standard incident response procedures and just use them you know practice them and particularly like know what your upgrade paths are if you have any and if you

have the time and bandwidth you know drills and simulations can be good um now I'm going to give you a little bonus here of my like my favorite anti-pattern you know while I have a soapbox to stand on which is that like using raw ether is it's just like unnecessary in most contexts and and generally worse from a safety perspective um first of all you know there's no re-entrancy that you have to worry about with wrapped ether and if you're also supporting like erc20s anyway if everything is in erc20 you can eliminate an extra code path which is just fewer places for bugs to hide right you lower your overall complexity and you also have more composability with rapid ether there's no such thing as you know approve or transfer from for normal ether which you

do have with rapt ether and everything is erc20 compatible these days now what's the concern okay maybe there's a bug in the wealth contract that's that's super super unlikely I think the West contract is the contract I would probably trust the most on mainnet ethereum right now and yeah okay there's gas overhead but I I think the the benefit of the security and safety benefits of using weft outweigh the gas costs for most applications maybe the one exception is if you have a thing that's truly eat only um and then you say okay well I'm just going to put effort into getting this right so anyway I I think that's the end um and yeah if you have questions or whatever Now's the Time

do you know of any uh Dev tools that could help with the automated mutation to check failing tests not off the top of my head all this someone was mentioning one recently does anyone in the audience know a mutation tool for solidity some back there sorry I can't hear you again Gambit from sartora okay perfect all right yeah I haven't tried that out yet so I'll have to have to take a test of it also Soma how do you spell it oh Sumo Sumo Sumo apparently it's

another tool you can look up all right good crowdsourcing there uh what's a particular upgrade particular upgrades a little less late uh what are they a particular upgrade oh like um what do I mean by this is maybe just a poor choice of words um like I just mean like you might need to upgrade different things in your system differently so like maybe in some cases you'd want to deploy a new contract other cases you have like an upgradable proxy pattern maybe other things are just not upgradable at all and you've got to like shut down or migrate your protocol um yeah not maybe not the best source of words there but hopefully the context

helps uh no question I just want to say there's also a universal mutator anesthetist for a mutation testing so awesome more more options than I ever imagined uh so what about code that is generated for example like you want to do like a CK proof or something right that is

outputted by a tool let's not drag readable right so what do you think about those kind of uh because I you would see a lot more of that going forward what are your thoughts yeah that's a great thing to bring up especially in the context of ZK because there are a lot of interesting things that happen there so with generated code like often you're generating it because it would be too hard to write by hand or it would take too long and so then it comes to be about like trusting the tool and you know I think that means you need the same level of like effort to go into creating those tools that goes into creating you know smart contracts you know maybe even more right like you need mathematicians to like check that the papers match up with the math implementation

um and also that the papers were correct but just as a side there was one time a bug in Z cash where the programmer had perfectly implemented what was in the math paper but there was just a typo in one of the equations right so you've got to be checking that and then you've got a you know you you know like there should be a huge test suite for whatever your you know circuit generator is right and you know maybe that should be fuzzed I don't know if it'd be feasible to formally verify that but you know if it's going to be create if it's going to be producing critical components and those components themselves are like too hard to verify although you should verify them to the extent that you can you know it means that those tools also have to be basically space grade

great question all right yeah if there are no more questions I'll stop standing between you and your evening plans thank you very much thank you very much good so big Applause for cook who's been in this space for quite a long time contributing to make here a bigger close to the other speakers I don't see them here Moody all the best the house love all the rest here a big Applause to this aquarium people the volunteers who are here Rajiv and all the team fantastic job uh for tomorrow uh you have the evening on your own but those of you who do not

have ticket for one or one for the device security Summit we can give you a ticket don't worry we can we you have to register but uh approach UE or the volunteers will get you a free ticket so don't worry if you if you want to come tomorrow come tomorrow but we need to register you and enjoy the evening thanks [Applause] [Music] thank you [Music] thank you

[Music]