The use of main blockchains has increased over the years, specifically the Ethereum and Bitcoin ones. It’s not uncommon for the Bitcoin blockchain processing one transaction every hour. The Ethereum blockchain is feeling the strain of Dapps. These problems are due to the low scalability of both blockchains.
What is Scalability?
Let’s start with a simple example. Imagine that you are a farmer and need to sell apples. Specialists rate your apples. There are 100 experts who will rate your apples. They must give it a rating from 1-10, with 10 being the highest quality. To be allowed to sell your apple, you must wait for all the experts to rate them. This sounds complicated, doesn’t?
Imagine that you’re not the only one wanting to sell apples. There are 500 other farmers. They all have to wait for their products to be rated. What is the time frame? This is the scalability problem – the inability to adapt to changing requirements.
Major blockchains face scaling issues. This happens when a blockchain is able to process a small number of transactions per second or minute. This problem can be solved by sharding.
The Scalability Issue Can be Solved by Sharding
The same can be said for apples in order to explain what sharding means.
500 apple farmers have apples for sale. Before the apples can be sold, 50 experts must rate them. Specialists are then divided into different groups and each group does its part. It takes 10 times less to evaluate all apples if there are 10 groups with 5 specialists. They can rate apples faster if there are more experts who can form groups.
This is an example of sharding, where a system is broken into parts (shards), each shard responsible for processing data stored in the network.
Each shard contains its own data. This makes each shard unique.
Data is not randomly assigned to shards. A database can be broken down into rows. Different types of information are handled by shards (or rows):
- Storing transaction history
- Transaction state
- Type of digital asset, etc.
Sharding is already used in many other areas. Splitting large databases into smaller ones is a common practice. The blockchain case is however more complex due to its decentralization. There are also drawbacks to Sharding.
Sharding: The Challenges and Solutions
The possibility of a one-shard attacker
Even if they are broken into smaller instances, databases remain centralized. Blockchain is decentralized. This creates a serious security problem called a single-shard attack. It could lead to serious problems if we break it down into smaller instances, called nodes.
Different nodes can be assigned at random times to random shards in order to prevent attackers from focusing their attention on one shard. Nodes can then be reassigned or re-assigned to another Shard. An attacker cannot predict which nodes will be assigned to which shard at what time. The attackers can’t focus on specific shards. Because it is harder to predict which shards will be validators, the more secure the network is. After moving to the Ethereum2.0 network, Ethereum will implement this approach.
Blockchains that use PoW
The consensus mechanism is another problem with blockchain-sharding. Each node must have all of the blockchain information in order to use a Proof of Work blockchain (Bitcoin and Ethereum). These blockchains require that a majority of nodes confirm transactions, and then the transaction is added to the blockchain.
These blockchains do not support sharding. Although there are many ways to implement PoW blockchain sharding, they are too complicated and time-consuming to be efficient. To address the scaling issue, such blockchains will use an alternative solution. For example, off-chain transaction validations.
The entire blockchain is not stored in shards, but only its parts. Shards must communicate with each other in order to make the network work. Another challenge is to establish a communication mechanism that works when you introduce sharding.
There are two ways to solve the communication problem. It was very clear and easy to understand Ethereum.
You need to book both a train ticket or a hotel room. Both actions must be completed. The hotel room will be booked if the train ticket is available. The hotel room will not be booked if there are no available train tickets.
An app that handles both the ticket and hotel room requests simultaneously is one way. If one of the conditions is not met, it cancels the request and books the ticket as well as the hotel room. To complete the transaction, each shard sends receipts to the other. Account A on shard A sends money to account B on the shard N. ShardM deducts the amount from account A and creates receipt. The receipt proof (Merkle proof) and proof that the receipt was created are attached to the funds. Shard N reviews the receipt proof to ensure that it has not been spent. If all is well, shard N credits funds into Account B.
What if the app does not have the necessary functionality to handle both requests simultaneously? It can then be done using asynchronous messages. You first reserve a train. Next, you book a hotel. If both reservations succeed, you confirm both. You can’t have someone else reserve your seat or your ticket within the time frame specified by the reservation mechanism.
Here, shards communicate via a separate solution, a separate transaction network (a reservation mechanism).
Sharding is not the best solution to scaling. There are some drawbacks and complications. Many sharding methods are still being developed and tested. It is possible that there will be a standard solution to both security and scaling issues in the future.