Max: The Parity bridge is an ongoing research solution to connect Polkadot later. You can use it to connect a POA network to a DApp temporarily. Our roadmap is to have an ERC20 to Ethereum bridge, just tested it to Ropstein to Kovan, going to create a demo video. Going to move away from this arbitrary ether restriction to arbitrary message passing, because it requires fairly small modifications to the code. Aim to have something in 2 months.

1. Roadmap: Now! ERC20.

2. Security: Requires more trust than other solutions — have to trust the majority of validators. If they are compromised, the bridge is compromised. If you already use a POA network and are fine with them, it’s really transparent when they screw something up. It’s easy to call people out. If you already trust that, the bridge uses the same security model.

Disruption — doesn’t depend on any aliveness. Once everything’s normalized, you can continue running the bridge.

Finality curve — POA networks have definite finality after a while.

3. Scope of apps: Any DApp pretty much without modification. Can deploy a DApp on Kovan, POA, and try it out, test it out, and iterate it and use exactly the same DApp on the mainnet

4. Throughput: This is limited by the slowest chain, which will usually be mainnet. The bridge processes themselves have no problem handling the relay. On the POA side, on the sidechain, you could have a much higher throughput, you could run on much higher throughput than mainnet.

Simple example to use a bridge on a POA network: Giveth for example do some kind of manual bridge, run DApp on a sidechain because they are limited by transaction costs but still want to have their sidechain backed by things that exist on the mainnet. And they do they a manual relay.

As long as the bridge exists, you don’t always have to use it. Those solutions complement each other.

If you do a message passing from main to side, use the bridge to back things on the sidechain in a way that is not centralized, but instead the trust is distributed to the authorities running the sidechain. Most of the transactions are running on the sidechain.

6. Bottlenecks: The slowest part is the mainnet. You could get some additional speedup by having a lower amount of consensus on proof of authority chain. Compared to sharding or things like that, there’s no curve that keeps going up.

7. Cost: 200k gas to deposit and withdrawal (100k each). This assumes free transactions on the sidechain. Calling a function on the mainnet, that costs gas. All the transactions done by the authorities are basically free, the other way around, we collect signatures on the side chain, then there needs to be one final transaction that contains all the transactions. This definitely requires more trust, but the solution is fairly simple. We can make it fairly secure pretty fast, it will stay a pretty simple and elegant solution if you’re okay with using a POA network.

8. Upgradability: Ideally you would deploy the bridge once and then do the message passing. It’s more extendable also, we want to do ERC20 talk through the bridge. Can come along and apply to other contracts. Future awareness, eventually the goal is, something to keep in mind is it will connect Ethereum to Polkadot.

Regarding the requirement of proof of stake validators, we can move over to proof of stake, making it possible for those chains to start relying on an external consensus model like the Polkadot network.

There’s also an upgrade path for having these chains become Plasma chains. Then they can have the same consensus, you have the same cost and you just guarantee additional users. It doesn’t change much over having a normal DApp, just the Solidity costs.

9. Dev Experience: Some security design considerations. There’s some initial setup involved setting up the DApps. There’s a mapping between addresses that the bridge maintains automatically, as in “deploy a contract over here and here”. If you just accept arbitrary messages, this is an additional security design consideration you need to take into account.

10. User experience: Users don’t necessarily need to be aware that the bridge exists, except for latencies. They interact with normal contracts. There is latency, and there is some transparency issue we need to resolve where when the bridge is down for some reason, a transaction will seem stuck, so it would be good to have Etherscan for the bridge, so we could see very transparently where the relay actually is. Other than that, users have to use two networks. Ideally only when they use the bridge and move stuff over.

11. Dependencies: The mainnet, POA network needs to be running, the bridge authorities need to have the bridge nodes running.

12. Supporting services: Everything like Metamask and Mycrypto and Parity where you can select networks, you should be able to run both contracts through them. You’re just interacting with smart contracts, no additional protocols that need to be implemented. If you’re using a small, exotic chain that Metamask or Mycrypto don’t support, you’ll have to supply your own tooling. In a user flow, the user will have to change Metamask between networks. The DApp would need to say something.

Pain points: If you have different sets of authorities or manage changes, it already works. If you have authorities on a contract on one chain, want the bridge to work with that, it’s not impossible but it’s another project which is an ongoing solvable problem.

There’s an open issue with authorities collecting signatures on sidechains: the authorities cannot really do that because you could spam messages over to them and this would exhaust the authorities gas. It’s still an open, ongoing issue to build some sort of reward system or bounty market where you incentivize users to do transactions there. That could be solved by DApps, our bridge contract only passes certain messages over, then it would seem seamless, then it would say, we have implemented a reward system, we will pay out the relayer in the end, in tokens or ether. Developers can write some security measure to prevent a spam attack.

Parity Technologies’ Day 2 Parity Bridge Presentation

Björn’s Day 2 Presentation on Parity Technology’s Parity Bridge

Björn: We initiated this in light of Polkadot network. Polkadot will have its own consensus engine to trustlessly talk to another blockchain, such as the parent chain in Parity. Since summer it’s been roughly useable.

We’ve seen DApps who have been working on it for two years, two problems are prohibiting them from deploying it:

Network clogging, transactions don’t go through High gas price

If I hear from Colony that it would cost them $3 to create a task, that’s not viable. Same with Giveth who want to do something really great, a huge cut of every donation goes to gas costs, that’s not really cool, they can’t launch it. Parity Bridge is basically a software that is implemented in Rust, and can implement contracts.

Implement two nodes, each connects to one chain. Let’s say Ethereum network and Kovan. Relay arbitrary messages from one chain to another. So an app could say, this app should do this and transfer tokens to this other chain.

It allows the user to deposit ether on one chain into a contract and the bridge system relays the ether, they wrap them to an ERC20 token to the other chain, for example Kovan. So the other chain can do with it whatever it wants to with the pet token. And it can do that all for free, do all the calculations. What you get is 10–100x in transaction throughput.

So how could a DApp use that right now, a team that is right now in contract work, want to test it with real users, how do they need to change their DApp to roll out? We think it’s sensible for these projects to run their own POA chain with whatever or they use network like Kovan where they know the members, they will maintain integrity of the chain, or do something in between where Kovan and Rinkeby are just too much testnet for me, I’m not confident enough because what if some of these test nets test Casper right now? What you could do, Giveth comes together with Web3, Colony, spit up a new POA chain, we all have the same problem, we know this is not the long-term solution, we want to move over to mainnet but it would be fine to maintain integrity to the other chain, use the bridge for that. I don’t want to get into technicalities too much, but move over to a Q&A, I will do more technical in-depth talk at ETHcc.

Question: If a lot of people were using these POA chains, would there be some sort of denial of service attack? A lot of requests, fetches are coming though. The projects that are maintaining this poa chain will have to maintain some sort of infrastructure.

Björn: Mainly I think there are several critical paths. Metamask supports Rinkeby and Kovan.

These are already on Kovan and fewer on Metamask and Etherscan. If we as a community say hey we need that to improve, onboard Infura and Etherscan. A blockchain is absolutely very crucial, POA Network is working on an open source block explorer.

Question: (missed the question)

Björn: Slockit has been involved in testing the limits, there have been ongoing improvements, but 10x -100x should be possible, even on the throughput, it helps mitigate the problem at least for sometime.

Question: So that would be enough for Cryptokitties?

Björn: Probably right. It’s not going to be the solution we’re all looking for, but it’s probably the best we can do in a non-centralized way. POA network triggers doesn’t feel right but if we have 20 authorities running the bridge and the chain, the very DApp creators that users trust anyway because they use the DApps, I think it may be a sensible plan. There are two parties who run Rinkeby. If there are no other option, what do you do?

In order to figure out how many transactions, divide by 25k gas usage, divide by more time, which is say 5 seconds, so the maximum transaction per second would be 76 transactions. you can pump up the gas limit if you want a higher throughput.

Aragon has trouble deploying their contracts because the gas limit was just too low, obviously everything would not be mainnet compatible if the gas floor was 5 million on the mainnet and we deploy something that needs 8 million.

Jeff: This is one option: if you have an app that can’t deploy because of the gas costs, you could fix your app. Next question is in terms of relative risk, what do you think the relative risk is of main chain versus side chain?

Björn: The question is to personally estimate the mainnet proof of work chain compared to a POA chain. In order to estimate properly, you have to look chain by chain specifically. We could have the POA authorities stake real mainnet ether, we can implement that. This is incredibly difficult to answer, I really don’t know but especially in this phase of Ethereum it would be fair to say that to do this approach with parties that are trusted in the community, it would be good to implement with a stake in the main net.

Jeff: I bet at 10 to 1 that there will be a compromise of some valuable stake on a POA chain before the main chain.

Roman: So let’s create a smart contract into that, we can bet.

Björn: We don’t think this should be the thing in two years, we actively work on everything else, we just want to provide a temporary solution for a bridge for someone stuck in development right now.

Arthur Falls: If you’re using the POA chain, your assessment of that risk is completely different than if you’re trusting the main chain.

Question: Do you have an ice age for this thing? If you create something for totally free, people will completely using it even after we have better decentralized option, no one will have an incentive to move away.

Björn: I think we’re pretty aligned with where we want to go eventually.

Björn: The solution is not that we stop doing what we do, we keep working on what were working on state channels will take a year at least before a dev can really build it.

Jeff: They have state channels live right here (referring to FunFair).

Björn: Whatever you build as a smart contract builder, you have to change very little to use it and test everything. you have to reimplement if you switch to state channels.

Jeff: Not for Raiden.

Arthur Falls: It sounds like were talking about very similar parameters to the mainnet but extend to a POA network.

Björn: It doesn’t have to be POA network. In Parity you can build your logic in the smart contract. So yes, all kinds of modifications are possible; you could pump up the gas limit and then you could do crazier stuff.

Björn: This is already the first version with a wrapped token. Already deployed between Ropsten and Kovan, you can check it out on Etherscan, there’s a user guide and everything.

Max: Does anyone have a personal estimate on how expensive it is to compromise the main network?

Jeff: $27m USD (as of March 6, 2018). That’s the cost to reverse a transaction. But you can bribe a mining pool for less.