Data traceability methods, devices, electronic equipment and storage media in the power industry

Abstract

This invention relates to the field of blockchain technology and provides a method, apparatus, electronic device, and storage medium for data traceability in the power industry. The implementation scheme is as follows: Power business data from various participants in different business domains are acquired; based on a multi-layer hash fusion algorithm, corresponding data fingerprints are generated for the power business data of each participant, resulting in individual data fingerprints; consensus processing is performed on each data fingerprint and the associated business events through a pre-defined group fault-tolerant consensus network to generate blocks, and the blocks are written to the blockchain ledger; in response to a traceability request from a target participant, cross-domain traceability is performed in the blockchain ledger based on the target data fingerprint in the traceability request, resulting in candidate traceability events; each candidate traceability event is verified to obtain each target traceability event; and a cross-domain semantic traceability graph is constructed based on each target traceability event. This invention improves the reliability and accuracy of cross-domain traceability in the power industry.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a data traceability method, device, electronic device, and storage medium for the power industry. Background Technology

[0002] As the power system continues to evolve towards digitalization and intelligence, power operations are increasingly characterized by cross-regional, cross-organizational, and cross-system collaborative operations. A complete power business event (such as grid fault handling or renewable energy consumption dispatch) typically requires the collaborative participation of multiple business domains, including generation, transmission, distribution, and sales, and involves multiple stakeholders such as grid companies, power generation companies, electricity users, and regulatory agencies. Therefore, effectively tracing the entire lifecycle of business events during their generation, flow, and handling is of great significance for optimizing business processes, supporting operational decisions, and meeting regulatory audit requirements.

[0003] However, current technologies for tracing power business data mainly rely on centralized databases or log recording mechanisms within a single business domain. Since the data of each participant is typically stored in independent business systems, forming isolated data silos, not only are the data structures and coding rules inconsistent, but also, due to data sovereignty and security / privacy restrictions, it is difficult to centrally aggregate and share the original business data. This results in incomplete information chains and inaccurate tracing results during cross-domain tracing.

[0004] On the other hand, traceability methods based on centralized databases or traditional logs generally suffer from single-point control problems. Their traceability records are easily tampered with, deleted, or denied afterward. The lack of a credible evidence storage mechanism that is recognized by multiple parties makes it difficult for different participants to reach a consensus on the authenticity and consistency of traceability results, thereby reducing the credibility and accuracy of cross-domain traceability in power business. Summary of the Invention

[0005] This invention provides a data traceability method, device, electronic device, and storage medium for the power industry, which can solve at least one of the above-mentioned technical problems.

[0006] In a first aspect, embodiments of the present invention provide a data traceability method for the power industry, comprising: Acquire power business data from various participants in each business domain; Based on the multi-layer hash fusion algorithm, corresponding data fingerprints are generated for the power business data of each of the participants, thus obtaining each data fingerprint; A pre-defined group fault-tolerant consensus network is used to process the consensus of each data fingerprint and the business events associated with the data fingerprint to generate blocks, and the blocks are written into the blockchain ledger. In response to a traceability request from a target participant, cross-domain traceability is performed in the blockchain ledger based on the target data fingerprint in the traceability request to obtain various candidate traceability events; Each candidate tracing event is verified to obtain each target tracing event; Based on each of the target tracing events, a cross-domain semantic tracing graph is constructed, and the cross-domain semantic tracing graph is sent to the target participants.

[0007] Secondly, embodiments of the present invention provide a data traceability device for the power industry, comprising: The data acquisition module is used to acquire power business data from various participants in various business domains; The fingerprint generation module is used to generate corresponding data fingerprints for the power business data of each of the participating parties based on a multi-layer hash fusion algorithm, thereby obtaining each data fingerprint; The consensus processing module is used to perform consensus processing on each data fingerprint and the business events associated with the data fingerprint through a preset group fault-tolerant consensus network to generate blocks and write the blocks into the blockchain ledger. The cross-domain tracing module is used to respond to the tracing request of the target participant, and perform cross-domain tracing in the blockchain ledger based on the target data fingerprint in the tracing request to obtain various candidate tracing events; The verification module is used to verify each of the candidate traceability events to obtain each target traceability event; The construction module is used to construct a cross-domain semantic traceability graph based on each of the target traceability events, and send the cross-domain semantic traceability graph to the target participants.

[0008] Thirdly, embodiments of the present invention also provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method described in any one of the embodiments of the present invention.

[0009] Fourthly, embodiments of the present invention also provide a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to perform the method described in any one of the embodiments of the present invention.

[0010] This invention employs a multi-layer hash fusion algorithm to generate corresponding data fingerprints for each power business data point based on the acquired power business data from various participants across different business domains. This data fingerprint provides a unique identifier for each data point. A pre-defined group fault-tolerant consensus network is used to process the data fingerprints and their associated business events, ensuring not only the legality and consistency of the data on the blockchain but also establishing a trusted basis recognized by multiple parties through on-chain notarization. Subsequently, for cross-domain tracing requests, candidate tracing events are retrieved from the blockchain ledger based on the target data fingerprint, and the target tracing event is selected through a verification mechanism, thus preventing abnormal or tampered events from affecting the tracing results. Finally, each target tracing event is constructed into a cross-domain semantic tracing graph. This approach ensures the authenticity and integrity of data throughout the entire chain, from data source and notarization process to tracing analysis, effectively improving the credibility and accuracy of cross-domain tracing in power business.

[0011] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0012] The accompanying drawings are provided for a better understanding of this solution and do not constitute a limitation of the invention. Wherein: Figure 1 This is a flowchart of a data traceability method for the power industry according to an embodiment of the present invention; Figure 2 This is a structural block diagram of a power industry data traceability device according to an embodiment of the present invention; Figure 3 This is a schematic block diagram of an electronic device used to implement the methods of embodiments of the present invention. Detailed Implementation

[0013] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention, including various details to aid understanding. These details should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0014] In a specific application scenario, the power industry data traceability method of this invention is applied to a power industry data traceability system. This system is deployed on a consortium blockchain network and includes a data access layer, a blockchain notarization layer, an off-chain storage and indexing layer, and a traceability query and regulatory interface layer. The data access layer receives power business data from various sources such as power plants, substations, dispatch centers, and electricity sales companies. It standardizes the multi-source heterogeneous data and generates corresponding unique data fingerprint identifiers (FIDs). Each entity with data upload permissions is considered an access node, and a node certificate and an asymmetric key pair (public key (PK) and private key (SK)) are issued to it by the consortium blockchain certificate authority (CA) for node authentication and data signing. After data collection, the node digitally signs the data or its fingerprint and uploads the original data (or encrypted data), data fingerprint, node certificate, and signature to the system. The data access gateway performs certificate verification, signature verification, and permission verification on upload requests to ensure that the uploaded data is legal and valid, and writes the verified data fingerprint, node identifier (ID), timestamp, and signature verification result into the blockchain.

[0015] The blockchain notarization layer is used to build a traceability ledger for electricity data based on a consortium blockchain. It encapsulates each data fingerprint and its associated business events into blockchain transactions, and uses a modified Practical Byzantine Fault Tolerance (PBFT) group fault-tolerant consensus mechanism for consensus processing. The block header records the block number, the hash of the previous block, the Merkle root, the timestamp, and the consensus signature. The block body stores the event data and signature verification information. Through blockchain notarization, the immutability and verifiability of the data source and flow process are achieved, and each electricity data event can be uniquely located through the block hash.

[0016] The off-chain storage and indexing layer is used to store the original power data using distributed storage systems such as Hadoop Distributed File System (HDFS), InterPlanetary File System (IPFS), Ceph Distributed Storage System (Ceph), or MinIO Object Storage System (MinIO). On-chain storage only retains the data hash, version number, Merkle Root, and storage location index, achieving a precise correspondence between the data fingerprint and the original data through on-chain / off-chain mapping. The system supports encrypted data storage, generating sharded file blocks and corresponding metadata, and creating an on-chain index record for each data point, achieving "on-chain / off-chain binding." Simultaneously, the system periodically performs consistency checks, comparing the off-chain data hash with the on-chain record. When anomalies are detected, alarms are triggered and the anomaly event is recorded to the blockchain, achieving tamper-proof verification. For updated data, the system records difference snapshots, generates a version graph, and allows recovery of a specified version via a smart contract interface, enabling difference tracing and version recovery.

[0017] The traceability query and regulatory interface layer provides a unified traceability query interface, supporting retrieval based on data fingerprints or authorization records. The system automatically generates a data lifecycle traceability chain, including events such as upload, access, sharing, update, and revocation, and verifies the signature and block hash of each record through smart contracts to ensure the chain's integrity and trustworthiness. Users can query the complete event chain and corresponding block height via FID, and the system also supports multi-version data comparison, version graph generation, and difference tracing, providing regulatory authorities and enterprises with visualized auditing and liability determination evidence.

[0018] Figure 1 This is a flowchart of a data traceability method for the power industry according to an embodiment of the present invention.

[0019] like Figure 1 As shown, this power industry data traceability method may include: S110, acquire power business data of each participant in each business domain; S120, based on a multi-layer hash fusion algorithm, generates corresponding data fingerprints for the power business data of each participant, thus obtaining each data fingerprint; S130 uses a pre-defined group fault-tolerant consensus network to process consensus on each data fingerprint and the business events associated with the data fingerprint to generate blocks and write the blocks into the blockchain ledger. S140, in response to the traceability request from the target participant, performs cross-domain traceability in the blockchain ledger based on the target data fingerprint in the traceability request, and obtains each candidate traceability event; S150, Verify each candidate traceability event to obtain each target traceability event; S160: Based on each target tracing event, construct a cross-domain semantic tracing graph and send the cross-domain semantic tracing graph to the target participants.

[0020] For example, a business domain refers to different areas in a power system that are divided according to function or management scope, such as the generation business domain, transmission business domain, distribution business domain, and sales business domain.

[0021] For example, a participant refers to an entity that generates or uses electricity data within its business domain, such as a power plant, substation, distribution network operator, electricity sales company, or large electricity consumer.

[0022] For example, power business data refers to data related to power operation generated by participants in their business activities, such as real-time power generation of generator sets, load data of substations, current and voltage data of distribution networks, and user electricity consumption information of electricity sales companies.

[0023] In this example, a data acquisition interface is deployed in the participating systems of each business domain to automatically collect power business data. The power industry data traceability system collects power business data by calling the data acquisition interface and formats and standardizes the collected data, including unifying timestamps, unit conversions (such as kilowatt-hours (kWh), megawatts (MW), etc.), and unifying field naming. Subsequently, the power industry data traceability system performs integrity verification and anomaly detection on the received data, removing missing or outlier values ​​to ensure data accuracy. Finally, the processed data is stored in a temporary cache or database for subsequent data fingerprint generation and blockchain on-chain operations.

[0024] For example, power business data, such as {Subject: "Power Grid Company A", Operation: "Shared", Time: "10:05", Raw Data: {User ID: "User001", ...}}.

[0025] For example, a target data fingerprint refers to a unique identifier generated based on specific power business data through a multi-layer hash fusion algorithm, used to uniquely identify the data on the blockchain. For instance, if power plant A generates 100MW of power on January 1, 2026 at 10:00, its data fingerprint could be “0xA12B3C…” (represented by a hash value).

[0026] For example, a candidate traceability event refers to the set of all historical business events that may be related to the target data after querying the target data fingerprint in the blockchain ledger, including events across business domains. For instance, the events that may be associated with the power generation information corresponding to the target data fingerprint include generator scheduling events, transmission line load events, and electricity sales user settlement events.

[0027] For example, the target traceability event refers to the event determined after verifying the candidate traceability events (e.g., data integrity, time sequence, business logic consistency). For example, the events determined after verification are the power generation dispatch record of power plant A at 10:00 and the actual load event of transmission line L1.

[0028] For example, a cross-domain semantic traceability graph refers to a graph structure that represents the target traceability event and its cross-business domain relationships, including nodes (events, participants, data fingerprints) and edges (causal or data relationships between events).

[0029] According to the above implementation method, by acquiring power business data from each participant in each business domain, generating corresponding data fingerprints based on a multi-layer hash fusion algorithm, and then using a pre-defined group fault-tolerant consensus network to perform consensus processing on each data fingerprint and its associated business events to generate blocks and write them into the blockchain ledger, the immutability and reliable storage of data are achieved. When responding to a traceability request from a target participant, cross-domain traceability is performed in the blockchain ledger based on the target data fingerprint, and candidate traceability events are verified to obtain the target traceability event. Finally, a cross-domain semantic traceability graph is constructed and sent to the target participant, thereby achieving cross-domain data traceability and visualized analysis of data flow. Simultaneously, the consensus mechanism and group fault-tolerant characteristics of the blockchain enhance data credibility and accuracy.

[0030] In one implementation, based on a multi-layer hash fusion algorithm, corresponding data fingerprints are generated for the power business data of each participant to obtain each data fingerprint. This includes: performing the following data fingerprint calculations on the power business data of each participant: performing a hash operation on the power business data to obtain a data content summary; extracting business feature data and acquisition node identifiers from the power business data; concatenating the data content summary, business feature data, and acquisition node identifiers to obtain a first concatenated feature; performing a hash operation on the first concatenated feature to obtain a business-aware summary; concatenating the business-aware summary, the timestamp corresponding to the power business data, and a randomly generated perturbation factor to obtain a second concatenated feature; and performing a hash operation on the second concatenated feature to obtain the data fingerprint corresponding to the power business data.

[0031] For example, the core raw data content of the power business data to be processed is serialized into a standard byte stream. This byte stream is then used as input and sent to a pre-defined secure hash algorithm module (such as Secure Hash Algorithm 256-bit (SHA-256)). This module performs a complete hash calculation on the input byte stream, resulting in a fixed-length hexadecimal string, which is a data content digest that uniquely represents the raw data content (power business data).

[0032] For example, the process of generating a data content summary can be expressed as follows: In the formula, A summary of the data content; For power business data; Hash algorithm.

[0033] For example, business characteristic data refers to key information extracted from power business data that can characterize business status, operational characteristics, or key indicators, and is used to describe the core content and business semantics of power business data.

[0034] For example, in the power generation business domain, if power plant A generates 120MW of electricity at 10:00 on February 5, 2026, the corresponding business characteristic data can be "power generation 120MW"; in the distribution business domain, if the line load of substation B is 80 amperes (A), the business characteristic data can be "line load 80A".

[0035] For example, a data acquisition node identifier refers to a code or identifier used to uniquely identify the source of power business data acquisition, indicating the data acquisition location, acquisition equipment, or acquisition system.

[0036] For example, the data acquisition node identifier for power plant A is “NodeA001”, the acquisition node identifier for substation B is “NodeB005”, and the node identifier for electricity sales company C used to collect user electricity consumption is “NodeC102”.

[0037] In this example, business feature data that can characterize its business semantics and acquisition node identifiers that identify the data source are extracted from power business data according to preset rules. Then, the data content summary, the extracted business feature data, and the acquisition node identifier are concatenated in a fixed order to form a string containing multi-dimensional information, which is the first concatenated feature. Finally, a secure hash operation (hash algorithm) is performed on the first concatenated feature string again, and the resulting hash value is the business-aware summary.

[0038] For example, the process of generating a business-aware summary can be represented by the following expression: In the formula, For business-aware summary; A summary of the data content; For business characteristic data; This is the identifier for the data acquisition node.

[0039] For example, the system generates a high-precision random number or string as the perturbation factor (i.e., salt value) for this calculation. Then, the business-aware summary, the timestamp extracted from the power business data, and this newly generated perturbation factor are concatenated into a second concatenated feature. Finally, a secure hash operation is performed on this second concatenated feature, and the hash value obtained from this operation is the data fingerprint corresponding to the power business data.

[0040] For example, the process of generating a data fingerprint can be represented by the following expression: In the formula, For data fingerprinting; For business-aware summary; For timestamps; This is the disturbance factor.

[0041] According to the above implementation method, for the power business data of each participating party, a data fingerprint is generated through multi-stage hashing and feature concatenation. The specific process includes: first, performing a hash operation on the power business data to obtain a data content summary, and then extracting key business features and acquisition node identifiers from the data, concatenating them to form a first concatenated feature; subsequently, performing a hash operation on the first concatenated feature to obtain a business-aware summary; then, concatenating the business-aware summary with a data timestamp and a random perturbation factor to form a second concatenated feature; finally, performing a hash operation on the second concatenated feature to obtain the data fingerprint corresponding to the power business data. The technical advantage of this method is that it can generate a unique and tamper-proof identifier for each piece of business data, improving data security and trustworthiness. At the same time, the embedding of business features and timestamps enables data traceability and business semantic awareness. The introduction of random perturbation factors further enhances the fingerprint's anti-counterfeiting and privacy protection capabilities, which is conducive to secure and efficient cross-domain data management and traceability in blockchain or distributed environments.

[0042] In one implementation, a pre-defined group fault-tolerant consensus network is used to process consensus on each data fingerprint and the associated business events to generate blocks, and the blocks are written into the blockchain ledger. The group fault-tolerant consensus network consists of core nodes, group leader nodes, and ordinary nodes, and includes: determining each transaction to be uploaded to the blockchain based on each data fingerprint and the associated business events; calling each ordinary node to submit each transaction to the group leader node to which it belongs, so that each group leader node performs local Byzantine fault-tolerant voting on each transaction within its group to generate candidate block digests; calling each core node to receive the candidate block digests sent by each group leader node and perform global Byzantine fault-tolerant voting on each candidate block digest to generate blocks; broadcasting the blocks and writing them into the blockchain ledger.

[0043] For example, a regular node refers to a blockchain node deployed in various business domains or on the side of each participant, used to receive transactions to be uploaded to the blockchain and submit them to the corresponding group leader node. Its main function is to collect transactions and forward them initially.

[0044] For example, a node set up in the power plant's data center is used to submit the transaction to be uploaded to the blockchain from the fingerprint of power generation data and its associated business events to the group leader node of its respective group.

[0045] For example, a group leader node refers to a blockchain node selected within the same group to aggregate transactions submitted by ordinary nodes within the group that are to be uploaded to the blockchain, and to perform local Byzantine fault-tolerant voting on the transactions to be uploaded to the blockchain within the group to generate candidate block digests. Its main function is to undertake group-level consensus processing.

[0046] For example, in the group corresponding to the power transmission business domain, a high-performance server is set up as the group leader node to vote on the transactions to be uploaded to the blockchain submitted by each substation node in the group and generate candidate block digests.

[0047] For example, a core node refers to a blockchain node that receives candidate block digests sent by each group leader node and performs global Byzantine fault-tolerant voting on each candidate block digest to generate the final block. Its main function is to maintain global consistency across groups.

[0048] For example, nodes deployed in provincial power grid dispatch centers serve as core nodes, used to conduct unified voting on candidate block summaries from power generation, transmission, and distribution groups and generate the final block.

[0049] For example, the metadata (such as event type, timestamp, subject identifier, etc.) of the data fingerprint and the associated business event is encapsulated to create a standard-format digital object. This digital object, containing complete on-chain credential information, is a transaction to be uploaded to the blockchain. By encapsulating each data fingerprint and its associated business event in the aforementioned manner, each transaction to be uploaded to the blockchain can be obtained.

[0050] For example, a data fingerprint "0x1a2b..." is generated for a "shared" business event. The system then encapsulates the fingerprint and the metadata of the business event associated with it, {type: "shared", timestamp: "..."}, together to form a JavaScript Object Notation (JSON) format transaction to be added to the blockchain: {"fid": "0x1a2b...", "metadata": {...}}.

[0051] For example, firstly, transactions to be uploaded to the blockchain are distributed to their respective ordinary nodes belonging to different business domains based on the node identifiers in the transactions to be uploaded. Then, each ordinary node submits a batch of transactions to be uploaded, each with its own business domain attributes, as a transaction set to the group leader node corresponding to its business domain. After collecting all transactions submitted by ordinary nodes within its managed business domain, each group leader node verifies and summarizes these transactions from the same business domain, and broadcasts a consensus proposal containing this batch of transactions from the same domain only to the ordinary nodes within its group. After verifying the proposal, each node in the group signs and votes on it. When the number of votes indicating agreement collected by the group leader node reaches a preset fault tolerance threshold (e.g., two-thirds of the total number of nodes in the group), local consensus is reached within that business domain. Subsequently, the group leader node calculates the Merkle Tree (Merkle or Merkle Tree) root hash of this batch of transactions that have reached local consensus and are from the same domain, and encapsulates it into a candidate block digest that can represent the entire contribution of that business domain in this round of consensus.

[0052] For example, in a certain round of on-chain processing, there are three transactions to be uploaded to the blockchain: Power plant A reports power generation data at 10:00, with the corresponding collection node identifier being Node_Gen_A; Substation B reports line load data at 10:01, with the corresponding collection node identifier being Node_Trans_B; and Distribution station C reports user electricity consumption data at 10:02, with the corresponding collection node identifier being Node_Dist_C. The system first distributes the transaction from power plant A to the ordinary node corresponding to the power generation business domain, the transaction from substation B to the ordinary node corresponding to the power transmission business domain, and the transaction from distribution station C to the ordinary node corresponding to the power distribution business domain, based on the collection node identifiers of the three transactions to be uploaded to the blockchain. Subsequently, ordinary nodes in the power generation business domain submit the "power generation reporting" transactions they receive as a transaction set to the group leader node of the power generation business domain; ordinary nodes in the transmission business domain submit the "line load reporting" transactions to the group leader node of the transmission business domain; and ordinary nodes in the distribution business domain submit the "user electricity consumption reporting" transactions to the group leader node of the distribution business domain.

[0053] After collecting transactions submitted by all ordinary nodes within its power generation business domain, the leader node performs legality and format verification on these power generation-related transactions and broadcasts a consensus proposal containing only power generation transactions to the ordinary nodes within the power generation business domain. Ordinary nodes within the group verify the proposal and generate signature votes. When the number of agreeing votes collected by the leader node reaches a preset threshold (e.g., two-thirds of the total number of nodes in the group), a local consensus within the power generation business domain is considered to have been reached. Subsequently, the leader node constructs a Merkle tree for the power generation transactions that have reached a local consensus and calculates the root hash value H_gen of the Merkle tree. This root hash value is then encapsulated into a candidate block digest, representing the total transaction contribution of the power generation business domain in this round of consensus.

[0054] Similarly, after the leader node of the transmission business domain reaches a partial consensus on line load transactions, it calculates the corresponding Merkle root hash value H_trans; after the leader node of the distribution business domain reaches a partial consensus on user electricity consumption transactions, it calculates the corresponding Merkle root hash value H_dist. Therefore, the three candidate block digests H_gen, H_trans, and H_dist represent the transaction results of the generation business domain, transmission business domain, and distribution business domain in this round of consensus, respectively.

[0055] For example, all group leader nodes send candidate block digests to the core node layer, which consists of the most trusted nodes in the network. After receiving multiple candidate block digests from different groups, each core node in the core node layer elects a master node, which proposes a new block containing these digests. Subsequently, all core nodes perform a complete global Byzantine Fault Tolerance (BFT) consensus protocol regarding the legitimacy and order of this new block. When the number of votes indicating agreement among the core nodes reaches the fault tolerance threshold, global consensus is reached, and a new block containing multiple group digests and confirmed at the highest level across the network is officially generated.

[0056] For example, the leader nodes LA, LB, and LC each send their respective candidate block digests to all core nodes. The core nodes then vote globally using BFT to agree to include the digests of LA and LB in the next block. Once consensus is reached, a new block #101 containing both digests is successfully generated.

[0057] For example, after a new block is successfully generated at the core node layer, it is broadcast to all nodes in the consortium blockchain (including all core nodes, leader nodes, and ordinary nodes) via a P2P network protocol. Each node in the network, upon receiving the new block, verifies its legitimacy, including checking the block's hash value, signature, and its link to the previous block. After successful verification, each node appends the new block to the end of its locally stored copy of the blockchain. This process completes the network-wide synchronization and persistent writing of the new block, ensuring the consistency of the ledgers for all participants.

[0058] For example, the core node broadcasts the newly generated block #101 to the entire network. Upon receiving it, ordinary node A1 verifies its legitimacy and then links it to its locally stored block #100. At this point, block #101 is officially written into the blockchain ledger, and the transaction initially submitted by A1 is finally recorded on-chain.

[0059] According to the above implementation method, transactions to be uploaded to the blockchain are determined based on each data fingerprint and its associated business events. Ordinary nodes submit the transactions to be uploaded to their respective group leader nodes. The group leader nodes then perform local Byzantine fault-tolerant voting on the transactions within their groups to generate candidate block digests. The core nodes then receive the candidate block digests sent by each group leader node and perform global Byzantine fault-tolerant voting to generate blocks. Finally, the blocks are broadcast and written into the blockchain ledger. This achieves collaborative work between transaction processing and block generation through a grouped and hierarchical consensus structure. This reduces the number of nodes participating in a single consensus, improves consensus efficiency, and enhances the reliability and consistency of the system in the presence of malicious nodes or node failures through local and global two-level Byzantine fault-tolerant mechanisms. This, in turn, improves the security, stability, and scalability of power business data uploaded to the blockchain.

[0060] In one implementation, in response to a traceability request from a target participant, cross-domain traceability is performed in the blockchain ledger based on the target data fingerprint in the traceability request to obtain various candidate traceability events. This includes: using the target data fingerprint in the traceability request as an index key, querying the source event corresponding to the target data fingerprint from a preset blockchain cross-domain index table; starting from the source event and using the target data fingerprint as a global association identifier, querying the on-chain events corresponding to the global association identifier in each business domain in parallel to obtain various on-chain events; and determining various candidate traceability events based on the various on-chain events.

[0061] For example, the blockchain cross-domain index table may include the following fields: a target data fingerprint field, used to store the data fingerprint corresponding to the power business data; a business domain identifier field, used to identify the business domain to which the data fingerprint belongs, such as the power generation business domain, transmission business domain, or distribution business domain; a source event identifier field, used to record the business event number that is first associated with the data fingerprint; a block height field, used to indicate the block height of the block where the source event is located; a transaction hash field, used to indicate the on-chain transaction identifier corresponding to the source event; and a participant identifier field, used to identify the participant that generated the data fingerprint.

[0062] For example, a certain index entry could be: target data fingerprint is F123, business domain identifier is power generation business domain, source event identifier is E001, block height is Block_256, transaction hash is TX_A9B8, and participant identifier is power plant A.

[0063] For example, a candidate traceability event refers to a set of on-chain business events that are associated with the target data fingerprint and are obtained by querying the blockchain ledgers corresponding to each business domain, using the target data fingerprint as a global association identifier. These events are used as the initial event set for subsequent verification processing.

[0064] For example, if the target data fingerprint is F123 and the corresponding source event is the "power generation reporting" event of power plant A, then the "line load dispatching" event associated with F123 can be found in the transmission business domain, and the "user electricity consumption settlement" event associated with F123 can be found in the distribution business domain. The above "power generation reporting" event, "line load dispatching" event and "user electricity consumption settlement" event together constitute the candidate traceability event set.

[0065] In this example, firstly, the target data fingerprint, which serves as the core basis for this query, is extracted from the received tracing request. Then, using this target data fingerprint as the index key, an efficient key-value query operation is performed in a pre-built and maintained blockchain cross-domain index table. This query operation aims to precisely match the index entry associated with the fingerprint and read and return all information from that entry recording the first time the data was registered on the blockchain; this information is the source event for this tracing.

[0066] For example, the system receives a traceability request containing a target data fingerprint of "0x1a2b...". Using this fingerprint as an index key, the system queries the blockchain cross-domain index table. If the query successfully matches an entry, the system reads the source event corresponding to that fingerprint as: {EventID: "Event001", DomainID: "Power Generation Domain A", Timestamp: "2025-10-01 10:00:00"}.

[0067] For example, after identifying the source event, the system uses the target data fingerprint contained in the source event as a global association identifier to launch a parallel distributed query task. This task simultaneously sends query requests for associated events to nodes in all potentially relevant business domains within the consortium blockchain network. Each node receiving the request retrieves all on-chain events in its local ledger copy that contain the global association identifier in their data records. Subsequently, each node returns its retrieved set of events to the query initiator.

[0068] For example, starting with the source event Event001, the system uses its target data fingerprint "0x1a2b..." as a global association identifier to initiate queries in parallel to nodes in "Power Generation Domain A", "Power Grid Domain B", and "Regulatory Domain C". The "Power Generation Domain A" node returns the "Collection" on-chain event associated with this identifier. The "Power Grid Domain B" node returns the "Sharing" on-chain event associated with this identifier. The "Regulatory Domain C" node returns the "Access" on-chain event associated with this identifier.

[0069] For example, the system aggregates and integrates all the independent on-chain event records retrieved in parallel from nodes across all different business domains in the previous step into a unified, temporary set. This set contains all the original event records that can be found in this traceability query and are directly or indirectly related to the target data fingerprint. Each original event record is then ultimately identified as a candidate traceability event for the next step of verification and analysis.

[0070] For example, the system will aggregate the three on-chain events ("collection", "sharing", and "access") returned from "power generation domain A", "power grid domain B", and "regulatory domain C" into a list. This list, containing all the preliminary query results, is the candidate tracing event set for this tracing, and it will serve as the input for the next step of timing and dependency verification.

[0071] According to the above implementation method, the target data fingerprint in the traceability request is used as the index key to locate the corresponding source event from the blockchain cross-domain index table. Starting from the source event and using the target data fingerprint as the global association identifier, corresponding on-chain events are queried in parallel across multiple business domains, thereby constructing a candidate traceability event set associated with the target data fingerprint. By setting up a cross-domain index table, unified location and rapid retrieval of on-chain data from different business domains are achieved, avoiding the high time overhead of chain-by-chain traversal. By using the data fingerprint as the global association identifier to retrieve events from each business domain in parallel, the efficiency and completeness of cross-domain traceability are improved. By forming a candidate traceability event set, a reliable foundation is provided for subsequent verification and screening, thereby enhancing the accuracy, real-time performance, and scalability of cross-domain traceability of power business data.

[0072] In one implementation, each candidate traceability event is verified to obtain each target traceability event, including: obtaining metadata of each candidate traceability event from the blockchain ledger, wherein the metadata includes the timestamp and business domain of the candidate traceability event, the timestamp and hash pointer of the parent event corresponding to the candidate traceability event; for each candidate traceability event, the following verification operations are performed: performing time consistency verification on the candidate traceability event based on the timestamp of the candidate traceability event and the timestamp of the parent event to obtain a first verification result; performing parent-child dependency verification on the candidate traceability event based on the hash pointer of the parent event to obtain a second verification result; performing execution domain permission verification on the candidate traceability event based on the business domain of the candidate traceability event to obtain a third verification result; and determining each candidate traceability event that passes the verification for the first verification result, the second verification result, and the third verification result as the target traceability event.

[0073] For example, metadata refers to descriptive information extracted from the blockchain ledger in association with candidate traceability events, used to characterize the event's temporal attributes, source business domain, and relationships between events.

[0074] For example, a candidate traceable event is "Line load adjustment event in the transmission business domain". Its metadata may include: the event timestamp is 10:05 on February 6, 2026, the business domain is the transmission business domain, the timestamp of its parent event is 10:00 on February 6, 2026, and the hash pointer of its parent event is Hash_P001.

[0075] For example, a parent event refers to a business event in the blockchain ledger that has a sequential relationship with a candidate traceability event and is logically a prerequisite for it, and establishes a reference relationship with the candidate traceability event through a hash pointer.

[0076] For example, if power plant A generates a "power generation reporting event" at 10:00 and then generates a "transmission dispatching event" at 10:05, then the "power generation reporting event" is the parent event of the "transmission dispatching event".

[0077] For example, each candidate traceable event is traversed. For each candidate traceable event, its data structure stored in the blockchain ledger is parsed, and metadata is extracted from it. This metadata includes at least a timestamp recording the time when the event occurred, a business domain identifying the event's origin, and a hash pointer pointing to its direct predecessor event (i.e., the parent event). The system also queries and obtains the parent event's own timestamp based on this hash pointer.

[0078] For example, the system selects a "shared" event from the candidate traceability event set for processing. By parsing its record in the blockchain ledger, the system obtains the following metadata: The candidate traceability event's timestamp: "2025-10-01 11:00:00". Its business domain: "Power Grid Domain B". The hash pointer of the parent event: "0xEventHash001". The parent event's timestamp (obtained by querying 0xEventHash001): "2025-10-01 10:00:00".

[0079] For example, the first verification result refers to the time consistency verification conclusion obtained by comparing the timestamp of the candidate trace event with the timestamp of its parent event, which is used to determine whether the candidate trace event conforms to causal logic in terms of time sequence.

[0080] For example, if the timestamp of the candidate traceable event is 10:05 and its parent event timestamp is 10:00, then the first verification result is verification passed; if the timestamp of the candidate traceable event is earlier than the timestamp of its parent event, then the first verification result is verification failed.

[0081] For example, the timestamp of the candidate traceable event is compared with the timestamp of its parent event. The logical rule for this verification is that the occurrence time of the child event must be later than or equal to the occurrence time of its parent event. If the comparison result satisfies this rule, the candidate traceable event passes the time consistency verification, and its first verification result is marked as "pass"; otherwise, it is marked as "fail".

[0082] For example, the system compares the timestamp "11:00:00" of the "shared" event with the timestamp "10:00:00" of its parent event (the collected event). Since "11:00:00" is later than "10:00:00", it conforms to the causal sequence logic, so the first verification result of this event is "passed".

[0083] For example, the second verification result refers to the parent-child dependency verification conclusion obtained by comparing the parent event hash pointer recorded in the candidate traceability event with the actual hash value of the parent event in the blockchain ledger, which is used to determine whether the reference relationship between events is real and valid.

[0084] For example, if the hash pointer of the parent event recorded in the candidate traceable event is Hash_P001, and the hash value of the corresponding parent event in the blockchain ledger is also Hash_P001, then the second verification result is that the verification passes; if the two are inconsistent, then the second verification result is that the verification fails.

[0085] For example, the hash pointer of the parent event recorded in the candidate tracing event is used as the query key to perform an existence verification in the blockchain ledger. This verification aims to confirm whether the historical event record pointed to by the hash pointer truly and legally exists on the chain. If a unique historical event record corresponding to the hash pointer can be successfully found in the ledger, the candidate tracing event passes the parent-child dependency verification, and its second verification result is marked as "passed"; otherwise, if it cannot be found, it is marked as "failed".

[0086] For example, the system uses the parent event hash pointer "0xEventHash001" recorded in the "Share" event as a query condition to search the blockchain ledger. If the search is successful, the system finds a block and transaction that perfectly matches the "Collection" event. Therefore, the second verification result for this event is "Pass".

[0087] For example, the third verification result refers to the execution domain permission verification conclusion obtained by comparing the execution domain to which the candidate traceability event belongs with the preset execution permission rules of that business domain, and is used to determine whether the event was generated by a participant with the corresponding business domain permission.

[0088] For example, if the business domain to which the candidate traceability event belongs is the power distribution business domain, and the event is generated by an authorized node of the power distribution business domain, then the third verification result is verification passed; if the event is generated by a node of the power generation business domain, then the third verification result is verification failed.

[0089] For example, the business logic of the candidate traceability event is parsed. Then, the smart contract is queried to verify whether the business domain in which the event occurred is within the authorization scope implicit in its parent event or explicitly defined by the policy. For example, it verifies whether "Grid Domain B" has the authority to process data from "Generation Domain A". If the domain in which the event occurred is within the authorization scope, the event passes the domain permission verification, and its third verification result is marked as "passed"; otherwise, it is marked as "failed".

[0090] For example, the "sharing" event occurs in the business domain "Power Grid Domain B". The system queries the smart contract and finds that "Power Grid Domain B" has been granted permission to process data from "Power Generation Domain A" (the domain where the parent event is located). Therefore, the third verification result for this event is "passed".

[0091] For example, after completing the three-level verification described above, all events in the candidate traceability event set undergo a final screening. This screening operation iterates through all candidate traceability events and retains only those events whose status flags for the first, second, and third verification results are all "passed". The events obtained after this multi-dimensional filtering and purification are then ultimately determined as the target traceability events.

[0092] For example, suppose there are five events in the candidate event set. Four of these events have all three verification results as "passed," while the fifth event has an abnormal timestamp, resulting in a "failed" first verification result. During the final filtering, the system will retain the first four events and remove the fifth. Ultimately, the retained events are the target traceability events.

[0093] According to the above implementation method, metadata of candidate traceability events is obtained from the blockchain ledger. A time consistency check is performed based on the event timestamp and the parent event timestamp; a parent-child dependency check is performed based on the hash pointer of the parent event; and a domain permission check is performed based on the business domain to which the event belongs. Only candidate traceability events that pass all three types of checks are identified as target traceability events. By introducing time consistency checks, it is possible to prevent time-series anomalies or forged events from entering the traceability results. By introducing parent-child dependency checks, the reference relationships between events are guaranteed to be genuine and reliable, preventing tampering or chain breaks. By introducing domain permission checks, it is ensured that the event source complies with business domain division and permission control requirements. This significantly improves the accuracy, reliability, and security of traceability results in cross-domain traceability scenarios, providing a high-quality event foundation for the subsequent construction of a cross-domain semantic traceability graph.

[0094] In one implementation, a cross-domain semantic traceability graph is constructed based on each target traceability event, and the graph is sent to the target participants. This includes: parsing each target traceability event to obtain event records, where each event record includes semantic attributes and identifiers of the parent events corresponding to the target traceability events; mapping the event types in each semantic attribute to labels to obtain semantic labels, where semantic labels include data generation, data access, cross-domain sharing, and data derivation; using each target traceability event as a first graph node, each parent event as a second graph node, and each semantic label as an attribute of the first graph node; constructing directed edges between each first graph node and each second graph node based on the identifiers of the parent events to obtain first directed edges; determining the weights of each first directed edge based on the cross-domain type and operational risk level in each semantic attribute to obtain second directed edges; and constructing a cross-domain semantic traceability graph based on each first graph node, the attributes of each first graph node, each second graph node, and each second directed edge.

[0095] For example, semantic attributes refer to attribute information used to describe the business meaning and operational characteristics of the event, including event type, cross-domain type, and operational risk level.

[0096] For example, a target traceability event is "power plant shares power generation data with transmission dispatch center". Its semantic attributes may include: event type is "data access", cross-domain type is "power generation business domain → transmission business domain", and operational risk level is "medium".

[0097] In this example, all target tracing events are iterated over. For each event, the system invokes an Extended PROV Model (E-PROV) semantic parser to perform deep parsing of its internal structured data to extract a set of standardized event records. Each event record contains at least semantic attributes describing the event's business meaning (such as event type, cross-domain type, and operational risk level), and a parent event identifier pointing to its direct predecessor event for constructing the chain. Subsequently, the event type string in the event record is matched against a pre-defined mapping rule base to convert it into a standardized semantic tag.

[0098] For example, when the system processes a target tracing event, it parses it to obtain the event record: {semantic attributes: {event type: "shared", cross-domain type: "cross-enterprise", risk level: 3}, parent event identifier: "Event001"}. Then, the system maps the "shared" semantic attribute to the standard semantic tag TRANSFER.

[0099] For example, the first graph node refers to a graph node constructed with the target traceable event as the object, used to represent a specific data-related event that has occurred, and carries the corresponding semantic label as a node attribute. The second graph node refers to a graph node constructed with the parent event corresponding to the target traceable event as the object, used to represent a preceding event that occurs in time and logic before the first graph node.

[0100] In this example, within a graphical data structure (such as a graph database or in-memory graph object), a unique graph node representing each target tracing event is created; this is the first graph node. Simultaneously, graph nodes are created or retrieved for all parent events referenced by these events; these are the second graph nodes. When creating the first graph node, a semantic tag corresponding to the target tracing event is appended to it as a core attribute.

[0101] For example, the system creates a first-graph node for the "Share" event, denoted as Node002, and adds the attribute Label: TRANSFER to it. At the same time, the system creates or retrieves a second-graph node for its parent event Event001 (collection event), denoted as Node001.

[0102] For example, the first directed edge refers to a directed connection relationship between nodes in the first graph and nodes in the second graph, constructed based on the parent event identifier, representing a causal or dependent relationship between events, with its direction pointing from the parent event to the target tracing event. The second directed edge refers to a weighted directed edge formed by combining the cross-domain type and operational risk level in the semantic attributes, based on the first directed edge, and is used to characterize the importance or risk level of different event relationships in cross-domain scenarios.

[0103] In this example, firstly, based on the parent event identifier in each target tracing event record, a directed edge is established from parent to child between the corresponding first graph node and the corresponding second graph node; this is the first directed edge. Then, information such as cross-domain type and operational risk level is extracted from the semantic attributes of the child node events corresponding to the first directed edge (i.e., the events corresponding to the first graph nodes). This information is then appended to the first directed edge as a multi-dimensional weight object or a comprehensively calculated scalar weight value. After this weighting process, a directed edge containing weight information is obtained, which is the second directed edge.

[0104] For example, constructing the first directed edge: Based on the parent event identifier "Event001" in the "Shared" event record, the system constructs a directed edge from Node001 (parent node) to Node002 (child node). Determining the weight: The system extracts {Cross-domain type: "Cross-enterprise", Risk level: 3} from the semantic attributes of the "Shared" event. Obtaining the second directed edge: The system appends this weight object to the edge Node001→Node002, obtaining a weighted directed edge.

[0105] For example, all nodes in the first graph, nodes in the second graph (and their attributes), and all weighted second directed edges are finally integrated. This integration process combines all independent nodes and edges into a connected and directed acyclic graph data structure. This final graph structure, which visually represents all related events and their inherent causal, dependency, and semantic attributes, is the cross-domain semantic tracing graph.

[0106] According to the above implementation method, the target traceability event is parsed to obtain event records containing semantic attributes and parent event identifiers. Event types are mapped to semantic labels. The target traceability event is constructed as a first graph node, and its parent event as a second graph node. Directed edges are established between the two types of nodes based on the parent event identifier. Weights are then assigned to the directed edges based on the cross-domain type and operational risk level, thereby constructing a cross-domain semantic traceability graph. By expressing event relationships in a graph structure, the data flow paths and causal relationships between different business domains are intuitively depicted. The introduction of semantic labels ensures that the traceability results not only contain structural relationships but also possess clear business meanings. By setting weights for the directed edges, the risk differences and importance of cross-domain operations can be reflected, thereby improving the interpretability and refinement of traceability analysis and providing intuitive and reliable support for compliance auditing, security supervision, and accountability positioning of power business data.

[0107] In one implementation, before performing cross-domain tracing in the blockchain ledger based on the target data fingerprint in the tracing request to obtain various candidate tracing events, the method further includes: querying the target power data stored off-chain based on the target data fingerprint in the tracing request; performing a hash operation on the target power data to obtain an off-chain digest value; obtaining the on-chain digest value corresponding to the target data fingerprint from the blockchain ledger; comparing the off-chain digest value and the on-chain digest value; if the comparison result is inconsistent, determining a data repair strategy based on the anomaly type of the off-chain digest value, and obtaining a copy of the target data from a third-party trusted evidence storage node based on the data repair strategy; repairing the target power data based on the target data copy to obtain the target off-chain data; writing the repair event corresponding to the repair action into the blockchain ledger, and storing the target off-chain data in an off-chain distributed database.

[0108] For example, a data repair strategy refers to a pre-defined processing scheme for restoring target power data when the off-chain digest value is inconsistent with the on-chain digest value, based on the determined data anomaly type. For instance, when the anomaly type is "data content tampered with," the data repair strategy retrieves a complete original data copy corresponding to the same target data fingerprint from a trusted third-party evidence storage node and overwrites the currently stored off-chain target power data with this data copy. When the anomaly type is "missing data fields," the data repair strategy obtains a copy of the target data from the trusted third-party evidence storage node, replaces only the missing fields, and retains the unaffected field content in the off-chain database. When the anomaly type is "corrupted data format," the data repair strategy formats and parses the target data copy obtained from the trusted third-party evidence storage node and regenerates the target power data according to a preset data structure.

[0109] For example, firstly, using the target data fingerprint in the traceability request as the index key, a pre-defined index mapping table is queried to locate the specific path of the target power data stored in the off-chain distributed database corresponding to that fingerprint. Then, the complete original target power data is read according to this path, and a secure hash algorithm (such as SHA-256) is called to perform a complete digest calculation on the read data content. The hash value obtained from this calculation is the off-chain digest value representing the current off-chain data state.

[0110] For example, using the target data fingerprint as the query key, the original data digest associated with it, recorded during the initial notarization, is retrieved from the blockchain ledger; this is the on-chain digest value. Subsequently, a precise string comparison is performed between the off-chain digest value and the on-chain digest value retrieved from the blockchain, yielding the comparison result.

[0111] For example, when the comparison results indicate inconsistency, a multi-dimensional analysis process is first initiated. Combining information such as data version and authorization records, the inconsistency event is classified into a specific anomaly type (e.g., "unauthorized tampering"). Then, based on the anomaly type, a corresponding data repair strategy is matched and determined from a pre-defined strategy library. This strategy specifies the source and priority of data recovery. Finally, according to this strategy, a data copy retrieval request is initiated to one or more highly trusted third-party evidence storage nodes or redundant backup nodes within the system to obtain a verified, tamper-proof target data copy.

[0112] For example, firstly, the original target electricity data that has been contaminated in the off-chain distributed database is overwritten and replaced with a copy of the target data. This process is called data repair, and the result is the target off-chain data. The success of data recovery can be determined using the method described in the previous example (calculating and comparing hash values). After confirming successful data recovery, a repair event is created to record this repair action. This event includes information such as the original data fingerprint, anomaly type, repair source, new data summary, and timestamp. Finally, this repair event is written as a new transaction to the blockchain ledger for notarization through the consensus mechanism, thereby ensuring the traceability and non-repudiation of the repair action itself.

[0113] According to the above implementation method, the target power data stored off-chain is queried based on the target data fingerprint in the traceability request. An off-chain digest value is obtained by hashing the target power data. Then, the on-chain digest value corresponding to the target data fingerprint is retrieved from the blockchain ledger and compared. When the two are inconsistent, a corresponding data repair strategy is determined based on the anomaly type of the off-chain digest value. A copy of the target data is obtained from a third-party trusted storage node to repair the off-chain data. Simultaneously, the repair event corresponding to the repair action is written into the blockchain ledger, and the repaired target off-chain data is stored in an off-chain distributed database. In this way, on the one hand, it is possible to promptly detect cases of off-chain data tampering or corruption, and by introducing a third-party trusted storage node as a source of data copies, reliable recovery of abnormal data is achieved, avoiding data loss due to single-point storage failure. On the other hand, by recording the repair event on the blockchain, an auditable data repair trajectory is formed, thereby ensuring the integrity and trustworthiness of off-chain data while enhancing the security, traceability, and operational reliability of the system in the power data management process.

[0114] Figure 2 This is a structural block diagram of a power industry data traceability device according to an embodiment of the present invention.

[0115] like Figure 2 As shown, the power industry data traceability device may include: The data acquisition module 510 is used to acquire power business data from various participants in various business domains; The fingerprint generation module 520 is used to generate corresponding data fingerprints for the power business data of each of the participating parties based on a multi-layer hash fusion algorithm, thereby obtaining each data fingerprint; The consensus processing module 530 is used to perform consensus processing on each of the data fingerprints and the business events associated with the data fingerprints through a preset group fault-tolerant consensus network to generate blocks, and write the blocks into the blockchain ledger; The cross-domain tracing module 540 is used to respond to the tracing request of the target participant, and perform cross-domain tracing in the blockchain ledger based on the target data fingerprint in the tracing request to obtain various candidate tracing events; The verification module 550 is used to verify each of the candidate traceability events to obtain each target traceability event; The construction module 560 is used to construct a cross-domain semantic traceability graph based on each of the target traceability events, and send the cross-domain semantic traceability graph to the target participants.

[0116] In one implementation, the packet fault-tolerant consensus network consists of core nodes, group leader nodes, and ordinary nodes, and the consensus processing module includes: The transaction to be uploaded to the blockchain determination unit is used to determine each transaction to be uploaded to the blockchain based on each of the data fingerprints and the business events associated with the data fingerprints; The local Byzantine fault-tolerant voting unit is used to call each of the ordinary nodes to submit each of the transactions to be uploaded to the group leader node to which each of the ordinary nodes belongs, so that each of the group leader nodes can perform local Byzantine fault-tolerant voting on each of the transactions to be uploaded to the group to generate candidate block digests. The global Byzantine fault-tolerant voting unit is used to call each of the core nodes to receive the candidate block digests sent by each of the group leader nodes, and to perform global Byzantine fault-tolerant voting on each of the candidate block digests to generate a block; A block broadcasting unit is used to broadcast the block and write the block into the blockchain ledger.

[0117] In one implementation, the cross-domain tracing module includes: The first query unit is used to query the source event corresponding to the target data fingerprint from a preset blockchain cross-domain index table, using the target data fingerprint in the traceability request as the index key. The second query unit is used to query the on-chain events corresponding to the global association identifier in each of the business domains in parallel, starting from the source event and using the target data fingerprint as the global association identifier, so as to obtain each on-chain event; The candidate traceability event determination unit is used to determine each candidate traceability event based on each of the on-chain events.

[0118] In one embodiment, the verification module includes: The metadata acquisition unit is used to acquire the metadata of each candidate traceability event from the blockchain ledger, wherein the metadata includes the timestamp and business domain of the candidate traceability event, the timestamp and hash pointer of the parent event corresponding to the candidate traceability event; The verification execution unit is used to perform the following verification operations for each of the candidate traceability events: The time consistency verification subunit is used to perform time consistency verification on the candidate traceability event based on the timestamp of the candidate traceability event and the timestamp of the parent event, and obtain a first verification result; The parent-child dependency verification subunit is used to perform parent-child dependency verification on the candidate traceability event based on the hash pointer of the parent event, and obtain a second verification result; The domain permission verification subunit is used to perform domain permission verification on the candidate traceability event based on the business domain of the candidate traceability event, and obtain a third verification result; The target tracing event determination subunit is used to determine each candidate tracing event that has passed the verification of the first verification result, the second verification result, and the third verification result as the target tracing event.

[0119] In one implementation, the building module includes: The parsing unit is used to parse each of the target tracing events to obtain each event record, wherein the event record includes semantic attributes and the identifier of the parent event corresponding to the target tracing event; A mapping unit is used to map the event types in each of the semantic attributes to labels to obtain various semantic labels, wherein the semantic labels include data generation, data access, cross-domain sharing, and data derivation; The graph node construction unit is used to use each of the target tracing events as a first graph node, each of the parent events as a second graph node, and each of the semantic tags as attributes of the first graph node. A directed edge construction unit is used to construct directed edges between each first graph node and the second graph node according to the identifier of the parent event, so as to obtain each first directed edge; The edge weight determination unit is used to determine the weight of each first directed edge based on the cross-domain type and operation risk level in each of the semantic attributes, and to obtain each second directed edge. The graph construction unit is used to construct the cross-domain semantic tracing graph based on each of the first graph nodes, the attributes of each of the first graph nodes, each of the second graph nodes, and each of the second directed edges.

[0120] In one embodiment, the fingerprint generation module includes: The data fingerprint calculation unit is used to perform the following data fingerprint calculation for the power business data of each of the aforementioned participants: The first hash operation subunit is used to perform a hash operation on the power business data to obtain a data content summary; An extraction subunit is used to extract business feature data and acquisition node identifiers from the power business data; The first splicing subunit is used to splice the data content summary, the business feature data and the acquisition node identifier to obtain the first splicing feature; The second hash operation subunit is used to perform a hash operation on the first concatenation feature to obtain a business-aware summary. The second splicing subunit is used to splice the business perception summary, the timestamp corresponding to the power business data, and the randomly generated disturbance factor to obtain the second splicing feature; The third hash operation subunit is used to perform a hash operation on the second concatenation feature to obtain the data fingerprint corresponding to the power business data.

[0121] In one embodiment, prior to the cross-domain tracing module, the device further includes: The off-chain query module is used to query the target power data stored off-chain based on the target data fingerprint in the traceability request. The hash operation module is used to perform hash operations on the target power data to obtain an off-chain digest value; The on-chain digest value acquisition module is used to acquire the on-chain digest value corresponding to the target data fingerprint from the blockchain ledger; The comparison module is used to compare the off-chain digest value and the on-chain digest value; The target data copy acquisition module is used to determine a data repair strategy based on the anomaly type of the off-chain digest value when the comparison results are inconsistent, and to obtain a target data copy from a third-party trusted evidence storage node based on the data repair strategy. The repair module is used to repair the target power data based on the target data copy to obtain the target off-chain data; The storage module is used to write the repair events corresponding to the repair actions into the blockchain ledger and to store the target off-chain data in an off-chain distributed database.

[0122] The specific functions and examples of each module and submodule of the system in this embodiment of the invention can be found in the relevant descriptions of the corresponding steps in the above method embodiments, and will not be repeated here.

[0123] The acquisition, storage, and application of user personal information involved in the technical solution of this invention all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0124] This invention also provides an electronic device, comprising: At least one processor; and a memory communicatively connected to said at least one processor; The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the method described in any one of the embodiments of the present invention.

[0125] The beneficial effects of the electronic device in this embodiment of the invention are equivalent to the beneficial effects of the above-described power industry data traceability method, and will not be repeated here.

[0126] This invention also provides a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to perform the method described in any one of the embodiments of this invention.

[0127] The beneficial effects of the storage medium of the present invention are equivalent to those of the above-described power industry data traceability method, and will not be repeated here.

[0128] Figure 3 A schematic block diagram of an example electronic device 800 that can be used to implement embodiments of the present invention is shown. Electronic device 800 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic device 800 may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0129] like Figure 3 As shown, the electronic device 800 includes a computing unit 801, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 802 or a computer program loaded from a storage unit 808 into a random access memory (RAM) 803. The RAM 803 may also store various programs and data required for the operation of the electronic device 800. The computing unit 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0130] Multiple components in electronic device 800 are connected to I / O interface 805, including: input unit 806, such as keyboard, mouse, etc.; output unit 807, such as various types of displays, speakers, etc.; storage unit 808, such as disk, optical disk, etc.; and communication unit 809, such as network card, modem, wireless transceiver, etc. Communication unit 809 allows electronic device 800 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0131] The computing unit 801 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 801 performs the various methods and processes described above, such as the power industry data tracing method. For example, in some embodiments, the power industry data tracing method can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 808. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 800 via ROM 802 and / or communication unit 809. When the computer program is loaded into RAM 803 and executed by the computing unit 801, one or more steps of the power industry data tracing method described above can be performed. Alternatively, in other embodiments, the computing unit 801 can be configured to perform the power industry data tracing method by any other suitable means (e.g., by means of firmware).

[0132] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0133] The program code used to implement the methods of the present invention can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0134] In the context of this invention, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0135] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0136] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0137] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0138] It should be understood that the various forms of processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this invention can be achieved, and this is not limited herein.

[0139] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the principles of this invention should be included within the scope of protection of this invention.

Claims

1. A data traceability method for the power industry, characterized in that, include: Acquire power business data from various participants in each business domain; Based on the multi-layer hash fusion algorithm, corresponding data fingerprints are generated for the power business data of each of the participants, thus obtaining each data fingerprint; A pre-defined group fault-tolerant consensus network is used to process the consensus of each data fingerprint and the business events associated with the data fingerprint to generate blocks, and the blocks are written into the blockchain ledger. In response to a traceability request from a target participant, cross-domain traceability is performed in the blockchain ledger based on the target data fingerprint in the traceability request to obtain various candidate traceability events; Each candidate tracing event is verified to obtain each target tracing event; Based on each of the target tracing events, a cross-domain semantic tracing graph is constructed, and the cross-domain semantic tracing graph is sent to the target participants.

2. The method according to claim 1, characterized in that, The process involves using a pre-defined group fault-tolerant consensus network to perform consensus processing on each data fingerprint and the associated business events to generate blocks, and then writing the blocks into the blockchain ledger. The group fault-tolerant consensus network consists of core nodes, group leader nodes, and ordinary nodes, including: Based on each data fingerprint and the associated business events, determine each transaction to be uploaded to the blockchain; Each of the ordinary nodes is invoked to submit each of the transactions to be uploaded to the chain to the group leader node to which each of the ordinary nodes belongs, so that each of the group leader nodes performs local Byzantine fault-tolerant voting on each of the transactions to be uploaded to the chain within the group to generate candidate block digests. Each core node is invoked to receive candidate block digests sent by each group leader node, and a global Byzantine fault-tolerant vote is performed on each candidate block digest to generate a block; The block is broadcast and written into the blockchain ledger.

3. The method according to claim 1, characterized in that, In response to a traceability request from a target participant, cross-domain traceability is performed in the blockchain ledger based on the target data fingerprint in the traceability request, resulting in various candidate traceability events, including: Using the target data fingerprint in the traceability request as the index key, query the source event corresponding to the target data fingerprint from the preset blockchain cross-domain index table; Starting with the source event and using the target data fingerprint as the global association identifier, the on-chain events corresponding to the global association identifier are queried in parallel in each of the business domains to obtain each on-chain event; Based on each of the on-chain events, each of the candidate traceability events is determined.

4. The method according to claim 1, characterized in that, The process of verifying each candidate traceability event to obtain each target traceability event includes: Obtain metadata for each candidate traceability event from the blockchain ledger, wherein the metadata includes the timestamp and business domain of the candidate traceability event, the timestamp and hash pointer of the parent event corresponding to the candidate traceability event; For each of the aforementioned candidate traceability events, the following verification operation is performed: Based on the timestamp of the candidate traceable event and the timestamp of the parent event, a time consistency check is performed on the candidate traceable event to obtain a first check result; Based on the hash pointer of the parent event, the parent-child dependency is checked on the candidate traceability event to obtain a second check result; Based on the business domain of the candidate traceability event, the execution domain permission verification is performed on the candidate traceability event to obtain a third verification result; Each candidate traceability event for which the first verification result, the second verification result, and the third verification result are all verified is determined as the target traceability event.

5. The method according to claim 1, characterized in that, The step of constructing a cross-domain semantic traceability graph based on each of the target traceability events and sending the cross-domain semantic traceability graph to the target participants includes: Each of the target tracing events is parsed to obtain an event record, wherein the event record includes semantic attributes and the identifier of the parent event corresponding to the target tracing event; The event types in each of the semantic attributes are mapped to tags to obtain semantic tags, wherein the semantic tags include data generation, data access, cross-domain sharing and data derivation; Each of the target tracing events is used as a first graph node, each of the parent events is used as a second graph node, and each of the semantic tags is used as an attribute of the first graph node. Based on the identifier of the parent event, directed edges are constructed between each of the first graph nodes and the second graph nodes to obtain each first directed edge; Based on the cross-domain type and operation risk level in each of the semantic attributes, the weight of each first directed edge is determined, and each second directed edge is obtained. The cross-domain semantic tracing graph is constructed based on each of the first graph nodes, the attributes of each of the first graph nodes, each of the second graph nodes, and each of the second directed edges.

6. The method according to claim 1, characterized in that, The multi-layer hash fusion algorithm generates corresponding data fingerprints for the power business data of each participant, resulting in various data fingerprints, including: For the power business data of each of the aforementioned participants, the following data fingerprint calculation is performed: Perform a hash operation on the power business data to obtain a data content summary; Extract business characteristic data and acquisition node identifiers from the power business data; By concatenating the data content summary, the business feature data, and the acquisition node identifier, a first concatenation feature is obtained; Perform a hash operation on the first concatenated feature to obtain a business-aware summary; By concatenating the business perception summary, the timestamp corresponding to the power business data, and the randomly generated perturbation factor, a second concatenation feature is obtained; A hash operation is performed on the second concatenation feature to obtain the data fingerprint corresponding to the power business data.

7. The method according to claim 1, characterized in that, Before performing cross-domain tracing in the blockchain ledger based on the target data fingerprint in the tracing request to obtain various candidate tracing events, the method further includes: Based on the target data fingerprint in the traceability request, query the target power data stored off-chain; Perform a hash operation on the target power data to obtain an off-chain digest value; Obtain the on-chain digest value corresponding to the target data fingerprint from the blockchain ledger; Compare the off-chain digest value and the on-chain digest value; If the comparison results are inconsistent, a data repair strategy is determined based on the anomaly type of the off-chain digest value, and a copy of the target data is obtained from a third-party trusted evidence storage node based on the data repair strategy. The target power data is repaired based on the target data copy to obtain the target off-chain data; The repair event corresponding to the repair action is written into the blockchain ledger, and the target off-chain data is stored in an off-chain distributed database.

8. A data traceability device for the power industry, characterized in that, include: The data acquisition module is used to acquire power business data from various participants in various business domains; The fingerprint generation module is used to generate corresponding data fingerprints for the power business data of each of the participating parties based on a multi-layer hash fusion algorithm, thereby obtaining each data fingerprint; The consensus processing module is used to perform consensus processing on each data fingerprint and the business events associated with the data fingerprint through a preset group fault-tolerant consensus network to generate blocks and write the blocks into the blockchain ledger. The cross-domain tracing module is used to respond to the tracing request of the target participant, and perform cross-domain tracing in the blockchain ledger based on the target data fingerprint in the tracing request to obtain various candidate tracing events; The verification module is used to verify each of the candidate traceability events to obtain each target traceability event; The construction module is used to construct a cross-domain semantic traceability graph based on each of the target traceability events, and send the cross-domain semantic traceability graph to the target participants.

9. An electronic device, characterized in that, include: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-7.

10. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-7.

Images