## 3 Improved RE-BPFT Blockchain Consensus Algorithm
### Consensus Protocol  
RE-PBFT retains all phases of PBFT while eliminating communication between network nodes, thereby reducing bandwidth usage. The algorithm selects normal or higher-tier nodes as consensus participants to ensure system reliability and security. The consensus protocol flow is illustrated in Figure 1.  
In the request phase, client \(C\) sends a consensus request message \(<REQUIST,M,t,CID,Sign_{C}>\) to the current primary node \(PN\). The message includes the pending state machine operation  
Figure 1: RE-PBFT Consensus Protocol.  
\(M\), current timestamp \(t\), and client identifier \(CID\). After validating the request, the primary node proceeds to the next phase.  
In the pre-prepare phase, the primary node assigns a unique sequence number \(N\) to the client request and computes its digest \(DIGEST=Hash(M)\). Simultaneously, it calculates a credit value \(CREDIT_{PN}\) based on the node reputation scoring model, then generates a hash: \(OUTCOME=Hash(CREDIT_{PN})\). The primary node then constructs and broadcasts a pre-prepare message to all consensus nodes: \(<PRE-PREPARE,V,N,DIGEST,OUTCOME,CREDIT_{PN},M>\), where \(V\) is the current view number and \(M\) contains the client request. Recording OUTCOME enables traceability and consistency verification of consensus behavior in subsequent phases.  
During the preparation phase, after receiving the pre-prepare message from the primary node, the consensus nodes first verify the integrity and consistency of the message, including the view number, digest, reputation score, etc. If the verification passes, the consensus node generates a prepare message and broadcasts it to other consensus nodes. The message format is \(<PREPARE,V,N,DIGEST,i,CREDIT_{i}>\), where \(i\) is the identifier of the sending consensus node, and \(\text{CREDIT}_{i}\) is its current reputation score. After receiving the PREPARE messages from other consensus nodes, if the number of valid PREPARE messages exceeds \(2f\) (where \(f\) is the maximum number of Byzantine nodes tolerated by the system), the primary node considers the preparation phase successful and proceeds to the commit phase. If the number is insufficient, the primary node triggers the View Change protocol, transferring its authority to the newly elected node with the highest reputation, and broadcasts a failure message: \(<VIEW-CHANGE,V+1,reason>\). The original primary node is then demoted to a regular node, losing its leadership in subsequent consensus rounds.  
During the commit phase, after the preparation phase is completed, the primary node performs a consistency check on all received prepare messages. If all messages are consistent, it generates a commit message and broadcasts: \(<COMMIT,V,N,DIGEST,CONFIRM>\). Upon receiving the COMMIT message, the consensus nodes perform final confirmation and submit the new block generated by the request to their local ledger. Subsequently, the primary node sends the transaction processing result to the client, indicating the completion of the current consensus round. If more than \(f\) consensus nodes submit prepare messages inconsistent with the primary node during this phase, the system determines that consensus has not been reached and triggers the demotion and penalty mechanism:  
1. All consensus nodes with inconsistencies will have their reputation scores deducted;
2. If the number of dissenting nodes \(\geq f+1\) the current primary node will also be demoted, and the consensus process will be restarted.