• info@ghoststaking.com
Commentary
The Byzantine Generals’ Problem

The Byzantine Generals’ Problem

A lot of our readers may have heard or read the word ‘Byzantine’ or the phrase ‘Byzantine fault tolerance’ over and over again when researching Blockchain consensus. In fact we discuss the specifics within our deep dive into Casper CBC in the section entitled ‘Byzantine Fault Tolerence (BFT) and Guaranteed of common protocol future‘.

So what exactly is ‘Byzantine’ and why is the word littered across Crypto commentary? It in fact, it is a problem which computer scientists have been working on for decades; therefore it is well worth us spending a little time looking into it in detail.

Byzantine

Byzantine is the name historians have given to the Eastern part of the Roman empire.

Source: http://textusreceptusbibles.com/Editorial/Byzantinemap

Great, you might be wondering, why have I moved from blockchains to a history of the territories of the Roman empire? Well the Byzantine Generals problem was a specific historical problem faced by a collection of Generals within the Byzantine army.

Byzantine Generals Problem

A group of Generals, each commanding a portion of the Byzantine Army, encircle a City with the aim of conquering it.

They must decide whether to attack or retreat. However, whatever they decide, the most important thing is that they all reach a consensus i.e. they all attack or they all retreat. The reason for this is that the City can only be taken with the full might of the collective army. If even one General decides not to attack, then there will not be enough force to overthrow the City and all attacking soldiers will die.

Consensus however is not a simple thing to achieve, especially because within this Army, the Generals do not trust each other, just as we cannot trust each other online. A General might say they plan to attack, when in fact they plan to secretly retreat.

The Generals then have no choice but to route all of their battle plans through a Central Authority. When we consider a central authority, the first word which springs to our minds is Centralised/Centralisation. Centralised internet processes should be familiar to us all (as this is what blockchain and cryptocurrency is aiming to move away from when introducing the concept of decentralisation).

A central authority means each individual participant (or General in this case) does not have to trust another General. However there is now implicit risk and trust on the central authority. This is the fundamental concept upon how the internet was built. For those of us old enough, cast your mind back to when the internet was first designed and built. It was a few central government authorities and university researches interacting on it. There was no consideration to how it would evolve and to what kind of central function it would play in our lives in terms of payment processing and data sharing.

Internet Centralisation Problem

The primary online function is the exchange ‘things’ of value. Not necessarily payments in exchange for goods, but also data transactions. We are all familiar with the largest internet data third party companies: Google, Facebook, Twitter etc. These companies have grown at such pace that it has often caught the consumer off-guard in terms of what “payment” is being used to provide for these systems and services.

Facebook for example, is marketed as a social media platform when in fact it is a data warehouse and analytics platform of gigantic proportions – we are not Facebook’s consumer, we are in fact Facebook’s product. We are effectively using our data as a means of payment for the service. So what is the problem with this? Well, you would have had to have been living under a rock for the last few years to have missed how companies like Facebook have been using data to target advertising and embed divisions in society by analysing relatively small consumer dispositions (such as concerns about a vaccine programme) and then bombarding the user with direct anti-vax content. Or being using to direct campaigns to influence global elections. This, in addition to the obvious hacking or mis-sharing of information is the basis of the risk in trusting a central authority. So just as with trust needed in a central bank, where there is an accepted risk that the bank wont gamble your money away, there is also an accepted risk in terms of data transaction via centralised authorities on the internet.

These risks had to be accepted as there was no other solution without first solving the Byzantine Generals Problem.

Then along came Satoshi Nakamoto with the solution of decentralised ledgers via blockchains. Copies of the ledger are distributed among computers all over the world, updating with every transaction.

With the Byzantine Generals, if each of their orders were recorded and shared across the blockchain, every General would have a copy of every other General’s orders, always up-to-date and 100% verified. The maintenance of the ledger takes a lot of work (as does the function of a central authority), but the difference with the distributed ledger is that it has no single person/authority responsible for this. Instead, incentives are given to those who choose to do the work by using one of the various consensus protocol mechanisms (proof-of-work, proof-of-stake etc). Therefore the network of individuals choosing to maintaining the network arrive at the consensus. You can hopefully see now how a problem faced by Generals in the Roman army is so closely linked to problems on distributed computing systems, where components have failed and there is imperfect information on whether a component has failed.

Disclaimer: This article is written for the purposes of research and does not constitute financial advice or a recommendation to buy.

Stake your CSPR with us at GHOST:
1. Earn passive interest compounded every 2 hours!
2. High performance server with low CPU utilization that can be monitored in real time here.
3. Low fees with a GUARANTEE of no increases EVER!
Find out more here
.

Leave a Reply

Your email address will not be published.