Protocol Berg v2: Frederik Luehrs - Runtime Assertions New Paradigm for Customized Contract Security

Yeah. Hello, good morning. Uh, my name is Fred. I'm with the Filux team. Um, and I want to start with the question, what if we could stop smart contract hacks before they actually happen?

And that question uh we asked ourselves in the past year um how and look we were looking for solutions how we can actually prevent hacks instead of reactively just uh detect the hacks and react on them. So let's have a look what developers have as options for today. And um I want to dive in quickly into some security patterns which are commonly used today in in smart contract development. Um probably the most famous one is the checks effects interactions pattern. Uh here you uh do your require statements and your checks at the beginning of the function and make sure that uh the requirements are met that the function can actually be executed.

uh you then then do the effects and then only do the interactions with the rest of the chain. That helps for re-entry problems which has been a big problem in the past but it only does like a pre-state validation and then pre-input validation and no real after the fact check. So basically there is no in this pattern there is no verification of like did the function actually do what it was supposed to do and is my contract in a valid state. Um there are some evolutions of these protocols uh like a more modern one is called the fry pie pattern. Um I think this uh term was coined by naent and here um you extend the checks effects interactions pattern with a final verification of the state checking protocol invariance.

So basically after the function has modified the state um is the final state do the invariance still hold? This is more entitycentric and more proactive. So transactions would actually revert if the invariance do not hold anymore. However also um such patterns come with trade-offs. For one, it can become really gas intensive if a developer adds this security checks and this logic um at every function execution.

Um and that is a big problem. uh also it can become increasingly complex if you need to do internal accounting to actually verify the final uh state at the end. Furthermore, solidity and EVM gives you limitations of what you can actually check and what you can access in the state. Um but especially like having this tradeoff and this tension for developers to be very gas efficient and stay competitive with other devs but also at the same time secure the maximum or like um provide the maximum security is a constant trade-off developers have to make and when they do their their design decisions and here exactly we were looking for solutions how we can eliminate this dilemma. And our answer to that are assertions.

So let's start with a quick definition. What are assertions? Assertions are read only validation rules that define states that should never occur. Um so actually it's much like these verification of the final state at the end of the transaction. Um which are most of the time in 99% of the cases read only.

Um because we only read the state. that is very important and it actually allows the the dev to define what he would say is a hack on his protocol. So it's it's a definition of states which are invalid. Um this is not part of the core business logic. So it's not part of the contract itself.

It's defined somewhere else. But it should be written in solidity or really any smart contract language to to make it very frictionless for the developer to define these security checks. Um it should have a distinct outcome much like a require a pass or revert and you can really understand this as an extension of transaction validation rules. So networks define some transaction validation rules like the correct nons or something like that insufficient or like that there are sufficient funds on the user's account. Um and this is like an extension which can be defined by the DAP itself or by the contracts itself for every contract which was touched in that transaction.

Um so if they are not executed in the core business logic where are they executed and here we have defined our own modified EVM. So they do not run in the main thread of the network they run aside and that gives us a couple of benefits. So for one as I just mentioned assertions are read only um execution um traces. So that means they can they're completely independent from each other and they can execute they can be executed in parallel that gives us a lot more um room for gas and in terms of hint for gas efficiency um we don't need to execute them sequentially they run on the state after the transaction was executed so they have access to the chain state and while we have our own modified EVM we can actually extend the capabilities and allow the dev doing things through pre-ompiles which you cannot do in the normally VM execution. So this is like really goes into inspection of call traces or something like that.

So it can be seen like as a network extension. So we have the network has its normal main thread and they run alongside. So how would that look like in an integrated um manner? So the main thread executes the transactions as normal and validates the transactions as normal and then each of the contracts which was touched inside of the transaction can trigger additional security checks assertions and they get scheduled in a co-processor which runs basically in parallel to the main thread. These assertions are these addition additional transaction validation rules which then can either pass or revert and then if they revert they actually render the transaction invalid.

Uh how this is going to be enforced. I'm not going to go into detail now. So we can just assume it's going to be enforced either dur during the block building process or um at the fork choice rule. Um but there's a call later today from my colleague Odisas who will exactly dive into that topic. Yeah.

So by creating this new block space which is massively parallelizable um we allow the developer to eliminate this dilemma and have like a gas efficient uh core um business logic but also have a lot of room for additional security checks which run in parallel. um with well- definfined triggers uh the deaf has fine grained control of what should be executed and through the extended capabilities we can actually do things or the dev dev can do things which it cannot do in the normal EVM. So this way we allow maximum security while maintaining gas efficiency. So some of the uh here are some of the examples like uh how triggers could look like. So a developer can write his assertions which is basically a separate contract a separate function and then can attach it to a contract um if for example a storage slot changes a specific or a function is called or the balance changes and then during the execution um we allow for additional pre-ompiles we allow doing things which you cannot do in a normal EVM like real call spec inspection lock inspection um we can set break points to different uh to have access for different states of different points in time during the execution.

So uh this is like the flexibility which gives us by not enshrining into the core EVM and allow it to run it in our own EVM at the at the site basically. Yeah. So um I'm almost at the end. So this is like how an assertion would look like. You can see it's just a normal contract with some uh interfaces which need to be implemented and um uh we got inspired very much by Foundry and Foundry's cheat codes.

So um that was intentional. If a developer has used Foundry in the past, it should be very intuitive to just write assertions and use um pre-ompiles as cheat codes. Yeah. And uh if you want to secure your uh dab and um are interested in in this topic um please talk to us. Uh the whole team or like almost the whole team is here.

And um yeah as I mentioned there's a um call there's a talk later today about how to enshrine and enforce these assertions. Um I highly recommend it. Check it out 5:30 by my uh colleague Odysius. Thank you very much and have a great day.