About the author

Shawn Dexter

Shawn is a blockchain & distributed ledger technology enthusiast with a strong background in Computer Science, Product Management and Entrepreneurship.

Proof Of Work: Determining Majority “Power”

As discussed in a previous post, one of the primary goals for a Consensus Method is to facilitate “agreement” on the network. To come to agreement we need a majority of votes. However, determining this majority may not be as easy as you may think.

The difficulty in achieving Consensus in a networked system is actually a fundamental problem in Computer Science. There are various technical reasons for this. But we’re going to keep it simple in this post. 

We will tackle one particular difficulty that may seem easy on first glance:
"How Do We Determine Who Represents The Majority?"

Let’s take a step back for a moment. Let’s think about how majority decision making is done in the “real” world.

Consensus In A Boardroom Office

Agreement is usually settled by the “rule of the majority”, right? We’d sit in a big boardroom office, and everyone (who matters) would vote by either a ballot-system or raising their hands.

It’s pretty hard to cheat. (You could try to raise two hands, I suppose. But you’ll probably be found out)

But this boardroom clearly represents a centralized system. How do we achieve this in a decentralized system - like a blockchain? Such a system has the following features:

  • People Distributed Around The World
  • People Are Pseudo-Anonymous – Using Their Computers To “Vote”

In the office boardroom, the majority is represented by people raising their hands. We need a way to determine the majority in a networked & decentralized system. Essentially, we need a way for people to vote in such a system – and to do so fairly.

Consensus Online:  IP Addresses?

The first idea that comes to mind is : IP Addresses.  Each IP address could represents one vote. Not bad – but it won’t work.  It’s far too easy for someone create millions of Virtual IPs. A single person could spin-up several IPs around the world and cast a million votes to further his own agenda. 

Proof of Work - a simplified example

Suppose we have a network of 1000 participants. Each of them are allowed one vote per IP Address. The participants have to come to a decision between Decision A and Decision B.

999 participants vote for Decision A.  But John – a network participant – wants Decision B for his own agenda. He decides to create 1000 Virtual IPs and casts votes for Decision B from each one of them. The network now thinks it has a total of 2000 participants.

  • Decision A gets 999 votes.  Decision B gets 1001 votes. (1000 fake votes + John’s real vote

  • Decision B goes through. John wins, everybody else loses.

Consensus Online: CPU Power

The “One-IP-One-Vote” solution was simply not going to cut it. It was far too easy for people to manipulate the votes  – and also face no consequence for doing so. Even failed attempts could be brushed off. We needed the following:

  1. Add a difficulty to casting vote
  2. Make it costly for attempting manipulation

That’s where Proof Of Work stepped in as a Consensus Method - Proof Of Work uses CPU Power to determine the majority decision.

In order to show their support, participants have to expend electricity. (They do so using by solving Cryptographic puzzles – which we will discuss in the this post. For now, all you need to know is that they have to expend energy in order to show who they support)

Therefore, the only way someone could manipulate the “votes” is by  having a A LOT of CPU Power. Achieving this will cost them A LOT in:

  1. Initial hardware costs 
  2. Ongoing electricity costs.

Longest Chain: Determining Majority Support

Note: I explain the Longest Chain using a simple analogy in a post here: The Longest Chain - A Simple Farmer's Analogy

This gives us another interesting (and important) feature. Each time a “block” is added to the blockchain, CPU Power/energy is  consumed. Thus, every block preceding it also involved consumption of energy. These are essentially a “chain of blocks” (hence ‘blockchain’). These “chain of blocks” are representative of the TOTAL energy used for that chain.  

  • Remember, energy consumption is a form of indicating “support” by network participants.  So the longer the chain, the more support the chain has by the network participants.

With this, if there is ever a conflict of decision – we can simply look at the Longest Chain to determine which decision has majority support. Why? Because the longest chain has the most energy invested in it. And hence the most support.

Wrapping Up - Proof of Work

Just like any other system, decision conflict needs to be resolved by a majority vote. However, determining that majority can be difficult when dealing with a networked system. Proof Of Work adds a extrinsic cost to each vote (hardware and electricity).  And thus making it increasingly difficult to manipulate the votes.

Energy is expended to show support on each “block” of data added to the ledger. As the ledger (blockchain) increases in size, more energy is expended. The longest chain serves as representation of the majority support.

In future posts I’ll go into a little bit more detail on the Cryptographic Puzzle and The Longest Chain. For now, I hope this post helps.

If you have any questions, don’t hesitate to shoot me an email or PM 🙂

Further Readings:

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 >

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?

  • check
    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)
  • check
    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!?”

  • check
    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.
  • check
    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 >

1% Shard Attack Explained – Ethereum Sharding (Contd..)

By Shawn Dexter / March 11, 2018

In a previous post I discuss why Ethereum prefers PoS over PoW to combat the 1% Shard Attack.  In this post I will go into a little bit more detail.

Fair warning:  This post may get a little technical. I am going to be intentionally redundant to drive my point through.

Recall that in PoW computational puzzles are solved in order to come to “agreement” on the ledger. This “agreement” is what forms the “consensus” of the blockchain. These computational puzzles require a lot of processing power. Hence, network participants have to consume electricity to come to agreement on the ledger.

This is key to note:
In PoW, participants have to put up an extrinsic cost (electricity & hardware ) to propose an agreement on a new state of the ledger

PoW: Is A 51% Attack A Feasible?

The extrinsic cost of a participant – electricity – is referred to as “Hash Power

A “51% Attack” can be executed when an attacker has a majority of the total hash power of the network. This attack will allow a participant to double spend, claim all rewards, censor transactions etc.

Note: I will break down 51% Attack in another post. It’s not what people usually think it is.

However, having 51% (or more) of the hash power of the ENTIRE network would require a lot of electricity & hardware. Currently the cost of a 51% on the Bitcoin network is:

  • $8 Billion US in hardware costs & $12.8 Million US  Per Day in electricity costs (source)

As you can see, it’s far too expensive/infeasible for an attacker to achieve this. (Furthermore, even if a participant achieves this, he’d be far more profitable if he performs the role of a “good actor”. More on this in my 51% Attack post)

PoW Sharded: Is a 1% Attack Feasible?

Alright, so now we understand how a 51% attack is infeasible in Proof Of Work (if not, don’t hesitate to email me. I understand that this can get confusing). But what if the network is split into groups/pieces (as is done in Sharding)?  

Let’s consider a blockchain network that is split into a hundred pieces (Hundred shards)

If the entire network has 100% of the hash power
then each of the 100 shards will have 1% of the hash power  

Q. But what if an attacker has even 1% control of the total network hash power? 

He can essentially concentrate his hash power on a single shard. Since each shard is responsible for 1% of the network, the attacker attains 100% control of the shard (Shard = 1% of network. Attacker = 1% of network)


PoW vs PoW Sharded

  • In an unsharded PoW system, a bad-actor  would need 51% of the hash-power to win majority vote and attack the network.
  • In a sharded PoW system of 100 shards, he only needs 1% of the hash-power to attack the network.

If an attacker achieves 1% of the entire networks hash power, he can effectively achieve 100% of the hash power of a single shard.  With that he can completely control a single shard.

Proof Of Stake allows Ethereum to easily & effectively (by using random-sampling) take away the attacker’s ability to concentrate his hash power on the shard of his choosing. Thus eliminating the 1% Attack vulnerability.

Get my upcoming eBook for Free!

"The Mango Guide TO Understanding Blockchain"

Offer Valid For FIRST 500 registrations only

Continue reading >

Blockchain Explained Simply – An Easy Analogy

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 eyesHere'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

  • “DE”: latin for “Away from”
  • “CENTRAL” is simply a fancier way of saying “Middle

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.

  • “Woah, so you’re saying I can’t trust the blockchain?”

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:

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

“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:


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.

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:


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 >

Radix DLT – The Future Of Crypto?

By Shawn Dexter / February 7, 2018

Mango Research has repeatedly stated that 2018 will be the year of scalability and mass adoption. And Radix DLT seems to be leading the charge in both of these aspects.

The world is beginning to take notice of the potential of blockchain technology. Enterprises and governments want to take advantage of what distributed ledger technology and its token economics can offer.  However, Bitcoin and Ethereum – the two mainstream giants – are currently both plagued with scalability issues. Other solutions that purport scalability, like dPoS, do so at the cost of security and increased centralization. Furthermore, with the instability of prices – vendors/merchants are extremely unlikely to fully adopt current solutions.

We fiercely need a technology that allows for transactional speed & scalability while still being secure and efficient. We need all of these criteria to be fulfilled. Enter Radix DLT.

radix dlt

Even though Radix is yet to be launched – Mango Research strongly believes that there is no other technology that tackles scalability and adoption in the way Radix will.  Radix DLT has been in development for 7 years. Unlike most upcoming projects, they have a working product that will be ready for launch soon. There is a wealth of knowledge available on their website: RadixDLT.com. However, in this post we will highlight some of the major reasons why we think Radix DLT will lead 2018/19 in the upcoming crypto revolution.

Here Are 5 Reasons Why Radix DLT Could Be A Game Changer

Reason 1: Radix DLT Scales... Linearly! 

One of the major limitations of current blockchain solutions is the fact that every node must process every transaction in the network. This severely prohibits scalability. As a result, most blockchain consensus models have to make the tradeoff between throughput and decentralisation. 

Radix, however, achieves high throughput, scalability and security using its patented consensus model – Tempo (a more detailed post on Tempo soon). Furthermore, Radix DLT has linear scalability. This means that the more nodes added to the network, the more it will scale. Contrary to current solutions, each node that is added increases the throughput of the Radix network.

In their most recent tests, Radix averaged  20162 transactions per second (t/s) with only ~10 nodes. This is a massive improvement compared to existing solutions. Ethereum currently peaks at 7 transactions per second and Bitcoin peaks at 5 transactions per second! You can view the live tests yourself. 

Reason 2: Debit Cards that work on EXISTING PoS

In order to achieve mass adoption, we will need more merchants to accept crypto currencies at their Point of Sale devices. Existing solutions do not provide a true decentralized & independent form of payment solutions for merchants. They are reliant on partnerships with existing payment providers (such as Visa) to conduct the transaction.

If Visa pulls out of the partnership, the solution breaks. We are already seeing  cases of partnerships failing with Visa. Radix, however, allows for debit cards that are completely independent of any payment provider. In fact, anyone can make a Radix debit card at home with ease and low cost! (check out the video below)

Furthermore, most of the current solutions in blockchain require merchants to adopt new hardware. Radix, however, can be enabled on the standard everyday Point Of Sale solutions that merchants currently use! These features reduce the friction to adoption drastically! Combine this with the Radix’s stable-value feature (see next point) and we have a win-win solution for merchants!

Radix uses a standard EMV Card to broadcast transactions to the Radix Public Network (or your bank).  The transaction is then verified & validated on the Radix Network just like any other transaction would be! It’s as simple as that – and already working! Here is a video demonstration of it in action:

Notice how the video shows how easy it is for anyone to obtain these cards and load them with Radix! Also notice how this video was published almost a year ago!

Reason 3: ‘Relatively’ Stable Value - But Unlimited Growth

One of the major reasons that merchants/vendors hesitate to adopt cryptocurrencies is due to the extreme volatility. Radix, however, safeguards price stability of its token while still giving token holders massive upside as adoption grows.

Radix DLT will safeguard against violent price swings using an elastic-supply. Traditional tokens have violent swings in price. But the Radix cryptocurrency will remain stable. Instead, its supply will fluctuate. So, when demand of Radix increases – instead of your Radix token increasing in value, you will be supplied with more Radix tokens. When demand decreases, Radix will decrease supply of the overall tokens. (Don't worry, tokens will not be removed from holder wallets. A more detailed post on the economics will follow)

This will allow for mass adoption since Vendors won’t have to worry about their Radix tokens decreasing in value after an item has been paid for.

A brief post on the economic model will follow this post soon. For further reading, look up the Quantity Theory Of Money which gives more insight into an elastic supply.

Reason 4: Low Barrier To Entry & Fairness

Unlike mining Bitcoin, the Radix network will allow even resource-restricted devices to participate as nodes in the network. A node on Radix can be run on a device with as little as 16MB ram and a 100Mhz processor. This will further ensure the ideology of decentralization.

Furthermore, the Radix network ensures inclusivity and trustless collaboration between/of nodes. It rewards nodes fairly by distributing rewards based on resource availability of each node. This means that everyone can run a node on the radix network and will receive rewards fairly.

Reason 5: Smart Contracts - Scrypto!

Radix is already Smart Contract enabled. Developers build dApps using Scrypto – a decentralized application development language by Radix.

Scrypto is based on JavaScript/TypeScript – so the learning curve is almost non-existent. Furthermore, it has its own debugging tools and can be used on existing IDEs for JavaScript.  Essentially – if you know JavaScript, you are ready to develop applications on Radix!


Radix DLT is an all-in-one platform solution. It has a decentralized exchange and the ability to create your own tokens/assets. Furthermore, developers have the ability to create turing complete decentralized applications on-top of the Radix platform. With its limitless scalability and adoption-value, Radix is poised to be a leader in the industry.

This post was a brief overview on what Radix DLT has to offer. In upcoming posts, I will dive deeper into their Consensus & Economic models! Stay tuned!

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 4 of 5
Join us on Telegram!