Power marketing data cross-domain sharing management method and system based on smart contract

Abstract

The invention provides a power marketing data cross-domain sharing management method and system based on a smart contract, and the method comprises the steps: building an encryption channel through key negotiation, carrying out the encryption packaging of power marketing data, and constructing a traceability graph; deploying an intelligent contract containing traceability query and responsibility positioning logic to the block chain network; when traceability is needed, extracting an operation record and reversely traversing the traceability graph; when objection occurs, data consistency is verified through privacy calculation, and responsibility division is dynamically adjusted. According to the invention, safe sharing, whole-course traceability and justice responsibility determination of power marketing data are realized.

Description

Technical Field

[0001] This invention belongs to the field of blockchain, and specifically relates to a method and system for cross-domain sharing and management of electricity marketing data based on smart contracts. Background Technology

[0002] With the development of smart grids and the energy internet, electricity marketing data has become a crucial strategic resource for power companies. Existing cross-domain sharing management technologies for electricity marketing data lack effective data traceability mechanisms, making it difficult to track data flow paths and operational records during the sharing process. When electricity marketing data is transferred and processed among multiple entities, it is difficult to accurately pinpoint the source and responsible party if data anomalies or quality issues are discovered, leading to difficulties in clarifying data quality responsibility. The data sharing model suffers from insufficient security, making data vulnerable to theft or tampering during cross-domain transmission. Traditional data encryption methods often focus only on transmission layer security, neglecting the integrity protection of the entire data lifecycle, resulting in difficulty in tracking data fingerprints and tracing data changes, thus failing to form a complete data responsibility chain. Regarding data responsibility dispute resolution, existing technologies lack objective and impartial arbitration mechanisms. When parties involved in data sharing disagree on data quality responsibility, the lack of credible technical means to verify the authenticity of each party's claims often necessitates manual negotiation or administrative measures, which are inefficient and unconvincing, especially when protecting the data privacy of all parties, making responsibility determination even more complex. Summary of the Invention

[0003] To address the shortcomings of existing technologies, this invention provides a method and system for cross-domain sharing and management of electricity marketing data based on smart contracts, in order to solve problems such as difficulty in data traceability and complexity in liability determination.

[0004] To solve the above-mentioned technical problems, the present invention adopts the following technical solution.

[0005] This invention first discloses a method for cross-domain sharing and management of electricity marketing data based on smart contracts, the method comprising the following steps: An encrypted communication channel is established between multiple participating nodes in cross-domain data sharing through key negotiation. The acquired electricity marketing data is encrypted and encapsulated, and a traceability map is constructed. An operation record containing the identity signature of the operation subject and the data fingerprint is generated for each operation node. A smart contract containing traceability query logic and responsibility location logic is generated based on the traceability graph and deployed to the blockchain network. The operation records are written into the blockchain network to form a traceability chain. When it is necessary to trace the source of target data, the associated operation records are extracted from the traceability chain, the signature is verified, and the traceability graph is traversed in reverse to obtain the traceability path. The operation nodes in the traceability path are judged according to the responsibility division rules. When data anomalies are detected, the traceability location is performed by comparing the data fingerprint and the responsibility location result is generated. When an operator raises an objection to the responsibility allocation result, the consistency between the input data received by the objecting party and the upstream delivered data is verified through privacy computation. If the verification result shows that the input data was abnormal when it was received, the responsibility tracing process is triggered to dynamically adjust the responsibility allocation, generate a corrected result, and write it into the blockchain network.

[0006] The present invention further includes the following preferred embodiments: The process of encrypting and encapsulating the acquired electricity marketing data and constructing a traceability graph, generating an operation record for each operation node that includes the operator's identity signature and data fingerprint, further includes: Extract the operation subject identifier, operation type and data content from the power marketing data, and associate the data fingerprint of the current operation node with the data fingerprint of the previous operation node in a hash chain to form a data dependency relationship between nodes; A source graph is constructed based on the data dependencies. The source graph has operation nodes as vertices and data flow directions as directed edges. On each directed edge, the data fingerprint delivered by the source node and the data fingerprint received by the target node are recorded simultaneously. An operation record is generated for each operation node. The operation record includes the identity signature of the operation subject, the data fingerprint of the current node and the data fingerprint of the previous node. The operation record is digitally signed by the operation subject's private key and then encrypted and encapsulated. The encrypted and encapsulated operation record is associated with the corresponding node in the traceability graph and stored. The data fingerprint in the operation record is cross-validated with the data fingerprint recorded on the directed edge, which is used to determine the location of the data anomaly during subsequent traceability by comparison.

[0007] The step of generating a smart contract containing traceability query logic and responsibility location logic based on the traceability graph and deploying it to the blockchain network, and writing the operation records into the blockchain network to form a traceability chain, further includes: The directed edge relationships and data fingerprint associations between nodes are extracted from the source graph. The directed edge relationships are mapped to the path traversal rules of the source query logic, and the data fingerprint associations are mapped to the fingerprint comparison rules of the responsibility location logic. The source tracing query logic is generated according to the path traversal rules. The source tracing query logic receives the target data identifier and traverses the directed edges of the source tracing graph in reverse to obtain the source tracing path containing the sequence of all operation nodes. Responsibility location logic is generated according to the fingerprint comparison rules. The responsibility location logic receives the tracing path and compares the data fingerprint delivered by the source node with the data fingerprint received by the target node for each directed edge in the tracing path. When the two data fingerprints are inconsistent, the target node of the directed edge is marked as the responsible node. The source tracing query logic and the responsibility location logic are encapsulated into a smart contract and deployed to the blockchain network. The operation records are written into the blockchain according to the time sequence of the source tracing graph to form a source tracing chain, so that the smart contract can perform source tracing query and responsibility location by calling the operation records in the source tracing chain.

[0008] When it is necessary to trace the source of target data, the process of extracting associated operation records from the tracing chain, verifying the signature, and then traversing the tracing graph in reverse to obtain the tracing path further includes: Based on the identifier of the target data, retrieve the operation record containing the identifier of the target data from the traceability chain as the starting operation record; Extract the identity signature and data fingerprint of the operating subject from the starting operation record, verify the identity signature using the public key of the operating subject, and compare and verify the data fingerprint in the starting operation record with the data fingerprint received by the target node recorded on the corresponding directed edge in the traceability graph. When the identity signature verification is successful and the two data fingerprints are consistent, mark the starting operation record as a valid record. Based on the preceding node data fingerprint contained in the starting operation record, the preceding operation record is retrieved from the tracing chain. Identity signature verification and data fingerprint comparison verification are performed on the retrieved preceding operation record. When the verification is successful and the data fingerprint is consistent, the preceding operation record is marked as a valid record. The preceding node data fingerprint in the preceding operation record is extracted to continue the forward retrieval. The retrieval and verification process is repeated until the source operation record is reached. All verified operation records between the source operation record and the starting operation record are organized in time sequence to form a tracing path containing a complete sequence of operation nodes.

[0009] The step of determining the responsibility type for operation nodes in the tracing path based on responsibility division rules, and performing tracing and location by comparing data fingerprints when data anomalies are detected, and generating responsibility location results, further includes: Extract the operation type and data processing permission of each operation node from the traceability path. Determine the responsibility type of the operation node in the data flow process based on the combination relationship between the operation type and the data processing permission and the position of the operation node in the traceability diagram. The responsibility type includes data generation responsibility, data transmission responsibility, and data reception responsibility. Traverse the operation nodes in the tracing path, extract the data fingerprints recorded on the directed edges corresponding to each operation node, the data fingerprints delivered by the source node and the data fingerprints received by the target node, and compare them. When the comparison results are inconsistent, it is determined that a data anomaly has occurred. For directed edges where data anomalies occur, the target node of the directed edge is marked as an anomaly node, and the responsibility type of the anomaly node is extracted from the source tracing path. Based on the responsibility type of the anomaly node and the location of the directed edge where the data fingerprint is inconsistent, the location where the data anomaly was introduced is determined, and the responsibility is assigned. The node identifier of the abnormal node, the responsibility type of the abnormal node, and the organization to which the responsibility belongs are used to generate a responsibility location result.

[0010] When an operator objects to the responsibility allocation result, privacy computation is used to verify the consistency between the input data received by the objecting party and the upstream delivered data. If the verification result indicates that the input data was abnormal upon receipt, the responsibility tracing process is triggered to dynamically adjust the responsibility allocation, generate a corrected result, and write it into the blockchain network. This further includes: Based on the node identifier in the objection request, locate the objecting node and its predecessor node from the tracing path as upstream nodes; homomorphically encrypt the data stored locally by the objecting node and the upstream node and upload them to the verification environment; calculate and compare the ciphertext hash value in the ciphertext state; when the ciphertext hash value is inconsistent, it is confirmed that the data has changed during the transmission process. Extract the data fingerprint recorded on the directed edge corresponding to the objecting node from the tracing path, and compare it with the plaintext hash value of the objecting party's local data. When the two are consistent, combine the result of the inconsistent ciphertext hash value to confirm that the input data has an anomaly when it is received. Trigger the responsibility tracing process, re-execute data fingerprint comparison and responsibility type judgment for the sequence from upstream node to source node, and redetermine the responsibility attribution node; organize the responsibility attribution node identifier, responsibility adjustment basis and verification results to generate a correction result, and call the objecting node, upstream node and verification node to digitally sign the correction result to generate a three-party signature; When the three-party signature verification is successful, the correction result carrying the three-party signature is written into the blockchain, updating the responsibility positioning record in the traceability chain.

[0011] The step of invoking the objecting node, upstream node, and verification node to digitally sign the correction result to generate a three-party signature further includes: The original text of the correction result is formed by organizing the responsibility attribution node identifier, the basis for responsibility adjustment, and the verification results, and then performing hash calculation on the original text of the correction result to generate a summary of the correction result; The dissenting node extracts the verification result portion from the original text of the corrected result, verifies its consistency with the local record, and then uses its private key to sign the digest of the corrected result to generate the dissenting node's signature. The upstream node extracts the delivery data fingerprint from the original text of the correction result, verifies its consistency with the local data hash value, and then uses its private key to sign the digest of the correction result to generate the upstream node signature. The verification node extracts the verification process record and re-executes the verification steps. After the verification result is consistent, it uses its private key to sign the corrected result digest to generate a verification node signature. The three signatures are combined and bound to the original text of the correction result to generate a correction result carrying the three signatures.

[0012] This invention also discloses a smart contract-based cross-domain sharing management system for electricity marketing data, utilizing the aforementioned smart contract-based cross-domain sharing management method, comprising: The key negotiation and data preparation unit is used to establish an encrypted communication channel between multiple participating nodes in cross-domain data sharing through key negotiation, encrypt and encapsulate the acquired power marketing data and construct a traceability map, and generate an operation record containing the identity signature of the operation subject and the data fingerprint for each operation node. The contract deployment unit is used to generate a smart contract containing traceability query logic and responsibility location logic based on the traceability graph and deploy it to the blockchain network, and write the operation record into the blockchain network to form a traceability chain; The source tracing and responsibility location unit is used to extract associated operation records from the source tracing chain when it is necessary to trace the source of target data, verify the signature, and then traverse the source tracing graph in reverse to obtain the source tracing path. The unit determines the responsibility type of the operation nodes in the source tracing path based on the responsibility division rules. When data anomalies are detected, the unit performs traceability and location by comparing data fingerprints and generates responsibility location results. The correction unit is used to verify the consistency between the input data received by the objecting party and the upstream delivered data through privacy computation when the operating entity raises an objection to the responsibility positioning result. If the verification result shows that the input data was abnormal when it was received, the responsibility tracing process is triggered to dynamically adjust the responsibility division, generate a correction result and write it into the blockchain network.

[0013] Accordingly, this application also discloses a terminal, including a processor and a storage medium; The storage medium is used to store instructions; The processor is configured to operate according to the instructions to execute the steps of the aforementioned smart contract-based cross-domain sharing management method for electricity marketing data.

[0014] Accordingly, this application also discloses a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the aforementioned smart contract-based cross-domain sharing management method for electricity marketing data.

[0015] The beneficial effects of this invention are as follows: Compared with existing technologies, this invention provides a method and system for cross-domain sharing and management of electricity marketing data based on smart contracts. It achieves secure sharing and accountability for electricity marketing data through blockchain and smart contract technologies, establishing a two-layer traceability system combining a data traceability graph and a traceability chain. This system accurately records the entire data flow process and ensures the immutability of records, effectively solving problems such as difficulty in data traceability and ambiguity in accountability determination in traditional methods. The accountability allocation mechanism, combined with the automatic execution characteristics of smart contracts, makes the accountability traceability process more objective and fair. When data anomalies occur, the responsible party can be quickly located. Simultaneously, data consistency verification is performed through privacy computing technology, avoiding misjudgment of accountability, protecting the legitimate rights and interests of all participants, and improving the transparency and credibility of electricity marketing data management. This invention achieves traceable management of the entire lifecycle of electricity marketing data. Key negotiation and encrypted communication ensure the security of the data sharing process, data fingerprint technology ensures data integrity, and the dynamic accountability adjustment mechanism improves the flexibility and accuracy of accountability traceability. Overall, it promotes the standardized management and efficient utilization of electricity marketing data. Attached Figure Description

[0016] Figure 1 This is a flowchart of the smart contract-based cross-domain sharing management method for electricity marketing data in this invention; Figure 2 This is a flowchart of the dynamic adjustment process for handling objections to electricity marketing data and tracing responsibility in this invention. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0018] The embodiments described in this application are merely some, not all, embodiments of the present invention. Based on the spirit of the present invention, other embodiments obtained by those skilled in the art without inventive effort are all within the protection scope of the present invention.

[0019] To address the shortcomings of existing technologies, this invention proposes a method and system for cross-domain sharing and management of electricity marketing data based on smart contracts. (See [link to relevant documentation]). Figure 1 As shown, the present invention discloses a method for cross-domain sharing and management of electricity marketing data based on smart contracts, which includes the following steps: Step 1: Establish an encrypted communication channel between multiple participating nodes in cross-domain data sharing through key negotiation, encrypt and encapsulate the acquired electricity marketing data and construct a traceability graph, and generate an operation record containing the identity signature and data fingerprint of the operation subject for each operation node.

[0020] Step 2: Generate a smart contract containing traceability query logic and responsibility location logic based on the traceability graph and deploy it to the blockchain network. Write the operation record into the blockchain network to form a traceability chain.

[0021] Step 3: When it is necessary to trace the source of target data, extract the associated operation records from the traceability chain, verify the signature, and then traverse the traceability graph in reverse to obtain the traceability path. Determine the responsibility type of the operation nodes in the traceability path based on the responsibility division rules. When data anomalies are detected, perform traceability and location by comparing data fingerprints to generate responsibility location results.

[0022] Step 4: When the operating entity raises an objection to the responsibility positioning result, the consistency between the input data received by the objecting party and the upstream delivered data is verified through privacy computation. If the verification result shows that the input data was abnormal when it was received, the responsibility tracing process is triggered to dynamically adjust the responsibility division, generate a correction result and write it into the blockchain network.

[0023] For example, in a cross-domain sharing scenario of electricity marketing data, multiple participating nodes include provincial power company data center nodes, municipal power supply bureau business nodes, third-party data analysis service nodes, and regulatory agency audit nodes. Each node first establishes an encrypted communication channel through key negotiation and generates a session key using an elliptic curve key exchange protocol. The session key is used for symmetric encryption of subsequent data transmission. For instance, when a provincial power company collects electricity consumption data for an industrial park in October 2025, the data includes enterprise user identifiers, daily electricity consumption sequences, peak-valley-normal-time distribution, and total monthly costs. After encryption and encapsulation, this data is used to construct a traceability graph. The provincial node, as a data collection node, generates an operation record containing the node's digital signature and data fingerprint. The data fingerprint is a 64-byte value obtained by calculating the SHA-256 hash of the original electricity consumption data. The data is then transmitted to the municipal power supply bureau node for cost calculation. After receiving the data, the municipal node generates a new operation record. The data fingerprint of the current node in the record reflects the data status after calculation. The data fingerprint of the preceding node is linked to the data fingerprint of the provincial node. The directed edge from the provincial node to the municipal node in the traceability graph records both the data fingerprint delivered by the source node and the data fingerprint received by the target node. Under normal circumstances, the two fingerprints should be completely consistent.

[0024] After the smart contract generated from the traceability graph is deployed to the blockchain network, the operation records of each node are written to the blockchain in chronological order to form a traceability chain. When regulatory agencies need to trace the electricity consumption data of industrial parks in October, the smart contract extracts the operation record containing the data identifier from the traceability chain as the starting point, verifies the identity signature of the municipal-level node and compares the data fingerprint, and traverses backward to the provincial-level node to obtain the complete traceability path. If, during the traceability process, it is found that the data fingerprint received by the municipal-level node is inconsistent with the data fingerprint delivered by the provincial-level node, the responsibility positioning logic of the smart contract automatically determines that the municipal-level node is the responsible node, marks the responsibility type as data receiving responsibility, and the generated responsibility positioning result records that the abnormal node is the municipal-level power supply bureau, the abnormal location is the data receiving link, and the abnormal details include two inconsistent data fingerprint values.

[0025] The local municipal power supply bureau objected to the responsibility determination results, claiming that the data received contained anomalies, triggering a privacy computation verification process. Both the municipal and provincial nodes homomorphically encrypted their locally stored electricity consumption data before uploading it to a trusted execution environment. The verification environment calculated and compared the hash values ​​of the two datasets in their encrypted state, finding a discrepancy. Simultaneously, the fingerprint of the target node receiving the data was extracted from the tracing chain corresponding to the municipal node's directed edge, and compared with the plaintext hash value of the municipal node's local data, finding a perfect match. The combination of the inconsistent encrypted hashes and the consistent plaintext hashes confirmed that the data anomaly was introduced during transmission, and the responsibility tracing process reassigned the responsible node to the provincial power company's data center. The system generates a correction result, adjusting the responsible node from the municipal power supply bureau to the provincial power company. The original correction result includes the new responsible node identifier, the basis for the responsibility adjustment, and the verification result. The municipal node, the provincial node, and the verification node verify the relevant data portion of the correction result and then sign it with their private keys. The three signatures are combined to form a 192-byte joint signature data. The correction result carrying the three signatures is written to the blockchain, updating the responsibility location record in the traceability chain, ensuring the accuracy and traceability of responsibility attribution during the cross-domain transfer of power marketing data between the provincial company, the municipal power supply bureau, and the third-party service agency.

[0026] This invention enables trusted management of the entire process of cross-domain sharing of electricity marketing data through blockchain smart contracts, providing clear technical guarantees for data collaboration among multi-level power organizations.

[0027] In an optional embodiment, step 1, which involves encrypting and encapsulating the acquired electricity marketing data and constructing a traceability graph, and generating an operation record for each operation node that includes the operator's identity signature and data fingerprint, further includes: Extract the operation subject identifier, operation type and data content from the power marketing data, and associate the data fingerprint of the current operation node with the data fingerprint of the previous operation node in a hash chain to form a data dependency relationship between nodes; A source graph is constructed based on the data dependencies. The source graph has operation nodes as vertices and data flow directions as directed edges. On each directed edge, the data fingerprint delivered by the source node and the data fingerprint received by the target node are recorded simultaneously. An operation record is generated for each operation node. The operation record includes the identity signature of the operation subject, the data fingerprint of the current node and the data fingerprint of the previous node. The operation record is digitally signed by the operation subject's private key and then encrypted and encapsulated. The encrypted and encapsulated operation record is associated with the corresponding node in the traceability graph and stored. The data fingerprint in the operation record is cross-validated with the data fingerprint recorded on the directed edge, which is used to determine the location of the data anomaly during subsequent traceability by comparison.

[0028] For example, in a cross-domain data sharing scenario, multiple participating nodes first establish an encrypted communication channel through a key negotiation process. Each participating node generates an asymmetric key pair during the initialization phase, and the public key is stored in a distributed directory service after being authenticated by a trusted certificate authority. When nodes need to establish a communication channel, the initiator encrypts a randomly generated session key using the recipient's public key, and the recipient decrypts it using their private key to obtain the session key. Both parties then use this session key for symmetric encrypted communication using advanced encryption standards. The session key is 256 bits long, and a key update is triggered every 24 hours or when the transmitted data exceeds 10GB. The update process reuses the encryption method used to transmit the new key through the existing channel, avoiding the need to repeatedly execute the complete handshake process. After the channel is established, all data transmitted between nodes is encrypted.

[0029] The processing of electricity marketing data begins with the extraction of the operation entity identifier. This identifier uses a unified coding rule and consists of three parts: organization code, department code, and employee number, with a total length of 32 characters. The operation type field records the nature of the current operation, including five basic types: data acquisition, data transformation, data transmission, data storage, and data query. Each type corresponds to a unique numerical code. The data content field stores the actual business data, including user identifier, electricity consumption, billing cycle, and fee amount. Immediately after extraction, the data content's hash value is calculated as a data fingerprint. The data fingerprint is generated using the secure hash algorithm SHA-256, outputting a 64-bit hexadecimal string that uniquely identifies the current state of the data content.

[0030] After the current operation node generates a data fingerprint, it needs to be hash-chained with the data fingerprints of its predecessor operation nodes. The association method involves concatenating the data fingerprint of the predecessor node with the current node's operation subject identifier, operation type, and timestamp, and then performing another hash calculation. The resulting hash value contains both the current operation information and, through the predecessor fingerprint, establishes a cryptographic binding with historical operations. This chained association ensures that if any historical node's data is tampered with, the hash values ​​of all subsequent nodes become invalid, thus forming an immutable data dependency relationship between nodes. The data dependency relationship is organized in the form of a directed acyclic graph, where each node may depend on one or more predecessor nodes. The dependency relationship stores the unique identifier of the predecessor node through a pointer array.

[0031] When constructing a source graph based on data dependencies, operation nodes serve as vertices of the graph. Each vertex stores attributes such as node identifier, operation subject identifier, operation type, operation timestamp, and data fingerprint. The data flow direction is defined as a directed edge from the data provider to the data receiver. The attributes of a directed edge include edge identifier, source node identifier, target node identifier, flow timestamp, data fingerprint delivered by the source node, and data fingerprint received by the target node. The data fingerprint delivered by the source node is calculated by the source node before sending the data, while the data fingerprint received by the target node is calculated by the target node after receiving the data. Both data fingerprints are recorded on the same directed edge, providing a benchmark for subsequent data consistency verification. The source graph is stored using an adjacency list structure. Each node maintains its outgoing edge list and incoming edge list. The outgoing edge list records all edges where the node is a source node, and the incoming edge list records all edges where the node is a target node. The graph structure is serialized in JSON format and stored in a distributed database, supporting fast retrieval based on node and edge identifiers.

[0032] The process of generating an operation record for each operation node includes four steps: creating the record structure, filling in the field content, performing digital signature, and cryptographic encapsulation. The operation record uses a predefined data structure, including fields such as record identifier, operation subject identity signature, current node's data fingerprint, previous node's data fingerprint, operation timestamp, operation type, and data content hash value. The operation subject identity signature is generated by the operation subject using its private key to sign the message containing the operation subject identifier and timestamp. The signature algorithm is the elliptic curve digital signature algorithm, and the curve parameter uses the P-256 standard curve. The current node's data fingerprint is the SHA-256 hash value calculated for the data content. The previous node's data fingerprint is extracted from the previous node's operation record. If the current node is the starting node of the data stream, the previous node's data fingerprint field is filled with all-zero hash values ​​as placeholders.

[0033] After all fields of the operation record are filled in, the operating entity digitally signs the hash value of the entire operation record using its private key, and appends the signature value to the end of the operation record. The signed operation record is then encrypted using a symmetric encryption algorithm. The encryption key is a data encryption key specific to the operating node, with a key length of 256 bits, derived from the node's master key and the operation record identifier using a key derivation function. The length of the encrypted operation record is determined based on the original record length and the padding rules, employing a cipher block chaining mode. The initialization vector is randomly generated and appended to the beginning of the ciphertext. The encrypted operation record is stored in binary form, and its storage location is mapped to a specific node in the distributed storage cluster based on the record identifier using a consistent hashing algorithm.

[0034] The encrypted operation record needs to be associated with the corresponding node in the source graph. This association is achieved by adding an operation record reference field to the node attributes of the source graph. This field stores the location information of the operation record in the distributed storage system, including the storage node address, data block identifier, and offset. The source graph itself is stored in a graph database, and the operation records are stored in an object storage system; the two are logically linked through references. When accessing the complete information of a node is required, the node metadata and operation record reference are first read from the graph database, and then the encrypted operation record is read from the object storage system based on the reference. After decryption, the complete operation record content is obtained. The data fingerprint field in the operation record forms a cross-validation relationship with the data fingerprint fields recorded on directed edges. Specifically, the current node's data fingerprint in the current node's operation record should be equal to the target node's received data fingerprint recorded on the directed edge with this node as the target node, and the predecessor node's data fingerprint in the current node's operation record should be equal to the source node's delivered data fingerprint recorded on the directed edge with this node as the target node.

[0035] For example, data acquisition node A collects daily electricity consumption data of 58.3 kWh from smart meter user 201135. The operation entity identifier is ORG01-DEPT03-EMP0217, and the operation type code is 1, indicating data acquisition. The data content is structured data containing user identifier, date, and electricity consumption. Calculating the SHA-256 hash value of this data content yields the data fingerprint 7f4a8b2c9e1d3a5f6b8c0e2a4d6f8b1c3e5a7b9d1f3a5c7e9b1d3f5a7c9e1b. Node A is the starting node, and the data fingerprint of the preceding node is all zeros: 0 ... After receiving data transmitted by node A, data processing node B calculates the hash value of the received data to obtain the received data fingerprint. If the received data has not changed, the received data fingerprint should be equal to 7f4a8b2c9e1d3a5f6b8c0e2a4d6f8b1c3e5a7b9d1f3a5c7e9b1d3f5a7c9e1b. Node B then performs a format conversion on the data to generate new data content and calculates the new data fingerprint a3c5e7b9d1f3a5c7e9b1d3f5a7c9e1b3d5f7a9c1e3a5b7d9f1b3d5f7a9c1e3a. In the source graph, on the directed edge from node A to node B, the fingerprint of the data delivered by the source node is recorded as 7f4a8b2c9e1d3a5f6b8c0e2a4d6f8b1c3e5a7b9d1f3a5c7e9b1d3f5a7c9e1b, and the fingerprint of the data received by the target node is also recorded as 7f4a8b2c9e1d3a5f6b8c0e2a4d6f8b1c3e5a7b9d1f3a5c7e9b1d3f5a7c9e1b. If the data is tampered with during transmission, the fingerprint of the data received by the target node will be inconsistent with the fingerprint of the data delivered by the source node. By comparing them, it can be determined that the location of the data anomaly is in the transmission stage corresponding to the directed edge.

[0036] This invention constructs a verifiable data traceability graph through a dual data fingerprinting mechanism and chained hash association, providing a cryptographic-level chain of evidence for subsequent responsibility identification, effectively supporting data integrity verification and responsibility tracing in cross-domain data sharing scenarios.

[0037] In an optional embodiment, step 2, which involves generating a smart contract containing traceability query logic and responsibility location logic based on the traceability graph and deploying it to the blockchain network, and writing the operation records into the blockchain network to form a traceability chain, further includes: The directed edge relationships and data fingerprint associations between nodes are extracted from the source graph. The directed edge relationships are mapped to the path traversal rules of the source query logic, and the data fingerprint associations are mapped to the fingerprint comparison rules of the responsibility location logic. The source tracing query logic is generated according to the path traversal rules. The source tracing query logic receives the target data identifier and traverses the directed edges of the source tracing graph in reverse to obtain the source tracing path containing the sequence of all operation nodes. Responsibility location logic is generated according to the fingerprint comparison rules. The responsibility location logic receives the tracing path and compares the data fingerprint delivered by the source node with the data fingerprint received by the target node for each directed edge in the tracing path. When the two data fingerprints are inconsistent, the target node of the directed edge is marked as the responsible node. The source tracing query logic and the responsibility location logic are encapsulated into a smart contract and deployed to the blockchain network. The operation records are written into the blockchain according to the time sequence of the source tracing graph to form a source tracing chain, so that the smart contract can perform source tracing query and responsibility location by calling the operation records in the source tracing chain.

[0038] For example, when extracting directed edge relationships between nodes from the source graph, the adjacency list structure of the source graph is traversed, and the source node identifier, target node identifier, and edge identifier of each directed edge are read. This information is organized into a set of edge relationships in the form of triplets. The set of edge relationships is stored in an array structure, and the array elements contain edge identifier, source node identifier, and target node identifier fields, each field being 32 bytes long. The extraction of data fingerprint associations depends on the attribute fields of the directed edges. The data fingerprint delivered by the source node and the data fingerprint received by the target node are read from each directed edge, and the two data fingerprints are bound to the edge identifier to form a fingerprint association record. The fingerprint association record uses a key-value pair structure, where the key is the edge identifier, and the value is a structure containing the data fingerprint delivered by the source node and the data fingerprint received by the target node. Both data fingerprint fields are 64-byte hexadecimal strings.

[0039] The edge relationship set is converted into a reverse adjacency list structure. For each node, all directed edges with that node as the target node are recorded. The reverse adjacency list is implemented using a hash table, where the key is the node identifier and the value is an array of incoming edge identifiers pointing to that node. The path traversal rule is defined as starting from the node containing the given target data, searching for all incoming edges through the reverse adjacency list, obtaining the source node along the incoming edges, and recursively executing this search process until the source node with no incoming edges is reached. During the traversal, the identifiers of all nodes and edges visited are recorded and organized into an ordered sequence according to the traversal order. To avoid infinite traversal caused by circular dependencies, the traversal process maintains a set of visited nodes, terminating the traversal of that path branch when a visited node is encountered. The traversal depth is limited to 128 levels; exceeding this depth interrupts the traversal and records an exception message.

[0040] The fingerprint association records are converted into a comparison rule data structure. The comparison rule structure includes an edge identifier, a source node delivered data fingerprint, a target node received data fingerprint, and a comparison result field. The comparison result field is a Boolean type, with an initial value indicating an unexecuted state. The fingerprint comparison rule is defined as follows: for a given edge identifier, extract the corresponding source node delivered data fingerprint and target node received data fingerprint, and compare the contents of the two data fingerprints byte-by-byte. The comparison result is considered consistent when all bytes are identical, and inconsistent when any byte is different. The comparison operation uses a constant-time comparison algorithm to avoid timing-side channel leakage caused by premature termination. The comparison process traverses all 64 bytes and accumulates the difference count; consistency is determined when the difference count is zero.

[0041] When generating the source tracing query logic based on path traversal rules, the reverse adjacency list and traversal algorithm are encoded into a smart contract code segment. This code segment receives the target data identifier as an input parameter, which is a 32-byte hash value. The output is a source tracing path structure containing a sequence of node identifiers and edge identifiers. When the code segment executes, it checks whether the target data identifier exists in the source graph node set. If it does not exist, it returns an empty path and triggers a query failure event. If it exists, it starts from the node corresponding to the target data identifier and uses a depth-first search algorithm to traverse upwards along the reverse adjacency list, creating a path stack to store the node identifiers and edge identifiers visited during the traversal. During the traversal, for each node visited, the node identifier is pushed onto the path stack, the incoming edge of that node is found, the source node is obtained along the incoming edge, and the traversal continues. When a source node without incoming edges is reached, the path stack contains the complete path from the source node to the target node. Reversing the contents of the path stack yields the forward source tracing path. The node identifier sequence and edge identifier sequence in the source tracing path are arranged in chronological order of data flow, with additional metadata such as path length, query timestamp, and query initiator address.

[0042] When generating responsibility location logic based on fingerprint comparison rules, the comparison rules and node marking logic are encoded into a smart contract code segment. This code segment receives the tracing path as input parameters, which contains a sequence of node identifiers and a sequence of edge identifiers, and outputs an array of responsibility node identifiers. During execution, the code segment iterates through the edge identifier sequence in the tracing path, reading the source node's delivery data fingerprint and the target node's receiving data fingerprint from the fingerprint association record for each edge. After reading, a constant-time comparison algorithm is called to perform a byte-by-byte comparison, traversing 64 bytes and accumulating differences. If the difference is zero, the two data fingerprints are considered identical; otherwise, they are considered inconsistent. When an inconsistency is determined, the target node identifier is parsed from the edge identifier and added to the responsibility node identifier array. Simultaneously, the inconsistent source node's delivery data fingerprint value, the target node's receiving data fingerprint value, and the edge identifier are recorded for auditing purposes. The comparison process does not terminate prematurely upon discovering a responsibility node; it continues to traverse all edges to discover all responsibility nodes. After traversal, the responsibility node identifier array is returned. An empty array indicates that all data fingerprints on the tracing path are identical, and there are no data anomalies.

[0043] When generating smart contracts, the contract code is written using a smart contract programming language. This code includes state variable declarations, source lookup code, responsibility location code, and auxiliary operation code. State variables store a reverse adjacency list and fingerprint association records, using a mapping data type where the mapping key is a node identifier or edge identifier, and the mapping value is the corresponding adjacency information or fingerprint information. The source lookup code implements the reverse traversal logic starting from the target data identifier, including input validation, path search, and result assembly. This code segment is marked as a read-only view type, meaning it does not modify the contract state or consume transaction fees when called. The responsibility location code implements the data fingerprint comparison logic for the source path, including edge traversal, fingerprint reading, difference comparison, and node marking. It is also marked as a read-only view type. The auxiliary operation code includes data initialization, permission verification, and event notification. Data initialization loads the source graph data into the contract state variables. Permission verification restricts data initialization to authorized addresses. Event notification emits on-chain events upon completion of the query and location operations.

[0044] When a smart contract is deployed to a blockchain network, the contract code is compiled to generate bytecode and an application binary interface. A deployment transaction is then constructed through a blockchain client. The transaction data field of the deployment transaction contains bytecode content. An empty transaction recipient address indicates contract creation. The transaction sender is the contract deployment account, and the transaction carries sufficient gas fees to cover the computational costs of contract deployment. After the transaction is submitted to the blockchain network, it enters the transaction pool. Following consensus verification by network nodes, the transaction is packaged into a new block and broadcast to the entire network. Once the block receives sufficient confirmations, contract deployment is complete. The contract address is calculated using a deterministic algorithm based on the sender's address and the transaction count at that address; the contract address is 20 bytes long. After successful deployment, the data initialization code segment is invoked to batch write the reverse adjacency list and fingerprint association records into the contract state variables. Batch writing employs a phased submission strategy, with each batch containing no more than 256 records to prevent the gas consumption of a single transaction from exceeding the block gas limit. At least one block time interval is maintained between batch submissions to ensure sequential transaction execution.

[0045] When operation records are written to the blockchain in chronological order according to the traceability graph, the reference information of all operation records is extracted from the traceability graph node set. These records are then sorted in ascending order based on their timestamp field, using Coordinated Universal Time (UTC) with a precision of seconds. The sorted sequence of operation records is used to construct write transactions. Each transaction contains the encrypted content of one operation record, its identifier, and a timestamp. The write transaction invokes the storage code segment of the smart contract. This segment receives the operation record data and stores it in the operation record mapping of the contract's state variables. The mapping key is the operation record identifier, and the mapping value is a structure containing the encrypted content of the operation record, its timestamp, and the block height. After the operation records are written to the blockchain, a traceability chain is formed in chronological order. Each record is indexed using its identifier and timestamp. The index uses a composite key structure to support queries by time range and precise queries by identifier. Records in the traceability chain are immutable; any modification to a written record will change the block hash value and be rejected by the blockchain network. When a smart contract performs a traceability query, it retrieves operation records containing the target data identifier from the traceability chain. Node identifiers and data fingerprints are extracted from these records, and a path traversal is performed using a reverse adjacency list to generate a traceability path containing a complete sequence of operation nodes. When a smart contract performs responsibility localization, it receives the traceability path as input, traverses the edge identifiers along the path, reads the source node delivery data fingerprint and the target node receiving data fingerprint for each edge from the fingerprint association record, performs a byte-by-byte comparison, and records the target node identifier of the edge as the responsible node when they do not match. After comparing all edges, it returns a set of responsible node identifiers.

[0046] This invention directly maps the structural relationships and data fingerprint relationships of the traceability graph to the code segments of smart contracts, thereby realizing automated traceability query and responsibility location based on blockchain, ensuring the traceability and attributable attributes of the data flow process.

[0047] In an optional embodiment, step 3, which involves extracting associated operation records from the tracing chain when it is necessary to trace the target data, verifying the signature, and then traversing the tracing graph in reverse to obtain the tracing path, further includes: Based on the identifier of the target data, retrieve the operation record containing the identifier of the target data from the traceability chain as the starting operation record; Extract the identity signature and data fingerprint of the operating subject from the starting operation record, verify the identity signature using the public key of the operating subject, and compare and verify the data fingerprint in the starting operation record with the data fingerprint received by the target node recorded on the corresponding directed edge in the traceability graph. When the identity signature verification is successful and the two data fingerprints are consistent, mark the starting operation record as a valid record. Based on the preceding node data fingerprint contained in the starting operation record, the preceding operation record is retrieved from the tracing chain. Identity signature verification and data fingerprint comparison verification are performed on the retrieved preceding operation record. When the verification is successful and the data fingerprint is consistent, the preceding operation record is marked as a valid record. The preceding node data fingerprint in the preceding operation record is extracted to continue the forward retrieval. The retrieval and verification process is repeated until the source operation record is reached. All verified operation records between the source operation record and the starting operation record are organized in time sequence to form a tracing path containing a complete sequence of operation nodes.

[0048] For example, the target data identifier is a 32-byte hash value, which uniquely corresponds to a specific operation record in the tracing chain. The retrieval operation is implemented by calling the smart contract's query interface. The query interface receives the target data identifier as input and performs a key-value lookup in the operation record mapping maintained by the contract's state variables. The key of the operation record mapping is the operation record identifier, and the value is a structure containing the encrypted operation record content, timestamp, and block height. The retrieval process traverses the operation record mapping, comparing the data fingerprint field in each record with the target data identifier. The data fingerprint field is located at a fixed offset position in the operation record structure and has a length of 64 bytes. When an operation record whose data fingerprint matches the target data identifier is found, this operation record is marked as the starting operation record, and its complete content is extracted. If no matching record is found after the traversal, a retrieval failure status is returned, and an exception handling process is triggered. The exception handling process records the timestamp of the query request, the initiator's address, and the target data identifier, and writes this information to the audit log for subsequent analysis. The retrieved initial operation record is stored in encrypted form and needs to be decrypted using the data decryption key of the corresponding node. The decryption key is 256 bits long and is generated from the node master key and operation record identifier through a key derivation algorithm. Decryption adopts the cipher block chaining mode of the Advanced Encryption Standard, and the initialization vector is extracted from the ciphertext header.

[0049] The decrypted operation record is parsed according to a predefined structure, which includes an operation record identifier field, an operation subject identifier field, an operation type field, a timestamp field, a current node data fingerprint field, a predecessor node data fingerprint field, and an identity signature field. The identity signature field, located at the end of the record, is 64 bytes long and is generated using an elliptic curve digital signature algorithm. The data fingerprint field consists of a current node data fingerprint and a predecessor node data fingerprint, both SHA-256 hash values, each 64 bytes long. After extracting the operation subject identifier, the public key corresponding to the operation subject is retrieved from the public key infrastructure's certificate directory service. The public key uses P-256 elliptic curve parameters, and the public key certificate contains the public key value, the certificate issuer's signature, and validity information. Verification of the public key certificate includes checking that the certificate has not expired, that the certificate issuer's signature is correct, and that the certificate has not been revoked. After successful verification, the public key value is extracted for subsequent signature verification.

[0050] The identity signature is verified by concatenating all content in the operation record except for the identity signature field and calculating the SHA-256 hash value to obtain the message digest. The message digest, identity signature value, and public key value are then input into the elliptic curve digital signature algorithm's verification process. The verification process checks whether the signature value is a valid result of signing the message digest using the corresponding private key. The verification algorithm performs elliptic curve point operations to calculate whether the public key point recovered from the signature matches the provided public key point. If they match, the signature verification passes; otherwise, it fails. If signature verification fails, the starting operation record is marked as invalid, the tracing process is terminated, and a signature verification failure error code (a 4-digit hexadecimal value) is returned and recorded in the event log for auditing. After successful signature verification, a data fingerprint comparison verification is performed. The data fingerprint of the current node is extracted from the starting operation record. The directed edge with the node corresponding to the starting operation record as the target node is found in the tracing graph, and the data fingerprint received by the target node recorded in the attributes of that directed edge is read. Both data fingerprints are 64-byte hexadecimal strings. Consistency is verified by comparing each byte sequentially. The comparison process iterates through all 64 bytes and accumulates the difference count. A match is determined when the difference count is zero, and an inconsistency is determined when it is non-zero. If the data fingerprints are inconsistent, the starting operation record is marked as invalid, and the two inconsistent data fingerprint values ​​and the directed edge identifier are recorded, terminating the tracing process.

[0051] When identity signature verification passes and data fingerprints match, the starting operation record is marked as a valid record. This marking operation adds the record's identifier and metadata to the valid record set maintained in memory. The valid record set is stored using a linked list structure. Each linked list node contains an operation record identifier, a node identifier, a timestamp, and a pointer to the preceding record. The starting operation record becomes the first node in the linked list, and its preceding pointer is initially null. After extracting the preceding node's data fingerprint from the starting operation record, this data fingerprint serves as the target identifier for the next round of retrieval. Operation records containing this data fingerprint as the current node's data fingerprint are retrieved from the tracing chain. The retrieval method is the same as for the starting operation record: traversing the operation record mapping and comparing the data fingerprint fields, once a matching record is found, it is marked as the preceding operation record.

[0052] The retrieved preceding operation records undergo identity signature verification and data fingerprint comparison verification, with the verification process being completely consistent with that of the initial operation record. The operation subject identifier is extracted from the preceding operation record, the public key certificate is queried and the public key is extracted, and the public key is used to verify the identity signature of the preceding operation record. Upon successful verification, the current node's data fingerprint is extracted from the preceding operation record. A directed edge with the node corresponding to the preceding operation record as the target node is found in the tracing graph, and the received data fingerprint of the target node of this directed edge is read. The consistency of the two data fingerprints is compared. When the identity signature verification passes and the data fingerprint matches, the preceding operation record is marked as a valid record and added to the linked list of valid records. The preceding pointer of each linked list node points to the linked list node corresponding to the initial operation record, forming a reverse link relationship. If verification fails, the preceding operation record is marked as an invalid record, the tracing process is terminated, and the corresponding error code is returned.

[0053] Extract the preceding node data fingerprint from the verified preceding operation record. Use this data fingerprint as the new retrieval target to retrieve the next preceding operation record from the tracing chain. The retrieval and verification process continues. Each retrieved operation record, after identity signature verification and data fingerprint comparison verification, is added to the head of the valid record set linked list. The link direction of the linked list always points to the earlier record in time. When the preceding node data fingerprint of a retrieved operation record is all zero values, this record is the source operation record, representing the starting point of the data flow, and there is no earlier preceding record. The verification process of the source operation record still requires identity signature verification, but the data fingerprint comparison verification only verifies the consistency between the current node data fingerprint and the data fingerprint received by the target node of the corresponding directed edge in the tracing graph; there is no comparison of the preceding node data fingerprint. After the source operation record passes verification, it is marked as a valid record and added to the head of the linked list. At this time, the linked list contains a complete sequence of operation records from the source operation record to the starting operation record.

[0054] The traversal begins from the head of the linked list of valid records, where the head node corresponds to the source operation record. The traversal moves along the preorder pointer of the linked list, sequentially visiting each node and extracting the operation record identifier and timestamp stored within. Operation records are arranged in ascending order of timestamps, using Coordinated Universal Time (UTC) with a precision of seconds. During the traversal, the node identifier for each operation record is extracted and organized into a node identifier sequence, with the order matching the time sequence, from the source node to the target node. Simultaneously, directed edge identifiers connecting adjacent nodes are extracted from the source graph and organized into an edge identifier sequence. This sequence, along with the node identifier sequence, describes the data flow path. The node identifier sequence and edge identifier sequence are encapsulated into a source path structure, which includes a path length field, a node identifier array field, an edge identifier array field, and a path generation timestamp field. The path length field records the number of nodes, ranging from 1 to 128; paths exceeding 128 levels are truncated during the retrieval phase. The source path structure serves as the output of the source tracing query and can be used by subsequent responsibility location logic.

[0055] This invention ensures the authenticity and integrity of each record in the traceability path by verifying the signature of the operation record and comparing the data fingerprint. Based on the verified records, a reliable data flow path is constructed, providing a reliable basis for subsequent liability determination.

[0056] In an optional embodiment, step 3, which involves determining the responsibility type of the operation nodes in the tracing path based on responsibility division rules, and performing tracing and location by comparing data fingerprints when data anomalies are detected, and generating a responsibility location result, further includes: Extract the operation type and data processing permission of each operation node from the traceability path. Determine the responsibility type of the operation node in the data flow process based on the combination relationship between the operation type and the data processing permission and the position of the operation node in the traceability diagram. The responsibility type includes data generation responsibility, data transmission responsibility, and data reception responsibility. Traverse the operation nodes in the tracing path, extract the data fingerprints recorded on the directed edges corresponding to each operation node, the data fingerprints delivered by the source node and the data fingerprints received by the target node, and compare them. When the comparison results are inconsistent, it is determined that a data anomaly has occurred. For directed edges where data anomalies occur, the target node of the directed edge is marked as an anomaly node, and the responsibility type of the anomaly node is extracted from the source tracing path. Based on the responsibility type of the anomaly node and the location of the directed edge where the data fingerprint is inconsistent, the location where the data anomaly was introduced is determined, and the responsibility is assigned. The node identifier of the abnormal node, the responsibility type of the abnormal node, and the organization to which the responsibility belongs are used to generate a responsibility location result.

[0057] For example, the traceability path structure includes a node identifier sequence and an edge identifier sequence. The node identifier sequence is traversed, and the operation record corresponding to each node is read from the operation record mapping of the traceability chain. After decryption, the operation record extracts the operation type field and the data processing permission field. The operation type field uses numerical encoding, with a value range of 1 to 5, representing data acquisition, data conversion, data transmission, data storage, and data query, respectively. The data processing permission field uses bitmask encoding, with each bit representing a permission, including read permission, write permission, modify permission, delete permission, and forward permission. The permission field is 1 byte long, with a value range of 0 to 31. The combination relationship between operation type and data processing permission is determined by looking up a predefined responsibility mapping table. The responsibility mapping table is stored in the form of a two-dimensional array, where the row index is the operation type code, the column index is the decimal value of the permission field, and the array elements are the responsibility type codes.

[0058] The position of an operation node in the source graph is determined by analyzing its in-degree and out-degree. In-degree is the number of directed edges pointing to that node, and out-degree is the number of directed edges emanating from that node. A node with an in-degree of zero and an out-degree greater than zero is located at the beginning of the data flow and is identified as a source node. A node with an in-degree greater than zero and an out-degree greater than zero is located in the middle of the data flow and is identified as an intermediate node. A node with an in-degree greater than zero and an out-degree of zero is located at the end of the data flow and is identified as a terminal node. The responsibility type is determined by combining three dimensions: operation type, data processing authority, and node position. Responsibility types include data generation responsibility, data transmission responsibility, and data reception responsibility. When a source node's operation type is data acquisition, its responsibility type is data generation responsibility, indicating that this node is responsible for generating the raw data. When an intermediate node's operation type is data transmission or data conversion, its responsibility type is data transmission responsibility, indicating that this node is responsible for maintaining the integrity of the data during the flow. When a terminal node or intermediate node's operation type is data storage or data reception, its responsibility type is data reception responsibility, indicating that this node is responsible for verifying the correctness of the received data. Once the responsibility type is determined, it is stored in the node responsibility mapping structure. The mapping key is the node identifier, and the mapping value is the responsibility type code. The responsibility type code is represented by a single byte, with a value of 1 for data generation responsibility, a value of 2 for data transmission responsibility, and a value of 3 for data reception responsibility.

[0059] Adjacent node pairs and connecting edges are extracted sequentially from the node identifier sequence and edge identifier sequence. For each directed edge, the data fingerprint delivered by the source node and the data fingerprint received by the target node are read from the edge attributes of the source graph. Both data fingerprints are 64-byte hexadecimal strings. Data fingerprint comparison is performed byte-by-byte. A difference counter is created and initialized to zero. The 64-byte content is traversed. When the i-th byte of the data fingerprint delivered by the source node is different from the i-th byte of the data fingerprint received by the target node, the difference counter is incremented by one. After traversal, the value of the difference counter is checked. A difference counter of zero indicates that the two data fingerprints are completely consistent and the data has not changed during transmission. A difference counter greater than zero indicates that the two data fingerprints are different, and a data anomaly is determined. The detection result of the data anomaly is stored in an edge anomaly mapping structure. The mapping key is the edge identifier, and the mapping value is a boolean anomaly flag and a difference byte position array. An anomaly flag of true indicates that there is a data anomaly on the edge. The difference byte position array records the index values ​​of all inconsistent bytes. The maximum array length is 64.

[0060] For directed edges where data anomalies occur, the source node identifier and target node identifier are parsed from the edge identifier, and the target node identifier is marked as an anomaly node. The anomaly node marking operation adds the node identifier to the anomaly node set. The anomaly node set uses a hash set data structure, supporting insertion and lookup operations with constant time complexity. When extracting the responsibility type of an anomaly node from the source path, the anomaly node identifier is used as the key to query the node responsibility mapping structure to obtain the responsibility type code of that node. The responsibility type code is converted into a text description: code 1 corresponds to the text "data generation responsibility", code 2 corresponds to the text "data transmission responsibility", and code 3 corresponds to the text "data reception responsibility".

[0061] When determining the location of a data anomaly based on the responsibility type of the anomalous node and the position of the directed edge where the data fingerprint inconsistency occurs, the sequence number of the directed edge in the tracing path and the responsibility type of the anomalous node are analyzed. Directed edge numbers start from zero. An edge with a sequence number of zero connects the source node and the first intermediate node, while an edge with a sequence number two (the tracing path length minus two) connects the last intermediate node and the terminal node. When the responsibility type of the anomalous node is data reception responsibility and the directed edge sequence number is at the end of the path, the data anomaly is determined to have been introduced at the target node's receiving stage, and the cause of the anomaly may be data corruption or tampering during the reception process. When the responsibility type of the anomalous node is data transmission responsibility and the directed edge sequence number is in the middle of the path, the data anomaly is determined to have been introduced at the transmission stage between the source node and the target node, and the cause of the anomaly may be network transmission errors or a man-in-the-middle attack. When the responsibility type of the anomalous node is data generation responsibility and the directed edge sequence number is zero, the data anomaly is determined to have been introduced at the source node's generation stage, and the cause of the anomaly may be a data acquisition device malfunction or an untrustworthy data source.

[0062] When determining responsibility attribution, a responsibility attribution description is generated by combining the anomaly node identifier, responsibility type, and the location where the data anomaly was introduced. The responsibility attribution description uses a structured format, including a responsibility node field, a responsibility type field, an anomaly location field, and an anomaly details field. The responsibility node field stores a 32-byte identifier of the anomaly node; the responsibility type field stores a textual description of the responsibility type; the anomaly location field stores the directed edge identifier and edge sequence number; and the anomaly details field stores the fingerprint of the data delivered by the source node, the fingerprint of the data received by the target node, and an array of differing byte positions. The responsibility attribution description is serialized into a JSON string, with the string length dynamically varying based on the number of differing bytes, typically ranging from 512 to 1024 bytes.

[0063] A responsibility location result structure is created, containing fields for result identifier, abnormal node identifier, responsibility type, responsibility attribution, and generation timestamp. The result identifier is a 32-byte hash value, obtained by concatenating the abnormal node identifier and the generation timestamp and calculating a SHA-256 hash, ensuring the uniqueness of the result identifier. The abnormal node identifier field directly copies the node identifier value of the abnormal node. The responsibility type field stores a text description of the responsibility type, and the responsibility attribution field stores the previously generated JSON string describing the responsibility attribution. The generation timestamp field records the Coordinated Universal Time (UTC) at which the responsibility location result was generated, with a precision in seconds. The responsibility location result structure is serialized and stored in the blockchain's smart contract state variable. The state variable uses a mapping type, with the result identifier as the key and the complete content of the responsibility location result as the value. The storage operation is completed by calling the smart contract's write interface. The write interface receives the responsibility location result structure and performs a state update. The state update operation consumes blockchain network gas fees, the amount of which is calculated based on the size of the result data, typically ranging from 50,000 to 100,000 gas units.

[0064] This invention combines liability type judgment and data fingerprint comparison to accurately locate the introductory link and responsible party of data anomalies, and generates a liability location result containing a complete chain of evidence, providing a reliable basis for liability tracing in cross-domain data sharing.

[0065] In an optional embodiment, in step 4, when the operating entity raises an objection to the responsibility allocation result, the consistency between the input data received by the objecting party and the upstream delivered data is verified through privacy computation. If the verification result indicates that the input data was abnormal upon receipt, the responsibility tracing process is triggered to dynamically adjust the responsibility allocation, generate a corrected result, and write it into the blockchain network. This further includes: Based on the node identifier in the objection request, locate the objecting node and its predecessor node from the tracing path as upstream nodes; homomorphically encrypt the data stored locally by the objecting node and the upstream node and upload them to the verification environment; calculate and compare the ciphertext hash value in the ciphertext state; when the ciphertext hash value is inconsistent, it is confirmed that the data has changed during the transmission process. Extract the data fingerprint recorded on the directed edge corresponding to the objecting node from the tracing path, and compare it with the plaintext hash value of the objecting party's local data. When the two are consistent, combine the result of the inconsistent ciphertext hash value to confirm that the input data has an anomaly when it is received. Trigger the responsibility tracing process, re-execute data fingerprint comparison and responsibility type judgment for the sequence from upstream node to source node, and redetermine the responsibility attribution node; organize the responsibility attribution node identifier, responsibility adjustment basis and verification results to generate a correction result, and call the objecting node, upstream node and verification node to digitally sign the correction result to generate a three-party signature; When the three-party signature verification is successful, the correction result carrying the three-party signature is written into the blockchain, updating the responsibility positioning record in the traceability chain.

[0066] Combination Figure 2 The flowchart for handling objections and dynamically adjusting accountability in power marketing data is explained. Objection requests use a structured message format, including fields for the objecting party's node identifier, the objection reason, and the request timestamp. The objecting party's node identifier is a 32-byte hash value used to perform a search operation in the node identifier sequence of the tracing path. The search process traverses the node identifier sequence, comparing the consistency of each element with the objecting party's node identifier. When a matching element is found, its index position in the sequence is recorded. The index position is decremented by one to obtain the index of the preceding node in the sequence. The preceding node identifier is extracted from the node identifier sequence using this index, and the node corresponding to the preceding node identifier is defined as the upstream node. If the objecting party's node index is zero, it indicates that the objecting party is the source node. In this case, there is no upstream node, the objection request is rejected, and error code 0x0001 is returned, indicating that the source node cannot raise an objection. When the objecting party's node index is greater than zero, the upstream node identifier and the objecting party's node identifier are extracted and stored in the objection handling context structure. The context structure includes fields for the objecting party's identifier, the upstream node identifier, the objection submission time, and the processing status.

[0067] The original data is read from the local storage systems of the dissenting node and the upstream node. The original data is a structured record of electricity marketing business data, containing fields such as user identifier, electricity consumption, billing cycle, and fee amount, with a data size typically ranging from 128 to 512 bytes. Homomorphic encryption uses the Paillier encryption scheme, which supports homomorphic addition operations on the ciphertext. The encryption process requires the generation of a public key and a private key. The public key contains a modulus n and a generator g. The modulus n is the product of two large prime numbers with a prime bit length of 2048 bits, and the generator g is a random number within the range of the square of the modulus n. The private key contains the Euler's totient function value and the modular inverse, used for decryption. The dissenting node uses its public key to encrypt its local data. The encryption process maps the plaintext message m to ciphertext c, where c = (gm × rn) mod n², and the random number r is uniformly sampled from 1 to n. The upstream node uses the same public key parameters to encrypt its local data, ensuring that both ciphertexts can be processed within the same ciphertext space. The encrypted ciphertext data is twice the length of the modulus n, i.e., 512 bytes, and is uploaded to the verification environment through a secure transmission channel.

[0068] The verification environment is deployed within a trusted execution environment, which provides isolated computing space to prevent external access to ciphertext or intermediate computation results. After receiving ciphertext data uploaded by the dissenting node and the upstream node, the verification environment calculates the ciphertext hash value in the ciphertext state. The ciphertext hash calculation uses the SHA-256 algorithm to hash the 512 bytes of ciphertext content, generating a 64-byte hexadecimal hash string. The dissenting node's ciphertext hash value and the upstream node's ciphertext hash value are stored in temporary variables within the verification environment. The two hash values ​​are checked for consistency through a byte-by-byte comparison. During the comparison process, a difference counter is created and initialized to zero. It iterates through the 64 bytes of content, incrementing the difference counter when the i-th byte of the dissenting node's ciphertext hash value differs from the i-th byte of the upstream node's ciphertext hash value. After the comparison is complete, the value of the difference counter is checked. A difference counter greater than zero indicates that the ciphertext hash values ​​are inconsistent, confirming that the data has changed during transmission. A difference counter of zero indicates that the ciphertext hash values ​​are consistent, and the data has not changed during transmission. In this case, the dissenting party's objection is invalid, and the objection request is rejected.

[0069] The directed edge connecting the upstream node to the dissenting node is determined based on the index of the dissenting node in the node identifier sequence. The index of the directed edge in the edge identifier sequence is equal to the index of the dissenting node minus one, and the edge identifier is extracted from the edge identifier sequence using this index. The edge identifier is used to query the edge attribute mapping of the source graph, and the target node's received data fingerprint field is read. This field stores a 64-byte hexadecimal hash string, representing the data state recorded by the dissenting node when receiving data. The plaintext hash value of the dissenting node's local data is obtained by performing SHA-256 hash calculation on the raw data stored locally by the dissenting node. Before the calculation, the dissenting node needs to decrypt the local data into plaintext form. The plaintext data is calculated using the same hash algorithm and parameters as when the source graph was constructed to ensure the comparability of hash values. The comparison between the target node's received data fingerprint and the dissenting node's local data plaintext hash value is performed byte by byte. A consistency flag is created and initialized to true, and the 64-byte content is traversed. When any byte is different, the consistency flag is set to false.

[0070] When the fingerprint of the data received by the target node matches the plaintext hash value of the data in the objecting party's local data, a comprehensive judgment is made in conjunction with the aforementioned result of inconsistent ciphertext hash values. A matching plaintext hash value indicates that the data stored locally by the objecting party matches the received data fingerprint recorded in the tracing chain, proving that the objecting party did indeed record the data state upon receipt. An inconsistent ciphertext hash value indicates that there is a difference between the data actually received by the objecting party and the data actually delivered by the upstream node, and this difference was introduced during data transmission or delivery by the upstream node. When both conditions are met simultaneously, it is confirmed that the input data was abnormal upon receipt, and the responsibility for the abnormality should not be attributed to the objecting node; a responsibility tracing process needs to be triggered to re-identify the responsible node.

[0071] When the responsibility tracing process is triggered, a subsequence from the upstream node to the source node is extracted from the node identifier sequence of the tracing path. The starting element of the subsequence is the upstream node identifier, and the ending element is the source node identifier. The length of the subsequence is equal to the upstream node index plus one. For this subsequence, data fingerprint comparison and responsibility type determination are re-executed. The comparison process traverses the directed edges corresponding to the subsequence, extracts the source node delivery data fingerprint and the target node receiving data fingerprint from the tracing graph for each edge, performs byte-by-byte comparison, and accumulates the difference count. When an edge with a difference count greater than zero is found, the target node of that edge is marked as a new abnormal node. The responsibility type of the new abnormal node is extracted from the node responsibility mapping, and the new responsibility attribution is determined by combining the position of the edge in the tracing path. The re-determined responsibility attribution node identifier is stored in the responsibility tracing result structure, which includes a new responsibility node identifier field, an original responsibility node identifier field, and a responsibility transfer basis field.

[0072] Create a correction result structure containing fields for: Correction Result Identifier, New Responsible Node Identifier, Original Responsible Node Identifier, Responsibility Adjustment Basis, and Verification Result. The Correction Result Identifier is a 32-byte hash value, obtained by concatenating the New Responsible Node Identifier and the correction timestamp and then calculating the SHA-256 hash. The Responsibility Adjustment Basis field stores a JSON-formatted description, including the dissenting party node identifier, upstream node identifier, encrypted hash comparison result, and plaintext hash comparison result. The Verification Result field stores the verification report output by the privacy computation verification environment. The report includes a verification timestamp, verification node identifier, and verification node signature. The verification node is a trusted third-party node that performed the privacy computation. After serializing the Correction Result structure, calculate the SHA-256 hash value to generate a Correction Result Digest, which is 64 bytes long.

[0073] When the dissenting node, upstream node, and validator node are each instructed to digitally sign the correction result, a digest of the correction result is sent to each of the three nodes. The dissenting node uses its private key to perform an elliptic curve digital signature algorithm on the correction result digest, generating a 64-byte dissenting signature value. The upstream node uses its private key to perform the same signature algorithm on the correction result digest, generating a 64-byte upstream node signature value. The validator node uses its private key to sign the correction result digest, generating a 64-byte validator signature value. These three signature values ​​are concatenated in the order of the dissenting node signature, upstream node signature, and validator node signature, forming a 192-byte three-party signature data. This three-party signature data is appended to the end of the correction result structure, generating a correction result carrying the three-party signatures. The total length is determined based on the content of the correction result and the size of the signature data, typically ranging from 768 to 1024 bytes.

[0074] When the three-party signature verification passes, the three signature values ​​are extracted and signature verification is performed using the public keys of the corresponding nodes. The dissenting party's signature verification uses the public key of the dissenting node, the upstream node's signature verification uses the public key of the upstream node, and the verifying node's signature verification uses the public key of the verifying node. The verification process applies an elliptic curve signature verification algorithm to the corrected result digest and the signature value. When all three verification operations return a pass status, the three-party signature verification is considered successful. After successful verification, the corrected result carrying the three-party signatures is written to the blockchain. The write operation calls the smart contract's state update interface, which receives the corrected result data and stores it in the responsibility location record mapping. The mapping key is the corrected result identifier, and the mapping value is the complete content of the corrected result, including the three-party signature data. Simultaneously, the write operation updates the status field of the original responsibility location record in the traceability chain, changing the status field from valid to corrected, and adds a reference to the corrected result identifier to the record, establishing a relationship between the original record and the corrected result.

[0075] This invention verifies the authenticity of the objecting party's data through privacy computing technology, confirms the location of the anomaly by comparing both ciphertext and plaintext, dynamically adjusts the attribution of responsibility, and ensures the credibility of the correction result through a three-party signature mechanism, thus providing technical support for the fair determination of responsibility in cross-domain data sharing.

[0076] In a further optional embodiment, the process of calling the objecting node, the upstream node, and the verification node to digitally sign the correction result and generate a three-party signature further includes: The original text of the correction result is formed by organizing the responsibility attribution node identifier, the basis for responsibility adjustment, and the verification results, and then performing hash calculation on the original text of the correction result to generate a summary of the correction result; The dissenting node extracts the verification result portion from the original text of the corrected result, verifies its consistency with the local record, and then uses its private key to sign the digest of the corrected result to generate the dissenting node's signature. The upstream node extracts the delivery data fingerprint from the original text of the correction result, verifies its consistency with the local data hash value, and then uses its private key to sign the digest of the correction result to generate the upstream node signature. The verification node extracts the verification process record and re-executes the verification steps. After the verification result is consistent, it uses its private key to sign the corrected result digest to generate a verification node signature. The three signatures are combined and bound to the original text of the correction result to generate a correction result carrying the three signatures.

[0077] For example, a corrected result data structure is created, encoded in JSON format, containing multiple nested fields. The "Responsibility Attribution Node Identifier" field stores the 32-byte hash value of the newly determined responsible node, represented as a hexadecimal string, and is named "Responsibility Node Identifier". The "Responsibility Adjustment Basis" field is a nested object, containing subfields for "Disputing Party Node Identifier", "Upstream Node Identifier", "Original Responsible Node Identifier", "Ciphertext Hash Comparison Result", and "Plaintext Hash Comparison Result", and is named "Responsibility Adjustment Basis". The ciphertext hash comparison result subfield stores a Boolean value indicating whether they match, and the plaintext hash comparison result subfield also stores a Boolean value. The "Verification Result" field is a nested object, containing subfields for "Verification Timestamp", "Verification Node Identifier", "Privacy Computing Environment Identifier", "Disputing Party Ciphertext Hash Value", "Upstream Node Ciphertext Hash Value", and "Verification Log Reference", and is named "Verification Result". The fields in the corrected result original text are arranged in a predefined order to ensure that the original text generated by different nodes has a consistent byte sequence. The length of the corrected serialized original text is typically 512 to 768 bytes, depending on the encoding of the hash value and the identifier.

[0078] The serialized, corrected result byte stream is input into the SHA-256 hash algorithm. The hash calculation process maps input data of arbitrary length to a fixed-length 256-bit output, represented as a 64-byte hexadecimal string. The corrected result digest serves as input for subsequent signature operations; its value uniquely corresponds to the content of the corrected result original. Any byte change in the corrected result original will result in a completely different digest value. The corrected result digest is stored in a temporary variable, which is available for reading by participating nodes during the signature collection phase. After the digest calculation is complete, the corrected result original and the corrected result digest are sent together to the objecting node, upstream node, and verifying node. The transmission uses a secure transmission channel and Transport Layer Security (TLS) version 1.3 to ensure the confidentiality and integrity of the data within the network.

[0079] After receiving the original corrected result, the dissenting node parses the JSON structure and locates the verification result field. The verification result portion is extracted by reading the complete content of the verification result field using a JSON parser, including the verification timestamp, verification node identifier, privacy computing environment identifier, and each encrypted hash value. The dissenting node reads a stored copy of the verification result from its local record, which is returned by the verification environment and stored in the dissenting node's local database at the end of the privacy computing verification process. The local record contains the same field structure and uses the same JSON format encoding. To verify its consistency with the local record, SHA-256 hash values ​​are calculated for both the verification result portion in the original corrected result and the verification result portion in the local record, and the 64-byte content of the two hash values ​​is compared. The comparison is performed byte-by-byte, creating a consistency flag and initializing it to true. The 64 bytes are traversed, and the consistency flag is set to false if any byte differs. When the consistency flag is false, it indicates that the verification result has been tampered with; the dissenting node refuses to sign and returns error code 0x0002, which is recorded in the audit log. When the consistency flag is true, the dissenting node uses its private key to sign the modified result digest.

[0080] The private key of the dissenting node employs elliptic curve cryptography, using the P-256 standard curve as the curve parameter, and is a 256-bit random integer. The signature algorithm uses the Elliptic Curve Digital Signature Algorithm (ECDSA). The signing process first generates a random number k and calculates the elliptic curve point R = k•G, where G is the base point. The x-coordinate of R is extracted as the first part of the signature, i.e., r = xR mod q, where q is the curve order. The hash value e = SHA-256 (corrected result) of the corrected result digest is calculated. The second part of the signature, s = k⁻¹•(e + r•d) mod q, is calculated, where k⁻¹ is the multiplicative inverse of k modulo q, d is the private key, and all operations are performed modulo q. The signature result is a concatenation of (r, s), with a total length of 64 bytes; this 64-byte data constitutes the dissenting party's signature. After the dissenting party's signature is generated, it is stored in the signature response message. The response message includes a signature value field, a signature timestamp field, and a dissenting party node identifier field, and is sent back to the initiator of the corrected result.

[0081] After receiving the original correction result, the upstream node parses the JSON structure and locates the delivery data fingerprint subfield in the responsibility adjustment basis field. The delivery data fingerprint records the data hash value calculated by the upstream node when transmitting data to the dissenting node. This value is stored in the delivery data fingerprint attribute of the source node of the directed edge during the source graph construction phase. After extracting the delivery data fingerprint from the original correction result, the upstream node reads the actual delivered data copy from its local storage system. The local data copy is stored in the upstream node's archive database, which uses a timestamp index and supports retrieving historical data records by data transmission time. The upstream node calculates the SHA-256 hash value of the local data copy, obtaining a local data hash value with a length of 64 bytes. When verifying the consistency between the delivery data fingerprint and the local data hash value, a byte-by-byte comparison is performed on the two 64-byte hash values, using the same comparison method as the dissenting node's verification result. A consistency flag is created and iterated through the comparisons. If the consistency flag is false, it indicates that the delivery data fingerprint referenced in the correction result does not match the upstream node's local record. The upstream node refuses to sign and returns error code 0x0003. When the consistency flag is true, the upstream node uses its private key to sign the modified result digest, using the same signing algorithm and parameters as the dissenting node, generating a 64-byte upstream node signature. The upstream node signature is then encapsulated in a signature response message and returned.

[0082] After receiving the original corrected result, the verification node parses the JSON structure and locates the verification log reference subfield in the verification result field. The verification log reference is the location identifier of the log file generated during the verification process in the distributed storage system, including the storage node address, data block index, and offset. Based on the verification log reference, the verification node reads the complete verification process record from the storage system. The verification process record is stored in a structured log format, containing the input parameters, execution time, intermediate results, and output results for each verification step. When re-executing the verification steps, the verification node replays the steps according to the sequence recorded in the log. The replay process includes reading the ciphertext from the objecting party and the upstream node, calculating the ciphertext hash value, comparing the ciphertext hash values, reading the plaintext data fingerprint, and comparing the plaintext data fingerprint. The replay execution is performed in an isolated computing environment to ensure that the replay results are not affected by external interference. After the replay is completed, the recalculated verification result is obtained, including the ciphertext hash comparison result and the plaintext hash comparison result.

[0083] During the consistency check of the verification results, the recalculated verification results are compared with the verification results recorded in the original modified results. The comparison includes the Boolean values ​​of the ciphertext hash comparison results, the Boolean values ​​of the plaintext hash comparison results, the ciphertext hash value of the dissenting party, and the ciphertext hash value of the upstream node. An equality check is performed on each field; if all fields are equal, the verification results are considered consistent. If the verification results are inconsistent, it indicates that the verification results in the original modified results have been tampered with or the verification environment state has changed. The verification node refuses to sign and returns error code 0x0004, with a detailed description of the inconsistent fields. If the verification results are consistent, the verification node uses its private key to perform a signing operation on the modified results digest, generating a 64-byte verification node signature. After the verification node signature is generated, it is encapsulated together with the verification report in the signature response message. The verification report includes the timestamp of the replay execution, the replay environment identifier, and the replay result digest.

[0084] When combining the three-party signatures, three 64-byte signature values ​​are collected: the dissenting party's signature, the upstream node's signature, and the validator's signature. The signature values ​​are arranged in a predefined order: the dissenting party's signature is located at byte offsets 0 to 63, the upstream node's signature at byte offsets 64 to 127, and the validator's signature at byte offsets 128 to 191. These three signature values ​​are concatenated to form a 192-byte three-party signature data. The concatenation operation is implemented by copying a byte array to ensure the integrity and order of the signature values. Signature metadata, containing a signature generation timestamp, signature algorithm identifier, and signature curve parameters, is appended to the three-party signature data. This metadata is 32 bytes long and is appended to the 192-byte signature data, forming a complete 224-byte three-party signature block.

[0085] When binding the third-party signature to the original corrected result, a third-party signature field is added to the JSON structure of the original corrected result. The field name is "third-party signature," and the field value is the Base64 encoded string of the third-party signature block. Base64 encoding converts 224 bytes of binary data into approximately 299 bytes of printable characters, and the encoded string is appended to the end of the original corrected result. The original corrected result and the third-party signature field are merged and reserialized to generate the corrected result carrying the third-party signature, with a total byte length typically between 800 and 1024 bytes. The corrected result carrying the third-party signature serves as a complete proof of responsibility adjustment, possessing multi-party endorsement and non-repudiation, and can be subsequently written to the blockchain or distributed to relevant parties.

[0086] This invention constructs a multi-party consensus responsibility adjustment mechanism by having each participating node independently verify and sign the correction result, ensuring the authenticity of the correction result and the acceptance by all parties, and providing cryptographic protection for the reliable correction of responsibility positioning results.

[0087] The beneficial effects of this invention are as follows: Compared with existing technologies, this invention provides a method and system for cross-domain sharing and management of electricity marketing data based on smart contracts. It achieves secure sharing and accountability for electricity marketing data through blockchain and smart contract technologies, establishing a two-layer traceability system combining a data traceability graph and a traceability chain. This system accurately records the entire data flow process and ensures the immutability of records, effectively solving problems such as difficulty in data traceability and ambiguity in accountability determination in traditional methods. The accountability allocation mechanism, combined with the automatic execution characteristics of smart contracts, makes the accountability traceability process more objective and fair. When data anomalies occur, the responsible party can be quickly located. Simultaneously, data consistency verification is performed through privacy computing technology, avoiding misjudgment of accountability, protecting the legitimate rights and interests of all participants, and improving the transparency and credibility of electricity marketing data management. This invention achieves traceable management of the entire lifecycle of electricity marketing data. Key negotiation and encrypted communication ensure the security of the data sharing process, data fingerprint technology ensures data integrity, and the dynamic accountability adjustment mechanism improves the flexibility and accuracy of accountability traceability. Overall, it promotes the standardized management and efficient utilization of electricity marketing data.

[0088] This invention can be a system, method, and / or computer program product. This invention also discloses a smart contract-based cross-domain sharing management system for electricity marketing data, based on the aforementioned smart contract-based cross-domain sharing management method, comprising: The key negotiation and data preparation unit is used to establish an encrypted communication channel between multiple participating nodes in cross-domain data sharing through key negotiation, encrypt and encapsulate the acquired power marketing data and construct a traceability map, and generate an operation record containing the identity signature of the operation subject and the data fingerprint for each operation node. The contract deployment unit is used to generate a smart contract containing traceability query logic and responsibility location logic based on the traceability graph and deploy it to the blockchain network, and write the operation record into the blockchain network to form a traceability chain; The source tracing and responsibility location unit is used to extract associated operation records from the source tracing chain when it is necessary to trace the source of target data, verify the signature, and then traverse the source tracing graph in reverse to obtain the source tracing path. The unit determines the responsibility type of the operation nodes in the source tracing path based on the responsibility division rules. When data anomalies are detected, the unit performs traceability and location by comparing data fingerprints and generates responsibility location results. The correction unit is used to verify the consistency between the input data received by the objecting party and the upstream delivered data through privacy computation when the operating entity raises an objection to the responsibility positioning result. If the verification result shows that the input data was abnormal when it was received, the responsibility tracing process is triggered to dynamically adjust the responsibility division, generate a correction result and write it into the blockchain network.

[0089] Based on the spirit of this invention, those skilled in the art will readily conceive of a computer program product derived from the aforementioned smart contract-based cross-domain sharing management method for electricity marketing data. The computer program product may include a computer-readable storage medium on which computer-readable program instructions are loaded to enable a processor to implement various aspects of this disclosure. Specifically, this application also includes a terminal comprising a processor and a storage medium; the storage medium is used to store instructions; the processor is used to operate according to the instructions to execute the steps of the aforementioned smart contract-based cross-domain sharing management method for electricity marketing data.

[0090] Computer-readable storage media can be tangible devices capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination of the foregoing. The computer-readable storage media used herein are not to be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0091] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0092] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0093] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the protection scope of the claims of the present invention.

Claims

1. A method for managing cross-domain sharing of power marketing data based on a smart contract, characterized in that, The method comprises the following steps: establishing an encrypted communication channel between multiple participating nodes in cross-domain data sharing through key negotiation, encrypting and encapsulating the obtained power marketing data, and constructing a traceability graph, and generating an operation record for each operation node, which contains an operation subject identity signature and a data fingerprint; generating an intelligent contract containing traceability query logic and responsibility positioning logic according to the traceability graph and deploying it to a blockchain network, and writing the operation record to the blockchain network to form a traceability chain; when it is necessary to trace the target data, extracting the associated operation record from the traceability chain, verifying the signature, and obtaining a traceability path by reverse traversal of the traceability graph, judging the responsibility type of the operation node in the traceability path based on the responsibility division rule, and executing tracing positioning by comparing the data fingerprints when data anomalies are detected, and generating a responsibility positioning result; when the operation subject raises an objection to the responsibility positioning result, verifying the consistency of the input data received by the objector with the upstream delivery data through privacy calculation, if the verification result shows that the input data has been abnormal when received, triggering a responsibility tracing process to dynamically adjust the responsibility division, generating a correction result and writing it to the blockchain network.

2. The method of claim 1, wherein, The method further comprises the following steps: extracting the operation subject identifier, operation type and data content from the power marketing data, and performing hash chain association between the data fingerprint of the current operation node and the data fingerprint of the previous operation node to form a data dependency relationship between nodes; constructing a traceability graph according to the data dependency relationship, the traceability graph taking operation nodes as vertices and data flow direction as directed edges, and recording the data fingerprint delivered by the source node and the data fingerprint received by the target node on each directed edge; generating an operation record for each operation node, the operation record containing an operation subject identity signature, a data fingerprint of the current node and a data fingerprint of the previous node, and encrypting and encapsulating the operation record after digitally signing it by the private key of the operation subject; storing the encrypted and encapsulated operation record in association with the corresponding node in the traceability graph, and performing cross verification between the data fingerprint in the operation record and the data fingerprint recorded on the directed edge, which is used to judge the introduction position of data anomalies by comparison during subsequent tracing.

3. The method of claim 1, wherein, The method further comprises the following steps: extracting the directed edge relationship and data fingerprint association relationship between nodes from the traceability graph, mapping the directed edge relationship to the path traversal rule of the traceability query logic, and mapping the data fingerprint association relationship to the fingerprint comparison rule of the responsibility positioning logic; generating traceability query logic according to the path traversal rule, the traceability query logic receiving a target data identifier and obtaining a traceability path containing a complete operation node sequence by reverse traversal along the directed edges of the traceability graph; According to the fingerprint comparison rule, a responsibility locating logic is generated, the responsibility locating logic receives the traceability path, compares the data fingerprint delivered by the source node and the data fingerprint received by the target node for each directed edge in the traceability path, and marks the target node of the directed edge as a responsible node when the two data fingerprints are inconsistent; The traceability query logic and the responsibility locating logic are encapsulated to generate a smart contract and deployed to a blockchain network, operation records are written into the blockchain in a time sequence of the traceability graph to form a traceability chain, and the smart contract performs traceability query and responsibility locating by calling operation records in the traceability chain.

4. The method of claim 1, wherein, When traceability of target data is required, the associated operation records are extracted from the traceability chain, the signature is verified, and the traceability path is obtained by reverse traversal of the traceability graph, further comprising: According to the identification of the target data, the operation record containing the identification of the target data is retrieved from the traceability chain as a starting operation record; The identity signature and data fingerprint of the operation subject are extracted from the starting operation record, the identity signature is verified using the public key of the operation subject, and the data fingerprint in the starting operation record is compared with the data fingerprint received by the target node recorded on the corresponding directed edge in the traceability graph, and when the identity signature is verified and the two data fingerprints are consistent, the starting operation record is marked as a valid record; According to the pre-node data fingerprint contained in the starting operation record, the pre-operation record is retrieved from the traceability chain, and the identity signature verification and data fingerprint comparison verification are performed on the retrieved pre-operation record, and when the verification is passed and the data fingerprints are consistent, the pre-operation record is marked as a valid record, the pre-node data fingerprint in the pre-operation record is extracted to continue to retrieve forward, and the retrieval and verification process is repeated until the source operation record is reached. All operation records verified between the source operation record and the starting operation record are organized in a time sequence to form a traceability path containing a complete operation node sequence.

5. The method of claim 4, wherein, The operation nodes in the traceability path are judged based on the responsibility division rule to determine the responsibility type, and when data anomalies are detected, the responsibility locating result is generated by comparing the data fingerprints, further comprising: The operation type and data processing authority of each operation node are extracted from the traceability path, the responsibility type of the operation node in the data flow process is determined according to the combination relationship of the operation type and the data processing authority combined with the position of the operation node in the traceability graph, and the responsibility type includes data generation responsibility, data transmission responsibility and data receiving responsibility; The operation nodes in the traceability path are traversed, the data fingerprint delivered by the source node and the data fingerprint received by the target node recorded on the corresponding directed edge of each operation node are compared, and when the comparison result is inconsistent, it is determined that data anomalies occur; For the directed edge where data anomalies occur, the target node of the directed edge is marked as an abnormal node, the responsibility type of the abnormal node is extracted from the traceability path, the introduction position of the data anomaly is determined according to the responsibility type of the abnormal node and the position of the directed edge where the data fingerprints are inconsistent, and the responsibility attribution is determined. The node identifier of the abnormal node, the responsibility type of the abnormal node, and the responsibility attribution organization generate a responsibility positioning result.

6. The method of claim 1, wherein, When the operation subject objects to the responsibility positioning result, the consistency of the input data received by the objecting party with the upstream delivery data is verified through privacy calculation, and if the verification result indicates that the input data has been abnormal when received, a responsibility upstream process is triggered to dynamically adjust the responsibility division, generate a revised result, and write it to the blockchain network, further comprising: Locate the objecting party node and its predecessor nodes as upstream nodes from the node identifier in the objection request in the traceability path; upload the data stored locally by the objecting party node and the upstream nodes to the verification environment after homomorphic encryption; calculate and compare the ciphertext hash values in the ciphertext state, and confirm that the data has changed in the transmission process when the ciphertext hash values are inconsistent; Extract the data fingerprint recorded on the directed edge corresponding to the objecting party node from the traceability path, and compare it with the plaintext hash value of the local data of the objecting party. When they are consistent, the result of the inconsistent ciphertext hash value is combined to confirm that the input data has been abnormal when received; Trigger the responsibility upstream process, re-execute data fingerprint comparison and responsibility type judgment for the sequence from the upstream node to the source node, and re-determine the responsibility attribution node; organize the responsibility attribution node identifier, responsibility adjustment basis, and verification result to generate a revised result, and call the objecting party node, upstream node, and verification node to generate three-party signatures on the revised result; When the three-party signature verification is passed, the revised result carrying the three-party signature is written into the blockchain, and the responsibility positioning record in the traceability chain is updated.

7. The method of claim 6, wherein, The calling of the objecting party node, the upstream node, and the verification node to generate three-party signatures on the revised result further comprises: Organize the responsibility attribution node identifier, responsibility adjustment basis, and verification result to form a revised result original text, and generate a revised result digest by hashing the revised result original text; The objecting party node extracts the verification result part in the revised result original text, verifies its consistency with the local record, and then signs the revised result digest using a private key to generate an objecting party signature; The upstream node extracts the delivery data fingerprint in the revised result original text, verifies its consistency with the local data hash value, and then signs the revised result digest using a private key to generate an upstream node signature; The verification node extracts the verification process record and re-executes the verification steps, and generates a verification node signature using a private key after verifying the consistency of the verification result; Combine the three-party signatures and bind them with the revised result original text to generate a revised result carrying the three-party signatures.

8. A smart contract-based power marketing data cross-domain sharing management system for implementing the method of any one of the preceding claims 1-7, characterized in that, It includes: A key negotiation and data preparation unit for establishing an encrypted communication channel between multiple participating nodes in cross-domain data sharing through key negotiation, encrypting and packaging the obtained power marketing data, and building a traceability graph, and generating an operation record for each operation node containing the operation subject identity signature and data fingerprint; A contract deployment unit for generating a smart contract containing traceability query logic and responsibility positioning logic according to the traceability graph and deploying it to a blockchain network, and writing the operation record to the blockchain network to form a traceability chain; A traceability and responsibility positioning unit is configured to extract associated operation records from the traceability chain when traceability of target data is required, verify signatures, and then traverse the traceability graph in reverse to obtain a traceability path. Based on responsibility division rules, the responsibility type of operation nodes in the traceability path is determined. When data anomalies are detected, tracing and positioning are performed by comparing data fingerprints to generate a responsibility positioning result. A correction unit is configured to, when an operation subject raises objections to the responsibility positioning result, verify the consistency of input data received by the objector with upstream delivery data through privacy calculation. If the verification result indicates that the input data has been abnormal since it was received, a responsibility tracing process is triggered to dynamically adjust the responsibility division, a correction result is generated, and the correction result is written to the blockchain network.

9. An electronic device, comprising: The computer program instructions are executed by the processor to implement the method of any one of claims 1 to 7. The computer program instructions are executed by the processor to implement the method of any one of claims 1 to 7. The computer program instructions are executed by the processor to implement the method of any one of claims 1 to 7. ​ 10. A computer-readable storage medium having stored thereon computer program instructions, wherein, ​

Images