Burning Bridges is a Twitter Spaces series where we examine different mechanisms for crosschain and crossrollup bridges, and evaluate their security!

Session 2 introduces a walkthrough of the LayerZero whitepaper and model and general basic concepts around trust-minimization, economic security, and tradeoffs for bridges.

Alrighty, I think we should probably go ahead and get started.

I think there's definitely going to be people continuing to jump in as we get going, but I've dropped this link into a bunch of different places already.

Previously on burning bridges, you can see the in the pin tweet we have last week's episode.

So if you're listening to this in the future, you should go check that out.

Last week, we talked about what it means to be trusted and safe and decentralizing crypto.

What happens when builders don't talk about security first mindset and build with that.

And kind of how to think about trade offs when you go 1 direction or another when it comes to the trust, safety and decentralization triangle.

This week we're talking about Layer 0, and first we should talk about the news from Bridging since we kind of met last.

Well, You know, I think maybe the first thing we should talk about is maybe any swap because that happened first and then Obviously the big thing that happened yesterday Hold on I'm grabbing a tweet for any swap but The deal there is that there was a vulnerability in their token contracts that required users to revoke their authorization.

We're still at the stage where the kinds of attacks that we're seeing on these protocols are attacks related to contract security risk and not attacks related to like their actual economic models.

So like, while, you know, while this is obviously as competitors to these projects, it's obviously like a great time for us to be able to like, you know, fling shit and say, oh, well, these models don't work.

The reality is that that could happen anywhere.

It could happen in a roll of contract, it could happen in the ETH2 deposit contract, it could happen just about wherever anyone has written any code.

And that's part of like why building in this space is incredibly difficult and also part of why in the past it took a lot longer for protocols to really like get to the point where they had such a high amount of value under their control is because people were generally a little bit more scared to ape, though that's changed a little bit now as more people have come into the space.

And the numbers overall have gotten higher, So the perceived risk has gotten lower.

Yeah, and that same thing applies to the wormhole exploit.

I mean, in so far as I understand how the exploit worked, there was basically just this verification step that could be bypassed just due to a bug.

So whatever you think about different trust models of bridges and of chains and trust minimization, that really doesn't have to do with how this exploit happens.

So it's not really the time to gloat about the importance of trustless bridges and things like that.

There's been a lot of takes in that direction, and a lot of takes about, oh, this is why we shouldn't do cross-chain bridges, this is why we should only live on ETH, and it's, yeah, that just doesn't really apply here.

Even more ETH or L2 native things could, are vulnerable to this type of bug.

Because as you say, it's just sort of an implementation bug.

And this, these, these, you know, we're still maturing on that level.

So it's time to, it's a time to be humble and recognize that.

And yeah, I mean, in, in, in other situations where it is like the trust model that goes wrong, you know, like, I don't know, Quadriga, maybe that's the appropriate time to sort of talk about the importance of fresh minimization.

I gotta say, 1 of my favorite things to come out of the Quadriga Wonderland all that all the brouhaha.

There is the the funds are with Sifu memes I've been really enjoying that But yeah, I think what we're looking at is basically Maslow's hierarchy of security, right?

So the underlying, I think James has a good way of describing it, the root of trust doesn't matter if the application layer is busted.

And here, the issue was with smart contracts again.

So if you're dealing with issues at the application layer, people need to I think, I think a lot of this the issue here is with solidity.

It's quite hard to write good applications where you can reason about what's going on and I think a lot of that needs to get solved whether it's at the cross-chain use cases or just even on 1 chain.

So Daniel, I think you referenced some people were basically like Vitalik is correct, I'm going to only stay on Ethereum now.

But how many hacks have happened on Ethereum because of smart contract vulnerabilities?

Yeah, it's like this sort of thing isn't really like bullish for any 1 specific worldview or any 1 specific category.

It's just bearish for the space overall because what this means is just in general, building this stuff is incredibly difficult.

And while there are a lot of, like I've personally talked to a lot of people who are building on top of some of these, some of these admittedly more trusted bridges, but their trust models really don't necessarily apply in cases like this.

But most of those projects have said, oh, well, we're building on top of them because they're huge and now they're too big to fail.

Like if you look at the average hack size, it's been growing pretty steadily over the course of the last couple of years.

And it's not, it won't be long before we start seeing multi-billion dollar hacks.

Yeah, I mean, the way things are going, though, it's just none of these bridge hacks that we've seen so far have actually been compromises in the security model of the trust model of the actual bridge.

They've all been kind of programming errors.

You know, TorChain was a bad Ethereum block transaction parsing.

You know, PolyNetwork was like something with dynamic dispatch and EVM.

And Wormhole was using an old outdated precompile in the Solidity side of things.

So it's just like, I think the key takeaway here is that we as bridge builders and operators need to focus on kind of operational security and like excellence in, I don't know, programming.

Because it turns out, not the trust model.

I don't think Wormhole was the Solidity issue, it was on the Solana side.

Maybe we're jumping too deep into it, or maybe it's the right time to go into what happened.

So I think 1 thing I'd like to mention, and I don't want to spend too much time on this, but this is definitely an important piece of the wormhole hack that I think people are a lot more cognizant of, which is that creating wrapped assets does present systemic risk.

So while it's true that yesterday's hack was not really a result of the trust model itself, it really could have been.

Like the Solana contract was really just spoofing, the hacked precompile was spoofing the validator set of the contract.

And so if the contract had had a different model, trust model, it wouldn't necessarily have, may not necessarily have had the same type of effect.

So this is 1 of the reasons that I like Nomad, for instance, as an alternative for wrapping assets, is just that there is an explicit 30-minute latency for doing transactions across chains.

And that adds time for reacting to things like this.

It is entirely possible that a contract bug could exist in Nomad.

But in many cases, the surface area is lower because in many cases, the protocol, if something went wrong with the protocol and you were able to create mint funds out of nowhere, bridging them back would actually be quite difficult.

It would take 30 minutes and in that time you know, it's possible that people can could notice that that actually happened and then go through Nomads existing fraud proof system to like disconnect the Nomad channel I'm

a little I'm a little hesitant on this because I think it's akin to maybe CZ Asking if we can reorg a chain in order to basically like stop that Binance hack or whatever from happening, right?

So the fraud or dispute window is more to prevent an updater for that basically fraud from happening at the root of trust.

If there's an application level or layer vulnerability using that dispute window to prevent that seems like you're almost misusing the system.

It does leave the possibility, but I think that's something that a community or governance would have to decide whether that's appropriate.

I guess my point here is that in general, the risks of creating synthetic or wrapped assets are far, far greater.

There's I guess like taking a step back, there's 2 general approaches to interop.

In the first case, you are minting an asset and you're creating basically a synthetic or wrapped version of that asset on another chain.

And the really quintessential example of this is WBTC.

And a lot of protocols kind of fall into this category.

Things like Solana, or sorry, Solana Wormhole, you know, Nomad, Multi-chain, et cetera, et cetera.

And then the other version is the protocol itself holds liquidity through liquidity providers and then dispenses the actual canonical token on a given chain.

And that canonical token, in theory, could be a native asset, though of course, in many cases it is also itself a wrapped asset.

In the first case, the token holders in perpetuity absorb the risk of the bridge, because the bridge is kind of what controls the underlying assets that are locked against this token.

And so this presents a huge problem, because if you then go on and use that asset in DeFi, you take out loans against it, you do a bunch of other types of activities, those all of those things becoming uncollateralized.

And it can cause these systems to kind of implode.

I'm actually incredibly surprised that that hasn't happened on Solana.

It seems like there was a little bit of like a price dip but then there was a there was a market correction.

I think a part of that is just that like the correct mechanisms haven't really even been built to think about this yet.

And so most of the trading bots are still kind of like trading, assuming that the price is steady.

I think the other thing there is it was almost a too big to fail event where Jump basically came in and said we would make people whole.

And that kind of, the bank run fear goes away when a well capitalized person is willing to come backstop the entire system, right?

Yeah, you heard it here first, hashtag bridge bailouts.

That might be a good segue into our topic of interest today.

Unless anybody else got anything to talk about regarding Wormhole or any swap?

I do think like, I mean, I guess as part of the segue, I do think like it is, I would like to reiterate that it's only a matter of time before we start seeing economic attacks on these systems.

You know, like chains get 51% attacked all the time.

But like smaller chains that have weaker security models, this happens to all the time.

I think it's, you know, we're still quite early, and so on most of these validator brace bridges, there are, the validators, the node operators are all people that are super close to the team, so they're very unlikely to actually rug the system.

But of course, that means that they're not really decentralized, right?

Like that means effectively the team is controlling what is happening.

Now the team, most, I mean, I highly doubt that any of these teams are actually gonna hack their own bridges.

But at the same time, it's not a long-term viable solution, right?

It could work for like a few years to have everybody aligned and assume that they will be aligned, but it won't work in perpetuity because eventually you want these systems to be permissionless and they will get civil attack.

And just the trust model, again, the trust model for these particular exploits wasn't directly relevant.

But that isn't to say that in the big picture, trust assumptions are not relevant.

Because of course they are, which maybe that itself is a nice segue into Layer

Yeah, so I pinned their introduction tweet to the space here.

Just for a little bit of background, Layer 0 is an interop protocol that came out of stealth a couple months ago.

It took the bridging community by storm a little bit.

They're launching here in a couple weeks.

And they're just marketing heavily around solving all the problems.

And maybe I'll, you know, I'd love to pass it to Arjun or Daniel to kind of talk about Layer 0 and, you know, a little bit more about like what they do and how they do it.

Yeah, I mean, I guess in terms of we can start with sort of what they're, what they're claiming, as you say, you know, you, you summarize it as solving all the problems, but like more particularly, it's, you know, generalized message passing system, essentially, between any 2 chains.

They're saying that it's trustless, so it doesn't involve trusted, trusted intermediaries.

And also that it's sort of easier to work with.

It doesn't require much additional infrastructure relative to other chains.

It doesn't require its own block chain for example like some of these bridges do.

It also doesn't require sort of an intermediate token representation.

If what you're doing, for example, is bridging tokens or doing some sort of Dexatomic swap thing, there's no sort of intermediate representation there.

There's certain other claims about permissionlessness that are kind of being made.

That's a little harder to pin down, but we'll get into all of those things.

So that's sort of the context of how this thing is being presented.

And then, yeah, we can start getting into how it works, unless I missed anything there.

Nope, I think that was a really good summary.

The only other thing I would add is that part of the reason why they've gotten a lot of interest in the last couple of months is because Layer0 came out of stealth a few months ago and then raised at a billion dollar valuation per product from Sequoia.

And I think that made a lot of the researchers get interested in what they were doing to try to understand what is going on.

And that's how we found out about it, how we ended up reading the white paper.

Or at least I ended up reading the white paper myself.

And I think it's a great example of how we can explain the point at which the trust model kind of turns.

You know, it's like you could have built Layer

in a trustless way, but it isn't necessarily, I mean, spoilers, it isn't currently built in a trustless way.

And unfortunately, building it in a trustless way is the hard problem.

And as far as that problem goes, we should just say, so the white paper is still, this is linked on their home page.

The title of the white paper is Layer 0 trustless omni-chain interoperability protocol.

And yeah, the trustless came is obviously the 1 that is sort of eye-catching, what we'll probably focus on.

Command-F, I don't know, they use the word trustless on 8 pages.

I don't quite see how many times here, because of the way PDF search works, but I think over 20 times they use the word trustless in the white paper.

So that'll probably be the crux of what we want to get to.

But there's also other questions around sort of the implications of this model and yeah, what can and can't be claimed about it.

So yeah, I mean, I can start by going into it and feel free to step in anyone wherever in terms of sort of what the model is.

So yeah essentially we we want to have a bridging system.

So we want the ability to sort of pass messages from 1 chain to another.

And this problem kind of boils down to, I don't know, having 1 blockchain sort of have information about the other 1 and know about the other 1.

The basic model is There's a few entities, but there's kind of 2 important ones.

There's this Oracle and there's these relayers.

And essentially the Oracle, so let's say that we're bridging from, let's say, Ethereum to Solana.

So you sort of want the Solana chain to know about what's going on on Ethereum via this layer 0 bridge.

You have this Oracle, which is some entity that posts Ethereum block headers directly on Solana.

And then you have this other entity, which is called a relayer, which posts basically transaction data of what's going on in those blocks.

And that transaction data, when posted, has to come along with a Merkle proof.

And that proof kind of proves that the claim about the transaction is indeed included in the block or in the header that the block represents that the Oracle posted.

Anything else to add there or anything I missed so far?

Yeah, I'll just add that, you know, it's an open system.

And they have like a community pool where you can kind of choose between which Oracles and relayers you might want to listen to.

So let's come back to the idea of an open system because I think that is an interesting, the framing there is important and is interesting, but maybe let's first 0 in on the trust model here.

So again, the claim is that it's trustless, at least in the white paper.

So, I mean, do we first want to briefly define what trustless is?

I can take a stab, or if anyone else wants to, maybe that would just be useful.

Yeah, that's probably a good thing to start.

It's always good to start with a definition.

So I mean, I think the way I think about it, like the best formal definition I've seen, I should have this tweet ready to pin, but I can I can dig it up?

But there's a paper that John Adler and Mipra Quinton Collins wrote, I can't remember the name exactly, but it has to do with a particular sidechain model.

But the preamble to that paper, it's sort of leading up to the model itself, is in my mind, 1 of the best sort of formalization of a lot of these terms that I've seen.

And they sort of introduced this notion of you know they like lead up to defining trustless in a formal way.

If you sort of 0 it in on this idea of owned state.

So there's some state that is assigned that has sort of some address, let's say, that represents the owner of that state.

So we're not totally generalized, but we're, you know, kind of capturing the important things, right, especially things like bridging tokens or bridging Ethereum.

And there's some system that this own state is inside.

You can sort of call that system trustless if it preserves safety and liveness.

This may be getting like a little too in the weeds, but like briefly, you know, liveness means that essentially up to, you know, as of some bounded time, the owner of that state will be able to move it or transfer it or sort of update it.

Safety means only the owner can update it as of some bounded time, which kind of roughly translates to, you know, your funds can't be stolen and your funds can't be locked up forever.

So a system that preserves those 2 things, if you have that guarantee, I would say I would say is trustless.

The big note is that your funds can't be stolen even in the case of like, like so and this is the point where things get a little bit more interesting and messy, which is just like, you know, there's like trustlessness as a core concept of a property where you're building a system on top of another system.

And then there's like the crypto economic security of the system itself.

So like you can imagine, you know, like this is this is not this isn't currently the case and it's not going to be the case because realistically there's the amount of economic security that you would need to do it is huge.

But you can imagine, for instance, a bridge that is built 1 day that is realized on like an external validator set and the security of that external validator set is far, far higher than the security of Ethereum or Bitcoin.

And in that case, you know, of course, the bridge isn't being validated by the underlying chain itself.

But because the security of that validator set is higher, it is effectively trustless, right?

It is possible for this external validator set to censor you or steal your funds, but the amount of money it would take to do that is greater than the amount of money it would take to DOS Ethereum itself.

Now the caveat here is that bridges are not like chains.

In a chain, you can't actually steal funds.

You can 51 percent attack and create a fork, but people can still fork away into a canonical fork.

Whereas in a bridge, you can actually unlock the funds.

But at a high level, I just wanted to go over the concept of crypto economics.

1 other note here, I noticed that Brian from Layer 0 is here.

Brian, we're just going to step through the white paper and give our thoughts.

And then we'd love to have you up here as well to chat.

So I guess just from that, we can get to their notion of trustlessness.

So basically the question now is okay we have these 2 designated parties you have an Oracle you have you have this Oracle you have this relayer and again Oracle is responsible for posting block headers then the relayer is responsible for sort of transporting the relevant data.

The question then is who's to say that this will indeed be valid, right?

Who's to say this is indeed, again, if it's an Ethereum to Solana layer 0 bridge, let's say, who's to say this header is indeed a valid Ethereum, represents the header of a valid Ethereum block.

And then if it isn't, we could just include any old message in there and steal your money.

And basically, the model that they outline is, what they point out, which is true, is that in order for something invalid to happen here, both the Oracle and the relayer would have to be well, essentially, both would have to be malicious and colluding is maybe the strongest form of the statement.

But that's basically what it comes down to, right?

The Oracle would have to post an invalid block and then the relayer would have to sort of have some access to this data, this invalid data, right?

That's not presumably not really available on Ethereum because it's invalid.

And then again, they could post an arbitrary message.

So that is the core assumption is that there's these 2 entities, but if they are not colluding, then we cannot have an invalid update.

And then we sort of conclude that the system is trustless.

So 1 thing that I, so we can get into the problem with that core statement.

So that, by the way, that assumption is written several times in the white paper.

But unfortunately, there isn't actually a good explanation of why that assumption holds true.

So if you look at, if you kind of like look at section 2 in the meat of the white paper, you'll see that there is a pointer which says, okay, we'll show later why this assumption is true.

And then there's you read further down and you see that it says, okay, well, we show in section 1 that because of the way that the system is constructed, there is no way to have real layer oracle collusion.

And if you go to section 1, you see that it says we assume that there is no real layer oracle collusion.

So that's actually something that isn't really addressed in the white paper directly, though I think in speaking and posting about this on Twitter, I think I've seen Brian post a couple of responses to it, which we can get to afterwards.

Before we jump into that, though, I would like to say, there is something that I do like about the Layer 0 model.

So the way that this works is it's basically like a two-phase commit.

You have this proposal that is posted by an oracle, and then you have a verification step that happens on behalf of the relayer.

So the verifier in this case is some external party, or it could be a set of parties, or it could be an application itself.

And the way that Brian has described it on Twitter a few times is that it's really the application that kind of opts into what relayers they want to use.

And I think that there's something interesting about this, because the core property, and this is something we talked about last time, that the core property that all this bridge security relies on is who is the verifier.

And so in layer 0, you can actually just plug in the verifier.

See all Burning Bridges transcripts on Youtube

Analyzing LayerZero - Burning Bridges Session #2