How does Sharding help the Ethereum Blockchain to carry out transactions efficiently?
The future technological implementations in the Cryptocurrency industry is focused more and more on scalability. Many cryptocurrencies has designed and shared their roadmaps to show the world that things are going to improve in the Cryptocurrency Blockchain network. When it comes to scalability Ethereum is no different than Bitcoin.
Ethereum is in its early stages and the Ethereum community is filled with some of the sharpest minds in tech industry. The technical team carries out countless innovations in an accelerating speed. In order to overcome scalability issue, the Ethereum community has come up with a two-fold solution. The first and the foremost approach to improve scaling is via off-chain solutions which is also known as layer-2 scaling. In the layer-2 scaling, the transactions are handled away the Blockchain and they sparingly interact with one another. The other approach is to modify the design of the protocol entirely and to fix the fundamental problems that is parallel to the problems that the Blockchain faces.
In the current state of Ethereum, the nodes compete independently to verify a single transaction against a monetary reward. Once the node has successfully validated a transaction, the other nodes verify that the information is correct. And then they update the blockchain and in the end, compete to validate the next transaction. The nodes that handle these transactions stores a record of all transactions in the blockchain. This includes every account balance, smart contracts and transactions.
When Ethereum starts thriving, this process will become increasingly inefficient. Segmentation will allow nodes and transactions to be split into smaller groups, meaning that more transactions can be checked at one time, and nodes only need to store certain segments of the blockchain. Prior to the implementation of Sharding, the Ethereum agreement must be upgraded to Casper, which is still in development.
What is Sharding?
Sharding is a process to increase the number of transactions that the Blockchain can handle. Multiple network computers are designed for “chaining”, which divides the transaction load between them, allowing multiple transactions over the same time period. The “chain” shares the trading burden between them, allowing more transactions to occur in the same time period.
Currently, each and every node running the Ethereum network must handle every transaction which goes through the network. This makes the blockchain very secure because of how much validation each block has, but at the same time it means that the entire blockchain can only be as fast as its individual nodes, not the sum of its parts. Currently, transactions on the EVM are not parallelizable, and each transaction is executed globally in order. Then, the scalability problem and the blockchain can have up to two of the following three attributes:
If a network is scalable and secure that means that the blockchain is centralized and a centralized blockchain is anyday faster than a decentralized blockchain. On the other hand it is very well known that Ethereum is decentralized and secure. So the biggest problem here is how to include optimum scalability in the current Ethereum model. A simple answer would be if the size of the block increases then scalability is attainable and in the case of Ethereum there isn’t a block-size rather Ethereum has a Gas Limit. Even if this theory can be deemed as a right approach. But increasing the gas limit will make mining centralized around the nodes which runs on supercomputer and in the end this would simple bring a higher barrier to enter into the system.
This is the reason why Blockchain Sharding is a smarter approach. In Sharding, the the developers split the entire state of the network is a bunch of proportional partitions called shards and these shards contain their own independent piece of state as well as transaction history. In a system like this, the selective nodes would only process the transactions for the certain shards and this allows the throughput of the processed transaction across all the shards.
There are a few components in the Ethereum network which will directly or indirectly get affected when Sharding is implemented:
State: State is the complete set of information which describes a system at a given point in time. State in Ethereum is the current account set which contains smart contract code, current balances, and nonces at a given moment. Every single transaction changes this state into a completely new state.
Receipt: It is a side-effect of a transaction which isn’t stored in the state of the system rather it is kept in a Merkle tree so that its existence can easily be verified to a node. The smart contracts logs in the Ethereum network are kept as receipts in the Merkle Trees.
Meekly Tree: Merkle tree is a data structure that stores a huge amount of data via the cryptographic hashes. With Merkle tree, it is easier to check a piece of the data part of the structure in a short span of time and with a very little computational effort.
Transaction: We know what a transaction is but in Ethereum, transaction is an operation which is issued by a user. The transaction is mainly responsible to change the state of a system.
Minor Changes in Ethereum 2.0:
In Ethereum 2.0, there will a creation of a sidechain called Random Beacon Chain which will store hashes to the main chain blocks in its own blocks. This side chain will be a complete Proof of Stake system that implements the Casper FFG and will provide a distributed randomness source that allows us to build a sharding system on it.
The problems with the Sharded Blockchains become more apparent than ever once the possibility on stacks on the network is considered. The major problem which follows is the idea of a Single-Shard Takeover Attack. In this kind of attack, an attacker take control over the majority of collators in a single shared in order to create a malicious shared that has got the possibility to submit invalid collations.
How to resolve this problem?
Sharding is exclusively going to exist at the protocol layer and it won’t be exposed to the developers. The Ethereum state system will continue to look the same way it does now but there will be a slight change, the protocol is going to have a built-in system which will create shards, balance state across shards and it will also get rid of shards which are way to small. Everything is going to be happen behind the scenes and this will allow the develops to continue their current workflow on Ethereum.
Super-Quadratic Sharding and the Incredible Speed
In order to transcend, Ethereum may adopt a super-secondary fragmentation scheme, in simple words this means a system that is built from the shards of shards. It’s hard to imagine this complexity at this point, but the potential for scalability is huge. In addition, the super-secondary blockchain will bring huge benefits to users, reducing transaction costs to negligible quantities and serving as a more versatile infrastructure for new applications.
At the most basic level, the proposed initial implementation does not work through hard forks, but rather a side chain called a random beacon chain that will serve as proof of the benefit + fragmentation system.
The beacon chain will manage the validator and its sampling from the global validator set and will be responsible for the global coordination of all shard states.