The Interoperability Trilemma

Transcript

hello everyone my name is elaine haber i'm one of the co-founders of connext and i'm going to be talking to you guys about the interoperability trilemma so we've got another one so first i just want to say that ethereum l2s need trust minimized interoperability that shouldn't come as a surprise to anyone here we've seen a bunch of different domains pop up with arbitram and optimism zk sinks on the horizon and all of these domains need a way to trustlessly pass message between messages and data between each other as an aside there's a bit of a misconception that ethereum scalability

research and ethereum interoperability research are two different things but we've actually known for a really long time that we can scale ethereum by moving to multiple different domains so the question has always been how can we make sure that these domains can pass data between each other trustlessly or in a trust minimized way so turns out that building trust minimized interoperability protocols is actually kind of hard one of the new paper came out called communications across distributed ledgers that actually showed that you have to introduce one of two assumptions when you're building an interop protocol

either you have to introduce a trusted third party which is less than ideal or you have to introduce an ac a synchrony assumption behind asynchronous operations so what does that actually mean it means that you need an action to take place in a specific amount of time otherwise it won't happen so that looks a lot like expertise on hash locks so despite it being kind of hard we see new interop protocols new bridges every day and there's a ton of money going into this space and every single bridge protocol markets itself in the same way and they're all trustless secure and decentralized that may not be true but

it makes it really difficult for developers to be able to navigate that trade-off and understand which bridges are right for their projects so how's that going for us pretty poorly we actually have a bunch of new cross chain exploits there was one on thor chain the poly network one was pretty bad right up until compound happened and then there's of course this one which i'm not sure if you guys can read this but basically it's just a bridge operator saying that exclusively one person has access to all of the funds that are locked in the bridge so we've got a lot to learn in terms of

actually building protocols that live up to the marketing language that is used so what does it mean then to be trustless to be secure to be decentralized decentralized obviously means you have a diverse set of participants who are stakeholders in the system and they're interested in making sure it performs correctly when we say secure we mean crypto economically secure so the cost of misbehaving is far outweighs any of the benefits that you would get from acting maliciously but when we say trustless we're really looking to answer one question and that question is who's verifying the system

and how much does it cost to corrupt them and you have to keep in mind that when we're building these protocols and in this industry we're hoping to build things that will last for a really long time and have impact at a global scale so you have to really think boldly with your threat models if your threat models are just your competitors in the space that's not good enough you have to think like oh what if jeff bezos decided because why not to focus the entirety of his resources at just taking down my protocol and that's those are the types of actors that you have to consider when you're designing these things so how does that play into bridges well

imagine a scenario where you are a security conscious ethereum user trustless trust minimize security that means a lot to you and so you've done a really good job at waiting to move all your funds to from mainnet to rollups because bsc was exciting there was a lot going on on polygon but really you wanted the full ethereum verifier set to be securing your funds now you finally got your funds on arbitrum but optimism is also in place so say you want to move some things over to optimism there's some good yields who knows you're not boring you're gonna do something exciting so you decide to use a cheap fast bridge

that's cool except it's actually kind of not because now you've given the entire security of your funds over to this third-party bridge verifier set which is much much smaller and can likely completely different than the ethereum verifier set so now instead of the security just being the sum of all the parts it's the weakest link in the system and your funds are only secured by this small subset of bridge verifiers which is not what we want so now that we know a little bit about the importance of bridges and the like what it means to truly be secure and trust minimized let's go through a few different

types of bridges that exist the first is natively verified bridges an example is the near rainbow bridge and what these how these bridges work is they have a light client that's running in the vm of another bridge so they don't have any additional verifier sets it's the most trust minimized you can get because each chains verifier set is validating the other chains and you're not adding any additional trust assumptions that you wouldn't be comfortable with by already moving between the chains the downside though is that it's really difficult to build these systems in a way where you can port them over to different domains so

in an ecosystem like ethereums where we have just a bunch of different consensus mechanisms a bunch of different things to be aware of each of these bridges would have to be built individually and tailored to the underlying domains so that's a bit tricky on the other end of the spectrum you have externally verified bridges so these are things like thematic pos bridge these bridges have a third set of verifiers that are in charge of all of the funds locked in the bridge the great thing about them is that you can do arbitrary message passing really easily and that they're really easily portable to a bunch of different domains without doing a ton of extra work the downside it's a bit of a zinger

is that now you've introduced a major trust assumption so imagine you have about 10 billion dollars locked in a bridge say it's a mint and burn bridge and these assets they're the custodians the verifiers are supposed to be holding on to them and watching them until you exit back from your destination chain but if the stake that these verifiers are putting up is only 2 billion then it's perfectly rational for them to steal the entire 10 billion dollars worth of funds that are locked in the so you've taken a bit of a hit on the trust assumptions a third option is a locally verified

bridge and these bridges take difficult end party consensus and reduce it down to just two parties so a good example of this are just straight up atomic locks where now these counterparties will verify each other and they're both economically incentivized to do so because should one person gain by being funds by being malicious the other person loses it so they can't necessarily collude to steal all funds from the bridge so when we take all of these together just as a recap you have native cross chain validation that is by far the most trust minimized you can do generalized

message passing but unfortunately you cannot easily extend it to multiple domains you've got externally verified bridges that are easily extensible to a lot of domains you can do generalized message passing but they are not trust minimized and you have locally verified bridges which are trust minimized are extensible but are really difficult to do generalized message passing in and that usually comes down to permissions so take the example of wanting to call uniswap on some destination chain that's actually pretty easy to do because anybody who has swappable tokens can call a uniswap

swap function but if you look at something a bit more complex like locking and minting nfts you can't really do that in a locally verified system and that's because the color of the mint function really should be the lock function on or the lock contract on the origin chain and that's really difficult to represent in these locally verified systems so that's all really cool but none of this has helped answer the question how do i choose which bridge is right for my project and to do that and to navigate the trade-offs we have come up with this mental model

of the interoperability trilemma so similar to the blockchain scalability trilemma which states that you can have a blockchain that's either scalable decentralized or secure but at two of the three properties but you definitely can't have all three we have an interoperability trilemma which means you can have a bridge that's trust minimized extensible so easily portable to different domains or generalizable meaning you can do pass arbitrary data through it but unfor you can only have two of these three properties you cannot have all three and you can see that the multi-party computation or mpc bridges have chosen the extensible and

generalizable trade-off like client realize relays have chosen the trust minimized and generalizable trade-off but they're not usually extensible and systems that are like atomic locks choose the extensible and trust minimized trade-off where does connext fit into all of this and kind of how we think of navigating this we do a locally verified system so our system is extensible and trust minimized but it's definitely not generalizable so a quick primer on how this works uh sorry this is a bit busy but i swear it's not that complicated

you have a user on a sending chain and a router on a destination chain first you the user starts an auction and that's really just to select a counterparty that they're going to verify with and all of the routers who are interested in able respond to that auction user chooses the winning bid from there the user locks up funds on the sending chain router locks up funds on the origin chain or destination chain excuse me and then the user is able to unlock the funds on the destination chain and the router can use the same condition to unlock the funds on the origin chain so everybody's made whole the only real

conditions around what you can use as an unlocking condition is that it has to be the same between both chains how does this fit into the interoperability trilemma well when we design this protocol we really wanted to use a similar approach as ethereum did with their navigation of the scalabili scalability trilemma so when ethereum was trying to solve this problem they chose a to not make it scalable and instead focus on a decentralization and a secure as their two main features this is because these features are the most

important to having to longevity in blockchains similarly we think that extensibility and trust minimization are the key backbones to having a long-lived interoperability protocol and we believe that other more generalizable features can be built on top so we kind of see nxtp which stands for non-custodial cross-chain transfer protocols so nxtp may be a bit of a mouthful but you should hear it when it's not abbreviated that's kind of we see it as the base layer in this interoperability network and protocol stack so yeah thanks for listening i hope you

guys all learned something about bridges yeah find us on twitter [Applause] maybe you can take one question is there any questions the audience no okay by the way if you guys haven't read about the poly network track it's a great story can you explain more about the locally verified uh part like how how it's happening with like um currently like the evm compatible chains yeah sure so if we go back to looking at how nxtp is

designed the first step in that process is i need to find a counterparty and what that's really doing is it's reducing the consensus of both chains to just an agreement between two parties this is kind of similar to what channels did where they would reduce the entire chain consensus to just an agreement between two counterparties and from there as long as you can verify that your counterparty has taken the appropriate actions so in our case they've locked up funds and the right amount then you know that you can unlock and vice versa so does the node have to have like a custom implementation

or can like can a normal very like normal node runner just just verify that yeah so if you remove if all the chains or domains are evm compatible you don't have to have a custom do like function or implementation but when you move to other l ones that may have a different consensus mechanism like say we want to connect ethereum and bitcoin you would need a slightly different representation of the same concepts that works on the bitcoin blockchain so an example would be okay we use nxtp and the unlocking condition is just a hash lock and then you can plug that into like the lightning network that unlocks a an analogous payment on the bitcoin network with just that same hash lock

okay thank you very much um did you serve a little bit of some improvement