Simple Side-chaining for Graphene-based Blockchains (BitShares/PeerPlays/Steem)
In crypto currencies and blockchain technologies Sidechains are considered the holy grail to form a super network based on multiple cryptocurrency networks and their user base. Side-chains are often referred to as two-way peggs because they (at least on particular kind of side chains) allows to move tokens from one network into another network. This article tries to show how this could be done with the technology already existing in Graphene, today. This means that the following can be applied to BitShares, PeerPlays, MUSE, Steem among other (possible non-public) graphene-based blockchains.
Let's take the PeerPlays use-case as an example here. We have two graphene-based blockchains (BitShares and PeerPlays) and we want to move the PEERPLAYS asset from one chain to the other and vise versa.
Even if you had a third party that offered to exchange tokens among different blockchain, we do not want to trust a central entity like an exchange or gateway to do this for us.
On the other hand, because the block producers of both chains don't know about each other, you can't communicate with the other chain directly. Unless you convince the block producers to integrate every potential side chain into their servers (which won't scale by the way), it seems that you can't easily move your tokens over trustlessly.
Fortunately, there is something in between fully trustless (i.e. fully automated) and using a centralized entity (i.e. exchange, gateway) and that is a group of people that collectively and provably perform the handover of tokens from one blockchain into the other.
All we need is a group that acts on both blockchains and jointly control transactions from the group account. A user that wants to move funds to the other chain sends the asset to the group with a memo that identifies the recipient on the other blockchain.
After confirmations, the group uses their blockchain account on the target blockchain to send out the asset to the recipient. Since sending out assets (or issuing new shares) from the group's account requires all (or a fraction) of their members to approve, we can use the proposal system and simply use threshold-signatures. Only if the required amount of group members has approved the transaction, the funds will actually move the groups account. Of course the group only approves, if the corresponding funds have been deposited properly on the original chain.
Improvement Proposal 1
The group could be a fixed set of members that are defined by someone, or the members of that group
- are voted for by shareholders of some token
- are the biggest stake holders of a profit sharing SIDE-chain asset
- or a combination of the above (fixed set of users + votes set of users + set of top holders -- with equal or non-equal weights)
Of course, we can also distinguish owner and active permissions to hand over operations to someone else. Well, the permission system in Graphene is more powerful than most know.
Improvement Proposal 2
Instead of having the same members in the two groups on both blockchains, we could use two different sets of users for the groups and pick elected, approved, reputable members of the corresponding blockchain community. The advantage here is that the group doesn't need to share people, it only needs to be able to read the other blockchains state. Of course, if you are moving funds from one chain to another chain, you may want to have control over the corresponding asset, but assuming you are just interested in allowing people to move between chains and issue/burn the assets right after reception, then you can also just pay the group members by other means for the operations they perform
Improvement Proposal 3
Instead of using the recipient account in the memo and have the group on the target chain automatically send over the asset, we could add another explicit step to request from users to claim the stake from the other chain. This could be combined with gift-codes or any other shared secret required for claiming stake (that has been burned/deposited to the group account on the other chain).
Now let's get one step further, since we can add multiple operations in a transaction proposal, a business opportunity would be to allow cross-chain asset trading for a fee. For instance, you could require a valid proposal to have a second operation that pays the group members/operators a fee. This way, sending stuff to the other blockchain could be free, but claiming the stake would cost a fee.
Improvement Proposal 4
Given that we can require a fee, and have a profitable business around side-chaining, we could put all of this into a package and make it a Fee-Backed Asset. People that pay the fee have to pay it into the buyback account of the FBA. Holders of the FBA profit from these fees.
Conclusion
I here propose a simple method to implement side-chaining (as in cross-blockchain transfers via multisig groups) to arbitrary many blockchains today. The easiest, of course, is to start with Graphene-based blockchains because of their superior permissions model. Technically, any blockchain that knows a multi-signature scheme can be added too. Having a dynamic set of group members allows to kick out badly performing members that don't manage to approve legit proposals quickly.
Thanks for the proposal, xeroc, but IMO this not truly side-chaining.
This is the crucial point, IMO. Your proposal creates a more-or-less centralised gateway controlled by a number of people.
IMO a true sidechain {c,w,sh}ould be implemented by generating some kind of transferrable proof within the blockchain. Anyone should be able to transfer such a proof from one chain to the other.
For example, I create a special kind of transaction on PEERPLAYS that transfers 100 PLAYSHARES to user xeroc on chain BITSHARES. PeerPlays witnesses create a transferrable proof of that transaction. Someone (witnesses could voluntarily take that role) transfers that proof to the BitShares chain (by publishing it as a transaction). BitShares automatically recognized that proof, and issues 100 PEERPLAYS.PLAYSHARES to xeroc.
Such a proof could, for example, consist of the signed blockheaders in combination with some meta information like the block signing keys of the active witnesses.
The devil is in the details though. :-)
That's actually a brilliant idea. But requires the witnesses of the BITSHARES blockchain to know about the PEERPLAYS blockchain because otherwise they couldn't be sure that the blockheader and the signer is indeed a legit block producer on the other chain.
My goal was to have a means of bringing arbitrary many "side-chain"-groups to a blockchain without involving the actual consensus mechanism for the very simple reasons of maintaining scalability.
Let's assume you had a "master-blockchain" and wanted to add other blockchains as, erm, .. special-feature plugins blockchains, then you would want to be able to handle arbitrary many. For that reasons I think you should keep the consensus of each chain separately .. That's also good for robustness of the "master-blockchain" and the plugin-chains because they can all act independently ..
If we could come up with a proof that that can be verified without syncing the other blockchain, then your strategy is a winner!
We could use the committee for bootstrapping sidechains. A sidechain consists of at least (genesis hash, initial block signer's pubkeys, top-level asset name). Based on the genesis hash and the initial block signers, a chain of transferrable proofs can be generated. The transferrable proofs would have to continuously update the active block signing keys, and it'd have to produce a continuous chain of block header signatures. A transferrable proof is only accepted by the target chain after a sufficient number of successive blocks signed by 2/3 of the active witnesses has been received.
One tricky part is that Graphene currently allows to swap a large number (all?) of active witnesses (or their block signing keys) at once.
Storing block headers of several chains would create some bloat, but I think that'd be worth it.
Good to see that you came upt with a similar idea of what I have in mind as well .. at least long term. This article, however, focuses on a simple solution at the cost of trustlessnesa, of course.
I would love to see something like what you just explained potentially even with improvements to graphene, but in the meantime (lets assume we are going to need this soon), i think the approach above works sufficiently well.
Interestingly, though, a POW scheme could do better here because the difficulty is easier to track and stays constant for a certain period. That makes proofing a statemwnt in another chain easier (assuming sufficiently high difficulty)
: )
You are trusting the Peerplays witnesses as the multisig group that you trust then. There is no way of getting around that. Some trust is needed if you want to decouple the state of the blockchains for scalability reasons.
In the scheme I laid out the role of witnesses would not change: they can include transactions or try to suppress them. The rest is handled by the blockchain itself. Witnesses do not get to decide how much is paid out and to whom.
Perhaps you have misunderstood this sentence:
I'm not thinking of a to-be-defined piece of data signed by multiple witnesses, separate from the source blockchain. Basically, the block headers from the source blockchain plus the relevant transactions are the transferrable proof of work. Yes, some trust has to be put into witnesses, but IMO not more than is typical in Graphene.
That bolded part was my point. I understand what you are proposing. I have suggested something similar to that in the past for better light client security (that's why I linked to that post with my happy face reply). But the point is that the set of simultaneously active witnesses at any point in the past no older than the latest irreversible sync point can collude to trick the light client or the other blockchain of any proof they want. So it is fundamentally no more secure than a multisig sidechain.
As a point of comparison, a full validating node can know when the witnesses are producing invalid blocks that do not follow the rules. Those full nodes won't just follow the witnesses even if 100% of them agree to the fake rules. The nodes will instead think of it like a denial of service. Users of Graphene blockchains don't need to trust the witnesses to not change the rules, they just trust them to not censor transactions or cause network disruption. But whether it is a light client or a scalable mechanism for sidechains, in order to gain performance benefits (by not needing to validate the full chain) you need to give up something. And that thing you give up is trustlessness.
You are forced to trust a hopefully decentralized group to not collude to produce fake proofs or fake claims. You can potentially also provide other mechanisms that financially penalize them if the blockchain is presented with a provably-fake witness-signed proof as a way to align economic incentives to reduce the likelihood of cheating. So these ideas are still very valuable, but I just want to point out that the trust model isn't that fundamentally different from a multisig sidechain.
Xeroc, I see it as a gateway..... I agree that a trully n automate n without trust sidechain in bitcoin or ethereum maybe makes sense, because interoperate both giant market makes sense, bitshares has great potential but its still small, should focus on smartcoins, liquidity advanced trading features, if bts starts to trading millions daily, in that case, makes sense.
Why not a dynamic set of members?
Thats what i wanted to bring across in Improvment Proposal 1
I think GnuClear can be a great solution to this problem.
https://github.com/gnuclear/gnuclear-whitepaper
Hi publicworker, would you summarize how this proposal works? is it trustless, trully decentrilized or a kind of multisig? I always scared of spending too many times reading tech geek thing that does not solve any problem,
I cannot see a reason to lock btc/eth (only asset worth lock) to give it in bts blockchain, even there is no scalability issue........ even if projects build on graphene, issued n traded in dex could interoperate in a plug n play way it does not make sense what benefit could be gained for value, volume, adoption......I dont see a reason either a proposal that reasonable or that makes some sense to put a work for it over the tables, the benefits are not worth in my opinion, but this is just a opinion of a pratical averajoe that does not have interest for fancy things but for. solutions that drives adoption n make useful n needed
I'm speechless
Appologise for missing some parts of your post. However I don't propose to establish a company, nor am I asking for funds. All I do is present some technical details and a brief introduction of how i would approach this if i needed it today.
Thanks to @cyrano.witness who provided some thoughtful insides into his views and comes up with a different approach.
The OP by noeans wants to take anyone's business opportunity and merely serves as educational material.