A new Sidechain Proposal by Horizen — Part 1
A promising approach to building on top of existing first-layer protocols — summary of the whitepaper for readers with a general understanding of blockchain technology.
The Horizen sidechain construction has been revised and is covered in a new article here.
Many people don’t have the necessary time or motivation to work themselves through whitepapers but nonetheless want to stay up to date with current developments in the blockchain sphere and have a general understanding of the technology. For those, I want to provide an overview of why a number of teams are looking into sidechains and how the sidechain implementation that Horizen is proposing works.
TL;DR: The Engineering team at Horizen led by Alberto Garoffolo has proposed a new sidechain construction in a recent whitepaper based on proof-of-stake principles. The main innovation is a new backward transfer protocol, that allows transactions from one of the possibly many sidechains back to the mainchain, without the mainchain having to track the sidechain and without introducing a centralized federation of validators. While a reference implementation of a sidechain consensus protocol will be provided, a wide range of sidechain consensus protocols will be possible.
This is Part 1 covering sidechains in general. Part 2 will cover the Sidechain Consensus and Cross-Chain Transfer Protocol
Sidechains are a concept that people have been looking into for a while now. The first proposal of sidechains was developed by Back et al. in 2014 and a number of different teams are working on implementing them as a solution to problems such as scaling and interoperability.
I will first outline what sidechains are in general and what a successful implementation of sidechains can achieve. I will continue to explain, why Horizen is interested in a sidechain solution and what could be some specific use cases for the project. Lastly, I want to describe how the proposed solution that Horizen came up with is going to work. If you mostly care about the in-depth technical details of the proposed solution the whitepaper will be for you.
What is a sidechain and why would you want one?
When Back et al. introduced the concept of sidechains in 2014 they provided the following definition along with it:
A sidechain is a blockchain that validates data from other blockchains. […] 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. Back et al. — Enabling blockchain innovations with pegged sidechains, 2014
In other words, a sidechain is a blockchain in and of itself, but with the capability to communicate and interoperate with one or more other chains. When you hear the term sidechain today, people are mostly talking about pegged sidechains, which allow you to transfer assets back and forth between chains.
So what is the benefit of having sidechains?
Most blockchains facilitating cryptocurrencies (not tokens) use the proof-of-work consensus algorithm and have incorporated the core functionalities of the Bitcoin protocol. Therefore they inherited a lot of the constraints from the code created by Satoshi Nakamoto. This includes limited throughput, high latency and a limited ability to scale. Sidechains present an option to help overcome some of these technological shortcomings, but besides just opening doors to potential technical leaps, they touch on the topic of governance in a way.
As debates across the recent years have shown, making changes to the codebase in decentralized projects tends to be a cumbersome process. This is arguably a feature, not a bug. Especially for projects such as Bitcoin stability (not in regards to price, but code) is crucial and the overall security of the protocol benefits greatly from the careful consideration of every change applied to the system.
Sidechains offer a mechanism to implement features on top of a first layer protocol, such as Horizen in this case, without compromising the security or stability of said protocol. After an initial fork that adds the capability to deploy sidechains and introduces a way to transfer assets from the mainchain to the sidechain and vice versa, a number of parallel chains can be built, each serving a different purpose, without having to build consensus for each individual feature.
It is important to note though, that the initial change to the codebase enabling the deployment of sidechains and cross chain transfers has to be done carefully and possible solutions should be evaluated with great caution. If a project manages to deploy those features, ideally with giving sidechain developers many degrees of freedom, while eliminating the possibility to compromise mainchain security, then developers can start playing around and build on top of projects, where changes to the protocol traditionally required consensus building for months and even years. If a user is not interested in using a particular sidechain, he doesn’t have to care.
What can you do with a sidechain?
As I said earlier many teams are looking into the technology of sidechains for a variety of purposes. The team behind Rootstock is working on a way, to provide smart contract functionality on top of Bitcoin. They are referring to their sidechains as secondary chains. Polkadot, naming its sidechains Parachains aims to connect permissioned and public blockchains. The general idea of Plasma is also based on sidechains, or child blockchains and here the main goal is scaling. Drivechains are meant to enable BTC to be moved to other software applications, like different public blockchains.
I am aware that there are technical differences between the projects and that you could make a case of distinguishing between sidechains and drivechains as discussed in this paper by Rootstock. I will pick up on their distinction shortly when talking about how sidechains work.
The general idea is the same though and satisfies the broad definition of a pegged sidechain that Back et al. provided about four years ago.
Critics of the sidechain concept like to point out, that most current sidechain implementations rely on a set of validators to facilitate cross-chain transactions. Sidechain constructions are therefore often times called trust-minimized instead of trust-less. The risk comes down to the ability of the trusted validators to censor transactions from main- to sidechain and vice versa. The protocol at hand addresses this issue in an elegant way.
Why does Horizen look at sidechains?
The Horizen blockchain project has set itself quite ambitious goals, including features such as developing a treasury system for the DAO in cooperation with IOHK (here is a summary if you like), a decentralised solution for tracking Secure- and Super Nodes and handling their rewards, as well as developing a Block-DAG protocol to increase transaction throughput.
As some of these functionalities would require significant modifications of the core client if implemented directly in the existing codebase, you can probably already see the benefits of developing a sidechain implementation first.
Building new features and making changes to the protocol, even if they are small, is not just challenging from the aspect of building consensus around them, but it also comes with security risks. Every addition has to be considered carefully as the recently found bug in Bitcoin has shown.
The idea is to develop a robust sidechain implementation once and being able to build new features expanding the Horizen ecosystem afterward more easily. Sidechain implementations will be completely decoupled from the mainchain and can, for example, run an entirely different consensus algorithm.
That way, it would be possible to run the sidechains facilitating the treasury and node tracking system with a proof of stake like consensus protocol, a block-DAG on a sidechain with an entirely new POW-based consensus protocol, while the mainchain is maintained with “traditional” POW.
So, how does it work now?
The construction of the sidechain model consists of two parts:
- The sidechain consensus protocol — SCP
- The cross-chain transfer protocol or 2-way peg — CCT
The CCT consists of two sub-protocols that I want to introduce shortly because it simplifies talking about the matter a lot.
The first sub-protocol is dealing with forward transactions, which are transactions from mainchain to sidechain.
The second sub-protocol is dealing with backward transactions, which are transactions from sidechain to mainchain.
The first design decision that had to be made, is whether the mainchain should be aware of the sidechains. The team led by Alberto Garoffolo decided to develop the SCP and CCT independently of each other.
The CCT protocol is to be unified and fixed by the mainchain logic so that all sidechains will use the same CCT protocol. The SCP protocol will be completely decoupled from the CCT and mainchain logic in general so that a sidechain developer is free to choose the SCP protocol depending on the needs.
Outlook
Although a number of different SCP’s is possible, I will shortly outline the proposed reference implementation of the sidechain consensus protocol, that is based on Ouroboros. I know the topic has caused some controversy in the past that I would like to stay out of so I will call it a Proof of Stake consensus protocol that makes use of the concept of delegation. Lastly, I will talk about the Cross-Chain Transfer Mechanism.
Preliminary Conclusion
I hope I managed to get the point across, of why sidechains could be an elegant way to overcome current limitations regarding scalability and governance in the blockchain ecosystem.
Having the ability to deploy sidechains will dramatically enhance the possibilities of building on top of existing public blockchains. One of the first use-cases of a sidechain for the Horizen project will most likely be the Treasury, moving the organization a step closer to becoming a decentralized autonomous organization. If you want to know what the Horizen project is all about you can go check out their website here.
There will be a lot of work from here, to actually having a first sidechain deployed on the Horizen main-net. Nonetheless, the release of the whitepaper is an important step towards this target.
Here is Part 2, covering the Sidechain Consensus Protocol and Cross-Chain Transfer Mechanism.
As I am only getting started with writing about technical innovations in the blockchain sphere please feel free to leave any feedback or criticism. If you like what you have found here and would like me to cover another topic that is of interest to you, please leave a comment and maybe even a clap or two. I appreciate every new follower on Medium and Twitter.
I’d like to thank the Coinmonks publication for giving me a platform for increased exposure and proofreading. Also thanks to the team around Alberto for giving me access to the whitepaper pre-release.
See you guys,
Jonas Rubel
Edit 13.07.2020: Add reference to new sidechain article.
