\section{Introduction}

\textbf{History.} In 2008, Satoshi Nakamoto first proposed Bitcoin \cite{nakamoto_bitcoin_2009} and ushered in a new chapter for digital currency. The blockchain technology that forms the foundation of digital currency has continued to receive worldwide interest, and blockchain applications now span the spectrum of use cases ranging from agriculture, sports, education and government \cite{Swan_2015}. At the heart of blockchain lies the consensus algorithm, where all nodes on the public ledger reach consensus in a distributed, untrusted environment. Thus, the consensus mechanism fundamentally determines the security, availability, and system performance of the entire blockchain system. The study of consensus mechanisms in the blockchain is of great significance to the scalability of the blockchain, since it determines the transaction processing speed and the security of the blockchain. The consensus mechanism, then, is of fundamental significance in the widespread adoption and consequent success of blockchain applications. 

Since the first whitepaper describing Nakamoto's vision for Bitcoin was published in 2008, several variants of cryptocurrencies have been released. Notable among them is Ethereum \cite{wood_ethereum_nodate} which introduced the concept of a smart contract. Smart contracts, which denote contracts in code on the blockchain, allow for the use of Ethereum as a platform for currency transactions. While Ethereum and Bitcoin have several notable differences in their architectures, one common aspect of Ethereum and Bitcoin is that they are both public blockchains since any node can join these networks and partake in the network activity. Their consensus mechanisms are similar. 

In 2015, the Linux Foundation initiated an open-source blockchain project called the Hyperledger project \cite{Androulaki_Barger}. While Bitcoin and Ethereum are opened to the public without any authentication mechanisms, Hyperledger is not a public blockchain. Instead, Hyperledger belongs to a class of blockchain solutions called enterprise blockchain, which is specifically designed for enterprise-level applications. Enterprise blockchain provides roles and permission for each member who participates in the blockchain. Moreover, Hyperledger eliminates the incentive mechanism presented by Bitcoin mining to save energy consumption and achieve better performance. With blockchain technology development, more and more enterprise-level users have begun to consider using blockchain to meet their business needs. For example, Walmart has implemented transparency in their food supply chain with Hyperledger Fabric, CULedger has instituted fraud-protection for credit unions with Hyperledger Indy, and Kubernetes uses the Hyperledger Sawtooth to simplify enterprise blockchain adoption \cite{hyperledger_walmart,hyperledger_culedger,hyperledger_kubernetes}. Therefore, the exploration of effective consensus protocols for use in consortium blockchains has developed into a research problem of emerging significance. 

The release of Facebook's Libra project white paper in 2019 \cite{libra_association_members_libra_2020} has led to a new round of cryptocurrency interest, which has attracted widespread attention from many investors and researchers in blockchain. Among the various applications of blockchain technology in the public and private sectors, one notable application is that of digital governance. In what is touted as Web 3.0, countries around the world have ventured to seize the opportunity of a new round of information revolution using blockchain. The use of blockchain technologies has accelerated the pace of industrial innovation and development. 
Subsequently, the requirements for consensus algorithms have also risen to a new level. Consensus protocols, such as LibraBFT \cite{libra_association_members_libra_2020}, not only are suitable for enterprise scenarios but also include many features of public blockchain consensus protocols, such as incentive mechanism. 

\textbf{Related Work.} Considering the importance of consensus mechanisms and rapid development of enterprise-level blockchains, this paper provides a comprehensive survey of enterprise-level blockchain consensus protocols. There have been many surveys on blockchain technologies in the past, ranging from survey on public blockchain \cite{publicblockchainsurvey} to survey on blockchain applications \cite{Thakur_Kulkarni_2017, casino2019systematic, zou2020focus}. Regarding surveys on blockchain consensus protocols, we also identified multiple surveys either published \cite{Consortium, Nguyen_Survey} or presented on arXiv \cite{Salimitari_Chatterjee_2019, Xiao_Zhang_Lou_Hou_2019, Cachin2017BlockchainCP}. However, none of them have presented a comprehensive survey covering all the important concurrent consensus protocols for consortium blockchains as this survey. Nguyen et al. \cite{Nguyen_Survey} provides a tutorial style review on distributed consensus protocols
This survey classifies consensus algorithms into proof-based and voted-based on the mechanism of reaching consensus. Its focus is more on public chain. Important protocols, such as RBFT, HotStuff and LibraBFT are not covered. Salimitari et al. \cite{Salimitari_Chatterjee_2019} studies consensus algorithms and their applicability in the IoT areas. Similar as \cite{Nguyen_Survey}, multiple important protocols, such as LibraBFT, are missing. 
Cachin et al. \cite{Cachin2017BlockchainCP} provides an overview of blockchain consensus protocols for both public blockchains and consortium blockchains. However, some blockchains, such as Ripple and Stellar, have changed their consensus algorithms since the analysis of the paper. In addition, some important protocols, such as HotStuff, is not mentioned. 
The survey of Ferdous et al. \cite{Ferdous2020BlockchainCA} also miss multiple important protocols. 

\textbf{Contributions.} This survey presents a comprehensive exploration of current enterprise-level blockchain consensus protocols. The main contributions of our article are as follows.

\begin{itemize}
    \item A tutorial-style introduction to the background of blockchain technology and its relationship to distributed systems and consensus mechanisms. 
    \item Establishment of a new taxonomy of the attributes of consensus protocols, covering different aspects of consensus algorithms. In this classification, consensus algorithms are divided into two categories, which are Crash Fault Tolerance (CFT)-based and Byzantine Fault Tolerance (BFT)-based. 
    \item An analytical illustration of the Byzantine fault tolerance problem and a detailed explanation of how consensus is achieved in mainstream BFT algorithms.
    \item An introduction to application scenarios and well-known platforms of consensus algorithms.
    \item A detailed comparison of consensus algorithms regarding five key aspects, which are fault tolerance, performance, degrees of decentralization, scalability and recourse consumption.
\end{itemize}

The rest of this paper is structured as follows. Section 2 provides an overview of blockchain technology. Section 3 introduces different families of consensus protocols and illustrates two Crash Fault Tolerance (CFT)-based consensus mechanisms. Section 4 addresses variants of the Byzantine Fault Tolerance (BFT)-based consensus algorithm in consortium blockchains. Section 5 evaluates, analyzes and compares the consensus algorithms demonstrated in this paper. Section 6 presents challenges and future works. Finally, Section 7 concludes the paper.




\section{Blockchain overview}
The goal of the consensus protocol in blockchain technology is to achieve consistency of nodes participating in the distributed ledger. The nomenclature of \textit{blockchain} is derived from its architecture; each block is linked cryptographically to the previous block. Generally speaking, the first block of the blockchain is called the \textit{genesis block}, and each block contains a set of transactions generated in the network at a given time.

Blockchain has the following characteristics - decentralization, trustlessness, openness, immutability and anonymity. First, decentralization refers to the absence of a central trusted third party in the network, unlike those found in centralized transactions. Examples of centralized environments include governments, banks, or other financial institutions which serve to regulate various aspects of interactions between entities. Trustlessness denotes the lack of formal social constructs for nodes to establish trust-based on prior history, familiarity or a guarantee from a third party. Instead, trust is established through consensus on the ledger. Third, blockchain enables openness and transparency. In public blockchains such as Bitcoin, which are also called permissionless blockchains, all nodes can join and exit at any time, and nodes can obtain the historical ledger data of the blockchain at any time ranging back to the genesis block. The fourth defining characteristic of blockchain is the blockchain's immutability which ensures that it is tamper-proof. An example of a tamper-proof implementation is illustrated through Bitcoin's depth constraints. In Bitcoin, when the ``depth" of the block exceeds 6, it is established that the content of the block will not be tampered with \cite{bitcoin_wiki_faq}. Finally, blockchains ensure some degree of anonymity. Although Bitcoin is not completely anonymous, privacy-protection technologies, such as group signatures, ring signatures, and zero-knowledge proofs implemented in other blockchain solutions \cite{Bernal} can effectively increase user privacy on the blockchain.

\subsection{Model and Definition}
\subsubsection{State Machine Replication}
State machine replication (SMR) refers to the existence of a set of distributed nodes that can process and respond to requests from a $client$. The client can be software or a user and serves to jointly maintain a linearly growing log, with each node agreeing on the content of the log \cite{Schneider_1990}.

In the SMR mode, there is a $primary$ node, and the other nodes are called backups or $replicas$. The primary node's identity can change. State machine replication is fault-tolerant, allowing a certain percentage of nodes to fail or suffer from adversary attacks within a tolerable range. SMR needs to satisfy two essential security properties.
\begin{enumerate}
    \item Consistency. All honest nodes end up with the same logs in their output.
    \item Liveness. A transaction received by an honest node appears in the logs of all honest nodes after a specific time.
\end{enumerate}

\subsubsection{Adversary model}
In cryptography terminology, an adversary represents a malicious entity that aims to prevent non-malicious entities from achieving their goal \cite{Adversary_2020}. 
An adversary model is a model that imposes a specific limit on the percentage of computing power or property that an adversary can hold, generally represented by $f$ for the number of adversaries and $n$ for the total number of nodes in the network. For example, if a BFT algorithm's adversary model is $n = 3f + 1$, it implies that if the algorithm can tolerate $f$ faulty replicas, the system requires a minimum number of $n = 3f + 1$ replicas.

\subsection{Blockchain Architecture}
The basic framework of the blockchain is shown in Figure \ref{fig:archi}. The framework comprises the infrastructure layer, the network layer, the data layer, the consensus layer, and the application layer. In the core framework, the data layer includes the data blocks, the chain structure, and the cryptographical mechanisms that are the essential components of the blockchain \cite{Zhang_Xue_Liu_2019}. The data layer is responsible for blockchain transactions and implementation mechanisms, as well as related technologies for block propagation verification. The consensus layer is mainly a consensus mechanism represented by algorithms such as Proof of Work (PoW) used in Bitcoin, and Proof of Stake (PoS) used in Ethereum. In the application layer, various application scenarios and cases represented by programmable assets such as currencies and financial instruments, various script codes and smart contracts are encapsulated.

\begin{figure}[htp]
    \centering
    \includegraphics[width=12cm]{i1_archi.png}
    \caption{Blockchain Architecture}
    \label{fig:archi}
\end{figure}

\subsubsection{Infrastructure Layer}
The infrastructure layer contains hardware, network architecture equipment, and deployment environment for a blockchain system such as virtual machine and docker container.

\subsubsection{Network Layer}
The blockchain's network layer includes the blockchain system's node organization method and propagation verification mechanisms of the transaction and the block. A newly generated block can only be recorded in the blockchain after it has passed the verification.

Blockchains use P2P networks and are connected via a flat topology. Network nodes generally have the characteristics of equality, distribution, and autonomy. Each node in the P2P network undertakes node discovery, connection establishment, block synchronization, transaction broadcasting and verification, and block propagation and verification. After the new node is connected to the network, it establishes reliable connections to other nodes through the Transmission Control Protocol (TCP) three-way handshake. Once the connection is established, the new node continuously receives broadcast messages from the connected node and store the unknown nodes' address information from the connected node by broadcast message. Since the broadcast message from a node includes the information of all its connected nodes, eventually the new node can establish connections with all nodes in the blockchain \cite{Mao_Deb_Venkatakrishnan_Kannan_Srinivasan_2020}. With the establishment of the connection, the new node also synchronizes the block information from connected nodes. It can then start to work as a fully functional node to submit and verify transactions if the information of all blocks has been synchronized to the new node \cite{Mao_Deb_Venkatakrishnan_Kannan_Srinivasan_2020}.

When a new block is successfully generated, the node that generated the block will broadcast the block to other nodes in the network for verification. After a node receives the new block information, it verifies the block through a list of criteria. For instance, some of the criteria used in the verification process of a block in Bitcoin include the block hash, block timestamp, hash of the previous block and hash of the Merkle Root \cite{bitcoin_wiki}. If the block is verified to be invalid, it will be rejected. Otherwise, the new block will be appended after the preceding block is found on the chain. 

From the network layer's design principles, it is clear that blockchain is a typical distributed big-data technology. The entire network's data is stored on completely decentralized nodes. Even if some nodes fail, as long as there is still a functioning node, the data stored in the blockchain can be fully recovered without affecting the subsequent blocks. The difference between this blockchain model and the cloud storage model is that the former is an entirely decentralized storage model with a higher level of storage capacity, while the latter is based on a centralized structure with multiple storages and data backup functionalities.

\subsubsection{Data Layer}
The data in this layer is recorded through the blockchain structure, as shown in Figure \ref{fig:chain}. The data layer realizes the requirements of traceability and non-tampering. Any data in the blockchain system can be tracked through this chain ledger \cite{Paik_Xu_Bandara_Lee_Lo_2019}.
      
    \begin{figure}[htp]
        \centering
        \includegraphics[width=12cm]{i2_chain.png}
        \caption{An example of chain structure in blockchain \cite{bitcointWebPage}}
        \label{fig:chain}
    \end{figure}
      
For example, in Bitcoin, each data block comprises a block header and a block body containing a packaged transaction, shown in Figure \ref{fig:block}. The block header contains information such as the current system version number, the hash value of the previous block, the difficulty target of the current block, the random number, the root of the Merkel tree of the block transaction, and the timestamp \cite{nakamoto_bitcoin_2009}. The block body includes many verified transactions and a complete Merkel tree composed of these transactions \cite{Szydlo_2004}. The Merkle tree is a binary tree, where the bottom layer corresponds to the content of the leaf node. Each leaf node is the hash value of the corresponding data. Two neighboring leaves unite to perform a hash computation that becomes the content of the upper-level node. A recursive form of these computations forms the content of the root node. Based on the Merkle tree's particular date structure, any data modification that happens in the leaf node will be passed to its parent node and will propagate all the way to the root of the tree. The data in the block body constitutes the central part of the blockchain ledger. The Merkel tree formed by these transactions generates a unique Merkel root and stores it in the block header. The block header data is double-SHA256 hashed to get the hash value of the block \cite{article}. 

    \begin{figure}[htp]
        \centering
      \includegraphics[width=10cm]{i3_block.png}
        \caption{An example of a block in Bitcoin \cite{Blockchain_for_Dynamic_Spectrum_Management}}
        \label{fig:block}
    \end{figure}
        
\subsubsection{Consensus Layer} 
The consensus layer forms the core of the consensus process used to determine the validity of the block data by the highly decentralized nodes. The main consensus mechanisms are Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), and Practical Byzantine Fault Tolerance (PBFT), which have been the backbone of scalable solutions in blockchain technology. A particular economic incentive model used to encourage nodes to participate in the blockchain's security verification work is only used in an incentive mechanism-based algorithm, such as PoW.

\subsubsection{Application Layer}
The application layer encapsulates various script codes, smart contracts, Decentralized Applications (DApps) and Application Programming Interfaces (APIs). 

\begin{enumerate}
    \item \textbf{Script}. A script is essentially a set of instruction lists attached to a Bitcoin transaction. Bitcoin uses a simple, stack-based, left-to-right scripting language. Bitcoin transactions are verified through two scripts: locking script and unlocking script. The locking script specifies the conditions for spending the output of this transaction, and the output of this transaction can only be spent if the conditions of the locking script are met. The unlocking script corresponds to the locking script, a script that meets the transaction cost conditions. If a node receives transaction data, it runs locking scripts and unlocking scripts to check whether the transaction is valid, before accepting it \cite{nakamoto_bitcoin_2009}. The locking and unlocking of scripts provide flexible transaction control in Bitcoin. 
    The Bitcoin script system does not have complex loops and flow control, and it is not Turing-complete. A Turing-complete system means that a program written in this system can find a solution, and there is no limitation on time-consumption and memory usage. The Bitcoin script is not Turing-complete, because it has no conditional statements, cannot execute loops, and does not produce recursion. To improve the flexibility and scalability of the scripting system, Ethereum proposes a Turing-complete scripting language, which allows users to construct smart contracts and decentralized applications flexibly based on Ethereum \cite{Dannen_2017}.
    \item \textbf{Smart Contract}. The emergence of blockchain technology has redefined smart contracts. Smart contracts are event-driven, stateful computer programs running on a replicable shared blockchain data ledger that can actively or passively process data and manage various on-chain smart assets. Smart contracts are embedded programmatic contracts that can be built into any blockchain data, transaction, tangible or intangible asset. Thus, smart contracts create software-defined systems, markets, and assets that can be programmatically controlled. Smart contracts provide innovative solutions for issuing, trading, creating, and managing traditional financial assets and play an essential role in asset management, contract management, and regulatory enforcement in social systems.
    \item \textbf{DApp}. A DApp is defined as an application that runs on a distributed network, where participants' information is securely protected (and possibly anonymous) and decentralized through network nodes. A DApp in the blockchain generally meets the following three conditions.
        \begin{enumerate}
            \item The application normally is open-source, and most of them can run autonomously rather than controlled by a single entity. All data and records should be stored on the blockchain through some cryptographic technologies.
            \item The application generates tokens through a set of criteria and allocates partial or whole tokens. Any user who contributes is rewarded with tokens paid by the application.
            \item The application can improve and adjust its protocols based on business requirements, but all changes have to be agreed upon by the majority of users.
        \end{enumerate}
    \item \textbf{APIs}. Blockchain provides documented APIs in the application layer for development, thus allowing DApps and third-party applications the ability to handle smart contracts and retrieve data from the blockchain platform.
\end{enumerate}

The infrastructure layer, network layer, data layer, and consensus layer can be envisioned as the blockchain's underlying virtual machine, and the application layer comprises the business logic, algorithms, and applications built on the blockchain virtual machine, as shown in Figure \ref{fig:virtual}.

\begin{figure}[htp]
    \centering
    \includegraphics[width=10cm]{i4_virtual.png}
    \caption{Five layers model to virtual machine model}
    \label{fig:virtual}
\end{figure}

\subsection{Classification of blockchain networks}

Blockchain networks can be classified as public, consortium or private blockchain in order of decreasing degrees of openness available for participation by nodes, as shown in figure \ref{fig:threeTypes}. Here, we provide a brief overview of the three architectures.

\begin{figure}[htp]
    \centering
    \includegraphics[width=12cm]{i5_b_types.png}
    \caption{Public, Consortium, and Private Blockchain}
    \label{fig:threeTypes}
\end{figure}

\subsubsection{Public blockchain}
The public blockchain is also referred to as a permissionless blockchain, since any node can enter and exit the network freely. The public chain is the earliest and most widely used blockchain architecture. Bitcoin is the most widely known example of the public blockchain \cite{VRANKEN20171}. Every participant in the blockchain can view the entire ledger data in the public blockchain, and any public blockchain participant can freely execute transactions with other nodes on the public chain. Further, anyone on the public chain can participate in the blockchain consensus process for mining, i.e. any node can decide exactly which blocks should be added to the blockchain and participate in recording the current network status. Thus, the public chain is a completely decentralized blockchain. Users of the public chain can participate anonymously without registration and can access the blockchain network and view data without authorization. Additionally, any node can choose to join or exit the blockchain network at any time \cite{Yaga_Mell_Roby_Scarfone_2018}. The public chain uses cryptography-related technologies such as digital signatures, hashing \cite{Dods_Smart_Stam_2005}, symmetric/asymmetric keys \cite{7086640}, and  Elliptic Curve Digital Signature Algorithm (ECDSA) \cite{Johnson_Menezes_Vanstone_2001} to ensure that transactions cannot be tampered with. Economic incentives such as transaction fees and rewards are adopted so that the consensus node is motivated to participate in the consensus process, which in turn serves to maintain the security and effectiveness of the decentralized blockchain system. The consensus mechanism in the public chain is generally PoW (Bitcoin) or PoS (Ethereum). Under the PoW mechanism, nodes compete for the right to confirm a transaction and getting the associated rewards through computing power, while under the PoS mechanism, users compete for these rights through collecting resources. Section 2.4 elaborates on the different families of consensus protocols.

\subsubsection{Private blockchain}
The private blockchain is also known as the permissioned blockchain, and is only used in private organizations or institutions \cite{Thakur_Kulkarni_2017}. Unlike public blockchains, private blockchains are generally not open to the outside world and are only open to individual individuals or institutions. Data read and write permissions on the private blockchain and block accounting rights are allocated under the rules established by private organizations. Specifically, each node's writing rights in the private chain system are allocated by the organization, and the organization decides how much information and data is open to each node according to the specific conditions of the actual scenarios. The private chain's value is mainly to prevent internal and external security attacks on data and provide users of the private chain with a safe, non-tamperable, and traceable system. From the above description, it can be seen that the private chain is not a completely decentralized blockchain. Instead, there is a certain degree of centralized control. Compared with public chains, private chains sacrifice complete decentralization in exchange for increased transaction speed. 

\subsubsection{Consortium blockchain}
The consortium blockchain is a hybrid architecture comprising of features from both public and private blockchains. A consortium blockchain is also a permissioned blockchain, in which participation is limited to a consortium of members to participate; each node might refer to a single organization or institution in the consortium. The number of nodes in a consortium blockchain is determined by the size of the pre-selected participants in the blockchain. For example, suppose a financial blockchain is designed for a consortium of thirty financial institutions. In that case, the maximum number of nodes in this consortium blockchain is thirty, and the number of nodes required to reach the consensus depends on which consensus algorithm the consortium blockchain uses. The consortium chain accesses the network through the gateways of member institutions. The consortium chain platform generally provides members' information authentication, data read and write permission authorization, network transaction monitoring, member management, and other functions. Each member can have permissions assigned by the consortium to access the ledger and validate the generation of blocks. The well-known Hyperledger project is an example of a consortium blockchain. Since there are relatively few nodes participating in the consensus process, the consortium blockchain generally does not use the PoW mining mechanism as the consensus algorithm. Consortium chains' requirements for transaction confirmation time and transaction throughput are very different from those of public chains.

The following Table \ref{tab:compNetwork} shows a comparison between the three different types of blockchain. 

\begin{table*}[htp]
\caption{Comparison of three blockchain networks}
\label{tab:compNetwork}
   
    \begin{threeparttable}
    \begin{tabular}{p{0.25\textwidth}p{0.25\textwidth}p{0.25\textwidth}p{0.25\textwidth}}
    \toprule
    \textbf{Property} & \textbf{Public} & \textbf{Private} & \textbf{Consortium}\\
    \midrule
    \textbf{Infrastructure} & Highly Decentralized. & Distributed. & Decentralized. \\
    \textbf{Permission} & Permissionless. & Permissioned. & Permissioned. \\
    \textbf{Governance Type} & Public. & Consensus is managed by a single node. & Consensus is managed by a consortium of participants. \\
    \textbf{Validator} & Any node or miner. & A set of authorized nodes. & A set of authorized nodes.\\
    \textbf{Transactions Throughout} & Low ($\leq 100$ TPS\tnote{*} ). & High ($> 100$ TPS) & High ($> 100$ TPS)\\
    \textbf{Network \newline Scalability} & High. & Low. & Medium. \\
    \textbf{Example} & Bitcoint, Ethereum. & Quorum, SoluLab. & HyperLedger, Tendermint, Corda R3. \\
    \bottomrule
    \end{tabular}
    \begin{tablenotes}
        \small
        \item[*] TPS: Transactions per second
    \end{tablenotes}
    \end{threeparttable}
\end{table*}

\subsection{Consensus algorithm classification}
In this section, we will provide a brief overview of the different types of consensus algorithms. There are two ways in which consensus algorithms may be classified. 

One way of classifying consensus algorithms is by the approach of making a final decision to reach a consensus \cite{Nguyen_Survey}. The first category is \textit{proof-based} consensus algorithms, since a node in this category has to compete with other nodes and prove it is more qualified to commit transactions. PoW \cite{nakamoto_bitcoin_2009}, PoS \cite{King_Nadal}, Proof of Authority (PoA) \cite{VeChain_Whitepaper}, Proof of Elapsed Time (PoET) \cite{poet}, and Proof of Space (PoSpace) \cite{cryptoeprint:2013:796} are algorithms in this group. The other category is that of \textit{voting-based} algorithms since the commitment depends on which committed result wins the majority of votes. Paxos \cite{lamport_paxos_2001}, Raft \cite{ongaro_search_2014}, PBFT \cite{castro_practical_1999}, RFBT \cite{aublin_rbft_2013}, RPCA \cite{Schwartz2014TheRP}, SCP \cite{mazieres_stellar_2015}, Tendermint \cite{Tendermint}, and HotStuff \cite{yin_hotstuff_2019} belong to this category. Figure \ref{fig:classification2} shows the classification of blockchain consensus algorithms by working mechanism. The first group of consensus is proof-based, while the second group is voting-based.

\begin{figure}[htp]
    \centering
    \includegraphics[width=10cm]{i6_consensus_classification2.png}
    \caption{Classification of Blockchain Consensus Algorithm by mechanism}
    \label{fig:classification2}
\end{figure}

The second way of classifying consensus algorithms is by the design principle of fault tolerance. Nodes can suffer from non-Byzantine error (Crash Fault), which is exemplified by situations where the node fails to respond. Alternatively, nodes can forge or tamper with the information and respond maliciously, causing Byzantine errors (Byzantine Fault). Thus, consensus algorithms may be classified as being designed for Crash Fault Tolerance (CFT) or Byzantine Fault Tolerance (BFT). It is important to note that this classification method only focuses on the original design principle; most BFT-based consensus algorithms can tolerate either crash fault or Byzantine fault. Since the design principle of algorithms in the previous proof-based family is very different from fault tolerance, those proof-based families will be excluded in this classification.  

Paxos \cite{lamport_paxos_2001}, Raft \cite{ongaro_search_2014}, and Zab \cite{Junqueira_Reed_Serafini_2011} belong to the category of CFT-based consensus algorithm. A collection of variants of PBFT \cite{castro_practical_1999} algorithms, such as RBFT \cite{aublin_rbft_2013}, SBFT \cite{Gueta_Abraham_Grossman_Malkhi_Pinkas_Reiter_Seredinschi_Tamir_Tomescu_2019}, BFT-SMART \cite{bessani_state_2014}, DBFT \cite{neo_project}, and HotStuff \cite{yin_hotstuff_2019}, are in the category of BFT-based consensus algorithm. Another collection of consensus algorithms in the same category uses Byzantine Federated Agreement (BFA) \cite{mazieres_stellar_2015}  for voting, such as RPCA \cite{Schwartz2014TheRP} and SCP \cite{mazieres_stellar_2015}. Figure \ref{fig:classification} shows a classification of blockchain consensus algorithm by fault tolerance.
 
\begin{figure}[htp]
    \centering
    \includegraphics[width=10cm]{i7_consensus_classification1.png}
    \caption{Classification of Blockchain Consensus Algorithm by Fault Tolerance}
    \label{fig:classification}
\end{figure}

Section 3 presents CFT algorithms, and Section 4 presents BFT algorithms.

		
\section{CFT Consensus Mechanisms in Consortium Blockchain}

\subsection{The CFT Problem}
CFT consensus algorithms only guarantee a blockchain's reliability and resiliency to blockchain node failure. Also known as non-Byzantine errors, node failures can be caused by failed hardware, crashed processes, broken network, or software bugs. CFT can not address scenarios where malicious activities are involved, referred to as Byzantine errors. When nodes in a blockchain intentionally and maliciously violate consensus principles, e.g., tampering with data, a CFT algorithm can not guarantee the system reliability. Thus, CFT consensus algorithms are mainly used in closed environments such as enterprise blockchains. Current mainstream CFT consensus algorithms include the Paxos algorithm and Raft. The latter is a derivative of the former and is a simplified consensus algorithm designed to be more suitable for industry implementation than the original Paxos. 

\subsection{Paxos}
Paxos \cite{lamport_paxos_2001} is a fault-tolerant consensus algorithm based on message passing in a distributed system. The Paxos algorithm divides nodes into three roles: $proposer$, $acceptor$, and $learner$. Each role corresponds to a process on the node, and each node can have multiple roles simultaneously.

A proposer is responsible for proposing a proposal and for awaiting responses from acceptors. An acceptor is responsible for voting on the proposal. A learner is informed of the proposal's result and follows the results, but it does not participate in voting. 

A proposal consists of a key-value pair formed by a proposal number and a value. The proposal number ensures the proposal's uniqueness, and the value represents the content of the proposal itself. A value of $Chosen$ indicates that the proposal has been selected. When more than half of the acceptors approve a proposal, the proposal is considered Chosen.

The Paxos algorithm meets the constraints of $safety$ and $liveness$, which are described below.

\begin{itemize}
  \item Safety ensures that the decision is correct and not ambiguous. The safety constraint has the following requirements. Only the value proposed by the proposer can be chosen. Further, only one decision value can be chosen, and the process can only obtain those values that are actually chosen.
  \item Liveness guarantees that the proposal will be completed within a limited time. The value proposed by the proposer cannot be learned until it has been chosen.
\end{itemize}

The Paxos algorithm's consensus process begins with a proposer, who puts forward a proposal to win the support of the majority of acceptors. When a proposal proposed by a proposer receives more than half of the approval of acceptors, the proposer sends the result to all nodes for confirmation. In this process, if the proposer fails due to a crash, it can be solved by triggering the timeout mechanism. If the proposer happens to fail every time a new round of proposals is proposed, then the system will enter a livelock status and never reach an agreement \cite{Wen-Cheng_Shi_Jian-Ping_Li_2012}.

The Paxos algorithm execution is divided into two phases shown in figure \ref{fig:paxos}. In the \textbf{PREPARE} phase,the proposer sends a $prepare$ request with a proposal number to more than half of the acceptors in the network. The purpose of this initial transmission of the proposal number is to test whether the majority of acceptors are prepared to accept the proposal. After receiving the proposal, the acceptor will always store the largest proposal number it has received. When an acceptor receives a $prepare$ request, it will compare the currently received proposal's number and the saved largest proposal number. If the received proposal number is greater than the saved maximum proposal number, it will be accepted and included in a message called $promise$, which it returns as the response to the proposer. The internally saved largest proposal number is updated simultaneously and the acceptor will promise not to accept any proposal with a number less than the proposal number that is currently received.

\begin{figure}[htp]
    \centering
    \includegraphics[width=12cm]{i8_paxos.png}
    \caption{Paxos two phases.\cite{8726773}}
    \label{fig:paxos}
\end{figure}

In the \textbf{ACCEPT} phase, if the proposer receives more than half of the responses as $promise$ messages, it will broadcast an $accept$ request with the proposal. This $accept$ request consists of a proposal number and the value that the node would like to propose. Note that if the response message received by a proposer does not contain any proposal, the value is determined by proposer itself. However, if the response message retrieved by the proposer contains a proposal, the value will be replaced by the value in the response that contains the largest proposal number. After the acceptor receives the $accept$ request, if it finds that the proposal number in the $accept$ request is not less than the maximum proposal number promised by the acceptor, it will accept the proposal and update the accepted maximum proposal. If a majority of acceptors accept the proposal, then the proposed value is $chosen$, which means the cluster of all proposers and acceptors has reached consensus.

In the $n = 2f + 1$ model, Paxos can tolerate $f$ crashing nodes and implements a consensus algorithm based on message-passing. Paxos is fault-tolerant only for for crashed nodes, not for Byzantine nodes. This is because a Byzantine node can always try and find out a number larger than the current maximum proposal number, either to mess up other nodes’ efforts to reach a consensus or to force other nodes to accept its proposed incorrect value.

\subsection{Raft}
Raft \cite{ongaro_search_2014}, formally known as the Raft Consensus Algorithm, is motivated by Paxos. Raft is designed for ease of understandability and implementability for industry applications. Its core idea is that servers start from the same initial state and execute a series of command operations in the same order. The goal of Raft is to achieve a consistent state. Therefore, Raft uses the log method for synchronization, which is a consistent algorithm for managing replicated logs. 

The Raft algorithm divides nodes into three mutually-convertible roles: $leader$, $follower$, and $candidate$. There can be at most one leader in the entire cluster. The minimum size of a cluster is five nodes. The leader is responsible for receiving client requests, managing replication logs, and maintaining communication with followers.

Initially, all servers are followers. A follower, passively responds to the Remote Procedure Call (RPC) requests from the leader. Followers do not communicate with each other since they are passive nodes. A follower is responsible for responding to log replication requests from the leader and responding to election requests from candidate nodes. If a follower receives a request from the client, the follower forwards it directly to the leader. 

In Raft, a candidate is responsible for initiating election voting. If the leader goes down due to a crash or loses network connectivity, one or more nodes will change their role from follower to candidate and initiates an election to elect a new leader. Once a candidate node wins an election, its status is changed from candidate to leader, and it still has a chance to convert back to a candidate if a new leader is elected but then fails. Figure \ref{fig:raft} shows how the three roles change states. $Term$ in the figure is represented by a continuously increasing number. Each round of election is a term, and each term elects only one leader. 

\begin{figure}
    \centering
    \includegraphics[width=10cm]{i9_raft.png}
    \caption{Server states. \cite{ongaro_search_2014}}
    \label{fig:raft}
\end{figure}

The Raft algorithm consensus process runs in two phases. The first phase is the leader election, triggered by a $heartbeat$ mechanism. A leader sends a heartbeat message to all followers periodically, to maintain its authority. If a follower does not receive the heartbeat message for a period of time, denoted by $election$ $timeout$, it switches to the candidate role and starts a leader election process since it is determined that the leader has failed \cite{ongaro_search_2014}. Then, it increases its current term, canvasses for itself, sends RequestVoteRPC to other servers, and waits for the following any of the following three situations to occur:

\begin{enumerate}
    \item A candidate wins the election. This implies that the candidate has won more than half of the server votes, and it will become a leader.
    \item A candidate loses the election, which means another server has won more than half of the votes and has received the corresponding heartbeat, thereby leading to the candidate becoming a follower.
    \item If no one wins the election, after a randomized timeout, the election is re-initiated and the term increases. 
\end{enumerate}

The second phase is the log replication phase, where the leader accepts the client's request, updates the log, and sends a heartbeat to all followers. Consequently, all followers synchronize the leader's log.



\section{BFT Consensus Mechanisms in Consortium Blockchains}

\subsection{BFT}
In 1982, Leslie Lamport, Robert Shostak, and Marshall Pease proposed the Byzantine Generals problem \cite {lamport_byzantine_1982}. The Byzantine Generals problem is described as follows. Suppose there are several Byzantine armies camping outside an enemy city, and each army is commanded by a general. The generals can only communicate with each other by dispatching a messenger who carries messages \cite{lamport_byzantine_1982}. After observing the enemy's situation, they must agree on an identical plan of action. However, there are some traitors among these generals, and these traitors will prevent loyal generals from reaching an agreement. The generals should legislate an algorithm to guarantee that all loyal generals reach a consensus, and that a small number of traitors will not cause a loyal general to adopt the wrong plan. 

Let $v(i)$ represent the information sent by the $i$-th general. Each general draws up a battle plan based on $v(1)$, $v(2)$, $\cdots$, $v(n)$, where $n$ is the number of generals. The problem can be described in terms of how a commanding general sends an order to his lieutenants. Therefore, the problem will be transformed into the following $Byzantine$ $General$ $Problem$: A commander sends an order to his $n-1$ lieutenants such that: 

\begin{itemize}
    \item $IC1$. All loyal lieutenants obey the same order.
    \item $IC2$. If the commander is loyal, then each loyal lieutenant must obey his orders.  
\end{itemize}

The above $IC1$ and $IC2$ are conditions for interactive consistency, which is a configuration that includes the number of generals in a final agreement \cite{lamport_byzantine_1982}. It has been shown that if there are $m$ traitors and the total number of generals is less than $3m+1$, the Byzantine generals problem has no solution.

An example of the Byzantine generals problem is shown in Figure \ref{fig:bft1}. Here, the commander and Lieutenant 1 are loyal, and Lieutenant 2 is a traitor. The commander sends an attack order to all lieutenants. Lieutenant 2 is a traitor, and he/she deceives Lieutenant 1 by sending a tampered message called "retreat". Since Lieutenant 1 does not know whether the commander or Lieutenant 2 is a traitor, he/she cannot judge which message includes the correct information and thus, cannot reach a consensus with the loyal commander.

\begin{figure}[htp]
    \centering
    \includegraphics[width=9cm]{i10_bft1.png}
    \caption{Byzantine General Problem with three participants and one traitor (lieutenant) \cite{lamport_byzantine_1982}}
    \label{fig:bft1}
\end{figure}

In another case shown in Figure \ref{fig:bft2}, the two lieutenants are loyal, and the commander is a traitor. The commander sends different orders to the two lieutenants. Lieutenant 2 conscientiously delivered the information of the commander to Lieutenant 1. Lieutenant 1 can not judge which information is correct, resulting in two loyal lieutenants not reaching a consensus.

\begin{figure}[htp]
    \centering
    \includegraphics[width=9cm]{i11_bft2.png}
    \caption{Byzantine General Problem with three participants and one traitor (commander) \cite{lamport_byzantine_1982}}
    \label{fig:bft2}
\end{figure}

If there are $m$ traitors and the total number of generals $n$ is less than $3m + 1$, the Byzantine generals problem has no solution. Unlike CFT problems that deal with crashes or failures, a Byzantine fault, named after Byzantine generals problem, is caused by malicious nodes which may send incorrect information to prevent other nodes from reaching consensus. In distributed systems, the Byzantine Generals problem translates to the inability in maintaining consistency and correctness under certain conditions. 

Lamport proposed a BFT algorithm to solve the Byzantine generals problem in exponential time $O(n^f)$ if the adversary mode is $n = 3f + 1$ \cite {lamport_byzantine_1982}. This original BFT algorithm is computationally expensive to implement, and a practical BFT algorithm is introduced in the next section. 

\subsection{PBFT}
Practical Byzantine Fault Tolerance (PBFT) is a consensus algorithm based on state machine replication \cite{castro_practical_1999}. As a state machine, services are replicated in different nodes of a distributed system. Each copy of the state machine saves the state of the service and the operations it implements. This algorithm can ensure the system's regular operation when the proportion of nodes with errors does not exceed a third of the total number of nodes. The idea is to let every node receive a message asking about the content of the message received by other nodes. 

The adversary mode of PBFT is $n = 3f + 1$, and it ensures that the system which contains $n$ nodes can reach a consensus if the number of faulty nodes $f$ does not exceed 1/3 of $n$. In the PBFT algorithm, there is one primary node out of $n$ nodes, and other backup nodes called replicas. The PBFT consensus mechanism reaches a consensus through three phrases: $pre$-$prepare$, $prepare$, and $commit$. Another important mechanism in the PBFT algorithm is view-change. When the primary node fails, and cannot process the data request within a specified time, other replicas initiate a view-change, and the new primary node starts to work after the conversion is successful. 

The processes of reaching consensus in the PBFT algorithm is as follows:
\begin{enumerate}
  \item Propose. The client uploads the request message $m$ to the nodes in the network, including the primary node and replicas.
  
  \item Pre-prepare. The primary node receives the request message $m$ uploaded by the client, assigns to it the message sequence number $s$, and generates the pre-prepare message $\langle PRE$-$PREPARE, H(m), s, v\rangle$, where $H(m)$ is a one-way hash function and $v$ represents the view at that time instant. The view \textcolor{blue}{$v$} is used to record the replacement of the primary node. If the primary node changes, the view $v$ is incremented by one. The message sender uses its private key to implement the digital signature before sending it. The primary node sends the pre-prepare message to replicas.
  
  \item Prepare. Once replica nodes receive the pre-prepare message from the primary node, the replica nodes verify $H(m)$ to ensure they have not received other messages before view $v$ and sequence $s$. After the verification is passed, the replica nodes calculate the prepare message $\langle PREPARE, H(m), s, v\rangle$ and broadcast it to the entire network. If the number of valid prepare messages received by a replica node is greater than or equal to $2f + 1$ (including its own prepare message), then the replica node will generate a prepared certificate. This implies that it is prepared to move to the next phase.
  
  \item Commit. If the replica node collects $2f + 1$ prepare messages and generates the prepared certificate in the prepare phase, it will broadcast the commit message $\langle COMMIT, s, v \rangle$ to other replica nodes and store the message $m$ in the local log for processing. If the number of valid commit messages received by a replica node is greater than or equal to $2f + 1$ (including its own commit message), then the replica will generate a committed certificate which means the message has successfully committed.
  \item Reply. Once a node (either primary node or replica) receives $2f+1$ valid commit messages from the replicas and the primary, it will send the committed certificate as a reply to the message $m$ to the client.
\end{enumerate}

\begin{figure}[htp]
    \centering
    \includegraphics[width=12cm]{i12_pbft.png}
    \caption{PBFT algorithm process \cite{Feng_Zhang_Chen_Lou_2018}}
    \label{fig:PBFT}
\end{figure}

PBFT contains a checkpoint mechanism for discarding messages in a garbage-collection approach. Each request message is assigned a specific sequence number $s$. This functions as a $checkpoint$ for $s$, which is a state reached after the request $s$ is executed. Any checkpoint that has no less than $2f+1$ nodes generating the committed certificate is a $stable$ $checkpoint$. For example, let the sequence number corresponding to message $m$ be 106. If no less than 2$f$ + 1 nodes generate the committed certificate of message $m$, then the serial number 106 becomes the stable checkpoint after the commit phase. Thus, the replica can reduce storage costs by clearing the data before the stable checkpoint. 

The stable checkpoint also plays a crucial role in PBFT's view-change protocol. View-change protocol provides liveness through a mechanism to ensure that the cluster keeps working when the primary node fails. To avoid waiting indefinitely, a replica starts a timer when it receives a request. View changes are triggered if the replica has not received a response from the primary node after a timeout. PBFT's view-change protocol works as follows:

\begin{enumerate}
    \item Broadcast view-change messages. For replica $i$,  suppose the timer expires in view $v$. The current stable checkpoint is $\mathcal{S}^*$, and $\mathcal{C}$ is defined to be a set of $2f+1$ valid checkpoint messages for $\mathcal{S}^*$. $\mathcal{U}$ is a set of messages with sequence number greater than $S^*$ and contains a valid pre-prepare message. Node $i$ broadcasts the view-change message: $vc_i$: $\langle VIEW$-$CHANGE, v + 1, \mathcal{S}^*, \mathcal{C}, \mathcal{U}, i\rangle$ to all replica nodes. 
    \item View-change confirmation. The backup node verifies the legality of the received view-change message for view $v+1$. An acknowledge message is then sent to the new primary node for view $v+1$ once the verification is processed.
    \item Broadcast new view. For node $j$'s view-change message $vc_j$, if the new primary $p$ receives $2f$ acknowledge messages for view $v + 1$, then $vc_j$ is considered valid. Primary node $p$ broadcasts the new view message: $\langle NEW$-$VIEW, v + 1, \mathcal{V}, \mathcal{U}^*\rangle$ to all other replicas, where $\mathcal{V}$ is a set of valid view-change messages plus the view-change message for $v + 1$ which is sent by $p$. The term $\mathcal{U}^*$ denotes a set of numbers, which contains the sequence number of the latest stable checkpoint, and the highest sequence number in prepare message. 

\end{enumerate}

PBFT uses Message Authenticated Codes (MACs) \cite{10.1007/11502760_3} to facilitate inter-node authentication. In the authentication process, both the message and its digest are generated through a specific hash function. A pair of session keys between the two nodes is used to calculate the MAC of the message. The session key is generated through a key exchange protocol and dynamically replaced. PBFT achieves the consistency and activity of state machine replication. The message communication complexity is $O(n^2)$ if there is a non-malicious primary node which works without failure. Otherwise, it rises to $O(n^3)$ if the primary node fails (processing view-change protocol).

\subsection{Redundant Byzantine Fault Tolerance (RBFT)}
The Redundant Byzantine Fault Tolerance (RBFT) algorithm \cite{aublin_rbft_2013} is a variation of PBFT proposed in 2013 that uses a multi-core architecture to improve its robustness. 

The RBFT requires the same adversary mode, i.e. $n=3f + 1$ nodes, as PBFT. Each node runs $f+1$ PBFT protocol instances \cite{aublin_rbft_2013} in parallel. Only one of these instances is the master instance, while the other instances are backup instances. Each instance has its own $n$ replicas; and in  $f+1$ instances, each node has at most one primary in each. An overview of this parallel architecture is shown in Figure \ref{fig:RBFT1}. 

\begin{figure}[htp]
    \centering
    \includegraphics[width=12cm]{i13_rbft1.png}
    \caption{An overview of RBFT components \cite{aublin_rbft_2013}}
    \label{fig:RBFT1}
\end{figure}

As shown in the figure \ref{fig:RBFT2}, RBFT uses a communication process similar to PBFT in the consensus protocol phase but adds a propagate phase before the pre-prepare phase. This ensures that a request will eventually be sent to the next phase by all the correct nodes. To guarantee correctness, RBFT requires that $f+1$ PBFT instances receive the same client request. However, when a node receives a request from the client, it does not directly run it on its $f+1$  instances, but forwards the request message to each other. If a node receives $2f+1$ requests from client, it will eventually send the request to f+1 instances, and move to the next phase. This 3-phase process is similar to PBFT \cite{castro_practical_1999}, and is shown in steps 3, 4, and 5 in Figure \ref{fig:RBFT2}. In the 3-phase process, the RBFT algorithm is also performed by the $f+1$ instances when executing the consensus protocol. After execution, the result will be returned to the client through MAC authentication messages. When the client receives $f+1$ valid and consistent replies, it accepts these replies as a result.

\begin{figure}[htp]
    \centering
    \includegraphics[width=12cm]{i14_rbft2.png}
    \caption{RBFT protocol steps \cite{aublin_rbft_2013}}
    \label{fig:RBFT2}
\end{figure}
 
An improvement of RBFT over PBFT is the implementation of a monitoring mechanism and a protocol instance change mechanism to promote robustness. Each node runs a monitoring program to monitor the throughput of all $f+1$ instances. If $2f+1$ nodes find that the performance difference between the master and the best backup instance reaches a certain threshold, then the primary of the master instance is considered as a malicious node \cite{aublin_rbft_2013}. Thus, a new primary is selected or the primary in the backup instance with the best performance is chosen. It then upgrades the backup instance to the master instance. Since each node has at most one instance of the primary, if the wrong primary of the master instance has been found, all primaries on different instances need to be replaced. Each node maintains a counter to record the change information of each instance. If a node finds that it needs to change the primary, it will send an INSTANCE\_CHANGE message with a MAC authenticator to all nodes. After the node receives the incoming INSTANCE\_CHANGE message, it verifies the MAC, then compares it with its counter. If its counter is larger, then it discards the message. Otherwise, the node checks whether it also needs to send the INSTANCE CHANGE message by comparing the performance of the master and backup. If $2f+1$ valid INSTANCE\_CHANGE messages are received, the counter is incremented by one and this starts the view-change process as in PBFT. As a result, each instance's primary gets updated, including the master's. 


\subsection{BFT-SMART}
BFT-SMART \cite{bessani_state_2014} is a state machine replication library written in the Java language, designed to tolerate $f$ Byzantine nodes where the total number of nodes is $n\geq 3f + 1$. In BFT-SMART, a state transfer service is provided to repair a faulty node, re-assign it into the system, and access other nodes to obtain replicas' latest status. To ensure that the system can recover stably from errors occurring at the $f$ nodes simultaneously, the state transfer service stores each node's operation logs on other disks. Besides, BFT-SMART implemented a reconfiguration service to add/remove replicas dynamically through a Trusted Third Party (TPP) particular client. 

The BFT-SMART algorithm divides the nodes into two types: leader nodes and backup nodes, and it has a reconfiguration protocol \cite{Alchieri_Dotti_Mendizabal_Pedone_2017}, which is very similar to the view-change protocol employed in PBFT to handle a leader failure.

The consensus process of the BFT-SMART algorithm is based on a module named Mod-SMaRt \cite{Sousa_Bessani_2012}, with a leader-driven algorithm described in \cite{Cachin}. There are three phases in the consensus process: $Propose$, $Write$, and $Accept$, as shown in Figure \ref{fig:BFTSMART}. A leader node is elected from the entire network. Before entering the consensus process, a client sends a $REQUEST$ message contains the client serial number, digital signature, and operation request content to all nodes and then waits for a response. When the system is in the normal phase (no node fails or has an error in the system), the leader node first verifies the correctness of the received $REQUEST$ message. After the verification is passed, the leader node accepts the received message, assigns a serial number, and sends the $PROPOSE$ message to replica nodes. As long as a replica node accepts the message and forwards it, other nodes will also receive and send the $WRITE$ message to all nodes, including itself. When receiving $2f$ $WRITE$ messages, the node broadcasts an $ACCESS$ message to all nodes, including itself. When a node receives $2f+1$ $ACCESS$ messages, the request is executed. The algorithm stores the content of the series of request operations and the encryption certificate in each node's log and replies $ACCEPT$ to the client simultaneously. 

\begin{figure}[htp]
    \centering
    \includegraphics[width=10cm]{i15_bft_smart.png}
    \caption{BFT-SMART normal phase message pattern \cite{bessani_state_2014}}.  
    \label{fig:BFTSMART}
\end{figure} 

If an error occurs in a node (the number of error nodes are $f=(n-1)/3$) and triggers timeout twice, the algorithm is forced to jump to the synchronization phase, and the reconfiguration protocol will start to re-elect the leader node. This process and the consensus process can execute simultaneously. When the first timeout is triggered, the $REQUEST$ request will be automatically forwarded to all nodes because the timeout may be triggered by a faulty node that is only sending its response to a part of nodes in the network, instead of sending the response to the entire network. When the second timeout is activated, the node immediately enters the next reconfiguration and sends a $STOP$ message to notify other nodes. When a node receives more than $f$ $STOP$ messages, it will immediately start the next reconfiguration. Once the leader election is complete, all nodes send a $STOPDATA$ message to the new leader node. If the leader node accepts at least $n-f$ valid $STOPDATA$ messages, it will send a $SYNC$ message to all nodes. The node that receives the $SYNC$ message will perform the same operation as the leader node to verify whether the leader node has collected and sent valid information. If the leader has been verified as valid, then all other replicas will start to synchronize from the leader. 


\subsection{RPCA}
 The Ripple Protocol Consensus Algorithm (RPCA) \cite{Schwartz2014TheRP,chase_analysis_2018} was proposed in 2014 for use in the Ripple cryptocurrency created by Ripple Labs. The RPCA algorithm uses some pre-configured nodes as validators verifying and voting on transactions to reach the consensus. After several rounds of voting, if a transaction continues to receive more than a threshold (usually 80\%) of votes, the transaction is directly recorded in the ledger. Each node in the system maintains a subset of validators as a list of trusted nodes named Unique Node List (UNL). In addition to validators, there are also non-validators in the system known as tracking servers. Tracking servers are responsible for forwarding transaction information in the network and responding to client's requests, and not participating in the consensus process. A validator and a tracking server can switch roles. When a tracking server obtains a certain threshold of votes, it can switch to serving in the role of a validator. If a validator is inactive for a long time, it will be deleted from the UNL and it then becomes a tracking server.

The consensus process of the RPCA algorithm is shown in Figure \ref{fig:RPCA}. The client initiates a transaction and broadcasts it to the network. The validator receives the transaction data, stores it locally, and verifies it. Invalid transactions will be discarded, while a valid transaction is integrated into the candidate set of transactions. Each validator periodically sends its transaction candidate set as a transaction proposal to other nodes. Once the validator receives the proposal from other nodes, it checks whether the sender of the proposal is on the UNL. If it is not, the proposal is discarded. Otherwise, the validator will store the proposal locally and compare it with the candidate set. The transaction will obtain one vote if it is the same as in the candidate set. Within a certain period \cite{chase_analysis_2018}, if the transaction fails to reach 50\% of the votes, it will return to the candidate set and wait for the next consensus process. If it reaches a threshold denoted by 50\% of votes, it will enter the next round and be re-sent as a proposal to other nodes and the threshold will also be raised. As the number of rounds increases, the threshold continues to increase until the transaction reaches 80\% or more of the votes, at which point the validator writes it into the ledger.

\begin{figure}[htp]
    \centering
    \includegraphics[width=12cm]{i16_rpca.png}
    \caption{Ripple's RPCA Consensus Algorithm}.  
    \label{fig:RPCA}
\end{figure}

In the RPCA algorithm, because the identity of the nodes participating in the consensus (validators) is known, this algorithm reduces the communication cost between network nodes and improves consensus efficiency compared with PoW, PBFT, and other algorithms. Since the algorithm requires 80\% or more of the votes to reach a consensus, if malicious nodes want to cheat the ledger, they must reach 80\% or more in the UNL to succeed. Thus, RPCA has a better Byzantine fault tolerance compares to PBFT, and it is able to guarantee the correctness of the system.


\subsection{Stellar Consensus Protocol (SCP)}
Stellar is an open-source blockchain technology, mainly used in distributed financial infrastructure. One of the main objectives of SCP is to reduce the cost of financial services such as daily payments between enterprises, cross-border electronic remittances, and asset transactions. SCP, proposed by David Mazieres, is a distributed consensus algorithm designed around state machine replication, and does not require miners but a distributed server network to run the protocol \cite{mazieres_stellar_2015}.

SCP is the first implementation of a consensus protocol called the Federated Byzantine Agreement (FBA), which follows Federated Byzantine Fault Tolerance (FBFT). A quorum slice introduced by FBFT refers to the subset of nodes on the network that a given node chooses to trust. A quorum is a set, and each non-faulty member of it contains at least one quorum slice. The notion of FBA is similar to the UNL in the RPCA algorithm, since the UNL can be considered as a type of quorum slice. However, unlike the UNL used in Ripple which requires only 80\% of the agreement to reach the consensus, in Stellar, the ledger will not update the transaction until 100\% of nodes in a quorum slice agree on it. 

There are two mechanisms in the quorum slice model, federated voting and federated leader election. In federated voting, nodes vote on a statement and use a two-step protocol to confirm it. If each quorum of non-faulty nodes $v_1$ intersects each quorum of non-faulty nodes $v_2$ in at least one non-faulty node, then $v_1$ and $v_2$ are intertwined \cite{scp_2019}. It is guaranteed that intertwined nodes would never approve a conflicting transaction \cite{scp_2019}. In federated leader election, the algorithm allows nodes to pseudo-randomly select one or a small number of leaders in the quorum slice.

\begin{figure}[htp]
    \centering
    \includegraphics[width=12cm]{i17_fba.png}
    \caption{Federated voting process \cite{mazieres_stellar_2015}}.  
    \label{fig:FBA}
\end{figure}

SCP is a global consensus protocol consisting of three interrelated components - a nomination protocol, a ballot protocol, and a timeout mechanism. The nomination phase is the initial operation in SCP, and it proposes new values as candidate values to reach an agreement. $NOMINATE$ $x$ is a statement that states $x$ is a valid candidate consensus value. Each node that receives these values votes for a single value among these values. The nomination phase eventually generates the same set of candidate values as a deterministic combination of all values on each intact node \cite{scp_2019}.

Once the nomination phase is successfully executed, the nodes enter the ballot phase. In the ballot phase, federated voting is used to commit or abort the values. An example of the three-step process used in FBA is shown in Figure \ref{fig:FBA}. In the first step of the FBA process, a node $v$ votes for a valid statement $a$ by broadcasting the message. In the second step, $v$ accepts the $a$ if $v$ never accepted a values that contradicts $a$. If each member of $v$'s quorum set claims to accept $a$, then the fact $a$ is broadcasted again. The statement $a$ is confirmed in the last step if each node in node $v$'s quorum accepts $a$ and $v$ confirms $a$. However, there may be a $stuck$ state since the node cannot conclude whether to abort or commit a value. SCP uses two statements $PREPARE$ and $COMMIT$, and a series of numbered ballots to avoid stuck votes in the federated voting process. A statement $PREPARE \langle n, x\rangle$ states that no value other than $x$ was or will ever be chosen in any ballot $\leq n$. Another statement $COMMIT \langle n, x\rangle$ states that value $x$ is chosen in ballot $n$. A node has to confirm the $PREPARE \langle n, x\rangle$ statement before voting for the $COMMIT \langle n, x\rangle$ statement. Once the $COMMIT$ statement has been confirmed, the value $x$ can be output by the node. SCP provides liveness by using these two statements when the node thinks a stuck ballot has been committed.

The last and important part of SCP is the timeout mechanism. If the current ballot $n$ seems to be stuck, it will cause a new round of federated voting to start on a new ballot with a higher counter $n+1$. 

This particular quorum model used in SCP allows the participating node to decide quorums, which is the critical difference between FBA and the previous Byzantine agreement systems introduced in Sections 4.2 - 4.5 above. The SCP protocol employing FBA claims no stuck state and can provide low latency and flexible trust. 

\subsection{HotStuff and LibraBFT}
\subsubsection{HotStuff}
The HotStuff algorithm proposed by Yin, Abraham, Gueta, and Malkhi \cite{yin_hotstuff_2019} improves upon the PBFT. The HotStuff network is a partially synchronized network \cite{Chan_Pass_Shi} with an adversary model of $n = 3f + 1$. It uses a parallel pipeline to process the proposal, which is equivalent to combining the preparation and commitment phases of PBFT into a single phase. The original paper proposes two implementations of HotStuff, namely Basic HotStuff and Chained HotStuff.  

The Basic HotStuff protocol forms the core of HotStuff, which switches between a series of views. The views switch according to a monotonically increasing number sequence. A unique consensus leader exists within each view. Each replica node maintains a tree structure of pending commands in its memory. Uncommitted branches compete, and only one branch in a round will be agreed upon by the nodes. In the HotStuff protocol, branches are committed as the view number grows. Voting in HotStuff uses the cryptographic term $Quorum Certificate$ (QC), where each view is associated with a QC that indicates whether enough replicas have approved the view. If a replica agrees with a branch, it signs the branch with its private key, creating a partial certificate \cite{Chan_Pass_Shi} to send to the leader. The leader collects $n - f$ partial certificates, which can be combined into a QC. A view with a QC means that it receives the majority votes of the replicas. The leader collects signatures from $n-f$ replicas by using threshold signatures \cite{cachin_blockchain_2017,Gueta_Abraham_Grossman_Malkhi_Pinkas_Reiter_Seredinschi_Tamir_Tomescu_2019}. The process of collecting signatures consists of three phases, PREPARE, PRE-COMMIT, and COMMIT phases. Moreover, the entire algorithm consists of five phases, PREPARE, PRE-COMMIT, COMMIT, DECIDE, and FINALLY phases, as shown in Figure \ref{fig:HotStuffBasic}.

\begin{figure}[htp]
    \centering
    \includegraphics[width=12cm]{i18_hotstuff_b.png}
    \caption{Consensus in the HotStuff Protocol \cite{Team_2019}}  
    \label{fig:HotStuffBasic}
\end{figure} 


\begin{enumerate}
  \item PREPARE. The leader denoted by the current highest view designated as $highQC$, initiates a proposal for $highQC$, encapsulates it into a PREPARE message with message content $m = MSG(PREPARE$, $curProposal$, $highQC)$, and broadcasts it to all replicas. Replicas will decide whether to accept the proposal or not, and then return a vote with partial signature to the leader if the proposal is accepted.
  \item PRE-COMMIT. When the leader receives votes from $n-f$ replicas for the current proposal $curProposal$, it combines them into $prepareQC$, encapsulates $prepareQC$ into a PRE-COMMIT message, and broadcasts it to all replicas. The replica votes after receiving the above proposal message and returns the vote to the leader. 
  \item COMMIT. When the leader receives the PRE-COMMIT votes from $n-f$ replicas, it merges them into $precommitQC$, encapsulates a $precommitQC$ into a COMMIT message, and broadcasts them to all replicas. The replica votes after receiving the above proposal message and returns the COMMIT vote to the leader. To ensure the safety of the proposal, the replica is locked by setting its $lockedQC$ to $precommitQC$.
  \item DECIDE. When the leader receives the COMMIT votes from $n-f$ replicas, it merges them into one $commitQC$ and then uses the DECIDE message to broadcast it to all replicas. After receiving this message, the replica confirms and submits the proposal in the $commitQC$, executes the command and returns it to the client. After this, the replica increases the $viewNumber$ and starts the next view. 
  \item FINALLY. If the system moves to the next view, each copy sends a message to the next view's leader with the message $m = MSG(NEW$-$VIEW,\perp, prepareQC)$.
\end{enumerate}

Figure \ref{fig:HotStuffBasic} shows that the processes in each phase of Basic HotStuff are very similar to each other. A modified version of HotStuff called Chained HotStuff was proposed \cite{yin_hotstuff_2019} to optimize and simplify Basic HotStuff. In the Chained HotStuff protocol, the replicas' votes in the $PREPARE$ phase are collected by the leader, and stored in the state variable $genericQC$. Then, $genericQC$ is forwarded to the leader of the next view, essentially delegating the next phase's (the PRE-COMMIT phase) responsibilities to the next view's leader. Thus, instead of starting its new PREPARE phase alone, the next view's leader actually executes the PRE-COMMIT phase simultaneously. Specifically, the PREPARE phase of view $v+1$ also acts as the PRE-COMMIT phase of view $v$. The PREPARE phase of view $v+2$ acts as both the PRE-COMMIT phase of view $v+1$ and the COMMIT phase of view $v$. The flow of Chained HotStuff is shown in Figure \ref{fig:ChaindHotStuff1}. 

\begin{figure}[htp]
    \centering
    \includegraphics[width=12cm]{i19_hotstuff_c1.png}
    \caption{Chained HotStuff is a pipelined Basic HotStuff where a QC can serve in different phases simultaneously. \cite{yin_hotstuff_2019}}.  
    \label{fig:ChaindHotStuff1}
\end{figure}


Figure \ref{fig:ChaindHotStuff1} shows that a node can be in different views simultaneously. Through a chained structure, a proposal can reach a consensus after three blocks. In other words, it resembles a Three-Chain as shown in figure \ref{fig:ChaindHotStuff2}. An internal state converter enables the automatic switching of proposals through $genericQC$. The chained mechanism in Chained HotStuff reduces the cost of communication messages and allows pipelining of processing. In the implementation of Chained HotStuff, if a leader fails in obtaining enough QC, then it may appear that the view numbers of a node are not consecutive. This issue can be solved by adding dummy nodes, as shown in Figure \ref{fig:ChaindHotStuff2}, where a dummy node has been added to force $v_6$, itself, and $v_8$ to form a Three-Chain.

\begin{figure}[htp]
    \centering
    \includegraphics[width=12cm]{i20_hotstuff_c2.png}
    \caption{The nodes at views $v_4$, $v_5$, $v_6$ form a Three-Chain. The node at view $v_8$ does not make a valid One-Chain
in Chained HotStuff. \cite{yin_hotstuff_2019}}.  
    \label{fig:ChaindHotStuff2}
\end{figure} 

HotStuff achieves $O(n)$ message authentication complexity by improving the distributed consistency algorithm's efficiency using threshold signatures, parallel pipeline processing, and linear view changing. Compared to PBFT, HotStuff can reach consensus pipelining without a complex view-change mechanism and improves consensus efficiency.

\subsubsection{LibraBFT}
The LibraBFT consensus protocol \cite{libra_association_members_libra_2020}, implemented by the Facebook Libra Team, is a variant of the HotStuff consensus protocol. It leverages the advantages of HotStuff and further make two types of changes on top of HotStuff. 
One type of changes are proposed to meet multiple business requirements. The concept of epoch is introduced; 
consensus node replacement is enabled; incentive and penalty mechanisms are supported. 
Given the added economic incentives and penalties to LibraBFT \cite{baudet_state_2019}, a node can get rewarded for participating in the voting process and get penalized if it violates the voting constraints or submits conflicting proposals. 
Another type of changes is to overcome the problem of HotStuff that the upper bound of a message latency is unknown. Since HotStuff in effect only requires partial synchronization\cite{dwork1988consensus}, the upper bound of a message latency in the network is unknown. The view change mechanism in HotStuff is not time-bound; rather it relies upon the status of the last view. In other words, a block can be confirmed quickly if the view change takes a short time; the confirmation of a block can also take a long time otherwise. 
To overcome the above problem, LibraBFT employs the pacemaker mechanism \cite{baudet_state_2019} which ensures the confirmation latency is lower than an upper bound. 


\section{Comparison of Consensus Algorithms}
The use of different consensus algorithms in enterprise blockchains impacts the overall performance of the system. In this section, we compare and summarize the eight consensus algorithms profiled thus far in this paper. 

\subsection{Comparison Methodology}
The algorithms are compared with each other in the following five aspects: 
the degree of decentralization, scalability, fault tolerance, performance efficiency, and resource consumption.

    \begin{itemize}
      \item Fault tolerance: Fault tolerance refers to the ability of a consensus algorithm to tolerate both non-Byzantine faults (CFT) and Byzantine faults (BFT). Fault tolerance also impacts the security of the consensus protocol.
      
      \item Performance: Performance efficiency is measured by latency and throughput. 
      The latency of a transaction is defined as the time elapsed from the moment a node submits a transaction to the time that the transaction is confirmed by the blockchain network. Same as \cite{Salimitari_Chatterjee_2019}, we classify latency as high, medium, or low. High latency is in the magnitude of minutes, medium is in seconds, and low is in milliseconds. 
      
      Throughput refers to the block generation rate and the number of Transactions Per Second (TPS) that the system can process. Block generation is expressed as the time required for the entire process starting from the time when transactions are packaged into blocks up to the time when consensus is completed and recorded on the blockchain. TPS represents the transaction throughput, which is determined by the size of the data block and the block generation speed. TPS is measured as the number of transactions in the block divided by the length of time required for the generation of the current block. The faster the block generation speed of the algorithm used in the actual system, the greater is the transaction throughput, and the higher is the algorithm's performance efficiency. We classify throughput into three categories. If a protocol can provide higher than 2,000 TPS, it is classified as a high throughput protocol. A TPS between 1,500 to 2,000 indicates medium throughput and a TPS less than 1,500 indicates a low throughput.  
      
      \item Degrees of decentralization: Decentralization does not mean that there is no central node; rather, it implies there exists a relatively neutral entity that functions as the central node. In a round of reaching consensus, the node which decides the recording of transactions on the distributed ledger is considered as the central node. All other nodes keep the data consistent around it. In order to maintain the distributed state of the system, the role of each node (including the central node) is subject to change. Therefore, we compare the degree of decentralization of the algorithm according to the recording node's selection rules and the number of selected recording nodes in each round.
      
      \item Scalability: Scalability refers to the number of nodes that the algorithm can process in the system and implies an upper bound on the size of the network.
      If a protocol can support over 100 participants in the network, we conclude its scalability is high; otherwise, it is low. 
      
      \item Resource consumption: Resource consumption refers to the computing power, memory, input and output, and electricity resources that each node needs to consume in the process of reaching a consensus. Communication complexity is a theoretical proxy of resource consumption.  
    \end{itemize}


\subsection{Evaluation and Analysis} 
Table \ref{tab:CompConsensus} presents a comparison of various consensus algorithms presented in this paper regarding fault tolerance, scalability, latency, and throughput. Example applications are also listed. 


\begin{table*}
\caption{Comparison of Consortium Consensus Algorithms \cite{Consortium, wu2020hybrid}}
\label{tab:CompConsensus}
    \begin{tabular}{p{0.14\textwidth}p{0.14\textwidth}p{0.14\textwidth}p{0.11\textwidth}p{0.16\textwidth}p{0.28\textwidth}}
   
    \toprule
    \textbf{Consensus} & \textbf{Fault \newline Tolerance} & \textbf{Scalability} & \textbf{Latency} & \textbf{Throughput} & \textbf{Examples of \newline Applications}\\
    \midrule
    Paxos & $n=2f+1$ & High   & Low & Medium &    Google Chubby, \newline Zookeeper\\
    Raft & $n=2f+1$ & High  &    Low & Medium  &    IPFS \\
    PBFT & $n=3f+1$ & Low  &  Low &  Low &    Hyperledger Fabric  \\
    RBFT & $n=3f+1$ & High  &  Low &  High &    Hyperledger Indy  \\
    BFT-SMART & $n=3f+1$ & High  & Low &    High &  R3 Coda, Symbiont\\
    RPCA &  $n=5f+1$ &High  & Medium &    Medium &    Ripple  \\
    SCP & $n=3f+1$ &High  & Medium &    Low &    Stellar  \\
    HotStuff &  $n=3f+1$ &High  & Low &   High &    Libra \\
    \bottomrule
    \end{tabular}
\end{table*}

Table \ref{tab:complexity} presents the communication complexity of different protocols in normal situation and situations in which the leader fails. 

\begin{table}
\caption{Communication Complexity of selected protocols}
\label{tab:complexity}
    \begin{tabular}{p{0.28\textwidth}p{0.4\textwidth}p{0.28\textwidth}}
   
    \toprule
    \textbf{Consensus} & \textbf{Normal Case} & \textbf{Leader Failure}\\
    \midrule
    Paxos \cite{Xiao_Zhang_Lou_Hou_2019} & $O(n^2)$ & -\\
    Raft \cite{ongaro_search_2014} & $O(n)$ & -\\
    PBFT \cite{yin_hotstuff_2019} &  $O(n^2)$ & $O(n^3)$\\
    RBFT \cite{aublin_rbft_2013} & $O(n^3)$ & $O(n^3)$ \\
    BFT-SMART \cite{yin_hotstuff_2019} & $O(n^2)$ & $O(n^3)$ \\
    RPCA \cite{Xiao_Zhang_Lou_Hou_2019} &  $O(nK)$, $K$ is the size of UNL. & - \\
    SCP \cite{Xiao_Zhang_Lou_Hou_2019} &  $O(nK)$, $K$ is the size of quorum.& -\\
    HotStuff \cite{yin_hotstuff_2019} & $O(n)$ & $O(n)$\\
    \bottomrule
    \end{tabular}
\end{table}

\begin{table*}
\caption{Strengths and Weaknesses of Surveyed Consensus Protocols}
\label{tab:proscons}
   
    \begin{tabular}{p{0.17\textwidth}p{0.4\textwidth}p{0.4\textwidth}}
    \toprule
    \textbf{Consensus} & \textbf{Advantages} & \textbf{Disadvantages}\\
    \midrule
    Paxos & High Performance. & Cannot tolerate Byzantine failure. \newline Be lack of understandability. \\

    Raft & High Performance. \newline Improved understandability compares to Paxos. & Cannot tolerate Byzantine failure. \\

    PBFT &  No tokens. \newline High performance. \newline High security. & High communication volume. \newline Low efficiency of operation when the number of nodes is too large.\\
   

    RBFT & Can rapidly find malicious primary node. &  Cannot deal with closed-loop systems. \cite{Casado-Vara_Chamoso_De_Prieta_Prieto_Corchado_2019}\\

    BFT-SMART & Implement dynamic addition and deletion of nodes. \newline High system throughput. & Cannot prevent malicious nodes being primary node.\\

    RPCA & High efficiency. \newline High security. & Low fault tolerance. \newline More threat to the verification nodes.\\

    SCP & Fast transaction speeds. \newline Low transaction costs. \newline Flexible Trust. &  Can only guarantee safety if trusted nodes are adequate. \\
    
    HotStuff & High performance. \newline Linear complexity for message communication and validation. \newline No complex view-change mechanism compared to PBFT. &  Fewer applications.\\
    
   
   
   
   
   
   
   
   
    
   
   
   
   
   
   
    
   
   
   
   
   
   
   
   
    
   
   
   
   
   
    
   
   
   
   
   
   
    
   
   
   
   
   
   
   
    
   
   
   
   
   
   
   
    
   
   
   
   
   
   
   
    
    \bottomrule
    \end{tabular}
\end{table*}

The advantages of Paxos algorithm include its high performance and low resource consumption. It enables a distributed system to reach consensus when the number of normal nodes is greater than half of the total nodes. 
The distinct disadvantage of Paxos is that it does not provide Byzantine fault tolerance. It cannot be used for blockchains that require Byzantine fault tolerance. Google Chubby \cite{Burrows} is a typical application using the Paxos algorithm, which provides a coarse-grained locking service for a loosely-coupled distributed system that stores a large number of small files.
Another interesting weakness of Paxos, as noted by its author, is that the algorithm lacks understandability. Leslie Lamport first submitted the original paper of Paxos in 1989. It was finally published in 1998 after several rounds of revision to make it more understandable.

Raft was inspired by Paxos and its fault tolerance, performance efficiency, degree of decentralization, scalability, and resource consumption are very similar to the Paxos algorithm. Raft can enable the distributed system to reach a consensus if more than half of the nodes are non-failure nodes in the distributed system. That means Raft does not provide Byzantine fault tolerance, either. 
A distinct advantage of Raft is that it has only one legal leader in any round of consensus. This makes Raft simpler, and increases its understandability and implementability compared to Paxos. 

The PBFT algorithm can tolerate both non-Byzantine errors and Byzantine errors simultaneously, by sending broadcasts to the entire network in each round and allowing each node to participate in electing the primary node. This advanced mechanism ensures that PBFT has the capabilities to maintain consistency, availability, and anti-fraud attacking. However, with the increase in the total number of nodes, the growth rate of the total number of broadcast messages is quadratic, which results in rapid super-linear performance degradation. Therefore, a disadvantage of the PBFT algorithm is that it is only suitable for consortium blockchain and private blockchain. Since public blockchains are generally larger, they not suitable for implementing the PBFT protocol.

The BFT-SMART algorithm is an improvement to the PBFT algorithm. The advantage of BFT-SMART is that in addition to the implementation of consensus, BFT-SMART also provides state transition and reconfiguration services, addition and deletion of nodes in the system, and effectively improves the system's performance and efficiency. A blockchain implementation with the BFT-SMART protocol made by Symbiont can reach a throughput of 8000 TPS in a 4-node network cluster, which meets with the expected performance of the original paper \cite{bessani_state_2014}. Meanwhile, a drawback of BFT-SMART is that if a malicious node became the primary node, the performance would be significantly reduced.

The RBFT algorithm was first proposed for better Byzantine fault tolerance. In earlier BFT algorithms such as PBFT, Prime \cite{Amir_Coan_Kirsch_Lane_2011}, Aardvark \cite{DBLP:conf/nsdi/ClementWADM09}, and Spinning \cite{Veronese_Correia_Bessani_Lung_2009}, if the primary node is malicious, the whole system's performance is degraded. RBFT proposes a new model: multiple PBFT protocol instances are executed in parallel using multi-core machines, and only the results of the master instance are executed. Each protocol instance is monitored for performance and compared with the master instance. If a ratio of the performance of the master instance and the best backup instance is lower than a preselected threshold, the primary node of the master is considered malicious, and a replacement process is initiated. If one or more Byzantine faulty nodes exist in the blockchain network, it has been shown that the maximum performance degradation of RBFT is 3\%, which is better than other protocols; for instance, Prime is 80\%, Aardvark is 87\%, and Spinning is 99\%. 


The advantage of the RPCA algorithm is its relatively high performance and efficiency. Ripple can generate a block every 3 seconds with a transaction throughput that can reach 1500 TPS. A disadvantage of RPCA is that the fault tolerance is lower than other PBFT-likely consensus algorithms. Since RPCA's adversary mode is $n=5f+1$, to tolerate $f$ faulty nodes, the total number of nodes required in RPCA is greater than other algorithms that have adversary mode as $n=3f+1$. The verification node is pre-configured, and the degree of decentralization is low. Simultaneously, the reliability of the verification node directly affects the operation of the entire network.

The SCP algorithm is a new consensus mechanism based on the Federated Byzantine Agreement, and it has four essential attributes: decentralized control, flexible trust, low latency, and asymptotic security. Unlike other BFT protocols, the transaction is not verified by all nodes in SCP. If any node in a quorum has verified a transaction, the other nodes will trust that node and skip the verification process. This mechanism allows SCP to process transactions quickly, rather than other consensus algorithms in a public blockchain. SCP emphasizes maintaining the network's activity, and instead of choosing nodes, any node can join each other's trust list for transactions if it follows the policy. With SCP, the Stellar network is currently running approximately 100 nodes \cite{Berger_Reiser_2018}. 

The HotStuff consensus algorithm summarizes the features from other BFT-based consensus algorithms such as PBFT and Tendermint \cite{Tendermint}, and implements a new algorithm with safety, liveness, and responsiveness. Responsiveness allows the blockchain node to confirm the blocks fast when the network is under a reliable condition; otherwise, it can wait for more time to confirm if the network condition is limited. A distinct advantage of HotStuff is that it can reduce the communication complexity to linear and guarantee responsiveness by using threshold signatures, three rounds of voting, and a chained structure to acknowledge a block \cite{yin_hotstuff_2019}. However, since HotStuff has been published recently, fewer applications can be found using the Hotsuff algorithm than other consensus algorithms in the BFT family.

In summary, the advantages and disadvantages of the eight consensus algorithms are listed in Table \ref{tab:proscons}.



\section{Research Challenges}
The distributed, immutable, consensus-based operations of blockchain lends itself to different applications in diverse fields such as rights management, secure record keeping, and smart contracts. Regardless of the kind of blockchain used and its applications, the consensus algorithm lies at the core of the blockchain operation and must therefore, be carefully evaluated. The primary research challenges that need to be addressed in the consensus mechanism for consortium blockchain are:

\begin{itemize}
    \item Scalability enhancement: While the public blockchain allows any node to join the network without authorization, the consortium blockchain offers limited membership. Still, the issue of scalability in a consortium blockchain is critical. As we discussed, the size of a network has implications for parameters such as fault tolerance that impact the blockchain's efficiency. As the business needs grow, the number of access nodes required by the platform may increase to keep pace with the platform's expansion. Proactive approaches to build consortium blockchains that adapt to changing business needs and platform expansion needs must be considered to strengthen the scalability.
    
    \item Algorithm combination: As applications and platforms evolve, consensus algorithms may require more flexibility in adapting to the changing environment. The evolution of applications and platforms may introduce requirements for fusion between algorithms. For example, LibraBFT has introduced more incentive mechanisms used in public chains \cite{libra_association_members_libra_2020}. Therefore, integrating different types of consensus mechanism algorithms in the future poses a distinct challenge to interoperability.
    
    \item Privacy-preserving: The consortium blockchain needs authentication for the participating nodes, which reduces the probability of possible attacks to a certain extent. Nevertheless, we still need to consider the security and privacy of data on the consortium chain. The use of cryptography to ensure the security and privacy of data on the blockchain while still conforming to the central paradigm of blockchain decentralization will be a tradeoff to consider.

    \item Performance improvement: Performance improvement implies several factors, such as increase in throughput, reduction in latency, and reduction in the computational requirements for consensus algorithms. Each of these factors impacts the scalability of the blockchain. Therefore, ensuring increasing performance while reducing the impact on scalability is a challenge. 
    
    \item Searching and storing optimization: While the original philosophy of blockchain called for implementations to build a distributed ledger, the expectations for blockchain networks have evolved into data retrieval over the years. In this use scenario, a blockchain ledger is more like a distributed database without the capability of deleting and updating operations due to the immutability property of blockchain. Therefore, the consensus mechanisms that are built for blockchain should also consider whether the data storing and searching can be optimized accordingly.
\end{itemize}

The above list of challenges broadly summarizes the various areas of improvement for consortium blockchain algorithms. However, since these protocols are still under development and the applications leveraging these algorithms are continuously being refined, the scope of challenges for consensus algorithms used in consortium blockchain applications continues to remain a work under progress.


\section{Conclusion}
Consensus algorithms lie at the core of blockchain and have become a rapidly emerging area of research. This paper summarizes the working of eight consortium blockchain consensus algorithms: Paxos, RAFT, PBFT, RBFT, BFT-SMART, RPCA, SCP, and HotStuff. We discuss five crucial aspects of the operation of each of these algorithms, namely, fault tolerance, performance, efficiency, decentralization, resource consumption, and scalability. Our work in this paper lays the groundwork for researchers, developers, and the blockchain community at large to understand the current landscape of consensus technologies. The potential of blockchain to revolutionize use cases in various scenarios from finance to agriculture relies on the blockchain solution's ability to achieve a balance between three overarching objectives: scalability, security, and decentralization. The choice of consensus algorithm has an outsize impact on the performance of blockchain applications. Therefore, ongoing research into the design and implementation of consensus algorithms will go a long way in adapting blockchain for diverse applications.





\section*{Acknowledgment}
The research is partially supported by FHWA EAR 693JJ320C000021. 

\bibliographystyle{unsrt}
