# A Hierarchical Blockchain-Based Trust Measurement Method for Drone Cluster Nodes
## 2 Trust Metric Model of Unmanned Aerial Vehicle Cluster Nodes Based on Hierarchical Blockchain
### Blockchain Data Sharing Mechanism under Resource Constraints
#### 2.3.4 Latency Analysis  
PBFT consensus has the advantage of low block latency, but each step in the consensus process requires verification confirmation messages from a certain number of nodes. If some nodes experience long verification message delays, it will affect the overall latency of the consensus. Therefore, to meet the timeliness of reputations being recorded on the blockchain for UAVs, we utilize the high computing power of cluster-head UAVs to offload the verification tasks of low computing power nodes within the cluster. Considering  
Figure 5: Consensus process. the cryptographic operation calculation, let \(f_{m}^{max}\) represent the total allocatable computing power of cluster head node \(m\), and \(f_{i,m}^{ver}\) represent the allocated computing power for UAV to perform offloaded PBFT consensus verification tasks. Thus, the total allocatable computing power of cluster head node \(m\) can be expressed as  
\[f_{m}^{max}=\sum_{i=1}^{i}f_{i,m}^{ver}. \tag{10}\]  
In the transmission process of task offloading, the system adopts a universal frequency reuse scheme, which means that all cluster head nodes use the same radio resources. Each cluster head node and the UAVs use orthogonal spectra for block transmission, which means there is no interference between the UAVs connected to the same cluster head node. Let \(a_{i,m}\) represent the bandwidth percentage allocated by cluster head node \(m\) to UAV \(i\). The useful signal power ratio CINR is denoted as \(\gamma_{i,m}\), and the total bandwidth is \(B_{m}\). According to [PERSON]'s theory, the offloading rate between cluster head node \(m\) and UAV \(i\) is calculated as  
\[u_{i,m}=a_{i,m}B_{m}\log_{2}(1+\gamma_{i,m}). \tag{11}\]  
After task offloading, the analysis of the latency in each step of the PBFT consensus for the drone cluster is as follows. * Request: The block-generating node sends an unverified content block to the leader node. The content block includes the signature of the transaction user, and the block-generating node signs the content block. After the leader node verifies the signature, it proceeds to the next step. * Latency Analysis: The delay in the request phase mainly comes from the leader node's verification of the block-generating node's signature. Assuming that the CPU cycles required for signature verification are \(\delta_{1}\), the offloaded verification computational power of the leader node is \(f_{i,m}^{ver}\), the size of the received message is \(\mu_{1}\), and the offloading rate is \(u_{i,m}\); the time required to complete this step can be expressed as \[t_{1}=\frac{\delta_{1}}{f_{i,m}^{ver}}+2\frac{\mu_{1}}{u_{i,m}}.\] (12)
* Pre-Prepare: Nodes sign the unverified content block and send the signed pre-prepared message to other nodes. * Latency Analysis: The delay in the pre-prepare phase mainly comes from the leader node signing the received message and multicasting it to all other slave nodes. Assuming that the CPU cycles required for signing and verifying the received message digest are \(\delta_{2}\), the size of the received message is \(\mu_{2}\), and the broadcast rate of the leader node is \(u_{i}\); the time required for the leader node to complete this step is calculated as \[t_{2}=\frac{\delta_{2}}{f_{i}}+\frac{\mu_{2}}{u_{i}}.\] (13)
* Prepare: In the prepare phase, slave nodes validate the signature of the leader node to ensure that no one has forged the message. After checking the integrity of the message, the signature indicates agreement to validate and acknowledge receipt. The signed prepared message is then sent to other nodes. Each node receives \(2f\) (\(f\) being the number of tolerated Byzantine nodes) and prepares messages before proceeding to the next step. * Latency Analysis: In the prepare phase, the leader node needs to generate its signature for the prepare message and send it to the secondary nodes. It also needs to validate \(2f\) to prepare messages from other slave nodes.