All posts in " analogy "

RadixDLT Sharding Explained: Scalability Done Right

By Shawn Dexter / August 13, 2018

Shawn uses a simple analogy to explain the RadixDLT Sharding approach - A step towards scalability and mass adoption. 
(Note: I capitalize ‘Sharding’ throughout this post to emphasize its importance, and to avoid reading it as ‘sharing’)

Sharding has morphed from an obscure concept in 2017 into the buzz-word of 2018. The need for blockchain scalability has become glaringly obvious, and several projects have turned to Sharding as a solution.

However, Sharding a blockchain is not a simple task. In fact, it poses challenges that have our best thought-leaders scratching their heads. Several projects have made lofty promises of future scalability using Sharding. But, only few have provided a viable Sharding solution for mass adoption. RadixDLT is one of the rare projects that brings forth a novel approach to Sharding –– an approach that seeks to meet the demands of mass adoption

Right from its conception, the goal for Radix was:  Every single person, on every single device using a single protocol simultaneously.

Every single person, on every single device using a single protocol simultaneously.

The RadixDLT Sharding architecture was designed (unlike other projects that approached Sharding “after-the-matter”)  to allow for unbounded scalability while maintaining security, and maximizing decentralization.

In this post, I will explain how Sharding works in Radix in a simple way – without any technical jargon.

RadixDLT: Sharding

What is Sharding ?

Break a window, and you have shards of glass. Break an iceberg and you have shards of ice. A shard is simply a broken piece of ‘something’.  So, when you “shard” something, you’re simply breaking it into smaller pieces.

But, why do we shard? Well, you usually shard something because it’s easier to manage. For example, we ‘shard’ a large pizza because it’s easier to eat one slice at a time. It also allows us to share (distribute) the pizza with friends a lot easier.

Similarly, when a database gets too large to handle, we shard it and distribute it across multiple computers. There you go –– you now understand distributed computing & Sharding. It’s really that simple.

Sharding has been used to partition databases for a long time. You simply cut the database (think of an excel sheet) horizontally into several pieces and distribute across multiple “database servers” (machines that ‘serve’ you data when you need it). When the data needs to be retrieved or processed, the relevant database server is called upon to do the task.

In Blockchain these “servers” are what we call “nodes”.  However, Sharding a decentralized system isn’t as straightforward as we’d like. There are complications that a centralized system doesn’t need to concern itself with.

Why Is Sharding Difficult in Blockchains

Every distributed system requires a Consensus Method. But, developing a Consensus Method for a Sharded blockchain is tricky. You find yourself sacrificing security in favor of scalability.

Why? Well, a huge component of the security comes from the fact that every node stores all the data. Since every node keeps a copy of the entire database – you can’t cheat/lie about past events. But when you shard that database, each node stores partial data. Suddenly, you can tell Node Bob one thing, and tell Node Lisa another.

To understand this better, think back to when you were a kid.

Remember when your Mom grounded you and your Dad didn’t know about it? If you were anything like me, you tried to sneak out by asking your Dad for permission. Dad didn’t have all the info. And you took advantage of it.

Mom and Dad represent a Sharded database. Sure, together they have all the info needed to run the household. But as individuals, they don’t – and can be lied to about past events (like you being grounded or not)

RadixDLT Sharding: The Basics

Founder & CTO  Dan Hughes identified the scalability issues that would plague Bitcoin back in 2012. After several attempts at improving the protocol, he realized that the only solution is a brand new architecture and consensus method. Six years and a lot of sweat later, he brought us Radix DLT – a unique Sharding approach and consensus algorithm.

Radix DLT approaches Sharding in a unique but simple manner.  Most projects take existing Consensus Methods and build a Sharding solution on top of it. But as discussed, this leads to sacrificing security. For example, Sharding on PoS network could result in a One Percent Shard Attack.

Radix, however , started with a Sharded network –– and built a unique consensus method on top of that network. This “Sharding-first” approach allowed them to bypass the limitations faced by other consensus methods.

RadixDLT Sharding
The RadixDLT network is sharded into 18.4 Quintillion shards of 2mb each  – enough to  store the entirety of Google’s data and throughput!  And we all know that Google stores a lot of data. The goal was to have at least as many people using Radix as there are people using Google.

Essentially, Radix began with the end state in mind, which is:  every single person on every single device using a single protocol.

Pre-Sharded Network Explained

Radix’s pre-sharded network serves as a fundamental around which they have designed their consensus method (Tempo).

The size of each shard, and the number of total shards are predetermined. Nodes then place themselves atop shards – and can overlap with other nodes in layers. 

This is where it gets interesting…

Remember, every shard has already been created. They all live in the same “Universe” and their location ID is known. Every transaction is stamped with a blend of the sender’s ID and shard ID.

This makes it extremely simple to locate the Shard from which the transaction that has been sent.  Now, if Node Bob tries to double-spend his $10, we don’t need to check every other shard to catch him cheating. We can simply check his shard.

To better understand this let’s go back to our Mom & Dad analogy

Your Mom grounds you. But this time, she stamps your forehead with the word “Grounded”. You now go to your Dad’s study room and ask him if you can out to play. Your Dad simply looks at your forehead and says “Nope”.

He didn’t need to go check with your Mom. He didn’t need all the info – and was still able to stop you from cheating.

Similarly, the overlapping of nodes and easy cross-shard communication allows each node to store partial info. Which essentially means: not all nodes have to store all the data!  This plays a significant part in Radix’s massive scalability without sacrificing security.

(I simplified this, of course. But we will discuss more on Atoms, Universes timestamping & Temporal Proofs in future posts)

As mentioned earlier, the need to store and process every transaction is a huge limitation for blockchains. Radix is a cleverly designed network that avoids this limitation.

Concluding Thoughts - RadixDLT Sharding

Radix has presented an innovative and noble approach to solving the scaling issues of DLTs. 

Over six years of sweat and frustration, Dan Hughes and team remained true to the goal: Every single person, on every single device using a single protocol simultaneously. The project is still in alpha and the team urges us to participate and help find any potential issues or flaws. 

Although this was an introductory explanation, I’m sure you can’t help but wonder... Will Radix DLT be the answer to the burning question for mass adoption? Time will tell.

Get my upcoming eBook for Free!

"The Mango Guide TO Understanding Blockchain"

Offer Valid For FIRST 500 registrations only

No menu items have been found.
No menu items have been found.
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

No menu items have been found.
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

No menu items have been found.
No menu items have been found.
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

No menu items have been found.
No menu items have been found.
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

      No menu items have been found.
      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 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.

      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

      No menu items have been found.
      Continue reading >
      Share

      Proof Of Work: Determining Majority “Power”

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

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

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

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

      Consensus In A Boardroom Office

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

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

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

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

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

      Consensus Online:  IP Addresses?

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

      Proof of Work - a simplified example

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

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

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

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

      Consensus Online: CPU Power

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

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

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

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

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

      1. Initial hardware costs 
      2. Ongoing electricity costs.

      Longest Chain: Determining Majority Support

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

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

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

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

      Wrapping Up - Proof of Work

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

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

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

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

      Further Readings:

      Did you enjoy this post?

      Help Us Keep Doing What We Do Best!

      Tip Jar 🙂​​

      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

      How Are Blockchain Transactions Validated? Consensus VS Validation

      By Shawn Dexter / March 22, 2018

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

      How Are Blockchain Transactions Validated?

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

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

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

      Blockchain Validators

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

      Blockchain Validation Explained

      Blockchain Validation vs Blockchain Consensus

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

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

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

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

      Validation Without Consensus

      How Are Blockchain Transactions Validated?

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

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

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

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

      A Simple Bitcoin Transaction Example

      Miner Bob &  Miner Joe

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

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

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

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

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

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

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

      Using Proof of Work (PoW) for Picking Blocks

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

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

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

      Using Proof Of Stake (PoS) for Picking Blocks

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

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

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

      Wrapping Up - Blockchain Validators vs Miners

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

      Get my upcoming eBook for Free!

      "The Mango Guide TO Understanding Blockchain"

      Offer Valid For FIRST 500 registrations only

      No menu items have been found.
      Continue reading >
      Share

      Blockchain Trilemma – The Village’s Impossible Trinity

      By Shawn Dexter / March 12, 2018

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

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

      The Village Began To Grow - A Scalability Crisis

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

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

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

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

      The Ultimate Sacrifice

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

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

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

      • Security
      • Scalability
      • Decentralization

      These three factors are the essence of the blockchain Trilemma.

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

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

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

      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.

      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

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

      By Shawn Dexter / March 11, 2018

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

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

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

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

      PoW: Is A 51% Attack A Feasible?

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

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

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

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

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

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

      PoW Sharded: Is a 1% Attack Feasible?

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

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

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

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

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

      1%-attack

      PoW vs PoW Sharded

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

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

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

      Get my upcoming eBook for Free!

      "The Mango Guide TO Understanding Blockchain"

      Offer Valid For FIRST 500 registrations only

      Continue reading >
      Share
      Page 1 of 2
      >