## 4 Performance Evaluations  
### Experiment Environment  
Table 3 describes the computing environment utilized for the experiments. The experiments were conducted on a computer operating on the Ubuntu 20.04 LTS system. This system comprises a total memory capacity of 64 GB, distributed across four DDR4 16 GB modules. The proposed PBFT method was implemented using Python 3.7.13, and the aiohttp 3.8.1 Python library was employed for HTTP communication.  
In order to compare the performance of the proposed PBFT method, the experiment compared the typical PBFT, DLM-PBFT, and the proposed PBFT method.  
* Typical PBFT: this method is a kind of the traditional Practical Byzantine Fault Tolerance (PBFT), which is a consensus algorithm that allows a system to continue operation even if some nodes fail or act maliciously. It requires a series of communication steps among nodes to reach a consensus and guarantees system reliability. When the number of nodes participating in the blockchain is denoted as \(N\), the communication complexity of this method is \(O(N^{2})\).
* DLM-PBFT: it dynamically adjusts the network's hierarchical structure to enhance consensus performance. However, in a single group, if a node with comparatively high latency is included, it can result in a degradation in the consensus performance.
* Proposed PBFT: the proposed PBFT method initially clusters the nodes participating in the blockchain network according to their location information. It then dynamically adjusts and manages the network's hierarchical structure in response to the current network environment. Consequently, nodes with comparatively low mutual latency can group. Therefore, there is a further decrease in the consensus time.  
The parameters used for the experiment are detailed in Table 4. To assess the effectiveness of the proposed PBFT method, experiments were conducted with node counts of 120, 160, 200, 240, 280, and 300. The maximum number of subgroups (\(N_{child}\) for CPNs and GPNs) started at a minimum of two and increased incrementally in steps of two, reaching up to twenty. The number of nodes in a single group (\(N_{g\_node}\)) was consistently set at four. The network consists of four distinct clusters. Two types of communication latencies were used to simulate a blockchain network with distributed nodes: the latency within each cluster and the latency between clusters involving CPNs. The latency values were based on interactions within a Google Cloud region, reflecting an average of 126 ms between Los Angeles, USA, and Seoul, Korea. The intra-cluster latency was set at an average delay of 0.03 s for transmitting a 1 MB message. Moreover, experiments varied the communication delay ratio between \(L_{inter}\) and \(L_{intra}\), including ratios of 1:2, 1:4, and 1:8. In our experiments, we measured the cumulative time required to process a 1 MB message four times, and the comparison results are detailed in Section 4.2.  
\begin{table}
\begin{tabular}{c c} \hline \hline
**Name** & **Descriptions** \\ \hline OS & Ubuntu 20.04 LTS \\ Mainboard & ASRock TRX40 CREATOR ASWin \\ CPU & AMD Ryzen Threadripper 3960X 24-Cores \\ Processor (12 Cores, 24 Threads) \\ Memory & DDR4 64 GB (16 GB \(\times\) 4) \\ Python & 3.7.13 \\ aiohttp & 3.8.1 \\ \hline \hline \end{tabular}
\end{table}
Table 3: Experimental environments.