## 3 Improved RE-BPFT Blockchain Consensus Algorithm
### View Change Protocol  
To ensure system continuity and consistency when primary node \(PN\) fails, this paper designs a view change protocol incorporating a reputation scoring mechanism. The view change process is triggered when any of the following abnormal conditions occurs in the primary node:  
1. Fails to receive at least \(2f+1\) valid PREPARE messages within timeout period \(T_{1}\);
2. Fails to successfully package and broadcast new block (\(T_{2}>T_{1}\)) within maximum tolerance time \(T_{2}\). To prevent Byzantine primary nodes from repeatedly disrupting consensus, the system adopts a reputation-weighted primary node election strategy during view changes. Specifically, the system selects highly reputable and active nodes from the \"excellent node set\" excel as candidate primary nodes. The new primary node election no longer uses simple modulo rotation logic but introduces weighted randomness to prevent \"oligarch nodes\" from dominating the system long-term. The improved primary node selection formula is as follows:\[prim=argmax_{i\in excel}(credit_{i}\cdot rand_{i}) \tag{14}\]  
where credit \(i\) represents the current reputation score of candidate node \(i\), and \(rand_{i}\in(0,1)\) is a pseudo-random factor generated based on system seed. This strategy introduces a degree of randomness while maintaining reputation priority, effectively mitigating the issue of high-reputation nodes monopolizing the primary node role. The detailed algorithm is presented in Algorithm 2. ``` Input: Client request message \(msg\), view number \(v\), node set \(N\), system fault tolerance node count \(f\) Output: Client response result, node ledger update
1. The client sends a consensus request \(msg\) (containing operation, timestamp, client identifier) to the primary node \(PN\)//Client request phase
2. The primary node \(PN\) assigns a number to \(msg\) and calculates the digest
3. Calculate the primary node's reputation value \(credit_{PN}\) and generate the hash digest \(OUTCOME\gets Hash(credit_{PN}\times rand_{PN})\)
4. Construct the pre-prepare message \(M_{prepare}\leftarrow(v,d,msg,OUTCOME)\)
5. \(PN\) broadcasts \(M_{prepare}\) to all consensus nodes
6. for each consensus node \(n_{i}\in N\)do//Consensus node preparation phase
7. Verify \(M_{prepare}\) (validate \(v,d,OUTCOME\))
8. if verification passes then
9. Calculate local reputation value \(credit_{i}\), construct \(M_{prepare}\leftarrow(v,d,OUTCOME,credit_{i})\)
10. Broadcast \(M_{prepare}\) to other consensus nodes
11. end if
12. end for
13. Master node \(PN\) collects \(M_{prepare}\) message set \(S_{prepare}\) Master node collects prepare messages
14. If \(|S_{prepare}|\geq 2f+1\)then
15. if all \(M_{prepare}\) contents are consistent then
16. Construct confirmation message \(M_{commit}\leftarrow(v,d)\)
17. \(PN\) broadcasts \(M_{commit}\) to consensus nodes
18. else
19. Mark conflicting nodes and execute penalty \(credit_{i}\downarrow\)
20. if number of dissenting nodes \(\geq f+1\)then
21. \(PN\) is demoted; triggers view change
22. end if
23. end if
24. else
25. Insufficient preparation messages, \(PN\) was demoted, triggering view change
26. Elect new primary node from excellent nodes based on \(credit\times rand\)
27. end if
28. for each consensus node \(n_{i}\in N\)do//Block commit phase
29. if received valid and consistent \(M_{commit}\)then
30. Commit new block to local ledger
31. end if
32. end for
33. Primary node \(PN\) returns transaction processing result to client, ending consensus process//Client feedback phase

## 4 Experimental Verification and Analysis

To evaluate the performance of the proposed improved RE-PBFT consensus algorithm, a consortium blockchain system was constructed and simulated using Python 3.9 on a computer equipped with an Intel Core i5-10400 processor, 16 GB RAM, and Windows 10 operating system. The experiment compared RE-PBFT against classical PBFT [17], RBFT [28], and PPoR [29] across three key performance metrics: communication overhead, system throughput, and transaction latency.