Carbon emission abnormity tracing method and device, medium and equipment

Abstract

The invention discloses a carbon emission abnormity traceability method and device, a medium and equipment, and belongs to the field of carbon emission, and the method comprises the steps: receiving a traceability request containing a to-be-verified data identifier, positioning target link data from a block chain storage, and executing signature verification and Hash consistency verification, thereby guaranteeing the authenticity and consistency of the data. And if the verification of the target link data is passed, verifying the inclusion relation of Merkle tree root hash of each link upwards layer by layer to confirm the integrity of the full-chain data. And if verification failure of any level is found, the feature data of the level is combined with an anomaly detection model based on an isolated forest algorithm, and an abnormal data node is positioned. And then, according to the signature information of the abnormal data node and the preset tracking secret key, a group signature verification and private key derivation process is applied, the responsibility participant is traced, and the tracing process of the carbon emission abnormity is completed, so that the problem that the carbon emission abnormal point cannot be accurately and efficiently traced in the prior art is effectively solved.

Description

Technical Field

[0001] This invention relates to the field of carbon emissions, and in particular to a method, apparatus, medium and equipment for tracing the source of carbon emission anomalies. Background Technology

[0002] As the global energy structure transitions towards a low-carbon model, the installed capacity of renewable energy is experiencing explosive growth. Simultaneously, carbon market mechanisms are also developing rapidly. Against this backdrop, accurate traceability of the carbon emission attributes of renewable energy has become a crucial foundation for achieving effective linkage between green electricity trading and the electricity carbon market.

[0003] However, currently, data on renewable energy, from production and transmission to consumption, is managed by different entities, posing a risk of data tampering, and the data at each stage lacks effective correlation. When tracing emissions across different levels, it is difficult to quickly locate data anomalies and clarify responsibilities, making it difficult to achieve a closed-loop logic for tracing carbon emission attributes across the entire chain. Furthermore, existing carbon emission attribute tracing technologies mainly revolve around data collection, storage, and verification involving multiple parties, but they suffer from the following problems: Centralized platform data management: Existing carbon emission tracing systems based on centralized platforms centrally manage data from various parties through a single organization (such as a power grid company), and achieve data querying and verification through permission allocation. This model suffers from problems such as data monopoly, susceptibility to tampering, and difficulties in cross-domain collaboration. Furthermore, identity management relies on a central server, making it difficult to balance security and anonymity.

[0004] Single-level data on-chain: Basic blockchain traceability solutions employ a single-level data on-chain approach, leveraging the distributed nature of blockchain for evidence storage. However, this approach lacks a hierarchical data association mechanism, resulting in isolated data across different stages and hindering end-to-end verification from production to consumption. Anomaly detection relies solely on simple threshold judgments, and identity tracing depends on publicly available identity information, making it difficult to balance privacy protection and regulatory requirements.

[0005] Data format disorder: The lack of a standardized hierarchical data collection mechanism has resulted in disordered data formats and missing core items at each stage. In addition, the use of a single-level evidence storage mode makes it impossible to achieve hierarchical anchoring, leading to a break in the correlation of data throughout the entire chain and making it impossible to verify the complete chain from production to consumption.

[0006] Insufficient anomaly detection and identity tracing: Anomaly detection relies solely on simple threshold judgments and lacks real-time analysis capabilities. Furthermore, identity tracing does not incorporate group signature and private key derivation technologies, resulting in delayed location of abnormal data and difficulty in anonymously tracing responsible parties. This fails to protect privacy and impacts regulatory efficiency.

[0007] Lack of data change history tracing: The absence of a process for linking and re-verifying the rectification data chain makes it impossible to trace the change history after abnormal data is corrected, making it difficult to restore consistency across the entire chain.

[0008] These shortcomings prevent existing technologies from accurately and efficiently tracing the sources of carbon emission anomalies. Summary of the Invention

[0009] This invention provides a method, apparatus, medium, and equipment for tracing the source of carbon emission anomalies, in order to solve the problem that existing technologies cannot accurately and efficiently trace the source of carbon emission anomalies.

[0010] Firstly, this application provides a method for tracing the source of carbon emission anomalies, including: Obtain a traceability request for the entire carbon emission data chain of renewable energy, wherein the traceability request includes the identifier of the data to be verified; Based on the data identifier to be verified, the target stage data is located from the pre-set blockchain-stored evidence data, and signature verification and hash consistency verification are performed on the target stage data; wherein, the evidence data is formed by each level of participant signing their own carbon emission data and processing it with a Merkle tree before putting it on the blockchain; If the target stage data is verified, the Merkle root hash corresponding to the target stage data is used as the starting point to verify the inclusion relationship of the Merkle root hash of each stage level by level upwards. If any level of verification fails, abnormal data nodes are detected based on the feature data of the level that failed verification, combined with the pre-set anomaly detection model trained based on the isolated forest algorithm. Based on the signature information of the abnormal data nodes and the preset tracking key, the source tracing results of the carbon emission anomalies are obtained through the group signature verification method and the preset private key derivation process.

[0011] This application obtains traceability requests and locates data at the target stage. By utilizing signature verification and hash consistency verification, the invention ensures the authenticity and consistency of data. Simultaneously, leveraging the immutability of blockchain, it provides a reliable foundation for data storage. Building upon this, the inclusion relationship of the Merkle tree root hash is verified layer by layer upwards, further ensuring the integrity and relevance of the entire chain of data and quickly identifying breakpoints in the data chain, thus effectively preventing data tampering. Once a level of verification failure is detected, an anomaly detection model trained using the isolated forest algorithm can accurately detect and locate abnormal data nodes, improving the accuracy and efficiency of anomaly detection. Furthermore, by tracing the identities of responsible participants through group signature verification and private key derivation processes, a balance is achieved between anonymity and regulatory requirements, protecting the privacy of participants. This combination of technologies not only improves the efficiency and accuracy of traceability but also provides reliable technical support for renewable energy carbon emission management. This application effectively solves the problem that existing technologies cannot accurately and efficiently trace carbon emission anomalies.

[0012] Furthermore, after obtaining the source tracing results of the carbon emission anomalies, the process also includes: The tracing results include basic tracing information, data layer verification results, hierarchical upward verification results, anomaly detection results, and identity tracing results; wherein, the anomaly detection results include the hash of the abnormal data node, the location of the tampering, and the characteristics of the tampering behavior; the identity tracing results include the decentralized identity identifiers of the participants, entity registration information, and the affiliation records of the abnormal data nodes; Based on the identity tracing results, the abnormal data node attribution record is associated with the decentralized identity identifier of the participating party, and combined with the signature submission record of the participating party for the data corresponding to the abnormal data node, the participating party is confirmed as the responsible party for the abnormal data node. The basic traceability information, data layer verification results, hierarchical upward verification results, and anomaly detection results are sent to the responsible party so that the responsible party can correct the abnormal data and output the corrected data. The corrected data is then subjected to signature verification, hash consistency verification, and hierarchical Merkle tree root hash inclusion relationship verification again.

[0013] After obtaining the source tracing results of the carbon emission anomalies, this application further ensured the completeness and accuracy of the tracing through detailed result analysis and responsibility confirmation processes. Specifically, the tracing results encompass basic tracing information, data layer verification results, hierarchical upward verification results, anomaly detection results, and identity tracing results. The anomaly detection results record in detail the hashes of the abnormal data nodes, the location of tampering, and the characteristics of the tampering behavior. The identity tracing results include the decentralized identity identifiers of the participants, entity registration information, and records of the anomalous data node ownership. Based on this information, by associating the participants' decentralized identity identifiers with the records of anomalous data node ownership, and combining this with the participants' signature submission records of the data corresponding to the anomalous data nodes, the responsible party can be accurately identified. Subsequently, the relevant tracing information is sent to the responsible party, prompting them to correct the abnormal data and output the corrected data. Finally, the corrected data undergoes rigorous signature verification, hash consistency verification, and hierarchical Merkle tree root hash inclusion relationship verification to ensure that the corrected data is authentic, valid, and consistent with the data across the entire chain. This series of interconnected steps not only enables accurate location of abnormal data and traceability of responsibility, but also ensures the effectiveness of data correction through a closed-loop verification mechanism, thereby significantly improving the reliability and credibility of carbon emission data traceability and providing solid technical support for carbon emission management.

[0014] Furthermore, the step of locating the target stage data from the pre-set blockchain-stored evidence data and performing signature verification and hash consistency verification on the target stage data specifically involves: Based on the data identifier to be verified, the evidence records that match the target stage are selected from the evidence storage data stored in the preset blockchain, and the data signature package of the target stage in the evidence records is extracted; wherein, the data signature package includes the original carbon emission data, the private key signature value of the participants, the timestamp, and the decentralized identity identifier of the participants; The public key corresponding to the decentralized identity of the participating party is retrieved from the blockchain, and the challenge value is calculated by concatenating the original carbon emission data and timestamp according to the Schnorr signature verification rules. Based on the challenge value, verify whether the private key signature value satisfies the preset discrete logarithm equation. If it does, confirm that the signature verification is successful. Based on the Merkle tree verification path of the target link in the evidence storage record, the hash value of the original carbon emission data is calculated using the SHA-256 hash algorithm. The hash value of the original carbon emission data is then aggregated layer by layer with the node hashes in the verification path to obtain the top-level hash value. If the top-level hash value is consistent with the root hash of the Merkle tree of the target link, the hash consistency verification is confirmed to be successful.

[0015] This application filters matching evidence records based on the identifiers of the data to be verified, extracting a data signature packet containing the original carbon emission data, private key signature value, timestamp, and decentralized identity identifiers of the participants. Next, it retrieves the participants' public keys, calculates challenge values ​​for the original data and timestamps using the Schnorr signature verification rules, and verifies whether the private key signature value conforms to the discrete logarithm equation, thereby confirming the validity of the signature. Furthermore, based on the Merkle tree verification path, it uses the SHA-256 hash algorithm to hash the original data, aggregating it layer by layer with the hashes of nodes in the path, and finally comparing the top-level hash value with the Merkle tree root hash to ensure data consistency. This series of rigorous verification processes not only ensures the authenticity and integrity of the data but also enhances the reliability and credibility of traceability through the immutability of blockchain technology, providing strong technical support for the accurate management and supervision of carbon emission data.

[0016] Furthermore, the step of verifying the inclusion relationship of the Merkle root hashes of each stage, starting from the Merkle root hash corresponding to the target stage data and proceeding upwards level by level, specifically involves: The Merkle tree root hash corresponding to the target stage data is concatenated with the target stage level identifier in the data to be verified to calculate the hash of the leaf node to be verified in the next level Merkle tree. Extract the Merkle tree root hash and the corresponding Merkle tree verification path from the evidence storage data stored on the blockchain. The hash of the leaf node to be verified is calculated layer by layer with the hashes of adjacent nodes in the Merkle tree verification path according to preset rules until the top-level aggregate hash is obtained. If the top-level aggregate hash is consistent with the Merkle tree root hash of the previous level, the hierarchical inclusion relationship is confirmed. The previous level is then used as the new target link, and the hierarchical inclusion relationship verification step is repeated.

[0017] This application ensures the integrity and consistency of the entire chain of data by verifying the inclusion relationship of the Merkle tree root hashes at each stage upwards. Specifically, firstly, the Merkle tree root hash corresponding to the target stage data is concatenated with the target stage level identifier to calculate the hash of the leaf node to be verified in the Merkle tree of the next level. Next, the Merkle tree root hash of the next level and the corresponding verification path are extracted from the blockchain storage. Then, using the hash of the leaf node to be verified and the hashes of adjacent nodes in the verification path, the parent node hash is calculated layer by layer according to preset rules until the top-level aggregate hash is obtained. If the top-level aggregate hash is consistent with the Merkle tree root hash of the next level, the inclusion relationship of that level is confirmed, and the next level is taken as the new target stage, and the verification steps are repeated. This process not only ensures the accuracy and integrity of the data at each level, but also enhances the credibility of the entire chain of data through the immutability of the blockchain, thus providing a solid technical foundation for the accurate traceability of renewable energy carbon emission data.

[0018] Furthermore, if any level of verification fails, based on the feature data of the level where verification failed, and combined with a pre-set anomaly detection model trained using the isolated forest algorithm, abnormal data nodes are detected, specifically as follows: Extract feature data of the verification failure level; the feature data includes the participant entity type, region identifier, power generation fluctuation value, and the correlation between the verification failure level and the Merkle tree root hash of the previous level; Calculate the carbon emission factor deviation of the verification failure level; The feature data and the carbon emission factor deviation are input into a preset anomaly detection model trained based on the isolated forest algorithm, so that the anomaly detection model can calculate anomaly scores. If the abnormal score is greater than a preset dynamic threshold, the feature data is marked as suspected abnormal data. Based on the suspected abnormal data, a recursive subtree hash comparison is performed between the verification failure level and the Merkle tree of the previous level. Starting from the root node, the subtree hash values ​​are compared level by level to locate the leaf node corresponding to the hash difference and confirm that the leaf node is an abnormal data node.

[0019] This application employs a series of meticulous steps to precisely locate anomalous data nodes when verification fails at any level, ensuring the accuracy and reliability of data tracing. Specifically, it first extracts key feature data from the verification failure level, including the type of participating entity, regional identifier, power generation fluctuation value, and the correlation between this level and the Merkle tree root hash of the previous level, and calculates the carbon emission factor deviation. This feature data provides comprehensive input for anomaly detection. Subsequently, this feature data and carbon emission factor deviation are input into an anomaly detection model pre-trained based on the isolated forest algorithm. This model assesses the degree of anomalousness of the data by calculating anomaly scores. If the anomaly score exceeds a preset dynamic threshold, the data is marked as suspected anomalous data. Finally, for suspected anomalous data, a recursive subtree hash comparison is performed between the verification failure level and the Merkle tree of the previous level. Starting from the root node, the subtree hash values ​​are compared layer by layer until the leaf node corresponding to the hash difference is located, thereby accurately confirming the anomalous data node. This process not only improves the accuracy of anomaly detection, but also ensures the precision of anomaly location through recursive comparison, providing a solid foundation for subsequent accountability and data correction, and significantly improving the efficiency and credibility of carbon emission data tracing.

[0020] Furthermore, based on the signature information of the abnormal data node and the preset tracking key, the source tracing result of the carbon emission anomaly is obtained through a group signature verification method and a preset private key derivation process, specifically as follows: The signature information corresponding to the abnormal data node is parsed to obtain the commitment value, response value, and challenge value in the signature information; Based on the preset tracking key, and combined with the commitment value, response value, and challenge value, the validity of the signature information is verified using a group signature verification method to obtain the signature verification result. If the signature validity verification passes, the private key characteristics of the participant corresponding to the abnormal data node are deduced according to the preset private key derivation process and based on the association between the preset tracking key and the signature information. Based on the private key characteristics, query the mapping relationship between the private key characteristics and the participant identities stored in the blockchain to obtain the corresponding participant identity information; By integrating the abnormal data nodes, signature verification results, and participant identity information, the source tracing results of carbon emission anomalies are obtained.

[0021] The signature verification and identity tracing process approved in this application effectively achieves accurate tracing of carbon emission anomalies. First, the signature information of the abnormal data nodes is parsed to extract key information such as commitment values, response values, and challenge values. Next, using a pre-set tracking key and these values, the validity of the signature is confirmed through a group signature verification method, thus ensuring the authenticity and reliability of the signature information. If the signature verification passes, the private key characteristics of the participants are further derived based on a pre-set private key derivation process and the correlation between the tracking key and the signature information. Then, by querying the mapping relationship between private key characteristics and participant identities stored in the blockchain, the identity information of the corresponding participants is accurately obtained. Finally, the abnormal data nodes, signature verification results, and participant identity information are integrated to form a complete carbon emission anomaly tracing result. This coherent process not only ensures the accurate identification of abnormal data but also guarantees the reliable tracing of identity information through blockchain technology, greatly improving the transparency and regulatory efficiency of carbon emission data management and providing strong technical support for achieving precise carbon emission regulation.

[0022] Secondly, this application provides a device for tracing the source of carbon emission anomalies. The device for tracing the source of carbon emission anomalies includes: The acquisition module is used to acquire traceability requests for the entire carbon emission data chain of renewable energy, wherein the traceability requests include data identifiers to be verified; The first verification module is used to locate the target stage data from the pre-set blockchain-stored evidence data according to the data identifier to be verified, and to perform signature verification and hash consistency verification on the target stage data; wherein, the evidence data is formed by each level of participants signing their own carbon emission data and processing it with a Merkle tree before putting it on the blockchain. The second verification module is used to verify the inclusion relationship of the Merkle root hash of each stage by taking the Merkle root hash corresponding to the target stage data as the starting point and moving upwards level by level if the target stage data is verified. The detection module is used to detect abnormal data nodes based on the feature data of the failed level and a pre-set anomaly detection model trained on the isolated forest algorithm if any level of verification fails. The tracing module is used to obtain the tracing results of carbon emission anomalies based on the signature information of the abnormal data nodes and the preset tracking key, through a group signature verification method and a preset private key derivation process.

[0023] The carbon emission anomaly tracing device of this application, through modular design, achieves fully automated processing from obtaining the tracing request to finally obtaining the tracing result. First, the acquisition module receives the tracing request containing the identifier of the data to be verified, providing a clear target for subsequent verification. Next, the first verification module locates the target data from the blockchain-stored data based on the identifier and performs signature verification and hash consistency verification to ensure the authenticity and consistency of the data. If the target data verification passes, the second verification module uses the Merkle root hash corresponding to the target data as a starting point and verifies the inclusion relationship of the Merkle root hashes of each stage upwards, further ensuring the integrity and relevance of the entire chain of data. If any level of verification fails, the detection module, based on the feature data of that level and combined with a pre-set anomaly detection model based on the isolated forest algorithm, accurately detects the abnormal data node. Finally, the tracing module uses the signature information of the abnormal data node and a pre-set tracking key to trace back to the responsible party through group signature verification and private key derivation processes, obtaining the tracing result of the carbon emission anomaly. This modular design not only improves the efficiency and accuracy of traceability, but also enhances the credibility and security of data through blockchain technology, providing strong technical support for the precise management and supervision of carbon emission data, and effectively promoting energy transition and sustainable development.

[0024] Furthermore, after obtaining the source tracing results of the carbon emission anomalies, the process also includes: The tracing results include basic tracing information, data layer verification results, hierarchical upward verification results, anomaly detection results, and identity tracing results; wherein, the anomaly detection results include the hash of the abnormal data node, the location of the tampering, and the characteristics of the tampering behavior; the identity tracing results include the decentralized identity identifiers of the participants, entity registration information, and the affiliation records of the abnormal data nodes; Based on the identity tracing results, the abnormal data node attribution record is associated with the decentralized identity identifier of the participating party, and combined with the signature submission record of the participating party for the data corresponding to the abnormal data node, the participating party is confirmed as the responsible party for the abnormal data node. The basic traceability information, data layer verification results, hierarchical upward verification results, and anomaly detection results are sent to the responsible party so that the responsible party can correct the abnormal data and output the corrected data. The corrected data is then subjected to signature verification, hash consistency verification, and hierarchical Merkle tree root hash inclusion relationship verification again.

[0025] After obtaining the source tracing results of carbon emission anomalies, this application ensured the integrity and validity of the results through a series of coherent steps, and promoted closed-loop management of data correction and verification. First, the source tracing results encompass basic source tracing information, data-level verification results, hierarchical upward verification results, anomaly detection results, and identity tracing results. The anomaly detection results record in detail the hashes of the abnormal data nodes, the location of tampering, and the characteristics of the tampering behavior. The identity tracing results include the decentralized identity identifiers of the participating parties, entity registration information, and records of the anomalous data node ownership. Based on this information, by associating the participating parties' decentralized identity identifiers with the records of anomalous data node ownership, and combining this with the participating parties' signature submission records of the data corresponding to the anomalous data nodes, the responsible party can be accurately identified. Subsequently, the relevant source tracing information is sent to the responsible party, prompting them to correct the abnormal data and output the corrected data. Finally, the corrected data undergoes rigorous signature verification, hash consistency verification, and hierarchical Merkle tree root hash inclusion relationship verification to ensure that the corrected data is authentic, valid, and consistent with the data across the entire chain.

[0026] Thirdly, this application provides a computer-readable storage medium comprising a stored computer program, wherein, when the computer program is executed, it controls the device containing the computer-readable storage medium to perform a carbon emission anomaly tracing method as described above. Its beneficial effects are the same as those of the carbon emission anomaly tracing method provided in the first aspect of this application.

[0027] Fourthly, this application provides a terminal device including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein the processor executes the computer program to implement any of the carbon emission anomaly tracing methods described in the first aspect. Attached Figure Description

[0028] Figure 1 A schematic flowchart of an embodiment of the carbon emission anomaly tracing method provided in this application; Figure 2 A schematic diagram of an embodiment of the hierarchical Merkle tree provided in this application; Figure 3 A schematic diagram of an embodiment of the Merkle tree consistency verification process provided in this application; Figure 4 A schematic diagram of an embodiment of the multi-level tracing mechanism architecture provided in this application; Figure 5 A schematic diagram of an embodiment of the multi-level traceability mechanism provided in this application; Figure 6This is a schematic diagram of one embodiment of the carbon emission anomaly tracing device provided in this application. Detailed Implementation

[0029] 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 embodiments of the present invention, and not all embodiments. 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.

[0030] Example 1 Please refer to Figure 1 In order to solve the problem that existing technologies cannot accurately and efficiently trace the source of carbon emission anomalies, this invention provides a method for tracing the source of carbon emission anomalies, including steps S01-S05.

[0031] Before implementing the method and process of this application, a series of initializations and identity system establishments are required, specifically: 1. Participant identity registration and DID allocation: (1) Determine the scope of participants: renewable energy power plants (photovoltaic / wind power, etc.) under the State Grid Corporation of China, regional power grid companies, carbon emission monitoring agencies, regulatory authorities, and electricity users; (2) Participant registration process: Participants enter their system private key on the identity authentication server. Participants verify private keys The identity authentication server will verify the private keys of the participating parties. The data is stored in a list and sent securely to regulatory agencies. When tracing identities, the calculation results are compared with the participants' verification private keys to determine their identities. (3) DID generation rules: Each participant generates a unique DID (decentralized identity identifier) ​​through the blockchain node, which includes the participant's ID in different management domains and the management domain public key. Identity information such as attribute credentials and operation behavior records; (4) Identity mapping table establishment: Use smart contracts to create a unified identity information mapping table to store the association between DID and the ID, domain public key and attribute credentials of each participant in different management domains, so as to realize cross-domain identity association.

[0032] 2. Key system configuration: (1) Key generation process: Input security parameters into the identity authentication server The system master key pair of the identity authentication server is output using the elliptic curve cryptography algorithm. Tracking Key Group public key Participant verification key pair To meet the authentication requirements of multiple participants in power traceability, the NIST-recommended secp256r1 curve was selected. It is internationally recognized and offers high security. Its parameters are shown in Table 1. The system master key pair of the identity authentication server Tracking Key Group public key Participant verification key pair The specific calculation formula for the generation process is as follows: Among them, the system master private key It is a random number within the elliptic curve domain. For elliptic curve generators, This is for scalar multiplication of elliptic curves. This is the bitwise XOR operator. As a participant The aggregate weight of the public key, As a participant public key, The number of participants. To trace the key generation function, This is a function for generating public keys for a group. For key derivation functions, ensure and Strong associations enhance security; (2) Each participant generates a public-private key pair: the private key is stored locally (for data signing), and the public key is written into the DID and uploaded to the blockchain; (3) The regulatory agency holds the tracking key: used for identity tracing in abnormal situations, ensuring a balance between anonymity and regulatory controllability; (4) The participants and the regulatory authorities jointly hold the group public key: The participants obtain the group public key and store it locally for generating and verifying the group signature; the regulatory authorities simultaneously write the group public key into the blockchain for evidence storage to ensure that it can be retrieved on the chain during subsequent signature verification, and at the same time trace the real identity through the group public key. Furthermore, the data stratification criteria of this application are shown in Table 2 below: Table 2 Data Hierarchy Information Table Furthermore, the specific process of data on-chaining and Merkle tree construction is as follows: (1) Data collection and signing: After collecting data in the standard format, the data producers at each level verify their private keys. The data is signed to generate a data signature packet (original data + private key signature value + timestamp + DID). The signing process follows the Schnorr algorithm, with specific parameters and implementation details as follows: ① Schnorr signatures rely on the Discrete Logarithm Problem (DLP) for construction and require the following global parameters to be predefined: a. Generator : Selecting a finite field Generators: Fundamental points of the elliptic curve group, satisfying The order of is a large prime number, which serves as the basic public key generation factor for Schnorr signatures, ensuring the mathematical security of the signature.

[0033] b. Finite field parameters Choose a 2048-bit prime number, define the modulus for discrete logarithm operations, and restrict the private key. Temporary numbers The range of values .

[0034] ② The signature process consists of four steps: "temporary number generation → commitment calculation → challenge generation → response signature", as detailed below: Temporary key generation: The data producer randomly selects a temporary private key. Calculate the corresponding public commitments: in It is a one-time random number, which is regenerated each time a signature is made, ensuring that the signature is unpredictable. It is a public commitment, used in the "hidden temporary number" stage of zero-knowledge proofs.

[0035] Challenge value calculation: data splicing timestamp , Calculate the hash value as the challenge value : in yes Hash function, guarantees and Strong binding; It is the "verification anchor" of the signature, associated with the commitment. With business data .

[0036] Response signature generation: using the private key With challenge value Calculate response value : in This is the core output of the signature, bound to a temporary number. Private key Challenge Value The final signature value is: The data signature packet is obtained .

[0037] (2) Leaf node generation: Calculate the hash value (SHA-256) of the data signature packet and use it as the leaf node of the corresponding level of the Merkle tree. Let the first... One data signature packet is Its hash value is: The hashes of all leaf nodes form a set. ,in This represents the number of data generators at this level.

[0038] (3) Construction of hierarchical Merkle tree: Each level generates a parent node according to the "pairwise hash aggregation" rule until the Merkle root hash of that level is calculated.

[0039] Suppose a certain level has leaf nodes, if If the number is odd, then an empty hash is added (e.g., ...). To make the total even, recursively aggregate: Parent node generation rule: Hash the two adjacent leaf nodes The parent node hash is: Root hash calculation: Repeatedly aggregate parent nodes until only one root hash remains. ,Right now: The leaf nodes of the upper-level Merkle tree contain the root hash and data signature packet of the lower level, achieving "inter-level anchoring". Let the lower-level root hash be... Its data signature packet is Then the hash of the upper-level leaf node is: A diagram illustrating the construction of a hierarchical Merkle tree is shown below. Figure 2 As shown; (4) On-chain storage of root hash and data signature package: The root hash of each level and the corresponding data signature package are written to the blockchain through smart contracts, and on-chain transaction hashes are generated. This creates an immutable record of evidence. The State Grid regulatory node synchronizes the on-chain data in real time for subsequent auditing. The evidence storage logic can be represented as: After completing system initialization, identity system construction, data layering standard definition, data on-chaining, and Merkle tree construction, the abnormal source tracing process for carbon emission data across the entire renewable energy chain can be initiated, specifically including the following steps S01 to S05.

[0040] S01: Obtain a traceability request for the entire carbon emission data chain of renewable energy, wherein the traceability request includes the data identifier to be verified.

[0041] In a preferred embodiment of this invention, the step of obtaining a traceability request for the carbon emission data chain of the entire renewable energy chain includes a data identifier to be verified, specifically: In this embodiment, the "renewable energy full-chain carbon emission data chain" specifically covers the complete data flow links of renewable energy from production to consumption, including power generation and unit carbon emission factor data of the production layer (such as wind power and photovoltaic power plants), transmission loss and grid loss carbon emission conversion data of the transmission layer (such as regional power grid companies), multi-regional data integration and total carbon emission statistics of the aggregation layer (such as dispatch centers), and electricity consumption and carbon emission allocation data corresponding to electricity consumption type of the consumption layer (such as industrial users and residential users). The data of each link forms a coherent data chain in the order of "production → transmission → aggregation → consumption". The traceability request is initiated for any link of data in the data chain that may have anomalies. The entities initiating traceability requests can include renewable energy carbon emission regulatory agencies (such as carbon emission monitoring centers under the energy authorities), various participants in the data chain (such as power plants needing to verify whether their data has been tampered with, or power grid companies needing to verify the consistency between transmitted data and power plant data), or third-party auditing institutions (commissioned to verify the authenticity of carbon emission data across the entire chain). Initiation can be completed through a client deployed in the blockchain traceability system. For example, regulatory agencies can submit request instructions through the system backend, and participating parties can log in to the system with their own accounts and select the "Data Traceability" function module to initiate the request. The core "data to be verified identifier" is a unique identification information used to accurately locate the data to be traced. Its composition must meet the technical requirements of subsequent "locating target link data" and "extracting hierarchical identifiers." Specifically, it includes four key pieces of information: First, a link type identifier, using a preset code (e.g., "SC" for production layer, "CS" for transmission layer, "JH" for aggregation layer, and "XF" for consumption layer), used to directly pinpoint the link in the chain to which the data to be verified belongs; second, a time range identifier, using the format "YYYYMMDD - YYYYMMDD" to mark the corresponding time interval of the data (e.g., "20240501 - 20240531" represents data from May 2024), avoiding data confusion across time dimensions; third, a unique code for each participant, assigning a unique code to each data generation participant (e.g., power plant A is coded as "DL - 001", power grid company B as "WD - 001"). 003”, used to associate the main body of data generation; fourth, data item coding, setting codes for different types of carbon emission data (such as “GF” representing power generation, “PF” representing carbon emission factor, and “SL” representing transmission loss), clarifying the specific data item to be verified. For example, a complete data identifier to be verified can be represented as “SC - 20240501 - 20240531 - DL - 001 - GF”, which represents “power generation data of power plant A in May 2024”; the specific business form of the data identifier to be verified (such as “the data identifier to be verified can correspond to the power transaction number, production data ID, transmission dispatch instruction code, etc., to ensure that the starting link (such as power plant production) to the target link (such as user consumption) of the target data chain can be accurately associated”). When initiating a traceability request, the system needs to retrieve three types of core evidence storage data from the blockchain in advance: ① Merkle tree root hashes at each level, ② data signature package sets, and ③ Merkle tree verification paths, to provide basic data support for subsequent data layer verification and upward verification. When the traceability system receives the traceability request, it will first parse the information in each part of the data identifier to be verified, so as to provide a basis for subsequent "locating the target link data from the blockchain evidence data according to the identifier" and "extracting the target link level identifier for hash concatenation", ensuring that the traceability process is accurate from the data positioning stage and avoiding positioning deviation or invalid verification due to missing identifier information.

[0042] S02: Based on the data identifier to be verified, locate the target stage data from the pre-set blockchain-stored evidence data, and perform signature verification and hash consistency verification on the target stage data; wherein, the evidence data is formed by each level of participant signing their own carbon emission data and processing it with a Merkle tree before putting it on the blockchain.

[0043] In a preferred embodiment of this example, the step of locating the target stage data from the pre-defined blockchain-stored evidence data based on the data identifier to be verified, and performing signature verification and hash consistency verification on the target stage data, specifically involves: In this embodiment, it is necessary to first clarify the generation logic of the "evidence data". It is formed by the participants at each level (renewable energy power plants in the production layer, power grid companies in the transmission layer, dispatch centers in the aggregation layer, and electricity users in the consumption layer) processing their own carbon emission data according to the "data layering standard" and then putting it on the chain: Each participant first collects core data items (such as power plants collecting power generation and carbon emission factors, and power grid companies collecting transmission loss rates), and then uses the participant's private key stored locally to sign the core data, timestamp, and their own DID (decentralized identity identifier), forming a data signature package containing "original carbon emission data + participant's private key signature value + timestamp + participant's DID"; then, according to preset rules, multiple data signature packages at this level are constructed into a Merkle tree (taking the production layer as an example, the signature package corresponding to the daily power generation data of the same power plant in May is used as the leaf node, and the parent node hash is calculated layer by layer until the root hash is generated), and finally, "data signature package + Merkle tree structure + Merkle tree root hash ... The "Merkle tree verification path" serves as complete evidence storage data, which is written to a pre-defined blockchain system (such as a consortium blockchain, which can only be read and written by authorized participants) through blockchain nodes, ensuring that the evidence storage data is immutable and traceable. When the system receives a tracing request containing a "data identifier to be verified", it first locates the target process data based on the identifier. The data identifier to be verified includes "process type code (e.g., 'SC' represents the production layer, 'CS' represents the transmission layer) + time range (e.g., '20240501-20240531') + participant code (e.g., 'DL-001' represents a photovoltaic power plant) + data item code (e.g., 'GF' represents power generation)". After parsing the identifier, the system filters the blockchain evidence data for "process type matching the code, time range falling within the identifier range, participant code matching, and signature packet corresponding to the data item code". For example, after parsing the identifier "SC-20240501-20240531-DL-001-GF", the system filters out the evidence record corresponding to the power generation data of the DL-001 power plant in the production layer in May 2024, and extracts the original information and data signature packet of the power generation data, thus completing the location of the "target process data". After locating the target data, perform signature verification and hash consistency verification sequentially: The system first retrieves the public key of the participant corresponding to the 'Participant DID' in the target stage data signature packet from the participant identity mapping table stored on the blockchain. This mapping table is created by a smart contract during the system initialization phase and is used to store the association between the participant DID and the public key. The participant's public key has been written into the DID and uploaded to the blockchain during identity registration. Then, according to the Schnorr signature verification rules, the original carbon emission data and timestamp are concatenated into a string, and the challenge value is calculated using a preset hash algorithm (such as SHA-256). Next, the participant's public key, the challenge value, and the private key signature value in the data signature packet are substituted into a preset discrete logarithm equation (such as "private key signature value = (challenge value × participant's private key + random number) mod base point order", where the random number is obtained from the signature packet and the base point order is referenced from the "base point order" parameter of the secp256r1 curve in Table 1 above). If the equation holds, the signature verification is confirmed to be successful, proving that the target stage data was indeed generated by the participant and has not been tampered with. If the equation does not hold, the target stage data is directly determined to be abnormal, and subsequent verification is terminated. Furthermore, the signature verification specifically includes: Use the DID public key of the target layer responsible entity Verify signature Follow Schnorr signature verification rules: (1) (1) Parsing the signature Extract public commitment and response value ; (2) splicing Target data timestamp , Calculate the challenge value : (3) Verify the discrete logarithm equation: If the equation is true, the signature is valid; otherwise, the signature is invalid.

[0044] After signature verification is successful, the system extracts the "Merkle tree verification path" corresponding to the target stage data from the blockchain evidence storage data (this path is generated synchronously when the participants at each level construct the Merkle tree and is uploaded to the blockchain along with the evidence storage data to ensure traceability for subsequent verification). First, the system uses the SHA-256 hash algorithm to calculate the hash value of the original carbon emission data of the target stage, and uses this hash value as the hash of the leaf node to be verified. Then, according to the Merkle tree verification path order, the hash of the leaf node to be verified is concatenated with the hash of the first adjacent node in the path according to the preset rule of "left hash + right hash" to calculate the hash of the parent node. The above operation is repeated with the hash of the next adjacent node in the path, and the process is aggregated layer by layer until the top-level hash value is obtained. Finally, the top-level hash value is compared with the "target stage Merkle tree root hash" recorded in the evidence storage data. If the two are consistent, the hash consistency verification is confirmed to be successful, proving that the target stage data has not been replaced or tampered with in the Merkle tree. If they are inconsistent, the Merkle tree structure corresponding to the target stage data is determined to be abnormal, and the abnormality detection stage needs to be entered later. Furthermore, the Merkle tree hash consistency verification specifically involves: Validation path based on the target layer Merkle tree Calculate the hash of the data to be verified. And verify whether it belongs to the target layer root hash. : in This function validates Merkle tree members. If it returns True, the data belongs to the current level; otherwise, it does not.

[0045] S03: If the target stage data is verified, starting from the Merkle root hash corresponding to the target stage data, verify the inclusion relationship of the Merkle root hash of each stage level by level upwards.

[0046] In a preferred embodiment of this example, if the target stage data verification passes, the inclusion relationship of the Merkle root hashes of each stage is verified level by level, starting from the Merkle root hash corresponding to the target stage data. Specifically: In this embodiment, the "data verification of the target stage is passed" requires a clear premise: the signature verification (confirming that the data was generated by the corresponding participant and has not been tampered with) and hash consistency verification (confirming that the data has not been replaced in its own Merkle tree) of the target stage data have been completed in the previous text. At this time, it is necessary to further verify the Merkle tree root hash inclusion relationship by "verifying the data level by level" to ensure the correlation and integrity of the target stage data with the data of the upper stage in the carbon emission data chain of the entire renewable energy chain, and to avoid the chain break caused by the tampering of the upper stage data. In this embodiment, the order of 'hierarchical upward verification' is set according to the data layering standard mentioned above, that is, it progresses from the target link to the aggregation level upstream of the chain (e.g., when the target link is the production layer, the order is production layer → transmission layer → aggregation layer; when the target link is the transmission layer, the order is transmission layer → aggregation layer), ensuring that the entire related link of data from generation to aggregation is covered; The specific operation of "verifying inclusion relationships level by level" is illustrated by the example of "the target stage being the production layer and verifying the transmission layer upwards". The steps are as follows: Generate the leaf node hash to be verified: First, extract the Merkle root hash (denoted as H1) corresponding to the data of the target stage (production layer). Then, extract the target stage level identifier (production layer code "SC") from the "data identifier to be verified" in the traceability request. Concatenate the two according to a preset format (such as "level identifier + root hash") to obtain the string "SC+H1". Calculate the hash value of this string using the SHA-256 hash algorithm, denoted as H1'. This H1' is the leaf node hash of the "corresponding production layer data" in the Merkle tree of the next level (transport layer). Since the leaf node of the transport layer Merkle tree is essentially the result of processing the Merkle root hash of all production layer stages under its jurisdiction, the association anchor point between the two levels of data can be established through this concatenation calculation. Extracting upper-layer evidence data: From the evidence data stored in the blockchain, filter the evidence records corresponding to the upper-level (transport layer), and extract the "transport layer Merkle tree root hash (denoted as H2)" and the "transport layer Merkle tree verification path" (this path records the hashes of all adjacent nodes from the leaf node to the root node of H1' in the transport layer Merkle tree, and is stored together with the transport layer data when it is uploaded to the blockchain). Layer-by-layer aggregation calculation and inclusion relationship determination: The hash H1' of the leaf node to be verified is concatenated with the hash of the first adjacent node in the Merkle tree verification path of the transport layer (denoted as H-neighbor 1) according to the preset rule of "left hash first, right hash last", and the parent node hash H-parent 1 is calculated; then H-parent 1 is concatenated with the hash of the next adjacent node in the verification path (denoted as H-neighbor 2) and the parent node hash calculation operation is repeated, and the aggregation is carried out layer by layer until the top-level aggregated hash (denoted as H2') is obtained. At this time, H2' is compared with the extracted transport layer Merkle tree root hash H2; if H2'=H2, it proves that the root hash of the target link (production layer) has been effectively included in the transport layer Merkle tree, the data of the two levels are completely associated, and the inclusion relationship is established; if H2'≠H2, it proves that the transport layer Merkle tree data has been tampered with (such as H2 being replaced), the verification of the level (transport layer) fails, and the subsequent anomaly detection process needs to be triggered; If a certain level of verification passes (e.g., production layer → transport layer verification is successful), then the upper-level link (transport layer) is taken as the new "target link," and the above 3 steps are repeated to continue verifying upwards (e.g., transport layer → aggregation layer) until all upstream level verifications are completed; if all level verifications pass, it can be confirmed that the target link data is completely associated with the upper-level data in the entire chain and has not been tampered with, thus achieving full-chain data integrity verification; Furthermore, the hierarchical upward verification in this embodiment specifically involves: Target layer root hash As the next level The leaf node of the Merkle tree is used to verify whether it belongs to the upper-level root hash. This is to confirm the consistency of data within the region.

[0047] If it belongs to the upper-level root hash: If the verification passes, it means "the current layer" → Previous Floor The data transmission process of “” satisfies: and yes Merkle tree leaf nodes, with tamper-proof data, indicate that the data at the current level is part of the data chain at the previous level, conforming to the end-to-end logic of "production → transmission → aggregation → consumption". Based on this foundation, we can continue to verify higher layers to ensure a closed-loop traceability logic throughout the entire chain.

[0048] If it does not belong to the upper-level root hash: If it does not belong to the root hash of the upper layer, it means that the data in the current layer (or the data in the previous layer) may have been tampered with or replaced, resulting in the destruction of the correlation between the two layers of data. Output a failure flag for upward verification. This triggers anomaly detection and identity tracing processes.

[0049] S04: If any level of verification fails, based on the feature data of the level that failed verification, combined with the pre-set anomaly detection model trained based on the isolated forest algorithm, anomaly data nodes are detected.

[0050] In a preferred embodiment of this invention, if any level of verification fails, abnormal data nodes are detected based on the feature data of the failed level and a preset anomaly detection model trained using the isolated forest algorithm. Specifically: First, feature data of the verification failure level (transmission layer) is extracted from the blockchain evidence storage data and the participant identity mapping table: the participant entity type is retrieved from the DID association attribute of the identity mapping table, the regional identifier is extracted from the participant filing information in the evidence storage data, the power generation fluctuation value is calculated by the transmission layer core data item (transmission power generation) and the historical average value of the same period, the hierarchical correlation degree is measured by the XOR operation of the Merkle root hash of the transmission layer and the aggregation layer, and at the same time, the deviation between the actual carbon emission factor of the transmission layer and the industry benchmark value is calculated to obtain the carbon emission factor deviation degree. Feature data input and anomaly score calculation: The extracted transmission layer feature data (participant entity type "Regional Power Grid Company", regional identifier "North China Region", power generation fluctuation value "+8%", hierarchical correlation degree "0.3") and carbon emission factor deviation degree "+12%) are converted according to the preset format (numerical feature normalization, categorical feature encoding) and input into the anomaly detection model. The model traverses 100 isolated trees, counts the path length of the data isolated to the leaf node, and calculates an anomaly score of 0.82. This score is higher than the preset dynamic threshold of 0.7. Therefore, the transmission layer data corresponding to this set of feature data is marked as "suspected anomaly data".

[0051] Merkle tree recursive comparison for locating anomalous nodes: Based on suspected anomalous data, the complete Merkle tree structure (including the hash values ​​of all nodes) of the verification failure level (transmission layer) and its upper level (aggregation layer) is extracted from the blockchain evidence data. Recursive subtree hash comparison is then performed: First, the root node hashes of the two Merkle trees are compared (confirmed to be inconsistent). Then, the transmission layer Merkle tree is split into left and right subtrees, and the root hash of each subtree is calculated and compared with the corresponding subtree hash of the aggregation layer Merkle tree to locate the right subtree with inconsistent hashes. The right subtree is recursively split and the subtree hash comparison operation is repeated until the leaf node level of the Merkle tree is reached. It is found that the hash value of a certain leaf node (corresponding to a certain power loss record in the transmission layer) is completely inconsistent with the hash value of the corresponding leaf node in the aggregation layer Merkle tree. This leaf node is the "abnormal data node", and the associated power loss record in the transmission layer is the tampered data. This completes the accurate location of the anomalous data node and provides a clear data object for subsequent identity tracing. Furthermore, the process for detecting abnormal data points in this embodiment is as follows: 1. Upward validation failure flag ; 2. Static features ,in For entity type, For regional identification; 3. Dynamic characteristics ,in For power generation fluctuation value, This represents the deviation of carbon emission factors. For data reporting frequency; The calculation formula is: in The carbon emission factor for the current layer of data. As the baseline carbon emission factor, The carbon emission factor is the "mean absolute error" of historical normal data. Minimum value To avoid the denominator being 0.

[0052] 4. Association Features ,in The correlation between the current layer and the Merkle root hash of the upper layer is calculated using the following formula: in The root hash of the current Merkle tree. For the root hash of the upper Merkle tree, For set Jaccard similarity, For the Merkle leaf node to root hash A set of hash paths.

[0053] The total eigenvector is: ; Furthermore, the isolated forest algorithm in this embodiment is specifically as follows: (1) Offline training: Construct the training set using historical normal data. ( (Number of normal samples) and an isolated tree forest constructed using the isolated forest algorithm. Each tree Randomly select features to segment the data until all samples are isolated.

[0054] (2) Online updates: Real-time collected normal data is continuously input into the model, and the isolated tree forest is updated through incremental learning: in, The tree update function inserts new samples into the forest and adjusts the segmentation logic; The anomaly score calculation in this embodiment is as follows: (1) Path length calculation: Real-time data samples Given a forest of isolated trees, calculate the path length in each tree. This refers to the number of edges from the root node to the leaf node.

[0055] (2) Derivation of outlier scores: Based on path length expectation and sample size Corresponding path length constant Abnormal scores (Range 0 ~ 1) is defined as: in, Let be the expected value of the path length of the sample in the forest. The sample size is The path length constant at that time. The closer the value is to 1, the more abnormal the data is.

[0056] From the upper tree and the current layer tree Starting from the root node, recursively compare the hashes of the left and right subtrees to process the tree. nodes Its left subtree hash is The hash of the right subtree is Comparison rules: If the hashes of a certain subtree do not match, continue drilling down that branch until a leaf node with a hash difference is found. If the tampering occurred in the current level's leaf node, then the hash of this leaf node is recorded. and its location Complete the location of abnormal data, such as Figure 3 As shown.

[0057] S05: Based on the signature information of the abnormal data node and the preset tracking key, the source tracing result of the carbon emission anomaly is obtained through the group signature verification method and the preset private key derivation process.

[0058] In a preferred embodiment of this invention, the process of obtaining the source tracing result of carbon emission anomalies based on the signature information of the abnormal data nodes and a preset tracking key, through a group signature verification method and a preset private key derivation process, specifically involves: In this embodiment, before conducting carbon emission anomaly tracing, it is necessary to clarify the sources of two types of core information: First, the signature information of the abnormal data node, which needs to be extracted from the abnormal data node association records stored on the blockchain. This information includes the group signature data submitted by the participants when the abnormal data is generated (specifically including the commitment value, response value, and challenge value), the decentralized identity identifier (DID) associated with the participant bound to the abnormal data node, and the timestamp when the signature is generated. All of the above information is stored on the blockchain synchronously with the original data of the abnormal data node to ensure that the source of the information is traceable and tamper-proof. Second, the pre-set tracking key, which is generated by the identity authentication server based on the secp256r1 elliptic curve algorithm. After generation, it is delivered to the regulatory agency for exclusive holding, which can realize identity tracing without disclosing the privacy of the participants.

[0059] Group signature verification must be performed according to a preset process: First, the commitment value (denoted as C), response value (denoted as R), and challenge value (denoted as e) in the signature information of abnormal data nodes are parsed. Simultaneously, the group public key is retrieved from the blockchain (participants obtain the group public key and store it locally; regulatory agencies simultaneously write the group public key into the blockchain for notarization, ensuring that participants can retrieve it at any time when generating / verifying group signatures, and regulatory agencies can also trace the true identity through the on-chain group public key); then, the preset tracking key, group public key, C, R, and e are substituted into the preset group signature verification equation (constructed based on the discrete logarithmic properties of the secp256r1 curve, the equation form is "R×G = C + The formula is: e×PK_group, where G is the elliptic curve generator, PK_group is the group public key, "×" represents elliptic curve scalar multiplication, and "+" represents elliptic curve point addition. If the equation holds true after substituting the formula, it can be confirmed that the group signature was generated by all legitimate participants in the chain and there is no forgery; the signature verification is successful. If the equation does not hold true, the signature is determined to be forged, and further verification of the on-chain logs of abnormal data nodes (including data submission IP address and submission timestamp) is required to rule out anomalies caused by external attacks. Private key derivation must proceed step by step according to a preset process to ensure accurate and compliant identity tracing: First, based on the verified group signature information and the preset tracking key, the preset key derivation function (denoted as KDF, which is strongly associated with the secp256r1 algorithm, and whose parameters include the preset tracking key and the commitment value C in the signature information) is called to deduce the private key characteristics of the participant corresponding to the abnormal data node (this characteristic is a fragment of the private key information, such as the first 64 bits of the private key hash value, which can both meet the identity matching requirements and avoid privacy and security issues caused by the leakage of the complete private key); Second, from the smart contract identity mapping table deployed on the blockchain (this mapping table is created during the system initialization phase to store the association relationship of "private key characteristics - DID - entity filing information"), the complete record corresponding to the above private key characteristics is queried to obtain the participant's DID code, entity name (such as "North China Regional Power Grid Company XX Branch"), industry qualification number, data submission permission scope and other identity information, thereby confirming that the participant is the party responsible for generating the abnormal data; The final carbon emission anomaly tracing results need to integrate key information from multiple dimensions to form a complete conclusion. Specific integrated content includes the basic information of the anomaly data nodes (their layer, such as the transmission layer; node hash value, such as "0x8a7f2c9d3e5b1a4f6h8j0k7l9m3n5p"; corresponding core data items, such as "transmission loss rate data on May 15, 2024"), group signature verification results (including the judgment conclusion of "signature valid" or "signature forged" and the derivation process of the verification equation), the identity information of the responsible party (including DID code, entity registration information, and scope of responsibility for data submission), and the tampering characteristics of the anomaly data (such as a comparison of hash values ​​before and after data modification, and the timestamp corresponding to the tampering operation). The integrated tracing results need to be simultaneously written to the blockchain for notarization to ensure the tracing process is auditable, and pushed to regulatory agencies and responsible parties to provide a clear basis for subsequent anomaly data rectification. Furthermore, in this embodiment, the identity tracing process is specifically as follows: First, the output of the anomaly detection section includes: 1. Abnormal data leaf node hash : The unique identifier for locating anomalous data in the Merkle tree; 2. Location of the leaf node containing the abnormal data : Mark the hierarchical path of anomalous data in the Merkle tree; 3. Abnormal data signature package : Core credentials linking abnormal data to the responsible party; 4. Tracking Key : Generated by the identity authentication server for identity tracing; 5. Signature of the participant's attribute certificate Schnorr group signature, format is ; 6. Group public key : Distributed by the identity authentication server for signature verification; 7. System Public Key : The public key of the identity authentication server master key pair, used for attribute credential verification; 8. Original text of attribute certificate : Raw data containing user attributes; 9. Algorithm parameters: generators finite field parameters These are all publicly available parameters of the Schnorr signature algorithm.

[0060] Next, proceed to the verification process: 1. Signature validity pre-validation: The regulatory body first verifies the entered signature ( Does it conform to the group signature specification? Using the group public key ( ) and system public key ( ), execute the Schnorr group signature verification algorithm: (1) Group signature structure parsing: Will According to the Schnorr group signature algorithm specification, it is divided into sub-components. in For the hash challenge (challenge value) used in zero-knowledge proofs; The result (response value) of the computation involving the private key; The commitment (commitment value) for the attribute credential hash.

[0061] (2) Attribute credential hash calculation: Original text of calculated attribute voucher Hash value: (3) Zero-knowledge proof verification: Using group public key Verify the validity of the zero-knowledge proof for the signature: a. Based on generator and discrete logarithmic parameter Calculate the commitment value Corresponding public commitments: b. Calculate the challenge value Expected value: c. Verify the response value Does it satisfy the Schnorr signature equation? If the equation is true, the signature conforms to the group signature specification; otherwise, it is considered an invalid signature.

[0062] (4) Output results: a. If the verification passes, output "Signature valid".

[0063] b. If verification fails, output "Invalid signature".

[0064] Ensure through group signature verification algorithm If the group signature is valid, interference from forged signatures will be excluded; if the verification fails, proceed directly to the in-depth verification section; if the verification passes, proceed to the next step.

[0065] Based on the reversibility of the Schnorr group signature algorithm, the tracking key is designed ( ) and user verification private key ( The eigenvalues ​​exhibit the following correlations: Group signature ( The generation process of ) can be represented as: in This is the group signature generation function for the Schnoor algorithm. For attribute credential hash, From the original text of the attribute certificate calculate: Tracking key ( )yes The inverse function key can be obtained from the inverse operation. Extract eigenvalues : The Schnoor group signature algorithm can derive the complete private key from the eigenvalues: The core formula for Schnorr signatures is: in , It is a generator. It is the commitment value. For the message, For attribute credential hash, For hash functions, It's a challenge value. It is the response value.

[0066] according to The derivation process for the form (discrete logarithmic exponent / hash partition) is divided into two categories: ①①Derivation based on the discrete logarithmic exponent: like It is the exponential component in the discrete logarithm problem, deriving the complete private key. Steps: Get public parameters: Obtaining public parameters from the blockchain: Generator Finite field parameters Challenge value in group signature Commitment value .

[0067] Constructing discrete logarithmic equations: Using the Schnorr signature formula, construct the equation: in Available from Derivation (or from) (Analysis in Chinese) It is possible Solving using discrete logarithms yields: .

[0068] Private key decryption: Solving the deformation equations : in yes In a finite field The multiplicative inverse in the equation satisfies .

[0069] ②②Derivation based on hash partitioning: like It involves hashing and sharding the private key to derive the complete private key. Steps: Segmentation and Reorganization: Regulatory authorities query other fragments of the private key hash from the unified identity information mapping table and reconstruct the complete hash. ): in This is a fragment reassembly function that merges the hash fragments into a complete private key hash.

[0070] Private key matching: The reorganized Hash( Match the private key hashes with the list of private key hashes stored on the identity authentication server to find the corresponding complete private key. : in For private key hash-private key mapping table, For lookup functions.

[0071] This process ensures that, in anomaly tracing, the complete private key can be restored through feature values, and the security and compliance of the process can be guaranteed by relying on cryptographic algorithms, making it fully compatible with the identity tracing needs of electricity carbon emission tracing.

[0072] By comparing private keys, identity can be traced: (1) During the registration process, the participants store the verification private key in a list and send it to the regulatory agency.

[0073] (2) The regulatory agency performs a SHA-256 hash operation on the verification private key to generate the private key hash.

[0074] (3) Regulatory agencies can use smart contracts to access the unified identity information mapping table, using the private key hash as an index, to query the associated DID and entity information. This allows them to trace the true identities of the participants.

[0075] Further, a more in-depth investigation will be conducted: Retrieve the historical interaction records of this data chain from the blockchain evidence storage, and focus on verifying them: (1) Device fingerprint consistency verification: Device fingerprint From the terminal (recorded as) ), Encryption module serial number Hash generation after concatenation: Historical signatures Storing evidence on the blockchain and verifying consistency: like This indicates that the signature generation device matches the historical records, ruling out the risk of terminal identifier tampering. If If so, the device fingerprint is determined to be abnormal.

[0076] (2) IP source tracing and attribution verification: Query the network IP address at the time of signature submission (denoted as...). ), combined with operator logs to trace the organization to which the IP belongs , with entity information Registered organizations in contrast: like This indicates that the IP address used to submit the signature matches the registered organization of the participating party, thus eliminating the risk of IP forgery. If so, the IP address is deemed to be abnormal.

[0077] (3) Operation log anomaly detection: retrieve the on-chain operation log of the participant's DID. It is a time series record, and its format is: Each log Includes operation type ,in The abnormal behavior determination function is: in, The function is: like If so, it is determined that there is an abnormal operation.

[0078] Based on the above information, combined with manual screening, the true identities of the participants who forged group signatures were identified.

[0079] The identity verification algorithm successfully authenticated the participants, and the following results were output: 1. Basic identity information: DID, entity type, real name, and associated business / industry filing information; 2. Attribute credential association information: qualification certificates, business records, and exception associations; 3. Identity tracing evidence chain: private key hash, group signature verification log, and tracking key call records; The regulatory node generates an anomaly rectification work order, which includes the anomaly level, anomaly data hash, tampering timestamp, responsible party's DID, and identity tracing evidence chain. The work order is then pushed to the responsible party via a smart contract, requiring them to submit correct data and supporting documentation, explaining the reason for the invalid signature / data tampering.

[0080] To prevent secondary errors, the data submitted by the responsible parties must first undergo local compliance verification: 1. Format verification: Complies with power data standards; 2. Business logic validation: No conflicts with data in the upper or lower levels; 3. Signature re-signing: Regenerate the data signature package using the currently valid private key to ensure compliance with format and content requirements.

[0081] After making the modifications, the responsible party submits the revised data signature package to the blockchain and receives the revised on-chain transaction hash. The smart contract marks the data as "corrected data" and associates it with the original abnormal data hash to facilitate tracing the change history.

[0082] Through anomaly detection and identity tracing, the anomalous data is corrected, allowing for continued source tracing and verification. Starting from the anomaly level, the "multi-level source tracing and verification" process is re-executed, forming a complete source tracing chain: in For target layer data, For the upper-level root hash, For the higher-level root hash, This is the raw data for the initial layer.

[0083] Generate a source tracing report, including the following: 1. Basic traceability information: Source Request Identifier: A unique business identifier for the data to be verified (such as an electricity transaction number); The entire data chain path: the flow of data through the production layer → transmission layer → aggregation layer → consumption layer; Source tracing trigger requirement: The business motivation for initiating source tracing (such as verifying the authenticity of data); Overall traceability status: End-to-end verification completed / Anomaly rectification in progress / Anomaly rectification completed; 2. Data layer validation results: Target-level responsible entities: DID and roles (e.g., electricity sales company); Signature validity: Passed / Failed DID public key verification; Data hash: The hash value of the target layer data; Target layer root hash: The root hash value of the Merkle tree in the target layer; Consistency determination: Whether the data hash belongs to the root hash of the target layer; 3. Validate results hierarchically upwards: Hierarchical chain: Target layer → Transport layer → Aggregation layer → Production layer verification hierarchy chain; Root hash association: Determines whether the current root hash contains the root hash of the next lower level, level by level; Anomaly Trigger Flag: Whether anomaly detection is triggered (Yes / No); Exception level (if any): The specific level at which exception detection is triggered; 4. Anomaly detection results: Characteristics of anomalous data: hash, timestamp, and tampering characteristics of anomalous data; Results of the Isolation Forest algorithm: results of outlier detection; Merkle tree verification: the path connectivity of outlier data in the Merkle tree at each level; Tampering level identification: Identify the specific level at which data tampering occurred; 5. Identity tracing results: Input parameters: tracking key, attribute credential signature, group public key, system public key; Signature pre-verification: Is it a valid group signature (yes / no); Basic identity of the responsible party; DID: Decentralized Identity Identifier; Entity type: Power plant / Grid company / Testing agency / User; Real name and filing information; Attribute credential association: Carbon emission qualification number and validity period; Historical business record hash index (data reporting, cross-domain protocols, etc.); Index of violation records (if any); Tracing the chain of evidence: Private key hash matching record; Group signature verification logs and compliance results; Track the key call timestamps and parameters; In-depth verification results (if required): Device fingerprint consistency: Comparison results of signature device identifier; IP attribution: IP ownership information submitted with the signature; Operation Log: Records of abnormal on-chain operations for DID; 6. Rectification Results (if any abnormalities are found): Responsible party's response status: Submitted / Not submitted rectification data; Rectification data verification: Format validation: Does it conform to power data standards? Business logic validation: Whether it conflicts with data in the upper and lower levels; Signature re-signature verification: Is the new signature compliant? Correcting data upload to the blockchain: Whether the data upload was successful; Re-verification results: Recovery status of root hash correlation at each level; 7. Overall Conclusion: Data link full path attributes: Untampered / Corrected / Anomaly present; Cross-domain verification results (if applicable): cross-domain root hash consistency and trust status; Overall traceability conclusions: Reliability of data across the entire supply chain and results of tracing the responsible parties; Closed-loop status: Final determination of end-to-end data integrity (restored to normal / requires further processing); The entire process of tracing the source of carbon emission anomalies in this application is as follows: Figure 4As shown, the process first involves "system initialization and identity system construction" to complete participant registration, DID generation, identity mapping, and key configuration; then, through "data collection and Merkle tree storage," Merkle trees are constructed and uploaded to the blockchain after data collection at each level of production, transmission, aggregation, and consumption; finally, "multi-level traceability verification" is performed, which combines the identifier and attributes of the data to be verified to first verify the consistency of the data signature and hash, and then verify the root hash inclusion relationship level by level. If there is a mismatch, anomaly detection and identity tracing are triggered, and finally, a traceability report is output. like Figure 5 As shown, Figure 5 The document presents a complete process for tracing the source of carbon emission anomalies: starting with "identity system construction" (including participant registration, DID generation, identity mapping table establishment, and key configuration), proceeding through "data layering" (production, transmission, aggregation, and consumption layers), "data collection and signing," "hierarchical Merkle tree construction," and "on-chain evidence storage," it first conducts "data layer verification" (signature validity and Merkle tree hash consistency verification), and then "hierarchical upward verification." If the data belongs to the upper-level root hash, it continues to verify to higher levels, ultimately forming a complete traceability chain and outputting a traceability report; if it does not belong, it calculates anomaly scores and determines anomalies through "feature extraction" and "isolated forest model training," locates the abnormal data through Merkle tree consistency determination, and parses the signature packet to verify validity (if the verification is successful, the Schnorr algorithm is used to derive the private key to trace the real identity and push the responsible participant to correct the data; if the verification fails, in-depth verification such as device fingerprinting, IP tracing, and operation logs is carried out before tracing the identity), ultimately forming a traceability chain and outputting a traceability report.

[0084] In summary, this embodiment, by acquiring traceability requests and locating data at the target stage, utilizes signature verification and hash consistency verification to ensure the authenticity and consistency of data. Simultaneously, leveraging the immutability of blockchain, it provides a reliable foundation for data storage. Building upon this, the inclusion relationship of the Merkle tree root hash is verified layer by layer upwards, further ensuring the integrity and relevance of the entire chain of data and quickly identifying breakpoints in the data chain, thereby effectively preventing data tampering. Once a level of verification failure is detected, the anomaly detection model trained using the isolated forest algorithm can accurately detect and locate abnormal data nodes, improving the accuracy and efficiency of anomaly detection. Furthermore, by tracing the identities of responsible participants through group signature verification and private key derivation processes, a balance is achieved between anonymity and regulatory requirements, protecting the privacy of participants. This combination of technologies not only improves the efficiency and accuracy of traceability but also provides reliable technical support for renewable energy carbon emission management. This application effectively solves the problem that existing technologies cannot accurately and efficiently trace carbon emission anomalies.

[0085] Example 2 Please refer to Figure 6 This is a carbon emission anomaly tracing device provided in the embodiments of this application.

[0086] In this embodiment, the carbon emission anomaly tracing device includes an acquisition module 10, a first verification module 20, a second verification module 30, a detection module 40, and a tracing module 50.

[0087] The acquisition module 10 is used to acquire a traceability request for the carbon emission data chain of the entire renewable energy chain, and the traceability request includes the data identifier to be verified.

[0088] The first verification module 20 is used to locate the target stage data from the pre-set blockchain-stored evidence data according to the data identifier to be verified, and to perform signature verification and hash consistency verification on the target stage data; wherein, the evidence data is formed by each level of participants signing their own carbon emission data and processing it with a Merkle tree before putting it on the blockchain.

[0089] The second verification module 30 is used to verify the inclusion relationship of the Merkle root hashes of each stage by taking the Merkle root hash corresponding to the target stage data as the starting point and moving upwards level by level if the target stage data is verified.

[0090] The detection module 40 is used to detect abnormal data nodes based on the feature data of the failed level and a preset anomaly detection model trained on the isolated forest algorithm if any level of verification fails.

[0091] The tracing module 50 is used to obtain the tracing result of carbon emission anomalies based on the signature information of the abnormal data nodes and the preset tracking key, through a group signature verification method and a preset private key derivation process.

[0092] For ease of description and brevity, the embodiments of the device of the present invention include all the implementation methods in the above-described methods for tracing the source of abnormal carbon emissions, and will not be repeated here.

[0093] Example 3: This application provides a computer-readable storage medium including a stored computer program, wherein the computer program, when running, controls the device where the computer-readable storage medium is located to execute the aforementioned method for tracing the source of carbon emission anomalies. The carbon emission anomaly tracing method, if implemented as a software functional unit and used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.

[0094] Example 4 This embodiment provides a terminal device, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor. When the processor executes the computer program, it implements any one of the carbon emission anomaly tracing methods as described in Embodiment 1.

[0095] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. In particular, it should be noted that any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention for those skilled in the art.

Claims

1. A method for tracing the source of carbon emission anomalies, characterized in that, include: Obtain a traceability request for the entire carbon emission data chain of renewable energy, wherein the traceability request includes the identifier of the data to be verified; Based on the data identifier to be verified, the target stage data is located from the pre-set blockchain-stored evidence data, and signature verification and hash consistency verification are performed on the target stage data; wherein, the evidence data is formed by each level of participant signing their own carbon emission data and processing it with a Merkle tree before putting it on the blockchain; If the target stage data is verified, the Merkle root hash corresponding to the target stage data is used as the starting point to verify the inclusion relationship of the Merkle root hash of each stage level by level upwards. If any level of verification fails, abnormal data nodes are detected based on the feature data of the level that failed verification, combined with the pre-set anomaly detection model trained based on the isolated forest algorithm. Based on the signature information of the abnormal data nodes and the preset tracking key, the source tracing results of the carbon emission anomalies are obtained through the group signature verification method and the preset private key derivation process.

2. The method for tracing the source of carbon emission anomalies according to claim 1, characterized in that, After obtaining the source tracing results of the carbon emission anomalies, the process also includes: The tracing results include basic tracing information, data layer verification results, hierarchical upward verification results, anomaly detection results, and identity tracing results; wherein, the anomaly detection results include the hash of the abnormal data node, the location of the tampering, and the characteristics of the tampering behavior; the identity tracing results include the decentralized identity identifiers of the participants, entity registration information, and the affiliation records of the abnormal data nodes; Based on the identity tracing results, the abnormal data node attribution record is associated with the decentralized identity identifier of the participating party, and combined with the signature submission record of the participating party for the data corresponding to the abnormal data node, the participating party is confirmed as the responsible party for the abnormal data node. The basic traceability information, data layer verification results, hierarchical upward verification results, and anomaly detection results are sent to the responsible party so that the responsible party can correct the abnormal data and output the corrected data. The corrected data is then subjected to signature verification, hash consistency verification, and hierarchical Merkle tree root hash inclusion relationship verification again.

3. The method for tracing the source of carbon emission anomalies according to claim 1, characterized in that, The step of locating the target stage data from the pre-stored evidence data in the blockchain and performing signature verification and hash consistency verification on the target stage data specifically involves: Based on the data identifier to be verified, the evidence records that match the target stage are selected from the evidence storage data stored in the preset blockchain, and the data signature package of the target stage in the evidence records is extracted; wherein, the data signature package includes the original carbon emission data, the private key signature value of the participants, the timestamp, and the decentralized identity identifier of the participants; The public key corresponding to the decentralized identity of the participating party is retrieved from the blockchain, and the challenge value is calculated by concatenating the original carbon emission data and timestamp according to the Schnorr signature verification rules. Based on the challenge value, verify whether the private key signature value satisfies the preset discrete logarithm equation. If it does, confirm that the signature verification is successful. Based on the Merkle tree verification path of the target link in the evidence storage record, the hash value of the original carbon emission data is calculated using the SHA-256 hash algorithm. The hash value of the original carbon emission data is then aggregated layer by layer with the node hashes in the verification path to obtain the top-level hash value. If the top-level hash value is consistent with the root hash of the Merkle tree of the target link, the hash consistency verification is confirmed to be successful.

4. The method for tracing the source of carbon emission anomalies according to claim 1, characterized in that, Starting with the Merkle root hash corresponding to the target stage data, the inclusion relationship of the Merkle root hashes of each stage is verified level by level upwards, specifically as follows: The Merkle tree root hash corresponding to the target stage data is concatenated with the target stage level identifier in the data to be verified to calculate the hash of the leaf node to be verified in the next level Merkle tree. Extract the Merkle tree root hash and the corresponding Merkle tree verification path from the evidence storage data stored on the blockchain. The hash of the leaf node to be verified is calculated layer by layer with the hashes of adjacent nodes in the Merkle tree verification path according to preset rules until the top-level aggregate hash is obtained. If the top-level aggregate hash is consistent with the Merkle tree root hash of the previous level, the hierarchical inclusion relationship is confirmed. The previous level is then used as the new target link, and the hierarchical inclusion relationship verification step is repeated.

5. The method for tracing the source of carbon emission anomalies according to claim 1, characterized in that, If any level of verification fails, based on the feature data of the level where verification failed, and combined with a pre-set anomaly detection model trained using the isolated forest algorithm, abnormal data nodes are detected, specifically as follows: Extract feature data of the verification failure level; the feature data includes the participant entity type, region identifier, power generation fluctuation value, and the correlation between the verification failure level and the Merkle tree root hash of the previous level; Calculate the carbon emission factor deviation of the verification failure level; The feature data and the carbon emission factor deviation are input into a preset anomaly detection model trained based on the isolated forest algorithm, so that the anomaly detection model can calculate anomaly scores. If the abnormal score is greater than a preset dynamic threshold, the feature data is marked as suspected abnormal data. Based on the suspected abnormal data, a recursive subtree hash comparison is performed between the verification failure level and the Merkle tree of the previous level. Starting from the root node, the subtree hash values ​​are compared level by level to locate the leaf node corresponding to the hash difference and confirm that the leaf node is an abnormal data node.

6. The method for tracing the source of carbon emission anomalies according to claim 1, characterized in that, The process of obtaining the source tracing result of carbon emission anomalies based on the signature information of the abnormal data nodes and the preset tracking key, through a group signature verification method and a preset private key derivation process, is as follows: The signature information corresponding to the abnormal data node is parsed to obtain the commitment value, response value, and challenge value in the signature information; Based on the preset tracking key, and combined with the commitment value, response value, and challenge value, the validity of the signature information is verified using a group signature verification method to obtain the signature verification result. If the signature validity verification passes, the private key characteristics of the participant corresponding to the abnormal data node are deduced according to the preset private key derivation process and based on the association between the preset tracking key and the signature information. Based on the private key characteristics, query the mapping relationship between the private key characteristics and the participant identities stored in the blockchain to obtain the corresponding participant identity information; By integrating the abnormal data nodes, signature verification results, and participant identity information, the source tracing results of carbon emission anomalies are obtained.

7. A device for tracing the source of abnormal carbon emissions, characterized in that, include: The acquisition module is used to acquire traceability requests for the entire carbon emission data chain of renewable energy, wherein the traceability requests include data identifiers to be verified; The first verification module is used to locate the target stage data from the pre-set blockchain-stored evidence data according to the data identifier to be verified, and to perform signature verification and hash consistency verification on the target stage data; wherein, the evidence data is formed by each level of participants signing their own carbon emission data and processing it with a Merkle tree before putting it on the blockchain. The second verification module is used to verify the inclusion relationship of the Merkle root hash of each stage by taking the Merkle root hash corresponding to the target stage data as the starting point and moving upwards level by level if the target stage data is verified. The detection module is used to detect abnormal data nodes based on the feature data of the failed level and a pre-set anomaly detection model trained on the isolated forest algorithm if any level of verification fails. The tracing module is used to obtain the tracing results of carbon emission anomalies based on the signature information of the abnormal data nodes and the preset tracking key, through a group signature verification method and a preset private key derivation process.

8. The carbon emission anomaly tracing device according to claim 7, characterized in that, After obtaining the source tracing results of the carbon emission anomalies, the process also includes: The tracing results include basic tracing information, data layer verification results, hierarchical upward verification results, anomaly detection results, and identity tracing results; wherein, the anomaly detection results include the hash of the abnormal data node, the location of the tampering, and the characteristics of the tampering behavior; the identity tracing results include the decentralized identity identifiers of the participants, entity registration information, and the affiliation records of the abnormal data nodes; Based on the identity tracing results, the abnormal data node attribution record is associated with the decentralized identity identifier of the participating party, and combined with the signature submission record of the participating party for the data corresponding to the abnormal data node, the participating party is confirmed as the responsible party for the abnormal data node. The basic traceability information, data layer verification results, hierarchical upward verification results, and anomaly detection results are sent to the responsible party so that the responsible party can correct the abnormal data and output the corrected data. The corrected data is then subjected to signature verification, hash consistency verification, and hierarchical Merkle tree root hash inclusion relationship verification again.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored computer program, wherein, when the computer program is executed, it controls the device on which the computer-readable storage medium is located to perform the carbon emission anomaly tracing method as described in any one of claims 1 to 6.

10. A terminal device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein the processor executes the computer program to implement the method for tracing carbon emission anomalies as described in any one of claims 1 to 6.

Images