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

How Are Blockchain Transactions Validated?

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!?”

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

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.

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.

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”

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)

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.

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.

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.

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.

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)

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

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.

Conclusion​

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.

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.