## 3 Improved RE-BPFT Blockchain Consensus Algorithm
### View Change Protocol
To reflect realistic transaction behaviors in large-scale consortium blockchain applications, particularly traceability scenarios, the experiment simulated transaction data across multiple business phases. Scalability tests were conducted by increasing the number of nodes in the system from 10 to 60. All nodes were initially assigned a trust value of 70. After system startup, clients submitted a total of 200 transaction request sets to the network. Each experimental configuration was repeated 20 times, and the average results were recorded as the final performance data. Detailed hardware and software experimental settings are provided in Table 4.

In this experiment, the system's throughput was determined by counting the transactions successfully completed. The metric \"transactions per second\" (TPS) was used to quantify throughput performance. By gradually increasing concurrent transaction volumes and recording the number of transactions processed successfully per unit of time, the system's overall throughput was measured. Transaction latency was assessed by logging the interval between transaction initiation and final execution confirmation. Various transaction concurrency scenarios were simulated, and the execution time for each transaction was captured, enabling the calculation of average transaction latency. To examine the communication overhead, we recorded the number and size of messages exchanged between nodes during the consensus process. Node communications were monitored throughout the experiment, with message counts logged and analyzed, providing insight into the communication overhead incurred by the system. ### Consensus Latency

Consensus Latency (CL) is a critical performance metric for consensus mechanisms, typically representing the time required for a blockchain network to confirm a transaction after its initiation. A lower CL indicates higher consensus efficiency in a blockchain system. We define the period from the selection of consensus nodes to the completion of transaction confirmation as \(CL\). The calculation formula for \(CL\) is as follows:

\[CL=T_{\text{c}}-T_{r} \tag{15}\]

Here, \(T_{c}\) denotes confirmation time, and \(T_{r}\) represents initiation time. To comprehensively evaluate the CL of different consensus mechanisms, we measured the CL under varying node counts with transaction sizes of 1, 10, 50, and 100 KB. For clearer experimental presentation, single transactions of different sizes were used to measure CL. Figure 2 displays the CL of PBFT, RBFT, and PPoR under different experimental conditions. When the number of consensus nodes and transaction size were identical, RE-PBFT demonstrated \begin{table}
\begin{tabular}{c c} \hline \hline
**Experimental Setup** & **Configuration** \\ \hline Operating System & Windows 10 64-bit Professional Edition \\ Experimental Platform & Python 3.9 \\ Processor & Intel (R) Core (TM) i5-10400 \\ Memory & 16 GB RAM \\ Number of Nodes & 10–60 nodes \\ Network Model & Local area network simulating network latency \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Experiment configuration. significantly lower latency than PBFT and RBFT, outperforming PPoR as well. As shown in Figure 2, while the node count increased from 10 to 60, RE-PBFT consistently maintained a low latency level, whereas PBFT's Consensus Latency (CL) rose sharply with the growing number of nodes. The graph reveals that when the network node count exceeded 30, both PBFT and RBFT exhibited notable upward trends in CL, while RE-PBFT's CL increased more gradually, showing relative stability and stronger scalability. For instance, with a transaction size of 100 KB and 60 nodes, PBFT's CL reached 164.2 ms, whereas RE-PBFT's CL was only 71.6 ms--a reduction of approximately 56.4%, highlighting its exceptional latency control capability. Moreover, as transaction size grew from 1 KB to 100 KB, PBFT's CL increased significantly, while RE-PBFT consistently maintained the lowest latency across all transaction sizes, demonstrating superior handling capacity for large transactions.