Scaling through Sidechains

What is a Sidechain?

The term “sidechains” was first described in the paper “Enabling Blockchain Innovations with Pegged Sidechains”, circa 2014 by Adam Back et al. The paper describes “two-way pegged sidechains”, a mechanism where by proving that you had “locked” some coins that were previously in your possession, you were allowed to move some other coins within a sidechain.

A misconception here should be clarified.

Sidechains can increase scale but do not imply scalability. Sidechains are no better at providing scalability than increasing block size. What sidechains bring is the ability to experiment. To be able to build networks that run on different — and possibly better-scaling — technology.¹

They enable innovation.

A sidechain is defined by a custom “rule-set” and can be used to offload computations from another chain. Individual sidechains can follow different sets of rules from the mainchain, which means they can optimize for applications that require extremely high speeds or heavy computation, while still relying on the mainchain for issues requiring the highest levels of security.

Application-Specific Sidechains

The rules that define a sidechain can imply adding privacy features, or even trading security & decentralization for more throughput. There is a lot of room for experimenting here and what trade-offs should produce the optimal performance, based on the needs of the individual application.

Also, in the case of data-driven applications, incentives differ from financial applications. It may be worth it for an attacker to spend hundreds of millions of dollars to 51% attack a financial blockchain and reverse a payment, but it probably doesn’t make sense for them to do so to reverse a tweet on a microblogging platform. Because of this, applications need to be able to choose more flexible threat modeling and optimize for performance.

There is a huge need for unstoppable applications that are censorship-resistant, transparent, and provide high performance.

With that in mind, in a Twitter-style Decentralized Application running on a blockchain, adjustable security can enable higher throughput while submitting “checkpoints” to the main-chain in order to declare the finality of the data so far.

Now that we have described a way to scale DApps, what would happen if an entity gathered too much power, due to a potentially relaxed security model, and was able to control a sidechain?

Achieving independence through hard-forks

In centralized communities such as a subreddit, sometimes a toxic moderator gets into place, starts censoring messages according to his agenda, and eventually tears that community apart.

In multiplayer games such as World of Warcraft, sometimes a massive change is implemented against community consensus, leaving no option for users to protest — they’re forced to either accept it or quit the game. Even Vitalik Buterin was horrified by these events!

“I happily played World of Warcraft during 2007–2010, but one day Blizzard removed the damage component from my beloved warlock’s Siphon Life spell. I cried myself to sleep, and on that day I realized what horrors centralized services can bring. I soon decided to quit.”

Coordinated communities need to be able to pave away from situations they believe are not fair and move on alternatives that they all agree on.

They key to achieving that is sidechain hard forks.

Being as laconic as possible, a fork is a protocol upgrade mechanism. A high-quality comparison between forks can be found on Vitalik’s blog.

Fork variations Venn diagram, taken from vitalik.ca/general/2017/03/14/forks_and_markets.html

A hard fork is a permanent divergence from the previous version of the blockchain. Nodes running previous versions will no longer be accepted by the newest version.¹

How do you achieve independence that way?

In the occurence of an event that was against community consensus, the community is able to fork away, taking the state of the sidechain until before the dispute with it.

A proposed change that does not match community consensus can be ignored, and the community can keep on working on the old chain.

There are many questions that would arise in this case such as, in a game for example:

What if the majority of the leading “malicious” devs decide to stay in the old chain? Will the new chain become stagnant of development, or will the developers compromise and adapt?

We do not have all the answers, but we believe the free market will figure these things out and best practices will emerge as more of these types of self-governing applications are created.