Connext 🛠 Building Crosschain xApps with Connext

[Applause] [Music] verified bridge these bridges are like light clients ibc they're great because they're verified by the chains underlying validator set so you're not adding any additional trust assumptions outside of the ones introduced by switching domains inherently the other great thing is you can kind of pass any type of data between these two domains using this system unfortunately these bridges are really difficult to create because they're heavily dependent on the underlying consensus mechanisms and like the underlying chain dynamics so i'd have to like i can't just take ibc and now use it for my eth to avalanche bridge because that's just not how east or avalanche works so they have to be kind of developed in a bespoke way that next kind of bridge is called an externally verified bridge what's great about these bridges is they're portable between all domains so that pretty much will work the same regardless of what chains they're connecting you can pass general data between them unfortunately the concession that you're making when you're using this type of system is that you have introduced a third validator set that isn't necessarily the same as your origin chain validator set or your destination chain validator set and that can be problematic because you are now like the in the security in all of these systems is only as strong as your weakest link and so when you've added an additional validator set that's really what's holding the security of all of your payments um shout out harmony uh the next one is locally verified bridges these are bridges like like atomic swaps um where basically you take some transaction where you want to go from chain a to chain b and instead of including everybody in the chain and including it as part of the state you kind of match up to somebody else who's willing to go the opposite way and you swap funds this is great because like you're not really adding any trust assumptions basically your counterparty will always verify that you did something correctly these usually happen through some type of commit and unlock mechanism the downside is you can't really it works the same between all domains like you really only need a hash function and a signature for the most part uh the downside is you can't really pass complex data around because that doesn't translate easily to a two-party system yeah so lane covered uh externally verified and locally verified and so you can see that externally verified it's quite extensible and portable meaning you can sort of pass any type of data and move it to any type of chain but it's insecure for reasons that you're trusting another external party with your funds or data and then she also touched on locally verified which is i guess very secure and minimally trustless but not very extensible and so we'll see that optimistically verified bridges are somewhere in the middle ground between these two things and can achieve both of these just kind of at a high level the way that an optimistic bridge works specifically i guess we'll talk about nomad is that someone from the user perspective will send a message and we'll have an offshoring actor pretty much attest to that and say okay this user sent this message let me sign a piece of data which attests to this message and so we'll post that on the other chain and the other chain before accepting it will start a fraud would a fraud window and basically say okay within this amount of time we'll let someone dispute it and submit it fraud proof which will basically tell the protocol hey if this attestation was invalid don't listen to it and disconnect from the messaging channel the reason why this is more secure though is that with something like a multi-sig which is an externally verified example you have basically a k of n honest actor assumption if you have a 3 of 10 multisig you need at least eight honest actors as soon as you have seven there's now three malicious actors which is enough to compromise your multi-sig an optimistic verified bridge then you really only need one honest actor to maintain liveness as long as there's one honest watcher which is inspecting these attestations from the updater you can assume that your funds and data are safe so does anybody have any questions right now about the different types of bridges before we move on yes yeah sorry maybe i wasn't too close um what part did i miss yeah that's a good point so i mean like at the moment uh nomad for example a watcher is a permissioned role where it's like a white-listed role and if they submit an attestation of fraud that is enough for the protocol to disconnect eventually this will be something that's permissionless it's just kind of like takes a lot of engineering work to get there but the trade-off that the way we think about this specific trade-off is that at the very worst you can if you're a malicious watcher you can grief the channel but you can't actually steal funds and so we think that this is a more desirable desirable trade-off than permitting some kind of scenario where you can actually steal user funds are there any other questions sorry could you speak up just a little bit i know having the same problem here sure um yeah so i it's a lot like sort of the way an optimistic roll-up is uh modeled like you basically instead of with an externally verified bridge let's say you have a multi-sig if you know if the threshold number of signers sign off on something that's kind of your what serves of zora proof that this event really did happen on the other chain we kind of flip that model and we'll have basically one signer attest to something and we'll let we'll post it on the other chain and let a committee of watchers essentially inspect this attestation and say it's either valid or invalid um it's basically you're giving the you you give the watchers the power to veto something as opposed to giving someone the power to actually say that it's correct uh right now they are whitelisted parties so a lot of l1 teams want to run their own watchers a lot of like defy apps for example want to run them as well so we want them to be such that the incentives are already aligned um but eventually this will be a permissionless role so at the moment it's it's a whitelisted thing now ahead yeah so the dispute window for nomad right now is 30 minutes a lot of people ask why uh why not seven days i think for optimism or arbitrarium the reason why it's this long is that the process of actually proving fraud is much longer there's a lot of transactions you have to submit on ethereum [Music] and from what i kind of understand at this point there's also some social coordination aspect for us because it's uh a whitelisted role and like you're just submitting an attestation that fraud happened we don't need nearly as much time and so really the way we parameterize the fraud window is just it's based on the economic cost that it would take to censor the chain essentially if you're a watcher and you need to submit a fraud proof how much would it cost if you're trying to censor that fraud transaction cool we'll leave more time for questions at the end but i'm going to keep it moving for now so hang on to them okay so another important concept that exists in the cross chain world that doesn't exist in the single chain world the regular dap world is asynchronous solidity and basically what i mean by this is the states of the two chains that you're connecting do not know about each other so if you think of the example of an amm well why does that work as well as it does on ethereum it's because you have when you have a transaction you have like solo read write access to the state of the blockchain um which means that the constant product formula can remain constant because the liquidity is always traded equally if you're building like a cross-chain amm these things that same assumption does not hold so you can't say that like oh i have full access to trade usdc on matic for usdc on optimism and it happens as soon as i submit my usdc on matic because the optimism chain has no idea that you wanted to start this transaction in the first place so these are the types of things that you have to be aware of when you're developing cross-chain applications that you may not have had to think about when you're developing regular dapps uh asynchronous patterns are very common in like regular web development so this is like a direction that i think is useful to go in um but it is something that is different than the most of the tooling that is available and most of the ideas that are in development patterns that are commonly used uh so now we're gonna dive in a little bit to building a zap and kind of what that looks like um so first what what is a zap like what does the anatomy look like in the architecture you have uh basically a contract on the sending chain and the receiving chain and then you'll submit your transaction to the source contract on the sending chain which will then call your bridge in this case it's connext that happens to be the one i'm most familiar with um and you call x call which then will initiate a cross chain transaction this is where the asynchronicity comes in as that transaction is propagated across to the destination chain by a network of relayers and then validated either by the nomad timeout or what have or somebody else is willing to take on that risk for the timeout then it is the action is propagated to the target contract so there's also another concept in this dev in this cross chain development platform with connects about authenticated and unauthenticated data and what that me means depends heavily on the optimistic timeouts because we are built on top of nomad um there is latency built in as part of the security mechanism again optimistic systems in general use time as a way to gain security like if nobody submits a transaction or disputes that something has happened within a certain window then you know that that data has been authenticated because the assumption is there are enough actors in the system who are incentivized to have correct data that if it is incorrect somebody will say something um so in connects we have this concept of authenticated data and what that really means is like permission calls so when you're executing a cross-chain transaction you'll want to make sure there are some calls where it the data that you're using is completely fungible like a token transfer you don't really need that uh data to be authenticated however in contracts that check like message.sender you need to make sure that that data has gone through the fraud proof window so that you know or can assume that then it is authenticated by the time you're acting on it for example if i am doing cross-chain governance i really need to make sure that i know that the data that is coming from some chain to the target chain has gone through that fraud proof window otherwise it is spoofable by the relayers it doesn't matter if it's spoofable for transactions that are completely like fungible again token transfers but for something that is more sensitive you have to make sure you have that extra security so yeah the unpermissioned calls are calls where you can go from the source to our relayers off chain the target all pretty much immediately in the times as immediate as blockchain gets in the time span of two on chain transactions whereas again permission you have to wait before you propagate the data for it to go through that fraud proof window yes right so the actual authentication depends a lot on how the target contract is implemented we'll walk through an example of this in the simplest way is the message.sender so we will pass through the original message.sender from the origin source chain but any relayer if you don't wait for this data to go through the fraud proof window could insert any message.sender that they want because nobody's challenging on it it hasn't been submitted as correct by the underlying system so that's why you have to make sure that you're waiting yeah yeah i think like a good example here is uh think about a token bridge so there's like two token bridge contracts and ultimately when you decide to send uh some assets to another chain that's you calling the tokenbridge contract which calls like our underlying message layer and so the the message.

sender ends up being the tokenbridge router on the sending chain and so that that gets wrapped up in the message and so basically the token bridge router on the other chain will only accept a message if it's from the other token bridge router correct yep yes oh i'm deaf you're gonna you need to yell no the the chains will not know about each other's state like they'll only know what data you've passed through cool okay so yeah so now we're going to walk through some example codes um the example i'm just going to lay it out for you it's very simple it's pretty much just like set value on destination chain contract from source chain contract using connext so here we have some example uh solidity code for how you would integrate that the source dot sole is basically what you would co that's your entry point for this user flow where you call this with your intended updated value on the origin chain this will then create the parameters to xcall which is the function that will initiate the cross chain transaction it's designed to mimic the lower level solidity call pattern but cross chain x um and then you call x call once you do that the relayers in our system will automatically pick up that this transaction has been submitted and simulated on the destination chain if it fails then they know okay well this is more likely a permissioned call um or spec explicitly specified that it wants to use the authenticated data flow and now i'll just wait for that to be fully propagated once it's fully propagated meaning that the message has made it through to the destination chain via the nomad system and has gone through the fraud proof window then you can go ahead and call the updated value on the target contract now the target contract so uh if you i'm not sure your name but if you look closely at this modifier this only executor modifier you can see that the origin sender which is the message.sender on the origin chain is asserted to some specific address and the same with the domain so like i only want if you again like if you're doing cross-chain governance i only want the ave dao on mainnet to be able to influence parameters for the ave contracts on polygon then i could assert that using something like this only executor modifier that exists on this update value contract does anybody have any questions before we dive yeah well you can pass arbitrary data between tens but you can't like if you didn't pass it the chain won't know about it so you can read anything that you've passed through but you're the one who has to initiate that right yeah i mean there's no like the chains that's the whole thing with asynchronously is that you're not composable they don't know about each other and so you are the one who has to pass that data through what do you mean can the parameters be changed yeah well i mean it's your target baby you can do what you want what yes sorry so the question was can the parameters be changed on the target contract so if like i want to change the admin yes you can that's completely up to the implementer of the target contract these origin sender and origin domain properties are just things that we expose when we when you make x calls so when you create that x call contract on the source chain uh that information about which chain it's on and who called that function is passed through to the destination domain so that changes based on who calls it where it's called from whether or not that matches with who the admin in is on the target contract is up to the implementer cool um so i there's an example repo here i'm going to kind of exit this presentation and look at some of the other cool things that you can do with k'nex so one of the other things that we're really excited about with our new protocol is the ability to do js style solidity callbacks so what does that mean this actually may be more relevant to your use case but basically sorry those aren't quite good enough okay okay so the con the source contract implements this interface called i call back the i callback interface um is right here and what this means is this is any contract on the source chain that can process return data from some call executed on the destination chain so when we execute arbitrary call data we just use the dot call on your destination domain and then you get back whether or not that was a success and what the return data from that contract call was if you have defined a callback when you initiate this call and x call then the protocol will automatically take the success result and the return data and propagate it back to the origin domain so this could look like in this example okay i want to update some value but i'm not going to specify a value instead the target contract is going to randomly choose a value so i call change value that will update the contract value from you know 3 to 11 or something and then i've specified a callback that will emit an event with that new value and so once that's changed the information is sent back to the origin domain where then i can say oh great the random value was 11. um and so that's kind of what i mean by solidity style callbacks and you can see is there a question nope okay and you can see that here in the source they implements the callback interface and this is the callback function where it decodes the new value that was set from the data and emits this event are there any other questions yeah yeah exactly uh the fraud window is let's just say that you wanted to build your own app you could i mean like the fraud window that we have for our core contracts are 30 minutes but you could technically deploy your own like set of core contracts change the latency and yeah it's definitely configurable depending on what level of security you want yeah yeah so we we have our own watcher implementation this is what we provide to partners and other apps that want to run it um it's just running a docker image go ahead right so your first call would still have succeeded but the sorry repeat the question yeah so um the question was if i have a revert on the target contract well that what happens to the original transaction like what happens to the flow where does it fail where does it break down um if you have a revert on the target contract there's a fallback function so any funds would just get immediately sent to your recovery address that's pre-specified but if you have also specified this callback interface the fact that it failed will still get propagated back to the specified callback contract are there any other questions cool um yeah so i'll just give you some updates on timelines then we are working on we're finishing up our audits for this protocol and it should be live yes yeah we'll fix it in the middle of a workshop getting called out by my cts so unreal [Laughter] uh any other questions cool awesome well i hope you guys learned a little bit about what goes into building across chain applications and the things that you should be thinking about if anybody at this workshop has been contacted by duck he's he's over here in the back and you guys should probably reach out to him and find him somewhere where it's more okay to talk awesome well thanks guys [Applause] what that he called me no i just liked