This lecture was more theoretic. It discussed a potential solution for having a pegged altcoin with Bitcoin as well as a new manner to efficiently validate transactions. I thought the topics discussed were worth exploring but still remained a bit too abstract for general consumption. As of today, there are no widely used decentralized sidechains. The paper,“Enabling Blockchain Innovations with Pegged Sidechains”, and the work was funded by a private company known as Blockstream. They currently provide a federated sidechain. Some of the authors have even suggested that the solution proposed was not feasible given breaks in the security model.
Questions answered:
- What is the purpose of a side-chain?
- What is a side-chain?
- What requirements are needed to support a sidechain?
- What was a gist of the research?
Side Chain Goals
Sidechains are a solution in response on how to enable bitcoin or other ledger based assets to be transfered across other blockchains, ie altcoin with bitcoin. Bilateral peg allows for someone to take a risk to transfer into an altcoin and still have the opportunity to transfer out to bitcoin without losing value. Token sales and token drops are unilateral meaning that once someone exits bitcoin there is no path back as well as it can add to the volatility of the altcoin. Some chunk of the lecture was spent describing what do the two chains need to support to allow this interoperability.
Side Chain Reqs
The requirement seem logical. To transfer into bitcoin, you want to lock the bitcoin up in some way that the other chain recognizes that some amount of the altcoin needs to be minted. In reverse, you need to burn or destroy the altcoin in a way that unlocks the bitcoin. Ok, now this isn’t as simple as doing an escrow payment where a lawyer locks up funds in one account and then gives you back funds after some event. Essential two independent worlds ie networks need to know enough about each other to do the locking and unlocking. By know enough, it’s that bitcoin would need to be able to validate the transactions that occurred on the altcoin to ensure you’re unlocking the right amount. The lecturer makes the claim that this would not be possible without modifying bitcoin in some manner by a soft-fork.
The most straightforward though costly would be to encode all the sidechain’s rules to Bitcoin and thus Bitcoin could always keep track of the sidechain’s transactions. There are some tricks to make this not necessary though. One is called the SPV trick.
SPV Proofs
SPV is the Simplified Payment Verification and this enables lightweight clients to validate just enough transactions that they’re accurate but not too many that it becomes cumbersome. SPV only verify block headers and worry about the longest valid chain. The lecturer suggests that one could extend the Bitcoin’s script on how to verify a proof that a specific transaction occurred in the sidechain. As discussed this requires tracking the longest chain and looking at all the block headers. Specifically, to reference a sidechain transaction in Bitcoin, you need to check that the sidechain transaction in the sidechain block and the sidechain block headers had received enough confirmations. The work suggests that instead of verifying that you have the longest chain, one will wait to allow other users to present evidence it’s not the longest chain. Thus, essentially you’re requiring that additional participants need to be correctly incentivized to present evidence. Additionally, the guarantees of the system are that Bitcoin will not be damaged but makes no claim about the sidechain. Thus, if you care more about the sidechain security, you’d need to take similar considerations. There is a second consideration given that block rates on sidechains may be different from bitcoin.
Research Work
As I’ve discussed earlier, blockchains like Litecoin and Ethereum have significantly shorter block rates. That’s one of the benefits the sidechains could provide. That said, lower block rates could make verifying SPV proofs too onerous for Bitcoin nodes. Thus, it would be clever if there was a way to decrease the amount of computation such that the number of verify N block confirmations grew slower than linear.
Thus this was the work discussed by the lecturer and the paper. The lecturer proposed using a datastructure known as skiplist which could allow for compact SPV proofs. The work is less about the datastructure but providing evidence that you need to do a fourth less verification work given the distribution of the hash values. This is where I’m going to stop since the vagueness isn’t too useful for the reader.