Modeling Risk For Cross Chain Bridges - Omer Goldberg

hey everyone good afternoon uh thanks for joining today my name is omar goldberg and i'm the founder and ceo of chaos labs and today we're going to talk about modeling risk and security for cross chain bridges so let's get into it let's start by sharing my screen there we go nice all right so before we get started just a few words about chaos labs ks lives is a cloud platform that specializes in agent-based simulations our main focus is running agent-based simulations to test to confirm and verify the economic security of d5 protocols the way it works is you you log on to our cloud we already have a catalog of agent-based simulations that interface with various popular protocols you can also create your own if your protocol is kind of niche or novel in any way shape or form um and we talk we basically fork the the blockchains that we support which are currently ethereum uh polygon avalanche um and soon supporting near and terra as well and our agents talk directly to your smart contracts in a fork environment in the same way that they're going to be called in production in addition to the agents we provide we also have a catalog of scenarios these are more like macro changes to the blockchain environment so some of the kind of features that we already support publicly are the ability to manipulate and control the return value of chain-link oracles this week we're also going to support the same thing for unit swap time weighted average price oracles and this is critical for unlocking a bunch of testing kind of uh cases for your d5 protocol so you can imagine if you're a lending protocol and you want to test it you stay solvent in kind of rough market conditions within our simulator you can drop oracle prices for collateral assets and see that your liquidation mechanics work properly lastly our simulation infrastructure also supports the ability to kind of optimize and test how you tweak different parameters for your protocol so whether it's liquidity incentives or interest rates uh for lenders or borrowers we can run thousands of simulation and show you statistical significance how these things play out um give it different market conditions lastly everything is in the cloud so you can connect this your your github your bitbucket whatever source control you're using in order to kind of write code have these tests run in an automated fashion and cache cache regressions as they happen in real time now for our talk before we talk about modeling risk let's understand what a cross-train bridge actually is so blockchains inherently are closed networks so for example uh the bitcoin blockchain doesn't know about ethereum and ethereum certainly doesn't know about bitcoin so bridges allow us to communicate between different blockchains and this opens a whole world of opportunity let's drill that down a bit what kind of opportunity are we talking about or more specifically what problems do cross-string bridges address so kind of flexible communication opens up the door for a lot of different things the first thing is interoperability so we have amazing application that sits on blockchain a and an additional amazing application that sits on blockchain b um before or in a world without bridges are completely fragmented fragmented it with no opportunity to kind of talk or to communicate with each other via bridges uh we can now support kind of the transfer of arbitrary data or messages between both bridges kind of really enlarging the kind of the world of of interactions and things that users can do um when when participating in different blockchain protocols or applications uh capital efficiency so currently we have like a bunch of layer ones in layer two isn't all of them have liquidity locked up uh whether it's obviously kind of the bitcoin blockchain ethereum uh terra avalanche each of them have hundreds of millions of dollars that could be locked up and currently or in a world without bridges it's completely siloed so with bridges this allows us not to transport liquidity to where it's needed therefore increasing the overall capital efficiency um of the crypto world uh in home lastly improved ux currently uh kind of moving and kind of bridging and and minting kind of assets on various changes a pretty kind of clunky experience but it's one that users are willing to do in order to achieve this interoperability in the future we think that like this is going to become a much smoother experience and users will be able to kind of freely move their crypto assets across different blockchains um in a really nice way overall kind of just opening up the world of crypto to them and improving the overall user experience cool so there are a couple of different ways that we can view actually this whole world of bridges um the first way that we're going to look at it is kind of from the perspective of the user so from the perspective of the user it can be breaking broken down into kind of several different subsets or vectors the first one is asset specific so you can have a bridge that's specific for for one or two type of assets one example of that is a bitcoin bridge right bitcoin ethereum bridge brings bitcoin into ethereum um and and then also kind of the reverse way uh when users want to kind of bridge your bitcoin back uh to the bitcoin blockchain and it's specific to a certain asset some bridges are specific to a chain uh so you can imagine that kind of like the the bridge that kind of powers um the connectivity between near and etherium the rainbow bridge that is specific uh to near and ethereum and currently doesn't support other type of blockchains we have application specific so we have specific applications that support their own bridge out of the box one of those applications for example is any swap and generalized when we're talking about generalized types of bridges these are more like communication protocols so if you're thinking of kind of a classic kind of networking it's similar to that and their job is basically to serve as a message bus uh they transport arbitrary data back and forth and what they promise us is that the data is valid has not been tampered with and is something that is that the client or the receiving end can trust so let's kind of visualize the breakdown that we just did asset specific so we have uh tbtc this is bridging bitcoin from the bitcoin blockchain to the ethereum blockchain specific for for kind of bitcoin and ethereum we have chain specific uh so we have like the avalanche bridge um which supports bridging assets from multiple blockchains we have application specific like we said here we have any swap chain flip uh ren as well and thor chain that basically all have kind of like their own bridges out of the box that they've built and then they can maintain and kind of always improve and we have generalized so kind of the most i think popular uh implementation of a generalized bridge that we're starting to see is maybe chain link ccip it's still early on but a lot of interesting things being built around that of course uh layer zero um very very strong team and very interesting project and we're excited to see where this goes all right so we're talking about kind of mitigating risk security reliability of bridges but before we get into the kind of the thick of things why should we even care so there's good reason to care if you're transporting if you're using bridges to transport your crypto assets to different blockchains there's a lot of things that happen under the hood uh depending on the kind of bridge that we use which we'll get into a second there's kind of a lot of trust there's a lot of danger and risk and it's enough that usually one or two things go wrong for you to get completely wrecked so this is good reason to care because potentially all of your funds are are in jeopardy uh when you're like basically executing on these cross chain swaps um or transfers all right so we looked at how users might view bridges so they might associate a specific bridge with any swap or with door chain um or to specific blockchain but at chaos labs we kind of take a step back and the way we like to kind of define criteria is by architecture because oftentimes architecture is going to dictate the type of measures and testing that we want to do to ensure kind of the security quality and reliability of the bridge so for us we look at kind of different things not in any specific order if i had to i would say security is on the top but we also look at latency uh complexity uh so how hard is it kind of to implement this bridge how hard is it to build it how hard is it to maintain it uh because complexity is obviously like a huge source of bugs as we jump into the most recent ones you're gonna see that um the more complex these kind of pieces of software are uh oftentimes the kind of attack surface is larger which kind of you know ends up in in more attacks and hacks and exploits overhead so it might be actually that it's not that complex to kind of um create but there's actually a lot of orchestration that needs to happen and it's a complex kind of um it's a complex kind of journey to get these bridges live and reusability so is this kind of bridge super specific to two assets does it just mint and lock and kind of release and burn or is it general purpose can i transport like different types of data different types of messages so overall these are the things that kind of we look at when we're surveying bridges and assessing risk and for that here's another visualization which we found by the way i highly recommend kind of checking out this link at the bottom um it summarizes things in a pretty nice way um so this is kind of the additional way that we want to look at it it's not just kind of like in those five components which we just mentioned it's actually like in what is the underlying architecture of the bridge because that oftentimes speaks and informs what we see here um so let's look at this kind of broadly and we're going to deep dive deeper into it as we go forward external validators and federations these are kind of the most popular bridges uh simply because they're the easiest to kind of to implement uh they're easy to implement because they're not completely decentralized so we have authorities or kind of decentralized entities in this case they're called validators or federations uh which we trust to kind of sign off on messages um and and basically kind of you know execute the actions um that are received from the source chain on the destination chain uh there are a lot of these uh if we look at them kind of the ones that we're going to focus on a little bit today are kind of like any swap uh wormhole thor chain uh but these are kind of predominantly the types of bridges that you see out in the wild usually any type of project which implements them also kind of caveats and says that like okay like we're doing this to get started just to kind of bootstrap liquidity or the ability to communicate between bridges but we are looking to move towards a more decentralized model um after that we have light clients and relays these are more secure um because the way they work is they they kind of use crypto cryptographic proofs in order to kind of prove the validity of the messages that are coming through um they have better security models they're harder to implement because you need to kind of have clients on both ends on source and destination chain which are basically provers and prove that the incoming messages are indeed valid we have liquidity networks these are actually in my opinion some of the safest type of bridges uh but they come with also their drawbacks which is like sub-optimal capital efficiency uh because in kind of these cases we're not kind of reproducing uh synthetic acids you usually get the native asset on that type of chain so let's dive deeper validators and federations so this is like kind of the wormhole model or any of the kind of like the larger bridges that you're likely familiar with and kind of the flow is simple you start off at the source bridge you lock and mint your tokens so let's say we're bridging uh salon and ethereum let's say we want to port our ethereum over to solana so we go to some smart contract which is like we'll call it the client on the source we'll lock our ethereum um some kind of relayer or some type of external actor will kind of dispatch that message uh on the destination chain it will be received say all right uh you've kind you've locked you we've seen that you blocked like your ethereum within our ethereum kind of smart contract and for that we're going to mint kind of the same wrapped asset on solana so you have wrapped eath on solana when you want to transport the way back you burn the the wrapped eath which is a synthetic acid that lives in the solana blockchain and then the ethereum blockchain uh with the help of external actors receives that message says okay i actually see that you you've locked the synthetic acid which we've produced on the solana chain and now i'm going to kind of release your native east back to you in this case and we have a lot of change a lot of kind of applications that work with this so wormhole any swap door chain and more um wormholes recently been in the news we're going to touch and dive deeper into this when we look at the recent exploit that happened over the past two weeks same goes for fortune and others now like clients and relays like we said before these use kind of headers of blocks and provers on the source kind of on the destination chain in order to prove the validity of the message it's received it's a talk within itself so we'll kind of stay high level here but basically you have these external actors to each of the blockchains then monitor events on the source and relay them to the destination chain the destination chain receives events uses approver to confirm the validity of the receive message and if it's valid it's going to kind of execute actions on behalf of kind of on behalf of kind of the the user on the source chain a really kind of simple and probably most popular example of this is kind of minting assets on the chain so we'll get into more into that and kind of popular examples for this are tbtc um the rainbow bridge which we mentioned before between near and ethereum if we're going to dive a little bit deeper into the architecture what we see here is the following so like we said um with light clients and relays each of the chain needs to implement basically a client that can monitor and receive messages so on the ethereum side we see that there's a mirror like client on the near side and see that there's an ethereum like client we have also these external actors which are kind of responsible for transfer for kind of data liveness trend like monitoring messages that are happening and transporting them uh to the corresponding bridges uh so let's say we want to kind of port so basically we'll deposit uh our our ethereum a smart contract on the ethereum blockchain uh the near light client uh or an actor and the near light client kind of will see this transport the message it will see it will kind of reach near um linear protocol like client it'll say hey i see that actually your theorem here is uh is locked and this is valid i've used approver to kind of validate that this has happened and now i'm going to mint um basically wrapped eth on near for you so again kind of kind of kind of the same model of of synthetic assets being minted and corresponding blockchains it's just the way that we do it is different now liquidity networks this is a little bit like out of scope for today but they're they're actually very promising kind of i we believe that they mitigate a lot of kind of the risk on the user end but basically you need um real liquidity on both sides of the chain here we're not minting synthetic assets um you actually get the native asset in the kind of the corresponding bridge what that means is that somebody needs to provide that liquidity on the other end so there are lps basically corresponding sides um it's secure because kind of or securing kind of the the perspective that for users if something happens to the bridge you're not completely wrecked because you have i mean after you've basically received the native acid on the corresponding chain because you have the asset um so theoretically uh you haven't lost everything it's not some synthetic like acid which can be burned in a way that is out of your control and that provides some type of security and assurance for users who are doing it they just need to kind of pass the initial kind of swap between chains again because it requires like capital on both sides real capital we're not making kind of representations of the assets in the form of synthetic assets it's the least capital efficient all right so now um before we kind of lastly talk about kind of how to model and solve for the risks involved in building cross-chain bridges let's kind of look at some of the exploits we've seen over the past year and try to understand where they came from so one example is thor chain which has been exploited twice i think over the past year and and kind of like these these attacks some of them are kind of really really nice in the sense that they were complex and and um and non-trivial um but they all kind of have the same root cause um which is bugs and implementation now what we're going to focus on here uh just because it's it's kind of the most recent is is kind of recent exploits but ones that are happening in bridges which are which use external validators and federations so we're looking at these types of bridges or we're looking specifically at the thor chain hack um without going too much into detail we have kind of these uh components which we're going to touch on in kind of the components of the bridge if we're modeling the architecture you have two clients which sit on each end of the bridge and you have the bridge itself which is responsible for basically passing the messages back and forth and what we see kind of as a pattern is that basically kind of exploiting the bridge itself or kind of corrupting the message is quite difficult and most of the exploits actually originate in the implementation of of the clients themselves so in this case in thor chain they were using basically an unsafe function it wasn't safeguarded the attacker basically saw uh the opportunity here kind of wrapped torching's implementation in their own smart contract and was able to kind of call um basically be able to create these fraudulent messages um and make away with tokens now with wormhole this one was like much bigger i think kind of collectively the the amount loss over two of the hacks was less than 20 million of door chain this one was freaking massive all over the news if i'm not mistaken it's about 250 million dollars uh worse the funds that worth the funds that were lost thankfully um users were made whole by by jump capital let's understand what actually happened here so again here um this is another type of bridge which if you remember we mentioned earlier which is of the type of external validators and federations um we have these kind of trusted actors would sign off on received messages and execute kind of um actions on the source and destination chain on behalf of of users and here again we have these three components which is two clients on each end of the bridge and the kind of the bridge itself or the channel for communication again the bridge itself here wasn't exploited it was the client um that was acting on behalf of users in this case the solana client so let's understand what happened here um basically uh the you the kind of salon client wasn't checking um who was signing uh these ad who was signing kind of these actions and the user was able to kind of emulate a trusted kind of guardian in this case um and this is what led to kind of the the hack itself which was in this case infinite minting so let's dive a bit deeper into the code this is kind of uh the implementation of the solana client here um you don't need to know russ too well in order to understand what's happening here but this function is a verified signature function and what's really important here to notice is that there's this kind of line here uh instruction says far account info now this is actually used kind of delegates to an internal kind of ras function that we can see here on the bottom um and unfortunately kind of the implementation that was selected uh was using kind of a deprecated version of this function which doesn't check uh the cisfar account address properly what's actually crazy about this is that uh the kind of the team behind wormhole knew this there was a pr out to fix this and actually use the correct implementation um but it wasn't merge in time and kind of the operating kind of theory here is that the attacker was monitoring the repo i saw this and then this was kind of the original inspiration um for the attack itself uh so this is just some kind of screenshots of if you're using soul scan you can really see here when the the attacker was basically able to exploit the fact that um cisvaria can't addresses were not being checked properly um and basically infinitely mint uh synthetic ethereum on the solana blockchain you can see his account balance uh kind of before and after which is quite staggering uh so here 120 000 worth of east ethereum and then he the bridge worked so again this wasn't a problem with the bridge it was a problem in the solana client so he was able to bridge a lot of that back to the ethereum kind of blockchain um kind of anecdotally like a bounty basically there there's a white hat bounty was offered to him to return it as far as i know he hasn't returned it yet um jump has provided the capital to kind of back the ethereum one to one so users in this case are okay but again this is another case of client implementation error so now that we kind of understand different kind of type of bridge architectures we've even seen a few exploits in recent news let's talk about how do we model risk for cross-train bridges so you know i won't get into the the flame wars of which which bridges are better than the others and you know every bridge has its trade-offs every bridge has its benefits um and kind of we're not prescribing which bridge to use but we are going to say this because of the different architectures and different bridges um there's no silver bullet right so there's no like kind of catch-all one one-size-fits-all solution here which we can recommend that will kind of guarantee automatically that your bridge is secure it's important to understand what architecture you've selected and what the trade-offs and pros and cons are of that architecture so this is a long-winded way of saying there's no silver bullet because this has been in the news and kind of and like currently they're the most prevalent type of bridges let's focus on external validators bridges that use kind of the model of external validators and federation so in the attacks that we just saw in generally speaking corrupting the actual bridge communication is is difficult um usually attackers need to overcome chain consensus on either one or two of the bridges that they're trying to attack this is can be really expensive really difficult and just not economically like a good idea or feasible um so what we see here is attackers focusing usually looking for kind of bugs or ways to exploit the clients themselves so like we said before we're looking at this architecture two clients one bridge in between and kind of the focus here is on the edge clients once they receive a message you have an incredible amount of power and the solano kind of wormhole bridge it's something kind of mint uh synthetic tokens um would certainly have value and and this makes it a great target for hackers to kind of look at and be patient with so what's the solution so we do a chaos is we focus on a continuous testing so before you're going to roll anything into production we're going to define a suite of kind of test cases you're going to want to have and these range from kind of black swan events for you know for different bridges this means different things but it could be um very heavy network traffic um like very high latency on transactions um just really massive sums being transported back and forth and seeing how that may affect um kind of downstream uh things in your application we run network simulations as well so kind of the underlying kind of belief of how we operate here is we're not running these kind of like simulations in a pristine lab environment we're literally forking um all the blockchains uh that we're kind of testing so in this case the source and destination chain um we'll recreate kind of the bridge within kind of the context of the simulation and we're going to run the bridge and we're going to run messages and transactions through both blockchains in the same exact way the same exact interfaces that it's going to be seen later in production lastly um this is just generally good practice you want to do some type of fuzzing so there's kind of a finite amount of uh inputs that we can be creative with we can randomly generate input into the basically all of the kind of public interfaces of both clients on both source and destination and try to catch things um with a wider net so kind of again this the list is much longer but for brevity the kind of the things that we we simulate is recovery from failure latency and communication errors protecting your public interfaces so what are the interfaces and methods that kind of can be called by anyone those are the ones that we need to focus on um heavily fuzzing and randomization which we just explained uh which is basically spamming all these public interfaces uh with different types of input to see what breaks all right so this is the call to action if you're building a bridge or if you're layer one or layer two that wants to have a bridge on the protocol and you value security and reliability reach out to us this is what we do we're happy to help we're happy to kind of plan with you the best way to secure these bridges for your users and your wider ecosystem a little bit about the team so we have deep tech backgrounds we've all written mission critical software uh that has served kind of billions of people in different contexts uh the team hails from israeli cyber intelligence units uh facebook apple microsoft um and so on and so forth and and this is kind of what we live and breathe so we're happy to speak um unfortunately this is a recorded session so uh i won't stop for q a because it's likely going to be boring considering that i'm alone here um in an airbnb uh but this is my twitter handle omer a goldberg um feel free to reach out uh dms are open um i'm always happy to chat more about security infrastructure testing um thank you guys enjoy denver um and yeah thanks for having me you