Method and system for verifying the legitimacy of multi-node monitoring data based on MPC fragment key
By using the MPC sharding key multi-node monitoring data legitimacy verification method, the legitimacy of monitoring data is generated and verified, solving the problems of correct monitoring data generation and node identity leakage in existing technologies, and realizing high security and reliability of distributed monitoring systems.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- JIANGSU HENGBAO INTELLIGENT SYST TECH CO LTD
- Filing Date
- 2026-03-31
- Publication Date
- 2026-06-09
AI Technical Summary
Existing distributed monitoring systems cannot verify the correctness of monitoring data generation in adversarial environments. Most consensus mechanisms are easily misled by malicious nodes that cooperate. Multi-signature mechanisms lack verification of the correctness of sharding calculations. Node identities and participation relationships are easily inferred, reducing system security.
A multi-node monitoring data legitimacy verification method based on MPC sharded keys is adopted. Public keys and key shards are generated through threshold key sharding protocol. Protection nodes obtain monitoring data in real time and generate partial signatures and zero-knowledge proofs. After verification by relay nodes, they are aggregated into a joint signature. The central node or smart contract performs the final verification.
It significantly improves the anti-forgery and anti-collusion capabilities and overall verifiability of the multi-node monitoring network, ensures the authenticity and legality of data sources, reduces the trust dependence of central nodes, and improves the robustness and security of the system.
Smart Images
Figure CN122179116A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of distributed security monitoring and data verification technology, and in particular to a method and system for verifying the legality of multi-node monitoring data based on MPC fragmentation keys. Background Technology
[0002] In the field of distributed monitoring, existing distributed monitoring systems (such as Guard Network, Watchtower, Oracle Network, distributed security alarm systems, etc.) generally adopt an architecture of multi-node monitoring and centralized verification. Multiple independently deployed monitoring nodes continuously monitor the target system, network status or on-chain behavior and report the monitoring results to the central node or smart contract. Finally, the central node or smart contract determines the credibility of the monitoring data.
[0003] In existing technologies, the mainstream methods for verifying data credibility mainly include the following three categories: 1. Hash-based consistency verification mechanism: First, multiple monitoring nodes calculate the hash value of the observed event or status data and report it. Then, the central node determines whether the event has actually occurred by comparing whether the hash values submitted by different monitoring nodes are consistent.
[0004] 2. Judgment mechanism based on majority node consensus: When a preset threshold number of monitoring nodes (e.g., 2 / 3, 3 / 5) give a consistent judgment on the same event or status data, the event or status data is considered trustworthy.
[0005] 3. Authentication mechanism based on multi-signature or simple threshold signature: Multiple monitoring nodes sign the monitoring data or event results respectively. When the central node or smart contract collects a number of signatures that meet the threshold, the central node or smart contract verifies the validity of the signature.
[0006] Although mainstream data trustworthiness verification methods have improved the robustness of the system to some extent, there are still many technical shortcomings in distributed monitoring scenarios under adversarial environments, as follows: (1) Inability to verify the correctness of the generated monitoring data: Existing solutions can only verify whether the results are consistent, but cannot verify whether each monitoring node actually executes the expected monitoring logic. For example, whether each monitoring node generates results based on real observation data; whether each monitoring node skips, tampers with, or simplifies monitoring rules; and whether each monitoring node submits forged or replayed historical data. Hash consistency verification or majority monitoring node consensus can only prove that the results are the same, but cannot guarantee that the generation process of the results is correct and reliable.
[0007] (2) Majority consensus cannot defend against coordinated malicious nodes: In actual deployment, multiple monitoring nodes may depend on the same data source or upstream service, be deployed in the same cloud environment or management domain, or be controlled or influenced by the same attacker. In such scenarios, even if a majority consensus is reached among the monitoring nodes, they may still form a consistent judgment on erroneous or forged monitoring results, leading the system to make incorrect decisions.
[0008] (3) The multi-signature mechanism lacks the ability to verify the correctness of the fragment calculation: Existing multi-signature or threshold signature schemes usually only focus on whether a sufficient number of signatures have been collected and whether the signature can be verified by the public key, but cannot verify whether each partial signature is generated by a legitimate key fragment or whether it is correctly calculated for the specified monitoring data. This makes it difficult for the system to prevent risks such as malicious nodes submitting random or invalid partial signatures, relay nodes forging or replacing partial signatures, and unauthorized nodes impersonating legitimate monitoring nodes to participate in signing.
[0009] (4) The identity and participation relationship of monitoring nodes are easily inferred: In multi-signature or direct reporting signature schemes, the actual set of nodes participating in monitoring is usually in a visible state, and the number of nodes, participation frequency, and role relationships are easily inferred from the outside. In distributed monitoring adversarial scenarios, such information leakage will significantly increase the risk of monitoring nodes being targeted or evaded, reducing the overall security of the system.
[0010] Therefore, there is an urgent need to develop a new method and system for verifying the legality of multi-node monitoring data based on MPC fragmentation keys in order to solve one or more of the above problems. Summary of the Invention
[0011] The purpose of this application is to provide a method and system for verifying the legitimacy of multi-node monitoring data based on MPC sharded keys. This method and system can significantly improve the anti-forgery capability, anti-collusion capability, and overall verifiability of multi-node monitoring networks without exposing key sharding, disclosing node identities, or revealing monitoring data details.
[0012] To achieve the above objectives, this application provides a multi-node monitoring data legitimacy verification method based on MPC sharded keys, comprising the following steps: S01: n protection nodes jointly negotiate through a threshold key sharding protocol to generate a public key PK and a set of distributed key shards for the target distributed monitoring network. Each protection node holds only one key shard share_i from this set of distributed key shards. The set of distributed key shards collaboratively possesses the signature function of a complete private key, and a single key shard share_i cannot independently generate a valid signature; S02: When a monitoring event is triggered, each protection node acquires monitoring data D in real time, processes the monitoring data D based on its own key shard share_i, obtains a monitoring data verification data packet, and reports the monitoring data verification data packet to the relay node; wherein, the monitoring data verification data packet includes: monitoring The data consists of a hash value D_hash, a partial signature (partial_sig_i), and a zero-knowledge proof (π_i). S03: The relay node verifies the zero-knowledge proof (π_i) in the monitoring data verification packets reported by each protection node packet by packet. Only the partially verified signature (partial_sig_i) is included in the aggregation candidate set. When the number of partially verified signatures in the aggregation candidate set is greater than or equal to a preset threshold, aggregation is performed to obtain the joint signature (sig) of the monitoring data D. S04: The central node or smart contract calls the public key PK to verify the joint signature (sig) of the monitoring data D, and simultaneously verifies the threshold participation proof. When the joint signature (sig) of the monitoring data D is verified and the threshold participation proof is valid, the monitoring data D is deemed to meet the legality requirements and is accepted; otherwise, the monitoring data D is rejected.
[0013] As shown above, the threshold key fragmentation protocol is the MPC threshold protocol.
[0014] As described above, the sub-steps of step S02 include: S021: When a monitoring event is triggered, each protection node acquires monitoring data D in real time and performs a hash operation on the monitoring data D to obtain the monitoring data hash value D_hash; S022: Each protection node uses its own key fragment share_i to perform a partial signature operation on the monitoring data D to obtain a partial signature partial_sig_i; S023: Each protection node generates a zero-knowledge proof π_i based on its own key fragment share_i, monitoring data D, and partial signature partial_sig_i; S024: Each protection node encapsulates the monitoring data hash value D_hash, partial signature partial_sig_i, and zero-knowledge proof π_i into a monitoring data verification data packet and reports all monitoring data verification data packets to the relay node.
[0015] As shown above, the protection node i uses its own key fragment share_i to perform a partial signature operation on the monitoring data D, resulting in the following expression for the partial signature: Where partial_sig_i is the partial signature generated by the protection node i; is a function of the MPC threshold protocol; share_i is the key fragment held by the protection node i itself; D is the monitoring data to be signed.
[0016] As mentioned above, the proof content of zero-knowledge proof π_i includes at least the following: the partial signature partial_sig_i is indeed generated by the legitimate key fragment share_i negotiated by the system; the partial signature partial_sig_i correctly corresponds to the specified monitoring data D; and no information of any key fragment share_i is disclosed during the zero-knowledge proof process.
[0017] As described above, step S03 includes the following sub-steps: S031: The relay node collects monitoring data verification data packets from multiple protection nodes and verifies the zero-knowledge proof π_i in each monitoring data verification data packet, generating a verification result. If the verification result is a verification failure, the monitoring data verification data packet is removed; if the verification result is a verification pass, the partial signature partial_sig_i in the monitoring data verification data packet is included in the aggregation candidate set; S032: After all monitoring data verification data packets have been verified, the number of partial signatures partial_sig_i in the aggregation candidate set is counted. If the number of partial signatures partial_sig_i in the aggregation candidate set is greater than or equal to the preset pass threshold, the partial signatures partial_sig_i in the aggregation candidate set are aggregated to obtain the joint signature sig of the monitoring data D, and the corresponding threshold participation proof is generated; if the number of partial signatures partial_sig_i in the aggregation candidate set is less than the preset pass threshold, it is determined that the multi-node monitoring data verification has failed, the subsequent aggregation operation is terminated, and the verification failure result is returned to the central node or smart contract.
[0018] As shown above, the partial signatures partial_sig_i in the aggregation candidate set are aggregated using a threshold aggregation function to obtain the joint signature sig of the monitoring data D. The expression for the joint signature sig of the monitoring data D is as follows: ;in, For threshold aggregation functions; Sign the first part of the aggregated candidate set; Let t be the t-th partial signature in the aggregate candidate set, and let t be the total number of partial signatures partial_sig_i in the aggregate candidate set.
[0019] As shown above, the preset threshold for the number of passes is set to more than 2 / 3 of the total number of protected nodes.
[0020] As shown above, the target distributed monitoring network is the Guard Network.
[0021] This application also provides a multi-node monitoring data legitimacy verification system based on MPC sharded keys, including: a protection node module, relay nodes, and a central node / smart contract; wherein, the protection node module includes n protection nodes, each with independent and consistent functions: the n protection nodes jointly negotiate through a threshold key sharding protocol to generate a public key PK and a set of distributed key shards for the target distributed monitoring network, and each protection node holds only one key shard share_i in this set of distributed key shards; the set of distributed key shards collaboratively possesses the function of signing with a complete private key, and a single key shard share_i cannot independently generate a valid signature; when a monitoring event is triggered, each protection node obtains monitoring data D in real time, processes the monitoring data D based on its own key shard share_i, obtains a monitoring data verification data packet, and sends the monitoring data to the relevant department. The data verification data packet is reported to the relay node. The monitoring data verification data packet includes: the monitoring data hash value D_hash, the partial signature partial_sig_i, and the zero-knowledge proof π_i. The relay node collects the monitoring data verification data packets reported by each protection node and verifies the zero-knowledge proof π_i in each packet. Only the partially verified partial signatures partial_sig_i are included in the aggregation candidate set. The number of partial signatures in the aggregation candidate set is counted. When this number is greater than or equal to a preset threshold, aggregation is performed on all valid partial signatures to obtain the joint signature sig of the monitoring data D, and a corresponding threshold participation proof is generated. The joint signature sig, the threshold participation proof, and the corresponding monitoring data hash value D_hash are reported to the central node / smart contract. Central node / smart contract: Used to call public key PK to verify the joint signature sig of monitoring data D, and at the same time verify the threshold participation proof; when the joint signature sig of monitoring data D is verified and the threshold participation proof is valid, it is determined that monitoring data D meets the legality requirements and monitoring data D is accepted; otherwise, monitoring data D is rejected. Attached Figure Description
[0022] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings.
[0023] Figure 1 This is a schematic diagram of the structure of an embodiment of a multi-node monitoring data legitimacy verification system based on MPC fragmentation keys; Figure 2 This is a flowchart of one embodiment of a multi-node monitoring data legitimacy verification method based on MPC fragmented keys. Detailed Implementation
[0024] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0025] like Figure 1 As shown, this application provides a multi-node monitoring data legitimacy verification system based on MPC sharding keys, including: a protection node module, a relay node, and a central node / smart contract. Each module collaboratively executes the following multi-node monitoring data legitimacy verification method based on MPC sharding keys, with the specific functions as follows: The protection node module comprises n protection nodes, each with independent and consistent functions: The n protection nodes jointly negotiate via a threshold key sharding protocol to generate a public key PK and a set of distributed key shards for the target distributed monitoring network. Each protection node holds only one key shard, share_i, from this set of distributed key shards. The set of distributed key shards collaboratively possesses the ability to sign with a complete private key; a single key shard, share_i, cannot independently generate a valid signature. When a monitoring event is triggered, each protection node acquires monitoring data D in real time, processes the monitoring data D based on its own key shard, share_i, to obtain a monitoring data verification data packet, and reports the monitoring data verification data packet to the relay node. The monitoring data verification data packet includes: the monitoring data hash value D_hash, a partial signature, partial_sig_i, and a zero-knowledge proof π_i. Here, n is a positive integer, and n is greater than 1.
[0026] Relay Node: Used to collect monitoring data verification data packets reported by each protection node, and to verify the zero-knowledge proof π_i in each monitoring data verification data packet packet by packet. Only the partially verified signatures partial_sig_i are included in the aggregation candidate set. The number of partial signatures in the aggregation candidate set is counted. When the number is greater than or equal to the preset passing number threshold, the aggregation operation is performed on all legal partial signatures to obtain the joint signature sig of the monitoring data D, and the corresponding threshold participation proof is generated. The joint signature sig, the threshold participation proof and the corresponding monitoring data hash value D_hash are reported to the central node / smart contract.
[0027] Central node / smart contract: Used to call public key PK to verify the joint signature sig of monitoring data D, and at the same time verify the threshold participation proof; when the joint signature sig of monitoring data D is verified and the threshold participation proof is valid, it is determined that monitoring data D meets the legality requirements and monitoring data D is accepted; otherwise, monitoring data D is rejected.
[0028] Furthermore, the hardware deployment of each module is not limited: the protection node module can be deployed as an edge computing node, an on-chain verification node, or an independent monitoring device; the relay node can be deployed as a cloud server, an off-chain relay node, or a distributed message queue; the central node / smart contract can be deployed as a centralized server cluster or an on-chain smart contract (such as Ethereum, BSC, and other public / consortium chain contracts), as long as it meets the functional logic and data interaction requirements of each module.
[0029] like Figure 2 As shown, this application provides a method for verifying the legitimacy of multi-node monitoring data based on MPC fragmentation keys, including the following steps: S01: n protection nodes jointly negotiate through a threshold key sharding protocol to generate a public key PK and a set of distributed key shards for the target distributed monitoring network. Each protection node holds only one key shard share_i in this set of distributed key shards. A set of distributed key shards collaboratively possesses the signature function of a complete private key, and a single key shard share_i cannot independently generate a valid signature.
[0030] Furthermore, this application preferably uses a Guard Network as the target distributed monitoring network, but it is not limited to this. Any distributed monitoring network with the ability to independently monitor multiple nodes, report data from multiple sources, and perform centralized or distributed verification can be used to implement the technical solution of this application.
[0031] Furthermore, this application preferably uses an MPC (Multi-Party Secure Computation) threshold protocol for the threshold key sharding protocol, but it is not limited to this. Any threshold cryptographic protocol that can decompose a complete private key into multiple independent shards, where a single shard cannot recover the complete private key, and where only a threshold number of shards can collaboratively generate a valid signature, is applicable to the technical solution of this application.
[0032] S02: When a monitoring event is triggered, each protection node acquires the monitoring data D in real time, processes the monitoring data D based on its own key fragment share_i, obtains the monitoring data verification data packet, and reports the monitoring data verification data packet to the relay node; wherein, the monitoring data verification data packet includes: monitoring data hash value D_hash, partial signature partial_sig_i, and zero-knowledge proof π_i.
[0033] Specifically, the monitoring events in this application refer to target behaviors or security alerts that are independently detected by protection nodes in the target distributed monitoring network and require authenticity verification through distributed signature and legality verification mechanisms. The specific content of the monitoring events is determined based on the monitoring object and business scenario, including but not limited to: risk intelligence (such as security threats, vulnerability warnings, attack intelligence), on-chain anomalies (such as abnormal transactions, contract violations, on-chain behavior tampering), asset monitoring (such as asset changes, permission changes, configuration violations), network anomalies (such as abnormal traffic, unauthorized access, communication tampering), and system alerts (such as service failures, node offline, abnormal status).
[0034] Furthermore, the sub-steps of step S02 include: S021: When a monitoring event is triggered, each protection node acquires the monitoring data D in real time and performs a hash operation on the monitoring data D to obtain the monitoring data hash value D_hash.
[0035] Specifically, the monitoring data hash value D_hash is used to form a unique binding relationship with the partial signature partial_sig_i to ensure that the monitoring data D has not been tampered with or replaced.
[0036] Step S021 can be implemented using a hash algorithm that can achieve data integrity verification and unique identifier generation, so it will not be described in detail here; for example, SHA-256, SHA-3, SM3, MD5 or other national cryptographic / internationally recognized hash algorithms can be used.
[0037] S022: Each protection node uses its own key fragment share_i to perform a partial signature operation on the monitoring data D to obtain a partial signature partial_sig_i.
[0038] Furthermore, the protection node i uses its own key fragment share_i to perform a partial signature operation on the monitoring data D, resulting in the expression for the partial signature: ; Where partial_sig_i is the partial signature generated by the protection node i; is a function for the MPC (Multi-Party Computation) threshold protocol; share_i is the key fragment held by the protection node i itself; D is the monitoring data to be signed.
[0039] S023: Each protection node generates a zero-knowledge proof π_i based on its own key fragment share_i, monitoring data D, and partial signature partial_sig_i.
[0040] Furthermore, the proof content of the zero-knowledge proof π_i includes at least the following: the partial signature partial_sig_i is indeed generated by the legitimate key fragment share_i negotiated by the system (i.e., the multi-node monitoring data legality verification system based on MPC fragment keys in this application); the partial signature partial_sig_i correctly corresponds to the specified monitoring data D (i.e., there is a unique binding relationship between the partial signature partial_sig_i and the monitoring data hash value D_hash); and no information of the key fragment share_i is disclosed during the zero-knowledge proof (ZKP) process.
[0041] Furthermore, this application preferably employs a zero-knowledge proof generation logic based on the MPC threshold protocol for the zero-knowledge proof process. However, it is not limited to this; it may also employ the Sigma protocol, Groth16, Plonky, ZKSNARK, or an elliptic curve-based zero-knowledge proof system. Any process capable of proving the zero-knowledge proof π_i can be used.
[0042] S024: Each protection node encapsulates the monitoring data hash value D_hash, the partial signature partial_sig_i, and the zero-knowledge proof π_i into a monitoring data verification data packet, and reports all monitoring data verification data packets to the relay node.
[0043] S03: The relay node verifies the zero-knowledge proof π_i in the monitoring data verification data packets reported by each protection node packet by packet. Only the partially verified signatures partial_sig_i are included in the aggregation candidate set. When the number of partially verified signatures in the aggregation candidate set is greater than or equal to the preset passing number threshold, the aggregation operation is performed to obtain the joint signature sig of the monitoring data D.
[0044] Furthermore, the sub-steps of step S03 include: S031: The relay node collects monitoring data verification data packets from multiple protection nodes and verifies the zero-knowledge proof π_i in the monitoring data verification data packets one by one, generating a verification result. If the verification result is a verification failure, the monitoring data verification data packet is removed; if the verification result is a verification success, the partial signature partial_sig_i in the monitoring data verification data packet is included in the aggregation candidate set.
[0045] Specifically, based on the proof content of zero-knowledge proof π_i, the zero-knowledge proof π_i in the monitoring data verification data packet is verified packet by packet. If the zero-knowledge proof π_i conforms to the preset proof rules, has not been tampered with, and can prove that the partial signature corresponding to the zero-knowledge proof π_i is generated by the negotiated legitimate key fragment share_i and correctly corresponds to the specified monitoring data D, then the generated verification result is verification passed. If the zero-knowledge proof π_i does not conform to the preset proof rules, has not been tampered with, and / or cannot prove that the partial signature corresponding to the zero-knowledge proof π_i is generated by the negotiated legitimate key fragment share_i and correctly corresponds to the specified monitoring data D, then the generated verification result is verification failed.
[0046] S032: After all monitoring data verification data packets have been verified, count the number of partial signatures (partial_sig_i) in the aggregation candidate set. If the number of partial signatures (partial_sig_i) in the aggregation candidate set is greater than or equal to the preset passing threshold, then perform aggregation operations on the partial signatures (partial_sig_i) in the aggregation candidate set to obtain the joint signature (sig) of monitoring data D, and generate the corresponding threshold participation proof. If the number of partial signatures (partial_sig_i) in the aggregation candidate set is less than the preset passing threshold, then it is determined that the multi-node monitoring data verification has failed, the subsequent aggregation operation is terminated, and the verification failure result is returned to the central node or smart contract.
[0047] Specifically, step S032 does not limit the specific implementation method, algorithm, or expression of the aggregation operation, as long as it can generate a joint signature from multiple valid partial signatures partial_sig_i and form a threshold participation proof. Preferably, this application uses a threshold aggregation function to aggregate the partial signatures partial_sig_i in the aggregation candidate set to obtain the joint signature sig of the monitoring data D, where the expression of the joint signature sig of the monitoring data D is: ; in, For threshold aggregation functions; Sign the first part of the aggregated candidate set; Let t be the t-th partial signature in the aggregate candidate set, and let t be the total number of partial signatures partial_sig_i in the aggregate candidate set.
[0048] Furthermore, this application preferably sets the threshold value for the number of passes to be more than 2 / 3 (inclusive) of the total number of protected nodes, but is not limited to this.
[0049] S04: The central node or smart contract calls the public key PK to verify the joint signature sig of the monitoring data D, and at the same time verify the threshold participation proof; when the joint signature sig of the monitoring data D is verified and the threshold participation proof is valid, the monitoring data D is determined to meet the legality requirements and the monitoring data D is accepted; otherwise, the monitoring data D is rejected.
[0050] Specifically, monitoring data D is rejected when the joint signature sig verification of monitoring data D fails and / or the threshold participation proof is invalid.
[0051] Furthermore, the verification logic for step S04 is as follows: , and VerifyZK (threshold participation proof) == true: , : Reject monitoring data D from this study. in, To verify federated signatures using the master public key PK The binding relationship with monitoring data D, This indicates that the joint signature sig of the monitoring data D is valid; VerifyZK(threshold participation proof) indicates the validity of the threshold participation proof, and VerifyZK(threshold participation proof) == true indicates that the threshold participation proof is valid.
[0052] Furthermore, when the joint signature verification passes and the threshold participation proof is valid, it signifies the following: 1. The joint signature sig of monitoring data D is generated by the private key system corresponding to the legitimate public key PK (i.e., a set of distributed key fragments). The signature has not been tampered with and is uniquely bound to monitoring data D.
[0053] 2. The joint signature sig of the monitoring data D is generated by aggregating no less than a preset threshold number of legitimate partial signatures. All partial signatures participating in the aggregation come from legitimate protection nodes verified by zero-knowledge proofs.
[0054] 3. The entire process of collecting, fragmenting, signing, verifying, and aggregating multi-node monitoring data is legal and valid, and the monitoring data D meets the system's preset requirements for legality and integrity.
[0055] The beneficial effects achieved by this application are as follows: (1) Through the MPC threshold key sharding mechanism, each protection node can only use the key shards it holds to generate a partial signature bound to itself. A single or a small number of protection nodes cannot independently generate a joint signature that can be verified. Only when legitimate protection nodes that have reached the preset number threshold jointly participate in the signature calculation for the same monitoring data can a valid joint signature be generated. This ensures that the monitoring data is not forged or tampered with from a cryptographic perspective, greatly improves the overall security of the distributed monitoring network, and significantly enhances the anti-forgery and anti-tampering capabilities of the monitoring data of multiple protection nodes.
[0056] (2) Through a complete mechanism of fragmented signature, threshold aggregation and joint signature verification, it is ensured that each signature is generated based on the real monitoring data of the protection node, and the joint signature corresponds to the joint confirmation of the same monitoring data by multiple legitimate protection nodes. Even if some nodes collude, they cannot generate a legitimate joint signature without actually collecting the same data. This fundamentally eliminates the security risks of protection nodes colluding to forge data, ensures the authenticity of the data source from multiple nodes, and effectively resists node collusion to forge data.
[0057] (3) Each partial signature is uniquely bound to a specific key fragment and node identity, and the key fragments are not interchangeable in cryptography; the legality of the generation of each partial signature is verified by zero-knowledge proof, which can confirm that the partial signature is generated by a legitimate key fragment and bound to the specified monitoring data without disclosing the sensitive information of the key fragments and nodes, and that unauthorized or fake nodes cannot generate verifiable partial signatures, effectively preventing node spoofing, substitution and simulation attacks, and realizing zero-knowledge verifiability of the protection of node participation and the correctness of key fragment calculation.
[0058] (4) The central node or smart contract does not need to judge whether the node is honest, nor does it need to participate in the execution of the MPC protocol and key sharding management. It only needs to perform a one-time verification of the joint signature and threshold participation proof to obtain a reliable legality judgment conclusion. The system changes from "judgment based on node trust" to "judgment based on cryptographic verification", which significantly improves the degree of decentralization and overall reliability and significantly reduces the reliance on trust in the central node.
[0059] (5) The threshold structure design enables the system to tolerate a small number of nodes being offline, malfunctioning, or acting maliciously. A small number of abnormal nodes do not affect the correct generation and verification of joint signatures. Even if an attacker controls some nodes, they cannot forge legitimate monitoring data. The system can still operate stably under network anomalies, node failures, or targeted attack scenarios, and has high robustness and attack tolerance, effectively enhancing the system's ability to resist single point failures and node malicious behavior.
[0060] (6) The joint signature has a fixed length and is independent of the number of participating nodes, which can be efficiently verified in smart contracts or backend systems. Compared with storing and verifying multiple independent signatures or hash values, this application can significantly reduce the data storage overhead, signature verification calculation cost and Gas cost on the chain or in the system, improve the efficiency of monitoring data verification, and is suitable for real-time and high-frequency monitoring scenarios with a large number of nodes participating, so as to achieve efficient data verification and storage.
[0061] (7) Through the synergistic effect of MPC fragmented signature, threshold aggregation and zero-knowledge verifiable mechanism, the system achieves comprehensive security capabilities at the system level, including anti-forgery, anti-tampering, anti-node collusion, anti-node masquerading and resistance to node offline and attack, significantly improving the credibility of the monitoring results output by the distributed monitoring network, achieving a comprehensive security enhancement effect that is difficult to achieve with existing technologies, and comprehensively improving the overall credibility and security level of the distributed monitoring network.
[0062] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the scope of protection of this application is intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application. Obviously, those skilled in the art can make various alterations and variations to this application without departing from the spirit and scope of this application. Thus, if these modifications and variations of this application fall within the scope of protection of this application and its equivalents, this application also intends to include these modifications and variations.
Claims
1. A method for verifying the legitimacy of multi-node monitoring data based on MPC fragmentation keys, characterized in that, Includes the following steps: S01: n protection nodes jointly negotiate through the threshold key sharding protocol to generate a public key PK and a set of distributed key shards for the target distributed monitoring network. Each protection node holds only one key shard share_i in this set of distributed key shards. A set of distributed key shards collaboratively possesses the signature function of a complete private key. A single key shard share_i cannot independently generate a valid signature. S02: When a monitoring event is triggered, each protection node acquires the monitoring data D in real time, processes the monitoring data D based on its own key fragment share_i, obtains the monitoring data verification data packet, and reports the monitoring data verification data packet to the relay node; wherein, the monitoring data verification data packet includes: monitoring data hash value D_hash, partial signature partial_sig_i, and zero-knowledge proof π_i; S03: The relay node verifies the zero-knowledge proof π_i in the monitoring data verification data packets reported by each protection node packet by packet. Only the partially verified signatures partial_sig_i are included in the aggregation candidate set. When the number of partially verified signatures in the aggregation candidate set is greater than or equal to the preset passing number threshold, the aggregation operation is performed to obtain the joint signature sig of the monitoring data D. S04: The central node or smart contract calls the public key PK to verify the joint signature sig of the monitoring data D, and at the same time verify the threshold participation proof; when the joint signature sig of the monitoring data D is verified and the threshold participation proof is valid, the monitoring data D is determined to meet the legality requirements and the monitoring data D is accepted; otherwise, the monitoring data D is rejected.
2. The multi-node monitoring data legitimacy verification method based on MPC fragmentation keys according to claim 1, characterized in that, The threshold key fragmentation protocol is the MPC threshold protocol.
3. The multi-node monitoring data legitimacy verification method based on MPC fragmentation keys according to claim 1, characterized in that, The sub-steps of step S02 include: S021: When a monitoring event is triggered, each protection node acquires the monitoring data D in real time and performs a hash operation on the monitoring data D to obtain the monitoring data hash value D_hash; S022: Each protection node uses its own key fragment share_i to perform a partial signature operation on the monitoring data D to obtain a partial signature partial_sig_i; S023: Each protection node generates a zero-knowledge proof π_i based on its own key fragment share_i, monitoring data D, and partial signature partial_sig_i; S024: Each protection node encapsulates the monitoring data hash value D_hash, the partial signature partial_sig_i, and the zero-knowledge proof π_i into a monitoring data verification data packet, and reports all monitoring data verification data packets to the relay node.
4. The multi-node monitoring data legitimacy verification method based on MPC fragmentation keys according to claim 3, characterized in that, The protection node i uses its own key fragment share_i to perform a partial signature operation on the monitoring data D, resulting in the following expression for the partial signature: ； Where partial_sig_i is the partial signature generated by the protection node i; is a function of the MPC threshold protocol; share_i is the key fragment held by the protection node i itself; D is the monitoring data to be signed.
5. The multi-node monitoring data legitimacy verification method based on MPC fragmentation keys according to claim 3, characterized in that, The proof content of zero-knowledge proof π_i includes at least the following: the partial signature partial_sig_i is indeed generated by the legitimate key fragment share_i negotiated by the system; the partial signature partial_sig_i correctly corresponds to the specified monitoring data D; and no information of the key fragment share_i is disclosed during the zero-knowledge proof process.
6. The multi-node monitoring data legitimacy verification method based on MPC fragmentation key according to claim 1, characterized in that, The sub-steps of step S03 include: S031: The relay node collects monitoring data verification data packets from multiple protection nodes and verifies the zero-knowledge proof π_i in the monitoring data verification data packets one by one, generating a verification result. If the verification result is a verification failure, the monitoring data verification data packet is removed; if the verification result is a verification success, the partial signature partial_sig_i in the monitoring data verification data packet is included in the aggregation candidate set. S032: After all monitoring data verification data packets have been verified, count the number of partial signatures (partial_sig_i) in the aggregation candidate set. If the number of partial signatures (partial_sig_i) in the aggregation candidate set is greater than or equal to the preset passing threshold, then perform aggregation operations on the partial signatures (partial_sig_i) in the aggregation candidate set to obtain the joint signature (sig) of monitoring data D, and generate the corresponding threshold participation proof. If the number of partial signatures (partial_sig_i) in the aggregation candidate set is less than the preset passing threshold, then it is determined that the multi-node monitoring data verification has failed, the subsequent aggregation operation is terminated, and the verification failure result is returned to the central node or smart contract.
7. The method for verifying the legitimacy of multi-node monitoring data based on MPC sharding keys according to claim 6, characterized in that, The partial signatures (partial_sig_i) in the candidate aggregation set are aggregated using a threshold aggregation function to obtain the joint signature (sig) of the monitoring data D. The expression for the joint signature (sig) of the monitoring data D is as follows: ; in, For threshold aggregation functions; Sign the first part of the aggregated candidate set; Let t be the t-th partial signature in the aggregate candidate set, and let t be the total number of partial signatures partial_sig_i in the aggregate candidate set.
8. The multi-node monitoring data legitimacy verification method based on MPC fragmentation keys according to claim 6, characterized in that, The preset threshold for the number of passes is set to more than 2 / 3 of the total number of protected nodes.
9. The multi-node monitoring data legitimacy verification method based on MPC fragmentation keys according to claim 1, characterized in that, The target distributed monitoring network is the Guard Network.
10. A multi-node monitoring data legitimacy verification system based on MPC fragmentation keys, characterized in that, include: Protection node module, relay node, and central node / smart contract; The protection node module consists of n protection nodes, each with independent and consistent functions: the n protection nodes jointly negotiate through a threshold key sharding protocol to generate a public key PK and a set of distributed key shards for the target distributed monitoring network. Each protection node holds only one key shard share_i from this set of distributed key shards. The set of distributed key shards collaboratively possesses the signature function of a complete private key, and a single key shard share_i cannot independently generate a valid signature. When a monitoring event is triggered, each protection node acquires monitoring data D in real time, processes the monitoring data D based on its own key shard share_i, obtains a monitoring data verification data packet, and reports the monitoring data verification data packet to the relay node. The monitoring data verification data packet includes: the monitoring data hash value D_hash, the partial signature partial_sig_i, and the zero-knowledge proof π_i. Relay Node: Used to collect monitoring data verification data packets reported by each protection node, and to verify the zero-knowledge proof π_i in each monitoring data verification data packet packet by packet. Only the partially verified signatures partial_sig_i are included in the aggregation candidate set; the number of partial signatures in the aggregation candidate set is counted. When the number is greater than or equal to the preset passing number threshold, the aggregation operation is performed on all legal partial signatures to obtain the joint signature sig of the monitoring data D, and the corresponding threshold participation proof is generated at the same time; the joint signature sig, the threshold participation proof and the corresponding monitoring data hash value D_hash are reported to the central node / smart contract; Central node / smart contract: Used to call public key PK to verify the joint signature sig of monitoring data D, and at the same time verify the threshold participation proof; when the joint signature sig of monitoring data D is verified and the threshold participation proof is valid, it is determined that monitoring data D meets the legality requirements and monitoring data D is accepted; otherwise, monitoring data D is rejected.