Bridging the ÐApp: contracts talking across chains by Björn Wagner (Devcon4)

hi I'm beyond and when it comes to bridging that AB talk contracts talking across chains so I will use the next half hour to tell you a bit about a project if you know vajay overview on a project that we kicked off roughly one and a half years ago in the larger context of another poem project which we call polka dot to really understand what we're trying to do I want to give you just a brief brief gist of polka dot so polka dot is our take on a next-generation blockchain protocol with key tenants being scalability interoperability and governments it really is heterogeneous multi chain proposal a framework that is set to enable independent blockchains to exchange information and value in a trust free manner now for this larger vision to become a success we need a component that we call the birch and the bridge in that context it's supposed to enable block chains that ourself secure that means that provide their own means to come to consensus to really communicate with each other now when we started with that project we realized that we really got an opportunity to create value for existing aetherium developers rather than shooting for the moon in a few years and in order to understand in what way this can help a serum developers today it's important to understand the problem that we are facing today those teams that building dabs today and I mean most of you are aware that the name of the game is scaling right we still haven't figured out how easy remain that can scale and I personally at least am very skeptical saspa will arrive within the next 12 month and I think Edward rather take a few years until we really get them and what we've seen over the last years is that we have this amazing ecosystem like hundreds of projects that have been working hard on implementing certain depths right certain depth with a certain smart contract architecture and it's sad but the reality is that a lot of them can't go live today on maenette because transaction fees are prohibitively low prohibitively high so the depths are economically not feasible and second we get into these situations where the network is just congested right the blocks are full and some people may say right but you know we have all these other EVM scaling approaches right that can potentially help us today or rather in a few months when they're done and a lot of them we we call Lea do scaling solutions right so we have one to run micropayment chairman it's such as micro Radin or we have state channel approaches from the wonderful team from fanfare the january state Senate from counterfactual or the great work that spank chain has been doing and last but not least just plasma right but what a lot of people forget is that those approaches are not applicable to most dab architectures that exist today so these teams that have set out like a few years ago when these ideas weren't around yet right and have written like hundreds and thousands of lines of code right I in a situation where they're like if we want to use these approaches these layer to scaling approaches that really means they have to start from ground zero they have to react attack their hold up so and that is what I believe parity bridge can at least help until in the intermediate time until chess pass around right so let me introduce you to what that paraty bridge basically it's a federated system that allows to relay arbitrary messages any kind of messages between two evm networks between two EVM chains for the sake of this presentation here let them call the main and side chain right so we have two there are three critical parts of that verge that exist today one is rust software that connects to two aetherium nodes via RPC or IPC you can choose and really just watches the chain for certain events to be triggered then second there are mid-space entities persons that run the aforementioned software and they are the authorities that validate and eventually relay the messages from one chain to another and last but not least we have smart contracts on both chains that coordinate between validate between these authorities the validation the relay and eventual delivery of the messages now what can you do with them right that's that's the biggest question well the nice thing about that is this general approaches that you can have adapt that has a smart contract on one chain that suddenly calls a function on a any contract with any parameters on another chain it's that simple and security of that message relay is guaranteed by trustworthy authorities so for every and each message that's being relayed it's required there's a that a certain number of authorities have signed off of that message relay and overall we try to keep the system as simple in general as possible right now how can that help mitigate these scaling issues that we run into well if you can offload a large amount of transaction from one chain to another right that that is an approach you can choose and really what you can do there now because of this arbitrary message relay approach is you can spread out you dab between those multiple chains so you have the assets that need to live on main that right on the assumed name that may be those that have to be interact with exchanges or maybe some identity of the user that can stay with us right but those interactions within the apps that happens on chain right that are really computationally expensive or we try a lot of transactions those you try to outsource to another app so that's one part the other exciting part about that approach is in my opinion that you can really get early access to new features features that are have yet to become available on the main net so if you take as an example that the sidechain is being run by parity theory nodes right in a pure network you could have today wasn't smart contracts being run down you could use private transactions or you could try out constantinople opcodes that will only become available in half a year in general when you Maynard upgrades there's one note of caution I wanna I want to add here and that's very important to me why this is really great for the moment in the long run this isn't gonna solve the scaling issue in in in the hole right that's why the slide says mitigating scaling issues and not solving them because what that means here is that you know if you spin up a new side chain that means you also have to secure that chance I chain and as more side chains are as more resources you need to secure these individual side chains and we all believe that that can't skate securely nonetheless in the meantime this is a way to get your application life so for the sign change what options do we have I believe you can choose between three flavors right now either you say hey you know I need the the transaction throughput that's available on a new change for myself for my own app in Pepe or a parity theorem you can get up to maybe 500 maybe one to two thousand transactions per second and then you just say like hey I spin up my own def specific chain you get a few different projects to run an authority note and thereby secure your chain or you say no actually you know this is as a team and we have like applications that interface with each other that are reliant on each other and we both make a consortium and we spin up our our kind of deaf friends of dabs chain or last but not least you use an existing bridge that verges existing networks for example the easier main network with the cove intestine now let's take a look how parity bridge actually works the next few slides will show you what a walkthrough for message being sent from main tree send what you can see in these diagrams is on the left side there's a main chain on the right side there's a side chain on the main chain you have a contract deployed that's called which contract right now it has one function that's called relay message on the side chain you have a bridge contract as well right and it's called it has a function called confirm message now some app wants to use this bridge what the Deaf does it deploy is extension contracts so contracts that know how to interact with these bridge contracts so we have on the left side sending contract which is part of your DAP it has some function and on the right side we have on the sidechain a receiving contract which is also part of your application and which has a function accept message now we also have bridge authorities write these in take this integral part of the system that actually facilitates the message relay between the two chains and that watches both chains now let's say a user kicks of a transaction with your application it called some function and some function again called relay message because I wants to send over a message to the other chain that again kicks off it triggers an event called relay message the Bridge Authority see that event being triggered they wait a few confirmations because they want to wait until they have a higher degree of finality right because the main ad it has only probabilistic finality and you really don't want to relay a message that might be reverted after the fact right so after a few block confirmations the authorities confirm the message one by one on the other chain once a certain threshold which is configurable has been achieved another event is triggered which is receive message and then this contract the bridge contract on-site chords whatever the recipient contract is and calls a function called accept message there that's a message delivered and it there can be whatever transaction should be kicked off by by this interaction can be kicked off by accept message sign so that's add the message relay the other way around from site or main is not identical to this interaction and that is mainly due to the reason that we build on the assumption that transaction costs are significantly higher on the main side than the side side and that means you know bridge outside is real we want to interact as little as possible with the main blockchain and like gather signatures gather these confirmations on the side chain so how can you utilize it as the app developer like what do you have change them and critically there are two interfaces that you need to be aware of you can see both here one allows you to relay a message it only has two parameters it's a data whatever your messages as well as a address which is recipient address on the other chain also you have a function called accept message which your recipient contract has to implement right and that's it one thing is to be noted here all information obviously needs to be encoded in the data parameter and the recipient contract needs to be able to decode that message and do certain actions based on this degradation now I brought you a few examples of what you can do with them so for example you can use to build an ELC 22 s and C 20 bridge you look up you build for example let's take organ as an example you build a contract that allows you to lock up orca on IEP on the main net that contract sends a message through the purge to another contract on the side network and says hey you know a sign that many or got oaken's that only live on the side network to this person and vice versa pretty straightforward as well you can do that with native currency so on the manor you could look up ether on one side and create rapt ether on the other side which is really an ESC 20 token that is redeemable for one ether on the main network and the last example I brought here and that's the one I'm most excited about probably in the in this combination here is that you can have an ESC 20 token on the main network lock it up and then if the user whoever locked it up native currency on the side network and that really means you suddenly can have a stable coin peck native currency on the sidechain right you can have died being essentially the currency that you used to pay for gas on your side network and if you combine that for example R is fixed gas prices you suddenly have a situation where those people that run dabs are those people that interact with stamps on your side network have full control and full understanding of what their transaction and their interactions will cost there will be no volatility and this last part really was made possible by something we called la cravat contract which allows a smart contract to inform the consensus engine how many new tokens should be minted and who they should be assigned to but basically the options are pretty much unlimited of what you can do everything you can write in a smart contract you can do them now here a few of the projects I've personally talked to that have either been using the parity bridge or that have been waiting for the arbitrary message passing in order to you know split up they're there between multiple chains now as always there are certain caveats with this approach and they occurred certain cave reads with our current implementation that I don't want to not talk about so number one currently all of the bridge authorities right these authorities that relay messages should also be authorities on the site network so they should be the validate as a block producers of new blocks on the side chain that is because currently the system is designed so that most transactions that happen on chain happen on the site network and you don't want the authorities to have to pay for these transactions right for both reasons spam protection as well as cost but if the British authorities happened to be the POA or authorities on the site network they don't have to pay for the transaction that they put in their blocks so that works pretty well in my opinion it also works pretty well with the trust model that you have to assume around this application because you know after all if you don't trust the authorities on your site network you know truthfully maintain integrity of this side chain right then you also wouldn't want to trust a bridge that relays messages through this chain right another one currently the spiritual authority set is immutable right it's very trivial to change that we can just add another contract logic that allows you to have a majority vote and vote a bridge authority in or out however you want or add whatever it's governance mechanism you want last but not least if you connect two chains and one of the chains is a proof-of-work network then unfortunately you are facing the problem that you don't have deterministic finality which means if you want to be fairly sure that nothing is being reverted you want a very weight of huge transactions and that introduces lesson let and see that we don't want that sad if you've got two networks that have deterministic finality there's really no no reason to wait longer than ones finality has been achieved on any block last but not least there's a very important note of caution here the contracts I've been talking about here they haven't been audited yet so please use with caution they in an alpha phase right so further challenges transactions on Maynard are very expensive right so if you relay a transaction from the side network back to the main network then you need at least one transaction to be made by authorities and that's the transaction that actually relays a message right so now who should pay for that transaction that's still a problem we are facing I believe in most cases it won't be a big problem because the application that decides to implement the site network and to utilize the bridge has an intrinsic motivation to pay for these transactions because it obviously increases the value of the network the overall network and its application second what happens when relay message kicks off a transaction that actually runs out of gas right like we are facing a more acing situation here and that's not trivial at all to to mitigate another thing that shouldn't be unnoted is that there is still missing tooling for side-chains right even though we finally have an open-source blockchain Explorer which is absolutely fantastic right which you can spin up for your site Network we've still met miss madam asked and if here and other kind of things that we usually want in order to effectively build on a network last but not least there are UX considerations that you have to take into account when you follow this approach for example you might end up in a situation where the user that interacts with adapt has to switch between networks which is not quite nice also the user might have to own native currencies on both networks so last thing a bit about the roadmap that we are looking at next things we want to do include we not want to enable which authorities to vote on a new bridge authority set what I just said dynamic bridge authority sense ii what we really want is that the bridge authorities are tracking whoever is an authority on the on the site networks and that these set are pretty much identical further we are exploring methods how the site network can be proof of stake and the sidechain validate us you know the validators of that chain actually state is on the main net which is a fairly interesting approach furthermore we are interested in finding more interesting use cases writing more extension contracts and last but not least they are still chilling that should be in place for example monitoring tooling that allows us really to inspect and see what is happening in the bridge and what messages are being relayed and debug problems if there are any problems I invite all of you to please have a look at our Vicki Reid contribute shared with us I can't wait to hear what you want to build with that and on what network you want to build it is it coven is that your own app for specific chains are you going to team up with giveth or some other teams to build a new chain in the meantime as long as the manor doesn't scale thank you so much so I've got another five minutes for questions I can repeat it to you them on the roadmap I noticed you guys had no intention to audit your contracts is that something that you know you're going to do I'm sorry on the roadmap you guys didn't list any intention to audit your contracts is that something that you guys are going to do because that hasn't really worked out well in the past yeah most definitely so what I want to see first is a bit more experimentation right we were we were we haven't actually released arbitrary message-passing Burchette it's already in github yeah you know you can play around with it it works but you know we want to write a few more integration tests and then I expect us in the following weeks to release it then deploy a test version between Colvin and maybe Robson right play around with it invite more people to play around with it see if it really you know fulfill these requirements and meets these needs that people have and then once we got there sure like definitely either we do it or we team up with a few teams to audit these contracts thank you yeah thank you for the question hey hey thanks for that Bjorn and thanks it looks looks really exciting and what question I had was with the bridge authorities who do you envision those would be like what are their incentives for actually securing those relay messages across screens across chains again how to panic punish bad actors that might seep in right I can envision multiple scenarios right number one the most obvious one is the DAP that needs to utilize the chain right being at their own chain or the multiple depths that want to spin up their own chains they have an intrinsic motivation to you know facilitate this transfer and after all the price isn't really the problem the cost the expenses to spin up a node today I believe for its nearing may not cost like what $150 a month geronimo note so that isn't really the point and to my knowledge I think POA network has been running the bridge for over half a year now and I think the cost were negligible so reason I ask is one of the most exciting use cases which I've thought of with something like thunder core something like that being able to use die sound one side chain and move it over you know you can end up if some application becomes really valuable or really of hot use right these bridge authority czar going to be presumably taking and Diet and being able to direct it in the main chain you know there might be a lot of valley moving from one chain to another that's it right and so obviously there's an incentive might be an incentive there right for you know then to direct die to some other contract that's not the intended intended contract right I can sum multiple aspects right I still think this is only an intermediary solutions as I said because I think we need to come to a point where we pull security for all these chains right this booty chain future where you have like thousands of chains that all secure themselves bid in in in this model right well you have IBM chains being bridged by parity bridge or in the cosmos model where you have all these zones that have to secure themselves I don't I don't think that's feasible in the long run right for me this is really an approach for all these applications right now that are facing these issues that they have been working on all that code for like multiple years and they are facing the situation a either you wait another three years and Jasper's here or you restart from scratch and try to implement it with layer 2 solutions such as state channels right that said I'm not quite sure if that click are you are you asking about the the danger of having too much there you locked up in a POA chain well it's well maybe not necessarily POA but for instance like you could mint dye on the main net right and then there's some application that uses dye say on another chain maybe it's like a proof-of-work saying or a peewee powder or something right and you send you know I don't know a million dollars into the other chain right through the bridge value gets generated there or whatever then you want to secure it back on the main net you know destroyed or properly accounted on the main net but maybe it's just not the youth the right use case for this kind of okay I get so so you're asking how can I trust these authorities effectively because they can send the diet you know wherever right that's always the case right like it's it's the same thing as in in any theorem proof of work or in any kind of proof of state system how can i sir I I trust that the validators who validate my chain be the chain or or the bridge doesn't really matter in that sense right like don't collude right don't build a cartel and say like oh I'm actually gonna take all the value out of that bridge very good question I think like as a user you've got to be really cautious to interact with certain chains with too much value right I wouldn't want to transfer a million died over to a chain that I know is rarely being used where there may be two to authorities only that have aligned incentives to actually collude and steal your money right yeah thanks for that appreciate it thank you thank you so how is the fault tolerance maintained at the delivery of the accept message is there a ring signature or something of the validators no so what is happening the Bridge Authority is do two things right when they watch message coming from me into a site on the site matches they all have to call a function on sight network right and you have a configurable section and if you say seven out of ten authorities have to sign off on the message only then the message is actually being relayed otherwise not right and in the other way around you gather signatures before right they gather signatures on the side network and then the last or ''tis submits one transaction on the main network that accumulates on all these signatures and the contract checks that all the signatures are there in that way you have like for tolerance okay is there is there like like on state channels where there's kind of this like the waiting period after message has been relayed is there something like that so that maybe somebody can bring in attestation saying that actually that's not what happened on the opposing chain currently not because really you take these the set of which our sorties as you are you know your point of reference if they say hey that message was real that is actually relayed and in order to make sure there's no reorganization they wait a few confirmation block confirmations in order you know to be sure that actually whatever kicked off this relay happened on the one side of the chain thank you thank you for the question I got a head off thank you [Applause] you