## 1 Introduction
### Related Work  
[PERSON] et al., introduced the concept of blockchain in their paper \"Bitcoin: A Peer-to-Peer Electronic Cash System\" [1], which provided a new application scenario for distributed algorithms. They also proposed the most famous algorithm in the blockchain field, Proof of Work (PoW), which uses a mechanism to demonstrate computational effort. Since then, blockchain has evolved to include three different types with varying levels of security: public chains, consortium chains, and private chains. In the realm of consortium blockchains, consensus algorithms can be mainly categorized into two types. The first type is Byzantine Failure, with Practical Byzantine Fault Tolerance (PBFT) [3; 5] being a representative consensus algorithm. The second type is Fail-Stop Failure, with RAFT [4] being a notable consensus algorithm in this category. PBFT (Practical Byzantine Fault Tolerance) [6] was proposed by [PERSON] and [PERSON]. The PBFT algorithm can operate in an asynchronous environment and addresses the inefficiency of the original Byzantine fault-tolerant algorithm by optimizing it, reducing the algorithmic complexity from exponential to polynomial levels. This optimization made Byzantine fault-tolerant algorithms practical for real-world system applications, and PBFT has been widely adopted. PBFT ensures both safety and liveness as long as the number of faulty nodes does not exceed one-third of the total nodes. However, due to its high communication complexity, PBFT is only scalable to a few dozen nodes. When the number of nodes in the network exceeds this threshold, the time required for transaction consensus in PBFT significantly increases, leading to a decrease in throughput. To address the scalability challenge of PBFT, researchers have conducted in-depth studies on the algorithm. [PERSON] et al., proposed a hybrid Byzantine fault-tolerant state machine replication protocol called HQ in 2006 [7]. Although HQ did not fundamentally change the structure of PBFT, it optimized the scenario where clients do not compete when sending requests. In 2007, [PERSON] et al., introduced speculation techniques to Byzantine protocols, resulting in the Zyzzyva and Zyzzyva5 protocols [8]. While these protocols greatly improved system performance under normal conditions, they suffered a significant performance degradation when faced with Byzantine problems. In their work, [PERSON] et al., presented the Scrooge protocol, which inherited the framework of the Zyzzyva protocol and increased the number of servers to improve system performance. In addition to server-side speculation, [PERSON] et al., proposed a Byzantine system based on client speculation (client speculation) in 2009 [9]. In 2017, [PERSON] et al., introduced a tree-based topology design for Byzantine fault-tolerant systems, using a multi-branch tree approach to optimize the complexity of the PBFT algorithm. This optimization reduced the communication complexity from O(P\({}^{2}\)) to O(P), while also improving scalability [10]. [PERSON] et al., proposed an improved algorithm called tPBFT (Trust-Based Practical Byzantine Fault-Tolerant) that is suitable for high-frequency transaction scenarios in consortium chains. It dynamically adjusts the consensus node list by introducing a trust fairness scoring mechanism among nodes in the network [11]. The dynamic adjustment of consensus nodes, when combined with optimization algorithms from artificial intelligence, can significantly enhance the performance of blockchain systems by preselecting nodes. [PERSON] et al., presented an algorithm based on reputation called RBFT, where a node's reputation determines its probability of being selected as the new primary node to generate new blocks [12]. [PERSON] et al., proposed the GH algorithm based on PBFT, which divides all replicas into multiple groups, with each group having a primary node. Clients broadcast requests to all nodes, and PBFT is executed within each group, followed by another round of PBFT execution among the primary nodes in each message [13].