# Distributed Ledger Technology Review and Decentralized Applications Development Guidelines
## 2 Protocol and Network Tier
### Network Layer
#### 2.2.3 Consensus Protocols  
Figure 3 presents a taxonomy of the consensus algorithms which are classified in Non-Byzantine fault-tolerant algorithms and Byzantine fault-tolerant algorithms. The difference is given by the ability of algorithms to reach an agreement, integrity, and termination in case of existing faulty or attacker nodes in the distributed system, thus Non-Byzantine fault-tolerant ones rely on the assumption that all the nodes are fair, while the Byzantine fault-tolerant algorithms can handle situations when the number of malicious nodes is as high as half of the total number of nodes. \begin{table}
\begin{tabular}{c c c c c} \hline \multirow{2}{*}{**Action**} & \multicolumn{2}{c}{**Public Chain**} & \multicolumn{2}{c}{**Private Chain**} \\ \cline{2-5}  & **Permission-Less** & **Permissioned** & **Consortium** & **Enterprise** \\ \hline Chain Access & Everyone & Everyone & Group Owner & Group Owner \\ Transactions & Everyone & Owners \& Validated Users & Administrator \\  & & Owners \& subset of & Owners \& subset of \\ Commit to chain & Everyone & Validated Users & Validated Users & Administrator \\ \hline \end{tabular}
\end{table} 
Table 5: Public vs Private Blockchain permissions. The _Non-Byzantine fault-tolerant protocols_ are leader-based, such as 2-Phase Commit [63] and RAFT [64], where a leader election algorithm is used to select a leader that will centralize the votes and commit the transaction. Furthermore, they are quorum-based, where a subset of the processes is selected to validate the transaction using a voting scheme. A well-known algorithm of this class is the Paxos algorithm [65] that solves consensus in a network of processes that may fail but are correct (there exist no faulty processes that may lie). In Quorum, RAFT algorithm is used, where a predetermined leader is creating a block that is sent to each node in the cluster [66]. The _Byzantine fault-tolerant protocols_ aim to assure that the peers can agree on a system valid state even in case some of them feature faulty or malicious behaviors. The idea is to find a model and protocol for a network of message-passing processes, some of them being faulty, such that a general agreed state can be extracted from the distributed system. The Byzantine fault-tolerant protocols can be classified as Byzantine Agreement protocols and Proof Protocols [67]. In terms of finality, proof-protocols are known not to be final, however, they offer probabilistic finality, since once many blocks are sealed over, the probability of a block's state to change is very low. The _Byzantine Agreement (BA)_ protocols use a quorum-based mechanism where a subset of the nodes must agree on a transaction validity. Examples of such algorithms are the Byzantine Paxos algorithm [68], the Practical byzantine fault tolerance algorithm [69], and variants that address the robustness such as Ardvark [70] and RBFT [71] or that address the performance problems of PBFT, such as Q/U [72], HQ [73], Zyzzyva [74] and ABSTRACTs [75]. An interesting Byzantine fault tolerant distributed commit protocol is proposed in [76], where the authors enhance the classical 2-Phase Commit protocol by replicating the coordinator to successfully terminate when the coordinator failed and by building a quorum of coordinators to validate transactions and identify malicious participants. The _Proof Protocols (PP)_ are used by most of the public DLT systems [77; 78] for supporting the consensus mechanisms to ensure the consistency of the ledger state across the network nodes. The Proof Protocols have defined two categories of nodes: Provers and Verifiers, where the Prover who may have unlimited resources needed to convince Verifier nodes with limited resources, about the truthfulness of a statement. As opposed to BA protocols, which use a quorum of participants to validate a transaction by voting, PP such as Proof of Work (PoW) and various alterations algorithms validate a transaction  
Figure 3: Consensus algorithms taxonomy.