Modular Interoperability - Layne Haber

hey guys thanks lane okay hi welcome to eath denver my name is layne haber i'm one of the co-founders at connects where i spend a lot of my time doing research on the protocol and we build interoperability protocols and i'm going to talk about modular interoperability and what that means and how you can use it to build secure cross-chain applications not simply multi-chain applications so first kind of a background on why bridge security is important and why you should care about it imagine that you're an extremely security focused ethereum user so you know you verify every single detail of your transactions that you send from a hardware wallet every time you send one you didn't you know jump to matic or bsc because you wanted the security of the ethereum verifier set so you stayed on mainnet until rollups came around and you paid the extra gas because security is really that important to you so you've got your funds on arbitrary you feel comfortable that they're there you want to move them to optimism because you feel comfortable on optimism as well but you decide to use a bridge and you may not know a ton about bridges they're kind of new there's not a lot of good resources out there about how to evaluate the security and you happen to choose a bridge that is externally verified well congratulations you played yourself because now you have completely bypassed the security of the ethereum verifier set and your transaction is only backed by the bridge verifiers which is likely a much smaller much less diverse group of validators so you really only have the security of that bridge verifier set and all of the extra gas costs you paid to stay on main net while everybody else was on polygon were for not so let's take a step back and kind of evaluate what bridges exist and what the setups are for them and how we can think about their security models so the first is a natively verified bridge and these are like light client bridges where there's some block header verification for the bridge itself to you know make sure that the transactions are secure these are awesome because you can pass pretty much any data you want from one chain to another they're very generalizable they are also very trust minimized because you're only depending on the chains validator set there's nothing extra that you're adding into the mix unfortunately they're definitely not extensible because they depend a lot on the underlying architecture and consensus mechanisms of the domains so i can't take you know the near rainbow bridge and put it on like copy past it and have it work for fmos to mainnet like it just won't work like that on the other hand you have externally verified bridges and these have a different set of trade-offs where you know you can port them easily from domain to domain like nothing usually about the protocol or the logic is domain specific so i can take the same externally verified bridge protocol and take it from matic to cello to evmos to what have you and it should all still have the same security model you can also pass generalized data through these bridges which is very helpful but unfortunately you're relying on the verifiers of the bridge not of the underlying domain so it's not exactly trust minimized some examples of this are like if you've ever heard of a multi-sig bridge that's an externally verified bridge any swap thor chain those types of things are fall into this category and usually it means there's some set of validators that are making sure that the deposits in match the funds that are minted out or the burns that you submit match the funds that are released from the lock deposit a third example is locally verified bridges and these are kind of like your atomic swaps your hash locks what have you but basically these take a complex multi-party uh problem and reduce it to just two parties and in these setups you normally have a counterparty who is for the duration of this transaction your economic adversary so you're both highly incentivized to verify that your counterparty is doing the correct thing so if in a hash lock for example i would be incentivized before i revealed the secret to make sure that you put the right amount of the right asset up on your side of the trade so locally verified systems they're great because they're extensible you can pass them through a bunch of different domains they're you know trust minimized because you can verify everything that your counterparty is doing but unfortunately they are not very generalizable like you can't really they're not designed well to pass general data between the two counterparties so that kind of brings us to a good mental model for how to evaluate different bridge models uh called the interoperability trilemma and similar to the scalability trilemma just says that you can only have two of these three very desirable properties when you're building a bridge so it can either be generalizable meaning i can pass whatever data through it trust minimized meaning i'm not adding any additional trust assumptions or extensible which means i could easily port the same protocol to different domains like clients are generalized and chest minimized but not extensible atomic swaps trust minimized extensible not generalized and externally verified systems are extensible and generalizable but not trust minimized so they all take a different portion they all have different trade-offs that are important to understand so whenever you're dealing with a particularly hairy problem like this you're never going to find like a silver bullet solution that's going to allow you to have your cake and eat it too you're only going to be able to navigate the trade-off space and you know when you're trying to solve this problem that pretty much means you're gonna have to do like what we did with the scalability trilemma where we start building things in a modular fashion so each layer can have different trade-offs that work best for that specific layer of the stack so if you look at ethereum and its roll-up ecosystem ethereum decentralized secure certainly not scalable roll-ups scalable secure but they're definitely not decentralized but as an end consumer of these systems i'm able to use a roll-up on ethereum and kind of have the best of all three worlds and you can take a similar approach to solving the interoperability trilemma by building these things modularly an important building block in this paradigm is a different type of bridge which i didn't mention before which is an optimistically verified bridge an optimistically verified bridge these are things like nomad or optics you basically have the equivalent of a sequencer called an updater who is responsible for for getting messages from chain a to chain b um but each message that the updater proposes has some latency period this latency period is to execute fraud proofs where there can be you know any number of watchers who are ensuring that the updater is passing not like correct data not fraudulent data and if they are found to be fraudulent the up or passing fraudulent data the updater can get slashed and then the uh watchers can disconnect the applications that were listening for that data so that you are any harm from any fraud that has occurred is mitigated so oh sorry okay so i'll talk a little bit about um what it looks like to build a modular cross chain application the first layer is the base layer which is transport and that really is just off chain infrastructure and it's people who are able to run infrastructure on two different chains and get the data between two different chains so in an optimistic bridge those are the updaters and the watchers in an externally verified bridge those are the verifiers and a light client bridge those are the relayers uh people who are capable of running infrastructure on both chains and on top of that you have the messaging stack and the messaging is basically governs the how of data transferring between these chains so it's like your roll-up amb it's nomad it's your like ibc protocol basically how can the data be passed between the different chains once you have people who are able to pass it on top of that you have a gateway stack and these aren't live but i expect that you'll start to see a lot of them in the near future and this layer of the stack is responsible for kind of select taking in contextual information about where what domain you're on and where you're trying to go and choosing the best messaging protocol for you to use so if i'm on ethereum and i'm trying to get to optimism the gateway protocol would say great use the optimism bridge but if i'm on ethereum and i'm trying to get to moonbeam then the gateway protocol would say okay for this one you should probably use nomad and then on top of that you have a liquidity layer and liquidity layers are important because when you have all of these different you know this big heterogeneous mix of protocols that are creating your interoperability stack you're going to have like 8 000 different flavors of assets that is incredible they're incredibly annoying to deal with as a user so like if i'm using any swap to get to matic then the liquidity layer would be responsible for swapping by any usdc for pos uscc which is actually usable on matic and when you take all of these layers together you have a cohesive interoperability system that allows users to securely transfer funds to and from any domain um sorry clicker delay so there's been a lot of talk about like multi-chain and not cross chain and how multi-chain is okay because it's more secure because typically in a multi-chain environment um the domains have some type of state machine verification whereas in a cross-chained environment that isn't guaranteed and then it becomes inherently a bit more uh risky so a good example of this is like the wormhole hack with like the full caveat that wormhole was not hacked because of its security models it was hacked because of a smart contract bug but the problem still exists and in that hack the on the salon side there was a bug that allowed the attacker to mint a ton of wormhole eath they then took that wormhole eath and withdrew it on the ethereum side which created a big systemic problem for the d5 applications on solana because now what had they had accepted as fully backed wormhole eth was no longer fully collateralized and you had to get like market makers jump in and kind of backstop that loss because it was a huge problem um i think however that we've seen a ton like a ton of different times across various situations within the market that users are going to make decisions that we wouldn't necessarily classify as secure but they will do it because there's a lot of utility to be had there so for example like my wbtc rap btc is way more useful for me on ethereum than my btc on bitcoin and while my bcc on bitcoin is much more secure there's like it is the native currency is about as secure as you're going to get i'm still going to wrap it and lock it up in some yield earning protocol that exists on ethereum so i think like our responsibility as builders in this ecosystem is not to force users to change their behavior but to create environments where users can do these more risky behaviors in the safest way possible and a good analogy is like cars like driving a car is obviously a risky behavior people die doing that all the time and the solution was not to you know ban cars for forever it was to create seat belts and airbags so that i can drive my car and have less of a chance of dying although it's still a slight slightly more risky behavior than just walking so what does that look like and how can i use modular interoperability to get there so first you have to understand intra-cluster communication and these are this is communication for all of the domains within a system that can verify each other's state machines so like roll up ambs or ibc on cosmos or xcmp on polka dot these are all very secure messaging systems and it allows interoperability within a single cluster but you also have inter-cluster communication and inter-cluster communication refers to interoperability in environments where i don't have the same state machine validation and for that you would use some optimistic protocol like nomad and when you put it all together you have a good pattern for how to set up you know interoperability in these heterogeneous environments you can use the gateway protocols to determine which messaging protocol to use in which cluster and then you can use the optimistic messaging protocols to message between clusters and the optimistic messaging protocols are actually really well suited to provide the backbone for inter cluster communication because they have the latency built in latency is great for fraud proofs but it can also be used to add in circuit breakers so what do i mean by a circuit breaker well something that adds extra verification natively if it seems like a risky or unusual transaction in the wormhole case what would a circuit breaker look like look like oh someone's withdrawing 80 percent of the eath on the east side of this bridge maybe i wait a bit longer before forwarding along this message and that provides a really useful way to mitigate a lot of the risks that you that are present in a cross-chain environment but maybe not necessarily in a multi-chain environment um yeah so that is kind of the where i see interoperability going if this was interesting to you uh connext is hiring please take a look at our available job postings if this was interesting but you're not looking for a job because your investments have done really well still join our discord we'd love chatting with new people and if you think that like me and you would just be really good friends you can find me on twitter uh but yeah i'm open to questions if anybody has any sweet well thanks guys hope you enjoy the rest of your eats denver [Applause]