Improving Smart Contract Security With Assertions | Jacob Czepluch - Phylax Systems

[Music] all right hey everyone I'm Jacob from filx and I'm the def at philx today I'll talk a little bit about how we can improve smart contract security with assertions so a little bit about who we are we are a small team dedicated to solving security so that crypto can win um and what we're building is the credible security layer which enables DBS um to embed and verify um ver to embed and verifiably enforce uh their rules in the base layer enabling the world to deploy Capital confidently so why should you care um about security um in 2024 we had uh two plus two billion loss to hacks um yes small story usually I never have my slides ready in in like very good time but actually these slides were ready on Thursday um so I had to put in a small edit with the 1.5 billion that was lost on Friday uh and we're not even in March for 2025 yet uh so yeah we're definitely facing some problems with uh Security in this space in general um and a tendency we're seeing is that the amount of hacks is going up so except for the incident with bybit on Friday the amounts are usually a little bit like smaller but there are more hacks which indicates that there are more projects which is a good thing but it also indicates that there are a lot of projects that don't care too much about security so we should definitely fix this this uh some of the ways people usually get their security improved is by audits which is good uh but the problem with audits are are is that they're very expensive and often they are like a oneoff uh event so if you get an audit that's good then a couple months later you upgrade your smart contracts and your audit is basically rendered invalid all right another cool tool is formal verification but it's difficult it's not for everyone it's difficult to to to write and it's difficult to like reason about it and also there is no such thing as perfect code like all code has box so that is just like the hard facts um so what if I told you that you can basically improve your security without paying a lot of money to do it and without uh like learning some obscure formal verification language so that is where the FX credible layer comes into play and how does that work you basically Define what a hack looks like um so you can define a state that you don't want your smart contract to get into and if you get into this state that would be basically um mean that you like have an invalid State and what our software will do it will basically revert or ignore the transaction that would result in this um so we're doing actual hack prevention uh instead of next block mitigation or whatever we have other projects doing we don't have any additional trust assumptions in our system so we are based on uh l2s where you already trust the sequencer so we Implement at the base layer with the sequence uh as part of the block Builder and we basically or we we do simulate all transactions so how it works is uh we take all the transactions that will go go into the next block then offchain we simulate all the transactions then we compare the state after all these transactions and see if any of the transactions would get your smart contract into a state that you do not want and if that is the case we ignore the transaction that would lead to this um state so this is basically How We Do hack prevention um and how do we Define this like how do we Define these hack preventions uh we do that through what we call assertions and assertions are written in like very familiar syntax you write them in solidity uh using our credible STD um Library which basically means you don't have any context switching as a solidity developer it's very familiar you can call the same functions as you already have in your smart contract and you don't need to learn some obscure um language for doing formal verification or whatever what our library includes is a bunch of powerful pre-compiled that allow you to compare State before transactions and after transactions so you could have like um a value before the transaction and then after the transaction you can compare it and if it uh let's say it's a price from an oracle that is going up more than 20% in one transaction then that's probably something is wrong and you could um just ignore that transaction um you can also get all state changes in a call stack for example for um a specific storage slot which can be useful for yeah again detecting price manipulation attack something like that um yeah so you have a bunch of of very powerful tools that you cannot like that you don't have in in in vanilla solidity so to speak um and as I mentioned due to find what a hack looks like and the cool thing about this is you don't have to worry about all the edge cases that could lead to your protocol being hack you just have to know what a hack looks like you can also kind of say like you just have to know the invariance in your code and how you can think about this is as reverse intents so you define a state you don't want to uh get your app into but you don't care about how it actually gets there um and another thing it is not part of your smart contracts so you can deploy them after the fact let's say you deploy your smart contracts and you realize you forgot to add some check to one of your functions or something like that then you can actually add that check with an assertion after the fact and in the same way you could say okay we have an owner of one of our smart contracts we know that we don't we probably will never want to change the owner but in case of emergency we will want to change it and instead of letting all all addresses being like a potential new owner you can Define just one address up front that you know if we ever change the owner it will be changed to this address um so that can kind of prevent that if anyone compromises your multis or your owner address then they can still only change it to one other address that you already control so it's a very good way that you can put some control patterns into your um smart contract as well um so yeah how does it work you have the order flow of trans actions which is sent to the sequencer or builder then we have our side car that runs all these dab rules against the unfinalized transactions uh what I talked about before where we basically simulate all the transactions um and only include then the transaction that pass the rule set that we' have defined with our assertions so what I mentioned a little bit earlier was uh these invariance um so invariance is it's it's very important when you are developing your smart contracts that you have an idea of the invariance that your protocol should always maintain um It's Not A New Concept per se but a lot of people start focusing on this we have this example from two weeks ago from TR trail of bits where they wrote a blog post about uh invariant driven development and why it's so powerful so in general you should always as a smart contract developer you should know what are the invariants of my protocol that I never want to break um this is a very powerful thing to do and a very good exercise to do um but on the other hand it's often quite expensive to always check all your invariants in your solidity code directly um so that's where you can use our assertions to Def find the invariance and make sure they're always enforced without having to have all these expensive checks within your uh smart contracts directly um so yeah basically an assertion could Define an invariant it could be that you never want the C ratio of your lending protocol to go above 75% or something like that and if there would ever be um a contract a transaction that would result in that then it would uh be ignored so yeah that's in general something that you should always think about in your pro protocol is like having good invariants and having them well defined and that is true for all projects um so what does an actual assertion look like it's a CO small code snippet like this in this case this is an example that we could have used to prevent the uler finance hack back in 2023 um what happened was that they introduced a new function called donate into their um into their protocol and this function did not have a health check so it didn't check if uh by donating that some positions got into like deep water or underwater sorry um so if you had an assertion that would always check this for all positions then even if you forgot to add this check uh the transactions that got the positions under water would have still been prevented and the hack wouldn't have taken place so here we have the example of an assertion that just checks for each modified account within a transaction if um the position is still healthy and this could have prevented something like the the uler uh Finance hack and it could also um yeah so I think a good example here is that even if you after the fact introduce some bug then if you have a good invariant in place it will always catch these um mistakes that developers make in a similar way um we have the AA the ability to get State changes uh for all the calls in the call stack so in this case we checking if an oracle uh that is reporting a price has any High deviations within the call stack of a transaction so this could be in the case of a price manipulation attack we can basically see does anything happen within this transaction that looks like the price is being manipulated in this case we check if more than 10% deviation is taking place um and if it is then probably something is wrong and the transaction will be um ignored or reverted so you basically with this you can really get in deep into your protocol and Define things that you never want to happen without worrying about how exactly someone could be manipulating the the prize Oracle okay so where we at at the moment we are just about to uh to start our closed beta round with the N nimian phase um so if you're interested to learn a little bit more come find me after the the talk we're also doing White Glove onboarding at the moment so we want to talk to a lot of protocols and understand what their invariance would be and how we can help them with assertions and as that like for that we would also be happy to to to write some assertions for you if you're interested in exploring this further and we also have a full demo where we can show all the things that that's possible um so if anyone's interested in that please contact me reach out uh yeah so let's solve security basically so uh crypto can win it's super important that we we do better at this I think that's uh all for me please uh reach out if you have any uh questions I would love to get in touch and also if you are skilled rust uh developer we are also hiring at the moment I think that's uh all for me thank you very much [Applause]