RE: Simple Side-chaining for Graphene-based Blockchains (BitShares/PeerPlays/Steem)
Thanks for the proposal, xeroc, but IMO this not truly side-chaining.
we do not want to trust a central entity like an exchange or gateway to do this for us
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.