Lets shard the blockchain using sidechains

Sharding is a very old concept in centralised database design. A database shard is a horizontal partition of data in a database. Each individual partition is referred to as a shard or database shard. Each shard is held on a separate database server instance, to spread load. It means breaking up your database into multiple separate databases which do not share any common data. It allows horizontal scaling of any database system as we can increase the shards to to scale infinately.

UPDATE : Karachain has been shut down, as has always been communicated, we were anyways not going for any fundraising round in the near future, which still stands in place.

Most of the databases like MongoDB and MySQL today already support sharding. So, the technology is already here and mature enough to be mainstream. While blockchains have been around for quite some time, we have still not seen any mainstream adaption of sharding. One approach proposed is to have multiple shards and each shard can have transactions based on the sender’s address range. For example, shard 1 can have addresses from 0x1… to 0x1999….. similarly shard 2 can have transactions with sender’s addresses in the range of 0x2000.. to 0x2999… There are multiple ways and orderings in which we can shard the blockchain, but they pose the following difficulties:

• Cross shard communication — the above design supports no cross-shard communication. How do we add cross-shard communication safely?
• Single-shard takeover attacks — what if an attacker takes over the majority of the collators in one single shard, either to prevent any collations from getting enough signatures or, worse, to submit collations that are invalid?
• Fraud detection — if an invalid collation does get made, how can nodes (including light nodes) be reliably informed of this so that they can verify the fraud and reject the collation if it is truly fraudulent?
• The data availability problem — as a subset of fraud detection, what about the specific case where data is missing from a collation?
• Superquadratic sharding — in the special case where n > c², in the simple design given above there would be more than O(c) collation headers, and so an ordinary node would not be able to process even just the top-level blocks. Hence, more than two levels of indirection between transactions and top-level block headers are required (ie. we need “shards of shards”). What is the simplest and best way to do this?

For more details, please refer to the Ethereum’s sharding FAQ.

Sidechains

Sidechain is a blockchain that runs in parallel to the main blockchain allowing a decentralized way of transferring/synchronizing your tokens between the two chains. In other words, you can move your native cryptocurrency to the sidechain and then back to the main chain.

So in short, sidechains are separate independent blockchains with their own consensus mechanisms, mining/forging algorithms and transaction formats. That is why each side chain can have its own native token/asset as well. Thus, if we imagine Bitcoin as the main chain and Ethereum’s ETH blockchain as a sidechain, we can transfer BTC to Ethereum’s blockchain and enjoy the benefits of Smart Contracts, just like any asset, those Smart Contracts can transact with BTC directly because those Bitcoins would be on Ethereum’s own blockchain.

Let us understand how such a scenario is possible:

1. There can be a lock transaction on Bitcoin’s blockchain locking an amount of 1 BTC(for example) showing proof of burn. The transaction would be a cross chain transaction with its own data parameters containing the required sidechain metadata.
2. We can wait for atleast 50+ confirmations or more in order to reduce the probability of reorganisation of the bitcoin’s blockchain.
3. Then, the receiver or the user can perform another transaction on the sidechain(in this case Ethereum’s) in order to withraw those funds. This sidechain would verify that the 1 BTC were locked on Bitcoin’s blockchain using SPV, or using Proof of Proof of Work(PoPoW) explained in this whitepaper. The node running the sidechain can also maintain bitcoin’s blockchain in the worst case as well.
4. The above transaction would be similar to a coinbase transaction, the only difference will be that it would be generating BTC rather than its native currency(ETH in this case). Before these Bitcoins can be used in this new blockchain with its own rules and regulations, there should be a minimum waiting period/confirmations.
5. Now the transactions can take place, these transactions may not follow the UTXO tx model. It would be exactly similar to the sidechain’s transaction model( account based in case of Ethereum).
6. A similar process can be used to transfer back those 1 BTC from the sidechain to the main chain(Bitcoin’s blockchain).

The main chain can protect itself even if the sidechain is compromised as it can proved very easily that only 1 BTC moved out of it and it will not accept more than that.

While we have reduced the probability of reorganisation of the main chain, it is still theoretically possible, the sidechain would need to adjust and reorganise itself if such a scenario occurs. This thing can be prevented by using a consensus mechanism in the main chain like DBFT(Delegated Byzantine Fault Tolerant) which has a sense of finality.

Sharding using sidechains

As we can see, an asset can move around sidechains and can be used across various networks in accordance with their rules and regulations. Here are some ways in which we can reduce the load of the main chain:

1. DApp based sidechains : Each DApp deployed can run its own sidechain, imagine Cryptokitties had its own sidechain, we would have been able to transact usually with Ethereum’s main chain.
2. Industry based sidechains : We can have multiple sidechains per industry as well, we can have a travelchain or a chain for the airlines industry, similarly the oil industry can run its own sidechain.
3. Asset based sidechains : Everyday, we see many ERC20 tokens being created for one purpose or the other. Each of these tokens can live as native assets in their separate sidechains, people can transfer these tokens without needing ETH as gas.
4. Utility based sidechains : We can have a separate blockchain for raising funds via ICOs and a separate blockchain for charity work.

Using the above concepts, there are infinite ways in which we can scale the blockchain just by sharding it via sidechains. There are a few things related to the security of this approach and we are actively researching in bringing out the best way in which we can implement this. This is one of the many ways in which we are scaling this amazing technology called blockchain.