About the author

Shawn Dexter

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

Settlement Finality in Blockchains: PoW vs PoS

By Shawn Dexter / August 6, 2018

In this post Shawn explains the concept of Settlement Finality in blockchains. He then goes over finality in proof of work and finality in proof of stake, resptively.

Settlement Finality

Settlement & Finality – often heard and often misunderstood. Newer blockchains boast about their speed to "finality". But does that really mean? What is Settlement Finality? 

Put simply – all transactions (daily transactions, security trades etc) have to be "settled" to be considered "final".  Hence, the term Settlement Finality.

In our daily transactions, settlement banks handle the 'finalisation' of our transactions. They are the middle-man. And we pay them for the privilege. However, a blockchain manages it's own settlement finality. It does not require a middle man. This is one of the reasons why blockchain technology is so revolutionary. 

Middle-men are used in the traditional systems to ensure that transactions have finality.  A blockchain, on the other hand, uses a consensus method like Proof of Work or Proof of Stake to reach finality.

But before we go any further, let's quickly describe what finality really means.

Settlement & Finality: What Is Finality?

Finality: Finality simply refers to the idea that the occurrence of event is “final” and “permanent”. You cannot undo this event – it has occurred, and will remain ‘occurred’

An Example: A simplified example of Finality would be your age. Once you turn 18, you’re an adult – and you will remain an adult forever. You can be certain in the ‘finality’ of that. No one can go back and change that event. (Unless time travel is possible, and they murder you before you’re 18)

However, achieving finality with financial transactions is actually easier said than done. We tend to equate "extremely difficult" to "impossible". 

To understand, let's explore settlement finality in blockchains and banks a bit more.

Settlement Finality: Blockchain vs Banks

In the finance, people & businesses want to be certain that their transactions are "settled & final". This  Settlement Finality is traditionally handled by settlement banks

Businesses – small or large – face issues with finality of payments quite often. A consumer can attempt to reverse his payment made via VISA or PayPal. In these scenarios, settlement finality conflicts are handled by the middleman.

However,  middleman-solutions are always going to be a point-of-weakness for finality. What if people in key positions are bribed?  What if  centralised servers are hacked? In a centralised solutions, there's always a chance that finality is reverted. Each intermediary will pose a risk point.

Comparatively, a blockchain uses no intermediary. It achieves finality via it's consensus method. Notable consensus methods are Proof Of Work and Proof of Stake. Both of which eliminate several weaknesses of centralised systems. However, neither of them achieve true finality. Finality will always be probabilistic (i.e there's a chance – however small – that a transaction can be reversed) 

First, let's go over finality in proof of stake and proof of work.

Settlement Finality: Proof of Work & Proof Of Stake

Finality in PoW and PoS are achieved in different ways. In Proof Of Work, the hash puzzle plays a key role in determining when a settlement is reasonably 'final'.  Proof of Stake uses a raffle system and economic incentives to arrive at finality (you could call it economic finality)

Finality in PoW

Finality in PoW is achieved as more and more blocks are created. It gets increasingly difficult to reverse a payment in the older blocks.

Blocks in Proof Of Work age well – the more hashpower used on future blocks, the more resilient the older blocks are to attacks. Why? Cause if someone wants to reverse a payment, he has start a new chain beginning at the old block. He has to then try to outpace the current chain. He will have to ensure that his chain is the longest chain.  The only way he can do this is by consuming A LOT of electricity.   This is why we wait for “Confirmations”. Each confirmation represents a block. Anything over 6 blocks gives us reasonable finality.

Finality in PoS

Casper’s Proof Of Stake uses a sorta raffle-system to facilitate finality (and other security elements too.)  People who want to validate blocks deposit their Ether into a pool. This pre-registering all the possible validators. Validators are then asked to declare finality at certain intervals. Essentially saying:  “I agree that every transaction/event up until this point is legit”. 

If at least, ⅔ of the validators make a claim – you have reasonable finality.

Notice how I said “reasonable finality” for both – Proof Of Work and Proof Of Stake. This is because finality is always going to be probabilistic!  To understand this, we have to dive a little deeper – but I’ll try to simplify.

Blockchain Settlement Finality is Probabilistic

I say "reasonable finality" because finality in proof of work and proof of stake are still not truly "final". Technically, a settled payment can still be reversed. It may be improbable – but not impossible. Let's go over some of the ways:

  • A 51% attack can lead to a reverse payment in Proof of Work  regardless of block age. While this is difficult, it’s not impossible – it’s improbable.  
  • In Proof Of Stake, we have the Nothing At Stake attackwhich again is improbable, but not impossible. (I explained Nothing At Stake just yesterday actually) Even with punitive penalties implemented - slashing - we have the improbable chance that a bunch of validators are willing to burn their own capital to hurt the network.

  • Finally, even our current centralized solutions don’t have  finality because they can always be hacked, burned down, gun-to-the-head etc etc. Perfect finality is probably impossible. There are too many external factors outside of the system that can remove finality.

Final Thoughts

No system is perfect – yet. A bank can be hacked. Proof of Work is subject to a 51% Attack. Proof Of Stake is subject a 1% Attack.  However, blockchains and distributed ledger technologies have come a long way in increasing the likeliness of finality.

Get my upcoming eBook for Free!

"The Mango Guide TO Understanding Blockchain"

Offer Valid For FIRST 500 registrations only

Continue reading >
Share

Nothing At Stake Problem – A Forkin’ Mess!

In this post Shawn explains the Nothing At Stake Problem simply. He goes over the nothing at stake definition, and also touches on nothing at stake Casper issue.

Barging into the bosses office and flipping him off may sometimes be too tempting to resist.  But we manage to refrain. Why? Cause we're incentivised against doing so. Usually, there are consequences – like losing your job. Bad behaviour usually has associated costs. Behave badly – lose something.

Sometimes, however, there are situations that allow you to act badly and lose… nothing. If the bad behaviour results in the most fruitful outcome, you’re most likely going to capitalize on it. This usually results from overlooked  incentivization models. In blockchain technology, The Nothing of Stake problem  is an example of an incentivization structure that allows someone misbehave – and get away with it.

 Nothing At Stake definition: –  a situation where someone loses nothing when behaving badly, but stands to gain everything.

Nothing At Stake Problem in PoS

When a fork occurs, the Consensus Method helps the network agree between the two chains. Participants have to choose which chain to follow, and the majority wins. Ideally, you want the Consensus Method to incentivize people to choose only one of the chains.

Kinda like you having your employees choose between this:  “Should I should I slap my boss across the face – or should I keep my job?”

You can’t have both.  You can’t act “badly” and have no costs. (Unless you have another job waiting for you, in which case – power to you!)

Proof Of Stake allows you to slap your boss and keep your job - You have nothing at stake.

Proof Of Stake: The Costs To Validate

In PoS, participants compete in a lottery to win the right to propose the next block. Each participant deposits tokens into a pool from which a “winner” is chosen. This deposit is the primary cost that a participant has to incur. All other costs are negligible.

The winner’s block is either accepted or rejected – and the process continues with the chain being extended on each “accepted” block.

Nothing_At_Stake(1)

Proof Of Stake:  A Fork In Mess 

However, things can get really messy if we run into a “Fork”.  A “fork” in the chain may occur if:

  • There’s a malicious attack  – an attempt to reverse a transaction
  • Two winners are chosen 

In both cases, two new blocks are proposed – and  hence we have a split in the chain:

Nothing_At_Stake(2)

Now, participants have to pick one of the two chains. The problem, however, is each participant can choose to follow both chains. Ideally, one chain will be picked:

Nothing_At_Stake(1)

Remember, the only real cost to a validator was his deposit. Since the chain forked, his deposit exists on both chains. So it costs him nothing more to validate on both chains. This allows him to collect transactions fees and rewards on both chains.

Nothing At Stake Problem: Best To Cheat

In fact, he is incentivised to follow both chains as his optimal strategy.

  • If he picks only one chain, he risks losing the transaction fees on the orphaned chain.
  • However, If he picks both chains, he simply has to wait for one of the chains to be picked as a winner – and he gets his rewards either way. 

When every validator picks the optimal strategy, we will end up with a chain like this: 

Nothing_At_Stake(4)

Why? Because we’d have 100% consensus on both chains. Everyone’s voting for both sides – so the chains extend at the same pace. At first glance, it may not seem like a big deal. But this compromises the security of the network drastically. A malicious actor can intentionally fork the chain, and get away with a double-spend. All he has to do is the following steps:

  1. Keeps validating on both chains as well.
  2. Wait for confirmation of the bad transaction. 
  3. Stop validating on the first chain.

This would tip the balance of the vote onto the other side of the chain – the one with his bad transaction.  Eventually, the second chain would outpace the original chain. The bad transaction will be officially accepted, and first chain will be orphaned.

Opportunity Cost 

The key point to notice is that the validator can follow both chains and have no opportunity cost.
For example, when you decide to quit your job for a new job, there's an opportunity cost. What if your boss was intending on promoting you? However, Proof Of Stake allows you to have two full-time jobs at no cost. If you don't get promoted in the first job – big deal. You have the second job that will promote you. You have Nothing at stake – no opportunity cost.

Being able to validate on both chains with no costs is like having two jobs.​
If the first chain gets orphaned, you still get all transaction fees & rewards from the second chain. In fact, if you pick only one chain you stand to lose your rewards & fees IF your chain gets orphaned. Hence, the optimal strategy is to pick both chains.

Nothing At Stake Problem: PoW vs PoS

Proof Of Work is not vulnerable to a Nothing At Stake problem. Why? Because , unlike PoS,  a participant has to use external costs to build blocks in Proof Of Work. An external cost forces participants to place his "bet" on one chain or the other. The external cost in Proof Of Work is the electricity/hash power used by the miner. 

To understand this better, we can go back to our Farmer's Analogy. Farmer's had to place their sacks of rice in one of the two rows. The more sacks they had, the more votes they got. The rice was their "external cost". They couldn't vote on both rows with all their sacks. They'd either have to split their sacks of rice or pick one row. The external factor of "rice" ensured that the village mayor didn't have to worry about the nothing at stake problem.

Similarly, In order to build blocks on a chain, he needs to place his electricity on the chain he believes in. To build blocks on both chains – he will have to split his electricity in two. He has an opportunity cost here. As he will not be using the full potential of his hash power on either chain. Since he is not building optimally on either chain, he will lose out on potential rewards. Regardless of which chain is eventually picked as a winner, he will have had some opportunity cost.

In Proof Of Stake a participant does not have any external costs to build blocks.

Remember: the only cost was the initial deposit. Because of this, he can place his bets on both chains. He can simply build blocks on both chains – and wait for a winner. Regardless of which chain wins, he comes out ahead – and no opportunity cost. He had nothing at stake.

Nothing At Stake & Casper: Hypothetical?

It's important to note that we are assuming that all participants act “optimally”.  The more likely scenario is that there will be some people who act honestly and reject the “bad chain”. That’s not to say, though, that the Nothing of Stake problem should be ignored. Even if a portion of validators acting selfishly, then attacking the network becomes easier.

But the great news is that the Casper team is not taking the nothing at stake problem lightly – be it a hypothetical problem or not. Ethereum Casper will include punitive measures like “Slashing” that addresses the Nothing At Stake problem. I will discuss and explain that in part 2 of this post!

Get my upcoming eBook for Free!

"The Mango Guide TO Understanding Blockchain"

Offer Valid For FIRST 500 registrations only

Continue reading >
Share

EIP-999 & Parity Drama Explained Simply

By Shawn Dexter / July 19, 2018

In this post Shawn explains the heated EIP-999 debate. He goes over how it happened and why the EIP-999 & Parity controversy is ruffling so many feathers.

Why Am I Writing This?

A cauldron of drama-soup is boiling in the kitchen – and most of us are too distracted to smell what’s cooking.   Either we're too busy refreshing Blockfolio or the EIP-999 drama has too much technical mumbo-jumbo for the new members. Well, the soup is being stirred again – and perhaps it’s time we pay attention.

As a community we need to have an open discussion about this. For that, though, we need to first understand what is going on. In this post I’ll try to explain the issue as simply as possible.

EIP-999  & Parity

What Happened? 

A somewhat comical incident led to a disastrous consequence.  An anonymous developer managed to gain ownership to a Smart Contract – and then killed it.

But this wasn’t just any smart contract. It was the underlying contract to Parity Technlogies’ Multi-Sig Wallet – which held 514,000 Ether.  That’s worth around $300,000,000.

Killing the smart contract resulted in 514,000 Ether being utterly inaccessible.

How Did It Happen?

Seems like Parity goofed up on auditing their smart contracts….

One of the contracts was left ‘uninitialized’. And a anon developer was able to simply take ownership by initializing it. Yeah... that simple.

He then went on to hit the self-destructo-button and killed it. Why? I’m not sure. He probably fumbled. It seems like an “oopsies!” moment. Either way, the contract is dead. Kaput! Gone. it was a disaster

All Parity Multi-Sig Wallets created after July 20th 2017 relied on that contract and without it – they can’t function. Funds in those wallets were effectively… burned?

Okay… So then what?

Around 600 wallets had their funds rendered inaccessible… indefinitely. Parity now have a lot of unhappy customers – some of which are big name ICOs.  (It’s important to note, however, that Parity haven’t lost any funds themselves.)

A solution was proposed a couple months ago: EIP-999. An EIP is simply an “Ethereum Improvement Proposal”. Put in simple terms, the proposal was:

“Let’s just simply restore the contract with a patch”

This patch would replace the self-destructed contract with a brand new contract. This new contract basically:

  • Allowed users to access their funds.
  • Contained a fix for the previous ‘bug’. (bug or..oversight?)

No big deal. Right? Ah… If it were only that simple... This where the EIP-999 debate started to boil...

EIP 999 Proposal  - Contentious?

Why the Drama?

The patch is simple – but the consequences are not. A code change like this will result in a hard-fork. A hard-fork isn’t necessarily a bad thing. In fact, the Metropolis upgrade was a hardfork and everything turned out fine.

It’s when we have a “contentious” hard-fork that things get really ugly. Why? Because a hard-fork requires miners and nodes to perform a software update. If the software update is “contentious” (controversial/debated) then we may not have 100% agreement on the upgrade.

If some participants decide to upgrade and others don’t, they will “fork” off into two different chains. We will have a chain split – fracturing the network and the community.

EIP 999, unfortunately, turned out to be a contentious proposal. 

EIP 999 Vote:  Majority Say NO

Some people say EIP-999 is the “right thing to do: people deserve access to their money”.

But others say that it’s "not fair – parity shouldn't get special treatment". And then there are the “code is law: deal with it” advocates.

There are many camps, but ultimately it’s either: “For EIP-999”  vs “Against EIP-999”. A vote took place to gauge community support.

  • 39.4% voted FOR the change
  • 55% voted AGAINST the change.

The vote was informal, but was enough to see that the community was at odds.  And this is why we should care. Because if there are enough people who disagree with the other side, then a chain split WILL occur.

At that point it won’t matter what’s fair, what’s right, what’s law etc.... The community will be fractured, and a narrative will be spun for both sides.

What Now?

A few days ago the EIP-99 was set as “Accepted” on GitHub because it was “not technically objected by the devs”.  (So not saying ‘no’ means ‘yes’, now…)

Apparently this was done in error, and was quickly reverted. But it still stirred things up. And now it seems like there are changes being made to the EIP process to bypass community consensus

The cauldron is beginning to simmer.

Facing The Real Issues

All of this makes for an extremely intriguing case study. It’s in Parity’s best interest to have EIP-999 passed. But Parity doesn’t want a chain split either.  So the only way they can have that is to have EIP-999 be passed without contention.

Well, there’s clearly contention… Now what? Are they going to pass it under EIP-1 because it is “technically feasible”?  Oh dear...that would open a new can of worms.

And what about the people screaming “Not fair!”? Last year, QuadrigaCX – Canada’s largest exchange – faced a similar issue and had a huge amount of Ether rendered stuck. At the time, general consensus was “Your shit out of luck – Double check, triple check your godam code!”

Should Parity be held accountable for lack of auditing standards?

Governance & Audits

In the 2008 financial crisis, big banks were bailed out to utter disdain of the public. Regardless of whether the bailouts were the right move or not, people were upset. But unlike the Ethereum network, people couldn’t simply “fork off”.  

It’s up to the community to step up and show that we are better than the rest. Someone is going to have to bite the bullet and set the stage for future dilemmas. Who is it going to be?

Either way, it’s now evident that we need more thought and discussion put into:

a) The Governance Process
b) Auditing smart contracts with more seriousness

Make no mistake – none of this is going to be easy. After all, we are a community who hate government but are in sore need of governance.

Continue reading >
Share

An Orphaned Block – What happens to your transaction?!

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!

Today, its Cassidy’s turn to ask a great question!


“ What happens if I send a transaction that ends up in an orphaned block? Do I lose my BTC or ETH ??“

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

Does this mean that her transaction is in peril too? And does that, in turn, mean that she may lose her BTC?

No, not at all. Her BTC is safe – and so is her transaction. She will not lose any BTC and her transaction will go through regardless of the fork.

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.  

Instead, your wallet holds the keys to access your funds. Your funds are located on the blockchain – and will always be there. Your keys allow you to say to the blockchain “I have the right to spend these 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”

Orphaned Block - Does Cassidy Lose Her Funds?!

Okay, so now we understand that our funds are not really located in our wallet – but on the blockchain. In particular, our funds are located in the current valid Longest Chain! Afterall, the Longest Chain is what represents the blockchain.

(You’re probably having a “Oooh, I see where this is going” moment about now)

Let’s suppose a fork happens, and Cassidy doesn’t know about it. No big deal.

Remember –  her funds are on the chain! And a fork splits the chain into two! So after the fork, her funds will exist on both chains.  Let’s illustrate with some diagrams!

Orphaned Block explained

In the above illustration, Cassidy has 10 BTC up until Block A.

She then sends 10 BTC to Tom. The chain forked, and her transaction ended up on Block B2.

Block B and Block B2 are now both in contention to win the Longest Chain Rule. Another block (Block C) gets added – but it gets added behind Block B.

Orphaned Block explained simply

In the above illustration, Block C gets added behind Block B

Oops, looks like Block B wins with the Longest Chain Rule. So Block B2 gets orphaned.

The transaction that Cassidy sent to Tom gets “orphaned” as well. But Block A still exists – so Cassidy still has her 10 BTC in the Main Chain (longest chain)

Orphaned Block for dummies

In the above illustration, Cassidy still has 10 BTC in Block A

  • So to answer the question:  No - Cassidy does not lose her funds!

Does Cassidy have to RESEND her funds to Tom?

  • AgainNo,  Cassidy doesn’t need to resend her funds 🙂

Why?  -- Because when a block gets orphaned, which in our case is Block B2, all the transactions in block B2 simply go back in the queue and wait to be added to the next block. Cassidy’s transaction will most likely get added in the next block.

Orphaned Block simple

In the above illustration, Cassidy's transaction to Tom will be put in queue, and will likely be added to Block D

Concluding Thoughts

I tried to keep this one short and simple. Believe me, I removed a lot of text that went into more detail. But I think this is more than enough to give you guys the core idea of what’s going on. The nitty-gritty stuff can wait for later!

The key point to remember is that your funds exist on the chain. A fork would entail you now have funds on two chains. But only the chain that ends up being the Longest Chain will be the one that matters! (Yes, the longest chain rule is that important!)

Did this post help you?

Help Us Keep Doing What We Do Best!

Tip Jar 🙂

BTC: 3LrzDr7ZYQ5xWAKnweM1XuUAvU5YEkF7Zb

ETH: 0x87ba0C08910Dbd3b93D74A2A3b61d78A3C2dbDab

Did you enjoy this post?

Help Us Keep Doing What We Do Best!

Tip Jar 🙂​​

BTC: 3LrzDr7ZYQ5xWAKnweM1XuUAvU5YEkF7Zb

ETH: 0x87ba0C08910Dbd3b93D74A2A3b61d78A3C2dbDab

Get my upcoming eBook for Free!

"The Mango Guide TO Understanding Blockchain"

Offer Valid For FIRST 500 registrations only

Continue reading >
Share

Longest Chain – How Are Blockchain Forks Resolved?

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

So when we have a disagreement in who gets to place the next block – we will have a “fork”

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

Blockchain Forks

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…

Blockchain fork

How Are Blockchain Forks Resolved - Orphaned Chains

Alright, so a fork has occurred. What now? How do we achieve consensus again? Did the Proof Of Work Consensus method fail here?   No – it didn’t.

Proof Of Work accounts for this sort of scenario with the Longest Chain Rule.

The Longest Chain Rule ensures that network will recognise the “chain with most work” as the main chain. The chain with the most work is typically (not always) the longest of the forks.

Blockchain forks

In the figure, the chain split after Block A.

Block B and Block B2 seemed to have won the Cryptographic Puzzle at the same time. The chain splits. There are now two scenarios that may take place:

  • Scenario 1: Majority of the other miners pick Block B as the “last valid block”

OR

  • Scenario 2: Majority of the other miners pick Block B2 as the “last valid block”

Let’s assume Scenario #1 takes place.  

This would mean that there are far more people solving for the cryptographic puzzle on Chain B.
Remember – the chance to solve the puzzle is random. But since Chain B has more people trying to solve the puzzle, it will probably solve it faster.  The key word here is “probably”.  Chain B2 may still solve the next (or next few) puzzles faster.

However, over a longer period of time – the probability will win out. Eventually Chain B will outpace Chain B2. The Longest Chain Rule will then kick in – and the following will happen:

  1. Chain B will be considered the main chain.
  1. The transactions contained within all the blocks on Chain B will be considered true and valid.
  1. All  the blocks & transactions on Chain B2 will be considered orphaned  and will be ignored.

Concluding Thoughts

That’s pretty much it – simpler than you thought it’d be eh?  The longest chain rule plays a crucial role in achieving consensus. You can probably use this explanation to figure out how this would play out in a 51% attack as well.  If not, I’ll be writing a post on that soon. And now that you know the Longest Chain Rule, it’ll be a breeze to understand 🙂

Did this post help you?

Help Us Keep Doing What We Do Best!

Tip Jar 🙂

BTC: 3LrzDr7ZYQ5xWAKnweM1XuUAvU5YEkF7Zb

ETH: 0x87ba0C08910Dbd3b93D74A2A3b61d78A3C2dbDab

Did you enjoy this post?

Help Us Keep Doing What We Do Best!

Tip Jar 🙂​​

BTC: 3LrzDr7ZYQ5xWAKnweM1XuUAvU5YEkF7Zb

ETH: 0x87ba0C08910Dbd3b93D74A2A3b61d78A3C2dbDab

Get my upcoming eBook for Free!

"The Mango Guide TO Understanding Blockchain"

Offer Valid For FIRST 500 registrations only

Continue reading >
Share

Understanding Longest Chain – A Simple Analogy

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 🙂

 Longest Chain Explained  - A Farmer Analogy

Let’s pretend we’re all farmers living in a small town. Majority of us farm rice as our major source of income. Weharvest the rice and pack them into 1KG gunny sacks and then carry the sacks to the Townhall. The sacks are then placed onto the only carriage the town has and transported to The Main City and sold.

The Town Hall Meeting: One day a Town Hall meeting is called to discuss the size of the gunny sacks...

An angry debate ensues on whether or not they should increase the size of each gunny-sack. Some farmers want the increased gunny-sack size for increased profits. But other farmers are against the idea – and claim it will make it more difficult for the older/younger/weaker farmers to carry the gunnysack to the Townhall.

The Mayor suggests that a vote should be conducted to solve the matter. However, an objection is raised:

“How is that fair? I do more work than these guys. I harvest far more rice. My vote should count more”

The Vote : That’s when a farmer named Satoshi comes up with an idea. He suggested that the next time they come to the town hall – they vote with their gunny-sacks of rice.

Each gunny-sack would represent a vote. That way, if you have more gunny-sacks you can cast more votes.Each sack of rice would be proof of their hard work. Farmers who worked harder, had more rice – and hence got to cast more votes 

The Result : Everyone loved the idea. The next day, two rows were laid out near the Town Hall. The first row represented “Increase Gunny Sack Size” and the second row represented “Don't Increase Gunny Sack Size”

Farmers would carry their gunny sacks to the town hall and place each sack in one of the two rows – thus casting their vote.   The row that had the longer chain of gunny sacks would be picked as the final decision.

At the end of the day, the “Don't Increase Gunny Sack Size” row had the longer chain of gunny sacks – and thus was the winner!


Disagreements within a blockchain are pretty much solved the same way. Each gunnysack represents a “block” in the blockchain.  A row of gunny sacks represents a chain.

Whenever there’s a disagreement, network participants can “fork” off the current chain. Thereby starting a new chain of blocks. Participants who agree with this new chain can now start applying their “blocks” to the new chain as well. Eventually, if the new chain extends the old chain – the Longest Chain Rule will kick in and will be declared the winning chain.

Longest Chain & “Work”

In our analogy, farmers were adding sacks of rice to “vote”. These sacks of rice are tangible and represent work done. The longest row of sacks represents the majority.

Similarly, in the blockchain, miners add a block to the chain to cast their vote. And the longest chain of blocks represent the majority.  

But - How does a “digital” block represent something tangible/work?  

Therein lies the beauty of Proof Of Work – but also a lot of confusion. In a previous post we discussed how Proof of Work uses the Cryptographic Puzzle to determine who represents the majority in the network.

To recap:  Miners on the network compete against each other by attempting to solve the puzzle – in order to win the “right” to add the next block onto the chain.  

A miner consumes a lot of electricity to solve these puzzles. But each time he wins (i.e solve it before someone else does)  – his block gets added to the chain.

In a way, the miner has permanently applied his electricity onto the block he just created. Since he won the solved the cryptographic puzzle, his block (with his ‘electricity’) gets added to the chain. 

So now you could say...

The farmers ‘proof of work’ was his sack of rice – and hence got to vote. After all the farmers place their sacks of rice in each of the two rows, we have our decision because: 

“The longest row of sacks represents where the majority farmers have placed their vote”

The miner’s proof of work is his winning “block” of transactions - since each block represents a miner’s electricity consumed – the entire chain represents the consumed electricity of all the previous winning blocks.

“The longest chain of blocks represents where the majority miners have placed their vote"

Concluding Thoughts - Longest Chain & Immutability

Remember, energy is never destroyed – simply transferred. In the proof of work, you could say that the energy is transferred to secure the blockchain.

Why ‘secure’? Because to change a block, you’ll have to redo the “work” that was needed to create that block.

To undo any of the previous blocks, you’ll have to redo the work for that block and every block that followed it. I’ll explain (in detail) why in another post. But this is what gives Bitcoin it’s strong immutability.  

In essence, an attacker will have to start a new chain and do enough work to also become the longest chain. If and only if  his chain is the longest chain will it be considered the winner and valid. And you may understand now – to achieve this, would require consuming a lot of electricity. This is why The Longest Chain rule is so crucial to understand 🙂

Did this post help you?

Help Us Keep Doing What We Do Best!

Tip Jar 🙂

BTC: 3LrzDr7ZYQ5xWAKnweM1XuUAvU5YEkF7Zb

ETH: 0x87ba0C08910Dbd3b93D74A2A3b61d78A3C2dbDab

Did you enjoy this post?

Help Us Keep Doing What We Do Best!

Tip Jar 🙂​​

BTC: 3LrzDr7ZYQ5xWAKnweM1XuUAvU5YEkF7Zb

ETH: 0x87ba0C08910Dbd3b93D74A2A3b61d78A3C2dbDab

Get my upcoming eBook for Free!

"The Mango Guide TO Understanding Blockchain"

Offer Valid For FIRST 500 registrations only

Continue reading >
Share

Radix DLT: Tempo’s Logical Clocks Explained Simply

In a previous post I discussed the various Consensus Methods - PoW, PoS, Tangle & Tempo.  Since then I’ve covered a few topics on the most well known of the consensus methods (PoW and PoS).  Today, I want to discuss, what I believe is, the most important of the Consensus Methods for us to grasp: Tempo.

Don’t get me wrong –  I’m not claiming that Tempo is “better” than the rest. “Better” is subjective. However, I do believe Tempo is by far the most groundbreaking of the Consensus Methods. 

Tempo tackles the current issues that plague the DLT/Blockchain world  – namely scalability & mass adoption. And it does so effectively. As such, from an enthusiast perspective, Radix’s Tempo deserves our keen attention.

In this post, I want to start with the most important element of Tempo:
The Logical Clocks.

Don’t worry – it’s not as intimidating as it sounds. In fact, we’re going to keep this as simple as possible 🙂

Ordering Of Events –  PoW, PoS and Tempo

Far too often people misunderstand the “goal” of a Consensus Method. Most people believe that consensus methods exist to “validate” transactions.  But in truth, the focus of a Consensus Method is coming to an agreement on a set of events. And most importantly to:

​​​​Come to an agreement on the ordering of events!

In distributed systems, the ordering of events (like transactions) can be difficult. You cannot simply attach a timestamp to an event. Due issues like network latency, each system may witness an event at a different time.  

So how are the systems to agree on the different timestamps? How are they to come to  consensus  on the ordering of events?

Bitcoin’s Proof Of Work uses The Cryptographic Puzzle as it’s core solution to determine the ordering of events.

Ethereum’s Proof Of Stake uses Random Sampling to determine the ordering of events.

And finally, Radix’s Tempo uses Logical Clocks to achieve ordering of events.

Logical Clocks – The Heart Of Tempo

Using normal timestamps for events doesn’t work too well in distributed systems. Why? Put simply – while one system may timestamp an event at 12:01 PM, another may timestamp the same event at 12:02 PM.  This will cause inconsistencies – and a failure to agree on the data.

So instead of using a normal clock, we use a ‘logical’ clock. This allows us to place a timestamp that is relative to an occurence of the previous event. The clock cares more about “what happened before” an event than the exact “time” of the event.  

Confusing? Let’s try an analogy....

Logical Clocks -A Restaurant Analogy

Let’s say you run a restaurant. Great food & a casual environment. No reservations are taken, you simply walk in and eat!

A typical scenario in your restaurant will consist of the following events in this order

A Patron will: 

  • Walk  into your restaurant
  • Order food
  • Eats Food
  • Pays Bill
  • Leaves restaurant

As a laid back restaurant owner, you don’t care about the exact time he conducts these events. However, you will care about in what order the events are conducted.  

For example, if a patron   “Leaves Restaurant” , you don’t care about what time he left. Instead, you care about what happened before  he left the restaurant.  

Specifically you will care if this event happened before:

Pays Bill

If he paid the bill, everything is A-okay.  If he doesn’t, you now check what happened before this event. This time, you want to check if this event happened before:

Eats food

If he didn’t eat any food – everything is fine. However, if he did eat food and is trying to leave the restaurant without paying the bill…. Is he dining & dashing?

Uh..oh, possible malicious act detected! Stop him!

If you notice – you don’t care about the time your patron conducted an event. You’re more concerned about the order of the events. This is the “happened before” relationship:

"Patron drank a Peach milkshake" happened before “Patron Leaves Restaurant”


Similarly, Radix's Tempo does not care about the exact time a transaction occurred. All it cares about is the order in which the transactions occur. For a particular transaction, it cares about what "happened before" that transaction.

Let's say Piers and Dan are two nodes in the Radix universe. Piers conducts "Transaction A" at 12:01 pm, right before Dan sends him "Transaction B".

Tempo does not care that Transaction A happened at 12:01 PM. It will, instead, care about this:  

Transaction A happened before Transaction B”      

(Essentially, in the Radix universe, each node records events without having to worry about the exact time of the event.)

This way, if Dan  sees Transaction A at around.. 12:03 PM (remember, Piers conducted the Transaction at 12:01pm) -- it won’t matter as long as  Dan sees that:


Transaction A happened before Transaction B


This allows for Piers and Dan to see Transaction A occur at different times, while still achieving consistency… eventually. Because the order of the transactions will be the same.

(Note: Dan and Piers are acting as two Nodes in our system)


ASIDE: Some of you may notice that there are similarities here to the Special Theory of Relativity. If so, you’re bang on… In the  Radix Universe, every “node” has its own local clock. The universe assumes that each node will see events at different times, but that eventually everything can be ordered in a consistent manner.

The use of Logical Clocks allows Tempo to place timestamps that are “relative” to each other – instead of absolute timestamps. This allows for consistent ordering of events – regardless of whether they were witnessed at different times.

“So What?”  & Final Thoughts

So what’s the big deal? Well, by using Logical Clocks to achieve ordering of events – Radix avoids:

  1. The intensive resource/electricity required by the PoW Hash Puzzle
  2. The capital requirement required for Random Sampling in Proof Of Stake

This allows Radix to achieve scalability while still maintaining the ability for mass-adoption – both of which are sorely needed today. Furthermore, the Logical Clocks also play a key role in the security – but we’ll leave that discussion for another day.

Radix’s Tempo is quite involved. We have a lot more to discuss, namely Sharding,  Temporal Proofs and Commitments. We’ll go over these and more in future posts. The Logical Clocks, however, lie at the heart of the Tempo Consensus. And it’s important that we get an idea of what they are before moving further 🙂

Read Next:   Radix: Sharding Explained   or   RadixDLT: The Future Of Crypto?


Did this post help you?

Help Us Keep Doing What We Do Best!

Tip Jar 🙂

BTC: 3LrzDr7ZYQ5xWAKnweM1XuUAvU5YEkF7Zb

ETH: 0x87ba0C08910Dbd3b93D74A2A3b61d78A3C2dbDab

Did you enjoy this post?

Help Us Keep Doing What We Do Best!

Tip Jar 🙂​​

BTC: 3LrzDr7ZYQ5xWAKnweM1XuUAvU5YEkF7Zb

ETH: 0x87ba0C08910Dbd3b93D74A2A3b61d78A3C2dbDab

Get my upcoming eBook for Free!

"The Mango Guide TO Understanding Blockchain"

Offer Valid For FIRST 500 registrations only

Continue reading >
Share

Is Proof Of Stake Less Resource Intensive Than PoW?

So, Mike – a Mango reader –  emailed me with this question a few days ago:


 Hey Shawn, I enjoyed your explanation on Sharding. Thank you. But now I’m  trying to understand what makes Proof Of Stake less resource intensive than Proof Of Work? Doesn’t the verification process need to take place the same way?

This is actually a really good question, Mike! It shows that your understanding is growing deeper. Your asking the right questions!

Yes, PoW and PoS conduct the validation/verification of transactions similarly. As such, Proof Of Stake  consumes just as much resources to verifiy transactions as Proof Of Work does.

However, it’s important to note that the “verification of transactions” is not what makes Proof Of Work resource intensive. It is the Cryptographic Puzzle  – required to be solved by all miners –  that consumes a large majority of the resources.

The PoW Puzzle – The Real Resource Hog

Many of us tend to believe that it's the validation of transactions consumes the resources. In truth, the majority of the resources is consumed while solving the Cryptographic Puzzle - which has nothing to do with the validation/verification of transactions.

In fact, Proof Of Work and other consensus methods are more concerned with the ordering of transactions than the "validation" of transactions. The ordering of transactions is resolved by getting miners to solve the Cryptographic Puzzle.

Miners solve the cryptographic puzzle in order to win the “right” to place their block next on the chain. And it’s the solving for the "cryptographic puzzle" that is computationally intensive - not the verifications transactions.  

In fact, Verifying the transactions is trivial compared to solving the cryptographic puzzle. Proof Of Stake eliminates the need for miners to solve the Cryptographic Puzzle – and hence eliminates the intense resource computation required.​

The PoW “Lottery” vs PoS “Lottery”

A couple of weeks ago, I explained Proof Of Work’s Puzzle using the Reverse Lottery Analogy.

In brief, Proof Of Work uses the Cryptographic Puzzle to setup a lottery. The winner of the lottery gets to place the next block in the blockchain – and everyone else agrees on it.  To win the lottery, miners have to churn numbers after numbers repeatedly until they generate the winning number. This process is extremely resource intensive.

The PoW Lottery System: Think of it this way –  the miners in this lottery know the winning number but they can’t forcefully print the number. Numbers on their ticket are printed randomly. So all they can do is keep printing tickets until they print the winning number.  The ‘printer’, however, consumes a lot of electricity – and hence the process can get really resource intensive.

The PoS Lottery System: Ethereum’s Proof Of Stake, however, doesn’t use a Reverse Lottery System. Instead, they use a normal lottery. In this lottery, each Ether token represents a lottery ticket. “Miners” (in Ethereum’s case we call them Validators)  simply place their Ether tokens in the lottery jar. We then simply shake the jar and pick the winner. The more tokens you have in the jar, the higher your chance of getting picked. (This is similar to having more hashpower in Proof Of Work)

And Voila! – we eliminate the intensive resource consumption.

Concluding Thoughts

Keep in mind – this is article is not claiming that Proof of Stake is better than Proof Of Work. Making a claim like that would show disregard for the multitude of use-cases for Blockchain and DLTs.  There are pros and cons for both consensus methods – and there will always be tradeoffs. In fact, the intense resources consumed by PoW can be stated as a positive aspect when pertaining to Immutability.  Here's a simple & well written article on Immutability in PoW that I recommend reading.

At MangoResearch, our community seeks to understand and educate ourselves – and not engage in futile debates.

Did this post help you?

Help Us Keep Doing What We Do Best!

Tip Jar 🙂

BTC: 3LrzDr7ZYQ5xWAKnweM1XuUAvU5YEkF7Zb

ETH: 0x87ba0C08910Dbd3b93D74A2A3b61d78A3C2dbDab

Did you enjoy this post?

Help Us Keep Doing What We Do Best!

Tip Jar 🙂​​

BTC: 3LrzDr7ZYQ5xWAKnweM1XuUAvU5YEkF7Zb

ETH: 0x87ba0C08910Dbd3b93D74A2A3b61d78A3C2dbDab

Get my upcoming eBook for Free!

"The Mango Guide TO Understanding Blockchain"

Offer Valid For FIRST 500 registrations only

Continue reading >
Share

What Exactly Is Ethereum Gas?

By Shawn Dexter / April 12, 2018

What Exactly Is Gas

There seems to be a lot confusion & questions around Ethereum & Gas – and rightfully so. Blockchain veterans & enthusiasts alike can be thrown off by the terminology. Moreover, people often wonder “why” Ethereum chose this route. Why not keep it simple – like Bitcoin?

There are good answers to these questions. But before we dive into the why & how”  of Gas – let’s briefly go over “what” Gas is.

Contrary to popular belief  – Gas is not a sub currency of Ether.  Gas is more so an “internal” token within the EVM (Ethereum Virtual Machine).  It is used by Ethereum to place a relative cost on each operation within a Smart Contract.

For example, a contract can have the following types of operations and associated costs

  • Single Execution Step:  1 Gas
  • Store A Value:  100 Gas 
  • Call Another Contract : 20 Gas

This allows Ethereum to “charge” more for contracts that are more complex. This is fair – since a Smart Contract with more/demanding operations will be using more network resources.

When you send a transaction to a Smart Contract, you are required to enter the following:

Gas Price
​The “Gas Price” is the amount of Ether you are willing to pay for each unit of Gas.

Gas Limit
The “Gas Limit” is the total amount of Gas you’re willing to buy for the execution of this transaction.

I get it – it's still confusing. Understanding how "Gas Price" and "Gas Limit" relate to each other can be a task. So let's use an analogy to clear things out.

The Maid Service Analogy

Suppose you join a new Maid Service Agency. But they decide to give their Maids more freedom & flexibility in how they conduct their business. They wanted the Maids to be allowed to earn more if the “market” deems it worthy.

 So, instead of charging you in USD$, they charge you in MaidTokens.  MaidTokens can be redeemed for cleaning activities (operations) as such:

  • Clean a Bedroom:  1 MaidToken
  • Clean a Living Room:  3 MaidTokens
  • Clean a Bathroom:  10 MaidTokens

These prices are set by the Maid Service Agency – and don’t change. So no matter what – the Maid Service Agency will get a fixed number of MaidTokens for each job (based on the rooms being cleaned).

Flexibility & Freedom 

We mentioned that the MaidTokens are being used for more freedom. But how is this freedom achieved?

The flexibility comes from the fact that the Maids can negotiate how much you (the customer) pay for each MaidToken. Here’s an example:

  •  A Maid can say, “I’m charging $25 per MaidToken” 
    •  You can reply with, “Well, I’m willing to pay only $15 per MaidToken” 

    The Maid (Miner) can then either take you up on your offer, and clean your rooms (validate your transaction) – OR look for other customers that will pay more.

    This is exactly what you're doing when you set your "Gas Price"

    •  You’re saying: “I’m willing to pay only 0.00002 Ether per Gas” 

    Similarly, a Miner can choose to take your offer or not.

    (To automate things – Miners set up a minimum a minimum Gas Price they are willing to acceptThey have the freedom to include your Transaction in their block or not. But just like the Maid, they are always looking to maximise profits.)

    Okay, awesome.. Using the “MaidToken Price” we have a better understanding of “Gas Price”. Now let’s tackle “Gas Limit”what in the world is it really?!

      MaidToken Limit

      Now let’s suppose you rent a cottage and host a huge party. You wake up the next day to a gigantic mess and a colossal headache. You call the Maid Service Agency, and they send over a Maid. You guys negotiate and agree on a MaidToken Price of  $20. 

      • MaidToken Price:  $20
      •  She asks, "how many rooms does the house have?"  
      • You reply: “Uh… I don’t know...”
      •  “Well, how do you expect me to quote you a price then?”, she replies.
      • You think about it (and your finances), and say: “How about this… I’ll pay for up to 100        MaidTokens. If the house needs more, just stop cleaning. If it needs less. I’ll pay you only    the MaidTokens it needs.”

      She agrees, and you’ve now agreed to the following:
      MaidToken Price:   $20 per MaidToken
      MaidToken Limit:  100 MaidTokens

      This is essentially the same type of agreement you get into when you send a transaction with the following:
      Gas Price:  20 Gwei (per Gas)   
      Gas Limit:  10,000 Gas

      **Note:  Gwei is a subunit of Ether.  1 Ether = 1,000,000,000 Gwei

      •  Over here, you’re telling the miner: I’ll pay for up to 10,000 Gas. If the Smart Contract needs more, just stop. If it   needs less. I’ll pay for the Gas you used”

      Hitting The Gas Limit  & Losing ETH

      Hopefully, 10,000 Gas is enough to complete execution of your Smart Contract. If the operations within the Smart Contract was costlier than you anticipated – then the execution will not complete. And the transaction fails.

      Similarly, if your 100 MaidTokens aren’t enough to clean your rooms (the cottage may have had more bathrooms than you thought) – then the Maid will stop cleaning/executing.

      The difference in our analogy is that when you hit your “MaidToken Limit” you get to keep the clean rooms.  Your house will be partially clean and the maid will leave. 

      However, we can’t have “partial execution” of a Smart Contract. So if you hit your “Gas Limit” before the contract is completely executed – the contract will roll back. It will be as though the transaction never occurred. And you’ll get an “Out Of Gas” error.

      The unfortunate part is that you will have “used up” the Ether (Gwei) you set. Afterall, the contract DID execute – just not entirely.

      Tip:  If you’re trying to save on transaction fees, set a LOW Gas Price and a higher Gas Limit.  Too often people do the opposite.

      Wrapping Up

      Gas is used within the EVM to place a cost on various operations. So when you’re conducting a transaction, think of “Gas Price” as the price you’re “offering” to the miner for each unit of Gas.  The "Gas Limit" is the total amount of Gas you’re willing to buy for this particular transaction.

      That’s pretty much it. In the next post, we’ll discuss why Ethereum has chosen to go this route as opposed to the way BTC does it.

      Did this post help you?

      Help Us Keep Doing What We Do Best!

      Tip Jar 🙂

      BTC: 3LrzDr7ZYQ5xWAKnweM1XuUAvU5YEkF7Zb

      ETH: 0x87ba0C08910Dbd3b93D74A2A3b61d78A3C2dbDab

      Did you enjoy this post?

      Help Us Keep Doing What We Do Best!

      Tip Jar 🙂​​

      BTC: 3LrzDr7ZYQ5xWAKnweM1XuUAvU5YEkF7Zb

      ETH: 0x87ba0C08910Dbd3b93D74A2A3b61d78A3C2dbDab

      Get my upcoming eBook for Free!

      "The Mango Guide TO Understanding Blockchain"

      Offer Valid For FIRST 500 registrations only

      Continue reading >
      Share

      Cryptographic Puzzle – Understanding Proof of Work

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

      The PoW Puzzle - The ‘Reverse’ Lottery Analogy

      To avoid the nitty-gritty technicals, let’s use an analogy. 

      Suppose you enter yourself into a lottery.. But this is a special kind of lottery. We’ll call it a “Reverse Lottery".
      In this lottery everybody knows the winning numbers. Sounds like an easy lottery to win, right? Not exactly.

      You can’t simply “pick” your numbers when buying your ticket. You can only buy a ticket with numbers randomly generated on it. So, the only way for you to win the lottery is to keep buying ticket after ticket after ticket…. Until you buy one that matches the winning numbers you have.

      This is precisely what is involved in the Proof Of Work cryptographic puzzle. People use their computers to randomly generate numbers at a rapid pace. (These people are called miners, btw.)  If they generate the “winning” number, they win the lottery.

      The Reverse Lottery & PoW : Breaking It Down

      Let’s say you know the winning ticket number of a Reverse Lottery to be:  1111111111.

      Now it’d be nice if you could go up to the counter and ask for a ticket with those numbers. But you can’t. All you can do is pay for a ticket and hope it generates: 1111111111. If not – tough luck. Buy another ticket and try again.

      The good news is that you can try as many times as you can. The bad news is that you have to pay for each new ticket.

      Our “Reverse Lottery” is essentially what the cryptographic puzzle is.

      • Player in the Lottery  = Miner in the Network
      • Buying tickets with random numbers = Using Computational Power To ‘Solve’ Algorithms (Hashing)

      In the Reverse Lottery, each player is hoping that he generates the winning ticket number before someone else does.  Similarly, each Miner is hoping that he can generate (by ‘hashing’) the winning numbers before other miners do.

      • In the lottery, players are paying for each ticket with money.
      • Miners are using computational power to “hash” their numbers – which translates to electricity costs.

      The good news is the miners are using hardware that generate millions of hashes per second.

      The miner who finds the winning hash gets to add his “block” to the blockchain. In return he gets a reward. He also gets to collect transaction fees for all transactions listed in the block.

      On average, a winning number (or winning hash) is found every 10 minutes. This average can be adjusted but we’ll talk about that later. And the miners move on to compete for the next winning hash. It’s kinda like a new Reverse Lottery every 10 minutes.

      The process of trying to find the winning hash is called “Mining”.  The term actually originates from the traditional “mining” of gold. But instead of using a pick-axe to dig for Gold, Miners are using their computers to dig for the winning hash.

      That’s pretty much it. You pretty much understand how the process works now.  But I may have left out one aspect. The Nonce.

      The Cryptographic Puzzle: Nonce?

      Let’s go back to our Reverse Lottery.  Suppose the creators of this lottery decide to spice things up. They realize that they need to make lottery players feel more “involved”.

      To achieve this, they add a new element into the Reverse Lottery. Now, instead of simply randomly generating a number they ask the player for the following information first:

      • His Name  (For example :  Bob )
      • His Favourite Color  (For example : Green )
      • A “random number” of his choice  (For example : 7)

      The Reverse Lottery will take all three answers –  Bob, Green, 7 – and put it into a special “mixer”.  You can think of Bob, Green and 7 are the “ingredients”.  The mixer will spit out a Lottery Ticket for Bob based on the ingredients he gave it.

      (Btw this is precisely what “hashing” is. A function/algorithm that takes “ingredients” and produces an output based the input.)

      If the ticket matches the winning number – great! He wins! If not, he will have to try again – but this time with a different “random number”.  This will give him a new lottery ticket number.

      Essentially, his name “Bob” and favorite color “Green” will remain fixed as ingredients. His ‘random number’ keep changing until he gets the winning lottery ticket.

      In Mining, this “random number” is what we call the nonce. The other “fixed” ingredients are the transaction data, block data, timestamp etc.

      The nonce is incremented after each failed attempt. (Fyi, the other ingredients are relatively fixed. They change when necessary – but that’s nitty-gritty stuff we don’t care about at them moment)

      Wrapping Up - PoW Cryptographic Puzzle

      To sum it all: In Proof Of Work people (miners) are essentially racing against each other to generate the winning numbers for the Reverse Lottery.

      Instead of repeatedly buying tickets at a counter, they expend electricity by rapidly running an algorithm on their computer over and over again. When and If they generate the winning number (winning hash) they get to add their “block” of transactions to the blockchain.  In return, they claim a reward and the transaction fees for all the transactions in the added block.

      There’s more I’d like to discuss – like Verifiability. I’ll leave that for the next post though. 

      For now, I’ll let you ponder over this question:
      “How do the other miners verify that he really did find the winning hash?”

      We’ll talk about this and more in the next post 🙂

      Did you enjoy this post?

      Help Us Keep Doing What We Do Best!

      Tip Jar 🙂​​

      BTC: 3LrzDr7ZYQ5xWAKnweM1XuUAvU5YEkF7Zb

      ETH: 0x87ba0C08910Dbd3b93D74A2A3b61d78A3C2dbDab

      Get my upcoming eBook for Free!

      "The Mango Guide TO Understanding Blockchain"

      Offer Valid For FIRST 500 registrations only

      Continue reading >
      Share
      Page 3 of 5
      Join us on Telegram!
      >