In this post, Krisha explains the 2 Types of Blockchains - Public vs Permissioned Blockchains

We have witnessed the term “blockchain” evolve from something dark and unknown, to the hottest topic on the block. While many are drawn to the ‘Investment’ opportunities that the technology presents, others have latched onto the efficiencies that blockchain promises.

This disparity in interests has prompted questions on the multiple types of blockchains available. Questions like, 'Which type of blockchain would best serve an individual's or company’s interests?"

However, when broken down simply, you’ll realize that there’s only one pivotal difference between each of these blockchain types: 

The need for Permission to participate in each of them.

In essence, every blockchain can be categorized under one of these 2 types:
​Public (Permissionless) Blockchain
​Permissioned Blockchain

A Blockchain's Consensus Mechanism allows participants to come to agreement on a truth that the network was intended to acertain.

The context of “permission” in blockchain lies within this Consensus mechanism.

Depending on the type of blockchain, an individual or entity may or may not require permission to participate in the consensus process.

A Little Perspective - The blockchain consensus mechanism is akin to a jury in a case trial. A jury reaches consensus on the final verdict - they agree on the truth. Consensus is as crucial a function to blockchain, as it is to a case trial.

Randy asked a great question in regard to The Longest Chain Rule & Forks. Over the last few posts, we’ve established that Consensus Methods are not as worried about “verifying” transaction but are more concerned with the “ordering” of transaction. When a fork occurs – we have a dispute in the correct ordering. The Longest Chain Rule kicks in and will fix that dispute for us. Awesome! Hope that is clear. If not, I suggest you read through the posts linked above!

Ah, this is such a great question!  Because it brings us one step closer to understanding the 51% Attack and Double Spends.

Cassidy is concerned about losing her BTC – and understandably so.  She’s always trusted the bitcoin blockchain, but now I’m telling her that her transaction may end up on an “orphaned chain”.  

Orphaned Blocks - The Key is in your Wallet....

A common misconception is that people tend to believe that their BTC or ETH is stored “within” their Wallet.  So, when they send a transaction – there is a belief that they are taking out some BTC (or ETH) and putting it in someone else’s wallet.

This is completely untrue.  But I don’t blame people for thinking that way. The term “wallet” is probably what confuses people. The term “wallet” was probably used to help user adoption, but it’s made explaining the technology even more difficult.

Your Bitcoin or Ethereum Wallet is not like your traditional wallet. It does not hold any of your funds.  

Don’t think of your Wallet as something that holds your BTC or ETH – but more so as something that holds the keys to access your funds.

Your keys allow you to say to the blockchain, “I have the right to spend these funds”

In the previous post I explained the Longest Chain Rule using an analogy. The analogy seemed to help several of the Mango Readers grasp the importance the rule plays. If you haven’t read it yet, I urge you to do so. The Longest Chain Rule plays a vital role in the Bitcoin and Ethereum consensus mechanism. Furthermore, it may also clear out other doubts you may have concerning Blockchain Forks.

This brings me to a question I received from Randy yesterday:

“Hey man,
Great explanation on longest chain!  
Quick question:  
" Why do we have 'Forks' if we have the Longest Chain Rule? 
Is the longest chain rule applied during a 'fork' ? "
​Cheers! - Randy “

Quick Answer:  Yes, the Longest Chain Rule will kick in when forks appear. Each fork will have its own chain and miners can pick which one to apply their work on. But eventually the longer of the chains will be declared the winner – and all miners will apply their work onto that chain.

That’s the quick and dirty answer. But I’d like to dive a bit deeper into this – and run you guys through exactly how this happens.

Why? Because understanding the Longest Chain Rule will be fundamental in allowing you to grasp other ideas (for example: 51% Attack).  In fact, once you grasp this idea – most of the other concepts will become super easy and intuitive.

Longest Chain & Blockchain Forks

But what exactly is a “fork” ? 
A fork is simply an occurence of a disagreement. Remember, the primary aim of a consensus model is “ordering of events”.  

Questions that fall under “ordering of events” criteria:  
Q) “Who gets to place the next block?”
Q)“Whose transaction gets verified first?”

Going back to the Farmer Analogy – the fork was simply the two rows that were placed at the townhall.  Up until the disagreement, everything was fine and dandy. Once the disagreement occurred – two rows were laid. Each row represented a decision. Villagers will vote by placing their sacks of rice in each of the two rows and the longer of the two rows will win.

It’s a similar process in a blockchain. Initially, everything is fine & dandy – and there’s only one “main chain”.  When a disagreement occurs, the chain splits into two. This is called a “fork”.

(It’s kinda like when you’re driving down the main road and it “forks” into two different paths. You have to now choose between two paths. In the blockchain, the mainchain splits into two –  and the miners now choose between two chains.)

But why do disagreements occur? Isn’t proof of work supposed to solve that?  

Why Do Blockchain Forks Occur ?

The Proof Of Work Consensus model is designed to allow the network come to agreement. So forks like this shouldn’t happen, right?

If you read my post on the PoW Cryptographic Puzzle, you know that miners compete against each other to win the right to place the next block.

The “winner” is the miner who solves the puzzles first. The rest of the network then “agrees’ that he gets to place the next block – and they will continue the process with his block being deemed the last approved/valid block.

Let’s say the last valid block is Block A. Miners are now competing fo Block B.  Miners will attempt to solve the puzzle until they hear a winner is declared. “

However, ever so often – we may have two “winners” simultaneously.

Since, the winner is broadcasted and propagated through the network  – different participants may hear a different winner. Once a winner is declared and “heard”, the miners accept that winning block and move on to the next block. 

So now we may have one group of miners accepting Block B, and the rest of the miners accepting Block B2. Hence, fork…

One of the most popular Consensus Methods used today is Proof Of Work. As I write this post, Bitcoin and Ethereum both still use the Proof Of Work consensus method.  Ethereum is set to switch to Proof Of Stake in it’s upcoming Casper update. However, the first iteration of this update will be a hybrid of PoW & PoS. Bitcoin will continue to use Proof Of Work for the foreseeable future. 

Regardless of the consensus method used,
Bitcoin & Ethereum are still blockchains. And such, both networks rely on the Longest Chain Rule when coming to consensus.

In this post, I’ll attempt to dive a little bit deeper into The Longest Chain Rule while still keeping things as simple as possible 🙂

In the previous post of this Proof Of Work series, we discussed how PoW is used to determine representation of the majority. Determining the majority is one of the keys in being able to come to consensus (or agreement) on decisions. But in order to determine the majority, Proof Of Work uses Cryptographic Puzzles (or Proof of Work Puzzles)  – making them just as important.

But how does this Proof Of Work puzzle work? What kind of puzzle is this? I get these questions a lot. Usually in different forms. 

But the general gist of the question is this:
“What exactly is the Proof Of Work Puzzle? What’s the point?”

In this post, I’ll attempt to explain the proof of work puzzle simply. We’ll also discuss its significant importance in Proof Of Work as a Consensus Method.

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.

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.

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. 

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)