Samson Mow & Vitalik Buterin / Ethereum #Supplygate / $6 billion locked in DeFi …

One million Korean got blockchain driving licenses, Steem vs Tron, Bitcoin broke $12K…

Aug 19 · 3 min read

Learn about Bitcoin dollar-cost averaging through RoundlyX in 30 seconds.

And don’t forget to use the “CoinCodeCappromo code to get $4 in BTC.

Latest News 📰

Podcasts 💽

Good Reads 📑


The picture says it all 📷

Get published on Coinmonks

If you like to write educational articles on crypto/blockchain space and wanna get published on Coinmonks publication. Just mail me at or DM me Twitter

“If you like to read Coinmonks, You can donate us too.

Get Best Software Deals Directly In Your Inbox

Image for post

Image for postImage for post

Sharding: The brain of Ethereum 2.0
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.

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.

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:

  1. Decentralization
  2. Security
  3. 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.

Before going further, let’s understand a 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.

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:

Beacon Chain: Heart of Ethereum 2.0
Ethereum 1.0 went live in the year 2015. At the time of writing this article, it uses the classic Proof-of-Work (Same as Bitcoin). Ethreum introduced turning complete smart contracts to blockchains.

What are Smart Contracts?

Smart Contracts are programs on Blockchain that can be triggered from outside of the blockchain and capable of storing data (Limited) and change the state of the EVM.

These smart contracts enable Dapps like CryptoKitties, LocalEthereum, and many more.

However, all these Dapps face scalability problems because of Blockchain limitations. PoW made it really hard to scale the Dapps to a larger audience.

The best example is the popularity of CryptoKitties. In 2017, as more and more people flocked to the platform to get the cryptokitties, it congested the whole Ethereum network and the transaction fees went to the $20.

This highlighted the shortcoming of the current network. Therefore, in the year 2016, Vitalik proposed the idea of shifting from Proof-of-Work to Proof-of-Stake.

This initiated the Ethereum 2.0 phase christened as Serenity. Serenity is all set to be released in different phases.

Before going further, let us try to get a generalized idea of Proof-of-Stake (PoS).

In PoS, a user will stake his/her asset as a security deposit to take part in the consensus protocol.

These people are called validators responsible for forming the blocks ( In PoW, miners were responsible for forming the blocks).

A validator is selected randomly to propose the next block. The block is then verified (through voting) by the rest of the validators. After the block is verified, it will be broadcasted in the network.

Examples of some of the well known PoS protocols include Delegated Proof-of-Stake, Byzantine Fault Tolerance Type Proof-of-Stake, and many more.

Ethereum proof of stake is called Casper.

  1. Elimination of energy-consuming hardware
  2. Reduce chances of 51% attack
  3. Increase the scalability of the network

Beacon Chain is the heart of Ethereum 2.0. It is the base upon which the rest components like Shard, eWasm, and cross-link will be built.

It (PoS based chain) will run parallelly with the Mainnet (PoW based chain). Beacon chain is mainly made for the validators.

To become a validator, a node has to deposit (stake) 32 Ether to a smart contract in the Ethereum Mainnet.

The amount is locked, and the contract will produce a log entry (a Merkle hash), which is proof to your stake.

It is like a gate pass to the Beacon chain. After that, you are made as an “active” validator and have earned the right to take part in the validation processes.

The node will be allowed to become the part of the validator committee, who will vote for the validity of blocks. A committee consists of 120 randomly selected validators.

Each committee will be responsible for a Shard (Think of it as a segment of Ethereum Network).

Just like hearts have heartbeats, Beacon has slots. Each slot is around 16 seconds.

In this time-frame, a validator (called proposer) is selected randomly. The rest of the validators in the committee becomes attestors.

The role of the proposer is to collect a group of transactions to form a block. The attestors will attest(vote/vouch) for the validity of the block.

After the block validation, it will be added to the shard. 32 slots collectively form one epoch.

One should keep note that the number of transactions that can be included in a block is proportional to the stake deposited by the validator.

For example, Alice has staked 38 ETH and if she is selected as the proposer, she will be allowed only a limited amount of transactions to include in the block.

Now, Bob has staked 200 ETH. If he is selected as a proposer, he will be allowed to include a lot more transactions than Alice.

After the block is validated and broadcasted, the proposer receives an incentive along with the transaction fees. According to Vitalik, the return in staking can vary from 2.2% to 6%.

What if a Validator selects an invalid transaction? In that case, the attesters will find it invalid and won’t vouch for it.

As a result, the proposer will lose a portion of the stake for malicious practice, this is called Slashing.

When slashed, a Validator may also lose a portion of his stake (called quadratic leak) if he/she is offline for a very long time.

If the staking amount falls below 16ETH, the validator will be removed from the Beacon Chain.

Any person in a sound mind won’t try to trick the network as it will result in his own monetary loss. So to make the best out of the staking, a validator has to be actively involved in the righteous practices.

At the initial stage, the Beacon chain won’t have smart contracts and EVM. There is nothing much one can do with just the heart. But this is the best for the formation and functioning of other body parts.

To interact with the beacon chain, you will need a Beacon Chain Client. You can use Geth, Parity, or Pantheon to run Beacon Chain Client on your machine.