HackMoney Summit | Interchain DeFi with Connext

[Music] so next up i want to invite arjun to talk about interesting d5 and how connex makes that a lot more convenient and simpler so uh without further ado let's welcome margin and uh i'll let you take over from here awesome um thanks so much context um hi everyone my name is arjun i'm one of the founders of connext connext enables fast trust minimized communication between blockchains and rollups we've been in this space for a very long time uh heavily researching later twos since like 2018 and then uh uh started working on crosstalk master uh and right now have a have a live product that works on transferring funds between chains that is now being upgraded to do more generalized messaging um and i'll kind of go into what that means in a couple minutes um this talk is about crosschain defy i know a lot of people have been thinking about what d5 looks like when you're when you're now in this like interchange interval paradigm and and this talk hopes to illuminate a little bit about like what uh kinds of things can be built in this cross-chain paradigm and what kinds of pitfalls exist when trying to build projects in this in this cross-chain world um so yeah uh without further ado let's start by just some some basic background on bridges bridge trade-offs and connects um one of the key things with building distributed systems is that there are always trade-offs um this is this is just like the unfortunate nature of being in our space and and this is especially true for bridges because really with a bridge or an interoperability system what you want is a combination of three things you want it to be trust minimized um obviously you want to kind of maintain the the security properties of the underlying blockchains if they're all possible you want it to be generalizable by which i mean you want to be able to take any arbitrary data and pass it between chains you can build arbitrary applications and you want it to be extensible which means that you can take the same system and replicate it on a bunch of different chains and rollups and other kinds of of constructions without having to go and do a bunch of custom work to do to integrate um and generally what what's existed in the past is that there's there's only ever like any construction that has existed has only ever been able to fulfill a couple of these these requirements at any time so the way that k'nex works currently for instance uses uh atomic swaps and uh and while it is trust minimized and can be deployed easily to any chain um we cannot uh handle any arbitrary kind of payload we can do some types of contract hauling across chains but not every kind of contract calling similarly you have you know mpc systems oracle systems what a large number of people are not colloquially referring to as like multi-sig bridges um and and those things include things like layer zero and synapse things like that a lot of those are very very easy to deploy to many different chains they support arbitrary message passing they're not really trust minimized you're having to trust this like external set of actors that is fundamentally going to have a different security model than the underlying blockchain now in the last um few months we've been we've been pushing this idea of optimistic bridges um which was first pioneered by nomads um optimistic bridges kind of take another path along this trade-off space where uh they actually fulfill all three of these requirements they are trust minimized generalized and they do this by relaying data across chains optimistically using the similar model to orus where they post data to chain uh on the receiving chain and then there's a certain timeout window in this case 30 minutes within which people can prove fraud now as you can tell there is again another trade-off here which is latency so while you're able to get some of these highly desirable properties it now takes 30 minutes to do transactions across chain is there a way to beat these trade-offs we think that the best way to do that is through modularity so uh one thing that we're working on now with our with our new upgrade is uh layering connects on top of nomad uh so that you know we we offer kind of the liquidity layer of the stacks nomad offers the messaging there at the stack and by doing this we can uh it's sort of like a positive sub situation where we can offset some of the the the trade-offs of connects and also some of the trade-offs of nomad um and the outcome is that we can actually end up with something that looks as close to ideal as possible while uh retaining the trust minimization properties of the underlying chain so for any kind of transfer or funds or an unpermissioned call by which i mean a call that goes across chains and doesn't actually need to check tx.org that can happen with two minutes of latency which is the normal time that it takes for connects to make a transaction um and then for permissioned calls where you are checking px.orgin um that takes 30 minutes of latency which is which is the standard nomad time generally what we've seen is that this is actually okay because uh in the vast majority of cases uh user facing interactions are typically unpermissioned because you you don't normally want your broad set of users to be able to call you know a mint function on your token or something like that because that's obviously going to be a security vulnerability and so generally we found that this works well because user facing interactions can happen quickly with good user experience and then the slower slower interactions happen with a higher degree of security or i guess they happen with a higher degree of latency but that's necessary because they need a higher degree period all right jumping into cross chain applications um one of the things that we like one of the ways that we like to think about what connex is actually enabling and what the stack enables is that we are making we are pushing solidity towards becoming asynchronous so until now everybody has built solidity applications in a synchronous environment everything happens within a single block it's sort of like you know the ap computer science version of development where you are only building programs that run locally on your on your machine that don't ever interact with resources at all but as we know from building web applications and for anybody that's written anything in typescript you know the reality of the internet is that it doesn't really work that way um you have remote resources you don't really know when you're going to get a response from those resources and so you have to think about asynchrony um and in short you have to start thinking about distributed systems what connects enables is making these kinds of asynchronous calls across chains so we have a function uh the the core kind of flow for for making this kind of call is uh is a is a function called xcall which maps to the lower level solidity call function and in the same way that you make a call to a contract on the same uh on the same chain as you with call data um you would make an x call to a contract on a different chain from you with call data and a destination domain or basically change chain address and what's really interesting about this is that you can actually again similar to things like javascript receive a callback and execute that callback back on the origin chain so you can go and execute some transaction somewhere else uh get data from from executing that transaction bring it back home and then do something else with that data now of course there is latency involved in this so you have to think carefully about what that latency means but this is a really really powerful primitive and there's a lot of really interesting types of protocols that can be built using this mechanism where you're able to to access resources in different locations at different times um now one of the biggest questions that comes up during this is like what does it look like to actually do this um how do you how do you charge fees how do you actually make this interaction happen and what we've tried to do is is just mimic the existing flow for building applications as much as possible so we charge gas fees on the origin chain they're charged in the native asset that is uh that you're already spending on the origin chain to make a transaction and similar to how you handle gas fees on with every single chain today the gas cost of execution on the receiving chain of course is variable but will get executed if you have enough gas to pay for it and if you don't have enough gas to pay for it you can bump gas in again the exact same way that you do today we think that this actually represents the ideal user experience because uh you do the the the development process for building these cross-chain applications then just becomes uh figure out how much it's going to cost to execute a transaction or receiving chain and you know just come up with your best guess estimate for this send a transaction on the sending chain passing in the gap and then if it isn't enough enough funds to make that transaction happen within the time period you wanted to bump gas in order to make it happen faster pretty much exactly what you would do to build an application today what does it look like in practice um in practice we try to as i mentioned map to the existing lower level call interface as much as possible now there's obviously limits to this because we're you know we're limited by what like solidity can accomplish and i think in the long run we can work towards doing more interesting mechanisms like perhaps even building in promises in facilities so that you don't have to deal with some of the annoying things associated with callbacks but overall it's still a very simple flow um the entirety the entire entry point of this flow is just a simple x call function and the idea is that you can x call things and return you know and and like get return data from x calling things um and use this as a core primitive to now start building much more many more complex multi-chain or a cross-chain system so now we kind of get into what can you actually build uh with this with with this primitive um and this is where things get interesting so there is an entire domain space of d5 applications that exist right now and the the big problem associated with the multi-chain d5 world that we live in is that users have to think about what chain they're on and they have to actually go to external interfaces like bridges to be able to go and interact with an application that's running on another chain and furthermore you don't have this like consolidated liquidity consolidated experience between these different applications so um you know uh you if you use uh like ave on polygon today um it's actually a completely different application to use ave on on app launch it looks the same but you have to go and do a bunch of things separately from the ave application to actually interact with aveon avalanche and that's just really really bad user experience but what we're really interested in is trying to figure out what like what ways we can uh basically trying to encourage people to build applications that are just chain agnostic by by default they they live across chains and similar to how you build applications on the web today they access liquidity and resources for many chains all at once examples of these are cross chain indexes so allowing you to swap any asset to any other asset across chains potentially with optimum optimal pricing and basically either depending on whether you want best pricing or whether you want to go to a specific chain you can make this an option to the user you can also build much more interesting yield aggregators so for example being able to zap into a yield aggregator fault from any chain so as a user you don't really need to think about where am i going to get the best opportunity and then even beyond that aggregating yield within those vaults from any source on any other chip another really interesting one is lending so being able to lend money into something like abe migrate ave positions across any chains to be able to get the best rate that you can on eight chains and do things like interest rate swaps um and then do more complex stuff like borrow across chains based on liquidity that you've led down on chain there is so much here there's a whole like world of crosstrain d5 that is yet to be explored and if you have original ideas around this we definitely want to help cool um last thing that i really am not really laughing this is definitely going to be the like biggest chunk of this talk so i what i what i really would like to talk about is uh cross-chain application design um this is something that like not a lot of people have have really explored um and i think that things start to get a little hairy when we deal with this asynchronous world and and i want to caution that like you know this is all this is all like early thinking that is still evolving in real time so as you as you go about designing your cross chain applications definitely try to like speak to us uh reach out to us and that way we can we can help you think through these ideas and and try to try to um be cognizant of the fact that the the asynchronous environment that you're operating in now will have a bunch of pitfalls what are these pitfalls well one of the first pitfalls to think about when you're building a distributed system is concurrency when you're when you're building into service systems outside of the space um you have to consciously be aware of the of the possibility that some resource that you're accessing for example if you're trying to like update a database may need to be accessed from other systems at the same time so what happens if you have conflicts within your database because you're trying to update two pieces of the same state at the same time from different origins and the same kind of problem exists in uh asynchronous solidity as well uh and this is this is where things kind of get a little weird so um imagine for example you have a b5 application where you like like a crosstainment where there is a pool of funds on the destination chain and that pool of funds needs to be accessed from several different origins concurrently um a really really simple example of this is something like synapse where you have a pool of funds sitting on optimism and then you have the ability for people to swap into that full of funds from arbitrarium and polygon and avalanche um what happens in the in the case that multiple people try to access that full of funds at the same time what happens if funds actually if you actually run out of funds in that pool well then you have to introduce concurrency control uh and this is this is like one of the things that you you traditionally deal with in distributed systems outside of the space and you can map a lot of the like core strategies that you use to deal with concurrency over to this space quite well as well though as we'll see not all of them are very effective the first thing is segmentation you can split up the state within your pool to make it so that only a part of your pool state can be accessed at any time by any origin um and in this case you know you have uh this this out of the single destination pool you now have three pools uh you basically have three destination pools sub pools that are created which each map to origin one two and three and the downside of this is of course that you have fragmented your liquidity on this at the destination and it kind of gets even worse because it's like every time you want to add a new origin you have to re-fragment your liquidity further and further um and of course that means lower pricing that means more complexity that means having to think about oh well you know i have an origin that's just not really being used do i need to resegment that pool so then that way i can utilize more more of that liquidity elsewhere these end up being like weird operational questions that you normally don't ever have to deal with in an amm another option is something called serialization so outside of space sometimes this is called optimistic locking but the idea is like globally order the transactions that are going into into your destination pool so if you have you know a transaction coming from origin one two and three at the same time um go to your uh ensure that these things are ordered within the destination pool based on when they actually uh when their mind within like basically when when uh miners ordered them uh within a block now the weird thing about this is that it doesn't really handle the case like with it with an optimistic lock outside of the space what you usually do is if the uh if the state that you're accessing the state update that you're trying to make make on the state that you're accessing is no longer valid then you just kind of drop that update and you go back to the origin chain and say hey let's just retry this in this case that doesn't exactly work because what happens is you end up in this sort of weird place where uh you're you uh you've say for example you've run out of funds in the destination pool entirely you end up in this weird case where it's like somebody has paid a transaction on the origin chain to be able to make a transaction the destination and now their funds are just kind of stuck they're just there and there's it's very unclear what happens you could potentially make it possible for them to revert their transaction back to the origin chain and then pull their funds out and submit a new transaction but that's just like horrible horrible user experience and it's really unclear like what that even looks like in practice a last option that i think has started to be explored is pessimistic locks so instead of actually ordering transactions or locking them at the point of the transfer itself you lock the pool before you start the transfer this is something that you do with databases where you you could set up like a mutex on uh on on some part of the databases state while you're executing something over here and accessing the database state repeatedly and then you release the mutex at the end of of of your process so that way other processes can now start accessing the update at the same time there are downsides to this even outside of the space so one of the big downsides is things like deadlocks um where you have two things now trying to access the same stay at the same time it becomes kind of weird you're like okay well which one of these things should happen first which one of these things should happen later um and that's actually even more weird when you're starting to deal with liquidity rather than just at arbitrary states so in this case if you have a pessimistic lock you are now locking you're now locking sublocking this pool just in time for each transaction but in order to do that you actually need to have a lot more messaging overhead you need to have a message that goes back and forth from you know origin one to the pool uh to lock a part of the pool then the actual transaction and then another message to unlock the pool um that's you know in a in a database environment that's not that bad because you can send these messages within like you know milliseconds if that um but on chain uh that latency can add up pretty quickly like if you're using something like nomad that can eventually be like a few hours for a transaction which would be kind of ludicrous um but even otherwise even if you have like very very low latency in all of these cases these are unchanged transactions so like if nothing else you have an incredibly high cost um and beyond that you also kind of get into some of the weird aspects of like okay well how would you handle a deadlock in this kind of uh in this kind of a scheme um and it's not really clear uh you know you would you would end up in a situation where uh you know if if origin 1 and 2 were interacting with the school at the same time and origin 3 tried to make a transaction um and and got deadlocked then origin 3 would just kind of be stuck until the others figured it out and and whether or not his transaction would go through would again depend on whether or not there was enough liquidity in the pool the kind of conclusion of this is that for pools and for this specific use case that we're talking about here none of these options are really that great um it kind of sucks we have a lot of like trade-offs associated with building on top of blockchains and one of the big big trade-offs is that they're expensive and slow and and this is especially magnified when you're trying to deal with something that's as complex as like concurrency um and so you know while it's true that you could potentially use these sorts of strategies for concurrency control on uh non-defy applications so on applications that aren't necessarily uh utilizing liquidity you uh you are probably going to run into issues with like pricing and complexity if you try to use them within v5 or within cross-chain design another really weird thing is synchrony and this is another kind of assumption that ends up getting made in the space quite a bit when people think about building cross-chain applications so by synchrony i mean the fact that there is asynchrony across chains means that it isn't actually possible to know this it isn't impossible for any one chain to know the state of another chain at the exact time that it knows its own state um a good example of this is say you are you have again yeah like our strongman of uh of uh of uh or maybe not strongmen uh a our quintessential example of a cross-chain amm and you have a pool of funds on on the origin chain made up of asset x and a pool of funds on the destination chain made up of asset y um in order to calculate the price that you swap into asset y on on the destination chain you need to know the the state of the pool at the time when the swap occurs so say when you initiate this swap at p0 you know that the state of the pool is s0 and this is what gets transported across chain by the time it gets across chains um the pool state of x is is uh is uh is actually changed to s1 um and the reason for this is that of course there are people making transactions going in the other direction the pool is changing constantly in size however at the destination chain this is actually not known uh at the destination chain the pool state at t1 is still s0 and it gets kind of weird because it's like one of the fundamental assumptions of amms is that you have a constant product right as we know the k and x y equals k stands for constant um but if you have asynchrony and you're making the synchrony assumption then you end up with a curve that doesn't actually look like an m at all amm at all it just looks like something that is not going to be extremely helpful for pricing um because now your constant is only sometimes constant um how do you synchronize pricing well this one's actually even more difficult you could use an oracle to have access to the to the pool state of all pools at all times um you can try to use a decentralized oracle for this but then once again you're introducing more asynchrony and potentially more assumptions there um if you use a centralized oracle then now you've just built coinbase so that's not very helpful um another option is to actually just have uh the pricing itself just happen entirely off-chain and this is something that's been explored quite a bit in the past you know this is originally how like xerox worked and a bunch of other projects have tried to try to build off-chain order books that are decentralized um but now you know you have some of the the same trade-offs that you did at that time which are that off-chain order books are just really really complex and like you have to think about what it means for uh this off chain order book to achieve consensus and things like that um once again none of these options are really that great uh you synchronizing things across chains and especially synchronizing pricing is just like a really really weird rabbit hole that uh is difficult to go down and you end up in sort of really unpleasant places um the kind of takeaway from this is that building these size apps is going to be tough um and it's not just like building distributed systems outside of space and the reason for this is that messaging overhead in on blockchains and between blockchains is costly you know it's not like messaging overhead when you're going between two databases where you can have many many millions of database updates happening per second if depending on how optimized your database is um instead you have one update happening every so often and it costs a ton of gas so you you really want to make sure that whatever construction you come up with minimizes the amount of messaging that you're doing between chains to begin with secondly state updating update ordering actually matters um in a in a database it only matters sometimes and in many cases you're able to kind of get away with using other mechanisms like you know things like kafka basically cueing mechanisms to be able to handle ordering better and insert things into a database in the correct way but that doesn't really work as well in this case because again gas overhead and when you don't get ordering correct or when it is possible to manipulate ordering to change pricing then you get mep is there a way out of this um i think over time we'll come up with better ways to handle concurrency across chains and to handle some of the design patterns around asynchrony and one of the things that will actually be the the impetus for this will be a massive reduction in cost of operating on these chains to begin with because really really like a lot of the bridge costs come from um the cost of the the underlying chain or roll-ups as we as we drive down the cost of roll-ups very significantly uh by moving to east 2 and things like that we will end up in situations where it is you you will have a bit more flexibility on the messaging overhead that you can have and probably better mechanisms around ordering as well however for now our recommendation is to try to build replicated instances instead of fragmented ones by this we mean have instead of building a cross-chain amm that has pools on many different chains all at once or a cross-chain lending protocol that has you know borrowing on one chain lending on another completely isolated from one another and then trying to synchronize those states against each other instead actually have replicated amm so you have an amm on chain a a good example this is something like sushi right you have you have sushi deployed on every single chain and then what you do is you make it possible for users to be able to to make transactions directly between these amms so that it goes you know swap to transfer to swap all of that can happen in a single transaction and then you allow for rebalancing the pricing between these chains using very cheap and efficient arbitrage um the mental model here is similar to something like ipfs you have a distributed system that has a bunch of replicated states that achieves eventual consistency the nice thing about eventual consistency is that it's very very low overhead um it's driven by market forces in this case there's very very strong incentives to actually achieve that consensus consistency in the form of arbitrage and um you get to kind of like mitigate a lot of these really weird situations that you end up at when you deal with like state itself being fragmented on many many different chains now of course this is early there's still a lot of like there are a lot of really interesting use cases around like protocols and things like that that actually where it does make sense especially if you're trying to just go and grab some arbitrary state somewhere else um that isn't liquidity it does actually make sense to still try to use like uh to still try to fragment the state or try to use mechanisms like concurrency control to like update that state a good example is something like um you know uh uh pcv in um in uh in uh uh in like a protocol where they uh pcv is used like the the the protocols pcv is used as a like pcb constants are used as a mechanism to decide how much money can be minted against like the protocol treasury and when you are minting against protocol treasury on other chains it is possible to just update that pcb value on other chains rather than having the liquidity move to other chains as well um so there are kind of like optimization functions written around this but generally speaking i would hesitate to like do not try to avoid um situations where you have user-facing pools and other kinds of like user-facing interactions that are fragmented on many many different chains all at once um this is a obviously like initial steps into into building defy into building cross-chain defy applications there's still a lot to be learned here and we're pretty excited about the the direction a lot of stuff is going so if you're interested in talking to us about it definitely message us on on our discord we have a very very awesome community that talks a lot about this stuff and and has a lot we overall are trying to figure out ways to like pioneer some of these standards around asynchronous ability um you can also follow our twitter for updates um and if you're interested in building on top of us um check out our docs we have a you know we have our new upgrade live on testnet right now and it should be fully possible to build things on top of um and then uh and it should it should be going live to mainnet within the next month or so and lastly if you do build on top of us and if you're not in the us apply to our contributor program we're running a program where people who uh build projects and otherwise contribute to connects can earn tokens um as uh once the token network once the once our token launch happens in again about a month or so um and we think of this as a good incent as an incentive mechanism to get some of these early applications early examples of what it looks like to build costume device out in a while cool thank you everybody i appreciate your time