 Hi, I'm Björn and welcome to bridging the web to our contracts talking across chains. So I will use the next half hour to tell you a bit about a project, give you an overview on a project that we kicked off roughly one and a half years ago in the larger context of another project, which we call Polkadot. To really understand what we're trying to do, I want to give you just a brief gist of Polkadot. So Polkadot is our take on a next generation blockchain protocol with key tenants being scalability, interoperability and governments. It really is a 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 Birch in that context is supposed to enable blockchains that are self-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 Ethereum developers rather than shooting for the moon in a few years. And in order to understand in what ways this can help Ethereum developers today, it's important to understand the problem that we are facing today, those teams that are building gaps 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 Ethereum Mainnet can scale. And I personally at least am very skeptical that Shasper will arrive within the next five months, and I think it would rather take a few years until we really get there. 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 depths 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 Mainnet 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 we have all these other EVM scaling approaches, right? That can potentially help us today or rather in a few months when they are done. And a lot of them, we call they get two scaling solutions, right? So we have one-to-one micro payment channels, such as Micro Raiden, or we have state channel approaches from the wonderful team from Funfair, the general state channel from Counter Factual, or the great work that Spank Chain has been doing. And last but not least, there's Plasma, right? But what a lot of people forget is that those approaches are not applicable to most depth 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? Are in a situation where they're like, if we want to use these approaches, these layer two scaling approaches, that really means they have to start from ground zero. They have to re-architect their whole doubt. And that is where I believe Parity Bridge can at least help in the intermediate time until Cheshire is around, right? So let me introduce you to what that is, Parity 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 them main and side chain, right? So we have two. There are three critical parts of that bridge that exist today. One is Rust software that connects to two Ethereum nodes via RPC or IPC you can choose and really just watches the chain for certain events to be triggered. Then second, there are need space entities, persons that run the Forged Mansion 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 these authorities, the validation, the relay, and eventual delivery of the messages. Now, what can you do with that, right? That's the biggest question. Well, the nice thing about that is this general approach is that you can have a DAP that has a smart contract on one chain that suddenly calls a function on 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 that a certain number of authorities have signed off of that message relay. And overall, we try to keep the system as simple and general as possible, right? Now, how can that help mitigate the scaling issues that we run into? Well, if you can offload a large amount of transaction from one chain to another, right, that is an approach you can choose. And really what you can do then now because of this arbitrary message relay approach is you can spread out your DAP between those multiple chains. So you have the assets that need to live on main net, right? On the Ethereum main net. Maybe those that have to be interact with exchanges or maybe some identity of the user that can stay where it is, right? But those interactions within the app that happens on chain, right? That are really computationally expensive or require 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 have yet to become available on the main net. So if you take as an example that the side chain is being run by parity theory nodes, right, in a PoA network. You could have today wasn't smart contracts being run there. You could use private transactions. Or you could try out Constantinople opcodes that will only become available in half a year in January when Ethereum main net upgrades. There's one note of caution I wanna add here. And that's very important to me. While this is really great for the moment, in the long run, this isn't gonna solve the scaling issue in the whole, right? That's why the slide says mitigating scaling issues and not solving them. Because what that means here is that if you spin up a new side chain, that means you also have to secure that side chain. And as more side chains there are, as more resources you need to secure these individual side chains. And we all believe that that can scale securely. Nonetheless, in the meantime, this is the way to get your application life. So for the side chains, what options do we have? I believe you can choose between three flavors right now. Either you say, hey, I need all the transactions throughput that's available on a new chain for myself, for my own app. In PoA parity theorem you can get up to maybe 500, maybe 1 to 2000 transaction per second. And then you just say, hey, I spin up my own depth specific chain. You get a few befriended projects to run an authority node and thereby secure your chain. Or you say, no, actually, there's this other team and we have applications that interface with each other, that are reliant on each other. And we both make a consortium and we spin up our kind of depth friends of depth chain. Or last but not least, you use an existing bridge, that bridges existing networks. For example, they see a main network with a coven test network. Now, let's take a look how parity bridge actually works. The next few slides will show you a walkthrough from a message being sent from main to site. 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 bridge 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 has a function called confirm message. Now, some app wants to use this bridge. What the DAB does, it deploys 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 DAB. It has some function. And on the right side we have on the side chain, a receiving contract, which is also part of your application. And which has a function accept message. Now, we also have bridge authorities, right? 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 off a transaction with your application. It calls some function and some function again calls relay message. Because they want to send over a message to the other chain. That again kicks off. It triggers an event called relay message. The bridge authorities 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 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, calls whatever the recipient contract is, and calls a function called accept message there. That's a message delivered. And there can be whatever transaction should be kicked off by this interaction can be kicked off by accept message there. So that said, the message relay, the other way around from site to 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 site side. And that means, you know, bridge authorities really want to interact as little as possible with the main blockchain and like gather signatures, gather these confirmations on the site chain. So how can you utilize it as a depth developer? Like what do you have to implement? 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 the data, whatever your message is, as well as address, which is the 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 decodation. Now, I brought you a few examples of what you can do with that. So, for example, you can use it to build an ESC22 as C20 bridge. You lock up, for example, let's take AUGA as an example. You build a contract that allows you to lock up AUGA on REP on the mainnet. That contract sends a message through the bridge to another contract on the side network and says, hey, assign that many AUGA tokens 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 mainnet, you could lock up ether on one side and create wrapped ether on the other side, which is really an ESC20 token that is redeemable for one ether on the mainnetwork. And the last example I brought here, and that's the one I'm most excited about probably in this compilation here, is that you can have an ESC20 token on the mainnetwork lock it up and then give the user, whoever locked it up, native currency on the side network. And that really means you suddenly can have a stablecoin-packed native currency on the side chain. You can have DAI being essentially the currency that you use to pay for gas on your side network. And if you combine that, for example, with fixed gas prices, you suddenly have a situation where those people that run DABs or those people that interact with DABs 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 call block reward 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 that. Now, here are 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 split up their DAB between multiple chains. Now, as always, there are certain caveats with this approach and there are certain caveats with our current implementation that I don't wanna not talk about. So number one, currently all of the bridge authorities, these authorities that relay messages should also be authorities on the side network. So they should be the validators, the 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 side network. And you don't want the authorities to have to pay for all these transactions, right? For both reasons, spam protection, as well as cost. But if the bridge authorities happen to be the POA authorities on the side 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 after all, if you don't trust the authorities on your side network to truthfully maintain integrity of this side chain, right? Then you also wouldn't wanna trust a bridge that relays messages to this chain, right? Another one currently this bridge 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 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 wanna be fairly sure that nothing is being reverted, you wanna wait a few transactions. And that introduces latency that we don't want. That said, if you got two networks that have deterministic finality, there's really no reason to wait longer than once 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're in an alpha phase, right? So further challenges, transactions on mainnet 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 the 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 side network and to utilize the bridge has an intrinsic motivation to pay for these transactions because it obviously increased the value of the network, the overall network and its application. Second, what happens when a relay message kicks off a transaction that actually runs out of gas, right? Like we are facing a more async situation here and that's not trivial at all to mitigate. Another thing that shouldn't be unnoted is that there is still missing tooling for sidechains, right? Even though we finally have a open source blockchain explorer which is absolutely fantastic, right? Which you can spin up for your side network. We still met Miss MetaMask and Infira 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 the app 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 don't want to enable bridge authorities to vote on a new bridge authority set. What I just said, dynamic bridge authority sets. Second, what we really want is that the bridge authorities are tracking whoever is an authority on the side networks and that these set are pretty much identical. Further, we are exploring methods how the side network can be proof of stake and the side chain validators, the validators of that chain actually stays east 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, there is still tooling 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 Wiki, read, contribute, chat 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 it your own app 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 main net doesn't scale? Thank you so much. So I've got another five minutes for questions. I can repeat it to you though. On the roadmap, I noticed you guys had no intention to audit your contracts. Is that something that you're going to do? I can't, 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 will, we will, we haven't actually released arbitrary message passing Bridget. It's already in GitHub, 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 Coven and maybe Rupston, right? Play around with it, invite more people to play around with it. See if it really, you know, fulfills 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. Thank you for the question. Hey, thanks for that, Bjorn, and thanks, it looks really exciting. One question I had was with the Bridge Authorities. Who do you envision those would be? Like what are the incentives for actually securing those relay messages across screens, across chains? Yeah, and how to punish bad actors that might seep in? Right. I can envision multiple scenarios, right? Number one, the most obvious one is the DAB that needs to utilize the chain, right? Being at their own chain or the multiple DABs that wanna spin up their own chain, 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 Ethereum may not cost like what, $150 a month to run a node, 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 costs were negligible, so. The reason I ask is one of the most exciting use cases, which I've thought of with something like Thundercore or something like that, being able to use DAI, say on one side chain and move it over, you know, you can end up if some application becomes really valuable or really of high use, right? These bridge authorities are gonna be presumably taking in DAI and being able to direct it in the main chain, you know, there might be a lot of value moving from one chain to another. That's true, right. And so, obviously there's an incentive, there might be an incentive there, right, for, you know, then to direct DAI to some other contract that's not the intended contract. Right. I can, so, multiple aspects, right? I still think this is only an intermediary solution, as I said, because I think we need to come to a point where we pull security for all these chains, right? This multi-chain future where you have like thousands of chains that all secure themselves, be it in this model, right, where you have EVM 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 think that's feasible in the long run, right? So, 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, hey, either you wait another three years until Shaspers here, or you restart from scratch and try to implement it with layer two solutions such as state channels, right? That said, I'm not quite sure if that... Like, are you asking about the danger of having too much value locked up in a POA chain? Well, it's... Well, maybe not necessarily POA, but for instance, like, you could mint dye on the mainnet. 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 peely pile 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 mainnet. You want to send it back. You want to make sure that that's, you know, destroyed or properly accounted on the mainnet. But maybe it's just not the right use case for this kind of... No, no, no. Okay, I get it. So, you're asking, how can I trust these authorities? Effectively, because they can send the dye, you know, wherever, right? That's always the case, right? Like, it's the same thing as in Ethereum proof-of-work or in any kind of proof-of-stake system. How can I trust that the validators who validate my chain be the chain 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 going to 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 dye over to a chain that I know is rarely being used, where there may be two authorities only that have aligned incentives to actually collude and steal your money, right? Yeah. Thanks for that. Appreciate it. Thank you. Thank you. Hi. 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 authorities do two things, right? When they watch a message coming from main to side, on the side measures, they all have to call a function on the site network, right? And you have a configurable threshold and if you say seven out of 10 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 site network and then the last authorities submits one transaction on the main network that accumulates all these signatures and the contract checks that all the signatures are there. In that way you have like fault tolerance. Okay, is there like on state channels where there's kind of this like the awaiting period after a message has been relayed? Is there something like that so that maybe somebody can bring an attestation saying that actually that's not what happened on the opposing chain? Currently not because really you take these, the set of which authorities as your point of reference if they say, hey, that message was relayed is actually relayed and in order to make sure there's no reorganization, they wait a few confirmation, block confirmations in order 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.