# The Modification of pBFT Algorithm to Increase Network Operations Efficiency in Private Blockchains
## 2 Blockchain Consensus Algorithm
### Consensus Algorithm of Private Blockchains
#### 2.2.2 pBFT (Practical Byzantine Fault Tolerance)  
Once a Byzantine fault occurs in a public blockchain, a 51% attack occurs. In a private blockchain, however, some of this Byzantine fault is tolerated, as only approved nodes may participate, and if a certain result reaches consensus, consensus is available. This specific case is called BFT (Byzantine Fault Tolerance), in which pBFT is the representative BFT algorithm [17; 18; 19]. pBFT is used in a system in which reliability-based nodes are participating and enables an asynchronous BFT consensus. The primary node is the representative node among all the nodes and the rest are called backups.  
In a pBFT case in which there are f malicious nodes in a total \(N\) number of nodes, consensus can be reached if \(N\) is equal to 3f + 1 [18; 19; 20].  
The following algorithm is applied to utilize pBFT.  
As shown in Table 1, pBFT goes through five steps: request, pre-prepare, prepare, commit, and reply [18]. In the request phase, the client sends a request MM for a service operation to the primary. The primary node generates a sequential number \(N\) according to the request and sends a message to the backups. The pre-prepare message is structured as <Prepare, V, N, D(M)>, in which V is for view of the message, \(N\) is the sequential number, and D(M) is the description of the message M. The message is sent to a random node in which the relationships between D(M), V, and \(N\) are verified, and once the verification shows to be true, the verification message is sent to the rest of the nodes. The prepare message is structured as <Prepare, V, N, D(M), a>, in which a is the number of the verification node. Each node connected to the network collects the pre-prepare and prepare messages and if the message is at least 2f, they prepare the certificate and become a state of \"prepared for the request\". Requests not reaching consensus are denied [19; 21].  
Figure 1: Raft Consensus Algorithm [16; 17].  
pBFT has a fault tolerance up to 33% and may ensure accuracy of a block creation by broadcasting messages to all nodes multiple times, but this may cause the network connection to slow down if there are too many nodes participating in the network [20,21].  
The pBFT may be used in an asynchronous network and goes through two consensus processes as shown in Table 2, which increases network communication for pBFT consensus if the number of participating nodes increase [21,22].  
This paper takes the fact that pBFT is comprised of authorized nodes based on reliability into consideration and uses safety, stating that if a consensus is reached among nodes, any node should have the same value once approached, and liveness, that if there is no problem within the block, there should definitely be a consensus within the network, as an index of evaluation to modify the consensus process. In order to satisfy the two conditions for a blockchain consensus, safety and liveness, pBFT considered \(N=3\)\(t+1\) for the conditions, resulting in a 33.3% loss of liveness and If the number of nodes increases in a pBFT consensus algorithm, the network connection costs also increases, resulting in a burden of expenses [21,22].