Consensus Mechanisms in Consortia Blockchains

7 min readAug 14, 2020

Authors: Jonas Gross, Constantin Lichti, Martin Schäffner, Philipp Sandner

In our recent publication, we provided insights into the process of selecting the most suitable blockchain platform for a collaboration project in the manufacturing industry. After a blockchain framework has been selected, a proper consensus mechanism must be chosen and specified. The consensus mechanism defines how the agreement to a state of the data is achieved and under which conditions a transaction is considered valid. This article assists partners of a consortium with the selection process of a suitable consensus mechanism for their research project and provides insights from the KOSMoS project.

Background

The Frankfurt School Blockchain Center and the Datarella GmbH are part of the “KOSMoS” consortium, a research project funded by the German Federal Ministry of Education and Research (BMBF). Together with partners from the industry, academia, and software development, we create a blockchain-based solution allowing manufacturing companies to establish a DLT-based framework for producing machines in order to a) execute dynamic leasing contracts, b) to provide transparent maintenance documentation, and c)to ensure high-quality documentation of manufactured products. As discussed in our previous publication, we have decided to use Hyperledger Fabric as the underlying blockchain protocol. In the following article, we provide insights into the process of selecting the most suitable consensus mechanism for a private permissioned blockchain.

Consensus in Hyperledger

In Hyperledger Fabric, the process of finding a consensus can be split up into three phases:

Endorsement: An endorsement policy specifies the set of peers on a channel that must “endorse” (i.e., approve of) the execution of transactions.
Ordering: While the permissionless nature of Ethereum and Bitcoin allow any node to participate in the consensus process, Hyperledger Fabric features an “ordering node” that — along with other nodes — forms an ordering service. The ordering service ensures verification and ordering of transactions, creating blocks, and broadcasting blocks to peers.
Validation: Finally, any block — as generated by the ordering service — a peer validates is guaranteed to be final and correct as ledgers cannot fork the way they do in many other distributed blockchains.

This separation of the process of finding a consensus into the three steps creates a high degree of transparency about the current state of the data, enables combining different consensus services for all phases, and has the benefit that various transactions can be processed at the same time. The process of finding a consensus is illustrated in Figure 1.

Figure 1: Endorsement and consensus in Hyperledger

The data source, in our case, a manufacturing machine or an edge device, distributes the data in the network to all participating peer nodes. These nodes simulate the input data and give back the status ‘acknowledged’ or ‘not acknowledged’ to the orderer node in case the data is valid or not valid, respectively. If the orderer node receives a predefined ratio of ‘acknowledged’ messages, for example, more than two thirds from the participating peer nodes, the transaction is being confirmed and distributed back to the peer nodes as a finalized transaction.

Consensus mechanism comparison

Assuming that there is no full trust among all participants in the system, a consensus algorithm is necessary, which tolerates faulty nodes. We considered proof-of-work (PoW), proof-of-stake (PoS), proof-of-authority (PoA), a practical Byzantine Fault Tolerant (pBFT) consensus, and a Byzantine Fault Tolerant Raft (BFT Raft) as possible consensus mechanism candidates. However, most of these algorithms had significant limitations in the context of our project:

Proof-of-work: Due to the choice of a private blockchain system with only a few validating nodes, PoW was unsuitable because it limits scalability and transaction throughput. Furthermore, this consensus mechanism was seen as too energy inefficient.
Proof-of-stake: If a PoS consensus mechanism is applied, the probability that one party is selected to validate a transaction depends on its respective stake on the underlying crypto currency. In the case of KOSMoS, it is not intended that the validating nodes hold large stakes. Therefore, we decided not to use a PoS consensus.
Proof-of-authority: As another consensus mechanism, PoA was analyzed. Even if PoA is very energy efficient, the transaction validation process is highly centralized. If one party is selected to confirm transactions, then the other parties are not involved in the validation process. Due to a possible lack of trust with potentially malicious behavior of the validating nodes, this high degree of centralization is undesirable for the KOSMoS research project as there are different use cases with different and independent stakeholders.
Practical Byzantine Fault Tolerant (pBFT) consensus: To circumvent the limitation of a highly centralized consensus procedure, we decided to use a variant of a pBFT consensus mechanism. This mechanism enables all validating nodes to participate in the process of finding a consensus. If two-thirds of the validating nodes confirm a transaction, the transaction is conducted. By doing so, it tolerates one-third of malicious nodes and still achieves a consensus (thus, it has a certain fault tolerance). Therefore, the consensus finding process is more decentralized than PoA, but still remains energy efficient and tolerates faulty nodes. In the case of KOSMoS, there is only a small amount of validating nodes processing infrequent transactions. Therefore, pBFT remains energy efficient since only these few validating nodes have to confirm the transactions.
Byzantine Fault Tolerant Raft (BFT Raft) consensus: We decided to implement the pBFT-similar BFT Raft consensus mechanism. Raft is considered more reliable as it implements a leader election protocol between the participating nodes to achieve consensus. The leader election protocol ensures that the elected leader of the participating nodes always acts correctly. Due to the algorithm, the data received from the leader node is considered valid so that the nodes can integrate them without doubting the leader. Raft BFT operates in a highly performant manner as the algorithm only distributes hashes of data while pBFT distributes the raw data. pBFT has further disadvantages, e.g., it does not perform well during a view change that has to be processed once the leader node is detected faulty. Raft BFT in Hyperledger also brings an out-of-the-box Kafka as a reference implementation which makes it highly compatible with the edge gateway technology used in our research project.

Next steps

After we have successfully selected the most suitable consensus algorithm for the KOSMoS system, the next step is to define the rules for the access management of network participants by determining which actors can participate in the system and which rights they get assigned. Further, it will be defined, who can run a node, which rights and responsibilities the nodes will have, and how new nodes can be added to the system. One challenge is to make sure that the system is secured against unintended behavior. We will address the question if the system should be entirely decentralized where every participant has equal rights, or if the machine manufacturers will have slightly more power than their clients. Furthermore, it will be determined how organizations can access or create a channel and what happens if organizations violate the rules of the protocol.

These policies will be written down in a governance model, which all participants have to accept, in order to ensure that the KOSMoS system will be a suitable framework for machine manufacturers and their customers.

About KOSMoS

KOSMoS is a research project funded by the German Federal Ministry of Education and Research (BMBF) under the funding code 02P17D020. More information about the project can be found on the website.

Remarks

If you like this article, we would be happy if you forward it to your colleagues or share it on social networks. More information about the Frankfurt School Blockchain Center on the Internet, on Twitter, or on Facebook.

Jonas Gross is a project manager and research assistant at the Frankfurt School Blockchain Center (FSBC) and also works for the KOSMoS research project. His fields of interests are primarily crypto currencies. Besides, in the context of his Ph.D., he analyzes the impact of blockchain technology on the monetary policy of worldwide central banks. He mainly studies innovations as central bank digital currencies (CBDC) and central bank crypto currencies (CBCC). You can contact him via mail (jonas.gross@fs-blockchain.de), LinkedIn (https://www.linkedin.com/in/jonasgross94/) and via Twitter (@Jonas__Gross).

Constantin Lichti is a research assistant and project manager at the Frankfurt School Blockchain Center (FSBC), and also works for the KOSMoS research project. Furthermore, he is responsible for project proposals and grants as well as studies published at the FSBC. As a doctoral candidate his research interests cover blockchain themes in the light of digital transformation processes, especially the adoption of blockchain technology as well as the emergence of the global token market and digital business models based on blockchain technology. He graduated from the Technical University of Munich with a master’s degree in industrial engineering and management. You can contact him via mail (constantin.lichti@fs-blockchain.de) and LinkedIn (https://www.linkedin.com/in/constantin-lichti-5644b9109/).

Martin Schäffner is a Blockchain Architect at Datarella GmbH, a Munich-based blockchain solution provider that is also a participant in the KOSMoS project. His fields of interest are designing, managing and creating enterprise blockchain solutions. Martin did his Master’s at the Technical University of Munich in information systems and wrote his Master’s Thesis about analyzing and evaluating the Self-Sovereign Identity ecosystem. You can contact him via mail (martin.schaeffner@datarella.com) or via LinkedIn (https://www.linkedin.com/in/martinschaeffner/).

Prof. Dr. Philipp Sandner is head of the Frankfurt School Blockchain Center (FSBC) at the Frankfurt School of Finance & Management. In 2018, he was ranked as one of the “Top 30” economists by the Frankfurter Allgemeine Zeitung (FAZ), a major newspaper in Germany. Further, he belongs to the “Top 40 under 40” — a ranking by the German business magazine Capital. The expertise of Prof. Sandner, in particular, includes blockchain technology, crypto assets, distributed ledger technology (DLT), Euro-on-Ledger, initial coin offerings (ICOs), security tokens (STOs), digital transformation and entrepreneurship. You can contact him via mail (email@philipp-sandner.de) via LinkedIn (https://www.linkedin.com/in/philippsandner/) or follow him on Twitter (@philippsandner).