## 3 Challenges and the State of the Art Progresses
### Architectural Choices behind Performance and Security Concer
#### 3.3.2 Byzantine vs. Non-Byzantine Consensus Fault Model  
A Byzantine fault is a condition of distributed computing systems, where nodes may fail and malicious nodes may exist; and there is no knowledge about whether a node has failed or it is a malicious node. A consensus protocol is Byzantine fault tolerant if it can work under an environment with malicious nodes and general node failures, while a protocol is non-Byzantine fault tolerant if it only works for general node failures. Some consensus algorithms of blockchain are Byzantine fault tolerant, where honest nodes can still reach an agreement with the existence of malicious nodes. Some consensus algorithms are not designed to work under a malicious environment, and they assume all nodes are honest and can only tolerate general system failures.  
Practical Byzantine fault tolerance is one of the Byzantine fault tolerant consensus protocols. It improves the original BFT consensus mechanisms, can tolerate \(\frac{1}{3}(n-1)\) of malicious nodes, where \(n\) is the number of peer nodes, and has a polynomial time complexity. It has been implemented and enhanced in some popular blockchain platforms such as Hyperledger Fabric.  
Raft is an improved practical version of Paxos. It has the same performance and fault-tolerance as that of Paxos protocol. It is more understandable and addresses all major pieces needed for practical systems. It is not supposed to work under a malicious Byzantine environment, only considers general system failures, and can tolerate \(\frac{1}{2}(n-1)\) of node failure. Hence, it is non-Byzantine fault tolerant and works for private blockchain.  
Ripple protocol uses proof-of-correctness and requires all nodes to be identified. It is more efficient than PoW and PoS protocols, can tolerate \(\frac{1}{5}(n-1)\) of malicious nodes and works only for permissioned blockchains.  
PoW protocol is a probabilistic Byzantine agreement, which can tolerate a malicious environment when the malicious nodes' hashing power is strictly less than \(\frac{1}{2}\), assuming high network synchronicity [44]. PoS protocol can also work in a malicious environment when the malicious nodes' stake is strictly less than \(\frac{1}{2}\). Thus, both PoW and PoS protocols work for public and federated blockchains.  
\begin{table}
\begin{tabular}{c c c} \hline \hline  & **Public** & **Private/Federated** \\ \hline Access & open read/write & permissioned read/write \\ Speed & slow & fast \\ Security & PoW, PoS, other consensus protocols & PBFT, Raft, legal contracts, proof of authority \\ Membership & anonymous/ pseudonymous & known identity \\ Environment & untrusted & trusted \\ Typical platforms & BitCoin, Ethereum & Hyperledger \\ \hline \hline \end{tabular}
\end{table}
Table 3: Comparison of public blockchain with private/federated blockchain.  
[PERSON] et al. claimed that the equal right of each member in pBFT is not reasonable since fault nodes should have less rights [45]. They presented a reputation based Byzantine Fault Tolerance (RBFT) algorithm, which evaluates each node's contribution together with its reputation in the voting process. A faulty node will get lower reputation and hence less right in the consensus process, if any malicious behavior is detected. The RBFT algorithm also assigns more priority to nodes with higher reputation when validating new blocks. RBFT algorithm can tolerate \(\frac{1}{3}(n-1)\) of malicious nodes as that of pBFT, but it has higher tps and lower latency compared with pBFT when the faulty node rate is high.