A lightweight dynamic security-associated double-layer UAV blockchain construction method and device

Abstract

The embodiment of the present invention provides a lightweight dynamic security-associated two-layer drone blockchain construction method. The present invention provides a lightweight dynamic security-associated two-layer drone blockchain construction method and device. The method and device construct an execution layer blockchain based on the subtask cluster division, and construct a command layer blockchain based on the execution layer blockchain; construct a multi-center semi-structured blockchain network topology model based on multiple routing nodes, which effectively adapts to the elastic changes in the scale of blockchain nodes, reduces the network diameter, reduces redundant communications, and improves communication quality; divides the nodes in the network into several clusters, and improves the data transmission rate of the blockchain system; selects a non-proof-of-work consensus mechanism to achieve fast and lightweight hierarchical consensus within and between chips, reduces unnecessary hardware performance waste, and improves consensus efficiency; designs a node dynamic reputation point algorithm combined with a consensus algorithm to improve the system's fault tolerance for negative and malicious behaviors of nodes. In addition, the embodiment of the present invention uses a two-layer drone blockchain construction device to implement the construction of the execution layer blockchain and the command layer blockchain.

Description

Technical Field

[0001] The present invention relates to a method and device for constructing a double-layer UAV blockchain, and in particular to a method and device for constructing a lightweight dynamic security-associated double-layer UAV blockchain. Background Art

[0002] Small rotary-wing drones, thanks to their compact size, low cost, rapid deployment, and high maneuverability, have been widely used in fields such as data collection, logistics, environmental monitoring, and military operations, becoming a vital civilian and military asset. However, with the continuous expansion of application scenarios and mission types, the limited capabilities of a single drone are no longer sufficient for many scenarios. For example, in battlefield environments, a single drone performing intelligence reconnaissance or target attack missions faces the risk of being destroyed or captured, leading to mission failure. In environmental monitoring, the limited field of view of a single drone reduces the efficiency of information collection and processing. Therefore, organizing multiple drones to collaboratively perform missions has become an important means of improving mission efficiency and success rates. This is especially true in harsh environments and complex tasks. Multi-drone collaboration significantly improves the overall efficiency of the fleet by sharing and integrating multi-type, multi-angle data between individual drones. Multi-drone collaboration has gradually become a key research topic in the field of drone applications.

[0003] Network communication is a prerequisite for multi-machine collaboration. Drones are small in size and have limited computing resources, necessitating a distributed ad hoc network approach for multi-machine collaboration. Compared to traditional ad hoc networks, drone ad hoc networks are characterized by frequent node entry and exit, high sensitivity to communication delays, and a lack of infrastructure support. These characteristics, in turn, present more complex security challenges for drone ad hoc networks. First, drone ad hoc networks face the inherent security threats of traditional wireless networks, such as sniffing, replay, denial-of-service attacks, and Sybil attacks. Commands and data from drone systems are transmitted over unprotected wireless channels, making them vulnerable to loss, tampering, and replay, severely compromising system security and data availability. Second, drone ad hoc networks lack fixed infrastructure such as available base stations, making it difficult for drones to maintain a reliable backhaul link with a ground station or control center for extended periods. However, traditional centralized multi-drone systems rely heavily on central drone nodes or other edge servers and ground units for data storage and processing, resulting in a high risk of single points of failure. An attack on an edge server or central drone node could paralyze the entire network.

[0004] The similarity between blockchain systems and multi-UAV systems, both of which are distributed, self-organizing systems, provides insights into blockchain-based solutions for addressing the security challenges of multi-UAV ad hoc networks. Leveraging the distributed nature of blockchain and UAV ad hoc networks, blockchain's self-organizing and tamper-proof properties can enhance the controllability and security of UAV swarms. On the one hand, leveraging blockchain's security features can effectively mitigate information security threats such as single points of failure and cyberattacks facing UAV systems. On the other hand, distributed collaboration technology based on smart contracts within blockchain systems can provide the underlying technical support for autonomous multi-UAV collaboration.

[0005] Furthermore, drones primarily rely on wireless communication, and the data and technical information they transmit and carry are highly confidential. Furthermore, drone collaboration requires extremely high real-time performance. Delays in data exchange and control commands within the network can lead to unpredictable consequences and mission failure. Drone nodes move much faster than ordinary moving objects like pedestrians and cars, and their high mobility results in frequent changes in network topology. Furthermore, uncertainties such as weather conditions, geographical obstacles, mission changes, network anomalies, and the addition of new drones can all cause network topology changes.

[0006] Therefore, when building a UAV blockchain self-organizing network for collaborative environments, it is necessary to focus on the following two aspects:

[0007] (1) Network topology optimization problem under dynamic changes in node scale

[0008] In the dynamic network environment of intelligent drone swarm collaboration, the cluster is rapidly reconfigured after drones join and leave the fleet, resulting in elastic changes in the scale of drone nodes and rapid dynamic changes in the network topology. Structured topology uses a deterministic topology structure and distributed hash tables to provide precise node positioning, which provides high system reliability. However, the low degree of decentralization causes the cost of topology construction and maintenance to increase significantly with network scale, making it unable to adapt to frequent node changes. Unstructured topology removes routing nodes, allowing new nodes to connect to other nodes arbitrarily to form a random topology. While this structure is simple to implement and easy to maintain, as the network scale continues to expand, unstructured topology networks can be instantly paralyzed when message storms occur, resulting in poor scalability.

[0009] (2) Improving consensus efficiency under a mixed distribution of strong and weak computing power nodes

[0010] Drone swarms have a mixed distribution of strong and weak computing power, and energy reserves are limited. Traditional proof-of-work consensus protocols require extensive and complex mathematical calculations, resulting in high time and energy costs for weak computing power nodes to participate in consensus. This also ignores the division of labor and collaboration among nodes with different computing power. Furthermore, drone swarms are numerous, and there may be passive and malicious nodes. To reach consensus within a single blockchain layer, accounting nodes must wait for more than half of the verification information to be counted. This results in high consensus latency and low network throughput, making it difficult to meet the needs of intelligent collaboration in drone swarms. Summary of the Invention

[0011] To address the existing technical issues, the present invention provides a lightweight, dynamic, and securely associated dual-layer drone blockchain construction method. This method constructs a hierarchical drone blockchain based on a "command layer-execution layer." To address the problem of optimizing network topology under dynamic node scale, a node clustering algorithm based on proximity sensing clustering is designed. Clustered routing nodes are calculated using the latitude and longitude coordinates and flight altitudes of multiple nearby, system-certified drones. This algorithm divides network nodes into several clusters, reducing network diameter, reducing redundant communication, and improving communication quality. A multi-center, semi-structured blockchain network topology model is constructed to enable dynamic self-organizing networks of drone blockchain nodes in an intelligent collaborative environment. To improve consensus efficiency under a mixed distribution of strong and weak computing power nodes, a dynamic, lightweight, hierarchical consensus based on non-proof-of-work is designed to reduce consensus computation complexity. The distributed self-organizing and data tamper-proof nature of blockchain supports secure and intelligent collaboration within drone swarms. A node dynamic reputation scoring algorithm is designed, integrated with the consensus algorithm, to calculate drone node reputation scores and construct a reputation score block to record each node's reputation score. This improves the fault tolerance of the dual-layer drone blockchain system to both passive and malicious node behavior.

[0012] The technical solutions adopted in the present invention are as follows:

[0013] A lightweight dynamic security-associated two-layer UAV blockchain construction method includes the following components:

[0014] A. Initialize the attribute parameters of UAVs performing collaborative tasks: Based on their storage capacity, divide the UAVs performing tasks into those with strong storage capacity and those with weak storage capacity. Initialize the combat information of the two types of UAVs. UAVs with strong storage capacity store global task information, while UAVs with weak storage capacity only store their own task information.

[0015] B. Constructing a two-layer drone blockchain using the drone's initial attribute parameters and mission information: Drones serve as blockchain nodes to build and maintain the two-layer drone blockchain. Sharding is performed based on each drone's subtask ID. Multiple vertical cross-layer blockchain shards are constructed at the execution layer. Nodes in each shard communicate with other nodes via the P2P protocol to build and maintain the execution layer blockchain. After the sharding is completed, nodes within each shard select the node with the strongest computing power and storage of global mission information as the command node for the shard based on the parameter information of all nodes within the shard. The command nodes communicate with each other via the P2P protocol to build and maintain the command layer blockchain.

[0016] C. Setting up a two-layer drone blockchain lightweight hierarchical consensus:

[0017] i. Blockchain consensus protocol setup: Design a master-slave node consensus model, setting up three types of nodes: master nodes, slave nodes, and low-reputation nodes. Set up a single master node and multiple slave nodes within each shard of the execution layer. The master node generates blocks and calculates voting results, while the slave nodes verify block content and vote. The voting behavior of low-reputation nodes is ignored when the master node records the account. Both master and slave nodes record block content.

[0018] ii. Setting up a blockchain reputation score accumulation mechanism: Design a dynamic reputation score algorithm for nodes, calculate node activity based on the time sequence of voting messages, calculate node credibility based on the frequency of sending false votes, design node incentive factors to regulate the speed of node reputation score accumulation, and construct a reputation score block to record the reputation score value of each node;

[0019] D. Construct a multi-center semi-structured blockchain network topology model: Routing nodes are generated from execution layer nodes. Routing nodes record routing node information of other network clusters and forward transactions between clusters through routing nodes, achieving parallel broadcasting between network clusters, synchronizing data between blockchain shards, and improving the transmission rate of the blockchain system. The node number thresholds for network cluster fusion and cluster splitting, as well as the topology control message sending interval, are initialized. A hash lookup table based on the mapping between drone IDs and communication addresses is constructed, and node communication addresses are quickly found using ID matching. The network topology is automatically adjusted based on changes in the number of drone cluster nodes and the division of labor in combat missions, thus building a dynamic self-organizing network of drone blockchain nodes.

[0020] E. The two-layer drone blockchain nodes reach consensus and keep accounts: the command node is responsible for packaging the block and broadcasting it to the execution node in the shard. The execution node verifies the block content packaged by the command node by running the block verification contract. If the verification is correct, the block verification pass message is broadcast. The command node needs to collect the block verification pass messages sent by the client nodes and check the block verification pass message content. When the total number of collected verification pass messages exceeds half of the current total number of nodes, the consensus is completed; the command node adds the block to the execution layer blockchain of the shard, and uses the block number, consensus completion message identifier, and the signature of the above two parts of data using its own node private key, a total of three parts of data constitute the block verification completion message, and broadcast the consensus completion message; after receiving the block verification completion message broadcast by the command node, the execution node writes the consensus-passed block into the local blockchain. Each command node submits the consensus-passed block in the shard to the command layer. The nodes in the command layer reach an agreement on the block after consensus.

[0021] The construction method described in Component A includes drone attribute parameters: drone ID, model, maximum flight altitude, maximum flight speed, battery capacity, computing power, and storage capacity. All drones must initialize their attribute parameters. The overall mission is divided into multiple subtasks. Task information includes: mission type, mission ID, mission area map, target information, task division information, preset mission path, and mission time limit. Nodes with strong storage capabilities store global mission information and each drone's attribute parameters, while nodes with weak storage capabilities store local attribute parameters and local subtask information.

[0022] The construction method described in Component B divides the shards according to each drone's subtask ID, ensuring that drones performing the same subtask are in the same shard, and that each shard has at least one drone storing global task information. Within each shard, the node with the strongest computing power is selected from the nodes storing global task information and becomes the command node for that shard. The command node participates in both intra-shard and inter-shard consensus.

[0023] The construction method described in component C(i) forms a master-slave node consensus model with a single master node and multiple slave nodes within the shard, selects a non-proof-of-work consensus mechanism to reduce unnecessary waste of hardware performance, and the selected consensus mechanism can process data quickly. Nodes with accounting rights need to record every piece of data truthfully.

[0024] The construction method described in component C(ii) only calculates the reputation points of drone nodes that have passed system authentication, calculates the node activity and node credibility of each authenticated node, and designs node incentive factors to regulate the accumulation speed of node reputation points to avoid the emergence of reputation point oligopoly nodes.

[0025] The construction method described in Component D selects routing nodes based on a proximity sensing clustering algorithm. Routing nodes must be nodes that store global mission information. Each routing node communicates with routing nodes in other network clusters and records routing node information in other network clusters. Driven by mission requirements, reasonable node number thresholds for network cluster fusion and cluster splitting, as well as topology control message sending intervals, are set. Each routing node stores a hash lookup table based on the mapping between drone IDs and communication addresses.

[0026] The construction method described in Component E adopts POA as the consensus mechanism for each shard at the execution layer. During the intra-shard consensus process, only the command node within the shard is the only node with the authority to package blocks, and other execution nodes are only responsible for verifying blocks. Raft is used as the consensus mechanism at the command layer. The command layer nodes elect a temporary leader. The leader is responsible for verifying whether the proposal meets the requirements for chain upload and broadcasting proposals that meet the requirements. Other command nodes are only responsible for verifying the proposal. Once consensus is reached, the leader will notify other nodes to accept the proposal and write the proposal block into the blockchain.

[0027] In another aspect, the present invention provides a lightweight, dynamic, and securely associated dual-layer UAV blockchain construction device, comprising the following modules:

[0028] Execution layer blockchain building module: The drones performing the mission are clustered according to their combat mission IDs. Multiple shards corresponding to multiple mission clusters are formed at the execution layer. A dynamic reputation points mechanism based on node consensus behavior is set up, and node incentive factors are set to regulate the node reputation point accumulation speed to avoid the emergence of reputation point oligopoly nodes. The POA consensus mechanism is set up, and an appropriate block generation time interval is set to generate blocks.

[0029] Command layer blockchain construction module: The command node is selected based on the computing power of the nodes that store global task information within the shard. In subsequent elections, the node with the highest reputation score is selected as the command node. The Raft consensus mechanism is set up, and the same dynamic reputation score mechanism and node incentive factor as the execution layer blockchain are set up. The command node submits the verified blocks in the shard and the reputation update records of the nodes in the shard to the command layer, and each command node reaches consensus and stores them.

[0030] The technical solution and construction device provided by the present invention have the following beneficial effects:

[0031] Among the aforementioned components, a multi-center, semi-structured blockchain network topology model based on a lightweight, dynamically securely associated drone swarm blockchain architecture was constructed, effectively adapting to the elastic changes in blockchain node scale, reducing network diameter, and reducing redundant communication, thereby improving communication quality. The network nodes were divided into several clusters, with information between clusters forwarded via routing nodes. This enabled parallel broadcasting between network clusters, data synchronization between blockchain shards, and improved blockchain system transmission rates. A lightweight storage method based on vertical cross-layer blockchain sharding was proposed. Based on the fleet structure within the drone swarm and the storage space differences between different drone models, data could be flexibly uploaded to the blockchain, effectively reducing the storage burden on drones. A non-proof-of-work consensus protocol based on reputation points was designed to achieve fast and lightweight hierarchical consensus within and between shards, avoiding the need for nodes to perform large amounts of complex mathematical calculations and improving consensus efficiency. A node dynamic reputation point algorithm was designed, combined with the consensus algorithm, to calculate the reputation points of drone nodes that have passed system authentication. A reputation point block was constructed to record the reputation point values ​​of each node, improving the fault tolerance of the two-layer drone blockchain system to negative and malicious node behavior. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0033] Figure 1 This is a schematic diagram of a double-layer drone blockchain structure disclosed in this application.

[0034] Figure 2 This is a schematic diagram of a two-layer drone blockchain sharding consensus disclosed in this application.

[0035] Figure 3 This is a two-layer drone blockchain inter-chip consensus behavior flow chart disclosed in this application.

[0036] Figure 4 This is a schematic diagram of the topology of a two-layer drone blockchain dynamic self-organizing network disclosed in this application. DETAILED DESCRIPTION

[0037] To make the objectives, technical solutions, and advantages of the present invention more clear, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. Obviously, the embodiments described are only part of the embodiments of this application, rather than all the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0038] Step 1: Initialize the attribute parameters and mission information of the UAV that performs the collaborative mission:

[0039] First, the attribute parameters of all drones ready to perform tasks are set, and then subtasks are assigned to the drones according to the attribute parameters and the task information is written to the drone's local storage.

[0040] Drone attribute parameters: drone ID, model, maximum flight altitude, maximum flight speed, battery capacity, computing power, and storage capacity.

[0041] Nodes with strong storage capabilities store global task information: including the task type, task ID, task area map, target information, task division information, preset task path, task time limit, and drone group information, including the attribute parameters of each drone.

[0042] Nodes with weak storage capabilities store local attribute parameters and local task information: task type, task ID, task area map, target information, task division information, preset task path, and task time limit.

[0043] Step 2: Build a two-layer drone blockchain:

[0044] 1) Sharding the execution layer and building the execution layer blockchain: In step 1, the drones were divided into subtasks. We clustered the drones performing the missions according to their combat mission IDs, forming multiple shards corresponding to multiple task clusters in the execution layer. The drone nodes in each shard use P2P protocols such as the Gossip protocol to broadcast the node communication address and node public key to establish communication with nodes in other shards. Each node in the shard is responsible for maintaining the execution layer blockchain of its shard.

[0045] 2) Select execution nodes and build the execution layer blockchain:

[0046] After the sharding is completed, the internal nodes of each shard select the node with the strongest computing power from the nodes storing global task information based on the parameter information of all nodes in the shard as the command node of the shard. The command node selected in each shard uses P2P protocols, such as the Gossip protocol, to broadcast the node communication address and node public key, establish communication with the command nodes of other shards, and build and maintain the command layer blockchain.

[0047] In the actual collaborative task execution scenario, drone nodes work together to perform the overall task, and the overall task is divided into many subtasks, which has a natural multi-center nature. The drone cluster is divided according to the subtasks and the command node is selected, and the command nodes of multiple shards are used to provide full decentralization.

[0048] Step 3: Set up a two-layer drone blockchain lightweight layered consensus:

[0049] 1) Setting up an intra-shard consensus mechanism: We chose POA as the consensus mechanism for each shard at the execution layer, and Raft as the consensus mechanism at the command layer. It's important to note that during the intra-shard consensus process, only the command node within the shard has the authority to package blocks, while other execution nodes are only responsible for verifying blocks, corresponding to our proposed master-slave node consensus model.

[0050] 2) Set up a dynamic node reputation points mechanism:

[0051] In a P2P network, node participation and trustworthiness are key to ensuring network stability. We introduce a dynamic reputation score calculation smart contract, deployed on each node, that dynamically calculates a node's reputation score based on the time sequence of voting messages and the frequency of fraudulent votes. The algorithm considers the following three key factors:

[0052] Node activity: There is an order in which the master node receives signature messages from other ordinary nodes.

[0053] Node credibility: A node’s credibility is related to how often it has sent false votes for multiple consensus processes in the past.

[0054] Node incentive factor: This is to encourage honest nodes whose reputation values ​​are low due to certain factors in the early stage to quickly accumulate reputation values ​​so that they are eligible to participate in the master node election and prevent the emergence of reputation oligarch nodes.

[0055] Step 4: Construction and maintenance of multi-center semi-structured blockchain network topology:

[0056] 1) Routing node selection:

[0057] Traditional processing methods require costly measurements of the network latency between each node and other nodes. Given that the network latency in the proximity sensing clustering algorithm depends on the Euclidean distance between two nodes, the routing node selection process is as follows:

[0058] ① All nodes that store global task information form a candidate subset. Calculate the Euclidean distance between any two nodes in the candidate subset, then find the farthest node pair to form a new set S, and finally delete these two nodes from the candidate subset.

[0059] ② Add the node farthest from the new set to S, and then delete the node from the candidate subset.

[0060] ③If the number of nodes in set S is less than N / logN (N represents the number of nodes in the network), repeat ②; the nodes in the final set S are the routing nodes in the network.

[0061] 2) Network clustering:

[0062] By setting an appropriate Euclidean distance range for clustering, nodes whose Euclidean distance from the routing node is within the given range and are not part of other network clusters form a network cluster. Routing nodes record the routing node information of other network clusters and forward transactions between clusters through routing nodes, enabling parallel broadcasting between network clusters and data synchronization between blockchain shards.

[0063] 3) Topology maintenance:

[0064] The minimum threshold for triggering network cluster merging and the maximum threshold for triggering network cluster splitting are set to logN / l and l*logN respectively (l represents the network cluster adjustment parameter, and N represents the number of nodes in the entire network).

[0065] Step 5: The two-layer drone blockchain node runs consensus and records accounts:

[0066] The command node receives transactions from a shard and stores them in its local transaction pool. It then packages the transactions into blocks and broadcasts them to the execution nodes within that shard. The execution nodes run the block verification contract to verify the contents of the block packaged by the command node. If verified, they broadcast a block verification pass message. The command node collects block verification pass messages from client nodes and examines their contents. Consensus is achieved when the total number of collected verification pass messages exceeds half of the current number of nodes. The command node adds the block to the execution layer blockchain for that shard and broadcasts a block verification complete message consisting of the block number, the consensus complete message identifier, and a signature using its own private key. Upon receiving the block verification complete message from the command node, the execution nodes write the consensus-passed block to their local blockchain.

[0067] Each command node submits the blocks that have passed consensus within its shard to the command layer. The execution layer nodes use the Raft consensus mechanism to reach consensus on the blocks submitted by each command node. At the execution layer, a complete consensus process is considered an epoch. At the beginning of an epoch cycle, the command layer nodes elect a temporary leader. The leader is responsible for verifying whether the proposal meets the requirements for on-chain upload and broadcasting the proposal that meets the requirements. The other command nodes are only responsible for verifying the proposal. Once consensus is reached, the leader notifies the other nodes to accept the proposal and writes the proposed block to the blockchain. At this point, the epoch cycle ends and the next epoch begins. It is also possible to reach consensus on multiple proposals within a single epoch based on actual task requirements.

[0068] In the description provided herein, numerous specific details are described. However, it is understood that embodiments of the present invention may be practiced without these specific details. In some instances, well-known methods, structures, and techniques are not shown in detail so as not to obscure the understanding of this description.

Claims

1. A lightweight dynamic security-associated two-layer UAV blockchain construction method, characterized by: It includes the following components: A. Initialize the attribute parameters of UAVs performing collaborative missions: Based on their storage capacity, the UAVs performing the missions are divided into those with high storage capacity and those with low storage capacity. The combat information of the two types of UAVs is initialized. UAVs with high storage capacity store global mission information, while UAVs with low storage capacity only store their own mission information. B. Constructing a two-layer drone blockchain using the drone's initial attribute parameters and mission information: Drones serve as blockchain nodes to build and maintain the two-layer drone blockchain. Sharding is performed based on each drone's subtask ID. Multiple vertical cross-layer blockchain shards are constructed at the execution layer. Nodes in each shard communicate with other nodes via the P2P protocol to build and maintain the execution layer blockchain. After the sharding is completed, nodes within each shard select the drone node with the strongest computing power and storage of global mission information as the command node for the shard based on the parameter information of all nodes within the shard. The command nodes communicate with each other via the P2P protocol to build and maintain the command layer blockchain. C. Setting up a two-layer drone blockchain lightweight hierarchical consensus: i. Blockchain consensus protocol setup: Design a master-slave node consensus model, setting up three types of nodes: master nodes, slave nodes, and low-reputation nodes. Set up a single master node and multiple slave nodes within each shard of the execution layer. The master node generates blocks and calculates voting results, while the slave nodes verify block content and vote. The voting behavior of low-reputation nodes is ignored when the master node records the account. Both master and slave nodes record block content. ii. Setting up a blockchain reputation score accumulation mechanism: Design a dynamic reputation score algorithm for nodes, calculate node activity based on the time sequence of voting messages, calculate node credibility based on the frequency of sending false votes, design node incentive factors to regulate the speed of node reputation score accumulation, and construct a reputation score block to record the reputation score value of each node; D. Construct a multi-center semi-structured blockchain network topology model: Routing nodes are generated from execution layer nodes. Routing nodes record routing node information of other network clusters and forward transactions between clusters through routing nodes, achieving parallel broadcasting between network clusters, synchronizing data between blockchain shards, and improving the transmission rate of the blockchain system. The node number threshold for network cluster fusion and cluster splitting, as well as the interval for sending topology control messages, are initialized. A hash lookup table based on the mapping of drone IDs and communication addresses is constructed, and node communication addresses are quickly found using ID matching. The network topology is automatically adjusted based on changes in the number of drone cluster nodes and the division of combat missions, thus establishing a dynamic self-organizing network of drone blockchain nodes. E. The two-layer drone blockchain nodes reach consensus and record accounts: the command node is responsible for packaging the block and broadcasting it to the execution nodes in the shard. The execution node verifies the block content packaged by the command node by running the block verification contract. If the verification is correct, the block verification pass message is broadcast. The command node needs to collect the block verification pass messages sent by the client nodes and check the block verification pass message content. When the total number of verification pass messages collected exceeds half of the current total number of nodes, the consensus is completed; the command node adds the block to the execution layer blockchain of the shard, and uses the block number, consensus completion message identifier, and the signature of the above two parts of data using its own node private key. A total of three parts of data constitute the block verification completion message, and the consensus completion message is broadcast; After receiving the block verification completion message broadcast by the command node, the execution node writes the consensus-passed block into the local blockchain. Each command node submits the consensus-passed block within the shard to the command layer. The nodes in the command layer reach an agreement on the block after consensus.

2. The lightweight dynamic security-associated double-layer UAV blockchain construction method according to claim 1 is characterized in that: In Part A, the drone's attribute parameters include: drone ID, model, maximum flight altitude, maximum flight speed, battery capacity, computing power, and storage capacity. All drones must be initialized with attribute parameters. The total task is divided into multiple subtasks, and its task information includes: task type, task ID, task area map, target information, task division information, preset task path, and task time limit. Nodes with strong storage capabilities store global task information and attribute parameters of each machine, while nodes with weak storage capabilities store local attribute parameters and local subtask information.

3. A lightweight dynamic security-associated double-layer UAV blockchain construction method according to claim 1, characterized in that: In the above-mentioned part B, shards are divided according to the subtask ID of each drone to ensure that drones performing the same subtask are in the same shard, and each shard has at least one drone storing global task information. The node with the strongest computing power is selected from the nodes storing global task information in each shard and serves as the command node of the shard. The command node participates in intra-shard consensus and inter-shard consensus.

4. A lightweight dynamic security-associated double-layer UAV blockchain construction method according to claim 1, characterized in that: In the aforementioned part C(i), a master-slave node consensus model with a single master node and multiple slave nodes is formed within the shard, and a non-proof-of-work consensus mechanism is selected to reduce unnecessary waste of hardware performance. The selected consensus mechanism can process data quickly, and the nodes with accounting rights need to record each piece of data truthfully.

5. A lightweight dynamic security-associated double-layer UAV blockchain construction method according to claim 1, characterized in that: In the aforementioned part C(ii), only the reputation points of drone nodes that have passed system authentication are calculated, the node activity and node credibility of each authenticated node are calculated, and a node incentive factor is designed to regulate the node reputation point accumulation speed to avoid the emergence of reputation point oligopoly nodes.

6. A lightweight dynamic security-associated double-layer UAV blockchain construction method according to claim 1, characterized in that: In the aforementioned part D, routing nodes are selected based on the proximity sensing clustering algorithm. Routing nodes must be nodes that store global task information. Each routing node communicates with routing nodes of other network clusters and records routing node information of other network clusters. Driven by task requirements, reasonable node number thresholds for network cluster fusion and cluster splitting and topology control message sending intervals are set, and each routing node stores a hash lookup table based on the mapping between drone ID and communication address.

7. A lightweight dynamic security-associated double-layer UAV blockchain construction method according to claim 1, characterized in that: In the aforementioned section E, POA is used as the consensus mechanism for each shard at the execution layer. During the intra-shard consensus process, only the command node elected within the shard is the only node with the authority to package blocks, and other execution nodes are only responsible for verifying blocks. Raft is used as the consensus mechanism at the command layer. The command layer nodes elect temporary leader nodes, which are responsible for verifying whether the proposal meets the requirements for on-chain and broadcasting proposals that meet the requirements. Other command nodes are only responsible for verifying the proposal. Once consensus is reached, the temporary leader node will notify other nodes to accept the proposal and write the proposal block into the command layer blockchain.

8. A lightweight dynamic security-associated double-layer UAV blockchain construction device, characterized by: Includes the following modules: Execution layer blockchain building module: The drones performing the mission are clustered according to their combat mission IDs. Multiple shards corresponding to multiple mission clusters are formed at the execution layer. A dynamic reputation points mechanism based on node consensus behavior is set up, and node incentive factors are set to regulate the node reputation point accumulation speed to avoid the emergence of reputation point oligopoly nodes. The POA consensus mechanism is set up, and an appropriate block generation time interval is set to generate blocks. Command layer blockchain construction module: The command node is selected based on the computing power of the nodes that store global task information within the shard. In subsequent elections, the node with the highest reputation score is selected as the command node. The Raft consensus mechanism is set up, and the same dynamic reputation score mechanism and node incentive factor as the execution layer blockchain are set up. The command node submits the verified blocks in the shard and the reputation update records of the nodes in the shard to the command layer, and each command node reaches consensus and stores them.

Images