A cross-shard collaborative consensus method for drone clusters based on reputation mechanism

Abstract

A cross-shard collaborative consensus method for drone clusters based on a reputation mechanism belongs to the technical field of drone cluster collaboration. The present invention solves the problems of heavy storage burden, high communication overhead, limited scalability and poor fault tolerance in existing systems. By combining state sharding technology and a multi-dimensional reputation evaluation mechanism, and realizing dynamic optimization allocation of tasks based on a task collaboration network and a label propagation mechanism, the system can adaptively adjust the sharding structure according to real-time load conditions, and the sharding strategy based on task correlation can reduce the communication overhead of cross-shard collaboration. The two-stage cross-shard transaction mechanism designed by the method of the present invention combines multiple guarantees such as lock-up period, multiple signatures and proof of failure. Through a lightweight state synchronization mechanism and the PBFT consensus protocol, it not only ensures the consistency and reliability of the data, but also improves the scalability and fault tolerance of the system. The method of the present invention can be applied to the field of drone cluster collaboration.

Description

Technical Field

[0001] The present invention belongs to the technical field of drone cluster collaboration, and specifically relates to a drone cluster cross-shard collaborative consensus method based on a reputation mechanism. Background Art

[0002] The rapid development of drone swarm technology has opened up the possibility of completing complex tasks in areas such as emergency rescue and military patrols. During mission execution, drone swarms require collaboration and data sharing. For example, in emergency rescue scenarios, a swarm composed of multiple drones must collaborate to complete tasks such as search and rescue and material transportation. In military patrol scenarios, drones from different formations need to share reconnaissance data in real time. However, drone swarms face complex security threats. Attackers may impersonate legitimate entities to steal, tamper with, or delete sensor and mission data collected by the swarm, and maliciously mislead the swarm's consensus results. However, existing technologies rely solely on traditional consensus methods to ensure consensus results, resulting in poor fault tolerance. Therefore, improving the data security and processing efficiency of collaborative tasks has become a research priority in the field of drone swarm technology.

[0003] To ensure data security and processing efficiency for collaborative tasks, blockchain sharding technology can be used to divide the entire drone cluster's operating area into multiple network shards to enable parallel processing of collaborative tasks. Blockchain sharding technology can be categorized as network sharding, transaction sharding, and state sharding. Of these three sharding technologies, network sharding is the foundation, providing underlying support for transaction sharding and state sharding.

[0004] Currently, multi-cluster drone networks primarily utilize transaction sharding to achieve collaborative task processing, but this approach presents significant technical bottlenecks. The primary issue is low storage efficiency, as some drone nodes are required to store all block data from the main chain, placing a significant storage burden on resource-constrained drone nodes. Secondly, frequent block data synchronization incurs significant communication overhead, potentially leading to network congestion and delays in collaborative task processing. Furthermore, as the size of drone clusters expands, the storage and communication burden on drone nodes increases exponentially. This scalability issue severely restricts the deployment of large-scale clusters.

[0005] Therefore, there is an urgent need for a solution that can balance collaborative efficiency, reliability and scalability. Summary of the Invention

[0006] The purpose of this invention is to solve the problems of heavy storage burden, high communication overhead, limited scalability and poor fault tolerance in the existing drone cluster cross-shard collaborative system, and propose a drone cluster cross-shard collaborative consensus method based on a reputation mechanism.

[0007] The technical solution adopted by the present invention to solve the above technical problems is: a cross-shard collaborative consensus method for drone clusters based on a reputation mechanism, the method specifically comprising the following steps:

[0008] Step 1: After the i-1 round of consensus ends, if there are drone nodes in the drone cluster that do not meet the requirements, the ground control station sends a backup drone node to replace the drone node that does not meet the requirements, and then executes step 2 for the drone cluster;

[0009] After the i-1th round of consensus is completed, if all drone nodes in the drone cluster meet the requirements, step 2 is directly executed on the drone cluster;

[0010] Step 2: Calculate the comprehensive score of each drone node in the drone cluster that performs the collaborative task in round i. Select m relay nodes based on the comprehensive score of each drone node and the proof-of-work mechanism, and divide the drone nodes in the drone cluster except the relay nodes into K ordinary shards.

[0011] Step 3: The m selected relay nodes collect the pending tasks and create a task status network based on all the pending tasks collected by the m relay nodes. The relay head node divides the pending tasks according to the task status network, generates a task status block based on the task sharding results, and broadcasts the generated task status block to each common shard.

[0012] Step 4: Each common shard receives the task status block generated by the relay head node and updates its own task according to the task status block. That is, each common shard updates the task V that does not belong to itself in the i-th round. k,out The state and Merkle path proof are sent to the target shard, and the task V sent by other common shards is received at the same time. k,in and Merkle path proofs;

[0013] Step 5: For the k-th common shard, the received task status block is used as the genesis block of the k-th common shard in the i-th round. During the task allocation consensus process within the k-th common shard, a common block is generated within the k-th common shard.

[0014] Step 6: Based on the task consensus results within the common shards, the relay nodes within the relay shards perform cross-shard consensus on the common shards to obtain the cross-shard consensus results.

[0015] Furthermore, the specific process of step one is:

[0016] Step 1: After the i-1 round of consensus, determine whether the indicators of each drone node in the drone cluster meet the requirements. Specifically:

[0017] For any drone node l in the drone cluster, if the remaining storage space M of drone node l i,l Greater than or equal to the threshold M low , the remaining computing capacity C of drone node l i,l Greater than or equal to threshold C low , the remaining energy E of drone node l i,l Greater than or equal to the threshold E low , the reputation value R of drone node l i,l Greater than or equal to the threshold R low And the consensus response rate S of drone node l i,l Greater than or equal to the threshold S low , then the drone node l meets the requirements, otherwise the drone node l does not meet the requirements;

[0018] Similarly, after the i-1th round of consensus is completed, each drone node in the drone cluster is judged separately;

[0019] Step 12: After the i-1 round of consensus, if there are drone nodes in the drone cluster that do not meet the requirements, continue to step 13;

[0020] After the i-1th round of consensus is completed, if there are no drone nodes in the drone cluster that do not meet the requirements, no processing is required;

[0021] Step 1-3: The ground control station sends a backup UAV node to each UAV node that does not meet the requirements, uses the backup UAV node to replace the UAV node that does not meet the requirements, and initializes the remaining storage space M of the backup UAV node to M initial , initialize the remaining computing capacity C of the backup drone node to C initial , initialize the remaining energy E of the backup drone node to E initial , initialize the reputation value R of the backup drone node to R initial , initialize the consensus response rate of the backup drone node to 0.

[0022] Furthermore, the specific process of step 2 is as follows:

[0023] Step 2.1: Use a distributed multi-level weighted normalization method to normalize the reputation value of each drone node in the drone cluster that performs the collaborative task in the i-th round:

[0024] (1)

[0025] in, express The corresponding normalized value, represents the reputation value of the UAV node l that performs the collaborative task in round i, Representing a collection The minimum value in Representing a collection The maximum value in represents the set of reputation values ​​of all drone nodes in the drone cluster that performs the collaborative task in round i, α is the weight coefficient, is the normalized reputation value of the UAV node l that performs the collaborative task in the i-1th round, e is the base of the natural logarithm, λ is the time decay factor, and Δt is the time interval between adjacent rounds;

[0026] Then, the Max-Min normalization method is used to normalize the remaining storage space, remaining computing power, remaining energy and consensus response rate of each drone node in the drone cluster that performs the collaborative task in the i-th round.

[0027] Step 2. Calculate the comprehensive score of each drone node in the drone cluster that performs the collaborative task in round i:

[0028] (2)

[0029] in, represents the comprehensive score of the drone node l in the drone cluster that performs the collaborative task in round i, represents the normalized remaining storage space of the drone node l in the drone cluster that performs the collaborative task in the i-th round, represents the normalized remaining computing power of the drone node l in the drone cluster that performs the collaborative task in the i-th round, represents the normalized residual energy of the drone node l in the drone cluster that performs the collaborative task in the i-th round, represents the normalized consensus response rate of drone node l in the drone cluster that performs the collaborative task in round i, 、 、 、 and are indicator weights, and ;

[0030] Step 2 and 3: The drone nodes with a comprehensive score greater than the threshold are used as the initially screened relay nodes, and then the final m relay nodes are selected from the initially screened relay nodes based on the proof-of-work mechanism;

[0031] Step 24: Divide the drone nodes in the drone cluster that performs the collaborative task in the i-th round, except for the final relay node, into K common shards.

[0032] Furthermore, in the drone cluster that performs the collaborative task in the i-th round, the reputation value R of drone node l is i,l for:

[0033] (4)

[0034] in, represents the reputation value of drone node l in round i-1, represents the task completion rate of drone node l before round i, represents the historical contribution of drone node l before round i, 、 and are weight coefficients, and .

[0035] Furthermore, the task completion rate for:

[0036] (5)

[0037] in, represents the number of tasks that drone node l has successfully processed before round i, represents the total number of tasks of drone node l before round i, represents the average mission delay of UAV node l, represents the maximum task delay allowed by the system, μ1 and μ2 are dynamic weight coefficients, and μ1+μ2=1.

[0038] Furthermore, the historical contribution for:

[0039] (6)

[0040] in, , represents the time decay weight of drone node l in round j, , represents the base of natural logarithms, represents the reputation value of drone node l in round j.

[0041] Furthermore, the specific process of step three is:

[0042] Step 3: All m selected relay nodes collect pending tasks, and then aggregate the pending tasks collected by all relay nodes to the currently selected relay head node. The relay head node creates a task state network based on all collected pending tasks. In the task state network, each collected pending task is treated as a node. If there is a collaborative relationship between the tasks represented by two nodes, there is an edge between the two nodes. If there is no collaborative relationship between the tasks represented by two nodes, there is no edge between the two nodes.

[0043] Based on the created task state network, continue to execute step 32 on the relay head node;

[0044] Step 32: The relay head node divides all collected tasks to be processed and obtains the task sharding result on the current relay head node;

[0045] The specific process of step 32 is as follows:

[0046] Step 321: Randomly assign an initial label to each task. The initial label indicates the shard to which the task belongs. Set the maximum number of iterations to τ and the task node update threshold to ρ.

[0047] Step 322: Initialize the number of iterations ;

[0048] Step 323: Calculate the score s(x,k) of migrating task node x to the kth candidate shard:

[0049] (7)

[0050] Among them, e x,y represents the collaborative weight between tasks x and y; f(l(y),k) is the indicator function. When the label of task node y is k, f(l(y),k)=1; when the label of task node y is not k, f(l(y),k)=0; is the adjustment coefficient; W k represents the total edge weight associated with the kth candidate shard in the task state network; h represents the candidate shard with the smallest total edge weight, W h represents the total edge weight of candidate shard h; NB(x) represents the set of neighbor nodes of task node x, k=1,2,⋯,K, task , Represents task x and task The synergy weight between them;

[0051] Select the candidate shards with scores exceeding the threshold from s(x,1), s(x,2), …, s(x,K), and use the candidate shards corresponding to the selected scores as the shards to which the task node x needs to be migrated. Similarly, obtain the shards to which each task node needs to be migrated.

[0052] Step 324: Determine the number of rounds each task node has migrated before the nth round. If the number of rounds a task node has migrated before the nth round reaches the threshold ρ, then the task node will not be migrated. Otherwise, if the number of rounds a task node has migrated before the nth round does not reach the threshold ρ, then the task node will be migrated to the candidate shard corresponding to the selected score.

[0053] Step 325: Determine whether the number of iterations is met ;

[0054] If satisfied , then the task sharding result is obtained;

[0055] If not satisfied , then let , return to step 323;

[0056] Step 3. Each relay node in the relay shard reaches a consensus on the task shard result and verifies the legitimacy of the task shard result.

[0057] If the task sharding result is legal, proceed to steps 3 and 4;

[0058] If the task sharding result is illegal, the next relay head node is selected based on the random backoff algorithm, and the selected next relay head node is used to return to step 32;

[0059] Step 3 and 4: The relay head node generates a task status block based on the task sharding results and broadcasts the generated task status block to each common shard.

[0060] Furthermore, the collaborative weight e between task x and task y x,y The calculation method is:

[0061] (8)

[0062] in, Indicates the number of collaborative tasks between task x and task y; represents the total number of collaborative tasks that task x participates in in the task state network; represents the weight coefficient; Indicates the priority value of task x; Indicates the priority value of task y.

[0063] Furthermore, the specific process of step six is ​​as follows:

[0064] Take the task x that requires consensus across common shards a and task x b The consensus process is as follows:

[0065] Step 6.1. Set the task to x a The ordinary shard where it is located is used as the source shard, and the task x executed in the source shard is a The UAV node is recorded as UAV-a, and the task x b The ordinary shard where it is located is used as the target shard, and the task x is executed in the target shard b The UAV node is recorded as UAV-b; and a common relay node is assigned to the source shard and the target shard;

[0066] For task x a Select task processing lock period H lock , and create raw transaction data :

[0067] (9)

[0068] Among them, transaction data Specifically include all the information in the angle brackets, D raw Represents task x a The original sensor data used is the result of data compression and encryption; D proc Represents task x a The result of denoising the original sensor data used; task info Include , priority level Represents task x a and task x b Collaborative task priority; network state Include , η UAV-a represents the number of task scheduling times of the UAV node UAV-a in the source shard; η relay Indicates the number of task scheduling of the relay drone, t sync Indicates the clock synchronization deviation between the source shard and the target shard; relay indicates the relay node with the smallest load among the relay nodes allocated to the source shard and the target shard; auth proof It is the identity authentication evidence of UAV-a based on zero-knowledge proof; sig data It is the signature of the entire transaction data by the drone node UAV-a;

[0069] The drone node UAV-a in the source shard will Send it to the relay drone, which verifies the legitimacy of the original transaction data;

[0070] If the verification result is illegal, then task x a No task x required b Collaboration, Task x a and task x b The consensus process ends;

[0071] If the verification result is legal, proceed to step 62;

[0072] Step 6.2: Relay drone creates the first phase of cross-shard transaction data :

[0073] (10)

[0074] Type1 indicates the cross-shard transaction type identifier of the first phase, id For cross-shard transaction data Hash value, tx source-digest tx source The hash value, H current Indicates the current block height of the source shard, consensus proof It is the internal consensus proof of the source shard, sig relay Indicates the signature of all data by the relay drone node;

[0075] The relay drone node relay broadcasts the cross-shard transaction data tx1 to the source and target shards:

[0076] If the source shard’s UAV node UAV-a is in H lock If the legal transaction data tx1 is received, then execute step 63;

[0077] If the source shard’s UAV node UAV-a is in H lock If no legal transaction data tx1 is received within 10 days, task x a With task x b Unable to cooperate in round i;

[0078] Step 6.3: The UAV node UAV-a of the source shard will receive the legal transaction data Pack it into a block and mark the packed block height as H source , the source shard provides token incentives to the relay drone node relay, and the token is in the block height range of the source shard [H source , H source +H lock ] is locked;

[0079] Relay drones create second-phase cross-shard transaction data :

[0080] (11)

[0081] Among them, Type2 represents the cross-shard transaction type identifier of the second phase, and the outer data Indicates all data of the inner tuple of the relay drone node signature;

[0082] The relay drone node relay broadcasts the second-phase cross-shard transaction data tx2 to the target shard;

[0083] If the UAV node UAV-b in the target shard exceeds the block height H in the source shard current +H lock / 2 received before , the target shard packages the transaction data tx2 into the block;

[0084] If the target shard’s UAV node UAV-b does not exceed the block height of H in the source shard current +H lock / 2 before receiving tx2, then task x a With task x b Unable to coordinate in round i, the target shard packages the transaction data tx1 of the first phase into the block and constructs a failure proof based on the confirmation and failure reason of tx1 , the failure proof will be provided by the other relay drone nodes assigned to the source and target shards Send to source shard:

[0085] (12)

[0086] Among them, k represents the index value of the target shard, H k Indicates the block height of tx1 in the target shard, chain state Represents the hash value of the current chain state, {P k} is the Merkle tree path, which is used by the source shard to verify whether tx1 is packaged into the block by the target shard. reason Indicates the reason for failure;

[0087] The source shard receives a failure certificate from the target shard After confirming that the target shard has not received the second-phase cross-shard transaction data tx2, when the block height is less than H current +H lock When γ is equal to γ, the source shard packs γ into the block and cancels the token incentive of the relay drone relay.

[0088] The beneficial effects of the present invention are:

[0089] By introducing state sharding technology and combining it with a multi-dimensional reputation assessment mechanism, the proposed TBNLPA algorithm achieves dynamic and optimized allocation of task states through a task collaboration network model and label propagation mechanism, enabling the system to adaptively adjust the sharding structure based on real-time load conditions. This sharding strategy based on task relevance significantly reduces the communication overhead of cross-shard collaboration while also avoiding load imbalances in the task scales of each shard by introducing a balancing factor. Regarding system security, the two-stage cross-shard transaction mechanism designed by the present method combines lock-up periods, multi-signatures, and proof of failure to provide a complete security chain for cross-shard task processing. Through a lightweight state synchronization mechanism and the PBFT consensus protocol, data consistency and reliability are ensured while improving the system's scalability and fault tolerance. In particular, when a new node joins, it only needs to synchronize the latest state block to quickly participate in the consensus process. This design greatly improves the system's dynamic adaptability. The present method fundamentally addresses the problems of heavy storage burden, high communication overhead, limited scalability, and poor fault tolerance found in traditional solutions. BRIEF DESCRIPTION OF THE DRAWINGS

[0090] Figure 1 This is a flow chart of a cross-shard collaborative consensus method for drone clusters based on a reputation mechanism of the present invention;

[0091] Figure 2 Schematic diagram of the consensus process for cross-shard collaboration of drone clusters;

[0092] Figure 3 Schematic diagram of the process of relay drone node machine performing cross-shard collaborative tasks;

[0093] Figure 4 This is a comparison chart of the average throughput of the present invention and the traditional sharding Monoxide solution under different numbers of shards;

[0094] Figure 5 This is a comparison chart of the average cross-shard consensus latency between the present invention and the traditional sharding Monoxide solution under different numbers of shards;

[0095] Figure 6 This is a comparison chart of the average throughput of the present invention and the traditional sharded Monoxide solution under different transaction arrival rates;

[0096] Figure 7 This is a comparison chart of the average cross-shard consensus delay between the present invention and the traditional sharding Monoxide solution under different transaction arrival rates;

[0097] Figure 8This is a comparison chart of the average throughput of the present invention and the traditional sharded Monoxide solution for different block sizes;

[0098] Figure 9 Comparison of the average cross-shard consensus delay between the present invention and the traditional sharded Monoxide solution for different block sizes. DETAILED DESCRIPTION

[0099] Specific implementation method 1: Combination Figure 1 and Figure 2 This embodiment describes a cross-shard collaborative consensus method for drone clusters based on a reputation mechanism, and the method specifically includes the following steps:

[0100] Step 1: After the end of the i-1 round of consensus, if there are drone nodes in the drone cluster that do not meet the requirements, the ground control station sends a backup drone node to replace the drone node that does not meet the requirements, and then executes step 2 on the drone cluster (the drone cluster obtained after the replacement is used as the drone cluster for performing collaborative tasks in the i round);

[0101] Among them, the remaining storage space, remaining computing power, remaining energy, reputation value and consensus response rate of the backup drone node are all initialized values;

[0102] After the i-1th round of consensus, if all drone nodes in the drone cluster meet the requirements, step 2 will be directly executed on the drone cluster (that is, the drone cluster after the i-1th round will be directly used as the drone cluster for performing collaborative tasks in the ith round);

[0103] Step 2: Calculate the comprehensive score of each drone node in the drone cluster that performs the collaborative task in round i. Select m relay nodes based on the comprehensive score of each drone node and the Proof of Work (PoW) mechanism (the specific value of m can be set according to the actual situation). Then divide the drone nodes in the drone cluster except the relay nodes into K ordinary shards. It is only necessary to ensure that the number of drone nodes in each shard is balanced, and the random division is sufficient.

[0104] Step 3: The m selected relay nodes collect all pending tasks (and also collect the tasks and their corresponding priorities), and create a task status network based on all pending tasks collected by the m relay nodes. The relay head node divides the pending tasks according to the task status network, generates a task status block based on the task sharding results, and broadcasts the generated task status block to each common shard.

[0105] Step 4: Each common shard receives the task status block generated by the relay head node and updates its own task according to the task status block. That is, each common shard updates the task V that does not belong to itself in the i-th round. k,out The state and Merkle path proof are sent to the target shard, and the task V sent by other common shards is received at the same time. k,in and Merkle path proofs;

[0106] Step 5. For the k-th common shard (k here does not represent a specific number, and the same intra-shard consensus process is performed for each common shard), the received task status block is used as the genesis block of the k-th common shard in the i-th round. During the task allocation consensus process within the k-th common shard (the consensus process is the process of the common shard assigning tasks to each drone node within the shard), a common block is generated within the k-th common shard (the common block is used to store transaction data stored during the intra-shard consensus process. The new task status block will be added to the local chain. In subsequent rounds, drone nodes newly added to the shard only need to download the latest task status block to synchronize the consensus process of this epoch);

[0107] Step 6: Based on the task consensus results within the common shards, the relay nodes within the relay shards perform cross-shard consensus on the common shards to obtain the cross-shard consensus results.

[0108] Based on the task consensus results within the common shards and the cross-shard consensus results, the drone cluster executes the current round of tasks.

[0109] Specific embodiment 2: This embodiment differs from specific embodiment 1 in that the specific process of step 1 is as follows:

[0110] Step 1: After the i-1 round of consensus, determine whether the indicators of each drone node in the drone cluster meet the requirements. Specifically:

[0111] For any drone node l in the drone cluster, if the remaining storage space M of drone node l i,l Greater than or equal to the threshold M low , the remaining computing capacity C of drone node l i,l Greater than or equal to threshold C low , the remaining energy E of drone node l i,l Greater than or equal to the threshold E low , the reputation value R of drone node l i,l Greater than or equal to the threshold R low And the consensus response rate S of drone node l in the previous round of consensus process i,l Greater than or equal to the threshold S low, then the drone node l meets the requirements, otherwise the drone node l does not meet the requirements (that is, the drone node l is not capable of supporting subsequent work);

[0112] Similarly, after the i-1th round of consensus is completed, each drone node in the drone cluster is judged separately;

[0113] Step 12: After the i-1 round of consensus, if there are drone nodes in the drone cluster that do not meet the requirements, continue to step 13;

[0114] After the i-1th round of consensus is completed, if there are no drone nodes in the drone cluster that do not meet the requirements, no processing is required;

[0115] Step 1-3: The ground control station sends a backup UAV node to each UAV node that does not meet the requirements, and uses the backup UAV node to replace the UAV node that does not meet the requirements (that is, each UAV node that does not meet the requirements is replaced by a backup UAV node), and initializes the remaining storage space M of the backup UAV node to M initial , initialize the remaining computing capacity C of the backup drone node to C initial , initialize the remaining energy E of the backup drone node to E initial , initialize the reputation value R of the backup drone node to R initial , initialize the consensus response rate of the backup drone node to 0.

[0116] Other steps and parameters are the same as those in the first embodiment.

[0117] Specific implementation method three: This implementation method is different from specific implementation methods one or two in that the specific process of step two is as follows:

[0118] Step 2.1: Use a distributed multi-level weighted normalization method to normalize the reputation value of each drone node in the drone cluster that performs the collaborative task in the i-th round:

[0119] (1)

[0120] in, express The corresponding normalized value, represents the reputation value of the UAV node l that performs the collaborative task in round i, Representing a collection The minimum value in Representing a collection The maximum value in represents the set of reputation values ​​of all drone nodes in the drone cluster that performs the collaborative task in round i, α is the weight coefficient, is the normalized reputation value of the drone node l that performs the collaborative task in round i-1 (it should be noted that if the drone node l is a newly added node in round i, then The value of is 0), e is the base of the natural logarithm, λ is the time decay factor, and Δt is the time interval between adjacent rounds;

[0121] Then, the Max-Min normalization method is used to normalize the remaining storage space, remaining computing power, remaining energy and consensus response rate of each drone node in the drone cluster that performs the collaborative task in the i-th round.

[0122] Step 2. Calculate the comprehensive score of each drone node in the drone cluster that performs the collaborative task in round i:

[0123] (2)

[0124] in, represents the comprehensive score of the drone node l in the drone cluster that performs the collaborative task in round i, represents the normalized remaining storage space of the drone node l in the drone cluster that performs the collaborative task in the i-th round, represents the normalized remaining computing power of the drone node l in the drone cluster that performs the collaborative task in the i-th round, represents the normalized residual energy of the drone node l in the drone cluster that performs the collaborative task in the i-th round, represents the normalized consensus response rate of drone node l in the drone cluster that performs the collaborative task in round i (which is an indicator of the communication stability of drone node l), 、 、 、 and are indicator weights, and ;

[0125] Step 2 and 3: The drone nodes with a comprehensive score greater than the threshold (the threshold value can be set according to the actual situation) are used as the preliminary selected relay nodes, and then the final m relay nodes are selected from the preliminary selected relay nodes based on the proof-of-work mechanism;

[0126] The specific process of selecting the final m relay nodes from the initially screened relay nodes is as follows:

[0127] Step 1: Generate a random value through a Verifiable Random Function (VRF).

[0128] Step 2: Each relay node that is initially screened needs to calculate a valid nonce value based on the random number value to determine the node identity. The first m nodes that calculate the nonce value that satisfies the following formula will be selected as the m relay nodes;

[0129] (3)

[0130] Among them, || means connecting multiple input parameters in sequence into a complete string. IP u is the IP address of the drone node u, PK u is the public key of drone node u, and the predefined d value determines the difficulty of the hash puzzle. Represents the proof-of-work mechanism.

[0131] The first m drone nodes u that successfully run as relay nodes will become the relay nodes for this epoch of consensus, and the network formed by these relay nodes will become the relay shard for this epoch of consensus.

[0132] Step 24: Divide the drone nodes in the drone cluster that performs the collaborative task in the i-th round, except for the final relay node, into K common shards (randomly divide the remaining drone nodes into K common shards, and make the number of drone nodes in each common shard balanced).

[0133] Other steps and parameters are the same as those in the first or second embodiment.

[0134] Specific embodiment 4: This embodiment differs from any one of the specific embodiments 1 to 3 in that, in the drone cluster that performs the collaborative task in the i-th round, the reputation value R of the drone node l is i,l for:

[0135] (4)

[0136] in, Represents the reputation value of the drone node l in the i-1th round (this is for the nodes that already exist in the i-1th round. For the nodes newly added in the i-th round, the reputation value R i,l It is obtained through the previous initialization process. The normalization method of the reputation value of the newly added node is ), represents the task completion rate of drone node l before round i, represents the historical contribution of drone node l before round i, 、 and are weight coefficients, and .

[0137] The other steps and parameters are the same as those in the first to third embodiments.

[0138] Specific implementation method 5: This implementation method is different from the specific implementation methods 1 to 4 in that the task completion rate for:

[0139] (5)

[0140] in, represents the number of tasks that drone node l has successfully processed before round i, represents the total number of tasks of drone node l before round i, represents the average mission delay of UAV node l, represents the maximum task delay allowed by the system, μ1 and μ2 are dynamic weight coefficients, and μ1+μ2=1.

[0141] The timeliness weight μ2 is adaptively adjusted based on the characteristics of the tasks in the previous round of consensus, increasing in urgent task scenarios. It should be noted that the tasks assigned to the shard where drone node l resides in round i-1 have ten priority levels: 1, 2, 3, 4, 5, 6, 7, 8, 9, and 10. The priority score represents the scenario judgment value of drone node l in round i-1. The average priority score of all tasks assigned to the shard where drone node l resides in round i-1 is calculated. Average values ​​in the range [1, 3), [3, 5), [5, 7), [7, 9), and [9, 10] correspond to scenarios with increasing task urgency. When the average value of all tasks assigned to the shard where drone node l resides in round i-1 is in the range [1, 3), [3, 5), [5, 7), [7, 9), and [9, 10], the corresponding timeliness weight μ2 values ​​are 0.1, 0.2, 0.4, 0.6, and 0.8, respectively.

[0142] The other steps and parameters are the same as those in the first to fourth embodiments.

[0143] Specific implementation method 6: This implementation method is different from the specific implementation methods 1 to 5 in that the historical contribution is (used to quantify the impact of successive rounds on contribution):

[0144] (6)

[0145] in, , represents the time decay weight of drone node l in round j, , represents the base of natural logarithms, represents the reputation value of drone node l in round j.

[0146] It should be noted that if the drone node l does not exist in the drone cluster from the first round, then the value of j in formula (6) starts from the first round when the drone node l joins. Let the first round when the drone node l joins be j=1. At this time, what needs to be accumulated is the first round when the drone node l joins to the actual i-1th round.

[0147] The other steps and parameters are the same as those in the first to fifth embodiments.

[0148] Specific embodiment 7: This embodiment differs from any one of specific embodiments 1 to 6 in that the specific process of step 3 is as follows:

[0149] Step 3.1: All m selected relay nodes collect pending tasks, and then aggregate the pending tasks collected by all relay nodes to the currently selected relay head node (the consensus algorithm can determine the relay head node this time from the m relay nodes). The relay head node creates a task state network based on all collected pending tasks. In the task state network, each collected pending task is treated as a node. If there is a collaborative relationship between the tasks represented by two nodes, there is an edge between the two nodes. If there is no collaborative relationship between the tasks represented by two nodes, there is no edge between the two nodes.

[0150] Based on the created task state network, continue to execute step 32 on the relay head node;

[0151] Step 32: The relay head node divides all collected tasks to be processed and obtains the task sharding result on the current relay head node;

[0152] The specific process of step 32 is as follows:

[0153] Step 321: Randomly assign an initial label to each task. The initial label indicates the shard to which the task belongs (each task can belong to multiple shards). Set the maximum number of iterations to τ and the task node update threshold to ρ.

[0154] Step 322: Initialize the number of iterations ;

[0155] Step 323: Calculate the score s(x,k) of migrating task node x to the kth candidate shard:

[0156] (7)

[0157] Among them, e x,yrepresents the collaborative weight between tasks x and y; f(l(y),k) is the indicator function. When the label of task node y is k, f(l(y),k)=1; when the label of task node y is not k, f(l(y),k)=0; is the adjustment coefficient (used to balance the ratio of cross-shard collaborative tasks and the load balancing of each common shard, the specific value can be set according to actual conditions); W k represents the total edge weight associated with the k-th candidate shard in the task state network (i.e., the total collaborative weight associated with the k-th candidate shard in the task state network after the initial task labeling); h represents the candidate shard with the smallest total edge weight, W h represents the total edge weight of candidate shard h; NB(x) represents the set of neighbor nodes of task node x (i.e., the set of nodes that have a collaborative relationship with task node x in the task state network), k=1,2,⋯,K, task , Represents task x and task The synergy weight between them;

[0158] By setting a score threshold φ, select the candidate shards with scores exceeding the score threshold from s(x,1), s(x,2), …, s(x,K), and use the candidate shards corresponding to the selected scores as the shards to which the task node x needs to be migrated. Similarly, obtain the shards to which each task node needs to be migrated.

[0159] Step 324: Determine the number of rounds that each task node has migrated before the nth round. If the number of rounds that a task node has migrated before the nth round reaches the threshold ρ, then the task node will not be migrated. Otherwise, if the number of rounds that a task node has migrated before the nth round does not reach the threshold ρ, then the task node will be migrated to the candidate shard corresponding to the selected score (that is, some candidate shards corresponding to the selected score may not contain task x after the end of the n-1th round. Task x needs to be removed from the candidate shards that do not correspond to the selected score, and task x will be migrated to the candidate shards corresponding to the selected score until the maximum number of migration rounds for task x is reached).

[0160] Step 325: Determine whether the number of iterations is met ;

[0161] If satisfied , then the task sharding result is obtained;

[0162] If not satisfied , then let , return to step 323;

[0163] Step 3: Each relay node in the relay shard reaches a consensus on the task sharding result (consensus uses the Practical Byzantine Fault Tolerance (PBFT) algorithm) to verify the legitimacy of the task sharding result.

[0164] If the task sharding result is legal, proceed to steps 3 and 4;

[0165] If the task sharding result is illegal, the next relay head node is selected based on the random backoff algorithm, and the selected next relay head node is used to return to step 32;

[0166] Step 3 and 4: The relay head node generates a task status block based on the task sharding results and broadcasts the generated task status block to each common shard.

[0167] The other steps and parameters are the same as those in the first to sixth embodiments.

[0168] Represents the local connectivity of task node x, aiming to group frequently coordinated tasks into the same shard as much as possible. is a balancing factor used to control the shard size. When the number of tasks in candidate shard k exceeds the normal load of the shard, W k >>min h∈K W h , this balance factor will reduce the score of the shard, prevent the imbalance of task scale of each shard, and achieve the effect of load balancing of each shard.

[0169] Specific embodiment 8: This embodiment differs from any one of specific embodiments 1 to 7 in that the collaborative weight e between task x and task y is x,y The calculation method is:

[0170] (8)

[0171] in, Indicates the number of collaborative tasks between task x and task y; represents the total number of collaborative tasks that task x participates in in the task state network; Represents the weight coefficient, which is used to balance the relative importance of the number of collaborative tasks and task priorities; Indicates the priority value of task x; Indicates the priority value of task y. A smaller priority value indicates that the task can be postponed or is relatively less important.

[0172] The other steps and parameters are the same as those in the first to seventh embodiments.

[0173] Specific implementation method nine: combination Figure 3This embodiment differs from any one of the first to eighth embodiments in that the specific process of step six is ​​as follows:

[0174] Take the task x that requires consensus across common shards a and task x b As an example, the consensus process of task x a and task x b They cannot belong to any common shard. In the previous task sharding process, the present invention has allocated tasks that may require collaboration to the same task shard as much as possible to avoid cross-shard consensus. For tasks that may require collaboration and cannot be allocated to the same task shard, a With task x b , before proceeding to this step of collaborative consensus):

[0175] Step 6.1. Set the task to x a The ordinary shard where it is located is used as the source shard, and the task x executed in the source shard is a The UAV node is recorded as UAV-a, and the task x b The ordinary shard where it is located is used as the target shard, and the task x is executed in the target shard b The UAV node is recorded as UAV-b; and a common relay node is assigned to the source shard and the target shard;

[0176] For task x a Select task processing lock period H lock (represents the a and task x b The consensus process starts with task x a and task x b The consensus process ends, the source shard is allowed to increase the maximum block height), and creates the original transaction data :

[0177] (9)

[0178] Among them, D raw Represents task x a The original sensor data used is the result of data compression and encryption; D proc Represents task x a The result of denoising the original sensor data used; task info Include , priority level Represents task x a and task x b Collaborative task priority; network state Include , η UAV-arepresents the number of task scheduling times of the UAV node UAV-a in the source shard; η relay Indicates the number of task scheduling of the relay drone, t sync Indicates the clock synchronization deviation between the source shard and the target shard; relay indicates the relay node with the smallest load among the relay nodes allocated to the source shard and the target shard; auth proof It is the identity authentication evidence of UAV-a based on zero-knowledge proof; sig data It is the signature of the entire transaction data by the drone node UAV-a;

[0179] The drone node UAV-a in the source shard will Send it to the relay drone, which verifies the legitimacy of the original transaction data;

[0180] If the verification result is illegal, then task x a No task x required b Collaboration, Task x a and task x b The consensus process ends;

[0181] If the verification result is legal, proceed to step 62;

[0182] Step 6.2: Relay drone creates the first phase of cross-shard transaction data :

[0183] (10)

[0184] Type1 indicates the cross-shard transaction type identifier of the first phase, id For cross-shard transaction data Hash value, tx source-digest tx source The hash value, H current Indicates the current block height of the source shard, consensus proof It is the internal consensus proof of the source shard, sig relay Indicates the signature of all data by the relay drone node;

[0185] The relay drone node relay broadcasts the cross-shard transaction data tx1 to the source and target shards:

[0186] If the source shard’s UAV node UAV-a is in H lock If the legal transaction data tx1 is received, then execute step 63;

[0187] If the source shard’s UAV node UAV-a is in H lockIf no legal transaction data tx1 is received within 10 days, task x a With task x b Unable to collaborate in round i (will also collaborate on task x in the next round) a With task x b collaborative consensus);

[0188] Step 6.3: The UAV node UAV-a of the source shard will receive the legal transaction data Pack it into a block and mark the packed block height as H source , the source shard provides token incentives to the relay drone node relay, and the token is in the block height range of the source shard [H source , H source +H lock ] is locked;

[0189] Relay drones create second-phase cross-shard transaction data :

[0190] (11)

[0191] Among them, Type2 represents the cross-shard transaction type identifier of the second phase, and the outer data Indicates all data of the inner tuple of the relay drone node signature;

[0192] The relay drone node relay broadcasts the second-phase cross-shard transaction data tx2 to the target shard;

[0193] If the UAV node UAV-b in the target shard exceeds the block height H in the source shard current +H lock / 2 received before (To determine whether the received data is valid by verifying its validity ), the target shard packages the transaction data tx2 into the block;

[0194] If the target shard’s UAV node UAV-b does not exceed the block height of H in the source shard current +H lock / 2 before receiving tx2, then task x a With task x b Unable to collaborate in round i (will also collaborate on task x in the next round) a With task x b The target shard packages the first phase transaction data tx1 into a block and constructs a failure proof based on the confirmation and failure reason of tx1. , the failure proof will be provided by the other relay drone nodes assigned to the source and target shards Send to source shard:

[0195] (12)

[0196] Among them, k represents the index value of the target shard, H k Indicates the block height of tx1 in the target shard, chain state Represents the hash value of the current chain state, {P k} is the Merkle tree path, which is used by the source shard to verify whether tx1 is packaged into the block by the target shard. reason Indicates the reason for failure;

[0197] The source shard receives a failure certificate from the target shard After confirming that the target shard has not received the second-phase cross-shard transaction data tx2, when the block height is less than H current +H lock When , the source shard packs γ into the block and cancels the token incentive of the relay drone relay (indicating that this time the task x a With task x b If the collaborative consensus fails, the relay drone fails to process this task, which in turn affects the relay drone's reputation value in the next round).

[0198] The other steps and parameters are the same as those in Specific Embodiments 1 to 8.

[0199] The method of this embodiment can be used to achieve cross-shard consensus on the tasks of any two ordinary shards. When a collaborative task may involve the collaborative execution of tasks in two ordinary shards, cross-shard consensus can be achieved on the tasks in these two ordinary shards. When a collaborative task may require the collaborative execution of tasks in more than two ordinary shards, for example, task a in ordinary shard 1, task b in ordinary shard 2, and task c in ordinary shard 3 are a group of tasks that may require collaboration, the method of this embodiment can be used to achieve cross-shard consensus on task a in ordinary shard 1 and task b in ordinary shard 2, cross-shard consensus on task a in ordinary shard 1 and task c in ordinary shard 3, and cross-shard consensus on task b in ordinary shard 2 and task c in ordinary shard 3. When any group of consensus fails, it means that task a in ordinary shard 1, task b in ordinary shard 2, and task c in ordinary shard 3 cannot be collaboratively executed in the current round, and consensus will continue in the next round until the consensus is passed and then collaborative execution is resumed.

[0200] Experimental part

[0201] Figure 4 This is a comparison chart of the impact of the present invention and the traditional sharding Monoxide solution on average throughput at different shard numbers. Figure 5 This is a comparison chart of the impact of the present invention and the traditional sharding Monoxide solution on the average cross-shard consensus delay at different numbers of shards. Figure 6 This is a comparison chart of the impact of the present invention and the traditional sharded Monoxide solution on average throughput at different transaction arrival rates. Figure 7 This is a comparison chart of the impact of the present invention and the traditional sharding Monoxide solution on the average cross-shard consensus delay at different transaction arrival rates. Figure 8 This is a comparison chart of the impact of the present invention and the traditional sharding Monoxide solution on average throughput at different block sizes. Figure 9 The following chart compares the impact of the present invention and the traditional sharded Monoxide solution on average cross-shard consensus latency at different block sizes. The experimental results show that the throughput achieved by the present invention's method is higher than that of the traditional sharded Monoxide solution under different numbers of shards, different transaction arrival rates, and different block sizes, and the average cross-shard consensus latency achieved by the present invention's method is lower than that of the traditional sharded Monoxide solution.

[0202] The above examples are merely illustrative of the calculation model and process of the present invention and are not intended to limit the embodiments of the present invention. Persons skilled in the art will readily appreciate that other variations or modifications based on the above description are possible. This list of embodiments is not exhaustive; however, any obvious variations or modifications derived from the technical solution of the present invention remain within the scope of protection of the present invention.

Claims

1. A cross-shard collaborative consensus method for drone clusters based on a reputation mechanism, characterized by: The method specifically comprises the following steps: Step 1: After the i-1 round of consensus ends, if there are drone nodes in the drone cluster that do not meet the requirements, the ground control station sends a backup drone node to replace the drone node that does not meet the requirements, and then executes step 2 for the drone cluster; After the i-1th round of consensus is completed, if all drone nodes in the drone cluster meet the requirements, step 2 is directly executed on the drone cluster; The specific process of step one is: Step 1: After the i-1 round of consensus, determine whether the indicators of each drone node in the drone cluster meet the requirements. Specifically: For any drone node l in the drone cluster, if the remaining storage space M of drone node l i,l Greater than or equal to the threshold M low , the remaining computing capacity C of drone node l i,l Greater than or equal to threshold C low , the remaining energy E of drone node l i,l Greater than or equal to the threshold E low , the reputation value R of drone node l i,l Greater than or equal to the threshold R low And the consensus response rate S of drone node l i,l Greater than or equal to the threshold S low , then the drone node l meets the requirements, otherwise the drone node l does not meet the requirements; Similarly, after the i-1th round of consensus is completed, each drone node in the drone cluster is judged separately; Step 12: After the i-1 round of consensus, if there are drone nodes in the drone cluster that do not meet the requirements, continue to step 13; After the i-1th round of consensus is completed, if there are no drone nodes in the drone cluster that do not meet the requirements, no processing is required; Step 1-3: The ground control station sends a backup UAV node to each UAV node that does not meet the requirements, uses the backup UAV node to replace the UAV node that does not meet the requirements, and initializes the remaining storage space M of the backup UAV node to M initial , initialize the remaining computing capacity C of the backup drone node to C initial , initialize the remaining energy E of the backup drone node to E initial , initialize the reputation value R of the backup drone node to R initial Initialize the consensus response rate of the backup drone node to 0; Step 2: Calculate the comprehensive score of each drone node in the drone cluster that performs the collaborative task in round i. Select m relay nodes based on the comprehensive score of each drone node and the proof-of-work mechanism, and divide the drone nodes in the drone cluster except the relay nodes into K ordinary shards. Step 3: The m selected relay nodes collect the pending tasks and create a task status network based on all the pending tasks collected by the m relay nodes. The relay head node divides the pending tasks according to the task status network, generates a task status block based on the task sharding results, and broadcasts the generated task status block to each common shard. Step 4: Each common shard receives the task status block generated by the relay head node and updates its own task according to the task status block. That is, each common shard updates the task V that does not belong to itself in the i-th round. k,out The state and Merkle path proof are sent to the target shard, and the task V sent by other common shards is received at the same time. k,in and Merkle path proofs; Step 5: For the k-th common shard, the received task status block is used as the genesis block of the k-th common shard in the i-th round. During the task allocation consensus process within the k-th common shard, a common block is generated within the k-th common shard. Step 6: Based on the task consensus results within the common shards, the relay nodes within the relay shards perform cross-shard consensus on the common shards to obtain the cross-shard consensus results.

2. A cross-shard collaborative consensus method for drone clusters based on a reputation mechanism according to claim 1, characterized in that: The specific process of step 2 is: Step 2.1: Use a distributed multi-level weighted normalization method to normalize the reputation value of each drone node in the drone cluster that performs the collaborative task in the i-th round: (1) in, express The corresponding normalized value, represents the reputation value of the UAV node l that performs the collaborative task in round i, Representing a collection The minimum value in Representing a collection The maximum value in represents the set of reputation values ​​of all drone nodes in the drone cluster that performs the collaborative task in round i, α is the weight coefficient, is the normalized reputation value of the UAV node l that performs the collaborative task in the i-1th round, e is the base of the natural logarithm, λ is the time decay factor, and Δt is the time interval between adjacent rounds; Then, the Max-Min normalization method is used to normalize the remaining storage space, remaining computing power, remaining energy and consensus response rate of each drone node in the drone cluster that performs the collaborative task in the i-th round. Step 2. Calculate the comprehensive score of each drone node in the drone cluster that performs the collaborative task in round i: (2) in, represents the comprehensive score of the drone node l in the drone cluster that performs the collaborative task in round i, represents the normalized remaining storage space of the drone node l in the drone cluster that performs the collaborative task in the i-th round, represents the normalized remaining computing power of the drone node l in the drone cluster that performs the collaborative task in the i-th round, represents the normalized residual energy of the drone node l in the drone cluster that performs the collaborative task in the i-th round, represents the normalized consensus response rate of drone node l in the drone cluster that performs the collaborative task in round i, 、 、 、 and are indicator weights, and ; Step 2 and 3: The drone nodes with a comprehensive score greater than the threshold are used as the initially screened relay nodes, and then the final m relay nodes are selected from the initially screened relay nodes based on the proof-of-work mechanism; Step 24: Divide the drone nodes in the drone cluster that performs the collaborative task in the i-th round, except for the final relay node, into K common shards.

3. The cross-shard collaborative consensus method for drone clusters based on a reputation mechanism according to claim 2 is characterized in that: In the UAV cluster that performs the collaborative task in the i-th round, the reputation value R of UAV node l i,l for: (4) in, represents the reputation value of drone node l in round i-1, represents the task completion rate of drone node l before round i, represents the historical contribution of drone node l before round i, 、 and are weight coefficients, and .

4. The cross-shard collaborative consensus method for drone clusters based on a reputation mechanism according to claim 3 is characterized in that: The task completion rate for: (5) in, represents the number of tasks that drone node l has successfully processed before round i, represents the total number of tasks of drone node l before round i, represents the average mission delay of UAV node l, represents the maximum task delay allowed by the system, μ1 and μ2 are dynamic weight coefficients, and μ1+μ2=1.

5. The cross-shard collaborative consensus method for drone clusters based on a reputation mechanism according to claim 4 is characterized in that: The historical contribution for: (6) in, , represents the time decay weight of drone node l in round j, , represents the base of natural logarithms, represents the reputation value of drone node l in round j.

6. The cross-shard collaborative consensus method for drone clusters based on a reputation mechanism according to claim 5 is characterized in that: The specific process of step three is: Step 3: All m selected relay nodes collect pending tasks, and then aggregate the pending tasks collected by all relay nodes to the currently selected relay head node. The relay head node creates a task state network based on all collected pending tasks. In the task state network, each collected pending task is treated as a node. If there is a collaborative relationship between the tasks represented by two nodes, there is an edge between the two nodes. If there is no collaborative relationship between the tasks represented by two nodes, there is no edge between the two nodes. Based on the created task state network, continue to execute step 32 on the relay head node; Step 32: The relay head node divides all collected tasks to be processed and obtains the task sharding result on the current relay head node; The specific process of step 32 is as follows: Step 321: Randomly assign an initial label to each task. The initial label indicates the shard to which the task belongs. Set the maximum number of iterations to τ and the task node update threshold to ρ. Step 322: Initialize the number of iterations ; Step 323: Calculate the score s(x,k) of migrating task node x to the kth candidate shard: (7) Among them, e x,y represents the collaborative weight between tasks x and y; f(l(y),k) is the indicator function. When the label of task node y is k, f(l(y),k)=1; when the label of task node y is not k, f(l(y),k)=0; is the adjustment coefficient; W k represents the total edge weight associated with the kth candidate shard in the task state network; h represents the candidate shard with the smallest total edge weight, W h represents the total edge weight of candidate shard h; NB(x) represents the set of neighbor nodes of task node x, k=1,2,⋯,K, task , Represents task x and task The synergy weight between them; Select the candidate shards with scores exceeding the threshold from s(x,1), s(x,2), …, s(x,K), and use the candidate shards corresponding to the selected scores as the shards to which the task node x needs to be migrated. Similarly, obtain the shards to which each task node needs to be migrated. Step 324: Determine the number of rounds each task node has migrated before the nth round. If the number of rounds a task node has migrated before the nth round reaches the threshold ρ, then the task node will not be migrated. Otherwise, if the number of rounds a task node has migrated before the nth round does not reach the threshold ρ, then the task node will be migrated to the candidate shard corresponding to the selected score. Step 325: Determine whether the number of iterations is met ; If satisfied , then the task sharding result is obtained; If not satisfied , then let , return to step 323; Step 3. Each relay node in the relay shard reaches a consensus on the task shard result and verifies the legitimacy of the task shard result. If the task sharding result is legal, proceed to steps 3 and 4; If the task sharding result is illegal, the next relay head node is selected based on the random backoff algorithm, and the selected next relay head node is used to return to step 32; Step 3 and 4: The relay head node generates a task status block based on the task sharding results and broadcasts the generated task status block to each common shard.

7. The cross-shard collaborative consensus method for drone clusters based on a reputation mechanism according to claim 6 is characterized in that: The collaborative weight e between task x and task y x,y The calculation method is: (8) in, Indicates the number of collaborative tasks between task x and task y; represents the total number of collaborative tasks that task x participates in in the task state network; represents the weight coefficient; Indicates the priority value of task x; Indicates the priority value of task y.

8. The cross-shard collaborative consensus method for drone clusters based on a reputation mechanism according to claim 7 is characterized in that: The specific process of step six is ​​as follows: Take the task x that requires consensus across common shards a and task x b The consensus process is as follows: Step 6.

1. Set the task to x a The ordinary shard where it is located is used as the source shard, and the task x executed in the source shard is a The UAV node is recorded as UAV-a, and the task x b The ordinary shard where it is located is used as the target shard, and the task x is executed in the target shard b The UAV node is recorded as UAV-b; and a common relay node is assigned to the source shard and the target shard; For task x a Select task processing lock period H lock , and create raw transaction data : (9) Among them, D raw Represents task x a The result of data compression and encryption of the original sensor data used; D proc Represents task x a The result of denoising the original sensor data used; task info Include , priority level Represents task x a and task x b Collaborative task priority; network state Include , η UAV-a represents the number of task scheduling times of the UAV node UAV-a in the source shard; η relay Indicates the number of task scheduling of the relay drone, t sync Indicates the clock synchronization deviation between the source shard and the target shard; relay indicates the relay node with the smallest load among the relay nodes allocated to the source shard and the target shard; auth proof It is the identity authentication evidence of UAV-a based on zero-knowledge proof; sig data It is the signature of the entire transaction data by the drone node UAV-a; The drone node UAV-a in the source shard will Send it to the relay drone, which verifies the legitimacy of the original transaction data; If the verification result is illegal, then task x a No task x required b Collaboration, Task x a and task x b The consensus process ends; If the verification result is legal, proceed to step 62; Step 6.2: Relay drone creates the first phase of cross-shard transaction data : (10) Type1 indicates the cross-shard transaction type identifier of the first phase, id For cross-shard transaction data Hash value, tx source-digest tx source The hash value, H current Indicates the current block height of the source shard, consensus proof It is the internal consensus proof of the source shard, sig relay Indicates the signature of all data by the relay drone node; The relay drone node relay broadcasts the cross-shard transaction data tx1 to the source and target shards: If the source shard’s UAV node UAV-a is in H lock If the legal transaction data tx1 is received, then execute step 63; If the source shard’s UAV node UAV-a is in H lock If no legal transaction data tx1 is received within 10 days, task x a With task x b Unable to cooperate in round i; Step 6.3: The UAV node UAV-a of the source shard will receive the legal transaction data Pack it into a block and mark the packed block height as H source , the source shard provides token incentives to the relay drone node relay, and the token is in the block height range of the source shard [H source , H source +H lock ] is locked; Relay drones create second-phase cross-shard transaction data : (11) Among them, Type2 represents the cross-shard transaction type identifier of the second phase, and the outer data Indicates all data of the inner tuple of the relay drone node signature; The relay drone node relay broadcasts the second-phase cross-shard transaction data tx2 to the target shard; If the UAV node UAV-b in the target shard exceeds the block height H in the source shard current +H lock / 2 received before , the target shard packages the transaction data tx2 into the block; If the target shard’s UAV node UAV-b does not exceed the block height of H in the source shard current +H lock / 2 before receiving tx2, then task x a With task x b Unable to coordinate in round i, the target shard packages the transaction data tx1 of the first phase into the block and constructs a failure proof based on the confirmation and failure reason of tx1 , the failure proof will be provided by the other relay drone nodes assigned to the source and target shards Send to source shard: (12) Among them, k represents the index value of the target shard, H k Indicates the block height of tx1 in the target shard, chain state Represents the hash value of the current chain state, {P k } is the Merkle tree path, which is used by the source shard to verify whether tx1 is packaged into the block by the target shard. reason Indicates the reason for failure; The source shard receives a failure certificate from the target shard After confirming that the target shard has not received the second-phase cross-shard transaction data tx2, when the block height is less than H current +H lock When γ is equal to γ, the source shard packs γ into the block and cancels the token incentive of the relay drone relay.

Images