The original concept of a Bitcoin sidechain was proposed by Adam Back, Matt Corallo, Luke Dashjr, Mark Friedenbach, Gregory Maxwell, Andrew Miller, Andrew Poelstra, Jorge Timón, and Pieter Wuille, who all went on to found Blockstream, in 2014.
The idea was proposed to allow a more liberal development environment, where people could try new ideas and technologies on a sidechain without risking the security of the main Bitcoin blockchain.
Since then the design space of sidechains has grown rather large.
At the end of the day sidechains is a very broad term that encompasses a large range of very diverse and different systems. They can be as varied and arbitrary as the entire ecosystem of altcoins and other blockchains can be. That is after all what they are, other blockchain systems.
Regardless of the specific designs of any given sidechain, they have two primary components: a peg, and a consensus mechanism and rules. The peg functions as the vehicle for “locking” and “unlocking” coins on the mainchain to move them back and forth between Bitcoin’s base layer and the sidechain. The consensus mechanism and rules are how the sidechain itself functions, i.e. how new blocks are created, and the rules for what behaviors and transactions or contracts are allowed.
These are the necessary pieces for a sidechain.
The Original Proposal
The 2014 Blockstream design proposed the use of merge mining for a consensus mechanism, reusing the work from current Bitcoin miners by having sidechain blockheaders be committed indirectly in the mainchain blockheader, and Simplified Payment Verification proofs (SPV proofs) in order to operate the peg mechanism.
To facilitate merge mining, all sidechains would construct their blockheader as a “subheader” committed to in the coinbase transaction of a mainchain block. This would allow all miners to simultaneously mine the mainchain as well as whatever sidechains they choose to commit to. Any mainchain blockheader that meets a sidechain difficulty target, even if it does not meet the target for the mainchain, can be submitted to the sidechain network as a valid block.
Pegging required merkle proofs showing that certain transactions were included in a block. The proposed peg mechanism could work one of two ways, using symmetric SPV proofs, or asymmetric SPV proofs.
The symmetric scheme would require SPV proofs of both deposits and withdrawals, with a contest period. To deposit, users would need to send coins to a script on the mainchain that could only be spent by producing an SPV proof. After waiting for the contest period to elapse, the user could unlock coins on the sidechain with an SPV proof that they have deposited coins to the sidechain script on the mainchain. Any proof that a reorg with more work has occurred on the mainchain can be used to invalidate the claim transaction on the sidechain, and every sidechain user would have an incentive to produce that proof to prevent the peg from losing 1:1 backing.
Withdrawals would require the inverse, locking sidechain coins in a script requiring SPV proofs from the mainchain to unlock. After waiting for the contest period to elapse, the user can then unlock coins on the mainchain using an SPV that they locked coins on the sidechain.
The asymmetric variant does away with the need to produce SPV proofs of the mainchain for deposits by requiring sidechain nodes to also run and verify the mainchain by consensus. This would allow for faster and more secure deposits, but increase the validation costs of a sidechain.
While merge mining has been deployed for numerous sidechains, as well as completely independent altcoin networks, the SPV peg proposed in the original paper, and the needed consensus changes to Bitcoin, have never been implemented or deployed.
The Appendix – Federated Pegs & Other Designs
In the Appendix A to the original paper, the authors proposed in lieu of (or until) the softfork necessary to implement their SPV peg design the use of a federated peg. The proposal was to use a multisig of functionaries to operate the peg, custodying users coins while used on the sidechain and enforcing the validity of withdrawals. This was done with the implementation of Liquid, which also used the functionaries to sign blocks for the sidechain with cryptographic keys, and Rootstock, which made use of merged mining for sidechain consensus.
Since the launch of these sidechains, there have been numerous other design proposals for different sidechain consensus mechanisms, as well as different sidechain peg mechanisms. While many of them have been deployed, not all of them have, and none of them have truly achieved any serious level of adoption.
Below are links to a previous article series I have written looking at the different aspects of other proposed sidechain designs. While this series is not entirely complete, it includes most of the biggest proposals.
