See all Burning Bridges transcripts on Youtube

Speaker 1

00:01

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.

Speaker 2

00:17

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.

Speaker 2

00:33

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. There's a lot that's been going on.

Speaker 3

00:55

Yeah, what are you talking about? Anything interesting happen lately?

Speaker 2

00:59

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.

Speaker 1

01:23

Yeah.

Speaker 4

01:26

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.

Speaker 4

01:55

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.

Speaker 5

02:38

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.

Speaker 5

02:55

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.

Speaker 5

03:22

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. But yeah, not now, not today.

Speaker 3

03:45

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.

Speaker 3

04:13

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.

Speaker 3

04:42

But how many hacks have happened on Ethereum because of smart contract vulnerabilities? The amounts there are insane.

Speaker 4

04:50

Right. Yeah. 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.

Speaker 4

05:06

It presents massive systemic risks. 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. And I don't really think that's true.

Speaker 4

05:30

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.

Speaker 2

05:40

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.

Speaker 2

05:58

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.

Speaker 3

06:26

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

Speaker 4

06:30

that was the Solana.

Speaker 2

06:31

Excuse me, sorry.

Speaker 3

06:33

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

Speaker 4

06:39

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.

Speaker 4

07:19

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.

Speaker 4

07:49

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

Speaker 3

08:23

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.

Speaker 3

08:51

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

Speaker 4

08:58

Yeah. Yeah. 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.

Speaker 4

09:17

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.

Speaker 4

09:40

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. But we can get to that later. 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.

Speaker 4

10:18

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.

Speaker 4

10:42

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.

Speaker 3

10:54

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?

Speaker 2

11:11

Yeah. Yeah, you heard it here first, hashtag bridge bailouts. It's a new era.

Speaker 3

11:19

Yeah, we are the 99% occupied bridges.

Speaker 2

11:23

Occupied bridges. 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?

Speaker 4

11:37

Not really. 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.

Speaker 4

11:51

It's a thing. 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?

Speaker 4

12:20

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. I think that would be crazy. But at the same time, it's not a long-term viable solution, right?

Speaker 4

12:36

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.

Speaker 5

12:47

Yes, right. 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.

Speaker 5

12:57

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

Speaker 1

13:02

0.

Speaker 2

13:03

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.

Speaker 2

13:15

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.

Speaker 5

13:31

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.

Speaker 5

13:54

So it's low cost. 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.

Speaker 5

14:08

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. You just sort of get the thing you want. And there's maybe the hazier thing. There's certain other claims about permissionlessness that are kind of being made.

Speaker 5

14:25

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.

Speaker 4

14:39

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.

Speaker 4

15:03

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

Speaker 1

15:25

0

Speaker 4

15:25

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.

Speaker 5

15:36

Right. And as far as that problem goes, we should just say, so the white paper is still, this is linked on their home page. Have it open here. The title of the white paper is Layer 0 trustless omni-chain interoperability protocol.

Speaker 5

15:48

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.

Speaker 5

16:07

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.

Speaker 5

16:33

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.

Speaker 5

16:56

Why not? Just a random example. 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.

Speaker 5

17:12

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. So, are we so far so good?

Speaker 5

17:36

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

Speaker 2

17:43

Yeah, I'll just add that, you know, it's an open system. Anybody can run an Oracle. Anybody can run 1 of these relayers.

Speaker 2

17:51

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

Speaker 5

17:59

Yeah. 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?

Speaker 5

18:18

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

Speaker 2

18:21

Yeah, that's probably a good thing to start. It's always good to start with a definition.

Speaker 5

18:24

Yeah. 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.

Speaker 5

18:51

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.

Speaker 5

19:13

There's this state and somebody owns it. 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.

Speaker 5

19:39

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.

Speaker 4

19:54

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.

Speaker 4

20:28

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.

Speaker 4

21:07

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.

Speaker 4

21:22

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.

Speaker 1

21:41

Cool. Sorry. Go ahead, then.

Speaker 5

21:44

Yeah. 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?

Speaker 5

22:06

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. And we can unpack that a bit.

Speaker 5

22:42

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.

Speaker 5

22:59

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 thoughts from the panel.

Speaker 4

23:15

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.

Speaker 4

23:29

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.

Speaker 4

24:08

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. In layer 0, this is a generic.

Speaker 4

24:27

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.

Speaker 4

25:03

However, the problem is that this model doesn't actually present a new verification mechanism. So if you have the relayer be the user themselves, and the user is basically verifying the block header and then signing to approve it on their own, then it's a locally verified system. And in fact, that construction would actually be exactly like Connects. So you would have the oracles in layer 0 would be our connects routers.

Speaker 4

25:32

The user would be the relayer, and they'll be verifying their own transaction. And that would be trustless, because the only parties to that transaction are the user and the oracle. However, on the other hand, if you're using an external set of relayers, now the trust kind of relies on that external set of relayers. And it actually, it presents this interesting problem where it's like, you know, if you want to do generalized message passing, you can only make it trustless if the entity that owns the funds and data is the 1 that's verifying that those funds and data have been relayed across chains correctly.

Speaker 4

26:07

And that concept gets extremely fuzzy when the owner of the funds and data are a DAO or a smart contract, right? Because there's no real logical owner at that point. And so, you know, if you minted a token across chains using layer 0, there would be no, there would really be no way to like, prove, like you're really just relying on the security of the relay and the validator, the relay and the Oracle themselves. You're not actually proving anything on chain related to the ownership of the funds and data themselves.

Speaker 4

26:41

And I think that's a pretty important point to consider when looking at a lot of these other systems as well. So this is why I was saying it's a good example of how you can understand different verification models. Because for instance, you use another system, if you have the relayers be an external set of actors, like an external set of NPC actors, then the model looks a lot like most of the validator bridges. And on the other hand, if layer 0 had a way, and this is also the really difficult part, if layer 0 had a way to make it so that the proof that was being posted by the oracle was being verified within the virtual machine of the chains, i.e.

Speaker 4

27:23

The relayers in this case are actually the chain's own nodes or validators, then that is trust minimized. And that is actually basically what IDC is. So yeah, it's a good example of pinpointing exactly where the trust model comes from in these bridges.

Speaker 3

27:43

Yeah. So maybe a devil's advocate question, which is that, why not have the application run the verifier or the relay in this case? Because a lot of the times the application and the end user have incentive alignment. The application presumably doesn't wanna screw over its own users.

Speaker 3

28:00

So have them kind of play the relaying role. What's wrong with that?

Speaker 2

28:03

Yeah, and maybe just kind of a more general question, like where do you place the root of trust when you're building systems like this? Do you move it down the stack, which is in my opinion, a little bit more broke, and do you move it up the stack a little bit more woke?

Speaker 5

28:17

Yeah, I mean, I think if you sort of delegate relay responsibility to the application layer, I mean, you know, we could, that's fine. And we could sort of talk about, we could talk about that model and its security implications. I just don't see any way you could call that trustless because now you are quite literally assuming that this, you know, these 2 particular designated parties are not polluting.

Speaker 5

28:36

Again, I think that model might have interesting things about it, but I just can't, I can't contort the word trustless in any way that it encompasses that. The idea of where I think this gets a little trickier to even talk about is this idea that it's kind of an open system. You can sort of, you know, anyone can run Relayers, anyone can run Oracles. And I think like, the way I think about this is there's an important distinction to make here or it's important to sort of get down on what exactly we mean by permissionless, right?

Speaker 5

29:06

So a sort of kind of extreme and kind of meaningless use of the term permissionless kind of boils down to something like, okay, we have a system here and it's permissionless because anyone can sort of deploy their own copy of it and interact with that 1. And then you can just choose which 1 you interact with, which is not really what we mean by permissionless, right? I mean, by that definition, you know, by that definition, literally a permission side chain is permissionless if the code is public on GitHub, because everyone, you can just launch your own permission sidechain. So it's really when we talk about open and permissionless, you're talking about which parties have the rights to sort of interact within the system and participate in it.

Speaker 5

29:44

And so you can certainly have, I mean, I could see a situation where, you know, there's a, there's kind of this group of relayers and app can sort of pick which 1 they delegate to. They can even, you know, delegate to relayers that come to some federated consensus, that sort of thing. But what you certainly can't do, what would just sort of work this whole system is have, for example, a designated Oracle and then permissionless relayers. So if on the correct level, I say, okay, I accept any relayer, I accept any message of relayer posts so long as the Merkle proof is valid, essentially.

Speaker 5

30:24

In that version of things, for example, the whole thing just reduces the trust in the Oracle because now the Oracle can just become their own relayer and update arbitrarily. So in order to have any hope that there isn't collusion going on between Oracle and Relayers, as far as I'm concerned, I would say these parties just need to be permissioned. The Oracle as well, right? You can't have anybody posting block headers, maybe for more obvious reasons.

Speaker 5

30:46

So that's sort of how I think about in terms of like the openness and how it relates to the trust model. I don't think it's really quite right to call it permissionless, not that they do that particularly, but yeah.

Speaker 2

30:59

Yeah, maybe a more generous term is trust minimized.

Speaker 4

31:04

Yeah, well, I mean,

Speaker 1

31:06

yeah, go ahead.

Speaker 6

31:08

I would

Speaker 4

31:08

say the issue with that is just like, when you say trust minimized, the implication is that like fundamentally it is, you know, as trustless as it possibly can be. And the users are able to fairly easily understand what the root of trust is for the system overall. Whereas in this case, the root of trust kind of turns on who the relay ends up being.

Speaker 4

31:38

And I think just kind of following what you said, Daniel, there's actually a core principle here which is really important. And this is just like a principle of cryptoeconomic systems. The concepts of collusion resistance and permissionlessness do not overlap. So there is no way to have a system where you are fundamentally assuming that collusion will not occur where that system is also permissionless.

Speaker 4

32:04

This is actually 1 of the big reasons why blockchains are, and like, you know, like we've had like BFT consensus for a while. 1 of the big reasons why blockchains are actually, and like the Bitcoin blockchain was such a leap forward in terms of our understanding of distributed systems is that it made it like it wasn't possible to, you know, say with certainty that there wasn't going to be a like an arbitrary number of anonymous providers coming into the system and civil attacking it. However, what they did was they what Satoshi did was he made that explicitly really, really expensive to do. And there was a there's a materialistic there was a very material cost to doing that, which grew over time, which made the system, so it's like it's a permissionless system, but it gives the system collusion or civil resistance intrinsic to the system itself.

Speaker 4

32:57

Now, if the core thesis of Bitcoin was that it's assuming that there is not collusion amongst Bitcoin miners, then you couldn't allow anybody to be a Bitcoin miner. Those 2 things are fundamentally incompatible ideas.

Speaker 5

33:11

Yes, exactly. Exactly. Yeah.

Speaker 5

33:14

Yeah. So I was just going to add. No, yeah. Sorry.

Speaker 5

33:17

Please finish.

Speaker 6

33:18

No, no, go ahead,

Speaker 5

33:18

go ahead. I was just going to add to that, just maybe another way of sort of thinking about that, what you just said there is, or maybe just reframe what I said earlier to make it a little more clear. At least the way I would think about it is the situation where there's a network of oracles you can select from and even a network of relayers you can select from does not make the system itself permissionless.

Speaker 5

33:37

It's more like you have a series of permission systems and you can opt into which 1 you choose. Which, you know, that might be better than having 1 permission system, for example. But that's where, that's the sort of haziness there and sort of in some sense in that version of things, you know, network of oracles, network of relayers, you sort of are having just multiple bridges, which is different than a single permissionless bridge for the reasons that I think you just articulated that has to do with, yeah, the assumptions about collusion.

Speaker 2

34:11

Is it worth bringing up? Go ahead, Pranay.

Speaker 3

34:14

No, I think I was gonna say the same thing, which is that I think we should bring Primo up. Because if somebody was talking about my project or baby, I would also want a chance to respond.

Speaker 2

34:24

Yeah, exactly.

Speaker 1

34:29

You can speak now. Sorry. There you go.

Speaker 2

34:32

Hey there, Brian. Thanks for being so patient with us.

Speaker 6

34:34

Let me see, am I here now? Yeah, you're here. Okay, awesome, hey guys.

Speaker 6

34:39

Yeah, I actually think for the most part, what you've said is fairly accurate. I do think 1 thing, I was just typing up a tweet tonight, I intend to say it here now because it's easier. 1 thing I think you guys are particularly misunderstanding is that in each of these systems, you're kind of making assumptions about what the systems look like. Like imagine a world where the Tendermint validator set is actually like the acting relayer for relaying transaction groups or block headers or, you know, any piece, right?

Speaker 6

35:05

Well, when a validator set on each side is basically playing the roles of this Oracle relay, right? There is no real constraint on what those systems look like. And I think that's something where right now, I don't necessarily, or it seems like you're not sort of picturing that view where it's not necessarily just like oh 3 oracles in the sense of how we think about oracles today or a relayer and you know maybe maybe it's a single SGX server or maybe it's like this distributed network of nodes, but it can look like the whole point has been that we've left this as modular as humanly possible. In Oracle is any system that takes a block header and there really is any system that really is a transaction proof.

Speaker 6

35:43

So that could be a fraud proof system. That could be a POA system from a set of validators. It could be a complete validator set. So yeah, I'll stop there for a second.

Speaker 4

35:54

Yeah, I definitely.

Speaker 6

35:56

I was just going to say

Speaker 5

35:56

it's a

Speaker 2

35:56

good time to maybe just mention that Layer 0 leverages the chain link network, specifically around oracles. And that kind of plugs into Brian's point.

Speaker 6

36:06

It is

Speaker 4

36:06

1 of the oracles,

Speaker 3

36:07

yeah, 100%. I think Primo's main point is that these 2 actors can, in the future, be generalized to be other systems that have better trust models. But I think maybe the smooth brain way of interpreting what we've been talking about is less that this is a valid model.

Speaker 3

36:26

Like, I know people building on layer

Speaker 1

36:28

0,

Speaker 3

36:28

and it has value because it's fast and cheap and allows apps to go quickly multi-chain. I think that's a really important service and together we're building this category. But I think the main point is misrepresenting where it is now.

Speaker 3

36:41

We're using words like trustless and permissionless, makes it seem like it's the holy grail at this moment, which I think causes a disservice to the space because users may have a misunderstanding of what they're opting into.

Speaker 4

36:54

Following up on this, so this is kind of related to what I said earlier. I like the layer 0 construction in that it is a generic, right? It's not, it isn't actually a bridge.

Speaker 4

37:03

It's just a, it is base infrastructure for message passing across chains where you can plug in an arbitrary verifier. And, you know, it's actually incredibly useful. Like this is, you know, if layer 0 had existed as a concept, like a year ago when everybody was building bridges, I have no doubt that everyone would have just used it because it would have saved us all the trouble of having to like build custom infrastructure to go across chains. You know, it, each team ended up having to do this by themselves over and over again for no reason.

Speaker 4

37:34

However, I think that's actually the piece that's important here is that like the security model of the verifiers is not actually a core part of how layer 0 works at all, right? It's the idea is that like that security model can be anything. It could be a Tendermint validator set, in which case it looks like Cellar. It could be an MPC system, in which case it looks like MultiChain.

Speaker 4

37:57

It could be an optimistic system, in which case it looks like Nomad. But the issue that I have is that the way that it's represented currently says that it is a trustless bridge. And like, it's almost, it's sort of like a misnomer because it's not really a bridge, it's infrastructure for bridges. And like, the trustlessness itself, the point at which it either is or isn't trustless.

Speaker 6

38:27

Yeah, again, I don't disagree. We certainly don't represent for, think about ourselves as a bridge, right? We think about it as a generalized messaging system or infrastructure for that, right?