Crosschain Security Considerations for the Degen in All of Us by Layne Haber | Devcon Bogotá

foreign [Music] well thank you guys all for coming my name is Lane Haber I'm one of the co-founders at connects where I focus mostly on the core bridging protocol and uh I'm gonna give you guys a talk about cross chain security considerations for the d-gen and all of us and hopefully by the end of this talk you guys will be able to come away with some key questions to ask yourself about Bridge security uh so first why is Bridge security important well Bridge security is more important than most systems because you can be subject to the risk of the bridge when you never even touch that and what do I mean by that well polygon the polygon POS Bridge the roll-up ambs you will those bridges basically work by locking up assets on one side and delivering you a minted version of those assets that represent a claim on the locked funds uh when everything is backed one to one this is works great because you can trade the assets on your destination domain freely and then whenever anybody wants to come back they can easily just unlock it unfortunately if your bridge is attacked then what you effectively have are claims on something that don't exist anymore and you are subject to this contagion risk whenever you are using those assets so if you're on polygon and you've withdraw like purchased POS usdc with your credit card or you've exited to polygon from an exchange you have never used the bridge and you were still subject to this contagion risk that exists with the polygon bridge and the same thing applies to Roll-Ups as well uh well really any default Bridge so this is kind of just a visualization of the risk that we as an industry are exposed to in just a small subset of default Bridges uh this these numbers may have changed you can see that they are in dollars um but it's over it's close to four or five billion dollars that uh of assets that are subject to this type of risk that's not those aren't the only bridges that are getting hacked are the default Bridges you can see here that like Bridges just keep getting hacked and in just under 14 months we've lost like two and a half billion dollars and I'm sure that I will have to update this slide soon in the future uh and really like why are bridges so easy or like such an appealing Target they're appealing targets because it's new technology like I think about this stuff every day and even for me the way that we are thinking about security or thinking about the best way to bridge between chains changes all the time on top of that it's also a honey pot so because you lock funds up you are become a really attractive Target to hackers and it's not just like the custody assets to create the minted assets are the only ones that could be locked on the bridge if you have a high latency Bridge you could also have assets to like that kind of represent more of a liquidity network if you're not the default bridge then you're probably going to want some type of amm to switch into the asset that everybody really wants and that is that's just all a lot of money that is an appealing Target and the other reason why these Bridge hacks keep happening is because Bridge technology is pretty complex like you are building a system that is connecting a lot of heterogeneous domains so not only do you have to know everything about your system but you have to know everything about the underlying domains that that you're connecting because the code that you write will not run the same on optimism or arbitrum or polygon there are slight differences that will impact you because there's slight differences that you may not understand fully uh are going to be the ones that end up being your downfall so now we're going to talk about like the different types of bridges that exist and some of like just to give you guys a easier mental model to evaluate all the bridges uh so first before we get into that um you can't have all the nice things you're going to have to choose some and there's always trade-offs like in any other type of engineering uh generally it means that you can't have all four of these properties it's low latency meaning the transfers or message passing happens quickly it's generalizable meaning you can pass whatever messages you'd like through the bridge it's trust minimized meaning that you're not adding any additional trust assumptions or it's extensible meaning you can take the same implementation and use it on many different domains you can also have there's a missing triangle but you can also have low latency trust minimized and extensible ridges those are more like liquidity networks like Atomic transfers would have that because you can't pass General data through you can only pass fungible tokens uh cool so what types of bridges exist and where do they exist on this trade-off space there's natively verified Bridges and natively verified ridges are bridges where the domain's underlying validators are the ones that are verifying these transactions uh this is something like like client Bridges ZK Bridges the uh which are coming out now uh or like even the roll-up ambs are a special special case of this type of bridge um they are very low latency you can pass whatever information you want through them and they are trust minimized however they are not extensible and they're not extensible because generally these Bridges depend really heavily on the underlying consensus of the domains that they're connecting so I would need a completely different I would need two different Bridges if I were creating a project that would use like client Bridges everywhere I would need two different implementations uh on ethereum if I wanted to connect from ethereum to Cosmos or ethereum to Solana uh there's also externally verified Bridges externally verified Bridges have a third-party validator set that's verifying these Bridge transactions um this cut is low latency generalizable and extensible but now you do have to consider what happens with that third party validator set the implications of like whether or not the bridge validator set is going to be the lowest trust point in your system really depends on like the validators of the domains that you're connecting so if you're connecting flip-flop chain through a very popular bridge to ethereum your weakest verifier set is probably going to be on flip-flop chain uh okay cool and then there's optimistically verified systems optimistically verified systems use fault proofs to uh enforce the validity and veracity of the messages that they're passing through one Quirk about how you have to construct the fault proofs for these types of systems is you can only uh prove that fraud happened on the home domain which is where the message was sent from generally that's because all of most optimistic systems have some type of Merkle root that they are verifying and you can only prove that your claim of fraud was valid if you know the contents that went into that Merkle tree however on the destination domains you can disconnect the math uh the chain so they don't process any fraudulent messages these systems are trust minimized generalizable and extensible but obviously they have there have some latency because you have to run a fault proof uh so I also want to talk briefly about ZK Bridges just because they are coming out soon but they're not available yet ZK bridges are a type of native bridge that you know uses a validity proof to ensure consensus one thing that you have to consider with any native bridge where it's just or any proof where it's just a certain consensus is if there's a 51 attack on one of the domains that malicious information would uh be treated as valid when it's crossing a bridge that verifies only consensus there's some really interesting work to validate both consensus and state transitions but it's in early days ultimately that's probably going to be the gold standard of bridges but it's not ready for prime time yet um so now we're going to talk about different types of security and where these Bridges fare in those trade-offs so when we talk about security of these cross-domain systems we're really talking about three different types of security Economic Security which is how much does it cost to like what what damage could a really well-funded adversary do to your system implementation is like how complex is it to build and reason about um and also implementation talks about your standard development practices like do you have good security hygiene and then there's environmental security environmental security is basically how can it you can think of bridges as an oracle of information from two different domains and if you think of them that way then you have to ensure the quality of the information as it transfers from a low security domain to a high security domain so what I mean by that is like if flip-flop chain is you have a bridge that's connecting flip flop chain to ethereum and that flip-flop chain is 51 percent attacked how does your system handle passing that information that may be maliciously malicious so Economic Security what's your price uh how much does it cost to corrupt all of your validators basically the only great way to kind of constrain this risk is to have a permissionless and diverse validator set otherwise you everybody does have some sort of bribery prize so natively verified Bridges to kind of break them on their Economic Security you have to corrupt the domain's underlying validator set for externally verified systems you have to corrupt their Bridge validator set and again like whether or not that's the weakest validator set depends a lot on the chains that you're connecting and then optimistically verified systems there's a few different ways you could corrupt the economic security of these systems the first is that you bribe all of the Watchers which ideally this is a permission listening to join so if you can do that that would be really expensive and difficult to do and you wouldn't even really be able to dox all of them but also you could censor the destination domain or censor the home domain so that it becomes impossible to actually submit a fraud proof or disconnect transaction uh so in terms of like where all these system ranks native is probably is going to be the most secure for Economic Security followed by optimistic and external and again this is largely dependent on the permissionlessness and diversity verifier set okay so implementation security how simple is it like your Bridges already have a massive surface area because they're connecting like dealing with a heterogeneous environment um so those dependencies will trickle up and it's something that you have to deal with so the only way to really mitigate that that type of implementation risk is to constrain your surface area uh which means you should probably talk to your theoretical physics friends because they're really good at that but implementation security is not just how simple your system is it's also all about code hygiene all about development practices all about security mindset like do you buzz your test you have audits what's your test coverage are your bug bounties live have you done war games um you can also constrain this implementation Risk by building your systems defensively and what I mean by that is integrating things like rate limits so if you're a bridge and somebody's withdrawing ten dollars that's probably fine you can probably let that happen but if somebody's withdrawing 90 of the value in your bridge in a single transaction maybe you want to add some delays or some extra verification on that so that people can uh react appropriately um so for natively verified Bridges they are pretty complicated because you have to deal with the underlying consensus set and so you really need a unique Bridge implementation for each domain pair that you're connecting uh for externally verified systems it's really nice because you can take the exact same system and put it on pretty much any domain the complexity comes from uh the like off-chain coordination between the verifier set anytime that you have to have a coordination between multiple actors it becomes more complex with optimistic systems um you don't need that off-chain coordination between all of the Watchers and so that they really have an advantage in terms of implementation security so yeah optimistic wins here followed by external and then native Bridges actually do the worst so now we're talking about environment security so again like bridges are Oracles of information from one domain to another and you need to make sure that your system can vouch for the quality of that information uh you can constrain environment really the best way to do that is to add off-chain checks like 51 attacks are really difficult to check on chain and uh you want to be able to add equivalency checks to and delays to your information so that you don't respond immediately to in data that could be malicious uh so natively verified systems these happen synchronously as soon as like it passes consensus it could pass through the mechanisms of natively verified Bridges which means that if there is a 51 percent attack you don't really have a strong defense against that um for externally verified Bridges it's really easy to insert these types of equivalency checks and these types of delays but it's not required by the model by default whereas in optimistic Bridges the delay is made like embedded in how the protocol works so these checks are kind of treated as a first-class citizen so yeah optimistic bridge is best here external and then native uh so woohoo optimistic Bridges like probably the best but that doesn't really matter that much because that's not like where we're getting attacked the hacks that we see the bridge hacks that we see they're almost all at this implementation level so in terms of attack difficulty it requires way less resources to be able to exploit the implementation of a bridge and like exploit the implementation risk if you're going to do an economic attack you're probably going to need a lot of money and if you're doing an environmental attacks like corrupting the validators uh well you're going going to need a lot of money and probably a lot of know-how as well and we're not seeing any of those types of attacks those are pretty rare what we're seeing all the time of these implementation Keys the one the one exception being Ronin uh Ronin is like a multi-sig bridge where they have some number of signers have to verify all the transactions I would argue and those keys got compromised the bridge got drained for hundreds of millions of dollars I would argue that that was again an implementation failure in guarding your keys more than an attack on the economic model of the bridge uh so if implementation security is like the most accessible thing for us to solve a lot of that comes from thinking simply but also from the Decades of Prior cyber security processes and research that we have why are we still having so many hacks and the reality is like security doesn't exist in a vacuum all of the projects that are creating Bridges right now are young and they are resource constrained and when you are creating a project of any type like hacks are a low probability high impact event and there are several other things that could kill your project so you are going to be forced into making different types of trade-offs so a lot of the trade-offs that people make when they actually ship Bridges is to take some type of shortcut uh the most common shortcuts that you'll see are whitelists upgradability and centralization so if you're lping on a bridge that's probably going to be dated behind a white list if you're an external validator most ridiculous of those oops sorry have those gated behind whitelists as well there's also upgradability upgradeability is controversial it's not clear whether it's better to have an opt-in or an opt out system since you'll want an opt-out system to fix emergency bugs but you want an opt-in system to allow projects to kind of change their security risk at their own at their Leisure but most of the time the upgrade systems that are in place on all of these bridges are just instant upgrade by an admin multi-sig which obviously kind of undermines the entire security model that most teams advertise and quite frankly it's mostly a branding exercise uh and then you also have elements of centralization uh that means like possibility you have centralized supporting services so in bridges actually if you are running your own node or running your own node is just as important as like securing your keys and the reason for that is if you don't run your own node you could get malicious events and generally as you're an LP like most bridges function by watching for events on Source chain validating them and sending them out on destination chain and if you're you have are connected to a malicious node provider then that event is incorrect and you could have just sent them a lot of money so these are all things that common shortcuts that bridge projects take because right now they're trying to de-risk their unknown unknowns like is this even the best way to pass information what are the RPC qualities like on the domains that I'm connecting to there's a lot of other things that go into creating a secure protocol uh so that means that there are some practical considerations that aren't the most tasteful that are important for you as a user when you're evaluating your security uh so the first one is is this my life now which basically means you have to understand how long you're exposed to the risk of the bridge so if you are using a assets that came from a default Bridge not even the default Bridge itself you are still exposed to that bridge risk if you are using uh or lping on a bridge for either the amm or just as a liquidity provider of some other type um you really will be exposed to the risk of that bridge for the duration of the time that you are lping if you're a user in your crossing a bridge and it's not the default Bridge so something like hop or connects um you're only exposed to the risk while you're Crossing now the other one to check is like where are your receipts what have you done like the Lindy effect is incredibly powerful in bridges but it should reset every time that there is an upgrade so you have to look at how long it take how long Bridges have been securing a large amount of money and that's a really good proxy for how secure it is because if there's a lot of money there uh it's probably an appealing Target and so people have probably tried to hack it and can't that being said just because it's been around for a while doesn't mean there's not a bug in it and then the other one this is like the most unfortunate to have to consider because it's kind of against the ethos of the space but uh because Bridge projects take these shortcuts it is really important and are kind of running on training wheels it is really really important to know if you can trust the Judgment of the team do you know that they follow good development practices do you trust that if something went wrong they would continue working on the project and if you're not capable of evaluating like the specific development processes and hygiene of the team then you really do need to lean on social signaling for other people who would vouch for that who do have more knowledge it's kind of unfortunate that that that that that ends up being what we have to fall back on but until these bridges are really Standalone systems that just kind of is your best bet so now we have time for questions we have about five minutes thanks yo thank you that was great uh how do you how do you make your own considerations so you're talking about getting some shortcuts regarding like uh the weighing of like security and speed like time to deploy time for time to production how do you how do you weigh those things that connects how do you make the decision of save centralizing some aspects for example yeah well I can tell you exactly what our shortcut was so and our nxtpv zero uh that's kind of an atomic transfer system and how it works is you have a trans you run an auction process and then LPS can bid on facilitating your transfer users select the winning LP that's great all of that needs to happen on a messaging server we use a centralized messaging server because figuring out how this would work in the wild and how it's like kind of what our risk to a business was figuring out decentralized messaging was not high on that like decision Matrix priority it just wasn't something that we would be able to focus on um I think like as we've matured as a project we've started to kind of realize that it is really important when you're not sure about the entire security of your system because you have no Lindy it's really really important to make sure that there are some controls that you can enact like pausing the system is incredibly important especially as it increases in complexity in practically speaking in your team who like how was the how did you come about that decision did you involve everyone like was it like more strategic like uh for the centralized messaging uh we asked some of these two folks if they would recommend lip P2P and I said absolutely not and so you're like okay foreign you talked about the dangers like how you lose your lendiness when you upgrade a bridge um I'm curious if you have specific ideas about like the testing and uh yeah the testing procedures that you would have specific to upgrades to make sure that super strong super strong opinions about that personally yeah yeah I think like you at the very least you should set up a hard hat or forage project that Forks the mainnet URL and runs a bunch of fuzzing and unit tests against the upgrade that you've performed but I think beyond that like that's great you need to have a separate main net test bed contract environment where you can run these tests and then you need to do some fire drills like red team blue team so we work with spear bit to do this kind of external attacks on our system and we'll get like if that obviously if it's a real bug you know please don't do that to us on mainnet uh but we'll give them upgrade keys to kind of inject a bug and then we'll test our monitoring systems like how quickly can we pause things if it went wrong like how quickly can we get our incident response team together because I think that if you have to figure those things out when it's under the gun you're in a lot of trouble so we're gonna do our first one on our upcoming uh Fork probably in the next few weeks here but um we'll give them like a two-week time frame and say okay sometimes within this two weeks get it and if I really wanted to be mean I'd be like do it while I'm asleep because which I probably will I was just curious would you recommend adding latency to increase security or it doesn't really do anything definitely I think until you're able to prove the validity of State Transitions and not just consensus then your only way to mitigate like your risk of 51 attacks is to have latency in your system awesome thanks guys