Blockchain-based data asset identification and tracing method and system

Abstract

The application discloses a kind of based on blockchain data asset identification and traceability method and system, it is related to traceability analysis technical field, it includes traversing source dependence directed acyclic graph, extract the parent node set of reference suspected node, and according to the derivative operation logic summary registered in parent node set Operation correlation verification is carried out to suspected node;According to the cumulative suspected node of operation correlation verification result False dependence penalty value, when the proportion of false dependence penalty value in parent node number crosses preset penalty threshold, suspected node is judged as shadow node;Reliable ancestor node is traced back along the reference path of shadow node, and generates the logical redirection pointer for connecting parent node and reliable ancestor node;According to logical redirection pointer, update source dependence directed acyclic graph, output pure source tree and source purification log.The application has the effect of improving data asset identification and traceability efficiency.

Description

Technical Field

[0001] This application relates to the field of traceability analysis technology, and in particular to a data asset identification and traceability method and system based on blockchain. Background Technology

[0002] As a core production factor in the digital economy era, data assets play an irreplaceable role in activating the potential of the digital market through compliant ownership verification, secure circulation, and accurate value assessment. Meanwhile, blockchain technology, with its immutable, distributed consensus, and traceable underlying characteristics, has become a key infrastructure for building a trust foundation for data assets, playing a vital role in ensuring transparency and clarity of ownership in data flow.

[0003] It is worth noting that the commercial valuation of data assets is highly dependent on the richness and reliability of their historical derivation paths. Malicious actors often exploit the pointer referencing mechanism of blockchain to artificially construct complex on-chain networks. The sensitivity of this mechanism means that even the slightest false attachment or meaningless nested reference during the asset registration process can create intricate dependency topologies on the chain, resulting in a significant discrepancy between the actual physical circulation state of the data asset and the traceability structure presented on the chain.

[0004] However, current blockchain-based traceability management for data assets still has significant vulnerabilities. Traditional traceability systems rely excessively on static comparisons of on-chain hash pointers, verifying only the legality of registered identities and formats while neglecting dynamic verification of the actual existence of data entities. Practice shows that even if a node has perfect transaction records on the chain, it may still be an empty shell entity with no substantial data. This reflects a major flaw in focusing solely on on-chain identity verification while ignoring in-depth questioning of data lineage logic. Existing traceability mechanisms cannot proactively penetrate and identify these false dependency layers used to mislead, resulting in a seemingly large but actually fraudulent traceability map that severely interferes with asset credibility assessment and lacks effective means for systematically identifying and purifying the traceability chain. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this application provides a blockchain-based method and system for identifying and tracing data assets.

[0006] Firstly, this application provides a blockchain-based method for identifying and tracing data assets, comprising the following steps: Parse the blockchain identifier sequence associated with the target data assets, read the asset registration transaction records corresponding to each blockchain identifier, extract the preceding reference hash pointer and block packaging and archiving time, and construct a traceability dependency directed acyclic graph containing node reference relationships and timestamp information; Highly sensitive detection nodes are selected based on the in-degree to out-degree ratio of each node in the source-dependent directed acyclic graph. Generate a random encryption seed and send it to the storage address bound to the high-sensitivity probe node, and receive a response data packet containing on-chain existence proof, content challenge proof and on-chain baseline hash value; Verify the on-chain existence proof and the content challenge proof. If the on-chain existence proof passes but the content challenge proof fails, mark the corresponding high-sensitivity detection node as a suspected node. Traverse the source-dependent directed acyclic graph, extract the set of parent nodes of suspected reference nodes, and perform operation association verification on suspected nodes based on the derivation operation logic summary registered in the parent node set; Based on the results of the computational association verification, the false dependency penalty value of suspected nodes is accumulated. When the proportion of the false dependency penalty value to the number of parent nodes exceeds the preset penalty threshold, the suspected node is judged as a shadow node. Tracing back along the reference path of the shadow node to the reliable ancestor node, a logical redirection pointer is generated to connect the parent node and the reliable ancestor node; Update the source dependency directed acyclic graph based on logical redirection pointers, and output a clean source tree and source purification log.

[0007] Secondly, this application provides a blockchain-based data asset identification and traceability system, including: The dependency graph construction module is used to parse the blockchain identifier sequence associated with the target data assets, read the asset registration transaction records corresponding to each blockchain identifier, extract the preceding reference hash pointer and the block packaging and archiving time, and construct a source dependency directed acyclic graph containing node reference relationships and timestamp information. The detection node screening module is used to screen out highly sensitive detection nodes based on the ratio of the in-degree to the out-degree of each node in the source-dependent directed acyclic graph. The content challenge module is used to generate a random cryptographic seed and send it to the storage address bound to the high-sensitivity probe node, and receive a response data packet containing an on-chain existence proof, a content challenge proof, and an on-chain baseline hash value; The suspected node determination module is used to verify the on-chain existence proof and the content challenge proof. When the on-chain existence proof passes but the content challenge proof fails, the corresponding high-sensitivity detection node is marked as a suspected node. The lineage query module is used to traverse the source dependency directed acyclic graph, extract the set of parent nodes of suspected reference nodes, and perform operation association verification on the suspected nodes based on the derivative operation logic summary registered in the set of parent nodes. The shadow node determination module is used to accumulate the false dependency penalty value of suspected nodes based on the operation association verification results. When the proportion of the false dependency penalty value to the number of parent nodes exceeds the preset penalty threshold, the suspected node is determined to be a shadow node. The relationship reconstruction module is used to trace back the reliable ancestor node along the reference path of the shadow node and generate a logical redirection pointer to connect the parent node and the reliable ancestor node. The source tracing output module is used to update the source tracing dependency directed acyclic graph based on the logical redirection pointer, and output a clean source tracing tree and source tracing purification log.

[0008] Thirdly, this application provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform any of the above-described methods for identifying and tracing data assets based on blockchain.

[0009] In summary, this application includes at least one of the following beneficial technical effects: 1. This application provides a blockchain-based data asset identification and traceability method. By parsing the blockchain identifier sequence associated with the target data asset and constructing a traceability dependency directed acyclic graph containing timestamp information, the method accurately screens out highly sensitive detection nodes based on the in-degree to out-degree ratio of nodes and sends random encrypted seeds to them to initiate dynamic verification including on-chain existence and content challenge proofs. This allows the system to proactively penetrate the complex on-chain reference appearances and dynamically question and mark suspected nodes based on the actual storage state of the data entity. This effectively avoids the rigidity of traditional blockchain traceability systems that rely too much on static hash pointer comparison, which emphasizes identity form over data substance. It makes the identification of data asset lineage and the determination of false attachment more consistent with the real situation of physical circulation, and greatly enhances the anti-interference and anti-spoofing capabilities of the underlying dependency graph. 2. This application utilizes the derived operation logic summary registered in the parent node set to perform deep operation association verification on suspected nodes, and accurately determines shadow nodes based on the dynamic accumulation of false dependency penalty values. Then, it traces back to reliable ancestor nodes along the reference path to generate logical redirection pointers as the basis for graph updates, thereby improving the reliability and accuracy of the final output pure source tree and source purification log. This not only helps data auditors and asset appraisal institutions to promptly strip away fictitious links without any substantial data support and grasp the most authentic value derivative source of data assets, but also provides participants in the data element market with transparent and conclusive purification traceability certificates, significantly improving the accuracy of data source assessment and the efficient management level of compliant asset transfer in complex nested transaction environments. Attached Figure Description

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

[0011] Figure 1 This is a flowchart of a blockchain-based data asset identification and traceability method according to an embodiment of this application.

[0012] Figure 2 This is a schematic diagram of a blockchain-based data asset identification and traceability system according to an embodiment of this application. Detailed Implementation

[0013] The following description, in conjunction with the implementation of the present invention, is merely an example and illustration of the concept of the present invention. Those skilled in the art can make various modifications or additions to the specific embodiments described, or use similar methods to replace them, as long as they do not deviate from the concept of the invention, and all such modifications and additions should fall within the protection scope of the present invention.

[0014] Example 1: This application is applicable to scenarios where data assets have been registered on-chain and subsequently referenced, processed, derived, and circulated. It is particularly suitable for handling data assets with numerous on-chain reference relationships where it is difficult to determine the true lineage using only hash pointers. The core idea is not simply to check the existence of a specific asset registration transaction record, but rather to first restore the blockchain identifier sequence associated with the target data asset into a time-ordered, source-dependent directed acyclic graph. Then, it identifies highly sensitive probe nodes that may be heavily referenced within the graph structure and initiates randomized content challenges against these nodes. When an on-chain identity exists but the content challenge fails, it combines the derivative operation logic digest registered by the downstream parent node to perform a lineage query. This identifies shadow nodes that are heavily attached without real data support. Furthermore, without rewriting the underlying blockchain ledger, it uses logical redirection pointers to generate a pure source tree and source purification log that more closely approximates the real data derivative relationships.

[0015] This application discloses a blockchain-based method for identifying and tracing data assets.

[0016] Reference Figure 1 A blockchain-based method for identifying and tracing data assets includes the following steps: Parse the blockchain identifier sequence associated with the target data assets, read the asset registration transaction records corresponding to each blockchain identifier, extract the preceding reference hash pointer and block packaging and archiving time, and construct a traceability dependency directed acyclic graph containing node reference relationships and timestamp information; Furthermore, a directed acyclic graph of origination dependencies, including node reference relationships and timestamp information, is constructed, including: Read the root blockchain identifier from the target data asset registration data, and extract the upstream blockchain identifier layer by layer along the preceding reference hash pointer recorded in the root blockchain identifier to form a blockchain identifier sequence; Retrieve the corresponding asset registration transaction record from the blockchain ledger based on the blockchain identifier sequence; Extract the asset content summary, front reference hash pointer, and block packaging and archiving time from the asset registration transaction record; Map each blockchain identifier to a graph node, and write the block packaging and archiving time into the corresponding graph node; By establishing directed connections between graph nodes according to the preceding reference hash pointers, an initial dependency graph is obtained; Based on the block packaging and archiving time of the graph nodes, a reverse time check is performed on the initial dependency graph. Connection edges with mismatched time order are moved into the abnormal edge set, and the remaining connection edges are used to generate a source dependency directed acyclic graph.

[0017] In one specific implementation, the method is executed by a processor deployed in a blockchain data asset management platform. The processor can access the blockchain ledger, the data asset registration database, and the storage addresses associated with each data asset. The blockchain ledger stores asset registration transaction records, which are stored using structured fields. These fields include at least a blockchain identifier, an asset content summary, a pre-reference hash pointer, a block archiving time, an on-chain base hash value, a storage address, and a summary of derived computation logic. The blockchain identifier can be a fixed-length transaction hash, such as a 32-byte hash string; the block archiving time can be a millisecond-level Unix timestamp; and the on-chain base hash value can be the value obtained by merging the asset content summary fragments in a fixed order and then performing a hash operation. For ease of explanation, the following example uses target data asset A. The target data asset registration data of target data asset A records a root blockchain identifier, and the processor uses this root blockchain identifier as the entry point to begin tracing.

[0018] When the processor parses the blockchain identifier sequence associated with the target data asset, it first reads the root blockchain identifier from the target data asset's registration data. Then, based on this root blockchain identifier, it reads the corresponding asset registration transaction record from the blockchain ledger. This asset registration transaction record contains a preceding reference hash pointer, which points to the blockchain identifier corresponding to the upstream data asset directly referenced by the target data asset A. The processor continues reading upstream asset registration transaction records along this preceding reference hash pointer until a certain asset registration transaction record no longer has a preceding reference hash pointer, or the preceding reference hash pointer has already been read and would cause a duplicate path. Each time a blockchain identifier is read, the processor writes it into the blockchain identifier sequence and temporarily stores its corresponding asset registration transaction record in a local cache to avoid duplicate reads caused by subsequent accesses to the blockchain ledger.

[0019] After obtaining the blockchain identifier sequence, the processor extracts the preceding reference hash pointer and block archiving time from each asset registration transaction record and creates a graph node for each blockchain identifier. The graph node's data body contains the blockchain identifier, asset content summary, on-chain base hash value, and block archiving time, with the block archiving time serving as a timestamp. Subsequently, the processor establishes directed connections between graph nodes according to the preceding reference hash pointer. If the preceding reference hash pointer in graph node B's asset registration transaction record points to the blockchain identifier of graph node C, then a directed connection is established from graph node B to graph node C, indicating that graph node B references graph node C in the data derivation relationship.

[0020] After the processor completes the establishment of all directed edges, it obtains an initial dependency graph. Then, based on the block archiving time of each graph node, it performs a time direction check on the initial dependency graph. This removes edges whose reference relationships return to traversed graph nodes and whose time order does not match, thus constructing a source-dependent directed acyclic graph containing node reference relationships and timestamp information. Here, a time order mismatch refers to a situation where the block archiving time of a downstream graph node is earlier than the block archiving time of the upstream graph node it references, and the time difference between the two exceeds the allowable range of ledger block production error, such as exceeding the average block production time of two blocks.

[0021] Specifically, based on the above scheme, when constructing a source dependency directed acyclic graph containing node reference relationships and timestamp information, the formation process of the blockchain identifier sequence can be more strictly limited. After the processor reads the root blockchain identifier from the target asset registration data, it not only extracts the upstream blockchain identifier layer by layer along the preceding reference hash pointer recorded in the root blockchain identifier, but also records the current level, source graph node, and referenced graph node at each extraction level. If there are multiple preceding reference hash pointers in a certain asset registration transaction record, the processor expands them one by one according to the pointer sequence number in the asset registration transaction record and writes the upstream blockchain identifiers obtained from different branches into the blockchain identifier sequence. The blockchain identifier sequence is not a simple linear array, but a reading result with hierarchical relationships; when retrieving asset registration transaction records subsequently, the processor still uses the blockchain identifier as an index to access the blockchain ledger item by item, avoiding the repeated creation of graph nodes due to branch overlap.

[0022] After extracting the asset content summary, before-reference hash pointer, and block packaging and archiving time from the asset registration transaction records, the processor maps each blockchain identifier to a graph node. During mapping, the blockchain identifier serves as the unique key of the graph node, the asset content summary is used for subsequent display and verification, and the block packaging and archiving time is written to the corresponding graph node as timestamp information. If the same blockchain identifier is read repeatedly in different branches, the processor retains only one graph node, but retains multiple directed edges pointing to that graph node, thus reflecting the situation where multiple downstream graph nodes jointly reference the same upstream graph node. When establishing directed edges between graph nodes according to the before-reference hash pointer, the processor first checks whether the before-reference hash pointer can find a corresponding graph node in the blockchain identifier sequence; if not found, the before-reference hash pointer is recorded as a dangling pointer and temporarily not participated in the initial dependency graph construction to prevent pointers without a registered source from destroying the traversability of the graph structure.

[0023] After obtaining the initial dependency graph, the processor performs a reverse time check based on the block packaging and archiving times of the graph nodes. The reverse time check can be defined as follows: for any directed edge from graph node X to graph node Y, where X is the referrer and Y is the referenced, if the block packaging and archiving time of X is less than that of Y, and the difference exceeds a preset time tolerance, then the directed edge is considered to have a time order mismatch. The preset time tolerance can be set based on the blockchain ledger's block production rules, for example, 2 to 5 times the average block interval. The processor moves the time-order mismatched edges into an abnormal edge set, which records the edge identifier, the referrer's blockchain identifier, the referenced blockchain identifier, the block packaging and archiving times of both ends, and the reason for the mismatch. When generating a directed acyclic graph (DAG) with tracing dependencies from the remaining edges, the processor performs a loop check. If a set of remaining edges still forms a closed path, the edge whose block archiving time is least consistent with the reference direction is moved to the abnormal edge set first, until the graph structure meets the DAG requirement. This results in a DAG that preserves interpretable node reference relationships while isolating on-chain records with obvious temporal conflicts, providing a cleaner graph data foundation for subsequent high-sensitivity node screening.

[0024] Highly sensitive detection nodes are selected based on the in-degree to out-degree ratio of each node in the source-dependent directed acyclic graph. Furthermore, based on the in-degree to out-degree ratio of each node in the source-dependent directed acyclic graph, highly sensitive detection nodes are screened out, including: Statistical sourcing relies on the in-degree data of each graph node in the directed acyclic graph, which is referenced by downstream graph nodes, and the out-degree data of each graph node, which is referenced by upstream graph nodes. The node reference offset value is obtained by calculating the ratio of in-degree data to out-degree data at the same scale. Read the block packaging and archiving time corresponding to each graph node, calculate the number of adjacent nodes with reference relationships to the graph node within the same time window, and obtain the node time aggregation value; Bind node reference offset values ​​to node temporal aggregation values ​​as node detection features; Based on the node detection characteristics, graph nodes with concentrated in-degree and time clusters are screened out to generate a list of highly sensitive detection nodes.

[0025] In one specific implementation, based on the previously generated source-dependent directed acyclic graph, when screening for highly sensitive detection nodes, the processor calculates the in-degree and out-degree data for each graph node. The in-degree data comes from all directed edges whose endpoints are the current graph node, and the out-degree data comes from all directed edges whose starting points are the current graph node. To avoid numerical incomparability between target data assets of different scales, the processor can further divide the in-degree and out-degree data by the total number of edges in the source-dependent directed acyclic graph to obtain normalized in-degree and normalized out-degree data, and then perform a ratio calculation at the same scale. At this point, the node reference offset value can be expressed as... ,in, Represents graph nodes The node reference offset value, Represents graph nodes in-degree data, This represents the out-degree data of graph node v. This represents the total number of connected edges in the directed acyclic graph that determines the source dependency. This represents a smoothing measure to prevent the denominator from being zero. It can be between 0.001 and 0.01. Because... By having both in the numerator and denominator, this formula can preserve the relative relationship between in-degree and out-degree, and also avoid the calculation results from getting out of control when the out-degree data is low.

[0026] The calculation of node time clustering values ​​takes into account concentrated referencing behavior within the same time window. After reading the block packaging and archiving time corresponding to each graph node, the processor expands forward and backward by half of a preset time window, centered on the block packaging and archiving time of the current graph node, forming the same time window corresponding to that graph node. If the preset time window is 48 hours, the processor counts the number of adjacent nodes with referencing relationships to the current graph node within 24 hours before and after the current graph node's registration time, and uses this number as the node time clustering value. For data assets with obvious batch registration on the chain, natural days, natural weeks, or audit batches can also be used as the same time window. The processor then binds the node reference offset value and the node time clustering value into a node detection feature, which can be written as a tuple. ,in, This represents the node time aggregation value. During filtering, the processor does not rely solely on a single metric. Instead, it first selects graph nodes whose node reference offset values ​​exceed a first preset threshold, and then selects graph nodes whose node time aggregation values ​​exceed a second preset threshold from these nodes, forming a list of highly sensitive detection nodes. The first preset threshold can be the 75th percentile of all graph node reference offset values, and the second preset threshold can be the average of all graph node time aggregation values ​​plus one standard deviation. The resulting highly sensitive detection nodes generally exhibit concentrated references within a short period and have relatively few upstream sources, which better matches the common structural characteristics of spurious dependency hierarchies.

[0027] Generate a random encryption seed and send it to the storage address bound to the high-sensitivity probe node, and receive a response data packet containing on-chain existence proof, content challenge proof and on-chain baseline hash value; Furthermore, a random encryption seed is generated and sent to the storage address bound to the high-sensitivity probe node. A response data packet containing on-chain existence proof, content challenge proof, and on-chain baseline hash value is received, including: Generate random encryption seeds with time-sensitive verification codes for high-sensitivity detection nodes; The position of the fragment to be verified with a predetermined number of bits is determined from the content digest fragment sequence registered by the high-sensitivity detection node based on the random encryption seed; The challenge request data consists of a random encrypted seed, the shard location to be verified, and the blockchain identifier of the highly sensitive probe node; Send the challenge request data to the storage address bound to the highly sensitive detection node; The system receives a response data packet returned by the storage address. The response data packet includes an on-chain existence proof corresponding to the high-sensitivity probe node, a content challenge proof generated by the content digest shard corresponding to the shard position to be verified, and an on-chain baseline hash value in the asset registration transaction record.

[0028] In one specific implementation, for each high-sensitivity detection node in the high-sensitivity detection node list, the processor generates a random encryption seed. The random encryption seed is generated jointly by a random number, the generation time, and the blockchain identifier of the high-sensitivity detection node. The random number can be generated by a cryptographically secure pseudo-random number generator, with a length ranging from 128 to 256 bits; the generation time uses the current millisecond-level timestamp; the blockchain identifier of the high-sensitivity detection node is used to limit the random encryption seed to only apply to the corresponding high-sensitivity detection node. The processor performs a hash operation on the above three data items to obtain the random encryption seed, and simultaneously generates a timeliness checksum based on the generation time and allowed response duration. The timeliness checksum can be obtained by hashing the generation time, allowed response duration, and random encryption seed together, where the allowed response duration can be set according to the network environment of the storage address, for example, 30 seconds to 300 seconds. In this way, even if the same high-sensitivity detection node is verified multiple times, the content selected for each verification will be different, making it difficult to handle verification with fixed cached content.

[0029] The asset registration transaction records of the high-sensitivity detection node contain a content digest fragment sequence. This content digest fragment sequence is formed by dividing the data asset content into fixed-size segments and calculating hashes for each segment (e.g., 4KB, 64KB, or 1MB). A digest is then calculated for each content segment, and the segments are arranged in order to form the content digest fragment sequence. The processor determines the position of the fragment to be verified from the content digest fragment sequence based on a random encryption seed. One feasible approach is to re-hash the random encryption seed, extract several segments from the hash result, and take the remainder of each segment modulo the total number of fragments in the content digest fragment sequence to obtain the position of the fragment to be verified. The predetermined number of bits can be 4, 8, or 16, depending on the size of the data asset and the verification strength. If duplicate positions appear after taking the remainder, the processor continues to read subsequent segments of the hash result to fill in the gaps until the number of fragment positions to be verified reaches the predetermined number of bits.

[0030] Once the location of the shard to be verified is determined, the processor will assemble a challenge request data consisting of a random encryption seed, the location of the shard to be verified, and the blockchain identifier of the high-sensitivity probe node. The challenge request data may also carry a timeliness checksum, the request generation time, and the format requirements of the response data packet. The processor reads the storage address bound to the high-sensitivity probe node's asset registration transaction record and sends the challenge request data to that storage address. Upon receiving the challenge request data, the data custodian at the storage address should read the corresponding content digest shard according to the location of the shard to be verified and generate a content challenge proof; simultaneously, based on the blockchain identifier of the high-sensitivity probe node, it should retrieve the on-chain existence proof and the on-chain base hash value from the asset registration transaction record and return them along with the content challenge proof to the response data packet. The response data packet must include at least the on-chain existence proof corresponding to the high-sensitivity probe node, the content challenge proof generated from the content digest shard corresponding to the location of the shard to be verified, and the on-chain base hash value from the asset registration transaction record. After receiving the response data packet, the processor writes it to the verification queue and records the return time of the response data packet for subsequent determination of whether the time window specified by the timeliness checksum is met.

[0031] Specifically, the process of generating a random encryption seed and sending it to the storage address bound to the high-sensitivity probe node can be further controlled by combining the content digest sharding sequence registered by the high-sensitivity probe node. When the processor generates a random encryption seed with a time-sensitive checksum for the high-sensitivity probe node, it combines the high-sensitivity probe node's blockchain identifier, current timestamp, random number, and current challenge sequence number, and then calculates a hash to obtain the random encryption seed. The time-sensitive checksum can be obtained by rehashing the random encryption seed, current timestamp, and allowed response duration, and written into the challenge request data along with the allowed response deadline. The allowed response deadline does not depend on the storage address's self-declaration but is determined by the processor based on the local clock when issuing the challenge request data, preventing the responder from extending the validity period by modifying the returned fields.

[0032] When determining the location of a fragment to be verified with a predetermined number of bits from the content digest fragment sequence registered by the high-sensitivity probe node based on the random encryption seed, the processor first reads the total number of fragments in the content digest fragment sequence. If the total number of fragments is less than the predetermined number of bits, all fragment locations are determined as fragment locations to be verified. If the total number of fragments is greater than or equal to the predetermined number of bits, the processor splits the random encryption seed into multiple fixed-length numerical segments. Each numerical segment is converted to an integer and then moduloed by the total number of fragments to obtain a candidate fragment location. If the candidate fragment locations, after deduplication, are still less than the predetermined number of bits, the processor re-hashes the random encryption seed and the supplementary sequence number to generate new candidate fragment locations until the number of fragment locations to be verified reaches the predetermined number of bits. The predetermined number of bits can be configured according to the importance of the data asset; for example, 4 bits for ordinary data assets and 8 to 16 bits for high-value data assets. Since the fragment location to be verified is temporarily determined by the random encryption seed, the storage address must actually possess the corresponding content digest fragment in order to return a valid content challenge proof within a limited time.

[0033] The challenge request data consists of a random encryption seed, the location of the shard to be verified, and the blockchain identifier of the high-sensitivity probe node. The processor sends this data to the storage address bound to the high-sensitivity probe node. The storage address can be an off-chain object storage address, a distributed file address, or an access address maintained by the data asset registration database, but in this implementation, it is read as a field in the asset registration transaction record. After the response data packet is returned, the processor only recognizes data packets that match the blockchain identifier of the high-sensitivity probe node in this round of challenge request data. The on-chain existence proof in the response data packet is used to prove that the high-sensitivity probe node does indeed have a corresponding asset registration transaction record; the content challenge proof is used to prove that the storage address can retrieve the content digest shard based on the location of the shard to be verified; and the on-chain baseline hash value is used as the on-chain comparison data when verifying the content challenge proof. The three types of data are interrelated. If any one type is missing, the processor marks the response data packet as an incomplete response and stops entering the consistency check.

[0034] Verify the on-chain existence proof and the content challenge proof. If the on-chain existence proof passes but the content challenge proof fails, mark the corresponding high-sensitivity detection node as a suspected node. Furthermore, the on-chain existence proof and content challenge proof are verified. If the on-chain existence proof passes but the content challenge proof fails, the corresponding high-sensitivity detection node is marked as a suspected node, including: Extract the on-chain existence proof from the response data packet, and verify whether the on-chain existence proof corresponds to the same asset registration transaction record based on the blockchain identifier of the high-sensitivity probe node; After the on-chain existence proof is passed, extract the content digest shard and shard position from the content challenge proof; The content summary is divided and reorganized into a challenge summary sequence according to the segment position; The challenge summary sequence is hashed together with the random encryption seed to obtain the hash value of the challenge to be compared; Perform a consistency check between the challenge hash value to be compared and the on-chain baseline hash value in the response data packet; When the consistency check fails and the response data packet returns outside the time window specified by the timeliness check code, the corresponding high-sensitivity detection node is added to the list of suspected nodes.

[0035] In one specific implementation, when verifying the on-chain existence proof, the processor extracts the on-chain existence proof from the response data packet and verifies whether the on-chain existence proof corresponds to the same asset registration transaction record based on the blockchain identifier of the high-sensitivity probe node. The on-chain existence proof can be a data structure containing a block header hash, a transaction index, a transaction hash, and a Merkel path. The processor uses the block header hash of the corresponding block in the blockchain ledger as the verification basis and calculates layer by layer along the Merkel path to obtain the transaction root to be verified. If the transaction root to be verified is consistent with the transaction root registered in the block header, and the blockchain identifier in the asset registration transaction record corresponding to the transaction hash is consistent with the blockchain identifier of the high-sensitivity probe node, then the on-chain existence proof passes. If the on-chain existence proof fails, it means that the response data packet cannot prove that it comes from the same asset registration transaction record. At this time, the processor will not continue to perform a substantive comparison of the content challenge proof, but will record the response data packet as an invalid response to avoid confusing on-chain identity errors with content deficiencies.

[0036] After the on-chain existence proof passes, the processor extracts the content digest shards and shard positions from the content challenge proof. The shard positions in the content challenge proof should match the shard positions to be verified in the challenge request data. The processor first checks each position sequentially; if a shard position is missing or an unrequested position appears, the content challenge proof is deemed incomplete. After the shard position verification passes, the processor reassembles the content digest shards into a challenge digest sequence according to their positions. This reassembly does not restore the complete data asset content, but rather arranges the corresponding content digest shards in ascending order of shard position, forming a repeatable challenge digest sequence. Subsequently, the processor hashes the challenge digest sequence with a random cryptographic seed to obtain the challenge hash value to be compared. The hash combination can use... In this way, This indicates the hash value of the challenge to be compared. Indicates a challenge summary sequence, Represents a random encryption seed, symbol This indicates that the data is concatenated in the agreed-upon order. Because the random encryption seed is different each time, even if the fragment to be verified comes from the same content digest fragment sequence, the final hash value of the challenge will change depending on the challenge request data.

[0037] After the challenge hash value is generated, the processor performs a consistency check on it against the on-chain baseline hash value in the response data packet. If the challenge hash value matches the on-chain baseline hash value, and the return time of the response data packet does not exceed the time window limited by the timeliness check code, the corresponding high-sensitivity probe node passes this round of content challenge. If the challenge hash value does not match the on-chain baseline hash value, it means that the returned content digest shard cannot corroborate the baseline relationship registered on the chain; at the same time, if the return time of the response data packet exceeds the time window limited by the timeliness check code, it indicates that the response cannot prove that the storage address actually holds and can read the relevant content in a timely manner during the challenge. When the consistency check fails and the return time of the response data packet exceeds the time window limited by the timeliness check code, the processor adds the corresponding high-sensitivity probe node to the suspected node list. The suspected node list records the suspected node identifier, the corresponding blockchain identifier, the on-chain baseline hash value, the failed shard position to be verified, the return time, and the verification digest, providing input for subsequent computational correlation verification. Instead of directly identifying highly sensitive detection nodes as shadow nodes, this process sends nodes that exist on the chain but have abnormal content challenges to a lineage-based review process, reducing the risk of misjudgment caused by a single network fluctuation.

[0038] Traverse the source-dependent directed acyclic graph, extract the set of parent nodes of suspected reference nodes, and perform operation association verification on suspected nodes based on the derivation operation logic summary registered in the parent node set; Furthermore, the source-tracing dependency directed acyclic graph is traversed to extract the set of parent nodes of suspected reference nodes, and the computational association verification of suspected nodes is performed based on the derivative operation logic summary registered in the parent node set, including: Read the suspected node identifiers sequentially from the suspected node list; In the source-dependent directed acyclic graph, reverse the search for directed connecting edges pointing to the suspected node identifier, and summarize the starting graph nodes of the directed connecting edges into a set of parent nodes. Read the asset registration and transaction records of each parent node in the parent node set; Extract the derivative operation logic summary from the asset registration transaction records of each parent node. The derivative operation logic summary includes the input data hash, the processing rule summary, and the output data hash. Match the on-chain baseline hash value of the suspected node with the hash of the input data; After a successful match, the input data hash is processed according to the processing rule digest to perform a digest-level operation, resulting in the verification output hash. The output hash of the verification is compared with the hash of the output data to generate the operation association verification result corresponding to each parent node.

[0039] In one specific implementation, after the suspected node list is formed, the processor traverses the source dependency directed acyclic graph (DAG) and performs computational association verification on the suspected nodes. The processor sequentially reads the suspected node identifiers from the suspected node list and searches the DAG in reverse for directed edges pointing to those identifiers. Since directed edges point from downstream graph nodes to their referenced upstream graph nodes, the starting graph node of the directed edge pointing to the suspected node identifier is the data asset node referencing that suspected node. The processor aggregates these starting graph nodes into a parent node set. The parent node set may contain one or more parent nodes; if the parent node set is empty, it indicates that although the suspected node's content is abnormally challenging, no downstream node in the current target data asset's source dependency DAG actually references it. The processor can retain this suspected node in the suspected node list without calculating the false dependency penalty value.

[0040] Once the set of parent nodes is determined, the processor reads the asset registration transaction records of each parent node in the set and extracts a derivation operation logic summary from these records. The derivation operation logic summary includes an input data hash, a processing rule summary, and an output data hash. The input data hash represents a summary of the upstream data assets consumed by the parent node during its formation; the processing rule summary represents a summary of the rules by which the parent node performs cleaning, desensitization, aggregation, format conversion, or other processing rules on the input data to form the output data; and the output data hash represents a summary of the data asset content formed by the parent node. The processor first matches the on-chain baseline hash value of the suspected node with the input data hash. If they match, it indicates that the parent node did indeed declare that the suspected node was the input source; if they do not match, the parent node's reference relationship to the suspected node lacks proof of input consumption, which will be reflected in the false dependency penalty value later.

[0041] After the input data hash matches successfully, the processor performs a digest-level operation on the input data hash according to the processing rule digest to obtain the verification output hash. The digest-level operation does not require the processor to reacquire the complete plaintext data; instead, it performs a deterministic hash combination of the input data hash, rule version number, processing parameter digest, and parent node identifier according to the digest transformation order registered in the processing rule digest. For example, it can use... This describes the process of generating the output hash for verification, where... This indicates the output hash of the verification. Indicates the hash of the input data. This represents a summary of the processing rules. This represents a summary of the processing parameters. Indicates the parent node identifier, symbol This indicates that the data is concatenated according to the agreed-upon order of the asset registration transaction records. The processing parameter summary comes from the asset registration transaction records of the parent node and is used to indicate the set of parameters used when executing the processing rule summary, such as the field selection range, desensitization level, and time truncation range. The processor then compares the verification output hash with the output data hash to generate the operation association verification result corresponding to each parent node. The operation association verification result records at least three states: input data hash mismatch, verification output hash and output data hash inconsistent, and operation association verification passed. This result will directly participate in the subsequent accumulation of false dependency penalty values.

[0042] Based on the results of the computational association verification, the false dependency penalty value of suspected nodes is accumulated. When the proportion of the false dependency penalty value to the number of parent nodes exceeds the preset penalty threshold, the suspected node is judged as a shadow node. Furthermore, based on the results of the computational association verification, the false dependency penalty value of suspected nodes is accumulated. When the proportion of the false dependency penalty value to the number of parent nodes exceeds a preset penalty threshold, the suspected node is determined to be a shadow node, including: Establish penalty count data for suspected nodes; Read the operation association verification results corresponding to each parent node in the parent node set one by one; When the operation association verification result indicates that the input data hash does not match, the parent node is written into the unconsumed proof set, and the penalty count data is incremented by one; When the hash of the operation association verification result is inconsistent with the hash of the output data, the parent node is written into the derived inconsistent set, and the penalty count data is incremented by one. Read the number of nodes in the parent node set, and use the penalty count data and the number of nodes in the parent node set to form the penalty percentage data; The penalty percentage data is compared with the preset penalty threshold. When the penalty percentage data exceeds the preset penalty threshold, the suspected node identifier, the set of unconsumed proofs, and the derived inconsistency set are written into the shadow node record.

[0043] In one specific implementation, based on the aforementioned computational correlation verification results, the processor establishes penalty count data for each suspected node. The initial value of the penalty count data is 0, and an unconsumed proof set and a derived inconsistency set are established for the suspected node. The processor reads the computational correlation verification results corresponding to each parent node in the parent node set item by item. When the computational correlation verification result indicates that the input data hash does not match, it means that although the parent node points to the suspected node through a directed connection edge in the tracing dependency directed acyclic graph, its asset registration transaction record does not register the on-chain base hash value of the suspected node as the input data hash. The processor writes the parent node into the unconsumed proof set and increments the penalty count data by one. When the computational correlation verification result indicates that the verification output hash is inconsistent with the output data hash, it means that the processing rule summary registered by the parent node cannot derive the declared input data hash to the registered output data hash. The processor writes the parent node into the derived inconsistency set and increments the penalty count data by one.

[0044] After all parent nodes have been processed, the processor reads the number of nodes in the parent node set and uses the penalty count data and the number of nodes in the parent node set to form the penalty percentage data. The penalty percentage data can be represented as... in, This indicates the percentage of penalties. This represents the penalty count data. This indicates the number of nodes in the parent node set. If the number of nodes in the parent node set is 0, no penalty percentage data is calculated to avoid incorrectly identifying unreferenced nodes. The preset penalty threshold can be set according to data asset management rules, such as 0.5, 0.6, or 0.7; for high-value data assets, a stricter threshold can also be used. The processor compares the penalty percentage data with the preset penalty threshold. When the penalty percentage data exceeds the preset penalty threshold, the suspected node identifier, the set of unconsumed proofs, and the set of derived inconsistencies are written together into the shadow node record. The shadow node record may also include the on-chain baseline hash value of the suspected node, the corresponding high-sensitivity probe node verification digest, the number of nodes in the parent node set, and the penalty percentage data. After this layer of judgment, the shadow node is no longer just a node with abnormal content challenges, but a node that simultaneously exhibits unverifiable on-chain content and inconsistent downstream derivative relationships.

[0045] Tracing back along the reference path of the shadow node to the reliable ancestor node, a logical redirection pointer is generated to connect the parent node and the reliable ancestor node; Furthermore, by tracing back along the reference path of the shadow node to the reliable ancestor node, a logical redirection pointer is generated to connect the parent node and the reliable ancestor node, including: Read the shadow node identifiers from the shadow node records, and extract the set of parent nodes and upstream reference paths of the shadow nodes in the source dependency directed acyclic graph; Read the asset registration and transaction records of ancestor nodes layer by layer along the upstream reference path; Perform on-chain existence verification and content challenge verification on ancestor nodes; Mark the first ancestor node that passes both the on-chain existence proof verification and the content challenge proof verification as a reliable ancestor node; Read the derivation operation logic summary of each parent node in the parent node set, and replace the original input data hash with the on-chain base hash value of the reliable ancestor node to perform cross-node data derivation verification; When cross-node data derivation verification passes, a logical redirection pointer is generated that includes the parent node identifier, shadow node identifier, reliable ancestor node identifier, and a summary of the verification result.

[0046] In one specific implementation, after identifying a shadow node, the processor traces back to a reliable ancestor node along the shadow node's reference path. The processor reads the shadow node identifier from the shadow node record and extracts the set of parent nodes and upstream reference paths of the shadow node in the source dependency directed acyclic graph. The upstream reference path is formed by the shadow node pointing to the upstream graph node it references, and then the upstream graph node continuing to point to an earlier registered graph node. Since the source dependency directed acyclic graph has been checked for time sequence, when the processor reads ancestor nodes along the upstream reference path, it can expand layer by layer according to the block packaging and archiving time from the most recent to the oldest. Upon reaching each ancestor node, the processor reads the ancestor node's asset registration transaction record and obtains its blockchain identifier, on-chain base hash value, storage address, and content digest shard sequence. For each ancestor node, the processor performs on-chain existence proof verification and content challenge proof verification. The on-chain existence proof verification follows the aforementioned Merkel path verification method to confirm that the asset registration transaction record corresponding to the ancestor node does indeed exist in the blockchain ledger and is consistent with its blockchain identifier. The content challenge proof verification regenerates a random cryptographic seed, determines the shard position to be verified based on the ancestor node's content digest shard sequence, and requires the storage address bound to the ancestor node to return the corresponding content challenge proof. The processor marks the first ancestor node that passes both the on-chain existence proof verification and the content challenge proof verification as a reliable ancestor node. The first ancestor node is chosen as the reliable ancestor node because it is closest to the shadow nodes, which typically preserves the business meaning in the original tracing dependency structure to the greatest extent possible, while avoiding false dependency layers that have already been identified as shadow nodes.

[0047] After the reliable ancestor node is determined, the processor reads the derivation operation logic digests of each parent node in the parent node set and replaces the original input data hash with the on-chain base hash value of the reliable ancestor node for cross-node data derivation verification. The processor does not simply attach the parent node directly to the reliable ancestor node; instead, it first checks whether the replacement can still interpret the parent node's output data hash at the digest level. The processor hashes the reliable ancestor node's on-chain base hash value, the parent node's registered processing rule digest, the processing parameter digest, and the parent node identifier in a predetermined order to obtain the replaced verification output hash. Then, it compares the replaced verification output hash with the parent node's output data hash. If they match, it means the parent node's data derivation relationship can be directly supported by the reliable ancestor node; if they do not match, the parent node does not generate a logical redirection pointer to avoid destroying the true dependency relationship due to excessive reconstruction. When the cross-node data derivation verification passes, the processor generates a logical redirection pointer containing the parent node identifier, shadow node identifier, reliable ancestor node identifier, and a verification result digest. The verification result summary can be obtained by hashing the input, processing rule summary, output comparison result and generation time used for cross-node data derivation verification, and is used for subsequent audit review.

[0048] Update the source dependency directed acyclic graph based on logical redirection pointers, and output a clean source tree and source purification log.

[0049] Furthermore, based on the logical redirection pointers, the directed acyclic graph of source dependencies is updated, and a clean source tree and source cleanup logs are output, including: Read the parent node identifier, shadow node identifier, and reliable ancestor node identifier from the logical redirection pointer; In the presentation layer data of the source-dependent directed acyclic graph, freeze the original connection edges from parent nodes to shadow nodes; Generate alternative connection edges based on the parent node identifier and the reliable ancestor node identifier; Write the replacement connection edge into the presentation layer data, while retaining the original connection edge's reference record in the underlying blockchain ledger; Based on the updated presentation layer data, the root hash corresponding to the target data asset is recalculated to generate a pure source tree; The shadow node records, original connecting edges, replacement connecting edges, logical redirection pointers, and root hash are arranged in chronological order to form the source purification log; Output a clean source tree as the default source tracing result, and output source purification logs as audit traceability data.

[0050] In one specific implementation, after the logical redirection pointer is generated, the processor updates the source dependency directed acyclic graph (DAG) based on the logical redirection pointer. This update occurs in the presentation layer data of the source dependency DAG, without altering the asset registration transaction records already registered in the underlying blockchain ledger. The processor reads the parent node identifier, shadow node identifier, and reliable ancestor node identifier from the logical redirection pointer, and finds the original connection edge pointing from the parent node to the shadow node in the presentation layer data. Even after the original connection edge is frozen, its edge identifier, freezing time, and freezing reason are retained, but it no longer participates in valid path calculations during default source display and root hash calculation. Subsequently, the processor generates a replacement connection edge based on the parent node identifier and reliable ancestor node identifier. The direction of the replacement connection edge is from the parent node to the reliable ancestor node, and a binding relationship is established with the corresponding logical redirection pointer. The processor writes the replacement connection edge into the presentation layer data, while retaining the reference record of the original connection edge in the underlying blockchain ledger, so that subsequent auditors can still see the original on-chain registration state.

[0051] After the presentation layer data is updated, the processor recalculates the root hash corresponding to the target data asset based on the updated presentation layer data, generating a pure tracing tree. The root hash calculation can start from the leaf ancestor node, merging the on-chain baseline hash value, valid connection edge identifier, and timestamp information of each graph node layer by layer according to the block packaging and archiving time and directed connection edge relationship, until the graph node containing the root blockchain identifier corresponding to the target data asset is located. If a graph node has multiple upstream connection edges, the processor determines the merging order according to the block packaging and archiving time of the upstream graph nodes and the lexicographical order of the blockchain identifier, ensuring that the same presentation layer data can obtain a stable and consistent root hash. The pure tracing tree does not delete the shadow node itself, but bypasses the shadow node in the default tracing path and presents the verified data derivative path with a replacement connection edge, thereby avoiding false dependency levels from further increasing the tracing complexity of the target data asset.

[0052] Simultaneously, the processor assembles a source tracing and purification log in chronological order, consisting of shadow node records, existing connections, replacement connections, logical redirection pointers, and the root hash. Each log entry in the source tracing and purification log includes the generation time, operator identifier or system task identifier, relevant blockchain identifier, and the log hash of the previous log entry. Each subsequent log entry references the log hash of the previous log entry, forming a log-level sequential chain to prevent subsequent undetected modifications to the purification process. The processor ultimately outputs a clean source tracing tree as the default source tracing result and the source tracing and purification log as audit traceability data. The default source tracing result is used for data asset valuation, compliance review, and circulation display; the audit traceability data is used to explain which connections were identified as being affected by shadow nodes, why logical redirection pointers were generated, and how the updated root hash was formed.

[0053] Example 2: This application also discloses a blockchain-based data asset identification and traceability system.

[0054] Reference Figure 2 A blockchain-based data asset identification and traceability system includes: The dependency graph construction module is used to parse the blockchain identifier sequence associated with the target data assets, read the asset registration transaction records corresponding to each blockchain identifier, extract the preceding reference hash pointer and the block packaging and archiving time, and construct a source dependency directed acyclic graph containing node reference relationships and timestamp information. The detection node screening module is used to screen out highly sensitive detection nodes based on the ratio of the in-degree to the out-degree of each node in the source-dependent directed acyclic graph. The content challenge module is used to generate a random cryptographic seed and send it to the storage address bound to the high-sensitivity probe node, and receive a response data packet containing an on-chain existence proof, a content challenge proof, and an on-chain baseline hash value; The suspected node determination module is used to verify the on-chain existence proof and the content challenge proof. When the on-chain existence proof passes but the content challenge proof fails, the corresponding high-sensitivity detection node is marked as a suspected node. The lineage query module is used to traverse the source dependency directed acyclic graph, extract the set of parent nodes of suspected reference nodes, and perform operation association verification on the suspected nodes based on the derivative operation logic summary registered in the set of parent nodes. The shadow node determination module is used to accumulate the false dependency penalty value of suspected nodes based on the operation association verification results. When the proportion of the false dependency penalty value to the number of parent nodes exceeds the preset penalty threshold, the suspected node is determined to be a shadow node. The relationship reconstruction module is used to trace back the reliable ancestor node along the reference path of the shadow node and generate a logical redirection pointer to connect the parent node and the reliable ancestor node. The source tracing output module is used to update the source tracing dependency directed acyclic graph based on the logical redirection pointer, and output a clean source tracing tree and source tracing purification log.

[0055] The above content is merely an example and illustration of the concept of the present invention. Those skilled in the art can make various modifications or additions to the specific embodiments described or use similar methods to replace them, as long as they do not deviate from the concept of the invention, they should all fall within the protection scope of the present invention.

[0056] In the description of this specification, references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0057] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to any specific implementation. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention.

Claims

1. A blockchain-based method for identifying and tracing data assets, characterized in that, Includes the following steps: Parse the blockchain identifier sequence associated with the target data assets, read the asset registration transaction records corresponding to each blockchain identifier, extract the preceding reference hash pointer and block packaging and archiving time, and construct a traceability dependency directed acyclic graph containing node reference relationships and timestamp information; Highly sensitive detection nodes are selected based on the in-degree to out-degree ratio of each node in the source-dependent directed acyclic graph. Generate a random encryption seed and send it to the storage address bound to the high-sensitivity probe node, and receive a response data packet containing on-chain existence proof, content challenge proof and on-chain baseline hash value; Verify the on-chain existence proof and the content challenge proof. If the on-chain existence proof passes but the content challenge proof fails, mark the corresponding high-sensitivity detection node as a suspected node. Traverse the source-dependent directed acyclic graph, extract the set of parent nodes of suspected reference nodes, and perform operation association verification on suspected nodes based on the derivation operation logic summary registered in the parent node set; Traverse the source-dependent directed acyclic graph, extract the set of parent nodes of suspected reference nodes, and perform operation association verification on the suspected nodes based on the derived operation logic summary registered in the parent node set, including: Read the suspected node identifiers sequentially from the suspected node list; In the source-dependent directed acyclic graph, reverse the search for directed connecting edges pointing to the suspected node identifier, and summarize the starting graph nodes of the directed connecting edges into a set of parent nodes. Read the asset registration and transaction records of each parent node in the parent node set; Extract the derivative operation logic summary from the asset registration transaction records of each parent node. The derivative operation logic summary includes the input data hash, the processing rule summary, and the output data hash. Match the on-chain baseline hash value of the suspected node with the hash of the input data; After a successful match, the input data hash is processed according to the processing rule digest to perform a digest-level operation, resulting in the verification output hash. The verification output hash is compared with the output data hash to generate the operation association verification result corresponding to each parent node; Based on the results of the computational association verification, the false dependency penalty value of suspected nodes is accumulated. When the proportion of the false dependency penalty value to the number of parent nodes exceeds the preset penalty threshold, the suspected node is judged as a shadow node. Tracing back along the reference path of the shadow node to the reliable ancestor node, a logical redirection pointer is generated to connect the parent node and the reliable ancestor node; Update the source dependency directed acyclic graph based on logical redirection pointers, and output a clean source tree and source purification log.

2. The data asset identification and traceability method based on blockchain according to claim 1, characterized in that, Construct a directed acyclic graph of dependencies that includes node references and timestamp information, including: Read the root blockchain identifier from the target data asset registration data, and extract the upstream blockchain identifier layer by layer along the preceding reference hash pointer recorded in the root blockchain identifier to form a blockchain identifier sequence; Retrieve the corresponding asset registration transaction record from the blockchain ledger based on the blockchain identifier sequence; Extract the asset content summary, front reference hash pointer, and block packaging and archiving time from the asset registration transaction record; Map each blockchain identifier to a graph node, and write the block packaging and archiving time into the corresponding graph node; By establishing directed connections between graph nodes based on the preceding reference hash pointers, an initial dependency graph is obtained; Based on the block packaging and archiving time of the graph nodes, a reverse time check is performed on the initial dependency graph. Connection edges with mismatched time order are moved into the abnormal edge set, and the remaining connection edges are used to generate a source dependency directed acyclic graph.

3. The data asset identification and traceability method based on blockchain according to claim 2, characterized in that, Highly sensitive detection nodes are selected based on the in-degree to out-degree ratio of each node in the source-dependent directed acyclic graph, including: Statistical sourcing relies on the in-degree data of each graph node in the directed acyclic graph, which is referenced by downstream graph nodes, and the out-degree data of each graph node, which is referenced by upstream graph nodes. The node reference offset value is obtained by calculating the ratio of in-degree data to out-degree data at the same scale. Read the block packaging and archiving time corresponding to each graph node, calculate the number of adjacent nodes with reference relationships to the graph node within the same time window, and obtain the node time aggregation value; Bind node reference offset values ​​to node temporal aggregation values ​​as node detection features; Based on the node detection characteristics, graph nodes with concentrated in-degree and time clusters are screened out to generate a list of highly sensitive detection nodes.

4. The data asset identification and traceability method based on blockchain according to claim 1, characterized in that, Generate a random encryption seed and send it to the storage address bound to the high-sensitivity probe node. Receive a response data packet containing on-chain existence proof, content challenge proof, and on-chain baseline hash value, including: Generate random encryption seeds with time-sensitive verification codes for high-sensitivity detection nodes; The position of the fragment to be verified with a predetermined number of bits is determined from the content digest fragment sequence registered by the high-sensitivity detection node based on the random encryption seed; The challenge request data consists of a random encrypted seed, the shard location to be verified, and the blockchain identifier of the highly sensitive probe node; Send the challenge request data to the storage address bound to the highly sensitive detection node; The system receives a response data packet returned by the storage address. The response data packet includes an on-chain existence proof corresponding to the high-sensitivity probe node, a content challenge proof generated by the content digest shard corresponding to the shard position to be verified, and an on-chain baseline hash value in the asset registration transaction record.

5. The data asset identification and traceability method based on blockchain according to claim 4, characterized in that, Verify the on-chain existence proof and the content challenge proof. If the on-chain existence proof passes but the content challenge proof fails, mark the corresponding high-sensitivity detection node as a suspected node, including: Extract the on-chain existence proof from the response data packet, and verify whether the on-chain existence proof corresponds to the same asset registration transaction record based on the blockchain identifier of the high-sensitivity probe node; After the on-chain existence proof is passed, extract the content digest shard and shard position from the content challenge proof; The content summary is divided and reorganized into a challenge summary sequence according to the segment position; The challenge summary sequence is hashed together with the random encryption seed to obtain the hash value of the challenge to be compared; Perform a consistency check between the challenge hash value to be compared and the on-chain baseline hash value in the response data packet; When the consistency check fails and the response data packet returns outside the time window specified by the timeliness check code, the corresponding high-sensitivity detection node is added to the list of suspected nodes.

6. The data asset identification and traceability method based on blockchain according to claim 1, characterized in that, Based on the results of the correlation verification, the false dependency penalty value of suspected nodes is accumulated. When the proportion of the false dependency penalty value to the number of parent nodes exceeds a preset penalty threshold, the suspected node is determined to be a shadow node, including: Establish penalty count data for suspected nodes; Read the operation association verification results corresponding to each parent node in the parent node set one by one; When the operation association verification result indicates that the input data hash does not match, the parent node is written into the unconsumed proof set, and the penalty count data is incremented by one; When the hash of the operation association verification result is inconsistent with the hash of the output data, the parent node is written into the derived inconsistent set, and the penalty count data is incremented by one. Read the number of nodes in the parent node set, and use the penalty count data and the number of nodes in the parent node set to form the penalty percentage data; The penalty percentage data is compared with the preset penalty threshold. When the penalty percentage data exceeds the preset penalty threshold, the suspected node identifier, the set of unconsumed proofs, and the derived inconsistency set are written into the shadow node record.

7. The data asset identification and traceability method based on blockchain according to claim 6, characterized in that, Tracing back along the reference path of the shadow node to the reliable ancestor node, a logical redirection pointer is generated to connect the parent node and the reliable ancestor node, including: Read the shadow node identifiers from the shadow node records, and extract the set of parent nodes and upstream reference paths of the shadow nodes in the source dependency directed acyclic graph; Read the asset registration and transaction records of ancestor nodes layer by layer along the upstream reference path; Perform on-chain existence verification and content challenge verification on ancestor nodes; Mark the first ancestor node that passes both the on-chain existence proof verification and the content challenge proof verification as a reliable ancestor node; Read the derivation operation logic summary of each parent node in the parent node set, and replace the original input data hash with the on-chain base hash value of the reliable ancestor node to perform cross-node data derivation verification; When cross-node data derivation verification passes, a logical redirection pointer is generated that includes the parent node identifier, shadow node identifier, reliable ancestor node identifier, and a summary of the verification result.

8. The data asset identification and traceability method based on blockchain according to claim 7, characterized in that, Update the directed acyclic graph of source dependencies based on logical redirection pointers, and output a clean source tree and source cleanup log, including: Read the parent node identifier, shadow node identifier, and reliable ancestor node identifier from the logical redirection pointer; In the presentation layer data of the source-dependent directed acyclic graph, freeze the original connection edges from parent nodes to shadow nodes; Generate alternative connection edges based on the parent node identifier and the reliable ancestor node identifier; Write the replacement connection edge into the presentation layer data, while retaining the original connection edge's reference record in the underlying blockchain ledger; Based on the updated presentation layer data, the root hash corresponding to the target data asset is recalculated to generate a pure source tree; The shadow node records, original connecting edges, replacement connecting edges, logical redirection pointers, and root hash are arranged in chronological order to form the source purification log; Output a clean source tree as the default source tracing result, and output source purification logs as audit traceability data.

9. A blockchain-based data asset identification and traceability system, applied to the blockchain-based data asset identification and traceability method described in any one of claims 1-8, characterized in that, include: The dependency graph construction module is used to parse the blockchain identifier sequence associated with the target data assets, read the asset registration transaction records corresponding to each blockchain identifier, extract the preceding reference hash pointer and the block packaging and archiving time, and construct a source dependency directed acyclic graph containing node reference relationships and timestamp information. The detection node screening module is used to screen out highly sensitive detection nodes based on the ratio of the in-degree to the out-degree of each node in the source-dependent directed acyclic graph. The content challenge module is used to generate a random cryptographic seed and send it to the storage address bound to the high-sensitivity probe node, and receive a response data packet containing an on-chain existence proof, a content challenge proof, and an on-chain baseline hash value; The suspected node determination module is used to verify the on-chain existence proof and the content challenge proof. When the on-chain existence proof passes but the content challenge proof fails, the corresponding high-sensitivity detection node is marked as a suspected node. The lineage query module is used to traverse the source dependency directed acyclic graph, extract the set of parent nodes of suspected reference nodes, and perform operation association verification on the suspected nodes based on the derivative operation logic summary registered in the set of parent nodes. The shadow node determination module is used to accumulate the false dependency penalty value of suspected nodes based on the operation association verification results. When the proportion of the false dependency penalty value to the number of parent nodes exceeds the preset penalty threshold, the suspected node is determined to be a shadow node. The relationship reconstruction module is used to trace back the reliable ancestor node along the reference path of the shadow node and generate a logical redirection pointer to connect the parent node and the reliable ancestor node. The source tracing output module is used to update the source tracing dependency directed acyclic graph based on the logical redirection pointer, and output a clean source tracing tree and source tracing purification log.

10. A computer-readable storage medium, characterized in that: The system stores instructions that, when executed on a computer, cause the computer to perform a blockchain-based data asset identification and traceability method as described in any one of claims 1 to 8.

Images