Mitigative Measures for Bridge Exploits

Transcript

um the slides are coming but I cannot really introduce the next speaker is Andres Monty and is going to talk about question mitigative safety mechanism yeah so I mean I'm not going to start with other slides because hey unfortunately I haven't memorized them but uh yeah I'm interest Monte there you go yeah thank you So today we're going to talk about a mitigative measures for bridge exploits and yeah a bit about me I'm Andres Monte co-founder of range I've been working in crypto for about five years and specialized in security for the last three and it's particular in the cosmos ecosystem so yeah today we are going to talk a bit about British exploits integrative mechanisms with an emphasis in Cosmos

so why breeds get hacked I guess the first one is Bridges handle a lot of tvl so you know like they're like very good targets just for attackers that attackers mostly are rational economic actors so so yeah bridges are very targeted for that some designs are better than others in bridges more on that later and bridges are very complex sometimes they have to integrate many different blockchains they have to be written in different languages so end up being even more complex than the blockchains that they are integrated with so like this is a really nice anatomy of bridges by types of design from from li-fi you can see in the blue like in

the very left at the the most trusted designs like these are multi-6 and then as we go to the right we get to more like trashless designs in the middle we have like a POS validator insert systems and then in the in the very right we have what we call uh trust minimize or trustless designs one of that we are going to talk later is IBC with light clients and relays but then we have as well CK Bridges which there says non-exist but there are many other projects right now building them out so yeah like the reality is that all Bridge designs are not created equal I think as a community like we've made a lot of progress and moving more for like the the right side to the to the pink so

we are building more and using more uh trust minimize uh and translate Bridges but the reality is we are not there there as we've seen like in last week and many other events but we have to understand that most of the breeds exploits are not just because the designs are poor like if we see I mean there are some like for example the one the yellow are uh multistig Bridges so Bridges where the key has been compromised like the big one of course is is running but the majority of bridges actually have been uh implementation flows right so it doesn't really matter uh the quality of your design How Sound your protocol is even

the most sound protocol Bridge protocols can be subject for for implementation flows this is the case for trustless Bridges but this is also the case for canonical Bridges between ethereum and Anil choose so we need to assume as an industry that we like it or not there will always be yet another software back and also like what we really realize is that as we move more to trans minimize and translate Bridges the the comp they're more complex like they are very complex software projects like for example at the oblivionates of CK and and distributed systems so so there will always be uh bugs we need more proactive and mitigative safety mechanisms Audits

and focus on code is not enough and also Bridge code bases are not immutable so our very large code bases that are really not immutable and also Bridges have a systemic risk to the whole critical system they are really the glue and they really pull systems risk for all the applications that talk to so we need a different types of mechanisms and mitigative mechanisms some of them are here like for example rate limits that we are going to talk later like IBC rate limits and the recently proposed RC 728a1 we have also transaction delays as the one implemented by the warholm team with one whole governor and their secret Breakers MMA multi-message aggregators and also like

Hashi by the nurses team so now we are gonna step over the bond and go to the cosmos ecosystem how we are handling this right now so for those that don't know ibc's addresses protocol interability protocol that communicates arbitrary data between different state machines initially built for Cosmos but now these light clients have been important to other ecosystems like polkadot and ethereum and we have ibc3 limits I think is the first standard on the wild being used in production so these are governance configurable rate limits for tangible tokens over IBC this means as a native example that a specific token a cannot be transferred more amount than 100 in

in the last hour between in or out a certain chain and this is very important protection mechanism because it's not just protecting that there is implementation flaws at the bridge level but it's also protecting at the chain itself that the destination is not exploited so in Cosmos we talk a lot about sovereignty so what rate limits gives you is actually a sovereignty of how much you trust your counterparties when you are attained when you're a project and you are connected with another chain without very limited actually just giving an open bar and and it says not the bridge that can be exploited but also your counterparty so dread limits give us a kind of like parameters to reason about

this trade of space we have two implementations the first one is by the osmosis team and this is implemented with Cosmo Watson smart Contours which is a framework written in Rust for for Cosmos and Compass to awesome and then we have a the native Cosmos SDK module written by the strike and this is just the present this is in production this is life but what is the future looking at for us so we want to stand as a community video like fungible token transfers as we mentioned before ibc's arbitrary message passing so we can pretty much put very limits in any type of message that happens cross chain uh we would like also to combine rate

limits with transaction delaying as we discussed with Warhol I think there are many cool features that you can do here and then also just make them smarter so make them dynamically adjustable so you can you know based on online events you can adjust uh the the very limit of a certain token pair so you could even say Hey whenever upgrade happens make like the the rate limit very small and then you can continually increase it as you get more confidence on your on your implementation and this is really like our Focus that we are putting in in range so we are building in Cosmos and we are kind of putting layers of security layers on top of IBC integrating of chain monitoring systems and also this on chain mediative uh techniques that we've discussed

before like on-sain mechanisms uh like rate limits circuit breakers and more uh we arranged my Twitter handle is AES month in Twitter and I'm just super excited as well to know uh how other you know Bridges other projects are thinking about this and on other unseen safety mechanisms so yeah just reach us uh over Twitter or here in the conference like super looking forward to discuss all these topics and yeah thank you very much for your attention thank you