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.