A Secure and Intelligent Data Sharing Scheme for UAV-Assisted Disaster Rescue

The emerging blockchain technologies in wireless networks for secure data sharing have attracted wide attention from both academia and industry. Liang et al. [21] design a permissioned blockchain-based electricity trading platform in industrial Internet of things (IoT) to address the high management cost, ensure reliable data transmission, and build trust among grid operators and electricity consumers. By leveraging the consortium blockchain, Chen et al. [22] develop a trustful on-chain and off-chain data sharing framework in vehicular networks, where edge nodes (i.e., roadside units (RSUs)) are responsible for blockchain maintenance by operating the practical Byzantine fault tolerance (PBFT) consensus protocol. Jiang et al. [23] investigate a blockchain-based reliable artificial intelligence (AI) model sharing mechanism for object detection in autonomous driving with cross-domain adaptation, where mobile edge computing (MEC) nodes run the delegated proof-of-stake (DPoS) algorithm for efficient ledger management. By deploying a vehicular blockchain network with homomorphic cryptosystem, Kong et al. [24] propose a secure and verifiable sensory information collection and sharing scheme in fog computing-enabled IoV, where the consensus process in blockchain is managed by RSUs with PBFT protocol. One can observe that most of the existing blockchain systems heavily depend on communication infrastructures for block building and consensus management and cannot be directly applied for disaster areas with severely disrupted or unavailable infrastructures.

Recently, many works have been reported on computation offloading for UAVs with constrained onboard resources. Bai et al. [18] design an MEC-based energy-efficient task offloading framework for UAVs in wireless networks with consideration of active and passive eavesdroppers and time-duration constraints. By exploiting the edge infrastructures, Callegaro et al. [25] propose an edge computing-based computation offloading scheme and design the optimal offloading policies for UAVs with joint consideration of network and computation load of MEC nodes. Chen et al. [26] present a hybrid edge/cloud computing-based offloading scheme to efficiently offload UAVs’ real-time computation tasks to proximal edge servers or remote cloud servers to reduce latency and improve energy efficiency. Liu et al. [20] devise an online multi-hop trajectory scheduling and computation task assignment algorithm for UAVs based on Lyapunov optimization and Markov approximation approaches for joint computing delay and cost minimization in the edge-cloud environment. However, as network infrastructures can be unavailable or insufficient in disaster scenarios, conventional cloud or edge based offloading mechanisms are difficult to meet the QoS requirements of UAVs. Moreover, different from the assumption in most of the existing works, it is not readily available for both resource consumers and resource contributors to acquire the accurate cost model parameters to determine the optimal offloading policies in practice.

In this work, distinguished from existing works, we study a lightweight and green consensus protocol for disaster scenarios with weak network connections to facilitate the implementation of blockchain into UDRNs. Besides, we devise an intelligent DRL-based optimal offloading algorithm under the promising VFC paradigm by exploiting the idle computation and storage resources shared by ground vehicles. Compared with our previous work [1], new contributions of this paper include: (1) we design a misbehavior tracing mechanism and give the property analysis of our RescueChain system; (2) we derive the SE for the general case of VFC-based offloading with multiple UAVs and vehicles with continuous strategies; and (3) we develop a two-tier deep Q-network (DQN)-based offloading mechanism to enhance the performance of Q-learning based offloading mechanism in [1].

Fig. 2 depicts a typical UAV-aided disaster rescue network (UDRN), which is composed of a group of UAVs, ground vehicles, ground stations, and a permissioned blockchain. More basic information about UDRNs can be found in works [10, 8].

In a given investigated disaster area, a set of vehicles, denoted as $\mathcal{I}=\{1,\cdots,i,\cdots,I\}$, are to perform search and rescue missions, where part of roads and network infrastructures are damaged. To facilitate data transmissions among ground rescue vehicles, a fleet of UAVs, denoted as $\mathcal{J}=\{1,\cdots,j,\cdots,J\}$, are dispatched to establish emergency communications by forming flexible aerial subnetworks. Each UAV $j\in\mathcal{J}$ is equipped with multiple sensors (e.g., thermometer, infrared camera, and GPS) to perceive its surroundings. On one hand, to save UAV’s limited battery energy, the sensory data (e.g., images, videos, and audios) collected by UAVs can be transmitted to ground vehicles for processing (referred to as VFC) such as pattern recognition and survivor detection via aerial-to-ground (A2G) links. On the other hand, a group of UAVs can serve as aerial communication relays via aerial-to-aerial (A2A) links to enhance network connectivity. Let $R_{j}^{A2G}$ and $R_{j}^{A2A}$ denote the radiuses of A2G and A2A communication ranges of UAV $j$, respectively. Due to the destruction of network infrastructures, the emergency control centers such as ground stations are deployed to coordinate both aerial and ground subnetworks by scheduling UAVs and vehicles. To better adapt to the affected areas, the ground station is hosted by an emergency communication vehicle (ECV) [27] with powerful communication and computing capabilities.

The blockchain contains a growing sequence of hash-chained blocks and each block $\mathcal{B}$ has two parts: the block body $body$ and the block header $header$. The block body includes a set of time-stamped records (e.g., sensory data, computing results, rescue commands, and node misbehaviors) which are compressed into a Merkle tree $\mathcal{T}_{1}$. To alleviate the heavy storage burden of blockchain, only the data pointers are recorded on-chain while the source data are moved to an off-chain data repository. The block header consists of the metadata of block such as the hashes of parent and current blocks, the Merkle root of $\mathcal{T}_{1}$, the block height, the signature of block creator, aggregated signatures of block validators, and a script $LastProof$ for misbehavior tracing (defined in IV-D). In RescueChain, only authorized entities can participate in the permissioned blockchain network after registration at the certification authority (CA) using their true identities. Let $\mathcal{M}=\{1,\cdots,m,\cdots,M\}$ be the set of authorized nodes in the blockchain. Three different roles of participants are considered in the blockchain as follows:

• •

  Full nodes store the copy of all blocks and are candidates of validators.

• •

  Lightweight nodes only need to store the block headers and can receive blockchain services from nearby full nodes. They can not participate in the consensus process for ledger maintenance.

• •

  Validators are part of full nodes and serve as consensus nodes in the blockchain that are responsible for consensus management by executing consensus protocols.

In the system, each ECV acts as a full node. Each authorized UAV can opt to be a lightweight node or full node based on its computation and storage capacities.

For efficient flying trajectory modeling, the total time period $T$ is evenly divided into $N$ time slots with an interval of $\Delta_{t}\!=\!\frac{T}{N}$. As each time slot can be sufficiently small, UAV $j$’s instant location at $n$-th time slot can be roughly fixed. The horizontal location of UAV $j$ at $n$-th time slot is denoted as $\mathbf{l}_{j}[t_{n}]=(x_{j}[t_{n}],y_{j}[t_{n}])$. To avoid frequent ascending and descending and maintain continuous flight over the air, the hovering altitude of UAV $j$ is considered to be fixed at ${H}_{j}$ during executing a rescue task [5, 28, 29, 30, 31], which varies for different tasks. In practice, the fixed hovering altitude refers to the lowest altitude at which the UAV can avoid any terrain or building obstructions in the task area, hence reducing the additional energy loss caused by frequent height changes. Let $E_{j}^{\min}$ be the minimum energy reserve of UAV $j$ to prolong its battery life. Then, UAV $j$’s remaining battery energy at $n$-th time slot is constrained by $E_{j}^{\min}\leq E_{j}[t_{n}]\leq C_{j}$, where $C_{j}$ is the battery energy capacity of UAV $j$. As UAV $j$ flies at a constant height, according to [29, 30, 31], its flying power $P_{j}^{\mathrm{fly}}[t_{n}]$ to propel its mobility and keep it aloft at $n$-th time slot is positively related with both the velocity $v_{j}[t_{n}]$ and acceleration $a_{j}[t_{n}]$, i.e.,

where $g$ is gravitational acceleration with nominal value $9.8\,\mathrm{m/s^{2}}$. $\lambda_{1}$ and $\lambda_{2}$ are parameters depending on UAV’s weight (containing its payload), air density, wing area, UAV type (e.g., fixed-wing or rotary-wing), etc. The flying velocity $v_{j}[t_{n}]$ of UAV $j$ is:

where $v_{j}^{\max}$ is the maximum velocity of UAV $j$.

For ground vehicles, the fluid traffic model [32] is adopted to capture the relationship between the traffic density $\chi$ and average vehicular velocity $\overline{v}_{GV}$. We have:

where ${\chi_{\max}}$ means the maximum traffic density. ${v_{GV}^{\max}}$ and ${v_{GV}^{\min}}$ are the maximum and minimum vehicle velocities, respectively. The number of ground vehicles entering the communication coverage of UAV $j$ at $n$-th time slot can be computed as $\phi_{j}[t_{n}]={\chi}\overline{v}_{GV}\Delta_{t}$. Let $o_{j}[t_{n}]$ denote the ratio of ground vehicles leaving the coverage of UAV $j$ at $n$-th time slot. Based on [11], the number of vehicles in the communication range of UAV $j$ at $n$-th time slot is calculated as:

The limited communication and battery resources of UAVs may be unaffordable to execute compute-intensive and delay-critical rescue tasks. Consequently, the executing time for rescue missions may be prolonged and the recharging interval of UAVs may be shortened. Under the VFC paradigm, the UAV’s heavy data computation and storage missions can be efficiently offloaded to ground vehicles in its communication coverage by collaboratively contributing their idle resources. Let $\mathcal{I}_{j}[t_{n}]=\{1,\cdots,i,\cdots,I_{j}[t_{n}]\}$ be the set of cooperative vehicles in UAV $j$’s coverage at $n$-th time slot. Each task of UAV $j$ to be offloaded to a vehicle $i\in\mathcal{I}_{j}[t_{n}]$ can be denoted as a 4-tuple, i.e.,

where $D_{j,k}$ (in bits) denotes the data size of task. $\theta_{i,j,k}$ (in CPU cycles/bit) indicates the required CPU cycles to process one bit. $T_{j,k}^{\max}$ (in seconds) means the time-to-live (TTL) of task. $\alpha_{j,k}\in[0,1]$ is the urgency degree for mission processing, and a higher $\alpha_{j,k}$ implies a higher urgency degree. $K_{j}$ is the total number of UAV $j$’s tasks to be offloaded.

In VFC, when all $D_{j,k}$ bits of task data are transmitted to a ground vehicle $i\!\in\!\mathcal{I}_{j}[t_{n}]$ through A2G communication, the data computation process is executed immediately on the vehicle, and then $\mu_{j,k}D_{j,k}$ bits of the processed results are sent back to the UAV $j$ through ground-to-aerial (G2A) communication. Here, $\mu_{j,k}\!\in\!(0,1)$ denotes the output/input ratio. Let $x_{i,j,k}$ be the amount of computing resource (AoCR) contributed by vehicle $i$ in performing mission $\Gamma_{j,k}$, which is measured by CPU cycles per second. According to [33], the execution time of mission $\Gamma_{j,k}$ in vehicle $i$ can be calculated as $t_{i,j,k}^{\mathrm{vfc}}=\frac{\theta_{i,j,k}D_{j,k}}{x_{i,j,k}}$. Besides, the energy consumption of vehicle $i$ in performing mission $\Gamma_{j,k}$ is:

where $\kappa_{i}$ is the effective switched capacitance [34].

For A2G/G2A communications, the line-of-sight (LoS) link is presumed to be dominant [33], and the channel gain between UAV $j$ and ground vehicle $i$ can be modeled by the free-space path loss model, i.e., $\varphi_{i,j}[t_{n}]={\varphi_{0}}\left(d_{i,j}[t_{n}]\right)^{-\mu}$, where ${\varphi_{0}}$ is the channel gain at the reference distance $d_{0}=1$, $\mu>1$ means the path loss exponent, and $d_{i,j}[t_{n}]$ represents the Euclidean distance between UAV $j$ and ground vehicle $i$ at $n$-th time slot. The frequency division multiple access (FDMA) protocol is applied for bandwidth sharing among ground vehicles in transmitting computation outcomes to the UAV [34]. Then, the available G2A uplink transmission rate from vehicle $i$ to UAV $j$ is obtained as:

where $B_{i}^{\mathrm{UL}}$ is the assigned uplink bandwidth to vehicle $i$, $P_{i}^{\mathrm{TX}}$ means vehicle $i$’s transmit power, and $\sigma_{0}^{2}$ is the power of additive white Gaussian noise. Moreover, the A2G downlink transmission rate from UAV $j$ to vehicle $i$ is denoted as:

where $B_{j}^{\mathrm{DL}}$ is UAV $j$’s downlink bandwidth, and $P_{j}^{\mathrm{TX}}$ is UAV $j$’s transmit power.

Three kinds of adversaries considered during information sharing in UDRNs are listed as follows.

• •

  Malicious Insider UAVs. Due to the open-access features of UAV networking to maximize the life-saving potential under disasters, any entities including malicious ones can connect to UAVs freely. Consequently, UAVs may be compromised and controlled by them to tamper with the sensory data, disseminate falsified information, and produce fake blocks.

• •

  Threats to Data Dependability. Owing to the unreliable wireless environment, the disseminated data (e.g., sensory data, processed results, and scheduling commands) may be forged, replaced, or deleted during multi-hop data transmissions[35]. Moreover, it is difficult to transparently audit the delivered information to enforce accountability when disputes occur.

• •

  Threats to Misbehavior Traceability. Traditional centralized misbehavior tracing mechanisms usually lack transparency and auditability and may suffer from the single point of failure (SPoF) and DDoS attack, causing difficulty in trustworthy, auditable, and immutable misbehavior tracing and punishment enforcement.

In UDRNs, owing to the sparse network environment and possible poor connections, network partitions may be frequent, resulting in the risks of blockchain forking. Besides, the limited resource of UAVs in terms of battery, computation, and storage restrict the adoption of conventional resource-hungry blockchains. Accordingly, our RescueChain should be low-cost, infrastructure-free, and robust in UDRNs. To achieve the three goals, we make two improvements: one is the VFC-based off-chain mechanism to offload the heavy data computation and storage tasks from UAVs; the other is the reputation-based Tendermint consensus protocol to robustly reach consensus in the weakly connected environment with enhanced safety. In particular, as shown in Fig. 3, the following three phases need to be undertaken:

• •

  Entity registration and key distribution. In this phase, after registration at CA, each authorized entity obtains its key pair and opts its role in the blockchain system.

• •

  VFC-based off-chain storage and computation. This phase performs off-chain data computation and storage for UAVs under the VFC paradigm.

• •

  Reputation-based Tendermint consensus process. In this phase, each entity runs the reputation-based Tendermint protocol to reach consensus on the new transactions to be added to the blockchain via validator election, two-phase voting with locking, and reputation assessment.

The system parameters are selected by CA based on the Boneh-Lynn-Shacham (BLS) short signature scheme [36]. A multiplicative bilinear map $e:\mathbb{G}_{1}\times\mathbb{G}_{2}\rightarrow\mathbb{G}_{3}$ is chosen by CA, where $g_{1}$ and $g_{2}$ are generators of groups $\mathbb{G}_{1}$ and $\mathbb{G}_{2}$, and $q$ is the prime order of $\mathbb{G}_{k}(k=1,2,3)$. Two hash functions $\mathbf{H}_{0}:\{0,1\}^{*}\rightarrow\mathbb{G}_{2}$ and $\mathbf{H}_{1}:\{0,1\}^{*}\rightarrow\mathbb{Z}_{q}$ are chosen by CA. Then, CA broadcasts the system parameters $parm$ to the network:

Each authorized node $m\in\mathcal{M}$ registers itself at CA using the real identity $RID_{m}$ and receives a group of $L$ private/public key pairs $\{{sk}_{m}^{l},{pk}_{m}^{l}\}_{l=1}^{L}$, wallet addresses, and certificates in the blockchain from CA. Here, ${sk}_{m}^{l}\xleftarrow{S}\mathbb{Z}_{q}$, ${pk}_{m}^{l}=g_{2}^{{sk}_{m}^{l}}\in\mathbb{G}_{2}$, and $\xleftarrow{S}$ indicates randomly sampling.

Under VFC, UAVs’ compute-intensive missions (e.g., human detection and multi-object tracking) on sensory data can be offloaded to ground vehicles to save their constrained battery energy. To alleviate the overhead of blockchain and improve system scalability, the VFC-based off-chain approach is adopted by moving both sensed and processed data to off-chain repositories while retaining a data pointer of source data on the blockchain. The set of data to be disseminated in UDRNs is denoted as $\mathcal{D}$. Each data $d\in\mathcal{D}$ is composed of two parts, i.e., the raw sensory data $d_{\mathrm{raw}}$ and the computation outcome $d_{\mathrm{out}}$. In RescueChain, the InterPlanetary File System (IPFS) [37] serves as the distributed off-chain data store, where each data $d$ is stored in the format of distributed files in IPFS and is uniquely addressed by its hash pointer $\mathbf{H}_{0}(d)=\{\mathbf{H}_{0}(d_{\mathrm{raw}}),\mathbf{H}_{0}(d_{\mathrm{out}})\}$. The ground vehicles serve as the distributed storage nodes in IPFS. After VFC-based computation offloading process for task $\Gamma_{j,k}$, UAV $j$ sends an off-chain storage transaction $tx_{\mathrm{data}}$ to the network as:

where ${pk}_{j}^{l}$ is the public key of UAV $j$. $\{{pk}_{i}^{l}\}_{i=1}^{I_{j}}$ is the group of public keys of vehicles involved in task $\Gamma_{j,k}$. $desc_{d}$ is the description of data $d$. $tStamp$ is the timestamp of $tx_{\mathrm{data}}$ generation. $\sigma_{j}=\mathbf{H}_{0}(tx_{\mathrm{data}})^{{sk}_{j}^{l}}$ means the signature of UAV $j$. $\sigma_{k}=\prod_{i=1}^{I_{j}}\bar{\sigma}_{i}$ is the BLS multi-signature of ${I_{j}}$ vehicles, where $\bar{\sigma}_{i}=\mathbf{H}_{0}(tx_{\mathrm{data}})^{\omega_{i}\cdot{sk}_{i}^{l}}$ and $\omega_{i}=\mathbf{H}_{1}({pk}_{i}^{l},\{{pk}_{1}^{l},\cdots,{pk}_{I_{j}}^{l}\})$. $cert_{DS}$ is the unique certificate issued by the IPFS data store.

In RescueChain, the Tendermint protocol [38] is adopted to reach consensus among distrustful UAVs due to its high energy efficiency and partial partition tolerance than its alternatives. To be adaptive to the sparse network environment in UDRNs, the multi-signature method [36] is applied in the consensus phase for bandwidth saving. To further enhance the safety of consensus and speed up the consensus process, our RescueChain incorporates reputation assessment into the Tendermint for validator election and block bookkeeping. In the proposed reputation-based Tendermint protocol, the following steps are included:

Step 1: Validator election. The consensus process is carried out by an elected validator committee, denoted as $\mathcal{Z}=\{1,\cdots,z,\cdots,Z\}$. Let $\mathcal{U}=\{1,\cdots,u,\cdots,U\}$ be the set of full nodes. Every full node $u\in\mathcal{U}$ can vote for a delegate and its voting weight is determined by its stake, namely, the reputation value ${\overline{\Im}_{u}}$. The top $Z$ delegates with the highest votes are selected to form the validator committee $\mathcal{Z}$, which can be further classified into two kinds: level-1 validators and level-2 validators. The top $\Psi$ validators with the highest votes serve as level-1 validators which can propose and validate new blocks, while the remaining $Z-\Psi$ validators are level-2 validators that can only perform block verification.

Step 2: Consensus process. The consensus process is composed of three phases: propose, prevote, and precommit. To eventually reach consensus in weakly connected UDRNs, the network is assumed to be partially synchronous, and the partial synchrony model [39] is applied in protocol design. An upper bound $\Delta$ of transmission delay and an unknown global stabilization time (GST) are defined in UDRN. In the partial synchrony model, there exist either a known upper bound $\Delta$ after the unknown GST or an unknown upper bound $\Delta$ on the transmission latency of messages. It means that the transmission between two correct entities in UDRN will eventually arrive within 1) the unknown timeout $\Delta$, or 2) the known timeout $\Delta$ beginning with an unknown GST. At each round of consensus process for a certain height, a small fixed increment of the timeout $\Delta$ is added than its previous round [40]. Besides, the internal clocks of non-Byzantine validators are assumed to be sufficiently accurate during a short time period until reaching consensus on the next block. In the following, we elaborate the detailed process to reach consensus in our RescueChain.

1) Propose phase. A leader $\hbar$ is designated from $\Psi$ level-1 validators in a round-robin fashion. At its round $r$, the leader $\hbar$ collects a batch of recent transactions from its local memory pool, compresses them into a Merkle tree $\mathcal{T}_{1}$, and packages them into a block $\mathcal{B}$ which includes a hash linked to the previous block. Then, a signed proposal is gossiped to the network, i.e.,

where $\Upsilon_{\hbar}$ is the proof-of-lock (PoL) indicating the locked block of the leader ${\hbar}$, and $\sigma_{\hbar}$ is its signature. A PoL for block $\mathcal{B}$ (or $nil$) means that a leader receives at least $\frac{2}{3}Z$ prevotes for block $\mathcal{B}$ (or $nil$) at round $r$ for height $h$ [40]. Note that the block $\mathcal{B}$ can be quite large, and can be a network bottleneck in disseminating it to other validators. To alleviate the communication burden of leader ${\hbar}$ in disseminating block $\mathcal{B}$, we design a block partition method for efficient proposal transmission. Specifically, the raw block is serialized and split into multiple chunks with appropriate size, and all the chunks are hashed into a Merkle tree $\mathcal{T}_{2}$. A Merkle root $root_{\mathcal{B}}$ together with the signature of leader ${\hbar}$ are included in the proposal. Once a validator receives all the chunks, it performs the block deserialization operation and validates the correctness of the received proposal by checking the Merkle root $root_{\mathcal{B}}$.

2) Two-phase voting with locking. In two-phase voting, each validator sends its prevote result of the proposal to the network in the first phase, and tells its precommit result of other validators’ claims regarding the proposal in the second phase. Intuitively, it can be ensured that the result of the first phase has been witnessed by enough validators in the second phase to offer Byzantine tolerance. Besides, the following two rules are defined in the locking mechanism to ensure blockchain safety:

• •

  Locking rule. A validator $z$ is locked on ${\mathcal{B}}$ (or $nil$) if it receives over $\frac{2}{3}Z$ prevotes for block $\mathcal{B}$ (or $nil$) at round $r$ for height $h$. Then, at round $r^{\prime}>r$ for height $h$, it should prevote for the locked block, and propose it if it is the leader. This can prevent validators from prevoting different blocks in different rounds, thereby protecting safety as conflicting blocks may be committed at the same height.

• •

  Unlocking rule. A validator can only unlock the block ${\mathcal{B}}$ which is locked at round $r$ if there exist a PoL for another block ${\mathcal{B}}^{\prime}$ (or $nil$) at a higher round $r^{\prime}$, where $r^{\prime}>r$. This allows validators to be unlocked and precommit another block that the rest of the network intend to commit, thereby protecting liveness.

If the validator $z\in\mathcal{Z}$ is locked on a block proposal at a previous round, it broadcasts a prevote for the locked block with its signature $\sigma_{z}$. Otherwise, if a valid proposal is received for the current round after verification, validator $z$ broadcasts a prevote for that block with its signature. If no proposal or a invalid one is received within the timeout $proposeTimeout$, validator $z$ sends a special prevote for $nil$ instead. The form of prevote message is:

where $block$ is the prevoted block or $nil$. $proposeTimeout$ is the maximum time that a validator stays in the propose phase, which is initialized as $\Delta_{propose}$ at the beginning of a height $h$ and is incremented every time $proposeTimeout$ expires.

If there exists a PoL for block $\mathcal{B}$, the validator $z$ locks on block $\mathcal{B}$, releases the prior locked block, and broadcasts a precommit for $\mathcal{B}$. If there exists a PoL for $nil$, the validator $z$ unlocks, and it broadcasts a precommit for $nil$. Otherwise, the validator $z$ precommits $nil$. The explicit form of precommit message is

The same prevote or precommit messages signed by distinct validators can be aggregated by BLS multi-signatures for compressed signature size. If validator $z$ receives over two-thirds of precommits for a specific block, it simply sets its commit time $commitTime$ to the current time and moves on to round $0$ at the next height $h+1$. Then, the specific block is eventually committed. Otherwise, it moves to the next round $r+1$ at current height $h$. Then, a new leader is designated and the above process is repeated. Before entering the next height $h+1$, validators wait until some fixed time duration past $commitTime$ to include more commits from validators with slower network connections.

Step 3: Misbehavior tracing. Malicious validators may conduct various kinds of misbehaviors to crash the consensus process and fork the blockchain. A malicious leader may conduct conflicting proposals (cp) misbehavior by disseminating conflicting block proposals to different validators within a round, and malicious validators may perform conflicting votes (cv) misbehavior by giving prevotes or precommits to conflicting proposals. A malicious leader can conduct wrong block creation (wbc) misbehavior by producing invalid block or true block at false round and height, and non-block creation (nbc) misbehavior if the block proposal is not generated on time or it is offline or partitioned. The above misbehaviors (i.e., $cp$, $cv$, $wbc$, and $nbc$) can be identified via their signatures attached on the proposals or votes, thereby the corresponding misbehaving entities can be detected. Moreover, malicious validators can perform violation of locking (vol) misbehaviors by violating the locking and unlocking rules to make the network commit on two different blocks at a height. In this case, if a prevote or precommit resulted from a $vol$ misbehavior affects the final commit, at least one honest validator must have been received it. As honest validators should broadcast all their received votes at each round of a height, the evidences of violations of the locking rule can be collected by stitching all votes and matching every prevote with the most recent precommit of the same validator. The violations of unlocking rule can be detected similarly via matching every precommit with the PoL that justifies it.

For efficient and reliable misbehavior forensics and tracing, a script denoted by $LastProof$ is included in the next block at height $h+1$, which contains the set of signed precommits that make the prior block at height $h$ committed (i.e., $LastCommit$), together with all votes justifying the precommits at all rounds for height $h$ (i.e., $LastVotes$). As such, the unjustified votes and the misbehaving entities can be identified and traced. For alleviated blockchain burden, all the votes in $LastVotes$ are moved to an off-chain data store instead, and only a Merkle tree $\mathcal{T}_{3}$ constructed from $LastVotes$ are included in the $LastProof$ with a root $root_{V}$. Furthermore, to accelerate misbehavior detection, nodes can form informer groups to report misbehaviors by collecting the cryptography trails as evidence and generating a report transaction as:

where ${pk}_{u^{\prime}}^{l}$ is the public key of accused node $u^{\prime}$. $\{{pk}_{u}^{l}\}_{u=1}^{N_{rep}}$ and $\sigma_{rep}$ are the public keys and BLS multi-signature of the ${N_{rep}}$ informers, respectively. $fee$ is the fixed report fee to prevent DDoS attack and is evenly divided among them. $Evidence$ is the collected evidence such as the digital signatures on votes or proposals at different rounds of a height.

Step 4: Reputation evaluation. The reputation of each full node is calculated based on two aspects: behavior effect and time fading effect. Commonly, node’s reputation can be gradually improved by benign behaviors and significantly decreased by misbehaviors; meanwhile, latest behaviors are of more significance than previous ones in determining current reputation. The following benign behaviors are considered in blockchain: the successful block creation (sbc) behavior of the leader and the successful block verification (sbv) behavior of validators. Both the $sbc$ and $sbv$ behaviors can be detected by the signatures on block proposal and precommits included in the $LastCommit$. Let $\Delta_{b}$ be the reputation reward or penalty for behavior $b$. A binary variable $\beta_{b}=\{-1,1\}$ is defined, where $\beta_{b}=1$ if $b$ is a benign behavior; and $\beta_{b}\!=\!-1$ if $b$ is a misbehavior. Besides, if $tx_{\mathrm{rep}}$ is verified as true and recorded in blockchain, all members within the informer group are rewarded with a reputation increase $\Delta_{rep}$, as well as a reputation decrease $\Delta_{acc}$ for the accused entity. Otherwise, the expended report fee is in vain. Here, the evidence collection and misbehavior forensics are out of scope for this paper, and readers can refer to existing works [41, 42]. At each time slot, each full node $u$’s reputation can be computed as:

where $\Im_{u}^{\mathrm{ini}}$ is the initial reputation of full node $u$, ${N_{u}^{n}}$ is the number of recorded behaviors of full node $u$ at $n$-th time slot, and $\eta>0$ is the exponential decay factor. The normalized reputation of each full node can be formulated as ${{\overline{\Im}_{u}^{n}}}=\left(1+e^{-\Im_{u}^{n}}\right)^{-1}$. The reputation values of full nodes are updated after each round of consensus according to the time-stamped behavior records stored in the blockchain.

Let $P_{b}$ denote the ratio of Byzantine validators in RescueChain, and $P_{p}$ be the ratio of validators that are offline or partitioned in UDRNs. According to [40, 38], under partial synchrony assumption of the network, our RescueChain system is resilient up to $N_{fault}=\lfloor\left(Z-1\right)/3\rfloor$ Byzantine validators. Next, we analyze the finality, network availability, and communication complexity of RescueChain in the following Theorems 1–3, respectively.

Theorem 1 (Finality): With assumptions of partial synchrony and $P_{b}\leq 1/3$, by taking multiple rounds at a given height to commit a block via two-phase voting with locking, our RescueChain can reach deterministic finality, where a deadlock that different blocks are locked by part of honest validators at different rounds can be avoided.

Payoff function of UAV. During VFC-based offloading process, to stimulate ground vehicles’ participation and high amount of resource sharing, each UAV $j$ needs to determine the payment vector ${\bf{y}}_{j}=\left\{{y_{i,j,k}}\right\}_{k=1}^{K_{j}}$ for each task $k$ to compensate the cost of ground vehicles in contributing computation resources. Let ${\bf{x}}_{j}=\left\{{x_{i,j,k}}\right\}_{k=1}^{K_{j}}$ denote the AoCR vector of ground vehicles that participate in the offloading process for UAV $j$. The payoff function of UAV $j$ is defined as the difference between the satisfaction and its cost, i.e.,

where $\beta_{i,j,k}\!=\!\{0,1\}$ is a binary variable which equals to zero if vehicle $i$ does not participate in the offloading of task $\Gamma_{j,k}$, otherwise it equals to one. $S_{j,k}\left(x_{i,j,k}\right)$ is the satisfaction function of UAV $j$ with the obtained AoCR ${x_{i,j,k}}$ of each task $\Gamma_{j,k}$. $C_{j,k}\left(x_{i,j,k},y_{i,j,k}\right)$ is the cost function of UAV $j$ during offloading. Here, the logarithmic function, which is widely employed in resource allocation mechanisms [46], is used to model the satisfaction. We have

where ${\rho_{j}}$ means the satisfaction parameter of UAV $j$, and ${\alpha_{j,k}}$ is the urgency degree of task $\Gamma_{j,k}$ defined in Eq. (5). The cost function $C_{j,k}\left(x_{i,j,k},y_{i,j,k}\right)$ is composed of two parts: the payment for shared computation resource (i.e., ${\lambda_{p}{x_{i,j,k}}{y_{i,j,k}}}$) and the time delay to obtain the processing results (i.e., $\Phi_{i,j,k}$). We have

where ${\varpi_{p}}$ means the weight factor, and $\lambda_{p}$ is the price adjustment parameter. Next, we analyze the total delay and energy consumption in task offloading.

1) Delay analysis. The total offloading latency $\Phi_{i,j,k}$ for every task $\Gamma_{j,k}$ includes three parts: the A2G transmission time $t_{i,j,k}^{\mathrm{A2G}}$, the task execution time $t_{i,j,k}^{\mathrm{vfc}}$, and the G2A transmission time $t_{i,j,k}^{\mathrm{G2A}}$. The A2G transmission time is denoted as $t_{i,j,k}^{\mathrm{A2G}}=\frac{{{D_{j,k}}}}{{\gamma_{i,j}^{\mathrm{A2G}}}}$. As UAVs and ground vehicles are highly mobile, vehicle $i$ may leave the communication range of UAV $j$ and drive into the coverage of another UAV $j^{\prime}$, $j^{\prime}\neq j$. Without loss of generality, we denote $t_{k}$ as the time slot that UAV $j$ begins to offload mission $\Gamma_{j,k}$. Two cases of G2A transmission latency are considered as below:

where ${\gamma_{{j^{\prime}},j}^{\mathrm{A2A}}}$ is the A2A transmission rate between UAV $j$ and UAV $j^{\prime}$. Hence, we have $\Phi_{i,j,k}=t_{i,j,k}^{\mathrm{vfc}}+t_{i,j,k}^{\mathrm{A2G}}+t_{i,j,k}^{\mathrm{G2A}}$.

2) Energy consumption analysis. The energy consumption of UAV $j$ during task offloading includes two parts: the A2G transmission energy and the flying energy. UAV $j$’s energy consumption during A2G transmission is denoted as $E_{i,j,k}^{\mathrm{A2G}}=P_{j}^{\mathrm{TX}}\,t_{i,j,k}^{\mathrm{A2G}}$. The flying energy of UAV $j$ can be attained as $E_{i,j,k}^{\mathrm{fly}}=P_{j}^{\mathrm{fly}}\Phi_{i,j,k}$.

The target of each UAV $j\in\mathcal{J}$ is to maximize its payoff function by deciding the optimal payment strategy ${{\bf{y}}_{j}}$, whereby its optimization problem $P1$ is formulated as:

Constraint (21) indicates that the total time delay of each task $\Gamma_{j,k}$ should be less than or equal to the task TTL $T_{j,k}^{\max}$. Constraint (22) implies that the remaining battery energy of UAV $j$ after task execution should not less than its minimum energy reserve $E_{j}^{\min}$. Constraint (23) means that the payment should be constrained by the lower bound $0$ and the upper bound $y_{j,k}^{\max}$.

Payoff function of ground vehicle. In VFC-based task offloading, the payoff function of each ground vehicle is associated with the payment provided by the UAV and its cost of sharing computing resources to the UAV. As such, the payoff function of ground vehicle $i$, $\forall i\in\mathcal{I}_{j}$ is the difference between the payment and the cost in sharing computing resource to UAV $j$, i.e.,

where $\Psi_{i}\left({x_{i,j,k}}\right)$ is the cost function, which contains two parts: the cost for sharing ${x_{i,j,k}}$ amount of computation resources and the energy consumption in data computing and transmission. According to the quadratic cost model [47], the cost of resources sharing can be formulated as a quadratic function of the contributed resources. As such, $\Psi_{i}\left({x_{i,j,k}}\right)$ can be defined as

The first term in formula (25) represents the quadratic cost in sharing ${x_{i,j,k}}$ amount of computation resources, and the second term indicates the total energy consumption in computing (i.e., $E_{i,j,k}^{\mathrm{vfc}}$) and data transmission (i.e., $P_{i}^{\mathrm{TX}}t_{i,j,k}^{\mathrm{G2A}}$). Here, $\lambda_{c}$ and ${\lambda_{e}}$ are positive adjustment parameters. ${\psi_{i}}$ is the unit cost of vehicle $i$’s computation resource.