TL; DR: Our Global Head of Professional Services, David Benko, recently held a Blockchain Consensus Algorithms 101 webinar. We’ve taken the first few highlights of his 30-minute presentation and summed them up for you via this blog post. Read more to find out what the two generals problem and the Byzantine generals problem have to do with today’s most modern efforts in distributed ledger technology. Here, you’ll learn what consensus algorithms are and why they’re important in today’s banking. 

The terms consensus algorithms or consensus mechanisms come up a lot when speaking of blockchain or distributed ledger technology (DLT). To remove confusion around a topic that isn’t generally handled in a straightforward manner, we’re going to the roots of two game theory problems in a way that’s incredibly easy to digest. This blog post will succinctly clarify what consensus algorithms are and why they’re important for financial businesses today. 

Blockchain consensus algorithms: A quick by-the-book definition

BCAs, as we’ll also refer to blockchain consensus algorithms moving forward for brevity, are technically defined as “a fault-tolerant mechanism that is used in computer and blockchain systems to achieve the necessary agreement on a single data value or a single state of the network among distributed processes or multi-agent systems.” Yet, to simplify this blockchain consensus algorithm definition, we can conceive BCAs as a way a series of computers make a unanimous (or close to unanimous) decision on a specific item. A consensus algorithm is thus the means through which we get a group of computer systems to all make a decision together on a specific state or value. This concept will be much clearer once we go over two general problems impacting distributed systems from the ground up. 

Common mentions of blockchain consensus algorithms 

BCAs have made the news in different ways throughout recent history. You may have heard of proof-of-stake related to this topic, for example. Proof-of-stake is Ethereum’s consensus algorithm (CA). Ethereum is a decentralized global software platform that’s come up with a CA that’s allowing faster transaction time with fewer computational requirements on a lower environmental and economical impact. 

The environmental aspect of BCAs has also been widely discussed. A proof of work BCA’s energy usage, for example, can be similar per year as that of Norway. And another common discussion on the topic is whether BCAs are truly decentralized. Giving lots to talk about, Trail of Bits produced an extensive report on the subject by June of this year. 

But, what problems do BCAs solve?

BCAs solve at least two problems we’re discussing. The first one is called the two generals problem, published originally all the way back in 1975. The gist of it is to solve for an unreliable network. According to it, two generals need to coordinate their armies to overcome a certain enemy. The theory dictates they can only use couriers to run through enemy territory in order to communicate with one another. The question is whether they attack or retreat. How can they make this decision together? 

The two generals problem: A clear and easy understanding

The solution to the two generals problem can be tried out in a couple of ways. The first option is to have one general send a message to the other saying: “If you receive this message, reply back and we’ll both attack.” But, remember the couriers on the actual mission? They could be intercepted in enemy territory at any point, which makes them perpetually unreliable. A general will always need to question whether the message they’ve received is real. 

To solve that, the second option would be to reply back to the initial general with a receipt confirmation asking for a new receipt from the other general to ascertain mutual agreement. And this can go on without end. 

For as many acknowledgements we send down what can now be considered a chain of messages, the question will forever remain whether communication was intercepted at any point. There’s a zero trust issue engrained to this, which is why the two generals problem is currently considered unsolvable. 

The Byzantine generals problem

The second problem is perhaps even more famous than the above and it’s very important in terms of distributed systems. It was published back in 1982 by Leslie Lamport, Robert Shostak, and Marshall Pease and is very much tied to unreliable nodes in a network. 

In this case, we conceive Byzantine armies whose generals must all agree to an attack or a retreat as they’re surrounding an enemy city. Courier communication is also the only way in this scenario. The added difficulty to it is that there are traitors in the ranks, purposefully inserting misleading information into the system. As you can see, the problem deals with the question of coming to a consensus in a distributed system in which certain nodes can send conflicting information to their peers. 

One of the simplest ways to conceive one of this problem’s viable solutions is to consider a node a commander. That leader will decide whether the group attacks or retreats. The rest of the nodes would act as lieutenants. The commander will send a decision to each lieutenant, and these other generals can check amongst themselves what their received response was. If the majority report a specific decision, consensus can be ascertained. More than two thirds of the generals have to be loyal in order for consensus to be reached this way. As this model requires increased messaging between generals, the solution is not entirely efficient, especially as it also requires a 3 to 1 general to traitor ratio. 

How is this all applied? The Byzantine fault tolerance

The application of the Byzantine generals problem is called Byzantine fault tolerance. Given a computer system, we assess how fault tolerant it is to Byzantine problems and seek for these systems to be able to continue to function in spite of these malicious or failing nodes. Consider malicious attacks and faulty systems here and take nuclear power plants and airplane control systems into account, for example. These Byzantine fault tolerant (BFT) systems are computationally expensive. And the modern kind use digital signatures, message authentication codes, and communication restrictions. 

How these theories impact our banking systems

Distributed ledger systems, such as blockchain, require Byzantine fault tolerance. That’s the case as the nodes that come into play in them aren’t necessarily known or trusted. Our efforts then have to do with stopping malicious actors or faulty systems from writing into our systems. In this sense, it may now be clearer why blockchain consensus algorithms are crucial to keep our financial and banking systems as secure as possible. 

David Benko’s webinar continues to expand on proof of work, another key aspect of the most popular consensus mechanisms that are heavily linked to current discussions in the fields of cryptocurrencies, distributed ledger technology, and much more. 

Watch the rest of the webinar. 

Was this article insightful? Then don’t forget to look at other blog posts and follow us on LinkedIn, Twitter, Facebook, and Instagram.

Author