## 4 Design
### The Re-Election Process  
The original HBFT algorithm's view-change protocol can be triggered by the client. In this type of triggering mechanism, the client is typically responsible for determining whether the servers have reached a consensus. If a consensus is not reached, it indicates that there might be issues with the server's operations. If the issue lies with the primary node, the client can request the server to replace the primary node. Figure 4: RBFT algorithm flowchart. Figure 3: Consensus on PBFT algorithm. In our improvement of the HBFT algorithm, we have enhanced the handling mechanism for unexpected node behavior. Instead of using view-change to replace Byzantine nodes within the group, we decided not to adopt this approach because the replacement nodes generated through view-change might lack representativeness. Additionally, if the blockchain encounters CFT situations instead of BFT scenarios and cannot be addressed promptly, it could significantly reduce the blockchain's efficiency. To address these concerns, we have chosen to utilize the election mechanism from the RAFT algorithm as a replacement for view-change. This way, we can more effectively elect representative nodes to replace Byzantine nodes within the group. By incorporating the RAFT algorithm, we can also implement the heartbeat mechanism, allowing us to detect leader nodes without having to wait for the consensus phase to end. This improvement ensures better maintenance of blockchain stability. With these modifications, our enhanced HBFT algorithm can efficiently handle unexpected situations, maintain representativeness in node replacements, and promptly address issues related to both CFT and BFT scenarios, thereby improving the overall efficiency and stability of the blockchain. The main difference between our improved HBFT and the original HBFT lies in the ability to rapidly detect when a leader within the group becomes a Byzantine node. Once we detect the occurrence of a BFT or CFT situation within the group, our algorithm utilizes its own selection mechanism to quickly choose a new leader node and broadcasts this information to other nodes outside the group for verification. During the leader node election process, the eligibility of the elected leader is confirmed based on the leader's historical records. We have referred to existing consensus algorithms and made improvements and adjustments based on the HBFT algorithm during the leader node election process. Figure 5 illustrates the flowchart of the operation when a leader node is detected to become a Byzantine node during the consensus process and the message is sent to other nodes within the group to initiate the re-election process. Suppose there is a group in a certain layer of the system, consisting of n nodes. When a node in the group detects that the leader node has become a Byzantine node, it will send a request for a re-election to the remaining nodes, excluding itself. This stage is referred to as t1, and the number of communications in t1 is  
\[\text{t1}=\text{n}-1. \tag{1}\]  
When other nodes receive the message, they will send corresponding requests to the leader node to confirm whether it has become a Byzantine node. In this case, the number of communications is  
\[\text{t2}=\text{n}-2. \tag{2}\]  
After discovering that the leader node has become a Byzantine node, an intragroup election will be held. The RAFT election algorithm will be used to vote on the candidate node, where the communication number is  
\[\text{t3}=\text{n}-1. \tag{3}\]  
Figure 5: The re-election process. When a candidate node receives more than half of the votes, it will become a leader and notify the superior group that it has become a leader node. The communication number here is 1, and it will also broadcast itself as a leader node to other members in the group.