Welcome to East to E to E to E to E. So I'm Jacob. I'm the deil at FAC systems and today I'll talk a little bit about how we can or how we try to fix security so that uh crypto can win. Um yeah, so who are we? We're a small team uh dedicated to solving security so crypto can win.
We've most of us has been around have been around in this space for a long time. We've gone through hacks. We've been hacked. We've seen it all. Um decided finally to try to uh to see if we can actually do some improvements on on all of this.
Um so what are we building? Uh we're building the file credible layer which enables DABs to define states that they don't want their uh protocols uh to reach. Um and by that it means that you don't have to worry about the edge cases that can lead to this. Um basically so an example would be you define um like you could have a safe proxy just a small example that's fairly relevant I think um and you can define that you'd ever want the implementation address to change so that's something you can write in a rule and if this rule will be broken by a transaction the transaction that results in that would be ignored basically by the uh block builder. I'll go into more details, but this is like just to give you an idea of what you can do.
So, why should you care about security? Um, basically since 2024, at the beginning of 2024, $3.5 billion um have been lost to hacks of all kinds. Um, we see more and more hacks. um they're not as big um as they used to be with a small exception of uh the the the bybit safe front end hack u which also made this number a fair bit bigger than it was a couple months ago.
Um audits in itself are often oneoff uh and are very expensive and as soon as you change your code just a little bit you should basically get a new audit. So it's it's a it it adds up and gets very expensive over time. Formal verification is difficult. It's like few people who can really do it and you often have to learn a new language for the formal verification. So it's it's not something that anyone can just sit down and and do.
Um and perfect code also doesn't exist. Like I think most of you or all of you probably agree with this or have seen code that you saw thought was perfect and anyway it got hacked somehow. Um so yeah basically we looked at all this and thought what can we do um to change this uh like where it doesn't have to be super expensive and difficult to improve security of your smart contracts. Um and that's how we came up with the credible layer. So in the credible layer you define what a hack looks like as I mentioned earlier.
Um so you basically can think of it a little bit like a reverse intent. you write a rule say I never want this I never want to allow a position in my lending pro protocol to be underwater for example. So if there is a transaction that results in it uh going underwater for some reason this transaction would be reverted. Um this is a already a pretty powerful uh concept. We do actual hack prevention.
So there are a lot of tools out there that allow you to do mitigation. So they can say okay there was a hack this protocol has now been been been drained or whatever and now we execute a transaction on behalf of this protocol pausing the pausing the protocol or there are even protocols that would do front running on your behalf. So if they see that there's a transaction that would hack your protocol, they would frontr run and do the hack themselves, so to speak, um, and then pay back the the the funds, but it still means that the protocol was hacked and it doesn't look good for the user that their funds were actually lost for a period of time until the funds were returned. So you really want to have hack prevention and not mitigation. um our solution is currently on uh L2s because um it's much easier to uh build what we're building if you can use um like already centralized sequences.
So we kind of like rely on the trust that people already have in these centralized uh sequences. Um how it works a little bit more in depth is that we for each um new block we fork the state of the chain run all the incoming transactions against the the the state of the chain and then we see if any of the transactions violate any of these rules and if there is a transaction that does this we ignore this transaction and it won't be included by the by the builder. So basically how do we do this? We do it with what we call assertions. Um, assertions are written in solidity.
Uh, and we use like a a small library called the credible std. Um, and there's basically no context switching or obscure languages needed. You can just like write it in solidity. It's pretty much in the same way as you write tests in Foundry. We have some additional cheat codes um that allow you for example to iterate through all uh calls in the call stack.
So you can say okay I will I want all changes to this storage slot in the entire call stack which can be useful for price manipula or detecting price manipulation attacks for example you can compare states pre and post state um pre and post execution you can get all call inputs um I'll show you a little bit more about the G-codes later uh as I mentioned you define what a hack uh looks like so something you never want to happen um and additionally something I think is very important important is that um these assertions are deployed independently. So it's not you don't need to have them written uh as part of your smart contracts. You can add them after the fact. So for example, you deploy your contracts your protocol and you find out oh there's actually a small like buck or a small edge case that you could get into. Um you can just you can deploy an assertion to cover this specific edge case and you don't have to redeploy your entire protocol for example.
Um, and you can also remove these assertions later on if you uh find out that they're not necessary or something like that. But it's it's a very powerful concept that you can do this in like a modeler kind of a way. Um, and it also means that all the protocols you already have deployed can can add assertions to them. Um, yeah. So how it works?
I explained a little bit before. Basically, you have all the transactions coming in the sequencer builder look at all these and run the the the rules against the the unfinalized transactions and only include the transactions that pass the the rule set basically. So, it's fairly um simple. Do I actually have a timer somewhere? Okay.
Okay. But I don't know when I started anyway. Um yeah. So another concept I think that is getting more more traction at the moment is invariance for your protocol. Um this was a couple months ago by tri of trade of bits that they wrote um like why invariant driven development is is a powerful um thing to do.
Um it's a very very good exercise to do for any smart contract developer. Sit down define the invariance for for your protocol. Um, if nothing else, then you'll probably find out what is like the important uh things to to to to like keep keep an eye out for in your protocol. But I found out um when I started looking into this more that there are quite a lot of projects that at least not publicly have their invarants um defined. So I think that's definitely something that's worth looking into.
And as late as yesterday, I I saw a discussion on Twitter with like uh Consta from Ref and uh Daniel from Extrafi. Um they were also talking about like how important invariant uh invariants are, but it's very difficult to actually define them in a in a good and precise way. But anyway, you can definitely you should do this and it's quite convenient to implement your invariants in assertions to make sure that they're always true for your protocol. And as I mentioned with cheat code, you can actually do some of this um which you cannot do in regular solidity um as you will see very soon. So what does the the credible layer um consist of?
We have the credible standard library that you use for writing assertions and writing tests for these assertions. So we have the PCL which is our command line tool that allows you to authenticate for the DAB and you use it for running the test and you use it for storing and submitting assertions. And then we have the DAB which allows you to create projects for your assertions as well as linking assertions to um a smart contract that you're monitoring um or that is part of your project and only the owner uh or some other wise defined admin of um a contract can actually add assertions to it. That's a very important small detail. Um otherwise you could just break different uh protocols easily.
Um and the last one is we are also building what we call a transparency dashboard. So you can go and see all the projects that actually have assertions defined. Um and that way you can quickly get an idea of how secure is a specific protocol before you put uh your life savings into it as an example. Um so we try to build this to make it more like transparent which projects have like good assertions defined um etc. Then a little bit about the the different cheat codes we have.
Um so you can basically load any uh specific uh uh data at a at a given uh storage slot which is quite nice. So you could read uh easily read private um variables stuff like that. We have the state management as I talked about earlier where you can both fork uh pre and post state which allows you to compare um values before and after a transaction. Um we have transaction data so you can get all the locks that can be very nice for rebuilding I don't know um let's say you're doing a lot of deposits into different uh positions in in a protocol but you also keep track of the full balance. Um so that's a mapping and it's also just a value.
Um but you can then use the logs for example to reconstruct this and make sure that the total balance uh increases by the total uh sum of the deposits um which is uh is very nice to make sure that your invariant or one of your invariants for example is always true. Then you can get all the call inputs in the call stack. So for example, you can get all the calls to update price in a price oracle. Um, and you can see, okay, is there a call in the stack that really deviates a lot from like all the other prices? This could mean that maybe there's a price manipulation attack going on or some kind of a flash loan um attack.
You can also get uh all state changes to a specific storage slot. Um so that could work in the same way as um as for the like it could work for the uh price manipulation attack. It could also be for example um as I mentioned earlier someone could uh change an owner or an admin of a contract um do some stuff and change it back to the initial um admin and it would look like nothing happened. But if you look through all the state changes, you could see that it actually changed intro transaction to someone that like it shouldn't be and then changed back. So you can catch these kind of things that you have no way of really catching in regular solidity just with your require statements or whatever.
And lastly we have uh call triggers or triggers which you use to define when an assertion should be run. So this is also very powerful. You can for example say anytime this storage slot slot changes we run the assertion or anytime there's a specific call to a specific uh function we run an assertion or if an fbalance changes of a specific uh contract then we run an assertion. So you can be pretty granular about when you run it and combining the triggers with the cheat code you can really um find some interesting uh things to trigger uh your assertions on. um two small examples.
Um, this is like one way that a hack that happened back in 2023 could have been prevented um by basically running a health check on all updates to uh positions um or or accounts um for like yeah I don't want to go too much into detail with it but basically um making sure that anytime there is an update to an account um or a position that this position is still healthy. um if you run this in your entire on your entire protocol, it doesn't matter if you add new functionality or something like that and forget to add a health check to that, it will always um check that all uh positions are healthy. So you can have kind of upgrade your protocol with like a peace of mind and we like to say devs will sleep better at night as well. And here's an example of what it would look like if you wanted to do a pri intransaction price deviation. So you basically you get all the state changes um of uh like a token price feed um you take the value of the token price feed before the transaction.
So that's the fork pre-state and then you take fork post state and you compare like all the state changes with uh like here I have deviation of 10% and if any of the price changes in inside of the call stack were more than 10%. we would um not allow this transaction to go through. So this is a way to detect and prevent uh price manipulation attacks. Um yeah, so where we at with this at the moment? Uh we are currently uh deploying uh this weekend our first uh demo.
Uh so that will be like a closed uh demo. People can reach out and they can get to try it out. We're also helping the first projects that are um willing to to try this out. We do like white glove onboarding, writing some assertions for them, helping them uh along the way. And yeah, if you're interested to get a full demo or see how this works, uh come find me after or shoot me a message on uh Twitter or whatever.
Um I think uh that's all for me. Here's like a little bit of info. Did I do it uh on time? Do I have No, you're good. You're good.
Do I have time for questions or Yeah, you have time for for questions. Are there any? Uh yes first any questions? Yeah. Okay.
So uh I didn't really understand who is like running these assertions. It's like a sidec car for like people running nodes. Uh so the assertions would be run like we have to integrate with the sequence like at the sequencer level. So basically let's say I don't know um right now we do opt so any it would be base or whatever they would have to actually implement our software at their sequencer uh block builder level. So that's also a challenge but that's uh what we need to do to improve security kind of.
Yeah. Cool. Thanks. Are there any other questions? Yeah.
So uh what if like someone write a assertion that actually preventing the uh the normal function functionality of another DAP, right? Yeah. Yeah. So, so you mean like if you accidentally write an assertion that has an an error in it or like that no codes are perfect, right? So, yeah, like false false positives.
Yeah. Yeah. So, that's the cool like that's one of the things why it's nice that it's kind of modular so you can disable it and we also usually would say um run it for like you can add it and run it but not enforce it. So for example, you can let it run for some time and see if it has any false positives uh without actually enforcing this. And you can also do back testing.
So you can add it and then you can run it on like the last 10,000 transactions to your protocol and see if any false positives would uh pop up there. Um yeah, but you need to test it of course very well and but you have the chance to remove it again if it turns out that you made a implementation error and it's doing false positives. So, so um okay if I understand correctly so if one sequencer adopt this technology it's still up to the protocol themselves to write assertion it's not like for example if uh it's not up for for base to base code developer to to decide what the assertion will be it will still be up for like a developer to run a searchion yes exactly um yeah so it's up to the to the protocols to define their rules and and use this as the tool to uh increase or improve security. So So if if I'm a code code in maker doll, I cannot write a certion for for RV uh or Exactly. You can write them but you cannot add them to their protocol.
It's um it's only the we have some different ways of doing it. Um, but like either the deployer, not the deployer, but like it would be like the the owner of a like if you have like an admin or an owner defined in your smart contract, then it would be this account that is allowed to to activate them. Okay. Thank you. Um, okay.
Last question. What would you say to those protocols like Bass that are worried about the the centralization aspect that this could bring? I mean then I would say that like B themselves they're they're basically already running a centralized sequencer right so we are just kind of piggybacking on the trust assumption that already exists that uh the sequencers will not censor or they will not like allow people to like they will not block transactions or they will not do weird stuff right so that's the thing right now with sequencers like we can basically point out and say this is the legal entity running this sequencer Um, and if a hacker then colludes with the sequencer, in theory, they could uh uh go around an assertion, but that would have severe consequences for the company that is running the sequencer, which would be base in this case, and we could like basically sue them for not uh like doing their job, so to speak. So, that's that's how we currently look at it. Um we would of course love to find a more uh like decentralized uh way of doing this in the future but it also increases the complexity quite a lot um which is why we focus on these centralized sequences to to start with.
Gotcha. Thank you.
Automatic transcript — names and jargon may be misspelled.