Supervision and command system for manned and unmanned collaborative operation based on trusted block chain

Abstract

The application relates to a manned and unmanned collaborative combat supervision and command system based on a trusted blockchain. The system comprises a chain network construction and anchoring module, which builds a command chain composed of manned units and a task chain composed of unmanned units, completes task fragmentation and cross-chain anchoring, and generates a corresponding mapping table and a public key list; a committee election and threshold signature module, which dynamically elects a threshold signature committee according to a supervision window, generates threshold signature parameters and stores them on a chain; and a key action supervision and audit evidence storage module, which initiates supervision in advance of key actions of the unmanned units, generates a threshold signature after verification by the committee, and records the execution of the signed instructions of the unmanned units on a chain and synchronously packages the supervision records for storage on the command chain. The system further improves the trustworthiness of manned and unmanned collaborative combat, the compliance of key action execution and the cross-chain collaborative security by means of building a double-layer heterogeneous chain network and cross-chain anchoring, dynamically electing a threshold signature committee and implementing key action pre-supervision.

Description

Technical Field

[0001] This invention belongs to the field of computer technology, and in particular relates to a manned and unmanned collaborative combat monitoring and command system based on trusted blockchain. Background Technology

[0002] With the rapid development of intelligent military technology, manned and unmanned collaborative warfare has become the core form of modern warfare. Leveraging the mobility advantages of unmanned combat systems and the decision-making advantages of manned units, it significantly improves combat response speed and mission execution efficiency. Blockchain technology, with its decentralized, immutable, and traceable characteristics, can be applied to areas such as military communication security, combat data storage, and command authority resilience. It serves as a key technological support for solving trust issues in collaborative warfare under untrusted environments.

[0003] However, current manned and unmanned collaborative combat systems still face numerous technical bottlenecks. On the one hand, command and mission chains often employ traditional centralized or single-chain architectures, creating barriers to cross-chain data exchange. The anchoring relationship between command nodes and unmanned unit nodes lacks reliable assurance, hindering the effective implementation of mission fragmentation management and cross-chain supervision in collaborative operations. On the other hand, when unmanned units execute high-risk critical actions such as weapon launches and airspace entry, there is a lack of dynamic and reliable real-time monitoring mechanisms. Existing signature schemes are ill-suited to the dynamic changes in the combat environment, making them vulnerable to malicious node attacks or command tampering. Furthermore, the execution process and accountability for critical actions lack fully auditable evidence support. In addition, blockchain applications in the military suffer from fragmented cross-chain interactions, insufficient dynamic node management, and poor adaptability of monitoring processes to operational rhythms, making it difficult to meet the collaborative command needs of highly confrontational and dynamic battlefield environments. Summary of the Invention

[0004] Therefore, it is necessary to provide a manned and unmanned collaborative combat supervision and command system based on trusted blockchain to address the above-mentioned technical issues. This system aims to improve the credibility and transparency of cross-chain collaboration and enhance the dynamic security and anti-attack capabilities of key action supervision.

[0005] Firstly, this application provides a manned and unmanned collaborative combat monitoring and command system based on a trusted blockchain, including:

[0006] The Chain Network Construction and Anchoring Module is used to construct a command chain composed of manned unit nodes and a mission chain composed of unmanned unit nodes. According to the combat mission, the unmanned unit nodes are divided into mission segments, the anchoring relationship between the command chain and the mission chain is established, and a segment mapping table containing member node information and supervisor node information of each mission segment, a public key list of command chain nodes, and a cross-chain anchoring table used to record the anchoring relationship between the mission chain and the command chain are generated.

[0007] The committee election and threshold signature module is used to divide the command chain into consecutive monitoring windows at preset time intervals. Within each monitoring window, a random seed is generated based on the hash value of the last block of the command chain in the previous monitoring window and the number of monitored key actions on the task chain. Based on the random seed, a verifiable random function is used to elect the threshold signature committee for the current window from the nodes of the command chain. The threshold signature parameter set for the current window is generated through a distributed key generation protocol, and the status information of the threshold signature committee is written into the command chain for notarization. The threshold signature parameter set includes the private key share corresponding to each member of the threshold signature committee.

[0008] The key action monitoring and auditing module is used to acquire preset key actions. Before the unmanned unit node in the task chain executes the key action, it generates a monitoring request containing a random number derived from the random seed of the current window and a hash of the action content. The monitoring request is sent to the threshold signature committee of the current window. After the threshold signature committee verifies the validity of the monitoring request, it generates multiple signature shares using the corresponding private key share, aggregates the signature shares to generate a threshold signature, and returns the threshold signature to the unmanned unit node. It then packages the monitoring records in the current window into a monitoring audit block and sends the monitoring audit block to the command chain for evidence storage. The unmanned unit node is used to attach the threshold signature to the action instruction, obtain and execute the executable instruction package, and record the executable instruction package in the directed acyclic graph ledger of the task chain.

[0009] In one embodiment, the system further includes:

[0010] The reputation assessment and dynamic admission module is used to calculate the reputation value of each unmanned unit node and the manned unit node on the command chain based on the reputation smart contract deployed on the command chain and the transaction data in the directed acyclic graph ledger of the task chain. It generates a reputation status table, performs dynamic admission and exit management for unmanned unit nodes based on reputation thresholds, and writes node status change events to the command chain.

[0011] In one embodiment, the system further includes:

[0012] The health monitoring and command transfer module is used to monitor nodes on the command chain in real time based on a health monitoring smart contract deployed on the command chain. When the monitoring results meet the preset trigger conditions, the command transfer process is initiated. Candidate nodes for command transfer are selected based on the reputation status table. The candidate nodes are elected by voting based on the weight of the reputation value of the nodes on the command chain other than the manned unit node that triggered the command transfer. The elected node is used to receive the handover data packet, synchronize the state, and officially take over the command. After the transfer is completed, the command change result is written to the command chain, and the nodes of each task shard update the shard mapping table based on the command change result. The candidate nodes can be manned unit nodes or unmanned unit nodes.

[0013] In one embodiment, the committee election and threshold signature module includes a committee election subunit, which is used for:

[0014] At the start of each supervision window, obtain the last block hash value of the command chain corresponding to the previous supervision window, as well as the number of key actions that have been supervised on the task chain within the previous supervision window; perform a hash operation on the concatenated string of the block hash value and the number of key actions to generate a random seed for the current window.

[0015] Each manned unit node in the command chain executes a verifiable random function using a random seed and its own private key to calculate its own VRF hash value and VRF proof; the VRF hash value and VRF proof are then broadcast within the command chain.

[0016] By using the manned unit nodes of each command chain, the VRF proof received from each manned unit node is verified according to the corresponding public key in the command chain node public key list, and the VRF verification result is obtained.

[0017] The VRF hash value corresponding to the VRF proof that passes the VRF verification is used as the election score of the corresponding human unit node; the top K nodes with the highest election scores are selected as the threshold signature committee members of the current window.

[0018] In one embodiment, the key action monitoring and audit evidence storage module includes a key action monitoring subunit, which is used for:

[0019] Before the unmanned unit node in the task chain executes the key action, a supervision request data packet is generated. The supervision request data packet contains the action identifier, node identifier, timestamp, current window sequence number, task chain identifier, action content hash value, and random number. The action content hash value is obtained by hashing the action instruction generated based on the key action, and the random number is generated using the random seed of the current window and the unmanned unit node's own node private key.

[0020] The unmanned unit node sends the supervision request data packet to the members of the threshold signature committee of the current window;

[0021] When a member of the threshold signature committee receives a supervision request data packet, they verify the supervision request data packet according to the preset verification rules and obtain the verification result.

[0022] If the verification result is successful, the members of the threshold signature committee calculate the hash value of the supervision request data packet, sign the hash value using the private key share corresponding to each member, generate a signature share, and broadcast the signature share among the members of the threshold signature committee.

[0023] Once the members of the threshold signature committee have obtained a preset threshold number of signature shares, they execute a signature aggregation algorithm to aggregate the signature shares into a threshold signature and generate a signature certificate. The signature certificate contains the identifier of the aggregated public key used and a list of identifiers of the members who participated in the signing.

[0024] In one embodiment, the reputation assessment and dynamic admission module includes a reputation assessment subunit, which is used for:

[0025] The current period's transaction data of each unmanned unit node and the manned unit node on the command chain are read from the directed acyclic graph ledger of the task chain through the reputation smart contract.

[0026] Based on transaction data, corresponding task completion quality scores are calculated for each unmanned unit node and each manned unit node. The task completion quality score is obtained by calculating the weighted sum of target recognition accuracy, hit evaluation coefficient and response delay.

[0027] Cross-validate the data reported by multiple unmanned and manned unit nodes in the same task segment for the same area and time period, calculate the average similarity between the data, and obtain the data consistency score corresponding to each unmanned unit node and each manned unit node based on the average similarity.

[0028] Based on transaction data, the system verifies whether each key action in the transaction record contains valid supervision credentials according to preset supervision rules, obtains the key actions that have passed verification, and calculates the supervision compliance score for each unmanned unit node and each manned unit node based on the key actions that have passed verification and the total number of key actions in the transaction record.

[0029] The reputation value of each unmanned unit node and each manned unit node for the previous period is obtained respectively. Based on the reputation value of the previous period, a new reputation value is calculated by combining the task completion quality score, data consistency score and supervision compliance score of the current period. Among them, the reputation value of the previous period is the preset initial reputation value when calculating for the first time.

[0030] Based on the node identifiers corresponding to each unmanned unit node and each manned unit node, and combined with the reputation value of the previous period and the new reputation value, a reputation status table is generated.

[0031] In one embodiment, the health monitoring and command transfer module includes a health monitoring subunit, which is used for:

[0032] The health monitoring smart contract retrieves the proof-of-survival transactions published by manned unit nodes on the command chain in each monitoring window. The proof-of-survival transaction includes node identifier, window number, timestamp, location coordinates, self-check status code, and signature; and counts the number of consecutive windows in which each manned unit node has not sent a proof-of-survival transaction.

[0033] Through health monitoring smart contracts, the task completion rate and data consistency score of each person unit node in the task chain are calculated from the directed acyclic graph ledger, the supervision response delay is extracted from the supervision audit block, and threat alarm events sent by the external threat detection system are received.

[0034] Based on the task completion rate, data consistency score, supervision response delay and threat alarm events, determine whether to initiate command migration and obtain the judgment result. When the judgment result is to initiate command migration, a migration trigger event is generated. The migration trigger event includes the original command node identifier, trigger condition type, trigger time and evidence data hash.

[0035] After the migration trigger event occurs, the election smart contract deployed on the command chain selects initial candidate nodes from manned and unmanned unit nodes based on the reputation status table.

[0036] Calculate the capability matching degree between the initial candidate nodes and the task fragments to be taken over, and select the top N initial candidate nodes with the highest capability matching degree to generate a candidate node list; the capability matching degree is obtained by weighted calculation of computing capability matching degree, communication quality matching degree and task experience matching degree.

[0037] Secondly, this application also provides a method for monitoring and commanding manned and unmanned collaborative operations based on a trusted blockchain, including:

[0038] Construct a command chain composed of manned unit nodes and a mission chain composed of unmanned unit nodes. Divide the unmanned unit nodes into mission segments according to the combat mission, establish the anchoring relationship between the command chain and the mission chain, and generate a segment mapping table containing member node information and supervisor node information of each mission segment, a public key list of command chain nodes, and a cross-chain anchoring table for recording the anchoring relationship between the mission chain and the command chain.

[0039] The command chain divides continuous monitoring windows according to preset time intervals. Within each monitoring window, a random seed is generated based on the hash value of the last block of the command chain in the previous monitoring window and the number of monitored key actions on the task chain. Based on the random seed, a threshold signature committee for the current window is elected from the nodes of the command chain using a verifiable random function. A threshold signature parameter set for the current window is generated using a distributed key generation protocol, and the status information of the threshold signature committee is written into the command chain for evidence storage. The threshold signature parameter set includes the private key share corresponding to each member of the threshold signature committee.

[0040] Before the unmanned unit node in the task chain executes the preset key actions, a supervision request is generated, which includes a random number derived from the random seed of the current window and a hash of the action content. The supervision request is sent to the threshold signature committee of the current window. After the threshold signature committee verifies the validity of the supervision request, multiple signature shares are generated using the corresponding private key shares. The signature shares are aggregated to generate a threshold signature, which is returned to the unmanned unit node. The supervision records in the current window are packaged into a supervision audit block, which is sent to the command chain for evidence storage. The unmanned unit node is used to attach the threshold signature to the action instruction, obtain and execute the executable instruction package, and record the executable instruction package in the directed acyclic graph ledger of the task chain.

[0041] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the first aspect.

[0042] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps in the first aspect.

[0043] The aforementioned manned and unmanned collaborative combat monitoring and command system based on trusted blockchain firstly addresses the cross-chain data interoperability barriers of traditional centralized architectures by constructing a dual-chain architecture of command chain and mission chain, establishing cross-chain anchoring relationships, and generating a mapping table. This enhances the credibility and transparency of manned and unmanned unit collaborative operations. Secondly, it solves the problem of static monitoring mechanisms being unable to adapt to dynamic battlefield changes by using a monitoring window mechanism and a verifiable random function to dynamically elect a threshold signature committee, combined with a distributed key generation protocol to implement threshold signatures. This improves the security and attack resistance of key action monitoring. Finally, by storing threshold signature approval and monitoring audit blocks on the blockchain, combined with the mission chain ledger recording executable instruction packages, it enhances the auditability and accountability of combat actions. Attached Figure Description

[0044] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0045] Figure 1 A schematic diagram of a manned and unmanned collaborative combat monitoring and command system based on a trusted blockchain, provided as an exemplary embodiment of the present invention;

[0046] Figure 2 A flowchart of a method for generating a candidate node list is provided as an exemplary embodiment of the present invention;

[0047] Figure 3 A flowchart of a manned and unmanned collaborative combat supervision and command method based on trusted blockchain is provided as an exemplary embodiment of the present invention. Detailed Implementation

[0048] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0049] In one embodiment, such as Figure 1 As shown, a manned and unmanned collaborative combat monitoring and command system 100 based on a trusted blockchain is provided. This embodiment illustrates the system's application to a terminal. It is understood that this system can also be applied to a server, or to a system including both a terminal and a server, and is implemented through interaction between the terminal and the server. In this embodiment, the system includes:

[0050] The chain network construction and anchoring module 101 is used to construct a command chain composed of manned unit nodes and a mission chain composed of unmanned unit nodes. According to the combat mission, the unmanned unit nodes are divided into mission segments, the anchoring relationship between the command chain and the mission chain is established, and a segment mapping table containing member node information and supervisor node information of each mission segment, a public key list of command chain nodes, and a cross-chain anchoring table used to record the anchoring relationship between the mission chain and the command chain are generated.

[0051] Specifically, manned and unmanned unit nodes differ fundamentally in their functional positioning, computing power, and security requirements. Furthermore, the command chain must undertake core functions such as decision-making, supervision, and command authority management, demanding high security and computing power. In contrast, the task chain needs to handle lightweight operations such as task execution and data reporting for unmanned units, making it suitable for distributed deployment and low-computing-power scenarios. Therefore, a two-layer heterogeneous chain network architecture can be adopted to construct the command chain and task chain separately, achieving functional layering and optimized resource allocation, avoiding performance bottlenecks and security risks associated with a single-chain architecture. Subsequently, task sharding can be performed based on the core attributes of the combat mission. Combat missions often exhibit regional, typological, and priority characteristics; therefore, dividing task shards according to dimensions such as combat area, mission type (e.g., reconnaissance, strike, collaborative support), and mission priority can achieve refined management of unmanned units, reduce data interaction redundancy between nodes of different mission types, and improve mission execution response speed. For example, sharding rules can be preset through smart contracts, matching the unmanned unit node's identifier, capability parameters, and mission adaptability with the sharding rules to automatically complete sharding and update the sharding mapping table.

[0052] Furthermore, the anchoring relationship between the command chain and the task chain is crucial for trusted cross-chain collaboration. Cross-chain smart contracts can bind the addresses of human-controlled unit nodes with supervisory authority in the command chain to the unique identifiers of their corresponding task shards, forming a cross-chain anchoring table and storing it on the chain to ensure that the anchoring relationship is immutable. The generated list of public keys for command chain nodes provides a foundation for subsequent secure operations such as encrypted communication and signature verification, avoiding security risks caused by chaotic public key management.

[0053] The committee election and threshold signature module 102 is used to divide the command chain into consecutive supervision windows according to a preset time interval. Within each supervision window, a random seed is generated based on the hash value of the last block of the command chain in the previous supervision window and the number of key actions that have been supervised on the task chain. Based on the random seed, a threshold signature committee for the current window is elected from the nodes of the command chain using a verifiable random function. A threshold signature parameter set for the current window is generated through a distributed key generation protocol, and the status information of the threshold signature committee is written into the command chain for evidence storage. The threshold signature parameter set includes the private key share corresponding to each member of the threshold signature committee.

[0054] Specifically, the committee election and threshold signature module 102 is the core of achieving dynamic and trustworthy supervision. The dynamic division of the supervision window is crucial for adapting to the pace of combat. In the battlefield, the mission status, node connection status, and combat environment of unmanned units are constantly changing. Therefore, the division and switching of the supervision window can be automatically triggered by a smart contract with a preset time interval, such as 5-10 minutes based on the average execution cycle of combat missions. This fixed time interval allows the supervision mechanism to match the execution cycle of combat missions, ensuring that supervision neither lags behind mission execution nor consumes excessive resources due to excessive frequency. The random seed can be generated using dual-dimensional data fusion, and the hash value of the last block of the command chain in the previous supervision window possesses the immutable characteristics of blockchain, ensuring the security of the random seed. The number of key actions monitored on the mission chain reflects the dynamic situation of mission execution, enabling the random seed to adapt to different scenarios and avoiding the predictability risk of random seeds caused by single-dimensional data. Therefore, we can first extract the block hash value of the previous window from the command chain ledger, count the number of key actions that have been supervised and passed in the previous window from the directed acyclic graph ledger of the task chain, convert the two into strings of a unified format and concatenate them, and calculate the random seed using the SHA-256 hash algorithm to ensure the randomness and unpredictability of the seed.

[0055] In illustrative terms, the election of the threshold signature committee employs a Verifiable Random Function (VRF), which ensures the randomness and verifiability of the election process. Subsequently, each member node in the command chain executes the VRF algorithm using its private key and a random seed, generating a corresponding VRF hash value and verification proof. This is broadcast through the command chain, allowing other nodes to verify the validity of the verification proof using the command chain's public key list, eliminating malicious nodes that might forge election results. The nodes with the highest hash values ​​are ultimately selected to form the committee. The number of members can be set according to Byzantine fault tolerance requirements (e.g., 3f+1, where f is the tolerable number of malicious nodes), ensuring that even if some members are attacked, the signing operation can still be completed normally. The threshold signature parameter set can be generated using a distributed key generation protocol. Committee members exchange key share information through a secure communication channel, jointly calculating the aggregate public key. Private key shares are held separately by each member, ensuring that no single node possesses the complete private key, thus effectively preventing the risk of private key leakage. This parameter set, once generated, can be written to the command chain for record-keeping, ensuring the traceability of subsequent signing operations. This module achieves the trustworthiness of the supervisory body and the anti-attack capability of the signature mechanism through dynamic election and distributed key management, providing secure and dynamic technical support for the supervision of key actions.

[0056] The key action supervision and audit evidence storage module 103 is used to obtain preset key actions. Before the unmanned unit node in the task chain executes the key action, it generates a supervision request containing a random number derived from the random seed of the current window and the hash of the action content. The supervision request is sent to the threshold signature committee of the current window. After the threshold signature committee verifies the validity of the supervision request, it generates multiple signature shares using the corresponding private key share, aggregates the signature shares to generate a threshold signature, and returns the threshold signature to the unmanned unit node. It packages the supervision records in the current window into a supervision audit block and sends the supervision audit block to the command chain for evidence storage. The unmanned unit node is used to attach the threshold signature to the action instruction, obtain and execute the executable instruction package, and record the executable instruction package in the directed acyclic graph ledger of the task chain.

[0057] Specifically, the critical action supervision and audit evidence storage module 103 focuses on the whole-process reliable control of high-risk critical actions, which can solve the problems of weak supervision and untraceable responsibility in traditional collaborative operations. Critical actions performed by unmanned units, such as weapon launches and entry into restricted airspace, have high-risk attributes. Once tampered with or maliciously executed, they will cause serious combat consequences. Therefore, a supervision process can be triggered before the action is executed, and the legality and integrity of the action command can be verified through a threshold signature mechanism. Among them, the generation of supervision requests includes dual security protection. The random number derived from the random seed can be used to verify the identity and legality of the unmanned unit, preventing malicious nodes from forging supervision requests. The action content hash can be obtained by hashing the action command, which can quickly verify whether the command has been tampered with during transmission. For example, the unmanned unit node can use the current window random seed and its own private key to derive random numbers through a pseudo-random number generation algorithm. The SHA-256 algorithm is used to calculate the action content hash of the command text corresponding to the critical action, and it is combined with the action identifier, node identifier, timestamp and other information to form a supervision request data packet.

[0058] In illustrative terms, the threshold signature aggregation process ensures the credibility of the oversight results. Upon receiving an oversight request, committee members can first perform validity checks according to preset rules, such as window sequence number consistency, task chain identifier legality, and node permission matching. After successful checks, they use their own private key share to sign the hash value of the oversight request data packet, generating a signature share which is then broadcast internally within the committee. When the collected valid signature shares reach the threshold value, a complete threshold signature can be generated using the threshold signature aggregation algorithm, ensuring that no single node can unilaterally determine the oversight result and preventing malicious nodes from manipulating the oversight process. Furthermore, the evidence storage design of the oversight audit block enables accountability. After each oversight window ends, the committee can organize and package all relevant records within that window, including oversight requests, verification results, signature shares, and threshold signatures, to generate an oversight audit block and send it to the command chain for on-chain evidence storage. Combined with the executable instruction packages recorded in the task chain, a complete chain is formed, ensuring that the execution process of key actions is traceable and accountability is delineable. The unmanned unit node attaches the threshold signature to the action instruction to form an executable instruction package, which not only ensures the legality of the instruction, but also provides a basis for subsequent auditing. Furthermore, after the instruction is executed, it is written into the task chain ledger, which can realize the immutable storage of action execution data.

[0059] The aforementioned system first addresses the issue of fragmented cross-chain interaction by constructing a two-layer heterogeneous blockchain network and establishing anchoring relationships, generating multi-dimensional mappings and public key lists. This enables precise collaborative management of manned and unmanned units, enhancing the credibility of blockchain network collaboration. Secondly, it generates random seeds based on dynamic monitoring windows and two-dimensional data, elects a committee through verifiable random functions, and generates threshold signature parameter sets. This adapts to dynamic battlefield changes, avoids single-point-of-failure risks, and enhances the signature mechanism's resistance to attacks. Finally, through pre-monitoring of key actions, threshold signature aggregation, and full-process auditing and evidence storage, it ensures the compliance of high-risk actions, achieves traceability of the operation process, and prevents command tampering and malicious execution risks. By independently storing dual-chain data and performing cross-chain verification, this system can adapt to highly adversarial battlefield environments, further improving the security and reliability of collaborative operations.

[0060] In one embodiment, the committee election and threshold signature module includes a committee election subunit, which is used for:

[0061] At the start of each supervision window, obtain the last block hash value of the command chain corresponding to the previous supervision window, as well as the number of key actions that have been supervised on the task chain within the previous supervision window; perform a hash operation on the concatenated string of the block hash value and the number of key actions to generate a random seed for the current window.

[0062] Each manned unit node in the command chain executes a verifiable random function using a random seed and its own private key to calculate its own VRF hash value and VRF proof; the VRF hash value and VRF proof are then broadcast within the command chain.

[0063] By using the manned unit nodes of each command chain, the VRF proof received from each manned unit node is verified according to the corresponding public key in the command chain node public key list, and the VRF verification result is obtained.

[0064] The VRF hash value corresponding to the VRF proof that passes the VRF verification is used as the election score of the corresponding human unit node; the top K nodes with the highest election scores are selected as the threshold signature committee members of the current window.

[0065] Specifically, at the start of each monitoring window, a random seed can be generated. This random seed forms the basis for the randomness of subsequent committee elections and must simultaneously satisfy security and scenario adaptability. Illustratively, the hash value of the last block in the command chain of the previous monitoring window (a fixed-length hexadecimal string) and the number of key actions (converted to string format) can be concatenated in the order of block hash value + key action number to form a uniformly formatted raw string. This raw string is then input into a hash function for computation to generate the random seed for the current window. The hash function used must possess collision resistance and one-wayness to ensure that the original data cannot be deduced from the seed, thus guaranteeing the unpredictability of the seed. For example, its core computational logic can be represented as follows: ), where Seed is the generated random seed, For hash functions (such as SHA-256), Here, || is the hash value of the last block in the previous window's command chain, and || is the string concatenation operator. This represents the number of supervised critical actions in the previous window's task chain.

[0066] After the random seed is generated, each manned unit node in the command chain can execute a verifiable random function and broadcast the result. This verifiable random function guarantees the randomness of the output and provides publicly verifiable proof, preventing opaque operations during the election process. For example, each manned unit node, as an election participant, can call a locally pre-set VRF algorithm module, inputting its private key and the generated random seed. The algorithm calculates two sets of core data: the VRF hash value and the VRF proof. The VRF hash value is used for subsequent election sorting; its generation depends entirely on the input private key and seed, possessing randomness and uniqueness. The VRF proof is used to verify the legitimacy of the hash value to other nodes, ensuring it is not forged by a node. Illustratively, the core logic of the VRF operation can be represented as follows: , For VRF hash value, For VRF verification proof, For node-based private keys A verifiable random function is used, with Seed being the previously generated random seed. After the calculation is completed, each manned unit node packages its node identifier, VRF hash value, and VRF proof into a broadcast data packet through the distributed P2P network of the command chain, and broadcasts it to all other manned unit nodes in the command chain, ensuring that each node can obtain complete election-related data, providing a basis for subsequent verification steps.

[0067] After receiving data packets broadcast by all other nodes, each manned unit node in the command chain initiates a VRF proof validity verification process to further exclude malicious nodes from forging VRF results and ensure the fairness of the election process. This verification process relies on the command chain node public key list, which is generated and stored on the chain by the chain network construction and anchoring module. This list contains the public key information of all legitimate manned unit nodes in the command chain, ensuring that the legitimate public key of the corresponding node can be obtained during the verification process. For example, for each received broadcast data packet, each node can first extract the node identifier, query the public key Pk corresponding to that node identifier from the command chain node public key list, and then call its local VRF verification algorithm module, inputting the public key. Then, the local VRF verification algorithm module is called, and the public key is input. Random seed (Seed), VRF hash value in the data packet With VRF proof The algorithm is used to determine whether the VRF result is valid. The core logic of the verification algorithm is as follows: , To verify the results, This is the VRF verification function. If the verification result is true, it means that the VRF hash value was generated by the corresponding node using its own private key and a legitimate seed, and is valid. If the verification result is false, the data packet is determined to be forged by a malicious node, and its contained VRF hash value and proof are directly discarded, and it will not participate in the subsequent election and sorting.

[0068] Specifically, after verifying all VRF proofs, the selection phase for the threshold signature committee members can begin. For example, the election score of each legitimate node can be determined first. For nodes that pass verification, their corresponding VRF hash value is directly used as their election score. Due to the randomness of VRF hash values, this score objectively reflects the randomness of node elections, avoiding human intervention. Subsequently, all manned unit nodes with valid election scores are sorted according to their election scores. The sorting rule adopts the natural ordering of hash values ​​(such as sorting by lexicographical order of hexadecimal strings or numerical size) to ensure the uniqueness and repeatability of the sorting results. Finally, the top K nodes with the highest scores in the sorting results are selected to form the threshold signature committee for the current monitoring window. The value of K can be set according to the Byzantine fault tolerance principle, meaning it can tolerate a certain number of malicious nodes in the committee without affecting the overall function. For example, the tolerable number of malicious nodes f can be determined based on factors such as the total number of manned unit nodes in the command chain and the security level of the battlefield environment. Therefore, K = 3f + 1 is set to ensure that even if f nodes are malicious, the remaining 2f + 1 legitimate nodes can still complete the threshold signature operation normally. Once the committee members are determined, the list of committee members can be broadcast through the command chain, and the list, along with the corresponding VRF verification results, election scores, and other data, can be written into the command chain for evidence storage. This ensures that the election process is traceable and provides a basis for the legality of subsequent threshold signature operations.

[0069] In one embodiment, the key action monitoring and audit evidence storage module includes a key action monitoring subunit, which is used for:

[0070] Before the unmanned unit node in the task chain executes the key action, a supervision request data packet is generated. The supervision request data packet contains the action identifier, node identifier, timestamp, current window sequence number, task chain identifier, action content hash value, and random number. The action content hash value is obtained by hashing the action instruction generated based on the key action, and the random number is generated using the random seed of the current window and the unmanned unit node's own node private key.

[0071] The unmanned unit node sends the supervision request data packet to the members of the threshold signature committee of the current window;

[0072] When a member of the threshold signature committee receives a supervision request data packet, they verify the supervision request data packet according to the preset verification rules and obtain the verification result.

[0073] If the verification result is successful, the members of the threshold signature committee calculate the hash value of the supervision request data packet, sign the hash value using the private key share corresponding to each member, generate a signature share, and broadcast the signature share among the members of the threshold signature committee.

[0074] Once the members of the threshold signature committee have obtained a preset threshold number of signature shares, they execute a signature aggregation algorithm to aggregate the signature shares into a threshold signature and generate a signature certificate. The signature certificate contains the identifier of the aggregated public key used and a list of identifiers of the members who participated in the signing.

[0075] Specifically, before the unmanned unit node in the task chain executes a critical action, a supervision request data packet can be generated first. This data packet can achieve dual security guarantees of identity legitimacy and content integrity through multi-field collaboration. Illustratively, the action identifier in this data packet is a unique identification code for the critical action, generated by the system's preset critical action classification system, used to clearly distinguish different types of high-risk operations, ensuring that the supervision request accurately corresponds to the specific action. The node identifier is a unique identification code for the unmanned unit node in the task chain, consistent with the member node information in the sharding mapping table, used to trace the request initiator. The timestamp can use UTC time format to record the precise moment the data packet was generated, used to prevent replay attacks. The current window sequence number is consistent with the supervision window during the committee election phase, ensuring that the request is within the valid supervision period. The task chain identifier is a unique code for the corresponding task chain, matched with the task chain information in the cross-chain anchoring table, used to define the chain network affiliation of the request. The hash value of the action content is crucial for ensuring the integrity of the instruction. For example, an unmanned unit node can first generate a structured action instruction containing core content such as action type, execution parameters, and target information based on the key actions to be executed. Then, this instruction is input into a collision-resistant, one-way hash function (such as SHA-256) to obtain a fixed-length action content hash value through hash operation. The operation logic can be represented as follows: , For the hash value of the action content, For hash functions, This refers to action instructions generated based on key actions. During random number generation, unmanned unit nodes can call their local pseudo-random number generation module, inputting the random seed of the current window and their own node private key. The logic for generating unique and unpredictable random numbers through non-linear computation can be represented as follows: Rand is the generated random number. For unmanned unit node private keys The pseudo-random function, Seed, is the random seed for the current window. This calculation ensures that only nodes that legitimately hold the private key can generate random numbers that match the seed, preventing malicious nodes from forging requests.

[0076] Specifically, after the supervision request data packet is generated, the unmanned unit node can send the data packet to all members of the threshold signature committee of the current window through a distributed P2P network that connects the task chain and the command chain. The transmission process can use an encrypted channel such as TLS to ensure that the data packet is not tampered with or stolen during transit. Furthermore, the data packet can be appended with the unmanned unit node's digital signature (generated based on its own private key) before transmission, allowing committee members to initially verify the legitimacy of the request source. In addition, a full transmission mode can be used to ensure that each committee member receives the complete request data, providing a consistent data foundation for subsequent distributed verification and signature operations, and avoiding delays in the supervision process due to missing data from some members.

[0077] Specifically, after receiving a monitoring request data packet, members of the threshold signature committee can initiate a step-by-step verification process based on preset verification rules to ensure that only legitimate requests can proceed to the subsequent signing stage. For example, they can first verify the current window number. Members extract the currently valid window number from locally stored monitoring window management information and compare it with the window number in the data packet. If they do not match, the request is deemed expired and rejected. This process can prevent malicious nodes from reusing historical request data to launch attacks. Secondly, they can verify the task chain identifier. For instance, members can query a list of legitimate task chain identifiers from the cross-chain anchoring table generated during the chain network construction phase and verify whether the task chain identifier in the data packet is in the list, ensuring that the request originates from an anchored legitimate task chain and preventing cross-chain forged requests. Furthermore, they can verify the legitimacy of the random number. Members extract the node identifier from the data packet and query the corresponding node public key from the command chain node public key list. Call the random number verification algorithm, and input the random seed (Seed) of the current window and the node's public key. The random number Rand in the data packet is used to verify whether it was generated by the corresponding node's private key and seed. If the verification fails, the request is determined to be initiated by an illegitimate node. Next, the node identifier can be verified. Members query the sharding mapping table to confirm whether the node identifier belongs to the member node of the corresponding task shard and has the authority to execute the current critical action (the sharding mapping table records the node's action permission range), preventing unauthorized nodes from initiating high-risk action requests. Finally, the format of the action content hash value can be verified to ensure its length and character type conform to the preset hash function output specifications, eliminating forged hash values. If all the above verification items pass, a verification success result is generated. If any verification item fails, a verification failure result is generated, and the reason for the failure is fed back to the initiating node along with the data packet and recorded in a temporary log for later traceability.

[0078] Specifically, if the verification result is successful, each member of the threshold signature committee can generate a corresponding signature share and complete the internal broadcast. For example, a member performs a total hash operation on the received supervision request data packet, using the same hash function as the action content hash, combining all fields in the data packet to form the original data string, and obtaining a condensed data packet hash value through hash operation. This operation reduces the amount of data to be signed while ensuring that the overall content of the data packet has not been tampered with. Subsequently, a member can call the local threshold signature algorithm module, using their own private key share (from the threshold signature parameter set) to perform a signature operation on the data packet hash value, generating the corresponding signature share. The core logic of the signature operation can be represented as follows: , The signature share generated for the i-th member, For threshold signature algorithms, such as threshold signature variants based on elliptic curve cryptography, For the private key share of the i-th member, To monitor the hash value of the request data packet, after the signature share is generated, members broadcast it through a dedicated P2P communication channel within the committee. The broadcast data packet contains their own member identifier, signature share, and data packet hash value, ensuring that other members can clearly identify the source of the signature share and the corresponding data object, thus avoiding the problem of share mismatch with data.

[0079] Specifically, after members of the threshold signature committee receive signature shares broadcast by other members, they can first verify the validity of each received signature share. This verification process can be performed using the member's corresponding public key (derived from the aggregated public key in the threshold signature parameter set). If the signature share can be verified using the public key, it is considered a valid share; otherwise, it is discarded. When the number of valid signature shares collected by a member reaches a preset threshold, the signature aggregation process can be initiated. The preset threshold can be set according to the Byzantine fault tolerance principle to ensure that even if some members are malicious nodes, a valid threshold signature can still be aggregated. Furthermore, the relationship between the threshold and the total number of committee members must satisfy "threshold > 2 / 3 of the total number of members." The signature aggregation algorithm, based on the secret sharing principle, combines multiple valid signature shares to generate a unique, complete threshold signature. This aggregation process is irreversible, and the aggregated signature has the same legal effect as a complete private key signature, but no single member can generate this signature alone. Furthermore, members can generate corresponding signature proofs, which include an aggregated public key identifier and a list of participating member identifiers. The aggregated public key identifier is used by subsequent unmanned unit nodes to verify the legality of the threshold signature, while the list of participating member identifiers can be used to trace the entity that generated the threshold signature, ensuring that the signing process is auditable and traceable. After the threshold signature and signature proof are generated, committee members can send them back to the unmanned unit node that initiated the oversight request through a designated channel, providing legitimate credentials for the execution of key actions.

[0080] In one embodiment, the system may further include a reputation assessment and dynamic admission module, which is used to calculate the reputation value of each unmanned unit node and the manned unit node on the command chain based on the reputation smart contract deployed on the command chain and the transaction data in the directed acyclic graph ledger of the task chain, generate a reputation status table, perform dynamic admission and exit management on the unmanned unit nodes based on the reputation threshold, and write the node status change event to the command chain.

[0081] Specifically, the credit assessment and dynamic access module may include a credit assessment sub-unit, which can be used for:

[0082] The current period's transaction data of each unmanned unit node and the manned unit node on the command chain are read from the directed acyclic graph ledger of the task chain through the reputation smart contract.

[0083] Based on transaction data, corresponding task completion quality scores are calculated for each unmanned unit node and each manned unit node. The task completion quality score is obtained by calculating the weighted sum of target recognition accuracy, hit evaluation coefficient and response delay.

[0084] Cross-validate the data reported by multiple unmanned and manned unit nodes in the same task segment for the same area and time period, calculate the average similarity between the data, and obtain the data consistency score corresponding to each unmanned unit node and each manned unit node based on the average similarity.

[0085] Based on transaction data, the system verifies whether each key action in the transaction record contains valid supervision credentials according to preset supervision rules, obtains the key actions that have passed verification, and calculates the supervision compliance score for each unmanned unit node and each manned unit node based on the key actions that have passed verification and the total number of key actions in the transaction record.

[0086] The reputation value of each unmanned unit node and each manned unit node for the previous period is obtained respectively. Based on the reputation value of the previous period, a new reputation value is calculated by combining the task completion quality score, data consistency score and supervision compliance score of the current period. Among them, the reputation value of the previous period is the preset initial reputation value when calculating for the first time.

[0087] Based on the node identifiers corresponding to each unmanned unit node and each manned unit node, and combined with the reputation value of the previous period and the new reputation value, a reputation status table is generated.

[0088] Specifically, the reputation smart contract can proactively invoke the read interface of the task chain's directed acyclic graph ledger according to a preset reputation assessment cycle to extract all transaction data of each unmanned unit node and manned unit node on the command chain within the current cycle. This cycle can be dynamically adjusted based on the intensity of combat missions. Subsequently, only valid records related to node task execution, key actions, and data reporting can be extracted, including but not limited to execution instructions for key actions, supervision credentials, data reporting content, and mission completion feedback results, excluding invalid network interactions, state synchronization, and other irrelevant data to ensure the relevance of the assessment data. Because the task chain ledger is immutable, the read transaction data accurately reflects the actual behavior of the nodes, providing a fundamental guarantee for the objectivity of the reputation assessment.

[0089] Based on the filtered transaction data of the current period, a task completion quality score can be calculated for each node. This score is based on the actual effect of the node's task execution and is quantitatively evaluated through a weighted fusion of multiple indicators. Specifically, target identification accuracy, applicable to nodes performing reconnaissance and target location tasks, is calculated as the ratio of the number of targets correctly identified by the node in the current period to the total number of identified targets. The criteria for correct identification are that the target's identifier, location, and attributes are consistent with the target baseline information issued by the command chain. The hit evaluation coefficient, applicable to nodes performing strike and destruction tasks, is calculated as the ratio of the number of targets actually hit to the planned number of targets hit. Hit determination is confirmed through cross-validation using battlefield situation feedback data and target damage assessment data. Response latency, applicable to nodes performing coordination and emergency response tasks, is calculated as the ratio of the time interval between receiving the task instruction and initiating the first effective response to the preset standard response time. The standard response time is preset based on the task type and battlefield environment complexity and stored in a smart contract. The weighted sum calculation logic of the three indicators can be expressed as follows: , To score the quality of task completion, The weights are preset, and the sum of the weights is 1. They can be dynamically adjusted according to task priority. For target recognition accuracy, This is the hit rating coefficient. The response delay ratio is calculated by subtracting this ratio from 1. A faster response time results in a higher score, consistent with the logic of other metrics.

[0090] Specifically, to prevent nodes from reporting false data, cross-validation can be performed on similar data (such as reconnaissance data and environmental monitoring data) reported by multiple nodes within the same task segment (including all unmanned unit nodes and manned unit nodes with data reporting capabilities) in the same area and at the same time. This cross-validation process can employ similarity comparison algorithms. For example, the data reported by each node is first converted into structured data in a unified format. Based on the core feature dimensions of the data, such as location, attributes, and numerical values, the similarity between any two nodes' reported data is calculated. This similarity can be calculated using algorithms such as cosine similarity or Euclidean distance to ensure the objectivity of the comparison results. Subsequently, the average similarity of each node's data with the data reported by all other nodes is calculated to obtain the node's data consistency score. A higher average similarity score indicates a higher data consistency score, meaning the data reported by the node is closer to the group consensus and has higher credibility. Conversely, a lower average similarity score suggests the data may be false or erroneous, and the score will decrease accordingly.

[0091] Specifically, based on the current period's transaction data, each key action's corresponding transaction record can be verified one by one according to preset supervision rules to ensure it contains valid supervision credentials. Specific verification content may include: whether the threshold signature in the transaction record can be verified by the aggregated public key of the corresponding supervision window (the aggregated public key is extracted from the threshold signature parameter set stored in the command chain), ensuring the signature is generated by the legitimate threshold signature committee; whether the timestamp in the supervision credential is within the valid time range of the corresponding supervision window to prevent the reuse of expired credentials; and whether the hash value of the action content matches the hash value of the action instruction in the transaction record, ensuring the supervision object matches the actual executed action. If all verification items are satisfied, the key action is considered verified successfully; otherwise, it is considered verified unsuccessfully. By statistically analyzing the number of key actions verified successfully by the node within the current period to the total number of key actions executed by the node, the ratio of these two values ​​is the node's supervision compliance score. This score directly reflects the compliance level of the node's execution of high-risk actions; a higher ratio indicates more standardized node behavior and a greater ability to resist malicious operation risks.

[0092] Furthermore, the reputation value of each node in the previous cycle can be extracted from the historical reputation status table of the command chain. If a node is participating in the reputation assessment for the first time (e.g., a newly added node), the reputation value of the previous cycle can use a preset initial reputation value. The initial reputation value can be determined based on the node's initial qualifications, such as hardware performance, preset permissions, and historical service records, to ensure the rationality of the initial assessment. The calculation logic for the new reputation value can be expressed as follows:

[0093]

[0094] in, For the new reputation value, The reputation value from the previous period. Historical reputation weight, ranging from 0 to 1, is used to adjust the degree to which historical performance affects current reputation. , , The preset weights for task completion quality score, data consistency score, and supervision compliance score are 1. These weights can be adjusted according to the priority of the battlefield's requirements for the capabilities of each node in each dimension. To score data consistency, To monitor compliance scores, if a node exhibits clear malicious behavior (such as reported data that differs significantly from the group consensus and is verified to be false, or key actions lacking valid oversight evidence and reasonable explanation), additional malicious behavior penalty points will be deducted from the above calculation results. The penalty points are preset based on the severity of the malicious behavior and stored in the smart contract.

[0095] Specifically, based on the unique identifiers of each node, a complete reputation status table can be generated by combining the reputation value from the previous period, the newly calculated reputation value, and the reputation change trend of the node in the current period, such as the magnitude of reputation value increase or decrease. This reputation status table includes the node identifier, the reputation value from the previous period, the current reputation value, and can also record the node's historical reputation sequence (reputation values ​​arranged in order of evaluation period). This sequence can intuitively reflect the long-term trend of node reputation changes, providing a more comprehensive decision-making basis for subsequent dynamic access management. After the reputation status table is generated, it can be written into the command chain by a reputation smart contract for notarization, ensuring that the reputation data is immutable and publicly searchable. It can also trigger the chain network notification mechanism to synchronize the status table update information to relevant nodes and management modules, providing data support for the execution of dynamic access and exit management. As an illustration, the core basis for dynamic access and exit management is the dual reputation threshold preset in the smart contract, namely the access threshold and the exit threshold. This dual reputation threshold can be dynamically adjusted according to the battlefield security level, mission sensitivity, and the overall reputation level of the node group. For example, a higher access threshold corresponds to a high-sensitivity strike mission, while a lower threshold can be appropriately reduced for a low-risk reconnaissance mission. It can also be confirmed by the on-chain voting mechanism and then written into the smart contract for solidification.

[0096] Specifically, for newly added unmanned unit nodes, an admission application can be submitted first. The smart contract can extract its initial reputation value and historical reputation record, compare them with the admission threshold, and if the initial reputation value reaches or exceeds the admission threshold, it is allowed to join the specified task shard. The member node information of the task shard in the shard mapping table is updated synchronously, and the corresponding task execution permission and data reporting permission are assigned to the node. If the threshold is not reached, admission is rejected and the reason for failure is reported. For existing unmanned unit nodes that have joined the task sharding, the smart contract can periodically (synchronized with the reputation assessment cycle) compare their current reputation value with the exit threshold. If the current reputation value is lower than the exit threshold and fails to rise above it for two consecutive assessment cycles, it is determined to be a low-reputation node, triggering the exit process. This involves first revoking the node's critical action execution permissions and data reporting permissions to prevent it from affecting task execution security; secondly, deleting the node's member information from the sharding mapping table to sever its anchoring association with the task chain and command chain; and finally, generating a node state change event. This event includes the node identifier, state change type (exit), reputation value triggered by the change, change timestamp, and smart contract verification signature to ensure the change process is traceable. If, after exiting, the node raises its reputation value above the admission threshold in subsequent cycles through compliant behavior such as participating in low-risk auxiliary tasks or providing effective data support, it can resubmit its admission application. The smart contract will re-examine it according to the new node admission process, and upon approval, restore its sharding membership and corresponding permissions. Once a node state change event is generated, it can be packaged into an on-chain transaction by a smart contract. After being verified by the consensus of the command chain nodes, it is stored on the chain and simultaneously synchronized to the sharding management module and the permission control module to ensure that all modules of the chain network have a consistent understanding of the node state and avoid permission conflicts or management disconnect.

[0097] In one embodiment, the system may further include a health monitoring and command transfer module, which is used to monitor nodes on the command chain in real time based on a health monitoring smart contract deployed on the command chain. When the monitoring results meet preset trigger conditions, the command transfer process is initiated. Candidate nodes for command transfer are selected based on a reputation status table. The candidate nodes are elected by voting based on the weights corresponding to the reputation values ​​of nodes on the command chain other than the manned unit node that triggered the command transfer. The elected node is used to receive the handover data packet, synchronize the state, and formally take over the command. After the transfer is completed, the command change result is written to the command chain, and the nodes of each task shard update the shard mapping table based on the command change result. The candidate nodes are manned unit nodes or unmanned unit nodes.

[0098] In one embodiment, the health monitoring and command transfer module may include a health monitoring subunit, such as... Figure 2 As shown, this health monitoring subunit can generate a list of candidate nodes through the following steps:

[0099] S201: Obtain the proof-of-survival transactions issued by manned unit nodes on the command chain in each supervision window through the health monitoring smart contract. The proof-of-survival transactions include node identifier, window number, timestamp, location coordinates, self-check status code and signature; count the number of consecutive windows in which each manned unit node has not sent a proof-of-survival transaction;

[0100] S202: Through the health monitoring smart contract, calculate the task completion rate and data consistency score of each person unit node supervising the task shard from the directed acyclic graph ledger of the task chain, extract the supervision response delay from the supervision audit block, and receive threat alarm events sent by the external threat detection system;

[0101] S203: Based on the task completion rate, data consistency score, supervision response delay and threat alarm events, determine whether to initiate command migration and obtain the judgment result. When the judgment result is to initiate command migration, generate a migration trigger event. The migration trigger event includes the original command node identifier, trigger condition type, trigger time and evidence data hash.

[0102] S204: After the migration trigger event occurs, the election smart contract deployed on the command chain selects initial candidate nodes from manned and unmanned unit nodes according to the reputation status table.

[0103] S205: Calculate the capability matching degree between the initial candidate nodes and the task fragments to be taken over, and select the top N initial candidate nodes with the highest capability matching degree to generate a candidate node list; the capability matching degree is obtained by weighted calculation of the computing capability matching degree, communication quality matching degree and task experience matching degree.

[0104] Specifically, the health monitoring smart contract can be synchronized with the supervision window cycle. Within a fixed time period of each supervision window, such as a preset duration after the window begins, it reads all survival proof transactions published by manned unit nodes on the command chain. Survival proof transactions are the proactive reporting carriers of a node's own health status. The node identifier is used to identify the reporting entity and corresponds one-to-one with the identifiers in the command chain node public key list. The window sequence number ensures that the transaction matches the current supervision cycle, avoiding interference from historical transactions. The timestamp records the transaction generation time, used to verify the timeliness of the reporting. The location coordinates reflect the node's physical deployment or network access location, providing a basis for determining whether the node is in a normal operational area. The self-check status code is generated by the node's hardware self-check module and includes operational information of core components such as computing power status, communication module status, and encryption module status, including normal operation codes, fault codes, and degraded operation codes, directly reflecting the node's hardware health level. The signature, generated by the node's private key, is used to verify the authenticity of the transaction and prevent malicious nodes from forging survival proofs. After receiving a proof-of-survival transaction, the smart contract can first verify the signature validity using the node's public key to exclude forged transactions. Then, it extracts the node identifier and window number from the valid transaction and updates the node's proof-of-survival record. For nodes that fail to report proof-of-survival transactions within the specified time period, the smart contract can mark them as non-reporting and accumulate the number of consecutive windows without sending proof-of-survival transactions. That is, if the current window does not report, the number is incremented by 1 based on the historical cumulative number; if the current window reports, the number is reset to 0. This ensures accurate statistics of consecutive non-reporting states and provides basic data for subsequent migration trigger judgments.

[0105] Specifically, the health monitoring smart contract can also synchronously acquire task supervision performance data and external environmental threat data of the command chain nodes through multi-source data interfaces. The task completion rate can be calculated based on transaction records in the directed acyclic graph ledger of the task chain. That is, the smart contract can extract the total number of tasks and the actual number of completed tasks in the task shards supervised by each manned unit node. The criterion for task completion is that the task transaction record contains valid execution feedback, such as confirmation of target achievement. The calculation logic is: Task completion rate = Actual number of completed tasks / Total number of tasks. This indicator directly reflects the node's supervision and scheduling execution capabilities. The calculation logic for the data consistency score is the same as that in the reputation assessment in the above embodiment, but it can focus on the node's data analysis capabilities as a supervisory subject. That is, the smart contract can extract the data reported by all unmanned unit nodes within the node's supervision range, cross-compare it with the verification results of other supervisory nodes within the same task shard, and statistically analyze the proportion of consistent data to form the data consistency score of the manned unit node. The higher the score, the stronger the node's ability to identify data from its subordinate unmanned units. The monitoring response latency originates from the monitoring audit block stored in the command chain. The smart contract can extract the time interval between the node receiving the monitoring request and generating the signature share from the audit block, and take the average of the monitoring request response latency within the current period as the final monitoring response latency. This indicator reflects the node's real-time processing efficiency; the lower the latency, the better the node's computing power and response capability. In addition, the smart contract can also receive threat alarm events sent by the external threat detection system through a preset secure communication interface. The alarm events contain core information such as threat type (e.g., network attack, physical attack, electromagnetic interference), threat level (gradient coding according to severity), affected node identifier, and threat occurrence time, providing direct evidence for determining whether a node is in a dangerous environment. Furthermore, the communication between the external threat detection system and the smart contract can use an encrypted channel to ensure that alarm events are not tampered with or stolen.

[0106] Specifically, the health monitoring smart contract can integrate four types of data—task completion rate, data consistency score, monitoring response latency, and threat alarm events—to construct a migration trigger determination model, enabling accurate judgment of migration needs. For example, for task completion rate, the smart contract can preset a minimum acceptable threshold. If the node's task completion rate in the current period is lower than this threshold and fails to rise above it for two consecutive periods, it indicates insufficient monitoring and scheduling capabilities of the node, triggering a migration determination. For data consistency score, a reliability threshold can be preset. If the score is lower than the threshold, it indicates that the node has weak ability to identify data from subordinate unmanned units, which can easily lead to incorrect decisions, triggering a migration determination. For monitoring response latency, a maximum tolerance threshold can be preset. If the latency exceeds this threshold and fails to improve for several consecutive periods, it indicates a decline in the node's computing power or communication capabilities, making it unable to meet real-time monitoring requirements, triggering a migration determination. For threat alarm events, if a high-level threat alarm is received targeting the node, and the alarm event clearly indicates that the node is no longer able to perform its command functions normally, a migration determination is directly triggered. All of the above judgment conditions can be executed based on preset parameters in the smart contract. These parameters can be dynamically adjusted through an on-chain voting mechanism according to the type of combat mission and the battlefield security level, ensuring the adaptability of the judgment logic. When any judgment condition is met, the judgment result can be "Initiate command transfer". The smart contract immediately generates a transfer trigger event. The original command node identifier clearly identifies the node whose command needs to be transferred, the trigger condition type indicates the specific reason for the transfer, the trigger time records the precise time when the judgment result is generated, and the evidence data hash can be obtained by hashing all trigger basis data to ensure the traceability and immutability of the trigger basis.

[0107] Specifically, after the migration trigger event is generated, the health monitoring smart contract can send a trigger notification to the election smart contract. The election smart contract immediately calls the reputation status table stored on the command chain to start the candidate node screening process. For example, it can first extract the current reputation value of all unmanned and manned unit nodes in the reputation status table and compare it with the preset candidate node reputation threshold in the smart contract. Only nodes whose reputation value reaches or exceeds the threshold are retained. This threshold is set higher than the admission threshold for ordinary nodes to ensure that candidate nodes have good behavioral compliance and reliability. Secondly, for manned unit nodes, their proof-of-life records are additionally verified to exclude nodes that have not continuously reported proof-of-life or whose self-check status codes are abnormal, ensuring that the node hardware and network status are normal. For unmanned unit nodes, their permission level in the sharding mapping table can also be verified. Only high-level unmanned unit nodes with the potential for command authority, such as nodes that have been specially authorized, have sufficient computing power, and have performed well in executing complex tasks in the past, are retained, while ordinary task nodes with low permissions and low computing power are excluded. During the screening process, information such as the identifier of all nodes that meet the criteria, their current reputation value, node type (occupied / unoccupied), and permission level can be compiled into an initial list of candidate nodes, providing a candidate pool for subsequent capability matching assessment.

[0108] Furthermore, the election smart contract can quantify and rank each node in the initial list of candidate nodes by calculating its capability matching degree with the task shard to be taken over, based on three core dimensions: computing capability matching degree, communication quality matching degree, and task experience matching degree. The computing power matching degree is obtained by comparing the node's peak computing power and concurrent processing capacity with the computing power requirements of the task shard to be taken over. The computing power requirements of the task shard to be taken over are preset based on factors such as the number of unmanned unit nodes in the shard, the frequency of key action execution, and the amount of data processing. The calculation logic is: Computing power matching degree = actual computing power of the node / computing power requirements of the task shard to be taken over. The closer the ratio is to 1, the better the computing power adaptability. The communication quality matching degree can be obtained based on the node's historical network communication data (extracted from the communication logs stored in the command chain), including average network latency, packet loss rate, and cross-chain communication success rate. After standardization, the average value is taken. The higher the average value, the stronger the communication stability. The task experience matching degree can be obtained based on the node's historical records of executing similar task shards. The historical execution count, task completion success rate, and fault-free runtime are statistically analyzed and quantified by weighting according to preset weights. The higher the score, the richer the node's command experience for similar tasks. The capability matching degree can be obtained by weighted summing of the dimensional values ​​of the above dimensions. The smart contract can sort candidate nodes from high to low based on their comprehensive score of capability matching, and select the top N nodes to generate a candidate node list. The value of N can be determined by following the Byzantine fault tolerance principle, combined with the importance of the task fragment to be taken over and the security level of the battlefield environment, to ensure that the candidate node list has sufficient redundancy and fault tolerance, providing a candidate pool for subsequent voting.

[0109] Furthermore, during the voting and election phase, all legitimately owned nodes in the command chain, except for the original node that triggered the command transfer, can act as voting entities. Each voting node's voting weight is positively correlated with its current reputation value; the higher the reputation value, the greater the weight, ensuring that highly trustworthy nodes have a stronger decision-making influence. The voting process can be publicly executed through an election smart contract. Each voting node selects a single node from the candidate node list to vote for. The smart contract calculates the cumulative score of all valid votes according to their corresponding weights, and the node with the highest score is elected. After the elected node is determined, the original command node can package its command authority credentials, real-time status data of the task shards to be taken over, and node association configuration information into a handover data packet via an encrypted channel and transmit it to the elected node. Upon receiving the packet, the elected node completes data verification and status synchronization, officially taking over the command function. After the migration is complete, the election smart contract can generate the command change result, including core information such as the elected node identifier, the original command node identifier, the change timestamp, and the smart contract verification signature, and package it into an on-chain transaction for storage in the command chain. The nodes of each task shard can obtain the change results through the chain network synchronization mechanism, automatically update the command node association information of the corresponding task shard in the shard mapping table, ensure the coordination consistency of all nodes with the new command node, and avoid permission conflicts or scheduling disconnection.

[0110] Based on the same inventive concept, this application also provides a method for implementing the aforementioned manned and unmanned collaborative combat supervision and command system based on trusted blockchain. The solution provided by this method is similar to the implementation scheme described in the above system. Therefore, the specific limitations of one or more embodiments of the manned and unmanned collaborative combat supervision and command method based on trusted blockchain provided below can be found in the limitations of the manned and unmanned collaborative combat supervision and command system based on trusted blockchain described above, and will not be repeated here.

[0111] In one exemplary embodiment, such as Figure 3 As shown, a method for monitoring and commanding manned and unmanned collaborative operations based on a trusted blockchain is provided, including:

[0112] S301: Construct a command chain composed of manned unit nodes and a mission chain composed of unmanned unit nodes. Divide the unmanned unit nodes into mission segments according to the combat mission, establish the anchoring relationship between the command chain and the mission chain, and generate a segment mapping table containing member node information and supervisor node information of each mission segment, a public key list of command chain nodes, and a cross-chain anchoring table used to record the anchoring relationship between the mission chain and the command chain.

[0113] S302: Through the command chain, consecutive supervision windows are divided according to a preset time interval. Within each supervision window, a random seed is generated based on the hash value of the last block of the command chain in the previous supervision window and the number of key actions that have been supervised on the task chain. Based on the random seed, a threshold signature committee for the current window is elected from the nodes of the command chain using a verifiable random function. A threshold signature parameter set for the current window is generated through a distributed key generation protocol, and the status information of the threshold signature committee is written into the command chain for evidence storage. The threshold signature parameter set includes the private key share corresponding to each member of the threshold signature committee.

[0114] S303: Obtain the preset key action. Before the unmanned unit node in the task chain executes the key action, generate a supervision request containing a random number derived from the random seed of the current window and the hash of the action content. Send the supervision request to the threshold signature committee of the current window. After the threshold signature committee verifies the validity of the supervision request, generate multiple signature shares using the corresponding private key share. Aggregate the signature shares to generate a threshold signature and return the threshold signature to the unmanned unit node. Package the supervision records in the current window into a supervision audit block and send the supervision audit block to the command chain for evidence storage. The unmanned unit node is used to attach the threshold signature to the action instruction, obtain and execute the executable instruction package, and record the executable instruction package in the directed acyclic graph ledger of the task chain.

[0115] In one exemplary embodiment, the present invention also provides a computer device, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the steps of the manned and unmanned collaborative combat supervision and command system based on a trusted blockchain as described in this application. A multi-core processor is preferred to improve the system's parallel processing capability. The memory provides sufficient temporary storage space to support program execution and data processing. The memory capacity should be large enough to accommodate large amounts of data and computational tasks.

[0116] In one exemplary embodiment, the present invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the manned and unmanned collaborative combat supervision and command system based on a trusted blockchain as described in this application. The computer-readable storage medium may include: a read-only memory, a random access memory, a solid-state drive, or an optical disk, etc.

[0117] The above-described embodiments are merely illustrative of several implementation methods of the embodiments of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of the patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the embodiments of this application, and these modifications and improvements all fall within the protection scope of the embodiments of this application.

Claims

1. A manned and unmanned collaborative combat monitoring and command system based on trusted blockchain, characterized in that, The system includes: The chain network construction and anchoring module is used to construct a command chain composed of manned unit nodes and a task chain composed of unmanned unit nodes. According to the combat mission, the unmanned unit nodes are divided into task segments, the anchoring relationship between the command chain and the task chain is established, and a segment mapping table containing member node information and supervisor node information of each task segment, a public key list of command chain nodes, and a cross-chain anchoring table used to record the anchoring relationship between the task chain and the command chain are generated. The committee election and threshold signature module is used to divide the command chain into consecutive monitoring windows according to a preset time interval. Within each monitoring window, a random seed is generated based on the hash value of the last block of the command chain in the previous monitoring window and the number of monitored key actions on the task chain. Based on the random seed, a threshold signature committee for the current window is elected from the nodes of the command chain using a verifiable random function. A threshold signature parameter set for the current window is generated using a distributed key generation protocol. The status information of the threshold signature committee is written into the command chain for notarization. The threshold signature parameter set includes the private key share corresponding to each member of the threshold signature committee. The key action monitoring and auditing module is used to acquire preset key actions. Before the unmanned unit node in the task chain executes the key action, it generates a monitoring request containing a random number derived from the random seed of the current window and a hash of the action content. The monitoring request is sent to the threshold signature committee of the current window. After the threshold signature committee verifies the validity of the monitoring request, it generates multiple signature shares using the corresponding private key share, aggregates the signature shares to generate a threshold signature, and returns the threshold signature to the unmanned unit node. It then packages the monitoring records in the current window into a monitoring audit block and sends the monitoring audit block to the command chain for evidence storage. The unmanned unit node is used to attach the threshold signature to the action instruction to obtain and execute the executable instruction package, and records the executable instruction package in the directed acyclic graph ledger of the task chain.

2. The system according to claim 1, characterized in that, The system also includes: The reputation assessment and dynamic admission module is used to calculate the reputation value of each unmanned unit node and the manned unit node on the command chain based on the reputation smart contract deployed on the command chain and the transaction data in the directed acyclic graph ledger of the task chain, generate a reputation status table, and perform dynamic admission and exit management on the unmanned unit nodes based on the reputation threshold, and write the node status change event to the command chain.

3. The system according to claim 2, characterized in that, The system also includes: The health monitoring and command transfer module is used to monitor the nodes on the command chain in real time based on the health monitoring smart contract deployed on the command chain. When the monitoring results meet the preset trigger conditions, the command transfer process is initiated. Candidate nodes for command transfer are selected according to the reputation status table. The candidate nodes are elected by voting based on the weights corresponding to the reputation values ​​of the nodes on the command chain other than the manned unit node that triggered the command transfer. The elected node is used to receive the handover data packet, synchronize the state, and formally take over the command. After the transfer is completed, the command change result is written to the command chain, and the nodes of each task shard update the shard mapping table according to the command change result. The candidate node is either the manned unit node or the unmanned unit node.

4. The system according to claim 1, characterized in that, The committee election and threshold signature module includes a committee election subunit, which is used for: At the start of each supervision window, obtain the last block hash value of the command chain corresponding to the previous supervision window, and the number of key actions that have been supervised on the task chain in the previous supervision window; perform a hash operation on the concatenated string of the block hash value and the number of key actions to generate a random seed for the current window; Each manned unit node in the command chain uses the random seed and its own private key to execute a verifiable random function to calculate its own VRF hash value and VRF proof; the VRF hash value and VRF proof are then broadcast within the command chain. The VRF verification result is obtained by verifying the VRF proof received from each of the manned unit nodes in each of the command chains according to the corresponding public key in the command chain node public key list; The VRF hash value corresponding to the VRF proof that the VRF verification result is passed is used as the election score of the corresponding human unit node; The top K nodes with the highest election scores are selected as members of the threshold signature committee for the current window.

5. The system according to claim 1, characterized in that, The key action monitoring and audit evidence storage module includes a key action monitoring subunit, which is used for: Before the unmanned unit node in the task chain executes the key action, a supervision request data packet is generated. The supervision request data packet includes an action identifier, a node identifier, a timestamp, a current window sequence number, a task chain identifier, an action content hash value, and a random number. The action content hash value is obtained by hashing the action instruction generated based on the key action, and the random number is generated using the random seed of the current window and the unmanned unit node's own node private key. The unmanned unit node sends the supervision request data packet to the members of the threshold signature committee of the current window; When a member of the threshold signature committee receives the supervision request data packet, he or she verifies the supervision request data packet according to the preset verification rules and obtains the verification result. If the verification result is successful, the members of the threshold signature committee calculate the hash value of the supervision request data packet, sign the hash value using the private key share corresponding to each member, generate the signature share, and broadcast the signature share among the members of the threshold signature committee. Once the members of the threshold signature committee have obtained the number of signature shares of a preset threshold value, they execute a signature aggregation algorithm to aggregate the signature shares into the threshold signature and generate a signature proof. The signature proof includes the aggregated public key identifier used and a list of member identifiers who participated in the signing.

6. The system according to claim 2, characterized in that, The credit assessment and dynamic access module includes a credit assessment subunit, which is used for: The credit smart contract reads the current period transaction data of each unmanned unit node and the manned unit node on the command chain from the directed acyclic graph ledger of the task chain. Based on the transaction data, a corresponding task completion quality score is calculated for each unmanned unit node and each manned unit node, wherein the task completion quality score is obtained by calculating the weighted sum of target recognition accuracy, hit evaluation coefficient and response latency. Cross-validation is performed on the data reported by multiple unmanned unit nodes and manned unit nodes in the same task segment for the same area and time period. The average similarity between the data is calculated, and the data consistency score corresponding to each unmanned unit node and each manned unit node is obtained based on the average similarity. Based on the transaction data, the key actions in the transaction record are verified according to the preset supervision rules to determine whether each key action contains a valid supervision certificate, and the key actions that have been verified are obtained. Based on the key actions that have been verified and the total number of key actions in the transaction record, the supervision compliance score corresponding to each unmanned unit node and each manned unit node is calculated. The reputation values ​​of each unmanned unit node and each manned unit node for the previous period are obtained respectively. Based on the reputation values ​​of the previous period, a new reputation value is calculated by combining the task completion quality score, the data consistency score, and the supervision compliance score of the current period. In the first calculation, the reputation value of the previous period is a preset initial reputation value. Based on the node identifiers corresponding to each unmanned unit node and each manned unit node, and combined with the reputation value of the previous period and the new reputation value, the reputation status table is generated.

7. The system according to claim 3, characterized in that, The health monitoring and command transfer module includes a health monitoring subunit, which is used for: The health monitoring smart contract obtains the proof of survival transactions issued by the human unit node on the command chain in each supervision window. The proof of survival transaction includes node identifier, window number, timestamp, location coordinates, self-check status code and signature. Count the number of consecutive windows in which each of the said inhabited unit nodes has not sent the proof of survival transaction; The health monitoring smart contract calculates the task completion rate and data consistency score of each human unit node supervising the task shard from the directed acyclic graph ledger of the task chain, extracts the supervision response delay from the supervision audit block, and receives threat alarm events sent by the external threat detection system. Based on the task completion rate, the data consistency score, the supervision response delay, and the threat alarm event, it is determined whether to initiate command migration, and a judgment result is obtained. When the judgment result is to initiate command migration, a migration trigger event is generated. The migration trigger event includes the original command node identifier, trigger condition type, trigger time, and evidence data hash. After the migration trigger event occurs, an initial candidate node is selected from the manned unit node and the unmanned unit node by an election smart contract deployed on the command chain, based on the reputation status table. Calculate the capability matching degree between the initial candidate nodes and the task fragments to be taken over, and select the top N initial candidate nodes with the highest capability matching degree to generate a candidate node list; The capability matching degree is obtained by weighting the computing capability matching degree, communication quality matching degree, and task experience matching degree.

8. A method for monitoring and commanding manned and unmanned collaborative operations based on trusted blockchain, characterized in that, The method includes: Construct a command chain composed of manned unit nodes and a mission chain composed of unmanned unit nodes. Divide the unmanned unit nodes into mission segments according to the combat mission. Establish the anchoring relationship between the command chain and the mission chain. Generate a segment mapping table containing member node information and supervisor node information of each mission segment, a command chain node public key list, and a cross-chain anchoring table for recording the anchoring relationship between the mission chain and the command chain. Through the command chain, consecutive monitoring windows are divided according to a preset time interval. Within each monitoring window, a random seed for the current window is generated based on the hash value of the last block of the command chain in the previous monitoring window and the number of monitored key actions on the task chain. Based on the random seed, a threshold signature committee for the current window is elected from the nodes of the command chain using a verifiable random function. A threshold signature parameter set for the current window is generated through a distributed key generation protocol, and the status information of the threshold signature committee is written into the command chain for evidence storage. The threshold signature parameter set includes the private key share corresponding to each member of the threshold signature committee. Before the unmanned unit node in the task chain executes the preset key action, a supervision request is generated containing a random number derived from the random seed of the current window and a hash of the action content. The supervision request is sent to the threshold signature committee of the current window. After the threshold signature committee verifies the validity of the supervision request, multiple signature shares are generated using the corresponding private key share. The signature shares are aggregated to generate a threshold signature, and the threshold signature is returned to the unmanned unit node. The supervision records in the current window are packaged into a supervision audit block, and the supervision audit block is sent to the command chain for evidence storage. The unmanned unit node is used to attach the threshold signature to the action instruction to obtain and execute the executable instruction package, and record the executable instruction package in the directed acyclic graph ledger of the task chain.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the system according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the system according to any one of claims 1 to 7.

Images