Bonnie Prince Charlie needed Byzantine Fault Tolerance

If you’ve been around the world of blockchain or cryptocurrency in the last few years you may have heard of the term Byzatine fault tolerance.  Where does this name come from and what does it have to do with modern day blockchains?

For years my father told me that the reason we Scots lost the battle of Culloden was because a messenger sent by Bonnie Prince Charlie to attack the English was killed before he could deliver the order and so the poor Jacobite’s were left to be decimated by cannon and musket fire before they could even start.  A quick google search will tell you this is a bit of an exaggeration, and that the entire battle was a bit of a badly coordinated jumble, however it highlights a major problem in those days – communication.  And more importantly – trusted communication.

Distance and logistics in a battle created a whole host of problems for commanders.  Apart from the physical danger to messengers, problems of timing and delay created a great difficulty in coordinating troops, especially in terrains where flags or other visual communications weren’t effective or could be seen by the enemy. And then there was the fact that loyalty in those days was literally like something from Game of Thrones – who could be trusted?

What does all this have to do with Byzantine fault tolerance and blockchain I can hear you asking?

Gospel uses practical Byzantine Fault Tolerance (pBFT) at the core of its data layer security, which we believe is by far the most effective system of authenticating and authorising any activity on our private permissioned blockchain. BFT, as the basic version is known, apart from sounding like a university protest group, is in fact the mechanism by which cryptocurrencies and essentially all blockchains authenticate transactions.

However, the original inspiration for why this consensus mechanism has such an exotic name is quite an interesting one and helps to understand the mechanics of what is going on in modern day distributed ledgers.  As someone who works in branding I’m always intrigued by the origins of phrases or terms (there is usually some logic somewhere) and believe metaphors are a great way of conveying a concept, especially those which can be complicated at the best of times.

Armies and empires

The Byzantine empire was the extension of the Roman empire in the East and was at one time the largest in the world, lasting for over 1000 years. Their generals were regarded as some of the best when it came to strategic thinking. However, their downfall came when the barbarians, many of whom had served in the Roman army, used their tactics against them and deliberately used subterfuge to disrupt their coordinated attacks eventually leading to the downfall of Rome.   In actual fact, the problems encountered by the Byzantine armies are exactly the same as those faced by engineers trying to create a trusted method of communication in a modern day computer system and co-ordinate actions over unreliable and corruptible links.

BFT is so-named because it represents a solution to the “Byzantine generals’ problem,” a logical dilemma that researchers Leslie Lamport, Robert Shostak and Marshall Pease described in an academic paper published in 1982.

The two generals problem

The most basic way to simplify the Byzantine problem is to think of two separated armies trying to attack a large force between them.  If they were to attack at the same time they would win.  If they didn’t, it is possible the opposing force would be strong enough to repel a single army.  So, in order to co-ordinate the attack, they must use a messenger to convey the signal and time to advance.  To confirm they have received the message and are in agreement on the time of attack, the recipient must send a messenger back (they may not be ready to attack at 2pm for example).  Unfortunately there is no way of knowing whether any of these messengers may have been intercepted on the way by the enemy and is now a spy – except by sending another message to re-confirm back – and so you can see the problem – ad inifinitum.

The Byzantine generals

Now take the problem and add a number of generals and a number of armies.  By using the single messenger method, you have the very same problem, only even more complicated by a number of different opportunities to have the attack disrupted by an insider.

However – if you change the system to a vote and send messengers to all other generals so you can see how everyone has voted, and everyone confirms back to all other generals what they received from everyone else, then in theory it doesn’t matter if there are one or two spies – because their deception will be easy to spot and their votes discounted.  You will be able to reach an agreed consensus.

Bring it back to modern day and BFT is a consensus mechanism which grades potential read and write requests to a ledger on their likelihood to be reliable, based on the agreement of a number of independent nodes on a network (where everyone is untrusted by default).  The inner workings in terms of zeros and ones are naturally far more complex than a mortal like me can explain in a blog, but essentially the theory is based on the same principles in overcoming the Byzantine attack problem. Gospel uses pBFT across its platform to ensure a single version of truth  at all times is accessible to its members on the private network – beyond the perceived safety net of data silos.

If only Bonnie Prince Charlie had had some sort of distributed network of nodes to reach agreement with his commanders back in the day, then things could have been very different.  Either that or the Scots would be very, very rich on bitcoin!

For a 90 second summary of Gospel click here.

For an in-depth overview of the Gospel solution click here.

Ask the team – many of your questions answered.

Related blogs & news

Announcing Gospel's first virtual hackathon

30 August 2018
Blog

Announcing Gospe

Managing access in a collaborative data sharing platform

30 August 2018
Blog

Managing access

Managing access in a collaborative data sharing platform

30 August 2018
Blog

Managing access