All posts in " Explained "

How Are Blockchain Transactions Validated? Consensus VS Validation

By Shawn Dexter / March 22, 2018

In this post Shawn answers the question: How Are Blockchain Transactions Validated?  He also explains what is Blockchain Validator – and the key difference between Consensus and Blockchain Validation.

How Are Blockchain Transactions Validated?

After my last post on Ethereum Proof Of Stake & Sharding, I received several follow up questions. Many of them could be summarised to one simple question: How Are Blockchain Transactions Validated? Is it done via the Consensus Method? Or does a Blockchain Validator Do It?

As discussed in previous posts, “consensus” is a key aspect in blockchain. It’s imperative that all participants in the network come to an agreement on the state of the ledger.

But what exactly are we trying to achieve consensus on? Are we simply trying to agree that each transaction is “valid”? Or is it more than that?  I believe that this is where a lot of people steer the wrong way.

Blockchain Validators

A Blockchain Validator is someone who is responsible for verifying transactions within a blockchain. In the Bitcoin Blockchain, any participant can be a blockchain validator by running a full-node.  However,  the  primary incentive to run a full node is that it increases security. Unfortunately, since this is an intangible incentive, it is not enough to prompt someone to run a full node.  As such, Blockchain Validators comprise primarily of miners and mining pools that run full nodes.

Blockchain Validation Explained

Blockchain Validation vs Blockchain Consensus

It’s important to note that “validation” and “consensus” aren’t the same thing. A Blockchain Validator performs validation by verifying that  transactions are legal (not malicious, double spends etc).

However, Consensus involves determining the ordering of events in the blockchain – and coming to agreement on that order. 

Essentially, Consensus involves agreeing on the ordering of of validated transactions. 

The validation precedes the Consensus. We may very well have something that is “valid” that the network does not “agree” upon. How? Let’s go over an example.

Validation Without Consensus

How Are Blockchain Transactions Validated?

  • Each time a transaction is made, it’s broadcasted to the entire network. Upon hearing the broadcasts, miners take a bunch of transactions, validate that they are “legitimate” – and put them into a block. (More on how in another post)
  • But miners “hear” about different transactions at different times (due to latency issues etc). Furthermore, they may simply choose different transactions to include in their block based on transaction fees. So essentially, each miner is building his own block. His block may be completely different from the rest of the miners in the network.

At this point, you’re probably thinking:
“What the hell? Everyone is building different blocks? Then how will we agree upon a single common ledger!?”

  • And that’s one of the beautiful things about the protocol.  Miners don’t need to build the same global block. They can each build their own block – consisting of entirely different transactions. And the participants will come to “consensus” on which block is included next.
  • A miner may have a block consisting of completely valid transactions, but his block may still fail to achieve consensus by the network. If someone else is picked, he will simply create a new block and try again.

Let’s run through a simplified example of two miners with different blocks.

A Simple Bitcoin Transaction Example

Miner Bob &  Miner Joe

Let’s say Bob and Joe are two miners on our network. Neither of them are up to any mischief. They are listening to the network and creating blocks with only valid transactions that have not already been spent.

  • Miner Bob creates a block consisting of “Transaction A , Transaction B, Transaction C”
  • Miner Joe creates a block consisting of “Transaction Z, Transaction Y, Transaction B”

Both of these blocks consist of valid transactions. Great. But we still need to come to “consensus” on who’s block to include onto the chain. Remember, a reward is given out to whoever gets to add their block to the chain. So should Bob get it? Or should Joe? How about both of them?

Adding both of them would be ideal, right? They both get rewards. And all the transactions get included onto the chain. Everybody wins! - But wait...Note that they both contain “Transaction B” in their blocks.

  • Let’s suppose that Transaction B is - “Alice pays 10 bitcoin to Jennifer” 

If we let Joe and Bob both include their blocks, Alice will end up paying Jennifer 20 bitcoins (two transactions of 10 btc each) when she intended to pay her only 10!  Furthermore, Alice may only have 10 bitcoin - so the second payment would be invalid.

As you can see, we can add only one of the blocks. And we need to agree upon which one. But how do we do that? 
This is where consensus methods like “Proof Of Work” or “Proof Of Stake” comes into play - Enter Consensus Methods

Using Proof of Work (PoW) for Picking Blocks

Miner Bob and Miner Joe both want their blocks included in the chain – they both want the reward. But only one of them can be picked. To “win” the right to include their block, they go through a consensus process – usually either “Proof Of Work” or “Proof Of Stake”

  • In Proof Of Work, Miner Bob and Miner Joe compete against each other to solve a cryptographic puzzle. Whoever solves it first, gets to add their block to the chain.

Food for thought: What if they solve it at the same time - or around the same time? That’s how a ‘fork’ can occur. And the bitcoin protocol resolves these occurrences as well. More on that later

Using Proof Of Stake (PoS) for Picking Blocks

Proof Of Stake involves Bob and Joe putting up their coins into a “jar”.  A coin is randomly picked from the jar. If it belongs to Bob, Bob gets to add his block. If it belongs to Joe, Joe gets to add his block instead.

Once the block is added, the process repeats. Both miners will listen to the network for pending transactions and create a new block. The competition goes on and on.

(Don’t worry, miners aren’t trying to solve the PoW puzzles themselves. Their computers are doing most of the work) 😉

Wrapping Up - Blockchain Validators vs Miners

As you can see, Consensus methods are primarily concerned with coming to an agreement on the ordering of events/transactions (and who gets to add them). Validation of the transactions is initially handled by the miner before they are added to the block.  And then once more by the rest of the Blockchain Validators when a block winner is picked. The miners add the block, and the Blockchain Validators verify that the block is valid. If Consensus is reached, then the network successfully moves on to the next block. (More on that in future posts)

Get my upcoming eBook for Free!

"The Mango Guide TO Understanding Blockchain"

Offer Valid For FIRST 500 registrations only

No menu items have been found.
Continue reading >

Will Price Of Ethereum Drop when ETH Scales?

By Shawn Dexter / March 22, 2018

Will Scalability Suppress The Price Of Ethereum?

In my previous posts, I discussed Ethereum Sharding & Scalability. Several of you have been following the series and have asked me some intriguing questions.

A question that has come up multiple times is:  
​“Will Ethereum’s Scalability lead to a reduced “scarcity” and thus suppress the price of Ether?”

It’s a fair question, since scalability will lead to reduced operations/transaction costs. And that’s precisely what creates the demand for Ether. But the answer isn’t as intuitive as most would think.

  • In fact, it’s a case of Jevon’s Paradox - where it’s assumed that technological improvements that lead to efficient use of a product will result in reduced use of the product. But in truth, the assumption turns out to be wrong and the opposite is true.​

Ether’s Scalability, Scarcity & Price

On one hand you’d think that Ethereum scaling should increase the price. After all, scalability is a good thing, right?

But on the other hand, scalability will lead to lower transaction fees. Since transaction costs are paid for in Ether – wouldn’t Ether be consumed less? And hence needed less? Therefore, is it fair to assume that the demand for Ether will decline because we’d need less of it?

Finally, if less Ether is needed for operation costs on the network, would the “scarcity” of Ether reduce? (leading to price suppression)

So which is it? Will scalability lead to a price up or price down?

Jevon’s Paradox - Coal & Steam,  Ether & Gas

English Economist William Jevons observed this paradox during the era of coal-fired steam engines.

"It is a confusion of ideas to suppose that the economical use of fuel is equivalent to diminished consumption. The very contrary is the truth"

He’s essentially saying: People assume that technological improvements that lead to efficient usage of fuel will in turn lead to reduced usage of fuel. But the opposite is true

Ether & Jevon’s Paradox:  The Rebound

Yes, transaction fees will decrease as the Ethereum network achieves scalability. However, this does not mean that the price of Ether will decrease as well.

As we scale into mass adoption, Ether will be used for various operations across a wide range of diverse industries. With this, the consumption of Ether will rise in response to lower prices. Eventually, we will reach a point of “rebound” where the gains in efficiency are overcome by the rise in consumption.

  • So, Instead of looking at it as: “Less Ether will be required for each operation, so demand will reduce” 
  • We should, perhaps, look at it this way: “Each Ether will now allow us to do THAT much more, so demand will increase”

There are several examples of technological advances increasing the efficiency and availability while prices have still gone up. 

A perfect example is the price of fuel for your car (gas)
Technology has made fuel far more efficient. We consume it more efficiently, and we find it more efficiently too. But the demand for fuel has only gone up with time.

Ether & Scarcity: To Infinity And Beyond

Finally, let’s understand what Scarcity really is - People tend to believe that scarcity is defined by the item/resource, but in truth, it’s defined by us humans and our needs.

  • Scarcity is a phenomenon of human’s infinite “wants” when the resource is finite.

And we live in a digital age where the “want” to conduct transactions/operations as efficiently as possible is fast approaching “infinite”.

As the cost of each operation on the Ethereum network reduces, humans will “want” to use the network more and more. But, Ethereum at any given point of time, is finite in number. (setting aside the minor inflation, of course)

  • As you can see, the decreasing transaction fees leads to increased scarcity.

Note: There’s a difference between a “shortage” and “scarcity”. Shortages are caused by rising prices, while scarcity results from falling prices.

As the cost of operations & transactions approach zero, our need to conduct those transactions will approach infinity. Hence, demand should go up, not down.

Did you enjoy this post?

Help Us Keep Doing What We Do Best!

Tip Jar 🙂​​


ETH: 0x87ba0C08910Dbd3b93D74A2A3b61d78A3C2dbDab

Get my upcoming eBook for Free!

"The Mango Guide TO Understanding Blockchain"

Offer Valid For FIRST 500 registrations only

Continue reading >

Blockchain Trilemma – The Village’s Impossible Trinity

By Shawn Dexter / March 12, 2018

Blockchain Scalability Trilemma - In the Village Analogy post, we ran through a scenario where the people of the village got frustrated with the corrupt man who kept track of their trades. The villagers eventually got rid of him and moved to a system where they used multiple diaries (ledgers) to keep track of the trades. This enabled them to:

  • Prevent A Middle-Man From Holding All The Power (Decentralization)
  • ​​​​Detect incorrect entries & fraud  (Security) 

The Village Began To Grow - A Scalability Crisis

However, as the village began to grow, they found it difficult to keep up with the system.

Maintaining the Security of the ledger was a tedious and time-consuming task.  It was essential that they cross-check & validate the ledgers properly. Any shortcuts would lead to security-vulnerabilities. Eventually, the village grew into a city, and they simply could not keep up with the task of maintaining the ledger anymore.

Essentially, the village wasn’t able to take their system and Scale it in preparation for the growth of the city.

In order to scale, the villagers had to alter their solution. They were wary of having a single middle-man due to their past experience with Mr.Ledger. So they appointed a group of individuals to maintain the ledger and keep a check on each other.

The Ultimate Sacrifice

They moved from having a “Middle Man” to having “Middle Men”.  Sure – it wasn’t as bad as having a single man in control. But they had still sacrificed their decentralization. They now had:

  • Ability to detect incorrect entries (Security)
  • Ability to cater to larger and larger cities (Scalability)

They had come to accept the fact that a sacrifice must be made. They were stuck in a Trilemma. They cannot have all three of the following:

  • Security
  • Scalability
  • Decentralization

These three factors are the essence of the blockchain Trilemma.

Vitalik Buterin calls it the “Scalability trilemma”. Perhaps because blockchains  inherently started off with the following: SecurityDecentralization

The question then became:  
“In order to add scalability to my blockchain – what should I sacrifice? Should I sacrifice Decentralization? Or should I sacrifice Security?”

Food for thought: Wouldn’t that then make it a dilemma? Hmm...
(Note: A dilemma is when you have to make a choice between two options. A Trilemma is when you have to make a choice between three options)


As things stand, blockchain solutions are struggling the find the right balance balance to the trilemma.  Vitalik Buterin proposes Sharding to theoretically break the trilemma. I explain Sharding (using another analogy) in a previous post. It’s an ingenious solution – but still has some form of sacrifice. 

Other blockchain solutions that have high scalability have done so by sacrificing decentralization. EOS is a notable example that uses Delegated Proof Of Stake. This is essentially much like appointing (delegating) a group of individuals to manage the ledger – much like our village analogy.

Finally, other solutions like Radix, HashGraph and IOTA are not blockchains. They do not have the architectural limitations that blockchains do.

Did you enjoy this post?

Help Us Keep Doing What We Do Best!

Tip Jar 🙂​​


ETH: 0x87ba0C08910Dbd3b93D74A2A3b61d78A3C2dbDab

Get my upcoming eBook for Free!

"The Mango Guide TO Understanding Blockchain"

Offer Valid For FIRST 500 registrations only

Continue reading >

Why PoS was Necessary for Ethereum’s Sharding

By Shawn Dexter / February 28, 2018

In a previous post, I provided a simple explanation on Ethereum’s Sharding. I also mentioned how Sharding was one of the driving factors for Ethereum’s switch to Proof of Stake consensus model.

In this post, I will provide a brief & simple explanation on why Proof Of Work was not the ideal choice for Sharding, and how Proof Of Stake tackles the problems posed by Sharding a blockchain.

Why Shard To Begin With?

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”.

What’s wrong with PoW?

The Ethereum blockchain currently runs on a Proof Of Work consensus algorithm.

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

Proof of Work essentially relies on hash-power to validate the chain. Blockchain is a trustless system, so we need to dis-incentivise people from being a bad actor. As explained, a bad actor would have to have a majority of the hash-power to manipulate the network. That’s a lot of hash-power. The electricity bill & hardware costs will be monumentally expensive.

Hence, in Proof of Work, the hash-power expense makes it cost-prohibitive to be an attacker.

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”)

Compared to attacking the network, each shard will require only a fraction of the hash-power. An attack is no longer cost-prohibitive.

In fact, if you split the network into 100 pieces, you only need 1% of the total hash-power to takeover a shard. To keep this post simple, I explain how in another post

Validators can collude their hashpower on a single shard, and takeover control of that shard. One way to prevent this attack is to prevent attackers from focussing their hash-power onto a single shard.

However, this is difficult/not-possible to do so in a Proof Of Work protocol. In PoW you cannot stop miners from applying their work on a given shard - This is where Proof Of Stake steps in!

Proof Of Stake

PoS removes the extrinsic cost of validating the chain: hash power/electricity costs. Here's how:

In, Proof Of Stake  super-nodes are required to “deposit” (stake) their Ether in order to perform validation functions. Again, remember that:

  • COLLATORS (TEACHERS-ASSISTANTS): Gather mini-descriptions of transactions & the current state of the shard – and send it up to the node validators.
  • SUPER NODES (PROFESSORS):  Collect the data from the Collators. Process the transactions & Validate the blocks.

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:

  • Cannot choose the Shard they want to work on.
    We don’t want them to pick their shard because a small group of attackers can target a single shard to dominate it. Even attackers with a small total-stake can focus their efforts and attack.
  • Cannot know what shard they will work on ahead of time. 
    If we don’t reshuffle, an attacker may have enough time to find the other people who have been assigned to his shard. This will allow him to collude with them and attack the shard. We reshuffle regularly to avoid this.Super Nodes are randomly assigned a shard. Not knowing which shard they are assigned to before hand, will prevent them from attacking the system.

Wrapping Up

As you can see, Proof Of Stake makes random-sampling pretty trivial. Sampled validators are reshuffled regularly.

A quote from Vitalik on my previous post:

 It's really important to mention that validators are super-frequently reshuffled between shards (possibly even once per block), so it's actually quite hard to "target" one specific shard for an attack. This is a large part of where sharding's at least theoretical success in breaking the trilemma comes from.
Vitalik Buterin

When Vitalik mentions “breaking the trilemma”, he is talking about how typically only 2 out of 3 of the following can be achieved in blockchain:
  • Security
  • Scalability
  • Decentralization

PoS allows for easy sampling & reshuffling which ensures the “Security” of the trilemma – while the sharding structure gives us a level of Scalability and Decentralization. Hence, theoretically breaking the blockchain trilemma. This is a huge feat!

Did you enjoy this post?

Help Us Keep Doing What We Do Best!

Tip Jar 🙂​​


ETH: 0x87ba0C08910Dbd3b93D74A2A3b61d78A3C2dbDab

Get my upcoming eBook for Free!

"The Mango Guide TO Understanding Blockchain"

Offer Valid For FIRST 500 registrations only

Continue reading >

Blockchain vs DLT (Distributed Ledger Technology)

By Shawn Dexter / February 20, 2018

DLT vs Blockchain:  In this post Shawn uses a simple analogy to explain the difference between a blockchain and distributed ledger technology (DLT) . He also discusses the difference between blockchain and other technologies – like blockchain vs tangle, and blockchain vs databases. 

Blockchain And DLT - Is there A Difference?

In a previous post, we discussed Radix DLT – a potential game-changer in the DLT world. While many of our readers were excited for what Radix promises, there were some who requested some clarity on DLTs (Distributed Ledger Technology) . One of the prevailing questions I received was:

 “What is the difference between a Blockchain and DLT?”

Blockchain vs DLT:   Apples vs Fruit

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)

Difference between blockchain and DLT
DLT vs blockchain

The confusion, probably, arises because most of us were introduced to the term “Blockchain” before “Distributed Ledger Technology”. The sudden surge of popularity had the term “Blockchain” turn into a generic term.

But in fact, Blockchains are a TYPE of  DLT.  Much like an Apple is a TYPE of Fruit.

So, is DLT a blockchain ?

No. All DLTs are NOT Blockchains. But all Blockchains are DLTs

Most of the cryptocurrencies, that we know, are blockchain implementations. All of them are DLTs. Bitcoin, Ethereum, Litecoin etc are all DLTs. What kind of DLT? Blockchains.

However, not all the cryptocurrencies are blockchain implementations. Radix, IOTA and R3 Corda are examples of DLTs that are NOT blockchains.

distributed ledger technology and blockchain vs iota

Bitcoin Blockchain And DLT -  An Analogy

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.

What is A DLT?
A DLT (distributed ledger technology) is simply a fancy way of saying,
 “A database that is spread  across several sites“

  • “How” that data is distributed, structured and agreed upon (consensus) will dictate the TYPE of DLT. Kind of like how the shape, taste, colour etc dictates the TYPE of Fruit (to us non-fruit experts, at least)

Al blockchains are DLTs.
 But not all DLTs are Blockchains

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.

Blockchain vs Databases

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 

Conclusion - DLT vs Blockchain

The key takeaway from this post is: “All blockchains are DLTs. But not all DLTs are Blockchains”. A blockchain is a specific type of DLT. Bitcoin paved the way for public DLTs. But as the market and technology matures, we will see more implementations of DLTs to satisfy the markets ever-changing demands.

Did you enjoy this post?

Help Us Keep Doing What We Do Best!

Tip Jar 🙂​​


ETH: 0x87ba0C08910Dbd3b93D74A2A3b61d78A3C2dbDab

Get my upcoming eBook for Free!

"The Mango Guide TO Understanding Blockchain"

Offer Valid For FIRST 500 registrations only

Continue reading >

Ethereum Sharding Explained Simply

By Shawn Dexter / February 14, 2018

Ethereum Sharding: The demand for scalability is becoming increasingly urgent. The Cryptokitties incident demonstrated how quickly the Ethereum network can clog-up. While  many in the community  are excited for Ethereum’s Sharding, there are just as many who struggle to understand how sharding will help Ethereum scale.

In this post, I will attempt to explain Ethereum’s sharding using a simple analogy.

Understanding The Problem

One of the major problems of a blockchain is that an increase in the number of nodes reduces it’s scalability. This may seem counterintuitive to some people. “More nodes = more power. So more speed, right?” Not exactly.

One of the reasons a blockchain has its level of security is because every single node must process every single transaction. This is like having your homework assignment checked by every single professor in the university. While this may ensure that your assignment is marked correctly, it will also take a really long time before you get your assignment back.

Ethereum faces a similar problem. The nodes are your professors. Each transaction is your assignment.

Sure, we can reduce the number of professors (nodes) until we are satisfied with the speed. But as the assignment (transaction) backlog increases, we will need to further decrease the number of professors. This will eventually lead us to rely on a few “trusted” group of professors. A centralized group.

This defeats the ideology of blockchain decentralization.  It’s much easier to compromise/corrupt a smaller group of professors (nodes) than the entire university (the entire network). As a result, we sacrifice security in an effort to scale.

To sum it up, blockchains must choose between Two of the Three following attributes:


This is also referred to as the Blockchain Trilemma. Sharding is an attempt to tackle this limitation

What is "Sharding"?

With the problem and limitations understood, we now pose a question:

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)?

Essentially, we are conceding that we can’t “max-out” on all three of the attributes: Scalability, Security, Decentralization.  But, can we have just “enough” decentralization & security so as to achieve more scalability?  

Sharding is Ethereum’s answer to this question.

Ethereum Sharding: Think of Sharding as simply a fancy way of saying, “let’s break down the network into smaller groups/pieces”.
  • Each group is a shard. A group/shard consists of nodes and transactions.

So in our professor analogy, a shard would consist of a group of professors and assignments. Now, instead of a professor having to correct the assignments across the entire network, he would be only responsible for the assignments within his shard(group).

This greatly reduces the number of transactions (assignments) each node (professor) has to validate.

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.


Sharding is a smart approach to tackling the blockchain scalability problem. However, it’s not without its drawbacks. Because of its structure, it’s easier to compromise a shard within the system.

This is one of the driving reasons behind Ethereum’s switch to Proof Of Stake. Proof Of Stake helps mitigate this security vulnerability that comes with Sharding. But for the sake of brevity,  we will discuss that in a future post.

Did you enjoy this post?

Help Us Keep Doing What We Do Best!

Tip Jar 🙂


ETH: 0x87ba0C08910Dbd3b93D74A2A3b61d78A3C2dbDab

Get my upcoming eBook for Free!

"The Mango Guide TO Understanding Blockchain"

Offer Valid For FIRST 500 registrations only

Continue reading >
Page 3 of 3