# The Evolution and Optimization Strategies of a PBFT Consensus Algorithm for Consortium Blockchains
## 4 Analysis of the Improved PBFT Consensus Algorithm
### The Hierarchical Group Consensus Algorithm  
The PBFT consensus protocol distinguishes between two distinct types of nodes: primary nodes and replica nodes. Each node type is designed to fulfill specific functions that enhance the overall efficiency and effectiveness of the consensus network. Primary nodes are responsible for leading the consensus process, while replica nodes play a critical role in validating transactions and maintaining the integrity of the network. The coordinated interaction between these two types of nodes is essential for achieving a reliable consensus in distributed systems. However, as the number of nodes within the network increases, a significant challenge emerges, as communication overhead and consensus latency is associated with the traditional PBFT consensus algorithm. With more nodes participating in the consensus process, the volume of messages that must be exchanged escalates, which can lead to an increased latency in reaching an agreement. This scalability issue poses significant hurdles for the efficient performance of the PBFT protocol, particularly in larger networks where the demands for rapid consensus and low communication costs become paramount. To address this challenge, researchers have proposed dividing the consensus process into groups and modifying the consensus protocol to operate as an intra-group consensus followed by inter-group confirmation. In this approach, a specific grouping algorithm is first employed to partition the nodes into groups, where nodes within each group achieve synchronous consensus. Afterward, the primary nodes of each group mutually confirm whether consensus has been reached. The hierarchical grouping consensus process is illustrated in Figure 10. This method effectively reduces the communication overhead required for consensus confirmation during the prepare and commit phases, thereby increasing transaction throughput and reducing consensus latency. [PERSON] et al. [91] addressed the issues of high latency, large system overhead, and limited scalability in the application of blockchain technology for drug traceability. They proposed a Practical Byzantine Fault Tolerance algorithm based on grouping and credit voting (P-PBFT). This algorithm first designs a grouping strategy based on the response speed between drug supply chain nodes, dividing the consensus node set and conducting group consensus. Additionally, the algorithm's credit model and voting mechanism dynamically update the nodes' credibility based on their behavior during consensus, assessing the  
Figure 10: The hierarchical consensus network topology. nodes' reliability, and electing a leader node based on credibility. This algorithm not only improves throughput but also significantly reduces consensus latency. [PERSON] et al. [92] suggested a consensus algorithm based on feature-based trust groups, referred to as GPBFT. Initially, this algorithm assesses the trust levels of nodes involved in the transaction process employing the EigenTrust model, which serves as the foundation for selecting both leader and replica nodes. Additionally, it categorizes the nodes within the blockchain system into several groups, achieving consensus within individual groups while designating the leader node externally. This approach minimizes communication overhead when dealing with a substantial number of nodes within the system. [PERSON] et al. [93] proposed a consensus algorithm known as credit-based Byzantine Fault Tolerance (CBFT). This algorithm categorizes network nodes into various consensus groups--management nodes, candidate nodes, and regular nodes--determined by their response times to the management nodes. Consensus is established within and among these groups to minimize communication overhead while improving system security. Furthermore, CBFT incorporates a reputation evaluation framework that sorts nodes into different categories according to the reputation model.