by Rebecca Johnson | 5 August 2020 | Ask Datarella, Blockchain
People in the blockchain space often throw around the words Byzantine Fault Tolerant (BFT) as though it was self-explanatory. Additionally, BFT often pops up in discussions about consensus mechanisms. If you look closer, in the consensus algorithm space there are lots of variants. there’s pBFT, Tendermint BFT, BFT Raft, IBFT, and Lisk BFT to name just a few. This short post seeks to clear up the confusion.
Let’s start with what BFT isn’t. BFT, or Byzantine Fault Tolerance is not a consensus method. It is not a security model. It is not a specific technology. It is not exclusive to blockchain or exclusively useful in blockchain systems.
A system can be described as Byzantine Fault Tolerant if it provides a method for solving the byzantine general’s problem. This is a problem in computer science wherein, the system handles malfunctioning or unreliable components that give conflicting information to different parts of the system.
Lamport, Shostak and Pease described it in a Microsoft research paper in 1982 thusly:
This situation can be expressed abstractly in terms of a group of generals of the Byzantine army camped with their troops around an enemy city. Communicating only by messenger, the generals must agree upon a common battle plan. However, one or more of them may be traitors who will try to confuse the others. The problem is to find an algorithm to ensure that the loyal generals will reach agreement.
Byzantine Fault Tolerant, is at its core, a term that works as an adjective, and which as we have seen is often integrated into the names of various technologies to describe what they do. Any technology or system that has mechanisms for disregarding unreliable inputs from dishonest participants and reliably agreeing on a global state with only valid inputs from honest players can be seen as Byzantine Fault Tolerant. As such there are many security models and consensus algorithms that can be said to be Byzantine Fault Tolerant.
Additionally, underlining the fact that BFT isn’t a security model or blockchain specific consensus algorithm, BFT architectures are commonly used in military command and control as well as spaceflight and aircraft control systems. Two prominent real-life examples of BFT systems outside the blockchain space include the ARINC 659 SAFEbus network used for flight control on the Boeing 777 and 787 aircraft and SpaceX Dragon Capsule systems for approaching the International Space Station in case of multiple computer failures.
by Martin Schäffner | 25 July 2019 | Blockchain, KOSMoS
We want to use the event of the 50th anniversary of the moon landing to give some updates on the KOSMoS project we are currently working on. Together with partners from the industry, university institutions and software development, we are continuously making one step after another to reach our goal, to deliver a blockchain-based solution which allows manufacturing companies to make use of dynamic leasing contracts with their customers, to get a valid and tamperproof maintenance documentation for their machines and to control the quality of the products based on predefined requirements.
In the beginning of July, teams from inovex, Ondics, University of Furtwangen and Datarella met at a workshop hosted and moderated by the Institute for Control Engineering of Machine Tools and Manufacturing Units (ISW) from the University Stuttgart.
Once there, we discussed possible interfaces between the machines, the edge gateway, the analysis tool, the global KOSMoS platform, and the blockchain. We were able to agree on a basic infrastructure plan. Going into greater detail, we also agreed upon how data to be transferred from one instance to the next one. Based on this infrastructure we are currently planning to develop a pilot that demonstrates a data workflow from an oil-pressure sensor of a machine over the blockchain to the cloud platform. This pilot should be finished within a few weeks.
Decision on Blockchain Technology and Consensus Algorithm
Moreover together with the Frankfurt School Blockchain Center, we decided to use Hyperledger Fabric technology as the underlying blockchain for the KOSMoS project. In addition to the fact that Hyperledger Fabric is very suitable for consortial blockchains, another big argument for using Hyperledger Fabric is channel functionality. Assuming we want only one single Blockchain for all the use cases, we need to make sure that the privacy concerns of the industrial partners are being respected. In Hyperledger Fabric, it is possible to channel connections between organizations in such a way, that the transactions are hidden from other participants on the blockchain. This protects the data from unintended sharing with others.
Another advantage of Hyperledger is the separation of the consensus in three phases ‘endorsement’, ‘ordering’ and ‘validation’. This creates more transparency about the current state of the data and also enables pluggable consensus services for all phases. We assume that there isn’t full trust among all participants in the system, so we need a consensus algorithm that tolerates faulty states. Because of this, we decided to implement the RAFT Byzantine Fault Tolerance consensus mechanism. This is practical especially for the ordering part where there is the highest probability of mixing up the order of the transactions. Raft-BFT in Hyperledger also brings an out-of-the-box Kafka as a reference implementation that makes it highly compatible with the edge gateway technology.
The next steps are actually implementing the blockchain for the project and connecting it to neighboring systems like the edge gateway and the KOSMoS platform.
