Why Proof of Stake Is The Future — Part 2

Proof of Work & 51% Attacks

Midas.Investments
3 min readDec 9, 2019

This article is the second installment in the “Why Proof of Stake Is The Future” series. To view part one of the series — an article which explored Proof of Work’s wasteful energy consumption — click here:

https://medium.com/@midasinvestments/why-proof-of-stake-is-the-future-part-1-7c9a585356bb

Proof of work consensus algorithms are unsustainable for a number of reasons. Wasteful, purposeless and ever-increasing energy consumption, increased vulnerability to 51% attacks, and severely limited scalability are probably the three leading reasons for its inadequacy.

All true cryptocurrencies are blockchain based and trustless. In order for a network to be entirely trustless, it must be decentralized. But for open source, decentralized networks to function, there must be some method of consensus. This consensus method must answer two fundamental questions: What is the Byzantine Security level, and how likely is it that this level will be met?

In order for two different blockchain processing nodes to reach consensus, there must be a secure and fault tolerant protocol. This is because it is not guaranteed that both of the nodes are displaying the same information. What would happen if one of these nodes was malicious and sought to attack the network?

This scenario is often allegorized with what is called the Byzantine Generals problem. In a nutshell, this problem is about two generals fighting a battle. One army is located within a walled city, the other is surrounding the city, and each are waiting to attack. If these armies are not able to attack simultaneously, the army outside of the walled city will lose. All of the generals must agree to attack at the same time.

This problem is a great example for what is the core of cryptography — sending messages in a corruptible environment. The only way that the generals can communicate is by sending a messenger into the city to convey the plan of attack. This problem was not solved from when it was first proposed in 1982 until 2008 when Satoshi Nakamoto solved the problem. Essentially the solution is to have the general outside the city use encrypted messages when he sends the messenger into the city. If he uses ever increasingly stronger encryption, the message can not be decoded in time for a malicious action to be taken. For blockchain, this looks like having a greater hash power on the chain than off the chain.

In blockchain, both expected and unexpected chain splits can occur. In the scenario described above with a malicious node, this would result in an attempted chain split. In theory, if this chain split were to occur, the malicious node would have complete control over the blockchain — and in some cases the blockchain’s history. The result would be disastrous — uninhibited coin minting and double spending would undoubtedly occur. In the case of Proof of Work chains, the chain with the highest active Hash power being mined is validated as the true chain. This is problematic for a couple of reasons:

1. Nearly all PoW miners use mining pools, which creates a large centralization of hash power.

2. Hash power is available for rent.

If someone were to control 51% of the hash power of a network, they have control over the network. This is what is referred to as a 51% attack. While many would think this is extremely unlikely, the reasons listed above have made this a common occurrence. Bitcoin Gold, Verge, Ethereum Classic, and even Bitcoin itself have all experienced 51% attacks at some point in their history. Blockchain’s supposed “secure store of value” proposition may not be foolproof — at least not when PoW is the consensus.

Midas.Investments
Discord
Twitter
YouTube
Telegram

Do not forget to clap 50 times (by pressing the clap button) and subscribe to our social medias and Medium!

--

--

Midas.Investments

https://midas.investments/ — is an investment platform that provides various tools for creating long-term crypto-portfolios and manage them automatically.