Picture yourself sitting in a big auditorium writing an exam with 500 other people. Let’s say there are 50 proctors in total monitoring and grading the exams. Imagine each one of those 500 exams had to be graded by all 50 proctors and your exam grade was the average of all of the scores. Could you imagine how long it would take to grade all the exams? It’s not a scalable or feasible method by any means and it only gets more difficult as the number of students writing exams increases. This is similar to the challenges faced by the Ethereum Blockchain as it becomes more popular and heavily used for transactions.

Now, imagine that instead of all 50 proctors having to grade 500 exams, the responsibility was now broken up into sections. Each proctor was responsible for grading 10 exams only and the grade that each proctor assessed was the final grade for each one of the 10 students. If the proctor was unsure of how a specific question should be graded, the individual would consult with other proctors for more information before grading.

In a nutshell, this is the current problem with the Ethereum blockchain and how Sharding can solve the scalability issue to allow for increased transaction speed and wider adoption. 

The Problem:

The Ethereum blockchain currently requires all nodes on the network to store and process all transactions taking place. In other words, the problem with the Ethereum blockchain is that it requires full nodes. Although this process provides relatively greater security as every transaction must be processed by every single node, this is a very intensive and non-scalable method that is currently being revamped by the Ethereum development community.

The greater the number of full nodes, the slower and less scalable the blockchain becomes.

In its current form, the Ethereum blockchain must choose to satisfy two of the three attributes below in a proficient manner:

  1. Security
  2. Scalability
  3. Decentralization

The current state of the Ethereum blockchain strongly complies with the 1st and 3rd attributes but sacrifices a lot when it comes to scalability. Times have changed and scalability is a real threat to mass adoption, so the Ethereum developer community has decided that the right decision here is to sacrifice a bit of security. Then they can proficiently scale the blockchain by increasing transaction speed.

The Solution: Sharding

Imagine that Ethereum has been split into thousands of islands. Each island can do its own thing. Each of the islands has its own unique features and everyone belonging on that island i.e., the accounts, can interact with each other AND they can freely indulge in all its features. If they want to contact other islands, they will have to use some sort of protocol. – Vitalik Buterin

Sharding, in the traditional sense, is a type of partitioning that separates large databases into faster, smaller parts called shards. A shard by definition is just a small part of something whole.

How it relates to the Ethereum blockchain is a very convoluted and technical concept. This article heavily simplifies the concept but you can dig deeper into the technology here. It involves splitting the network into many tiny partitions called shards, and each shard contains independent pieces of transaction data. What the Ethereum community is trying to achieve with the Sharding implementation is to move away from the full node requirement. Sharding will take place exclusively on the protocol layer.

With the implementation of Sharding, this problem can be resolved by having each node store a subset of data and be responsible for verifying those particular set of transactions, instead of all transactions sequentially taking place on the blockchain due to the non-parallelizable nature of the Ethereum Virtual Machine (EVM).

When a specific node requires information that is not stored in its own block, it will find the other node that has the information it requires. This is the premise behind cross-shard communication.

Currently, the Ethereum blockchain allows for 8 transactions per second (TPS) whereas, Sharding would allow for thousands of TPS without the need for full nodes, which would drastically reduce the overall node size as well. However, the process is not trustless as nodes are dependent rather than independent. This is the security sacrifice that is required in order to increase scalability.

Why Proof-of-Stake is Critical for Sharding

That being said, the security flaw is only inherent if Ethereum continues utilizing a Proof-of-Work consensus mechanism. Since PoW relies on hash power, and there needs to be a way to discourage bad actors from manipulating the network with a majority of the hash power, given that transaction data is now in shards or smaller pieces. In other words, the possibility of a network attack increases given that the hash power to compromise a given shard is drastically lower than the power necessary to compromise the entire network.

On a PoW-based blockchain without Sharding, a ‘51% Attack’ is almost unfeasible due to the hash power required and total cost, which would be in the billions. A bad actor would need 51% of the total network hash power to attack the network and control a majority vote.

On a PoW-based blockchain with Sharding, the possibility of a 51% attack is feasible and poses a greater threat to overall network security.  A bad actor or group of bad actors could concentrate their hash power on a single shard and take complete control of that shard. The bad actor could then use cross-shard communication to attack other shards on the network.

This is where Proof-of-Stake proves critical to ensuring a complete EVM that is secure, decentralized, and scalable. PoS would allow Ethereum to remove an attacker’s ability to concentrate hash power on a single shard, through the effective use of random sampling. A Proof-of-Stake based system would eliminate the ‘51% Attack’ security vulnerability that would otherwise be present if Sharding were implemented under a Proof-of-Work based system.

Under a PoS-based blockchain with Sharding, potential attackers are unable to choose the shard they want to work on and will not know which shard they will be assigned in advance, thus mitigating the inherent security risk with Sharding implementation.

If you have any questions about Sharding, please feel free to comment below and let us know.