Sharding — why does blockchain need it? - DapCash

Sharding — why does blockchain need it?

Sharding is a solution for the problem of blockchain scalability

Before talking about sharding, it is worth noting essential circumstance. Any fast-growing blockchain sooner or later faces the problem of scalability. The decentralization and security of blockchain are ensured by reaching a consensus between nodes and storing all the blockchain data in each node. Just imagine what a huge amount of data is growing every day, like a snowball! That is why it is not surprising that transactions speed is the chief casualty. And the Bitcoin blockchain shows it. One of the most effective ways to solve this problem is sharding.

How sharding can help

Sharding is one way to solve the problem of blockchain scalability. The essence of this technology is that a database is divided into separate small parts (shards), which are stored on different servers (nodes).

And there are some problems.

*Firstly, nodes need to know where the shards are stored so that there is no data overlapping or data loss. To do this, the nodes have to exchange information about the shards they store.

*The second problem is that the data inside the shards should be consistent with each other, as well as with the global blockchain.

*And third. Although shards are stored on different nodes, their data should not conflict with the data of the entire blockchain.

All these network operations have to ensure the exchange of data about the shards between the nodes and the validation of data both within the shards themselves and in relation to the global blockchain. Therefore, it requires non-trivial solutions from blockchain developers.
The introduction of sharding was announced by Ethereum at the end of 2017. However, it has not yet been implemented.

Sharding mechanism in DapCash

In contrast with other blockchains, the developers of DapCash thought out the problem of blockchain scalability already at the stage of designing the blockchain platform. So, sharding in the project is implemented as follows:

1) At the so-called “zero” level, there is the main blockchain (Golden chain). It is responsible for the exchange of messages between the nodes that store shards, for maintaining the global state of the network, and for coordination of the sharding mechanism. In the Golden blockchain, transactions and user data are not stored. In other words, this chain is fundamental to maintain all the blockchain architecture. The golden blockchain is the topmost level for all other consensuses.

2) At the next level, there is a silver blockchain (Silver chain), which begins sharding. Silver blockchain is divided into shards. Each shard stores transactions and the state of a single client/user. Thus, a user doesn’t have to store the entire blockchain. The user can store only the shard that comprises information related to him/her — transactions, messages, smart contracts, states, etc. All transactions of the same client are always in the same shard.
Communication between nodes storing shards is carried out through the consensus of the golden blockchain.

3) In the subsequent levels, sharded chains can also exist. You can store unlimited amounts of data in them. In addition, you can create your own blockchains — independent shards with own consensus and token.

In other words, the shard in DapCash blockchain is something like a “shitcoin” which has a gateway to the main network. Tokens issued and bought at the token sale can “flow” into other blockchain networks. The tokens obtained at the sale automatically become the coins of a new shard (shitcoins). And such a shitcoin is immediately traded on the internal exchange. With the help of sharding, you can organize your own (private) blockchains, issue your own «shitcoins»

A similar sharding mechanism is announced only at TON yet. As for DapCash, sharding is developed independently. To sum up, sharded blockchains designed for different purposes — it is, in fact, the substitute of Ethereum’s forks.

Оставьте комментарий

Your email address will not be published. Required fields are marked *

en_USEN