Breaking Down Bridge Security Models

Transcript

cool so yeah my name is Lane Haber I'm one of the co-founders at connects where I do research there and I'm going to be talking about different Bridge security models and their implications uh so first you know this has been touched on in the other talks but Bridge security is important because it frames it lies at an infrastructure layer for these other chains that it's connecting and if something goes wrong in a bridge you could be left holding the bag even if you've never interacted with a bridge so this kind of details where some of that two billion dollars that Chris mentioned earlier went into which hacks uh this is not a complete registry only that's happened in the last 365 days but as you can see

these hacks are getting larger and larger because more and more funds are getting put into Bridges and I expect that soon we'll probably see you know a billion dollar hack on a bridge regrettably but that just underscores their importance uh growing importance in the ecosystem another region reason why Bridge hacks are so malicious is like again you could be the collateral damage but that goes to this like contagion risk so lots of bridges work by you know being able to back assets one to one and this is like for example how all of the polygon the POS Bridge or the roll up amb Bridges or the gnosis Omni Chain Bridge they all

custody funds and then allow you to use an adopted asset on their chain the risk with Bridges is if the bridge gets hacked then those funds would no longer be backed one to one and you could be left holding the bag so you know scary example but if this were to happen to the polygon POS bridge now you can enter polygon through just using your credit card which means that you're exposed to this bridge risk even if you've never used the bridge so it can be something that you don't realize you're exposed to um yeah so now I'm going to go into different types of security models the first is a natively verified bridge and this is where your domain's underlying validators are the ones who are verifying the transactions so you can

think like like clients or you know roll up ambs or the polygon POS bridge but the underlying domain validators are the ones who are validating the bridge itself uh there's also externally verified transactions where the validator set is actually not part of the underlying domain validators but it is now just um a third party set of validators who can be incentivized through a variety of different ways but they're the ones who make sure that these transactions between the two domains net out um and then you have optimistically verified Bridges optimistically verified Bridges operate in a similar way to optimistic rollups and by that specifically I mean

that there is a delay window where anybody can submit fraud uh how fraud is proven is there is a Merkle tree of updates to stored or messages stored on the origin domain so where the message is sent from and you can prove that some root is incorrect on the origin domain now to disconnect other domains from processing that message you would have to rely on a watcher to call disconnect on those domain it is important to note that while the home can be or sorry only the origin chain can prove fraud but the destination chains can be disconnected by a trustworthy watcher yeah so when we talk about Bridge security there's three main things or questions

that we're talking about uh and three different types of security so there's Economic Security which is basically asking the question how much would it cost to corrupt your system um the implementation security which is like how difficult is it to implement and how secure is the out design outside of the implementation as well and then you have environment security which is like how can your sister handle underlying domains with low Economic Security so what I mean by that is bridges are generally an oracle of information and state from one chain to another you can have chains that are connected that don't have equal levels of economic security at the base layer so for

example connecting uh cardano to ethereum cardano is probably easier to corrupt and censor than ethereum is but the bridge is basically what would allow malicious State on cardano to be transferred and honored in ethereum and kind of break that Integrity on the higher security domain uh cool so Economic Security what's your price how much does it cost to corrupt all of the validators in your system uh so for natively verified Bridges you would have to corrupt the underlying domain validator so you would have to 51 attack the underlying domain to be able to violate the economic security uh externally verified systems you actually

just have to prep the bridge validator set I reference the Ronin hack here even though they weren't bribed but they did lose Keys which showed the implications of having a corrupted external validator set uh and then for optimistic security there's actually a few different bribes you can execute um one is for the entire Watchers so preventing any of the Watchers that are online from disconnecting any transaction or proving any fraud would certainly be problematic you can also censor the home change so that's where the disputes are initiated and fraud is proven you can prevent the fraud from

actually the proof fraud transaction from actually being submitted on the home chain or wherever the messages are sent from and then there's the last one last bribery opportunity where you could actually bribe the destination domain to and censor that domain so the validator is there so that the Watchers even if they are honest can't actually disconnect the domains so in terms of ranking the most secure for Economic Security is native and this is because you're really going to want to maximize the diversity and permission and size of your validator set and Native domain or natively verified Bridges do that in the best way optimistically verified Bridges uh the

reason why they're second is because it can be difficult to know who all of the Watchers are and you would have to bribe all of them because even one Watcher who couldn't be brave would be able to disconnect the chain and prove fraud uh and then you have externally verified where you just have to bribe the external validator set or even some majority of the external validator sent so the node the next one is implementation security uh you have to keep it simple this has been you know this is a problem for any smart contract system software is hard so try and keep your implementations as dumb as possible and keep them as extensible as possible uh so some of this Simplicity can come from the nature of the protocol

itself and some of the security for implementation would have to come from the team itself so what do I mean by that I mean like you have to have Fast Response times like Chris highlighted you have to have monitoring you have to make sure that you go through audits what's your test coverage look like like basically a cohesive secure development process is important but there are also things that you can do to build in defenses against certain hacks this is similar to what uh was mentioned with the pre-crime stuff although we call them circuit breakers or rate limits but basically the concept there is if you have a transaction that was withdrawing 0.01 of the Bridge Supply and one

transaction that's probably fine but if you have a transaction that says it would want to withdraw over 90 percent of all the funds locked in the bridge well maybe that one requires some additional verification um so natively verified Bridges tend to depend really deeply on the consensus of the underlying domains which means that you can't have this same implementation be used multiple times so this becomes very difficult to implement uh and then for externally verified systems you can have the same set of logic because it's not intimately tied with the consensus of the domains that validates the transactions that happen

however you're probably going to have some more complex off-chain coordination to between all of the validator sets off chain or the validators who are securing that bridge off chain uh with optimistic Bridges you are able to Port the same implementation to multiple different domains because it's not dependent deeply on the consensus and additionally you have kind of isolated agents who don't need to communicate with each other so you have the updater who is responsible for similar to a sequencer and a roll-up they put their stake on the line they're responsible for ensuring the Integrity of the messages and then you have a series of isolated Watchers who are there to prove fraud and potentially react to it

so in terms of who is the most which model is the most secure for with respect to implementation security uh optimistic is the best and followed by external because you can easily Port both of those models to different underlying domains and the third is natively verified Bridges because you can't easily support the same implementation to new domains so when you're trying to add a new domain you'd have to come up with a whole new implementation which doesn't necessarily have the same security because it hasn't been battle tested in the same way but rides off a similar brand uh the third one is environment security and what I mean by environment security is like how can you prevent 51 attacks on the underlying domain there's

this is all about ensuring that you maintain the high integrity of environments that have a really high Economic Security so in the Cardinal ethereum example that I gave it would be ensuring that ethereum did not react properly to the cardeno fraud from 51 attacking that domain so it was a natively verified Bridges uh this doesn't happen very or it doesn't defend against this very easily because really the only way you can defend against this is by taking advantage of asynchronous models and uh making sure that somebody off chain is validating that the two steps are that that there is no underlying 51 attack uh and that you have for externally

verified systems um it is very easy to add this type of delay in checking um but it's not necessarily required for the protocol so it's not correct by construction but can easily that added degree of security can easily be added uh and then for optimistic systems they have a delay embedded in the protocol which means that these types of risks take or like types of detection measures can be easily added without having to you know change anything fundamental and the delay to react to that is already embedded uh so who wins here you see optimistic is probably the most secure for environmental security followed by external because again you can easily

add those checks in but it's not required or add in the delay in those checks and then the third is native because there is no uh way to check that if it's depending on consensus and consensus is what where the problem exists um so the final rankings here uh economic natively verified bridges are the most secure for implementation optimistically verified bridges are the most secure and uh for environment security again optimistic Takes the Cake but keep in mind that there is some Nuance here and you're going to have to pay attention to kind of the details for the implementation of any bridge that claims it's optimistic in their new bridge that claims it's native and any bridge that says it's externally

verified so yeah happy to go to questions we're hiring as well let's just jump to the panel