In this episode, we sit down with Anna Carroll (Protocol Lead at Nomad) and Arjun Bhuptani (Founder of Connext) to discuss the blockchain interoperability trilemma, bridge architectures, Nomad’s optimistic design, and much more.

Show Notes: 
(00:00:00) – Introduction.
(00:02:58) – The interoperability trilemma. 
(00:09:01) – Categories of bridge design architectures.
(00:14:18) – Diving into Nomad.  
(00:31:17) – Optimistic interoperability vs optimistic rollups.
(00:44:35) – The relationship between Connext and Nomad.
(00:51:05) – Exciting cross-chain applications.  
(01:07:50) – Are bridges a zero sum market?
(01:15:41) – The Ronin hack and security design.
(01:23:44) – Closing thoughts. 

Social links:
Arjun’s Twitter: https://twitter.com/0xarjun 
Anna’s Twitter: https://twitter.com/annascarroll 
Nomad Twitter: https://twitter.com/nomadxyz_ 
Nomad Discord: http://discord.gg/nomadxyz 
Connext Twitter: https://twitter.com/connextnetwork 
Connext Discord: https://discord.gg/connext 
Resources: 

Nomad Website: https://www.nomad.xyz/
Nomad Docs: https://www.nomad.xyz/ 
Connext Website: https://www.connext.network/ 
Connext Docs: https://docs.connext.network/ 
The Interoperability Trilemma: https://medium.com/connext/the-interoperability-trilemma-657c2cf69f17 
The Nomad Design Philosophy: https://blog.nomad.xyz/the-nomad-design-philosophy-6fc0eacf3263 

More
💬 Follow Delphi Podcast on Twitter: https://delphi.link/PodcastDelphi 
✅ Follow Delphi Digital on Twitter: https://delphi.link/twitter  
🧠 Access Delphi's Research: https://delphidigital.io/pricing 

Disclosures: This podcast is strictly informational and educational and is not investment advice or a solicitation to buy or sell any tokens or securities or to make any financial decisions. Do not trade or invest in any project, tokens, or securities based upon this podcast episode. The host may personally own tokens that are mentioned on the podcast. Our current show features paid sponsorships which may be featured at the start, middle, and/or the end of the episode. These sponsorships are for informational purposes only and are not a solicitation to use any product, service or token. Delphi’s transparency page can be viewed at https://delphidigital.io/transparency.

We've seen so many bridge hacks happen, whether they're a smart contract bug or a compromise of keys like Ronan.

These hacks might have been prevented if there was an optimistic window or some kind of delay that could have allowed time for external actors to respond to the threat.

You're now plugged in to the Delphi Podcast.

Today we have 2 guests, Ana Carroll, protocol lead at Nomad, and Arjun Bhutani, founder of Connext.

Today, we're going to talk about everything bridges and the Connext and Nomad solutions.

But before we do, Arjun and Anna, would you please introduce yourself?

I'm 1 of the founders and project lead of Connext.

Connext is a interoperability protocol that lets you move funds and data across chains.

So you can kind of think of Connext as like the liquidity layer to Nomad's messaging layer.

building, basically researching and developing Layer 2 scalability solutions on top of Ethereum.

And then we ended up pivoting into Interop in 2020 because we just realized that there was this very, very big problem around L2 fragmentation and being able to actually build applications that make sense to users that aren't really fragmented across many different ecosystems.

And we went live with a network to do this in the start of

Nomad is an optimistic interoperability protocol.

We pass messages between chains and developers can use that to build applications on top of Nomad.

I work on our smart contracts, particularly Solidity and everything related to that.

I'm excited for this conversation and we're going to get in the weeds later on in the back half.

And to begin, we're just going to set the scene.

Now if you're a user or a listener who doesn't understand the importance of bridges, This is probably not the podcast for you.

We're going to skip over all of that so you guys don't need to explain it.

Now they're important for cross-train asset transfers and smart contract calls and many other things and interesting designs that could be built on top of these systems.

But I want to start with some of the challenges of actually building these systems.

And Arjun, you wrote an article last year titled Interoperability Trilemma, aka why bridging Ethereum domains is so damn difficult.

So would you mind telling our listeners why the Interoperability Trilemma, aka why bridging Ethereum domains is so damn difficult?

So 1 of the kind of annoying gotchas with building anything on top of blockchains, and I think this is true for any sort of distributed system, is that there are always trade-offs around desirable properties that you want as part of your system.

If we think about what we want the ideal bridge to look like, the ideal bridge is cheap, fast, it allows you to pass any kind of arbitrary message between chains, it's easy to deploy to many different chains, and then lastly it retains the core security properties of the chains that it operates on top of.

What we found is that it's actually very, very difficult to get all those properties at the same time.

So when I wrote that article, at the time optimistic bridges as a concept were not really around yet.

I mean, they've kind of been talked about a little bit, but we were largely analyzing the trade-off space around 3 of those properties, which is trust minimization, generalizability, so arbitrary message passing, and then extensibility, which is like, can you put the same system on many different chains very easily?

And what we found was that all of the different systems that existed ended up having to sacrifice 1 of those trade-offs, 1 of those properties, in order to be able to function correctly.

So the existing version of Connextless live on mainnet and has been live for some time, utilizes atomic swaps.

Atomic swaps are a mechanism to trustlessly basically take liquidity on 1 side and then swap it for liquidity on another side between 2 chains.

And they are very easy to deploy to many chains, and they retain a lot of the core trust minimization properties of the underlying chains.

But the downside is that you can't use them to do generalized message passing.

And we found that the same kind of thing existed for other types of bridges as well.

So externally verified bridges, which include everything from multi-sig bridges to MPC systems, TSS systems, POS systems like Axelar, stuff like that.

All of those also now introduce this new security assumption where you have an external set of verifiers, external set of parties that are validating data that goes between chains, and now you've introduced a new trust assumption against the chains themselves.

And so in the case of these externally verified systems, you're able to use them on many chains very easily, you're able to do generalized message passing, but they're not trustless.

When NOMAD came along, we kind of had to change this mental model a little bit and change it from a trilemma to a quadrilemma, because Nomad actually does get all 3 of these properties at the same time, but it does it by sacrificing something else, which is, in Nomad's case, latency.

So you have this very, very reasonably trust-minimized solution that is able to be deployed very easily to many different chains, and it can pass any kind of arbitrary messages.

But the downside is that it takes 30 minutes for a message to go across chains.

So yeah, the key takeaway from this is just that there is no easy way to actually get all of these properties at the same time.

Any project that claims to be able to do all of these things at the same time is probably sacrificing trust minimization without really telling you.

And I'll just weigh in to say that part of our thesis, our engineering thesis at Nomad is that for cross-chain protocols, latency is a feature.

And what I mean by that is a couple of things.

Every cross-chain protocol often will have some latency, at least to reach finality on the sending chain.

There are a lot of chains like proof of stake chains that reach finality instantly or quickly, but chains like Ethereum, which are often at the center of this ecosystem, they have probabilistic finality.

So you have to wait a certain amount of time after a message is sent to ensure that that message has truly been sent from the perspective of the chain's consensus, right?

So every interop protocol has to have some latency on chains that have non-deterministic finality.

Additionally, we think that latency on the receiving chain is also a feature that most interop protocols will want to incorporate as time goes onwards.

The reason being that having interop protocols that basically perform state changes immediately as soon as a piece of information is passed to that chain, have no opportunity to respond to attacks, compromises, or threats to the system, which is why we've seen so many bridge hacks happen, whether they're a smart contract bug or a compromise of keys like Ronin.

And as we've seen, the only bridge hack that I know of that has been stopped was on an optimistic bridge, the near rainbow bridge.

And that was because there was a period of time where they could react to that.

So overall, we think that regardless of whether it's an optimistic interop protocol or some proof of authority construction.

Latency is a feature that's desirable in interop protocols.

And because of that, we think optimistic bridges have the best seat in the trade-off space.

A bit contrarian with the latency, and I'm sure we'll dive into that a bit later.

Before we do, I want to just make a point of the—in the article that you wrote, Arjun, on the trilemma, you ask a question of who is verifying the system and what are the costs of corruption.

I think this is a great way to look at the architecture of bridges because it essentially comes down to this verifying cost.

And I'm wondering, you mentioned it in your last answer there, but if you could just really explicitly overview sort of the 3 buckets that you've identified bridge designs falling into.

All right, it's 4 buckets once you include optimistic bridges, but the 3 buckets are, you know, the chains themselves are verifying any state update, which is what we call a natively verified bridge, so This is things like IBC, where you basically have 1 chain's validator set proving or basically figuring out some mechanism to verify updates from another chain.

And typically, this happens by just verifying consensus directly.

Then you have externally verified systems.

So you have a third-party set of validators that are taking data from here and verifying that it's correct against data that's over here.

So this is things like multi-sig bridges, includes everything from layer 0.

This is actually the vast majority of things that are out there fall into this bucket.

So it's everything from like layer 0, Axelar, etc.

To, you know, I mean, technically Coinbase is an externally verified bridge, right?

It's a very, very explicitly custodial 1, but there is an external verifier and that is Coinbase.

And then you have locally verified bridges.

This is kind of like the atomic swap case that I was talking about, where you don't actually have that.

You basically limit the possible types of state transitions to be ones where all you can really do are like swaps or basically some sort of mechanism where you are just allowing somebody else to do something on your behalf in an atomic way.

And in those cases they're locally verified because both of the parties of that transaction are only verifying each other.

So you don't need to involve anybody else in that system, and it reduces the overhead massively.

Lastly, with optimistic systems, you do, again, have a third-party set of verifiers.

But the role of that verifier set has kind of changed.

Where instead of validating that an update is correct, that set of verifiers now just proves, like it submits a proof if the update is incorrect.

The slightly different model, which is, you know, sort of like a 1 of n honest party model rather than a m of n honest party model.

I'm curious, do you think like in future there can be a new category in this framework that you come up with, Or do you think the design space has somewhat matured, and we all know constraints and the space pretty well at this point?

Basically, what it comes down to is, are there other categories?

And then what do you need to do to expand those categories, or the existing categories?

It's possible, but at the moment I don't think so.

I think there's only a limited set of people that could possibly verify updates that happen between chains, and they will inevitably end up falling into 1 of these buckets at this stage, at least from what I can tell.

So I think, For example, in the optimistic space, we are just only just starting to scratch the surface of optimistic bridge designs.

And there is a lot that's out there that could be possible.

For example, there's a bridge design, there's a Beamer bridge or something like that, that was made by the BrainBot team, that uses a slightly different optimistic design than Nomad does.

And of course, it's like specifically targeted transfers only, but it makes some other sort of like trade-off concessions around not needing latency, but in sort of having an insurance mechanism effectively against it.

There's mechanisms like what UMA is doing that are sort of optimistic again, where you have somebody like front the liquidity for an exit, similar to like how Connexin Nomad would work together, But on the back end, you have this pool of funds that is used as insurance bond.

So I think there's an interesting design space that hasn't yet been explored there.

On the local verification side, To be honest, people have been doing locally verified cross-chain communication for a very long time.

We have optimized atomic swaps as much as we possibly could, and I think we're sort of starting to hit the limits of what can be accomplished there.

So I don't personally think that there's a lot more there than there has been.

And I would expect that for the other kinds of mechanisms, so externally verified mechanisms and natively verified mechanisms, we're in a similar spot where like in both of those cases, you would fundamentally need new cryptographic primitives or new sort of like tooling around cryptography to create better constructions, because that is the core dependency for both of them.

So I think we can slowly start to dive into like nomad so Like the optimistic bridge.

It's just evokes the optimistic roll ups In my mind because because the roll ups at the end.

They're just bridges chains with some like trust minimized bridges.

So like when I look at it the obvious difference is that in the roll-up case there is sort of 1 place where that the base chain that guarantees the data availability, whereas in the NOMAS case, the data availability sort of is guaranteed by chain.

So what are some like implications of it?

And please take your time to like walk us through your design, your bridge design.

I have a piece of writing that I want to put out actually about this, comparing optimistic interoperability to optimistic rollups.

So I'll start by giving a little bit of baseline context for what Nomad is and how it works.

Nomad actually as a protocol is quite simple or elegant if you ask me.

Basically the way that it works is that on the sending chain there's a Merkle tree.

When users send a message, that message is hashed and inserted as a leaf into the Merkle tree.

There's an updater, that's an external actor that signs attestations of Merkle roots in this tree.

Those signed attestations can be relayed across chains.

It's trivial and uses widely available cryptography to validate an updater signature.

So their attestations can be accepted on the receiving chain.

The catch is that these attestations have an optimistic timeout period during which watchers or guardians of the system can come and block fraudulent routes from the replica.

Watchers are configured on the application level rather than the system-wide level.

And this means that applications can have more control and sovereignty over blocking fraud from the system-wide root of the updater.

So, in short, messages are enqueued, a bundle of those messages are attested to by an updater, That signature is relayed to the receiving chain, which kicks off an optimistic period during which guardians of the system can block fraudulent routes and slash the updater if necessary.

So kind of with that down, there's a couple of different things that I would emphasize comparing the security models of optimistic roll-ups with optimistic interop.

In both systems, there's what I would call a strict hierarchy of truth.

So both of these systems, optimistic roll-ups and optimistic interoperability protocols, you're attempting to post state transitions from 1 domain to another domain.

That, when I say domain, I mean basically kind of a source of block space or sort of a security boundary, a chain or a rollup or a side chain, et cetera.

So in both cases, you're trying to post state transitions from 1 to another.

In rollups, it's state transitions from the L2 to the L1, and in NOMAD, it transitions from the sending chain to the receiving chain.

In both cases, like I said, there's what I would call a strict hierarchy of truth.

So 1 domain is the arbiter of what is considered valid state.

In an optimistic rollup, the layer 1 is the arbiter of truth.

The layer 1 is where the decision about valid state gets made.

In Nomad, the sending chain is the arbiter of truth.

So if there's state anywhere else that doesn't match the sending chain, that's considered fraudulent.

This actually introduces something really interesting which is that fraud proofs and fraud games are a lot simpler to implement in NOMAD than they are in roll-ups.

The reason being that the place where state changes happen, that's the sending chain, is also the arbiter of truth.

Whereas in roll-ups, the place where state changes happen, the L2, is not the arbiter of truth.

So if there's a dispute about fraud, you have to, in a roll-up, you have to play a complicated fraud game to try to narrow in on some sort of proof that what has happened on the L2 is not valid.

Because the state change has happened in the same place where truth is decided, all you have to do is provide the invalid state change and it's simple.

Another thing that I would say here is that another difference I would highlight between rollups and interop in the optimistic design space is that in 1 design in rollups there's a strict hierarchy of power between these domains and in optimistic interop that's not true.

So in rollups if fraud is proven then the layer 1 has the power to roll back state on the layer 2.

The layer 2 is essentially subservient to the source of truth, the layer 1.

But in interop by definition, by necessity, there is no hierarchy of power between the 2 domains.

The sending chain and the receiving chain are basically on equal footing.

The sending chain can't roll back state on the receiving chain if fraud is proven, right?

So that's where watchers come in and that's why you basically need watchers in optimistic interoperability.

Watchers have the ability to block the channel.

They don't have the ability to change state on it.

So if fraud happens in optimistic interoperability, the only way to roll back and erase that fraudulent state is through governance.

The watchers can only block the channel so that those state changes don't cause harm until governance is able to go in and roll back that state.

Those are 2 big things I would highlight between optimistic roll-ups and optimistic interoperability.

I have all of this in a hack MD that I'm meaning to actually write up, because I know it's a bit dense.

So if I may summarize those 2 points, and this will be a very quick summary.

The first point is that the source of truth in the optimistic bridge design is basically the home chain.

So this is where the slashing occurs, the fraud proof is sort of resolved.

And the second point, And this first point basically encompassed the fact that you don't necessarily have a parent chain, baby chain kind of structure.

And the second point was that you cannot automatically through smart contracts roll back the state.

You can only like halt the system and then sort of social consensus kicks into play.

Whereas in the rollup case, you can just like roll back the state and keep going without sort of interference from like a social consensus.

So if I had to try to summarize it really quick myself, I would just say in interoperability, state changes and truth live in the same place.

However, in interoperability, there is no hierarchy of power between domains.

And if we were to like dive into a deeper implications of this design, so let's suppose that there was a fraud and the fraud is sort of public in the home chain, and a slashing occurs on the home chain, and so a bond gets slashed.

And then the recourse of that in the destination chain is basically that nobody acts on that message anymore.

And so that begs the question, couldn't this open like a griefing vector where like these watchers just like sort of attempt to halt the system as a griefing vector and what would be a way to mitigate such possibility?

There could be a griefing vector and that is inherent to this design.

There's a couple of mitigations that can be done.

First things first, it's important to emphasize that the watcher role, there's an untrusted element and a trusted element on the sending chain where the source of truth is anyone can be a watcher there and Slash fraud that is totally permissionless on the receiving chain it is a permissioned role to actually block fraud.

The reason is by nature, we cannot verify on the receiving chain for sure what happened on the sending chain unless obviously we have something like a full header relay.

So because you cannot prove definitively that fraud happened on the home chain, there has to be a permissioned role that's capable of blocking fraud.

So something I'd first emphasize is that watchers are permissioned and they're permissioned at the ZAP level at the cross-chain application.

So Watchers should be reputable actors who are incentivized for the application to succeed.

In Nomad's case, this is actually not that difficult to find.

Anybody who wants to move tokens across chains, right, there's a lot of stakeholders in that act who are highly incentivized to have this system function the way it needs to function.

If they're a user of the tokens on the other side, like Kinects, for example, if they're a user of the underlying message channel, they have a strong incentive for this message channel to be live as long as it's safe to do so, and shut down as soon as it's not.

So the first step is basically permission watchers that are incentivized not to do that.

The second thing is just that we explicitly made the design choice to limit this vector, not for the whole channel, for a per application basis.

So the trust that you're placing in 2 watchers is kind of, you can more tightly configure that, right?

It doesn't have to be that every app building on top of Nomad trusts each other's set of watchers, because the incentives might get a little bit out of whack there.

Whereas on a per application basis, there's a tighter loop to ensure that the guardians of that app actually care about it being live.

Aside from that, right, those are more social considerations.

Well, I can pause there, but I have other thoughts.

So another answer for how you could mitigate this would be on the actual mechanism design and crypto economic front.

So you could imagine a construction wherein watchers are similar to the updater also bonded on the home chain.

If fraud is proven on the home chain, which is permissionless, anyone can do that.

There could be any number of watchers doing that.

You could require that the watchers submits its own signature to attest that fraud has occurred within a given number of blocks from fraud being proven on the home chain.

In which case, it would again be permissionless to relay that watcher's signature to the receiving chain which would shut down the channel.

So in that case, you could basically bond a watcher and slash them if anyone can provide a signature showing that they incorrectly attested to fraud and slash them if anyone can prove that they did not attest to fraud when it indeed happened.

I think something that's also important to highlight here is like there is a set of...

So like the incentives around watching as a role in optimistic systems are still like being researched more broadly, even in other kinds of optimistic systems like optimistic roll-ups, and they were a pretty big topic of research in state channels as well, where there is like an optimization function that you can create around the amount of, basically, the incentives for watchers to actually correctly watch the chain and to get around what's called the verifier's dilemma, which is what incentive is there for people to actually perform these services if fraud doesn't occur very frequently, versus the incentives, the disincentive, for people to maliciously prove fraud.

And that optimization function is still, like, it's that's still something that that is being talked about, even in the rollup space.

And that's part of the reason why, like, you know, not, there's no 1 really watching rollups at the moment.

And and why like fraud proofs don't exist for rollups at the moment.

And so I think the idea, the thesis, and I actually really agree with this thesis for Nomad is that it's better to work on figuring out the material and practical solutions that can be implemented today that give us the best possible level of security while working towards a model that can actually end up becoming permissionless through the use of these kinds of incentives and mechanism design.

I think it's titled the Nomad Design Philosophy that goes over this.

We talk about safety as opposed to security.

Not that security is not important, but the distinction is talking about theoretical versus practical concerns.

We think Nomad holds up very strongly in the theoretical realm, but we measure our success also based on the true safety of our users in the wild.

So that is something that I would highlight in Arjun's point.

I think you're kind of going after a very robust design here, and these are definitely not easy questions to be answered and even harder to implement.

So yeah, I'm like, I really sort of, I'm very excited for how things will enroll here.

I will ask 1 more difficult security question, just because I'm curious how you think about it.

And then we can get into more fun questions after that.

So rollups currently, they sort of implement a one-week challenge period.

That's sort of an arbitrarily chosen number, but it's on purpose chosen as 1 week, and the motivation for that is for like the sort of, if things go wrong, or like a smart contract bug, or whatever, that humans can react to it.

And yours is 30 minutes, so that begs the question, how were you comfortable with this choice?

What were some motivations that sort of made you comfortable in picking this much shorter timeframe?

Wait, I think that the security questions are the fun questions.

Yeah, so actually I would take it really back to that conversation about the difference between roll-ups and interop in the optimistic design space.

So remember how we talked about how fraud proofs are much simpler in optimistic interoperability compared to optimistic roll-ups?

In optimistic roll-ups, fraud games are extremely complicated.

See all Delphi Digital transcripts on Youtube

Is the Future of Blockchain Interoperability Optimistic? w/ Arjun & Anna