## 5 Experiment
### Experiment Settings  
We build a multi-node heterogeneous simulated experimental environment using docker to test the performance and scalability of the blockchain and federated learning algorithms. The experimental environment consists of fifteen nodes running on two computers, each configured with a 2-core processor and 4 GB of RAM to simulate a real heterogeneous IoT environment. In this experiment, we use Python 3.10 and PyTorch v1.13.1 for model training, while Hyperledger Fabric v2.3.0 is employed as the blockchain infrastructure. To enable the local training process to communicate with the blockchain, we developed a RESTful service based on Express.js v4.17.1 and ran it under the node.js v14.16.1 environment.  
For blockchain, a new block is generated if one of the following conditions is met: the waiting time for the next transaction reaches 2 s, the number of received transactions reaches 10, or the size of the received transactions reaches 100 MB. For federated learning, before the start of each experiment, the federated learning client selection scheme selects 9 devices to participate in each round of training, and each participant's dataset is divided into multiple small batches, each containing 300 data samples. The learning rate \(\eta\) was set to 0.01. The DQN algorithm uses four threads to interact with the external environment and collect empirical data in the process. The reward discount factor was set to 0.9, and the learning rate of the Q-network (value network) was set to 0.0001. The target network was updated with the parameters of the Q-network after every 100 rounds of agent training. In addition, the buffer size for experience replay was set to 10,000. The settings of the specific experimental parameters are shown in Table 1. In our simulations, the CPU cycle frequency \(f_{d}\) of the client devices follows a uniform distribution U[0, 1], while the wireless bandwidth \"r\" follows a uniform distribution U[0, 2], a setting that satisfies various computational and communication capabilities between the devices [39].  
The CIFAR-10 and MNIST datasets were selected for the experiments and trained using CNN and MLP models for federated learning. To evaluate the performance of the proposed BHFL model in terms of convergence speed and accuracy, we compared some state-of-the-art synchronous and asynchronous federated learning methods as benchmarks.  
1. BHFL-ST: A node selection model based on BHFL using commonly used single-target nodes, focusing on leveraging the impact of large amounts of data.  
\begin{table}
\begin{tabular}{l c c} \hline \hline
**Parameter Type** & **Parameter** & **Value** \\ \hline \multirow{5}{*}{Environment} & Processor & 2 cores \\  & Memory & 4 GB RAM \\  & Python & 3.10 \\  & PyTorch & v1.13.1 \\  & CPU cycle frequency & [0, 1] \\  & Wireless bandwidth & [0, 2] \\ \hline \multirow{5}{*}{Federated learning} & Number of terminals & 15 \\  & Number of nodes involved & 9 \\  & Local minibatch size \(B\) & 300 \\  & Learning rate \(\eta\) & 0.01 \\ \hline \multirow{5}{*}{Blockchain} & Time to wait before creating a block & 2 s \\  & Mmaximum number of messages per block & 10 \\  & Maximum bytes of messages per block & 100 MB \\ \hline \multirow{5}{*}{DQN} & Training steps & 1000 \\  & Q-network learning rate & 0.0001 \\ \cline{1-1}  & Bonus discount factor & 0.9 \\ \cline{1-1}  & Strategy update steps & 100 \\ \cline{1-1}  & Experience replay buffer & 10,000 \\ \cline{1-1}  & Batch size & 64 \\ \hline \hline \end{tabular}
\end{table}
Table 1: Parameter setting.  
2. BHFL-SYNC: The federated learning process is synchronized, with all nodes simultaneously aggregating and updating parameters at the end of each round.
3. BHFL-AVG: Unlike the aggregation mechanism of BHFL, this framework utilizes the traditional federated average aggregation algorithm.