Sharding: Divide to Conquer - The Key to Blockchain Scalability.

Imagine that you want to read "Lord of the Rings" and you go to the library to ask the librarian for it. Meanwhile, a line of other patrons forms behind you, each with their own book request. But they have to wait for the librarian to return before they can be served.

One librarian to serve the requests of so many customers is not ideal: he wastes too much energy and time going back and forth between shelves and cannot multitask.

To serve customers faster and handle their requests better, the library decides to hire new staff. Now, some librarians run back and forth between the shelves, search for requested books and bring them to customers.

With more staff, the system has improved, but efficiency still has a long way to go--and customers and requests keep piling up.

The library is very large, so why not divide it into smaller parts and assign a specific task to each librarian? One deals only with romance books, one with mystery books, and one with fantasy books.

"Lord of the Rings?" No problem, just ask the librarian in charge of fantasy books and he will find it in no time.

With this system, the queue of customers is processed much faster, the energy required to search for books is used more efficiently, and requests are resolved more quickly.

Well, the library has just applied the concept of Sharding to improve the performance of its book system.

We can think of the concept of?Sharding as the process of dividing a large task into smaller tasks so that they can be processed with a greater degree of parallelism and efficiency?(in terms of energy and time).

Simply put,?Sharding improves scalability!

However, not all that glitters is gold. What is the dark side of Sharding?

Sharding has some drawbacks and must be implemented carefully.

First, understanding the different Sharding techniques and choosing which one to use is not an easy task. The characteristics of specific data must be analyzed correctly.

In addition, one must be prepared for increased system complexity. If the correct technique is not identified or the complexity of the system is beyond your capabilities, Sharding "optimizations" could lead to even worse results than the unoptimized case, creating a degenerative scenario.

Sharding and Blockchain Technology

For blockchain technology to be seriously considered for mass adoption and applications in different sectors, it must become much more scalable.

It is a fact that over the past year and a half, Sharding techniques have been implemented even in complex decentralized infrastructures such as public blockchains to address scalability issues.

How does this process work?

Splitting a blockchain into shards means processing multiple transactions in parallel and making nodes responsible for a single shard at a time instead of the entire blockchain, greatly reducing hardware and storage requirements.

Imagine the blockchain infrastructure as a large city in which citizens (nodes) and marketplaces (dApps) are distributed over a vast space. To exchange information (transactions) and access marketplaces, citizens have to move around the city, but if they walk the same streets or enter the same marketplaces, very long queues are created.

To speed things up, the structure of the big city is divided into districts to include in the same space the citizens and markets they interact with most. This means that some parts we interact with are rarely available in our district, but we can always get out of one district and do business in another. The important thing is that there is a record of all the events happening in the big city somewhere. This is made possible by the distribution of the consensus algorithm.

In a nutshell, this is how sharding works for blockchain. But what happens to security?

If the integrity of a blockchain is based on the concatenation of information, organized over time into blocks through a hash mechanism and guaranteed by the distributed consensus algorithm (Proof-of-Work), can splitting the chain (Sharding) compromise this system and make the blockchain less secure?

Yes, we are heading straight toward Buterin's Trilemma: scalability, security and decentralization on the vertices of a triangle that prevents a single solution from finding the "best" value for each of the three elements simultaneously.

Sharding therefore improves blockchain scalability but threatens security. The game is to find an appropriate balance.

Back to our example: the blockchain is a large city divided into districts (shards) and full of citizens (nodes) and marketplaces (dApps). In this situation, who is responsible for the information flowing within the districts? And who verifies the accuracy of the information traveling from one district to another?

Leave information theory (IT) to those who like black screens and green text, let's take a more practical approach here.

To ensure the integrity of exchanged information, citizens periodically elect, from a set of eligible candidates, a high-level government, composed of so-called validators, to oversee the operations of all individual districts and keep track of the status of the big city. The high-level government then elects low-level governments for each district.

Only the high-level government will store and verify the correctness of every piece of information exchanged within the big city, while the low-level governments will only deal with their own district's information.

Unfortunately, our big city is not safe from "corruption."

What happens if one district tries to bribe another and take over? To avoid this unfortunate but real scenario, validators elect low-level governments periodically and randomly, so that each government cannot know in advance which district it will govern and who its colleagues will be.

This solution offers good scalability and, because of its multilevel control structure, improves the degree of security compared to a single-government solution.

According to the principles of Buterin's Trilemma, if scalability and security increase, decentralization will inevitably decrease. If we consider a traditional Proof-of-Work-based blockchain, in which all nodes compete with each other, with Sharding only a subset of nodes will compete for validation, reducing the decentralization of the entire ecosystem.

What about Quadrans?

In the Quadrans 2.0 Yellow Paper, sharding was explored and used as a means to increase infrastructure scalability.

You can check out the Quasdrans yellow paper here?https://quadrans.io/documentation

Transactions exchanged by actors in the P2P network are divided into shards based on the addresses of the senders. Specifically, a defined part of the addresses (the first N bytes) is used as a grouping key to divide M addresses into N different shards, where the respective transactions will be processed.

The Quadrans network will support two types of control entities:

Miners, similar to low-level governors, are responsible for validating blocks within a single shard-chain (district) using the Proof-of-Work mechanism.

Masternodes, similar to high-level governors, are in charge of controlling the work of Miners, electing them and adding information within the master-chain.

A node may be eligible for a Miner or Masternode role based on the capital (QDTs) it keeps locked in its portfolio: a Miner needs only 1k QDTs, while a Masternode has at least 100k.

Both Miners and Masternodes are rewarded with new Quadrans Coins (QDCs) in proportion to their role and contribution to the network.

Transactions stored and protected by Miners in each shard are collected and validated by Masternodes in each block, compressed into a compact data structure called Merkle-Tree, and added to the master-chain.

Maintaining consistency on all updates and transactions exchanged within shards is a challenging task. But with its multi-level control structure and appropriate consensus mechanisms, Quadrans strives to achieve a trade-off between scalability, security, and decentralization.