Bridges Discussion
DeFi Security Summit 2022 · 27 Aug 2022 · 16:45
At DeFi Security Summit 2022, Christopher Whinfrey of Hop Protocol, Ryan Zarick of LayerZero Labs, Layne Haber of Connext and Yoav Weiss of the Ethereum Foundation take questions on bridge security, moderated by Mudit Gupta. Topics include LayerZero's Pre-Crime filter, why the Nomad exploit turned into a crowd event rather than a single drain, the wider attack surface of bridge aggregators and how library upgrades suit protocols built on a messaging layer.
Speakers
Topics
From DeFi Security Summit 2022, hosted by DeFi Security Summit.
Transcript
now we'll do a panel uh your you are on the panel and we have Chris here yep that's Chris and two speakers on Zoom I'm not sure how to turn them on the screen but um okay uh we'll wait for Zoom setup then we'll get started in the meantime uh people can think about questions they want to ask do we have more mics just give me one
second okay uh let's just get started I'll thank you I have a question for Ryan uh you said that you deployed your pre-crime uh approach since May how many uh of those messages you have filtered out because they were malicious uh none of them now a message a free crime were to catch something you would mean that there's a bug in so it's first right now it's active in Stargate and so it would have prevented a bug in stargate's code right so uh we it has stopped nothing but it has checked everything since May [Music] hey everyone um not a specific question to any person but broadly for the panel so uh with the
The Nomad hack everyone was calling it you know the first decentralized hack because it happened with a bunch of people um I never really saw a good explanation as to why that happened and why there wasn't like why one person couldn't come in and drain the whole thing um and was curious if there was a technical reason for that or that's just how it went so so they actually could have um and the if the attacker was sufficiently content they could have drained the whole thing in probably 10 minutes um so I think the reason it kind of went on so long was because uh the attacker didn't do that and then it was kind of released publicly that that you could replace the addresses at some point and then we then we saw like a bunch of people join in
cool thank you [Music] yeah uh Isaiah Washington from coinfun thank you guys so much really appreciate it um question on bridge aggregation uh I know you guys aren't Bridge aggregators particularly but um clearly seems to you know expand the you know utility of an app developer or even a user being able to choose between you know characteristics that you pointed out lane that you know maybe prioritized maybe de-prioritized when choosing a bridge but definitely seems to significantly expand the attack surface in terms of you know how an attacker may you know exploit multiple Bridges maybe even at once through an aggregator uh
curious if that's you know uh the right way of thinking about it if you know there are nuances to make that you know assumption false or how you guys think about it yeah I'm not sure exactly how uh they would be able to attack multiple Bridges just by in this at once just by using an aggregator but my general opinion on aggregators is they are packaging up all of they're taking on the responsibility for understanding the technical details of all of these different protocols that they're aggregating and they're doing that to provide the user some positive user experience for whatever benefits that may be uh I believe the aggregators have to be really strongly opinionated about the bridges that they include in their
aggregation and they should keep in mind that the worst user experience you can have is that all of your funds are stolen or worthless yeah that's very that's a very good point and uh I think and the the li-fi the li-fi example I showed was exactly something like this where uh uh there's not where the aggregator was not opinionated about which Bridges get used so it's a so it could cause something that isn't even a bridge and still put the funds exposed foreign I got a question for Ryan on the the
library upgrades so just to expand on that a bit is there is that something that's intended for only specific use cases or could that be used in like a wide array uh and if so uh is it possible to do things like do upgrades for liquidity pools with libraries well without like separating those pools in the same way you would for a migration or just curious to hear more about what the trade-offs would be yeah so I guess the the library upgrades are great for protocols right like things that are built on top of them uh where you're adding where you're not changing the underlying interface but you might be adding new features or um optimizations and things like that uh that all messaging protocols and anytime it could be not could not be messaging but any type of something that's
composable that things are built on top of uh that aren't necessarily funds like layer zero is a message primitive uh moving messages it's not moving actual assets at its underlying base right it's just moving a generic message so um we're able to people can opt into different libraries that that do that kind of validation messaging so I don't know if it would work uh it's not as gonna work as seamlessly say with um liquidity pools because that's not all one person's liquidity so you each each liquidity uh you could do it but you would probably have every asset every app person who has money in a pool would need to migrate that liquidity so it kind of already exists in existing pool migrations with like I think what unit swap does and Sushi swap did before uh
and so um I guess it doesn't directly translate there okay I had a question also on the upgrade path and I think it's going to be to to everybody um but I'll start off Ryan just with your experience on that have you done this uh have you done some upgrades this way and uh if so or in terms of planning sometimes it can be hard to get people to be the first person to kind of stick their neck out so how do you actually get that ramp to kind of start occurring and it's going to ask you that then I thought for the other people if we could ask do people think this is a good thing to do and are we going to see upgrades
kind of taking on that design pattern so right now most applications on layer zero select default so they automatically opt into new uh upgrades um but imagine they have the flexibility to not do that and that's that's important I think most uh newer applications are want to take advantage of the new features that layer 0 Labs comes out with uh whether it be ZK technology in the future for our validation libraries our gas optimizations or um any any other features that we come up with uh and probably most likely like Blue Chip applications building on top will not want to take on that risk and will likely opt to choose things that
have stood the test of time and then see how they how it succeeds uh the newer Library succeed over time before they opt into it like uh I kind of went over in the presentation so I think you always have uh people who want to be on the bleeding edge in the same way like with open source software people are always testing out the latest and greatest uh Ubuntu while people who use Ubuntu for work uh use the LTS usually because they don't want to deal with the braking on them and so same kind of concept applies here um perhap uh hop is not upgradable so it's kind of like uniswap where if we're going to deploy a new version we're going to deploy a completely new set of contracts uh people will be able to opt in by just pointing to those contracts
we do have some modular components that that kind of act as their independent contracts and those can be swapped in and out um but you know ultimately it's not upgradable so uh first thing I really like that I really like the idea of if a contact is upgradable then make it possible to opt out or to opt in I'm not sure actually which is which is better because in some cases I mean in some cases you have a you can have a protocol that is not managed well or a bit negligent and there is a security fix and there's a security upgrade and you miss it on the other hand you don't want to be exposed to it so I think it would be great if it would be configured like for example a something that is not a bridge but
implemented a similar pattern is I think the rocket pool the rocket pool mini pools in the in their contract the contract gets upgraded from a it gets upgraded centrally by the by governance but it's possible for anyone in the mini pool to uh to opt out and then to apply upgrades manually so uh I think this is a I think this kind of pattern would allow protocols that are more diligent to opt out of it out of upgrades While others might want to upgrades but I'm frankly not sure which one which approach would be better in this case yeah I mean I think it's it's great to have the optionality
um I do think that as we would see that applied practically there would be a lot of people who just either kind of default into the upgrades so it's practically the same as just having upgradable contracts or they kind of get forced into it because the majority of people have moved on and say they just don't have enough liquidity to continue operating on those old versions so I mean I think it's optionality is incredibly important and I'm excited to see how it plays out yeah you're absolutely absolutely right because last time I looked at a rocket pool I think zero contracts opted out yeah foreign
like hack recovery so like earlier there was a mention about I think it was like usdc you know kind of helping recover funds from like certain hacks I'm just wondering like like what do they do like do they is it kind of like the tornado cache where like they they kind of like uh freeze funds or like what kind of mechanisms do they use yeah exactly they basically have the ability to freeze any account and they're they're willing to do that if it um there are stolen funds foreign [Music] I kind of like over my thought in the space is that there's kind of a
misalignment of development incentives for Bridges like they should be developed a lot more like execution layer infrastructure it's very slow it's tons of stuff depends on it it should be very security driven very a very long and slow process whereas a lot of times it's a lot of get rich Quicks teams because there's much money to be made and so do you think that those kind of ins like misalignment of incentives exist in this space and then do you guys have any thoughts on how to combat that and incentivize people developing Bridges slowly and well I agree yes there is a there is a strong misalignment that's why I called for users to uh for users to choose their Bridges wisely because and and unless the market demands security what you're
going to get is this real get rich quick there's no way there's no reason for a bridge to spend more time on security if users don't want it yeah I would also just add to that that I'm as you see Bridges become more and more of this used infrastructure like they truly do develop into their own messaging layer uh you're going to see the development cycle slow down that's just something that kind of happens naturally as there's more increased usage like right now I'm sure that bridge volumes have been dropping across the board just because it's cheaper to do things on mainnet in a bear market and why would you take on the extra risk when transactions aren't costing like hundreds of dollars on Main map foreign
so I have another question but just kind of a more fun controversial spicy one which is uh how would you deal with the like a censorship scenario of let's say I'm moving funds that came from tornado cash then through a bridge to another site and let's let's assume hypothetically you do want to allow people to do that uh purely hypothetically um are there solutions to that challenge or different trade-offs that you would have to think through in terms of having a bridge that would be either resistant to censorship or maybe you're okay with that and if so why I don't know so this has happened a few times with hop already uh notably um the funds that were stolen from wintermute uh with the kind of gnosis safe deployment hack uh got moved
through hop and hop is censorship proof so uh there was nothing we could do uh winter commute team reached out to us and and you know there's really nothing we could do yeah I think all you can do is prevent it at the protocol layer and so when people do come to you and say hey we need you to censor these transactions you can say ah I can't actually yeah this goes to the hall I mean it's it's a sort of a political question it goes to the heart of uh of what to believe in if and if blockchain is about this intermediation then the bridges should not become intermediaries who can't decide to censor it should be trustless infrastructure yeah and so uh to add to that I mean we
designed it and uh for player zero in mind of being completely censorship resistant uh things we do Beyond uh anybody can move messaging right uh but we not order enforce all messages so things can't be drop packets can't be dropped like if not to 10 comes and then 11 after that 11 can't be delivered till 10 gets delivered meaning that you have to stop all of layer 0 messaging or none of layer zero messaging uh and so it's an all or nothing thing and since the contracts aren't upgradable uh it means that uh even if someone wanted us or forced us to put a library out there that had censorship in it applications can opt just not to use it uh and and that is the the key thing one of the key things I want to drive home about
Library upgrades is that uh not everybody not every application have to have the same parameters right uh like we built it in a way because we might have new features to add in the future but like we could have there could be a layer zero where there's a DK roll-up version there's a ZK version there's an optimistic version there's the ultra light node version we have now and applications can choose which security properties that fit their needs at any given time and still maintain uh the censorship resistance that layers here has uh if that's great in general I'll add a couple of comments for me as well I agree that Bridges and the layer zero teams and even lay tools should be just
infrastructure they shouldn't be deciding what happens and what you're in they should interact as Judge Judy and executioners so um yeah neutrality there like maybe we need a term blockchain neutrality or something like that that's super important um so apart from that let's see if anyone else has anything any question from the audience or I'll throw in one mind so we talked about a bunch of different types of bridges here uh but there is another one which we didn't touch or another type which is I think Super interesting the Avalanche Bridge which is technically just an externally owned account but they have some MPC of chain has any one of you looked into their architecture maybe you can comment on it
I I would say it's similar to kind of the the multi-sig type Bridges because like ultimately someone still owns the Amazon account um the the you know is running the secure Hardware or wherever they're running that secure hardware and you know if you know one of these state level actors or sophisticated attacker can you know get that or they can uh insert an employee in the organization or or you know which we've seen multiple times then then those funds could still be uh taken yes I agree so what what I said about multisig about multistig bridges holds for all multistig bridges yeah that's a good statement um so I think uh that is it for
questions uh thanks for thanks panelists all of you for being here it was a super interesting uh session and we got to learn a lot