Connext Technical Workshop - Rahul Sethuram

okay cool hey everyone uh this talk is called building cross-chain cross-domain dabs which are called x apps or zaps as we like to call it so first of all a little introduction my name is rahul and one i'm one of the co-founders and the tech lead at connex we've been going at this since 2017 and we are basically one of the first teams that have developed interop solutions i'm so excited to show you guys how it works so first of all what is cross domain so there's been a lot of talk about cross chain multi-chain but really if you think about it these are domains so they're not necessarily chains sometimes you can have things like roll-ups and other l2s so basically what a domain is is it's an execution environment so this could be a layer one it could be another layer two it could be a side chain it could be something that's not even evm so everything like that is just looped into something called a domain and an x app or zap is a cross domain native dab so show me on why zaps should be a thing so one reason is as adapt developer you don't really want to pick a winning l1 or l2 you want to just be able to deploy your app everywhere and then let users choose how they want to use it or kind of abstract that whole interface away and then no matter what like execution environment ends up like winning or being around in 10 20 years you know your dap will always work and user's gonna use so like no matter what you know italic has talked a lot about cross chain multi-chain and you know the benefits and merits of both uh sorry it looks like some feedback here but in the end users are just going to keep using these things and what we want to do with connects is we want to build an environment where users can use these things safely no matter what so when you build a cross domain app you build it for users that are going to use these these no matter what and since this is an eth conference there might be eth maxis in the house so you know how do how do you reconcile this with all these different layer ones uh well if you create one of these zaps that contains layer one and each layer twos then you can actually value sync back to each and layer two so you have this cross domain app that is working on all these different layer ones and layer twos and in the end you can actually bring value back onto the ethereum ecosystem and at the end of the day these domains are a lot cheaper so you can onboard users from anywhere and cheaply so some users are currently priced out of each some users are even priced out of like optimism and arbitrarium but if you onboard them from other chains you can cheaply do this and you know get them into the ecosystem but security so this is a big thing now in the space because uh bridges have been getting hacked left and right so the main thing about security in this context is don't use trusted bridges you don't want your bridge to be like the point of failure in the system so if your bridge is not the failure point in the system then your domain becomes a failure point so as adapt developer who's developing on different domains you need to actually understand the risks of the domains that you're supporting so my co-founder lane has a talk coming up in a few minutes where she will go over the security much better and i won't front run her talk okay okay is that better cool so the thing is cross domain deployments are already here so you can see in a lot of these very popular dapps like ave for example sushi swap dexes lending protocols they all have these kind of like interfaces for multi-chain deployment so you can already go and use all these apps on different chains but if anybody has used these you know that they're very like they're basically different apps and they're siloed from each other so there's a lot of ways that we can actually improve on the zap interface so unifying the interface of course where you make one interface that you can interact with no matter what chain you're on you abstract the bridging process completely from the users that way users don't have to think about bridging or like what what chain to go to and from how to move the value all that is contained within the app and this is the most important part past call data so users are coming from different chains they're not going to have gas funds on all these different chains and if you really want to unify this you want to pass the call data so that you can have this relayer based system that uh basically does all the operations on the receiving domain i'll go more into this a little bit later um so this you know abracadabra is a protocol that is built by you know frog nation has a lot of weird stuff going on i won't get into that but uh the protocol itself so this d-gen box strategy used by abracadabra is really cool i think because this is an example of how the bridging is completely abstracted the domains are completely abstracted what you do is you deposit collateral as ust on ethereum in the background the protocol actually does all the bridging for you and then allows you to borrow against it and then when you withdraw for example it also bridges back and lets you withdraw so i like to call this protocol controlled bridging where you're like the users are not in charge of the bridging anymore that dap itself and the protocol does this all an automated way and this is really how bridging becomes like more sustainable for users and bridges as well because you know you don't you don't get long tail usage anymore you get this huge usage from the protocol itself um so what can actually be built here so cross domain zaps this is like lp zap so where you have like asset on one chain you zap it into a farm on another chain where you can do things like split it into the lp and then deposit it directly all through you know abstracted away from the user cross-domain governance this is another big thing like governance protocols are now starting to experiment with this stuff uh right now mostly governance centralized on one chain so like you know if you have curve tokens on ethereum and curve tokens on arbitrary you can't vote with your curve tokens on arbitrary so this is something that you know apps should start to enable when they go cross-domain native yield optimizing across chain since there's different yields then you can start to get into things where you can provide the best yields for users dex arbitrage or self-explanatory cross-domain borrowing this is a you know a concept like the abracadabra concept where you put in funds from one chain you get yields on another chain you're able to borrow against the funds that are bridged on a sending domain and of course i think we've barely started to scratch the surface of what you can do with cross domain so you know we at connex want to build the tools to make this stuff possible um so challengers as adapt developer you know building apps building dapps is pretty hard in general uh there's a lot of stuff moving around and when you add more domains you kind of exponentially increase that complexity so everything from deploying contracts to multiple chains getting rpcs getting gas fees managing deployed addresses like you know you have a huge list of addresses now how do you manage that like a lot of dapps have the stuff hard-coded and i think there's better ways to do it where you can automatically generate uh deployment files and artifacts uh reading and writing to chains rpcs of course like that just you know all that stuff is just exponentially more complicated and complex user interactions this is the big one where you really want to simplify the complexity at the layer of the dap but that of course becomes a big challenge with different domains um so with connext uh what we are trying to do is we are trying to build a unified smart contract interface for x-domain native apps this means that you can use connects to basically let you choose exactly how you want to do the cross domain stuff and you have a single unified interface and you you don't really have to think about this stuff as adapt developer we also provide instant liquidity bridging and call data passing so that goes back to what i was saying earlier about abstracting the gas stuff away from the user by letting the protocol actually take care of calling the function on the receiving chain through real air networks and whatnot message passing so this is something that we are heavily working on and about to release but unidirectional message passing means you can trust trustlessly pass a message from one chain to another chain and verify that it comes from a source that is trusted so if you want to vote from one chain to another chain you can actually do that in a trustworthy way bi-directional for example if you want to read a tiwa price from one chain to another chain you basically need to send a request to that chain and then get a result back that kind of stuff is still very much in the infancy and has not been explored but we provide the tools for that and you know some of the challenges i addressed before about deploying contracts subgraphs repos things like that like the complexity around this cross-domain management will be kind of abstracted away from dap developers by the connex toolkits so kind of going into like how an actual zap works so here you have a sending domain and you have a receiving domain so these can be two separate chains l2s whatever so from the dapps point of view all they need to do is basically write these two smart contracts so a cross-domain deposit contract this is this is for example like a ave deposit so in the cross domain deposit it will call on the sending chain it will call our unified interface which is the transaction manager which also lives on the sending chain so all the stuff at the bottom here is all the connext protocol bridge stuff then this transaction will get picked up by a router which is the liquidity provider on the connects bridging protocol which then transfers through to the transaction manager on the receiving side so the router will end up calling a function on the receiving side which calls a fulfill interpreter which ends up having the call data that you pass through i'll show this all in code it might make a little more sense but at the end of the day this fulfill interpreter will call your cross domain middleware contract on the receiving side and then you'll end up calling to your external like uh lending pool contract let's say so we can see some code now all this code is public on the github so this uh you know we're trying to build these starter kits for this stuff so if we dive into things here um here's the cross domain deposit contract so another hard thing about building zaps is when you're building these contracts you have to think a lot about what chain you're on so this is on the sending side chain so the dap will basically call this function called deposit it will use a token an origin domain and a destination amount oh so first in the constructor basically what you have to define is you have to define your transaction manager this is the uh this is the address of the connect smart contract on the sending chain uh then basically you have a mapping of domains to pool since we're using like an ave deposit in this example you're going to have a mapping of which domain in ave like for example uh sorry oh sorry about that thank you that better okay yeah good call um so for example you'll have like a mapping of the domain for polygon with the pool for polygon and so on and so forth so this contract will contain all those mappings so then when you call a deposit on the sender side it will look up your pool make sure it exists uh for example if you're calling this on polygon you want to ape into the avalanche lending pool it will look up the avalanche lending pool to make sure on the destination that exists and then it will encode the selector for the deposit function which is going to be your middleware contract and then it will set that as the call data so encode with selector is how you encode a call for a contract call that happens in a different contract so here getting here on the receiver side so now when this uh when this function is called on this receiving side contract it basically the way that connects to architecture works let me go back here so the fulfill interpreter is going to get the funds this is the bridge contract and then it is going to have the funds and then it will allow this contract which is called to have access to these funds so it will do an approval for these funds and then uh this contract can be written to basically take those funds and do whatever it wants with them um so in this case what we're going to do is we're going to take the amount which is the balance of the message.sender because message.sender is this bridge contract in this case it will transfer the funds to this contract then it will approve uh for the lending pool and then it will deposit into the lending pool so this is a basically a very simple wrapper contract around getting the funds directly from the bridge uh and to that so maybe maybe your question might be why can't you just directly encode the deposit to ave function directly in here and the reason that you can't do that is because you don't know the exact amount that you're going to get on the receiving side until the exact time of the bridging because the way the connects bridge works is the gas fees are basically paid out of the amount that the user bridges so um they you basically need to use this kind of wrapper contract helper contract to be able to get the exact balance that the bridge uh gave you and then transfer the funds from there and then you know the amount here so then you can just deposit it directly into ave so yep that's about it for that uh we are still early in this process of redesigning the connex protocol we're really eager to like onboard developers who want to build these and we want to work with you guys to build out these interface in the best way possible so whoever wants to build a dap please get in touch with us or zap and then we can help you through this and we can uh you know work together and come up with the best interfaces to make this make this as native and abstract as possible so thanks everyone you