In my previous post, I discussed the difference between blockchain technology and distributed ledger technology. If you haven’t read it yet, I recommend you do so before reading this post. It’s a quick read with a simple analogy to help you understand it.

The post seemed to help a lot of people, and I was immediately bombarded with more questions. This was a great sign. I often say that the first step to understanding something deeply is knowing what follow up questions to ask. One of the prevailing questions I received was:

“What makes blockchain technology so special? Why is it different from traditional databases?”

This is an important question. Many people will answer that question with words like “decentralization”  and “trustless". But there are many who still struggle to fully understand the magnitude of this development.

In this post, I’ll use an analogy/story to help us understand and appreciate the technology and revolution that is unfolding before our eyes - Here's Blockchain Explained Simply!

Blockchain - A Trustless System?

The first blockchain system was introduced to us in 2008 – right after the financial crisis in the United States of America. The Financial Crisis comprised of devastating losses.

Homes were lost. Jobs were lost. Money was lost – a lot of money. A total household wealth of 19.2 trillion dollars was estimated to be lost. These were innocent people who had put their trust in the government and financial institutions.Innocent people who had no say in the matter paid heavy prices for the mistakes of others.

The crisis highlighted a need for a system where people did not have to trust a “middle man” with their wealth.

That’s where the idea of “decentralization” steps in. Let’s break down the word: Decentralization

Essentially, we want to move to a system away from middle men. A system where we don’t have to put our “trust” in a middle man - A TRUSTLESS system. And that’s exactly what a blockchain can give us – a trustless, decentralized system.

No, I am saying that you don’t have to trust it. And your wealth (or information) will still be protected. To fully wrap our minds around this, let’s go into story mode:

The Village Story – An Analogy for Blockchain

Let’s say we go back in time – way before technology existed. No phones, electronic devices etc.

There exists a village that comprises of around 10 families. They farm, hunt, gather etc – and they trade their goods with each other.

The hunter would give the farmer some meat. And in return the farmer would give the hunter some rice. This worked fine. But every now and then, they’d have to make a promise:

Farmer
“Hey man, I don’t have any rice yet, but if you give me some meat, I promise to give you the rice when I harvest it”

​The Hunter was fine with this since he trusted the Farmer. But overtime, there were more and more promises being made. It became really hard to track all of these “promises”. Soon people were disputing over promises forgotten or never made. This halted trades and brought the village economy to a slow.  So the village got together to figure out a solution to this problem.

They decided to appoint someone to track these promises in a ledger.  Let’s call him LedgerMan.

LedgerMan got to work, and began tracking promises. This worked really well, and the trades were moving smoothly again. Farmers & Hunters would meet with the LedgerMan, and consolidate their payments according to the ledger.

As the ledger filled up with “promises”, LedgerMan was becoming increasingly more pivotal in the Village economy. The entire village was placing their trust in him. One day...

LedgerMan
“Hey, since I’m spending all my time tracking these promises – I think it’s fair I receive a small fee for every promise I track.”

This would mean that the villagers would be losing some of their profits on each trade. They weren’t too happy about this, but figured it was fair. But as time passed, LedgerMan accumulated a lot of wealth & power. 

• He took bribes to append the ledger
• He bribed villagers to keep appointed as the ledger-keeper
• Increased fees unfairly

Soon, disgruntled villagers started voicing their anger. This resulted in in-fighting and chaos within the village. Finally, Mr. LedgerMan was ousted. But the village realized that appointing a new ledger-keeper would do no good. So much power & trust in one person is bound to corrupt.

They liked the ledger idea to keep track of “promises”, but they needed a new way of doing things. So they got together and brainstormed for a solution. One of the smart villagers came up with an idea.

Smart Village Citizen
“Instead of only one of us holding on to a ledger, why don’t ALL of us keep a ledger”

Villagers from each family would meet at the village-square at certain times of the day.  Trades would be conducted, and every promise made was tracked in everyones ledger.

Every week, they’d meet at the village square for a “Validation Meeting”.  Each villager would read out their version of the ledger from start to end.

If there were no discrepancies, then it meant that everyone had the same agreement on the ledger. They had come to consensus. All new entries were validated and added to the ledger successfully. However, there would be occasions were entries between ledgers did not match. For example,

Villager John could have a promised tracked as:  
Farmer Pete owes John 10 bags of rice

But Villager Pete could have the entry tracked as:  
Farmer Pete owes John 5 bags of rice

So which promise is the correct promise? Who should we trust? Pete or John?

This is where the the “trustless” aspect of the method comes into play. The villagers didn't need to trust either of them.

They would resolve the issue by simply cross-checking with all the other ledgers.  The promise with the majority entries across all ledgers would be selected as the “correct promise”.

Once the majority promise is decided, the villagers all update their ledger accordingly.

"The Village-Square System" -Key Takeaways

This was brilliant. The system – let’s call it  the “Village-Square System” – was able to remove the need for a middle-man. They were able to:

• “DE-CENTRALIZE” THE LEDGER FROM A SINGLE PERSON
• CREATE A TRUSTLESS SYSTEM
• ELIMINATE FEES & KEEP PROFITS

Note: After a series of break-ins & tampering, they realized they had to add security measures to keep their ledger safely protected as well

As you can see, this system is effective – but quite tedious. But since the village was small – consisting of only 10 families, this was doable.

But as time passed and the village grew into a city. And they faced a new problem: The Villager's Trilemma. The system was not feasible anymore. It was just too much work. Eventually they would gravitate back to middle-men in order to keep track of their ledger - There was just no way to implement the Village-Square method in a scalable way.  

Until 2008, when Satoshi Nakamoto released the Bitcoin Whitepaper. Satoshi used an innovative combination of

1. Traditional Ledger System
2. Computers Distributed Around The World
3. Cryptography to enforce security

He was able to implement a more sophisticated implementation of the VIllage-Square to achieve a trustless, decentralized & secure system that would keep track of transactions with minimal effort from human beings.

Sharding is an initiative to tackle the scalability issues that Ethereum faces. All blockchains are limited by their architecture & design. How? Because every node in the blockchain processes every single transaction. While this enforces a high degree of security/reliability (explained in this post), it also limits the scalability.

Sharding improves the scalability of the Ethereum blockchain by splitting the network into smaller “groups/pieces”.

Remember from our post on Consensus Methods, that consensus or “agreement” is achieved by a majority agreeing on the state of the ledger.

Remember that if we SHARD in PoW, we are breaking up the network into "pieces". Hence, to achieve a “majority” hashpower in a particular shard would suddenly become feasible (since each shard will have only a “piece” of the total hash power”)

Proof Of Stake

Proof Of Stake – along with this structure – allows Ethereum to do something that it cannot do (easily) in PoW. And that is the ability conduct “random-sampling”.

Since Super-Nodes are depositing their Ether, we can use that to randomly assign them to a shard. The assignments are reshuffled regularly as well.

This will ensure that attackers:

Comparing a Blockchain to a DLT  is like comparing an Apple to a Fruit. An Apple IS A Fruit.  Similarly, a Blockchain IS A DLT (Distributed Ledger Technology)

I've also received questions on whether or not the Bitcoin blockchain and distributed ledger technology have anything in common. Let's use another analogy to answer this question.

The Bitcoin Blockchain and Distributed Ledger Technology synonymous to "Google" and "Search Engine". Google is a specific type of Search Engine.  Similarly,  the Bitcoin blockchain is a specific type of distributed ledger technology.  

 Bitcoin IS a Distributed Ledger Technology (DLT). 

Remember, in the previous section we discussed how a blockchain is a sub-category of a DLT. There are many types of DLTs; and blockchains are only one of them. Similarly, there are many types of blockchains; and the bitcoin blockchain is just one of them. 

What is a DLT?

So what exactly is a DLT ?  Again, I will attempt to make this as easy to understand as possible.  A DLT – Distributed Ledger Technology – simply distributes information to multiple computers. These computers could be spread across the world. The primary aim is to reduce the risk of central storage.

Distributed Ledger Technology is the umbrella term to describe any system that distributes data across multiple sites. There are several types of DLTs.

A Blockchain is a type of DLT that organises its data in a “chain of blocks”. Each block encompasses a bunch of data that is verified & validated and then chained to the next block. Hence the term “blockchain”.  This data  – in the form of chained “blocks” – is distributed to everyone in the network.

That’s how a Blockchain type of DLT is typically implemented. Other DLT types may choose to implement differently. Radix, Corda and IOTA are all different types of implementations of DLTs. None of which are Blockchains.

This is another frequently asked question: Blockchain vs Databases – what's the difference? Technically, Databases are used within a Blockchain system. So a comparison between a Blockchain VS Databases is akin to  a comparison between Heart and a Body. The heart lies within the body; and is a core part of the system. Similarly, databases are used within the Blockchain system.

Remember, DLTs are simply databases that are distributed across multiple sites. And Blockchains are simply a type of Distributed Ledger Technology.  So essentially, a blockchain comprises of structured databases – that are distributed.

Blockchain vs Distributed Databases

This is where things get tricky.  If a Blockchain is simply a system of distributed databases, then what's the difference between a Blockchain and a Distributed Database? This really boils down to the interpretation of a "Blockchain". 

The first Blockchain system was introduced in 2008, and its goal was to escape the shackles of centralisation. Usually, when people talk about  Blockchain technology, they are referring to a distributed system with no central control. However, when they talk about  Distributed Databases, they are referring to high powered distributed systems that have a central authority. 

To sum it up, a Distributed Database has a central authority that requires trust; while a Blockchain is typically a trustless system that has no central authority 

Can we have a system that has sufficient number of “professors” (nodes) to still maintain the security –  while being small enough to increase the speed at which your assignments are returned (throughput of the network)?

Ethereum Sharding - Structure

Okay, so I may have oversimplified a tiny bit. But now that you understand the gist, you’ll understand this part a lot easier.

In each shard/group, we have nodes that are assigned as “Collators”.  Collators are tasked with gathering mini-descriptions of transactions & the current state of the shard.

In our analogy, you can think of Collators as Teacher’s Assistants. All the TA’s in shard/group do the first run through of all the assignments within the shard.

Finally, we have super-nodes. Each super-node receives the collations created by the collators of each shard. They then processes the transactions within those collations. Furthermore, they maintain the full-description/state data of all the shards – which they get from the collators as well.

You can probably see the benefits of this structure. The number of nodes that process every single transaction would be greatly reduced, and thus increase overall throughput.