In our previous article, we talked about the Beacon chain. With the heart, you need memory to store information. That is where Sharding comes into the picture. Sharding is the memory center of Ethereum 2.0. Let’s have a discussion on the problem sharding is trying to solve.
DCS Triangle
An ideal blockchain is Decentralized, Consensus, and Scalable. But in reality, a Blockchain can not have all three at a time. There is always a trade-off of one or more features i.e. you can have any two features but not all three.
For example, Ethereum and Bitcoin are decentralized, consistent (consensus) but not scalable. Similarly, Hyperledger Fabric is consistent and scalable but not decentralized. It is visually represented using a DCS Triangle.
Scalability Trilemma
The Ethereum team has introduced a trilemma called Scalability Trilemma. According to this, a blockchain system can only, at most, have two of the following three properties:
- Decentralization
- Security
- Scalability
Currently, Ethereum can process 12–30 transactions per second. It is better than Bitcoin (which can process 7–10 transactions per second) but nowhere near Visa (which can handle about 1700 transactions per second).
Every node in Ethereum has to process the transactions taking place in the network. They also have to store the whole Ethereum blockchain (about 300 GB) on their computer. These are the reasons why Ethereum 1.0 is not suitable for micro-transactions and is suffering from scalability issues.
So, sharding is an attempt by Ethereum to beat the trilemmas by incorporating all three features without any trade-off.
From a database point of view, sharding is the process of partitioning a large database into smaller, manageable, scalable database fragments called data shards. It is like, instead of a single person taking charge of all tasks, the tasks are dividing among multiple persons. Let’s see how the sharding feature is implemented in Ethereum 2.0.
Sharding Implementation in Etheruem 2.0
Before going further, let’s understand few important terminologies here.
State: State, in general, is a set of information that describes a system at any point in time. In Ethereum, this is the current account set containing current balances, smart contract code in a given time. With each new transaction, the state changes.
Transaction: Operation issued by a user that changes the state of a system. It can e either transfer of ether or deploying a smart contract.
Merkle Tree: It is a data structure that can store a large amount of data via cryptographic hashes.
Receipt: It is an object generated from a transaction that is not stored in the state of the system, but is kept in a Merkle tree so that other nodes can easily verify its existence.
In sharding, the history and the state of the whole Ethereum blockchain are divided into individual partitions called shards. Each shard will have its state and a history of transactions.
As said by Vitalik, “An easy way to think of it is to imagine if Ethereum was split into thousands of islands. Each island can do its own thing, it can have its own features and every one belonging to that island can enjoy it. If they want to contact other islands, they will have to use some sort of protocol”.
Different Types of Nodes in Ethereum 2.0
- Super-full node -These nodes download the full data of the beacon chain
- Top-level node — These nodes process the beacon chain blocks only but do not download all the data of the shard blocks.
- Single-shard node — They act as a top-level node, but also fully downloads and verifies every collation on some specific shard that it cares more about.
- Light node — downloads and verifies the block headers of main chain blocks only; does not process any collation headers or transactions unless it needs to read some specific entry in the state of some specific shard in which case it downloads the Merkle branch to the most recent collation header for that shard and from there downloads the Merkle proof of the desired value in the state.
Also Read: Proof of Stake Explained
Shard Grouping
Now you must be wondering on what basis sharding will take place? One such scheme is to divide the shards based on the addresses.
For example, addresses starting with 0x0 will form one shard, addresses starting with 0x1 will form another shard, and so on.
For simple use cases, transactions can take place within a shard. Some advance use cases can be cross-shard transactions i.e. a transaction taking place from shard A to shard B. In such case, receipts are used as a verification tool.
Here is an example by Vitalik which explains the cross-shard communication
“if Bob has 50 coins on shard B, and Alice sends 20 coins to Bob from shard A, but shard B does not yet know the state of shard A and so cannot fully authenticate the transfer, Bob’s account state temporarily becomes ’70 coins if the transfer from Alice is genuine, else 50 coins.’ Clients that have the ability to authenticate shard A and shard B can be sure of the “finality” of the transfer (ie. the fact that Bob’s account state will eventually resolve to 70 coins once the transfer can be verified inside the chain) almost immediately, and so their wallets can simply act like Bob already has the 70 coins.”
From our earlier article on Beacon Chain, we know that there are validators who are responsible for producing blocks based on Proof-of-Stake. During each slot, a validator (proposer) will be selected randomly (through a RANDAO)for a specific shard.
After that, the validator will propose a block to be included in the shard. Along with him/her, 99 other validators (attesters) will attest to the block. The header of a block, together with at least 67 of the attesting signatures(votes), can be published as an object that gets included in the shard. Similarly in the second slot, another validator is selected randomly and the process continues.
For now, shards won’t support smart contracts. But with further advancement in EVM, smart contracts will also come into the picture of the shard. One of the biggest issues of sharding is Single-Shard Takeover Attack where a single attacker concentrates all his hashing power in a single shard to create a malicious shard. Ethereum proposes to overcome it through randomness. The second issue of sharding is fraud detection especially in case of cross-shard communication. In case someone finds an invalid block, there is no standard protocol to make other nodes aware of it for now.
Some useful links:
