Sidechains introduction
- 1. Sidechains
- 2. Sidechain in a nutshell
- 3. Background information Bitcoin blockheaders can be regarded as example of DDMS DDMS (Dynamic membership multi-party signature) ◦ Digital signature formed by a set of signers which has no fixed size Similarity ◦ any one can contribute with no enrolment process; contribution is weighted by computational power rather than one threshold signature contribution per party Difference ◦ Blockchain use of DDMS as a signature of computational power rather than a signature of knowledge ◦ Blockchain signers prove computational work, rather than proving secret knowledge as is typical for digital signature.
- 4. Pegged Sidechain(two-way peg) design idea Interoperable blockchains ◦ Allow movement of asserts between blockchains, new systems could be developed which users could adopt by simply reusing the existing bitcoin currency. Designed Properties 1. Assets which are moved between sidechains should be able to be moved back by whomever their current holder is, and nobody else (including previous holders). 2. Assets should be moved without counterparty risk; that is, there should be no ability for a dishonest party to prevent the transfer occurring 3. Transfers should be atomic, i.e. happen entirely or not at all. There should not be failure modes that result in loss or allow fraudulent creation of assets. 4. Sidechains should be firewalled: a bug in one sidechain enabling creation (or theft) of assets in that chain should not result in creation or theft of assets on any other chain. 5. Blockchain reorganisations should be handled cleanly, even during transfers; any disruption should be localised to the sidechain on which it occurs. In general, sidechains should ideally be fully independent, with users providing any necessary data from other chains. Validators of a sidechain should only be required to track another chain if that is an explicit consensus rule of the sidechain itself. 6. Users should not be required to track sidechains that they are not actively using.
- 5. Proposed method Transfer assets by providing proofs of possession in the transferring transaction themselves Break down: ◦ Chain 1 transfer asset to Chain 2 ◦ Chain 1: create a transaction, locking the assets ◦ Chain 2:create a transaction with input contain a cryptographic proof that lock was done correctly. Inputs tagged with an asset type(the genesis hash of its originating blockchain) ◦ Chain 1 can transfer to chain 2 and vice versa
- 6. Definitions Sidechain ◦ is a blockchain that validates data from other blockchains. Two-way peg ◦ refers to the mechanism by which coins are transferred between sidechains and back at a fixed or otherwise deterministic exchange rate. A pegged sidechain ◦ is a sidechain whose assets can be imported from and returned to other chains; that is, a sidechain that supports two-way pegged assets. A simplified payment verification proof (or SPV proof ) ◦ is a DMMS that an action occurred on a Bitcoin-like proof-of-work blockchain.
- 7. Symmetric two-way peg This works as follows: to transfer parent chain coins into sidechain coins, the parent chain coins are sent to a special output on the parent chain that can only be unlocked by an SPV proof of possession on the sidechain. To synchronise the two chains, we need to define two waiting periods: ◦ The confirmation period of a transfer between sidechains is a duration for which a coin must be locked on the parent chain before it can be transferred to the sidechain. A typical confirmation period would be on the order of a day or two. ◦ After creating the special output on the parent chain, the user waits out the confirmation period, then creates a transaction on the sidechain referencing this output, providing an SPV proof that it was created and buried under sufficient work on the the parent chain. ◦ The confirmation period is a per-sidechain security parameter, which trades cross-chain transfer speed for security. ◦ The user must then wait for the contest period. This is a duration in which a newly-transferred coin may not be spent on the sidechain. ◦ The purpose of a contest period is to prevent double- 240 spending by transferring previously-locked coins during a reorganisation. If at any point during this delay, a new proof is published containing a chain with more aggregate work which does not include the block in which the lock output was created, the conversion is retroactively invalidated. We call this a reorganisation proof. ◦ All users of the sidechain have an incentive to produce reorganisation proofs if possible, as the consequence of a bad proof being admitted is a dilution in the value of all coins. A typical contest period would also be on the order of a day or two. To avoid these delays, users will likely use atomic swaps (described in Appendix C) for most transfers, as long as a liquid market is available.
- 9. Drawbacks of sidechain Complexity ◦ Network level:multiple independent unsynchronized blockchain supporting transfers between each other. Must support transaction scripts which can be invalidate by a later reorganization proof. ◦ Software needed to detect misbehaviors, and produce and publish proofs. ◦ Assets level: each chain may support arbitrarily many assets ◦ Each of these assets is labelled with the chain it was transferred from ◦ User interface: need to have wallets that adapt and support multiple chains and transfers of assets between chains Fraudulent transfers ◦ Reorganisation of arbitrary depth in principle possible, which could allow attacker to completely transfer coins between sidechains before causing a reorganisation longer than the contest period on the sending chain to undo its half of the transfer. ◦ Reaction design ◦ No reaction: the sidechain is a “fractional reserve” of the assets it is storing from other chains ◦ The peg and all dependent transactions could be reversed. ◦ The amount of all coins could be reduced, while leaving the exchange rate intact.
- 10. Drawbacks of sidechain Risk of centralisation of mining ◦ Sidechain with mining fee may place resource pressure on miners, creating bitcoin centralisation risks Risk of soft-fork
- 11. Applications Altchain experiments ◦ Technical experiment ◦ Fixing undesired transaction malleability ◦ Improved payer privacy ◦ Script extensions ◦ Many ideas for extending bitcoin in incompatible way ◦ Economic experimentation Issued assets ◦ Side chains can have their own assets and currencies
- 12. SPV proof composed of (a) a list of blockheaders demonstrating proof-of work, and (b) a cryptographic proof that an output was created in one of the blocks in the list. This allows verifiers to check that some amount of work has been committed to the existence of an output. Such a proof may be invalidated by another proof demonstrating the existence of a chain with more work which does not include the block which created the output. Using SPV proofs to determine history, implicitly trusting that the longest blockchain is also the longest correct blockchain, is done by so-called SPV clients in Bitcoin. Only a dishonest collusion with greater than 50% of the hashpower can persistently fool an SPV client (unless the client is under a long-term Sybil attack, preventing it from seeing the actual longest chain), since the honest hashpower will not contribute work to an invalid chain
Editor's Notes
- #8: The purpose of this confirmation period is to allow for sufficient work to be created such that a denial of service attack in the next waiting period becomes more difficult.