ScalingNOW! Interview 1: Bridge Chains with Björn Wagner & Maximilian Krüger from Parity Technologies

There are a lot of projects focusing on building a scaling solution for Ethereum NOW! Each of these projects has their head down plowing forward with their solution and most don’t have time to communicate their solutions. We are pulling them out of their dark dev caves so that we can all understand our options for launching the DApps ASAP.

Everyone building their DApp is looking for a scaling solution right… well guess what? Parity Technologies has one that works right now! In our first Scaling NOW! interview, Griff Green, Quazia, and RJ from Giveth talk to Björn Wagner & Maximilian Krüger from Parity Technologies to get the deets on their bridge chain solution:

Solution, summary, helpful diagrams, related links, and transcript below.

Solution Summary:

1. The Parity Bridge solution uses a bridge authority process written in Rust as well as two solidity smart contracts to bridge two EVM-based chains. It is optimized for any sets of two chains where (at least) one of the two chains is run by a Proof-of-Authority (PoA) consensus mechanism.
2. The bridge can be used to make mainnet ETH available as an ERC20 token pegged to ETH on a side network.
3. Depositing ETH on mainnet to the bridge contract emits an event. That event is picked up by the bridge authorities, which then call a contract on the side network to confirm the deposit. Once a majority of authorities has confirmed the deposit, the token balance of the users address is increased. Now you can do however many transactions you want on the fast and (nearly) zero tx-fee PoA chain. :)
4. For example: if a user can deposits 2 ETH into a bridge contract on mainnet, the bridge will relay that deposit to the bridged chain, and the smart contract on the side network will give the user 2 ERC20 ETH tokens to play with on this chain.
5. Withdrawing ether decreases the ERC20 ETH token’s total supply on the side network and eventually releases (previously deposited) ether on mainnet. As with the deposit, a majority of authorities has to confirm. Withdrawing is a bit different from depositing insofar that signatures are collected on the side network where transactions are cheap and, once a majority is reached, the bundle of signatures is relayed to mainnet in a single transaction.
6. The last signature providing authority is chosen to execute that final transaction, but any entity can technically execute it since it’s already signed by a majority of authorities.

Solution Efficiency:

One roundtrip of moving ETH/ERC20 ETH tokens to the side network and back costs about as much as 4 regular mainnet transactions. Once the value is on the side network you can do any amount of transactions without spending mainnet ether. The users break after 84,000 gas, and the devs save alot of gas not having to their contracts to mainnet! To put this in perspective, Giveth’s DApp requires ~2 million gas to go from donation to a paid out milestone, and sometimes more.

Solution Issues:

The bridge solution requires DApp users to trust that a majority of the bridge authorities won’t collude to steal their deposited ETH. DApps on the side network are not trust free and therefore slightly less secure than using the mainnet. A majority of bridge authorities can freely transfer mainnet ETH and tokens that were deposited into the bridge. This is necessary for the bridge to function. Employing the bridge is a cost-savings/scaling solution vs security/centralization tradeoff. The larger the set of authorities, the higher the decentralization and the lower the trust one has to put into a single authority. Avoid small sets of authorities (1–3). Using an authority set of size 1 is centralized; you might as well not be using blockchain technology at all!

This solution is best for:

Continuing development and testing in situations where trusting a majority of authorities instead of the entirely trustfree mainnet PoW is acceptable, while waiting for a permanent solution.

Helpful Diagrams:

Deposit (from Parity Bridge github)

Withdraw (from Parity Bridge github)

ScalingNOW! IRL Gatherings:

Web3 Foundation and Giveth are working together to create an in-person gathering on March 5 & 6 of the top devs working on scaling solutions, as well as the DApp developers that rely on these solutions. Day 1 will be invite-only for select devs working on immediate scaling solutions to share their insights amongst one another. Day 2 will be open to DApp developers who submit a (super quick and easy) application on what they are building. We encourage all interested DApp devs to apply here.

The insights and momentum gathered from this small gathering will feed into a larger public conference on Scaling initiatives that the Web3 Foundation will organize. The initial details of this conference are still being determined but will likely take place in Berlin in late 2018. For more details, follow Web3 on Twitter, join the Web3 Riot channel, and join the ScalingNOW! channel.

Do you want to support ScalingNOW!?

We are funding the ScalingNOW! interviews and subsequent Barcelona gathering transparently on the Giveth Platform. If you want to support the cause, send some ETH or Token love to 0x9cb8921aa376219950ba134c15d8f5ee2769c599. 

Donations received will cover the costs. Any leftover funds will be split between the Web3 Foundation and Giveth.

Related links:

Parity bridge on github

Parity bridge discussion on gitter

Igor and Roman from PoA Network Talk with Giveth about their Implementation of the Parity Bridge

Max’s github

Parity PoA Chains on github

ScalingNOW! chat on Riot

ScalingNOW! YouTube playlist

Giveth

Interview transcript:

Griff: You guys are working on Polkadot and probably other long-term scaling solutions. The purpose of this interview is really to take a deep dive just into the bridge, because we’re focusing on DApps that need scaling solutions right now. The audience is a very high level technical audience, competent devs who are working on an Ethereum DApp right now, who are already noticing that their scaling issues are real and it’s not going to work on the mainnet so they’re looking at side chains.

Griff: Bridge chains may not be side chains. Can you guys explain that?

Björn: I think the concept of side chains is pretty well known from the Bitcoin space, where we’ve heard of things like merge mining and so forth. When we talk about bridging, or bridging chains, at least we in Parity, we assume that there are two chains that can live by themselves. So each chain provides their own means to come to consensus and maintains their own integrity. So let’s assume one chain is the Ethereum Foundation proof-of-work mainnet, and let’s say there’s a PoA network that is a proof of authority network, for example Kovan. In Kovan we don’t have a proof of work, but rather we have a set of validators, we call them authorities, that are identities at stake, so to say. They are well-known startups, DApp developers, and so forth. And they say, “We provide a validation process. We provide a means to maintain integrity of the network.” But generally speaking, these two networks can live on their own. And now when we talk about the bridge, we just provide another piece of the puzzle that allows bridging from one chain to another.

Griff: How does this bridge work? My understanding is that you have a smart contract on both sides and a group of authorities are acting as relays that interact with both contracts on two separate chains?

Max: What the bridge in its current form does is implement an ERC20 token on one chain, which is backed by ether on the other chain. It’s two smart contracts with relay processes, and those relay processes might be the authorities of the PoA chain on one side, but they don’t have to be. You could deposit ether on the home chain and then the bridge authorities will pick up this deposit and relay it to the other chain and make it available there as a token, and the other way around. And on the foreign chain, you can basically use it as any ERC20 token.

Björn: To simplify that, we designed the bridge initially based on two assumptions: First, the home network, so one of these two networks that we want to bridge is a network where the transaction fees are quite high, for example for the Ethereum main network: proof of work. And the other network, we have a network where transactions are almost free, or considerably lower than on the one network.So to walk you through that, let’s assume I’m the Ethereum main network and Max is the Kovan network. So on my network, the Ethereum main network, there’s a contract that looks a bit like a multi-sig but not like the multi-sigs we have out there. And this contract just accepts ether, the native currency of this chain. Now we have a bridge software and this bridge software is a piece of rust code, and his piece of rust code can connect to two Parity nodes. One of these parity nodes runs a full node of my chain, the Ethereum main network. The other Parity node runs a full node of Max’s chain. And the rust code, or the bridge code, listens to both chains through these Parity nodes and watches contracts on each side. And if you look in our documentation, what we call the “home” is always the high transaction fee network, the Ethereum network. And the foreign one is Kovan, for example.So let’s say someone sends Ether on the home chain, to the Ethereum main network. Then these people who run the bridge, they see the transaction, acknowledge it through their bridge software, and sign the message saying there’s ether coming from that address. And all the authorities that run the bridge software — that can be however many authorities you want, it could be one but it could also be ten — they do the same thing. They see the transaction, they say “Oh, I’ve seen it.” They wait maybe ten blocks, we assume that finality has been reached even though it’s probabilistic finality, and then the same amount of tokens is minted on Max’s chain, in his contract. So he has an ERC20 contract, an ERC20 token, where the total supply represents however many ether are on my chain in this contract.

Max: The main application that becomes possible through this is on the foreign chain, my chain, I can do transactions essentially for free because I can get ether from a faucet. So I can use this for scaling. Rather than having all the transactions on the mainnet, where they’re fairly expensive, I can just deposit the ether into the bridge and then do whatever, however many transactions, also with faster confirmation times, and then I can withdraw it at any point. The trust slightly changes — I no longer trust the very proven Ethereum proof of work mainnet. I now have to trust a supermajority of the authorities of the bridge or PoA network. But then I have a lot of scalability on this side. A deposit and a withdrawal costs about the cost of four transactions on mainnet that just move ether around. After those costs I basically break even.

Björn: I’m always careful about calling that a solution for scalability because the after all, all we want is a permissionless public blockchain where this stuff can be run on. But there are a lot of DApps out there who have been working hard for a long time and they are in a state where they could deploy their smart contract on the mainnet theoretically, but they couldn’t run it because it’s just too expensive or the network is clogged. So I think it’s fair to say that this could be a temporary mitigation solution for these developers to test out their applications in the same environment. After all, the state machine on Kovan, on the PoAnetwork, on Ethereum network is the same thing. So you can test the smart contract as you want. Once we get to a point where the Ethereum network actually scales, we can transition to that.

Quazia: The case you went over is mainly the deposit process. Can you go over your withdrawal process and the gas influences that led to that decision and how you engineered it?

Max: The bridge is asymmetrical because we assume that one net has much much higher transaction costs than the other one. The deposit case is very simple, all the authorities make a call into the smart contract on the cheap PoA network where their gas costs are 0 if they are the PoA authorities, or very little if they are the bridge authorities. And we just collect their calls and once a supermajority is reached, we give the recipient the tokens. The other way is more involved because we cannot do the same thing on the mainnet because it would require n, where n is the majority, transactions on mainnet, which is pretty expensive, so what we do is the bridges call back into the foreign chain, in my case the PoA network, to collect signatures together there and they sort of get bundled together. Then the last signature-providing authority is chosen to be the authority to do the relay. The relay is one single transaction on the main network, which sends all the signatures, as well as the data required to do the relay, and then that’s accepted on the home bridge. So basically it’s just an optimization to save transaction costs on the mainnet. Which makes the withdrawal a little more involved.

Griff: So the signatures are made from keys on the bridge or the foreign net?

Max: For this to be really secure, those are the same. But you could have different.

Griff: Let’s assume they’re the same. So you’re aggregating the signatures, they should be the same on the bridge contract on mainnet, the bridge contract on foreign net, and the relay, the keys on those are the same. So basically you could see it as a multi-sig and you’re just aggregating signatures over here where it’s cheaper than on the mainnet.

Björn: For the trust model involving bridge authorities, we can specify if it should be a supermajority, majority, if all the authorities need to provide signature for relay in either direction. We can specify that in the contract before the bridge is deployed or mid-contract. You could potentially make that upgradeable with some kind of governance model, like if the majority of the authorities vote to reduce the threshold. Even though we did the optimization to have the n authority or to actually make the withdrawal transaction on the Ethereum main network, it can be anyone who submits that. So if this authority goes rogue, then either the next authority does it, or we can allow any user to submit it.

Max: We tried to keep the bridge robust, so that nothing can ever get stuck completely.

Quazia: In your design, I saw at least a couple places where you were acknowledge and provide specific solutions for attack vectors. Can you go into those and your solutions?

Max: We had an attack vector where the addresses on the mainnet for the bridge authorities had to pay for the relay costs. One could potentially provide them with an initial balance and let them do their relays. But this opened an attack vector where one could deposit a very small amount of ether into home, have it as token on the other side, and then just make one wei transfers back. And every time the authority would try to do the final withdrawal call on the home side, they would spend significantly more ether to do the relay. So by depositing a very small amount of ether, I could exhaust an authority’s balance on mainnet. So we solved that by having the recipient pay for the relay gas costs by basically subtracting that from the value that’s getting paid out on home and giving it back to the sender which is the authority or anyone else who does the withdrawal call.

Björn: So it was mainly about, the bridge authorities when they submit a transaction to the contract on the mainnet and give out the ether to the user, they have to pay for gas. So someone could exploit that by withdrawing 0.001 ETH, then the authority has to pay for gas every time again, so at some point the bridge authority has no ether anymore. We mitigated that by subtracting the cost of the relay from the value that’s being relayed.

Max: We based this on the assumption that the PoA authorities are the bridge chain authorities so they could do free transactions anyway. But if they weren’t that wouldn’t be a big deal anyway since topping up a faucet on a PoA network is much easier, the real issue is when there’s real ether involved. And there’s really only one transaction where there’s real ether costs and we had to modify it to close this attack vector.

Björn: We found another attack vector that could be interesting for smart contract developers. We like the system to not have to rely on any single bridge authority to submit the final transaction with the gathered signatures and actually relay the withdrawal. And also allow people beyond the bridge authority, for example the user with the ether deposited. Before we said that whoever submits the final transaction pays for the gas costs. But imagine that Max was going to withdraw, sign and hand in the withdrawal transaction, but put a gas cost of 100k GWEI. Then the whole transaction value would be drained, I wouldn’t get any money, but he would have lost all his money. So that is kind of interesting.

Max: There’s a fairly easy fix for that that improves other things as well. We need more people interested in the project to polish it and find all those remaining issues.

Griff: Dtense asks, “Anyone depositing ether into the bridge is trusting the authorities — the authorities can steal the ether, right?”

Björn: One one side you have the PoA authorities, the authorities that maintain integrity of the bridge chain. And you have the bridge authorities. They can be the same, but they don’t have to be the same. Because your ether always remains on the mainnet, you really only trust your bridge authorities with that ether. So let’s assume we’ve got this system running, and the PoA token go wherever, on the mainnet they stay in this contract. The ones who can unlock it and send it off are only the bridge authorities together. So like even if the PoA authorities were completely compromised or the chain was completely shut down, the ether wouldn’t be lost. They could still be sent off. So that’s now the question of the trust model. So if for example, you guys, Giveth, Status, Aragon. And you want to connect your DApps and live on the same chain. So you could use Kovan as it is with authorities as they are. You could deploy the bridge, we could have a testing deployment with these teams or just two of them, so you wouldn’t have to trust any of the PoA authorities by managing the bridge. But anyone who uses the bridge has to trust the bridge authorities. So in most cases it makes most sense to have them be the same set, and have the bridge track the validator set of the PoA network, but it doesn’t have to be like that.

Griff: It could be that there’s this one sub network like Kovan, and maybe Aragon and Status and Giveth want to do a bridge, but maybe some other Melonport and DigixDAO and some other Kovan guys want to do a separate bridge. So there could be multiple bridges.

Max: Whatever you chose as the majority of the bridge authorities can ALWAYS withdraw all the ether deposited on the home side. I think the security model is much more sound if the bridge authorities are the PoA authorities, but you can do otherwise.

Björn: Well as many as possible, right? For example, if it’s just you guys, then everyone has to trust you that you won’t run off with the eth. But if we have like 10 teams as the bridge authority, it’s better for each team, kind of.

Griff: (Question on the number and costs of mainnet transactions.)

Max: There’s two transactions on the mainnet. The withdrawal costs 3x the deposit.

Björn: The deposit is about the same as a regular transaction on the mainnet. So when you have any kind of DApp with a user for each input of eth that’s four transactions or more, it’s already better than running it on the mainnet.

Griff: So there’s one transaction that shoots off an event, and that’s the extra cost I assume? Then magic happens on the bridge chain, and then the withdrawal transaction has a lot of extra data, and that costs about 3x a regular transaction. And that’s it. That’s all the gas you have to pay for on the mainnet.

Björn: Yes

RJ: What about a batching of withdrawal transactions?

Max: We could look into that if that becomes an issue.

Björn: Well you guys, Giveth, just created a multi-sig contract. Obviously you could use that for it and then the authority would batch it. Sounds sensible if it’s secure.

Griff: Let me give credit where credit is due. Aleksii from Kiev, Quazia, and Alon, they’re all contributors to Giveth to an extent, Aleksii’s a famous white hat in my mind. And they created a multisend that we did a trustless deploy where it’s the same address on Ropsten and on mainnet so you can test it on Ropsten and make sure it works and then deploy it on mainnet with the exact same transaction. It’s trustless in that it’s open, it’s not a private contract, so you guys could actually make that send without doing anything, you could just use that contract. It’s still being tested though.

Griff: So let’s talk about that chain that’s being bridged to. PoA vs. POS, do you have ideas where people could use a POS chain instead of a PoA chain? What are the requirements there?

Björn: So those that are familiar with how the Parity client is built, we have something that we call pluggable consensus, where you can switch the consensus engine. That’s why you can use the Parity client for the Ethereum main network, but also for Kovan, or your private PoA network. The nice thing about ours and how we implemented it is, is that you can have the validator set, so this piece of information that says who are the validators who maintain integrity of the system, is contract-based, and you can have arbitrary rules that say how this validator set should be updated from block to block, from epoch to epoch. So that means currently we only have PoA, and we could have a governance rule, majority vote if the current Kovan authorities vote and say this guy should be onboarded, he could be onboarded. But that also means you can implement POS in that. Because you could have whoever holds that much eth is an authority in the next round. And fundamentally the bridge doesn’t care about that. This is the next step from where we are right now. Right now with the bridge, when you deploy it — when you deploy the contract on the mainnet and the PoA net, you specify which address is an authority for the bridge, but we want to change it to probably two steps:

1. We want to add some kind of majority vote so that this set of authorities can add an authority or remove an authority.
2. It just relies on the contract of the consensus engine. Whoever are the PoA authorities, the bridge authorities are the same, which would make it a lot easier later. So if you say, “Hey, you guys have your own PoA chain,” for Kovan and stuff like that, if a new authority is onboarded for the PoA chain, it’s automatically an authority for the bridge. We could look at implementing a POS based on that.

Griff: Question from Detense — will Parity support dual chain mode plus bridge running one process instead of three?

Max: Probably not. Parity’s a specific thing, the bridge is another specific thing, merging them together doesn’t make sense.

Björn: It’s a question of what are the benefits. I had David, our devops guy, look into how much that would cost in terms of infrastructure to be an authority. He said it might be $10 — $100/month to run on one VM these two parity nodes across a bridge.

Griff: So the bridge is just a process, you’re just running this process, and you’re running two nodes all on the same VM, and that’s what it takes to do this, that’s it.

Max and Björn: Yup.

Griff: So for Giveth, what do we need to be considering for this?

Björn: Let’s consider multiple parts. One interesting conversation is where is the bridge and the contracts right now as it stands? Where can it go? What does it mean in terms of extensibility? You guys, where are you — testing, production, etc? Max and I had a look at your Tackling Scalability article.

Max: For you it could be very useful to remove this element of centralization from this entire approach, where you have a bridging of value and then on the PoA chain you have a lot of transactions and you’re saving a lot of gas, but you’re still backed by ether on the main chain through a mechanism where people don’t need to trust you exclusively, but they can trust, for example, the Kovan authorities, or another bridge authority set. So it’s more of a trust-less bridge chain.

Griff: So if a DApp team is thinking, “Hey, we want to start testing,” why should they choose a bridge chain over a centralized thing. You’d say, “Because it’s a little less centralized.” What other considerations would they have? Would they need to adapt their DApp to work on the PoA network?

Björn: Right now, as it stands, when I’m a user on Ethereum network, I send a transaction to the bridge, the key I use to send the transaction is the same key that owns the ERC20 tokens on the PoA network. So that requires the user to be active on the test network afterwards because he owns the same tokens. So currently the bridge could be deployed per DApp. A DApp developer could say, “I’m the bridge authority. I only deploy that for my DApp. So whatever tokens I use on the foreign side are only usable for my DApp.” And they could probably modify that to be their contract already.

Max: Right now we can only map ether to one ERC20 token. What we are aiming for is a much more generalized solution, which will probably be based on an ERC777 token and this ITokenRecipient ERC820 registry where people can deposit ether on the main network and then it will be deposited in the foreign bridge. The foreign bridge would then deposit it automatically in a user-defined token that is just an ITokenRecipient. So those users could deploy their own token with their own business logic on foreign, and this would enable a lot more use cases and reuse of the bridge without having to modify the bridge itself. So this is something we’re aiming for, to build more like an infrastructure that people could deploy and then hook into their own things. With this ERC777 solution, we could have multiple DApps without having to set up multiple bridges.

Björn: You can already use the same bridge, but the fundamental difference is that, for example the DApp on the main network, when it says “hey send ether to this contact” could already tell that this transaction contains some data, as is possible in ERC777. And in this data piece, it could say, “Actually, the user doesn’t want to just hold all these tokens on the PoA network, I want to go straight ahead to the Giveth application.” So you could already insert other actions in this message passing. And that’s why it would become way more general. But even in the current state with the ERC20 solution on the bridge chain side, every DApp could use it.

Griff: People would just need to make sure their DApp is playing this game. At least what we use for this solution is the donate through MyEtherWallet, it’s not necessarily a DApp button, it’s just data injected so that someone can click donate, they get sent to MEW with all the information for the send preloaded, and then they load their key, then when they go to the DApp they’re still on the testnet or whatever network we use, and all the other buttons are doing the normal thing. So they could probably do a solution like that too with the current setup right now. And it would work.So let’s walk through what it would be like for Giveth to adopt this solution. So we have our DApp. Right now we’re already rewriting it so that it accepts tokens instead of ether, which is step one.

Max: With the bridge, what you could do is have the user donate on home and then have it automatically get relayed or have it trigger one of your contracts which does something on the bridge contract, so have this donation automatically reach some token contract on the foreign chain.

Griff: So we could modify the smart contract on the foreign chain so that it, instead of the ERC20 token is given to the user, we could add some functions in there.

Björn: The fundamental question is do you want to have the user interact with the foreign chain at all.

Griff: Yeah we do.

Björn: So I don’t see any issue with using the bridge chain as-is. Right now you can have the user click a button, the ether is deposited on the other chain, it has an ERC20 token and then you have the user be on the test net and click another button and say, “Now you donate to Giveth.”

Griff: For our use case, it’s nice to give them the option. Like let’s say someone donates to a general charity to animals. They’re assigned a delegate who has authority over their funds. They always donate to something specific, like animals, to kangaroos, to a specific kangaroo charity or a specific kangaroo charity’s milestone. Depending on that they’d get different delegates. Then we’d send an email out when the animal charity does something to lock up those funds, the original giver will lose authority of their funds after that, so we send them an email, “If you don’t click a button, your charity will get your donation.” We want people to interact but we want it to be easy, to click a button and be done.

Björn: Either you modify the contract on the foreign side so it’s very specific for Giveth. So instead of the user receiving it on the other side, it goes straight to you. Then you take the bridge as it is, you’re the only authority, it’s all you on the other side. Or we work together to extend the contract on the foreign side, the ERC777, and solve it for everyone, and make it general. And in my opinion that’s a way better approach in the long run. There’s so much you can do on the test net, the better scalability of 1k transactions/second, you can have the interaction with all these different apps, you can share the responsibility of bridge authority and use the same thing. I like this approach more, but you can also just change the foreign side, make it very specific to your application, and just run the bridge by your own. You don’t need to change any line of rust code.

RJ: I think ERC777 is definitely the better way to go.

Quazia: I have a ERC777 wrapper done, so from here it should be trivial.

Griff: What else do DApp teams need to consider to implement this?

Björn: There’s a few things. We’ve been developing the bridge for quite a while. The first release was in October. We actually only did testing requirements internally but never deployed it between two running networks. Credit and kudos to POA Network, cool guys who’ve done a shit ton of really cool stuff, they’ve been testing it for some kind of demo for a crowd sale. They’re currently extending it for their scenario with a slightly different use case. They modified the bridge code, the smart contract code. Learn more in the interview with Igor.

Björn: We would like to deploy it as a test for us. We are fairly confident that it works, but it should be tested well first and audited. The bridge code, the rust code, as well as the contract. It would be awesome if that could be a community effort to test and audit it. So we are thinking of doing some sort of testing deployment maybe next week. It could be any proof of authority network but we’ll probably use Kovan just because it’s there, why not, and the Ethereum mainnet. In order to protect against a vulnerability, we are thinking of some sort of limitations. Like the user can’t deposit more than 5 ETH. And the bridge can’t hold more than 50 ETH in the beginning. So just to make sure we don’t have a major fuck-up. I think it would be awesome to get a few teams together who want to use the bridge and just test it.

Griff: Is the PoA Network the only people who are pushing and using it today?

Björn: I know that Melonport is keen on it but I’m not sure if they’ve deployed it. I talked to one other guy who had deployed it. But I don’t know if anyone is using it in production.

Griff: One of the big issues with using a PoA network as opposed to Kovan is there’s no block explorer that shows internal transactions. Do you know of any groups who are working on that or any way to mitigate that? Is there a way to see ERC20 token transfers?

Björn: I haven’t seen any open source block explorer that comes anywhere near the functionality that Etherscan offers. Unfortunately, we’re all aware of that problem. We’ve been working internally on some sort of DApp you can use, but I wouldn’t even propose that. Obviously we need a really good solution. Igor’s been interested in working on that, we’ve been talking to him because we’re interested in collaborating to some extent. I think it would be great to have an open source solution. But for Kovan at least Matt is providing the service for it.

Griff: Matt is a hero.

Björn: I don’t know of any good open source block explorer currently. But the Etherchain Light explorer has really helped me in a lot of projects, so I’m really thankful for that, but it lacks functionality.

Griff: Another one is Ethplorer. I’m in Thailand right now and so are the Everex guys who make Ethplorer. At least that works for ERC20 tokens, I wonder if they’d be interested in deploying that. Because you really just need token explorers.

Griff: Question from audience: Why not use ETC as a sidechain?

Björn: High transaction fees, it doesn’t scale. Not nearly as scalable as a PoA chain.

Griff: It also doesn’t have a block explorer.

Audience question: Authorities should always get back what they spent in gas.

Max: Assuming that the PoA authorities are the bridge authorities, this is working like that. We will have to do slight adjustments if the bridge is supporting other setups. The recipient will pay for gas or something like that.

Björn: It’s almost trivial at this point. If I’m a PoA authority and I mine blocks and I’m a bridge authority and I just put the transactions for free. If the bridge authority is not the PoA authority, in the Parity client we have an option where you list addresses that don’t have to pay for transactions. So you could just say, “That bridge is awesome,” you just add them to that list.

Audience question: Bridge authorities should need to update their commitment regularly so if people die eventually people would be able to withdraw their valuables.

Max: With the fixed authority set that we have at the moment, that’s kind of the problem because if there’s no longer a majority then the funds are basically frozen. Until then we should have some sort of escape hatch for those cases. But eventually we’ll have a dynamic validator set. So the ideal setup in my mind is having the bridge authorities be the PoA authorities and have dynamic validator sets on the PoA which we’ll roll out on Kovan in a couple of months, and have the bridge track all that which will solve all those problems.

Björn: It’s the same with any multi-sig wallets. You need to make sure you have that key safe or else you have a major problem. But I think the mitigation for this is to have many authorities on the bridge and have a reasonable threshold, such as 60%, 70%, where we’re pretty sure if we have 20 teams on it that 10 teams aren’t going to collude to steal all the ether. I actually don’t think that’s an issue with POW networks where there’s 5 big miners, where on the bridge we have 20 teams with reputations at risk. I think it’s not too hard to find a solution for that.

Griff: I like the escape hatch idea, there should always be an escape hatch. Put it in at the start and when you trust things you can zero it out.

Max: We’re testing, we need an audit, we need way more tests, until then we need escape hatches.

(Audience question that wasn’t understood)

Max: Just file an issue on the repository.

Björn: There’s two places to get more information. Our Parity Tech githuband Parity bridge github, and you can also reach us at our Gitter room. And if you’re interested, let’s all talk together and figure out what would be the best approach to that. This is a community project, so whoever’s interested, please join us.

Griff: On March 6, we’d love to do a ScalingNOW! gathering an invite-only for devs working on scaling solutions. Hopefully you guys can come to that.

Björn: We just want to get it deployed to start testing in a live network. We can either do that next week on our own or modify the contract a bit further, for example ERC777, and when we do that we could deploy together. With Kovan, you have the Kovan authorities be the same as the bridge authorities.Testing could start now. I think the whole upgradable authorities, a couple of months.

Griff: That’s perfect.

Audience: Is the ERC777 wrapper public and open source?

Quazia: No but as soon as it works it will be. It’s for Aragon. It’s going to be in the repository, I’ll pull it out and make it into its own thing. All their code is public. (Quazia will post the wrapper on his github when it’s done.)

Griff: On March 6 for the ScalingNOW! gathering, at midnight we want to do a launch party for ERC777.

Griff: Thanks a lot guys! This was a lot of fun.

Björn: We just want to see it be used.

See the next ScalingNOW! interview here. It’s Igor and Roman from PoA Network. They’ve actually implemented the rust code for the bridge and done some customizations.

Learn more about Giveth and the Giveth Future of Giving DApp.