Scaling Ethereum: Bridges & Interoperability / Max Lomuscio, duckdegen

Transcript

foreign [Music] hello everyone how's it going my name is Maxwell mucho I'm David Leonardi nice to meet you we are from connects we are a bridge and interoperability protocol we basically have to make blockchains layer tools and domains composable in a very very secure way and so we thought today we're going to talk we can talk a little bit about how we can scale ethereum how we can make interoperable between the different layers that have been created but first thing first ethereum is scaling that's a great news right the

older layer tools are finally finding some kind of product Market fit uh finally uh you know finding the right incentives the right mechanism to attract dabs and allowing ethereum to can we kind of become less congested and bring a lot of their operations up to the layer twos but there is a but this killing has some issues and this is fragmentations this is how the scaling of ethereum looks like a series of layers a series of different Roll-Ups they cannot start to fragment three things the liquidity that is present on different layers uh the data and the users and this starts to complicate things because all of a sudden you don't have a unified experience as you used to

have in ethereum but we have multiple small chunks of bits and so what happens is that the different the different layer tools are very well connected to um Criterium you know arbitrary ethereum optimism with ethereum and all the different layer tools that are not really connected to each other they're not really integrated with each other so that's what connects does we aim to really unify The Experience across all the different layers whether it's an L2 or an L1 we're currently connect 17 chains 17 different domains the ethereum and the layer twos the cosmos ecosystem the polycarlo ecosystem Avalanche Phantom polygon you name it and we do it in a very very secure way so we then have to do a kind of premise

on how the bridges work right how can we make it more secure than the others so let's have a look at the different type of bridges that exist today and then we'll explain how connects worked so the first one the first type is is kind of we cannot Define it as native Bridges and there are the bridges that are verified basically by all the uh validation all the validators on the base layer on the on the on the base chain let's say this is the case for the layer Twos for example where all the validators of ethereum verify the connections between ethereum and arbitrum for example these are very very secure right that's why they took so many years of research and that's why

they're so affecting the scaling ethereum which is great but they have an issue they are not extensible meaning that they only work for the connection if you wanted they were custom created for so for example the bridge between ethereum and an arbit room only works between ethereum and arbitrum the bridge between optimism and ethereum only works between optimism and ethereum and the same thing happens for other type of technological Technologies like IBC for Cosmos where it's very effective and very secure within the cosmos ecosystem but outside of the cosmet ecosystem it doesn't work then we have external what we call external verified Bridges which are very common today across the different

architectural Bridges where we have a third party that is normally a series of multisig the series of validators that are in charge of verifying what happens on one chain and then say okay something else can happen on the other chain these are the cases of for example multi-chain synapse layer you know inhibit uh what's the issue with that is that now you have to trust the third party right it kind of uh put in in discussion everything that we did with blockchains trying to make it more permissions and you know decentralized and now you have another third party that you have to trust if you want to move this information these tokens from one chain to another one so they're not secure we have then locally verified Bridges

where the relationship to move within the process to move tokens or data across chains is validated by just two parties so the relationship is simplified by two parties this is the case for example for Atomic swaps which is how connects for today where there is a liquidity provider on the other side the user on the first side they both lock their tokens and then they swap them at a time these are good because they're very secure and they're very extensible to different domains so different chains but unfortunately they are they have some limitations so they cannot pass any type of data and they they don't have any optimal user experience so we introduced the the last type of bridge the last type of bridge that we called optimistic Bridges this was a

mechanism that was pioneered by Nomad and the guys in Nomad say okay by definition it's impossible to verify that something that happened on one domain uh so it's impossible to verify from one domain that something has happened on another domain because the two ecosystems are separate all we can do is to verify if something has not happened on the other domain with proofs so what happens basically with optimistic Bridges there is a somebody a relayer that brings a message from one chain to another one but then before the message becomes valid there is a 30 minutes latency period and during this period any Watcher can come with a fro proof and say hey this message is not correct and

I can prove it from the origin chain and so this is a way to keep the system secure where any watch there's an unlimited number of Watchers and we only need one good actor basically to keep the system secure because anybody can come and say hey this message is a fraud this message is not correct so all we need is one good actor which is a fairly good assumption to make in the system it's a very extensible uh extensible approach to different domains but the trade-off here is latency so user has to wait 30 minutes which is not ideal so how do we solve this we saw that different Bridges have different trade-offs how can we solve these limitations that each of them has well the same way that blockchains are solving it with modularity basically so

what we're trying to do now is to build the stack which is called the model interoperability stack where we have different layers in our case it's Nomad and connects uh that we don't do not compromise on security but cannot try to balance the different trade-offs so we have Nomad on one side that is saying hey I bring you the information Singleton tokens from one chain to another one from arbitrum to optimism and this might take 30 minutes but it's super secure and on top of it normal connect says hey you users do not have to wait for 30 minutes I will give you the cash military so you can go and do whatever you want and I will wait for the slow refund in 30 minutes so in this way we are actually enable a very secure system with very limited trade-offs that can connect to different chains and

different domains and this is important because once we are able to unify these different ecosystems and make them composable we can actually change our mindset from a world that is multi-chain where the major protocols have deployed on the different domains think about Abe think about curve that are on different chains but these domains these instances are currently isolated right so there's a multi-chain word but it's not a Christian word yet we connect we can actually think about as a unified ecosystem where the users do not need to know which chain is interacting with the applications the protocol can basically interact on the background on the on the different domains so David here is going to explain us how do we move into

discretion world and building cross-chain applications thank you Max so let's take a look at how we can build xaps but to understand that first or to get to there we want to first know what can we build right there's a bunch of different applications that are ideal for this kind of scenario so dexes for instance so swap tokens across multiple Bridges with the best price or yield aggregation or lending or governance which is super interesting one where you can have a central Hub and one chain that is very cheap in gas and collect votes from a bunch of different chains and perhaps execute some callbacks and maybe send some tokens or whatever back to different chains and many more right so we're really looking to explore what the community and what the whole ecosystem comes up with but fundamentally it's a very flexible

system so what are we building here so are essentially creating promises or asynchronouses asynchronous solidity so on the original chain we will have a contract which has a state of this one at a specific snapshot and time and on the destination chain we have a Target contract which will then have a snapshot of a specific time and this allows us to send a message across chain and receive a callback when the execution has been successfully completed in a secure way on the target chain and then execute a callback from the origin chain to complete all of our actions so what does this look like we have two contracts as we said one in the source chain or when

the sending chain one of the receiving chain and we have our magic sauce which is xcal which is pretty much the equivalent of the call method and the call method or the x-call method which accepts an arbitrary amount of arguments which fundamentally are the payloads and the token the origin chain and the destination chain those then go and talk to the connects contracts which then relay and transmits all of this information through infrastructure which does a bit of magic we'll get into that in a second then relays this onto the destination chain and then finally on to your own contract um so there's a few different use cases let's take a look at token transfers so we got into uh this uh quick uh explanation that we have this fast

liquidity chain so a canonical token can get sent via the relayers to a destination chain and here we have these relayers that take the risk uh to relay the tokens from chain a to chain B but they know that they have the guarantee of receiving the tokens from the optimistic Bridge so this transfer actually is executed in a very fast way usually within a few minutes um we then have the optimistic liquidity transfer in the case in which there is no liquidity uh for a specific token and in this case all of this actually goes through the bridge itself uh in which um a token a canonical token is locked assuming we are sending it from a region chain that hosts a canonical token it's

locked into the chain into the bridge the bridge then mints out the destination token on the destination chain and this is then passed on to the user or to the relayer to reimburse them for the transaction or to pass it back to the user as needed we can do the same thing with data we can handle authenticated data or specifically for permission calls and in this case because it's permissions and we need to make sure that the sender is validated this needs to go through the bridge through the optimistic bridge to be able to successfully execute this call in the case of on permission calls this can also happen through the relayer so in the instance of a decks the configuration for the payload that needs

to go out to specify what swap needs to be executed can be contained and transmitted via the relayers directly um so fundamentally we have two contracts right via the bridge or the relayers and um it's as if you're just calling Source contracts or Target contract from The Source contract the rest is really handled from our infrastructure in a very simple way so let's take a look at code um so we have a Target function that is update value on chain B that we want to call in chain a and on the source chain we can call the target function and send it as a call data parameter and then we specify the other parameters that are truncated in the specific case

and what we really want to point out here is that we have xcal and the bottom which is pretty much our equivalent of the call method and we can also specify a callback which once the executed function on the target chain has executed will then be executed on the source chain um this specific example on the rights is permissions you can see this because it has a modifier that is only executed if we wanted to do this in a permission this way we can simply remove that modifier and that's as simple as it is um

to get started it's really simple we have a doc sites which is complete with a bunch of examples where currently this is a living document as we go and extend it with functionality and use cases we also have a GitHub repo which you can simply clone and really get started very quickly with a sample project to do some bridging in a very quick way and you can definitely reach out to us on discords and Twitter and all the rest of the usual channels and we'll gladly be there to help and support you through all of your let's say development journey and Shameless shell we also have a bunch of t-shirts and swag is these little ones we have some of these amazing octopus bridging entities and someone with the wolf so if you would like some of those

come up to me and I'll gladly had some some of these out to you guys and that's it thanks for your time thank you [Applause]