A data asset traceability method, device, equipment and storage medium

Abstract

Embodiments of the present application disclose a data asset tracing method, device and equipment and a storage medium. The method comprises: obtaining a data asset to be traced, and constructing a multi-way tracing index tree for the data asset; performing field-level segmentation on the data asset to obtain M data units, and generating an asset hash value of the data asset based on hash value aggregation of the M data units; creating K first leaf nodes corresponding to the M data units under a shard storage verification branch; creating P second leaf nodes corresponding to the M data units under an asset granularity index branch; and establishing a bidirectional mapping relationship between the K first leaf nodes and the P second leaf nodes through bidirectional hash anchor pointers. In response to a tracing query request of the data asset, the multi-way tracing index tree is located through a globally unique code of the data asset, and the data asset is verified and a tracing result is output based on the K first leaf nodes and the P second leaf nodes in the multi-way tracing index tree.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a data asset traceability method, a data asset traceability device, a computer device, and a computer-readable storage medium. Background Technology

[0002] With the rapid development of blockchain technology, its decentralized, immutable, and timestamped notarization characteristics provide new technical support for the authenticity and traceability of data assets. Currently, blockchain-based data asset traceability solutions typically employ an architecture combining a fixed-level index tree with overall granular hash verification. Specifically, the system constructs a fixed-level, fixed-branch index tree for the data asset to be traced. The system calculates the hash value of the data asset as a whole and stores it on the blockchain. Simultaneously, the entire data asset is uploaded to a decentralized storage network, and the storage address pointer is recorded in the leaf nodes of the index tree. During traceability, the system retrieves the entire data asset from the decentralized storage network, recalculates its hash value, and compares it with the hash value stored on the blockchain. If they match, the data asset is considered tamper-proof.

[0003] Research has found that when data assets are hashed at the overall granularity in practical applications, if a certain field of the data asset is tampered with, the overall hash verification can only indicate that the data has been modified, but cannot accurately locate the specific field that has been tampered with, making it difficult for the traceability results to support effective security auditing and problem investigation. Summary of the Invention

[0004] This application provides a data asset traceability method, apparatus, device, and computer-readable storage medium, which can reduce the verification granularity of data assets from the overall asset level down to the field level, and achieve precise location of tampering.

[0005] On the one hand, embodiments of this application provide a data asset traceability method, including: Obtain the data assets to be traced and construct a multi-branch traceability index tree for the data assets. The root node of the multi-branch traceability index tree includes the globally unique code of the data assets. The multi-branch traceability index tree includes a sharded storage verification branch and an asset granularity index branch. The data asset is segmented at the field level to obtain M data units. The hash values ​​of the M data units are aggregated to generate the asset hash value of the data asset. The asset hash value is recorded in the root node of the multi-branch traceability index tree. The asset hash value is used to store the data asset in the blockchain. M is a positive integer. Under the sharded storage verification branch, create K first leaf nodes corresponding to M data units. Each first leaf node contains the storage address pointer of the corresponding data unit. The storage address pointers of the M data units are obtained by uploading the M data units to the decentralized storage network, and K is a positive integer. Under the asset granularity index branch, create P second leaf nodes corresponding to M data units, and establish a bidirectional mapping relationship between K first leaf nodes and P second leaf nodes through bidirectional hash anchor pointers. Each second leaf node contains the storage address pointer of the corresponding data unit, where P is a positive integer. In response to a data asset traceability query request, the multi-branch traceability index tree is located through the globally unique code of the data asset. The data asset traceability query request includes the field to be queried. Based on the storage address pointer recorded in the target first leaf node or target second leaf node in the multi-branch traceability index tree, the encrypted unit corresponding to the field to be queried is pulled from the decentralized storage network. The target first leaf node is the first leaf node corresponding to the field to be queried. The target first leaf node records the identifier of the target operation node. The target operation node is the latest operation node of the data unit corresponding to the target first leaf node. The target second leaf node is the second leaf node corresponding to the field to be queried. The verification hash value is compared with the hash value corresponding to the field to be queried in the blockchain to obtain the first verification result of the data asset. The verification hash value is obtained by hashing the decryption result of the encrypted unit. By tracing back the operation records of the data asset through the operation pointer in the target operation node, and inferring the theoretical hash value of the data asset based on the operation records; The theoretical hash value is compared with the hash value corresponding to the field to be queried in the blockchain to obtain the second verification result of the data asset. Based on the first and second verification results, the tracing results are output.

[0006] On one hand, embodiments of this application provide a data asset traceability device, which includes: The acquisition unit is used to acquire the data assets to be traced and to build a multi-branch traceability index tree for the data assets. The root node of the multi-branch traceability index tree includes the globally unique code of the data assets. The multi-branch traceability index tree includes a sharded storage verification branch and an asset granularity index branch. The processing unit is used to perform field-level segmentation of the data asset to obtain M data units. Based on the hash values ​​of the M data units, the asset hash value of the data asset is generated by aggregating the hash values ​​and recording the asset hash value in the root node of the multi-branch traceability index tree. The asset hash value is used to store the data asset in the blockchain. M is a positive integer. And used to create K first leaf nodes corresponding to M data units under the sharded storage verification branch. Each first leaf node contains the storage address pointer of the corresponding data unit. The storage address pointers of the M data units are obtained by uploading the M data units to the decentralized storage network, and K is a positive integer. And used to create P second leaf nodes corresponding to M data units under the asset granularity index branch, and to establish a bidirectional mapping relationship between K first leaf nodes and P second leaf nodes through bidirectional hash anchor pointers. Each second leaf node contains the storage address pointer of the corresponding data unit, where P is a positive integer. And for responding to data asset traceability query requests, the multi-branch traceability index tree is located through the globally unique code of the data asset. The data asset traceability query request includes the field to be queried. Based on the storage address pointer recorded in the target first leaf node or target second leaf node in the multi-branch traceability index tree, the encrypted unit corresponding to the field to be queried is pulled from the decentralized storage network. The target first leaf node is the first leaf node corresponding to the field to be queried. The target first leaf node records the identifier of the target operation node. The target operation node is the latest operation node of the data unit corresponding to the target first leaf node. The target second leaf node is the second leaf node corresponding to the field to be queried. The verification hash value is compared with the hash value corresponding to the field to be queried in the blockchain to obtain the first verification result of the data asset. The verification hash value is obtained by hashing the decryption result of the encrypted unit. By tracing back the operation records of the data asset through the operation pointer in the target operation node, and inferring the theoretical hash value of the data asset based on the operation records; The theoretical hash value is compared with the hash value corresponding to the field to be queried in the blockchain to obtain the second verification result of the data asset. Based on the first and second verification results, the tracing results are output.

[0007] In one implementation, the multi-branch traceability index tree includes a first-level root node, second-level fixed branch nodes, third-level management dimension nodes, and fourth-level time-series leaf nodes; the sharded storage verification branch and the asset granularity index branch are contained in the second-level fixed branch nodes, and the second-level fixed branch nodes also include operation behavior index branches and ownership change index branches.

[0008] In one embodiment, the processing unit is further configured to: In response to the edit operation of the target data unit, calculate the hash value of the edited target data unit, where the target data unit is any one of the M data units; Create an operation node corresponding to the edit operation under the operation behavior index branch. The operation node includes at least one of the following: the identifier of the target data unit, the hash value of the target data unit before the operation, the hash value of the target data unit after the operation, and the operation metadata. Update the hash value corresponding to the target data unit in the first leaf node associated with the target data unit, and set the operation node corresponding to the edit operation as the latest operation node pointed to by the first leaf node; and... Update the hash value corresponding to the target data unit in the second leaf node associated with the target data unit, and use the operation node corresponding to the edit operation as the latest operation node pointed to by the second leaf node; The update of the operation node corresponding to the editing operation, the update of the first leaf node associated with the target data unit, and the update of the second leaf node associated with the target data unit are stored on the blockchain through the same transaction.

[0009] In one embodiment, the processing unit is further configured to: Collect dynamic metrics for each third-level management dimension node in the multi-branch traceability index tree. The dynamic metrics include: total number of leaf nodes, number of newly added leaf nodes per unit time, number of traceability query hits per unit time, and total number of different first leaf nodes associated with all second leaf nodes under the third-level management dimension node. When the dynamic indicators of any third-level management dimension node meet the preset triggering conditions within at least two consecutive statistical periods, the third-level management dimension node initiates a reconstruction proposal, which is used to restructure the multi-branch traceability index tree.

[0010] In one implementation, the preset triggering condition includes at least one of the following: The total number of leaf nodes under the three-level management dimension exceeds the first threshold, and the number of newly added leaf nodes per unit time exceeds the second threshold. The total number of different first leaf nodes associated with all second leaf nodes under the third-level management dimension node exceeds the third threshold. The total number of leaf nodes under any derived second-level branch node in the multi-branch traceability index tree is less than the fourth threshold, and the number of times that derived second-level branch node is hit by traceability queries within a unit of time is zero.

[0011] In one implementation, the processing unit is configured to establish a bidirectional mapping relationship between K first leaf nodes and P second leaf nodes through bidirectional hash anchor pointers, specifically configured to: For K first leaf nodes, write reverse anchor pointers. The reverse anchor pointer of any first leaf node records a list of all the identifiers of the second leaf nodes that point to that first leaf node. For P second leaf nodes, write forward anchor pointers. The forward anchor pointer of any second leaf node records a list of identifiers of all first leaf nodes that point to that second leaf node.

[0012] Accordingly, this application provides a computer device comprising: Memory, which stores computer programs; The processor is used to load computer programs to implement the aforementioned data asset traceability method.

[0013] Accordingly, this application provides a computer-readable storage medium storing a computer program adapted to be loaded by a processor and executed by the above-described data asset tracing method.

[0014] In this embodiment, data assets are segmented at the field level, giving each data unit an independent hash value. Each data unit is then independently uploaded to a decentralized storage network. Corresponding leaf nodes are created under the sharded storage verification branch and the asset-granularity index branch of the index tree, respectively. A bidirectional mapping relationship is established between the leaf nodes under the two branches through bidirectional hash anchor pointers. Based on this bidirectional mapping relationship, during traceability queries, the corresponding storage verification node and storage address pointer can be quickly located through the field node, thereby accurately obtaining and verifying the data status of a specific field. When verification fails, the specific data unit that has been tampered with can be directly located. This reduces the verification granularity of data assets from the overall asset level down to the field level, achieving precise location of tampering. Attached Figure Description

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

[0016] Figure 1 A flowchart illustrating a data asset traceability method provided in this application embodiment; Figure 2 A schematic diagram illustrating a dynamic adaptive reconstruction process for an index tree, provided as an embodiment of this application; Figure 3 A schematic diagram of the structure of a data asset traceability device provided in this application embodiment; Figure 4 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0017] It should be noted in advance that, in order to enable those skilled in the art to better understand the technical solutions proposed in the embodiments of this application, the embodiments of this application will be described clearly and completely in conjunction with one or more accompanying drawings. Furthermore, the various drawings shown in the embodiments of this application are merely illustrative examples; for example, the execution order of each step in the drawings can be adaptively adjusted according to the actual application scenario. In addition, in the embodiments of this application, the block diagrams shown in the various drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, or in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0018] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0019] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0020] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0021] It should be noted that "multiple" in this article refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0022] This application relates to data asset traceability technology in a blockchain decentralized storage scenario. For ease of understanding, the terminology that may be used in this application embodiment will be explained below.

[0023] Data assets refer to assets that exist in digital form and have certain economic or managerial value, including but not limited to structured data (such as data records in JSON, XML, and Avro formats), unstructured data (such as text, images, audio, and binary files), and mixed-type data. In this application embodiment, data assets are the core objects that need to be traced and managed.

[0024] Multi-branch traceability index tree: This refers to a tree-like data structure used to organize and manage traceability information of data assets, where each node can have multiple child nodes (i.e., a multi-branch structure). The index tree contains a first-level root node, second-level fixed branch nodes, third-level management dimension nodes, and fourth-level time-series leaf nodes. The second-level fixed branch nodes include at least a sharded storage verification branch and an asset-granularity index branch. This index tree is used to record multi-dimensional traceability information of data assets, such as field partitioning, storage location, and operation history.

[0025] Data unit: refers to the basic data fragment obtained after field-level segmentation of data assets. For structured data, a data unit is an atomic field that is recursively parsed according to semantic boundaries until it cannot be further divided, that is, a basic semantic unit existing in the form of key-value pairs; for unstructured data, a data unit is a data fragment obtained after continuous segmentation according to a preset block size.

[0026] Storage address pointer: This refers to the address identifier returned by the decentralized storage network (such as IPFS) after a data unit is uploaded to it, used to uniquely identify and locate the data unit. In IPFS, this address identifier is the Content Identifier (CID).

[0027] Bidirectional hash anchor pointers: In a multi-branch tracing index tree, this refers to a pointer mechanism used to establish a bidirectional mapping relationship between the first leaf node (located under the sharded storage verification branch) and the second leaf node (located under the asset granularity index branch). Specifically, a forward anchor pointer is recorded in the second leaf node and points to the first leaf node corresponding to that second leaf node; a reverse anchor pointer is recorded in the first leaf node and points to all second leaf nodes that point to that first leaf node.

[0028] Dual verification refers to two independent and redundant verification methods for tracing the origin of data assets. The first verification method (also known as "direct field verification") retrieves data units from a decentralized storage network, recalculates their hash values, and compares them with the hash values ​​stored on the blockchain. The second verification method (also known as "operation replay") traces back operation records and replays the hash change history to deduce the theoretical hash value, which is then compared with the hash value stored on the blockchain. The two paths are independent and can cross-verify the legitimacy of the data asset's state.

[0029] Dynamic restructuring refers to a mechanism that automatically adjusts the structure of a multi-branch tracing index tree based on real-time dynamic metrics of each node through smart contracts. Restructuring types include upgrading (promoting a third-level node to a new derived second-level branch node), downgrading / merging (compressing and merging inactive branches), and splitting (splitting a bloated node into multiple child nodes).

[0030] Please see Figure 1 , Figure 1 This is a flowchart illustrating a data asset traceability method provided in an embodiment of this application. This data asset traceability method can be executed by a computer device. Figure 1 As shown, the data asset traceability method may include the following steps S101 to S105.

[0031] S101. Obtain the data assets to be traced and construct a multi-branch traceability index tree for the data assets.

[0032] The root node of the multi-branch traceability index tree includes the globally unique code of the data asset, and the multi-branch traceability index tree includes a sharded storage verification branch and an asset granularity index branch.

[0033] In this embodiment, when a new data asset needs to be included in traceability management, the computer device first acquires the data asset and assigns it a globally unique traceability identification code (referred to as AssetID). This code serves as the root node of the data asset's traceability index tree. There are various ways to generate the AssetID. For example, the computer device can use a hash algorithm to perform a hash calculation on the uploader's public key, timestamp, and random number, and use the calculation result as the AssetID; alternatively, it can use a Universally Unique Identifier (UUID) or the Snowflake algorithm to generate a globally unique identifier. The AssetID generated in the above ways is globally unique and unforgeable, providing a reliable root node identifier for the data asset's index tree.

[0034] In one implementation, the multi-branch tracing index tree may include a first-level root node, second-level fixed branch nodes, third-level management dimension nodes, and fourth-level time-series leaf nodes. The first-level root node is the globally unique code AssetID for the data asset. Under the first-level root node, the computer device atomically creates four fixed second-level branch nodes to divide the data asset into different management dimensions. The four second-level fixed branch nodes do not overlap and have clearly defined responsibilities, specifically including: (1) Asset Granularity Index Branch: Used to mount and manage field-level information related to the data content itself. This branch will record the core traceability data such as the data units after the data assets have been segmented at the field level, their hash values, and storage address pointers.

[0035] (2) Operation Behavior Index Branch: This branch records the entire lifecycle of data assets from creation to their current state, including but not limited to operations such as adding, editing, deleting, and confirming ownership. Each operation record is attached to this branch as an independent leaf node, forming a traceable chain of operation history.

[0036] (3) Ownership Change Index Branch: This branch records all transfer records related to ownership and authorization, including events such as ownership transfer, authorization, and revocation of authorization. This branch provides a basis for tracing the ownership of data assets.

[0037] (4) Sharded Storage Verification Branch: This branch is used to establish the hash base for storage shards, serving as the core bridge anchoring data units and storage addresses. Under this branch, hash base leaf nodes will be created that correspond one-to-one with data units, recording the storage address pointer and hash value of the data units for use in all subsequent verification operations.

[0038] It should be noted that the four second-level fixed branch nodes mentioned above are fixed during the index tree initialization phase, and their type and number remain unchanged throughout the tree structure's lifecycle. The division of the four branches is not simply about storing different categories of information separately, but rather about providing structural support for subsequent field-level mapping and dual verification. Specifically, the bidirectional anchoring relationship between the asset granularity index branch and the sharded storage verification branch is established through pointers between the leaf nodes under these two branches, while the operation behavior index branch provides the data source of operation records for the "operation replay" path in dual verification. The three branches (asset granularity index branch, sharded storage verification branch, and operation behavior index branch) are structurally independent but functionally complementary, together forming the underlying architectural foundation for field-level traceability and dual verification.

[0039] Under each second-level fixed branch node, the computer equipment generates third-level subdivided nodes according to a predefined business pattern, providing precise mounting points for subsequent leaf nodes. For example, under the asset granularity index branch, third-level nodes can be pre-created: overall asset node → module unit node → data unit node, where the "data unit node" is the direct mounting point for the leaf nodes. Under the operation behavior index branch, third-level nodes can be pre-created: add node → edit node → delete / invalidate node → ownership confirmation node, used to distinguish different types of operation records. Under the ownership change index branch, third-level nodes can be pre-created: ownership transfer node → authorization node → revocation authorization node. Under the sharded storage verification branch, a third-level node: hash baseline node, under which fourth-level leaf nodes corresponding one-to-one with data units will be dynamically generated.

[0040] Through the establishment of the above four-level hierarchical architecture, the traceability information of data assets is organized in an orderly manner in different functional partitions, providing clear path guidance for subsequent data unit mapping and targeted retrieval.

[0041] S102. Perform field-level segmentation on the data asset to obtain M data units, and aggregate the hash values ​​of the M data units to generate the asset hash value of the data asset.

[0042] The asset hash value is used to store data assets in the blockchain, and M is a positive integer.

[0043] In this embodiment, after obtaining the skeleton structure of the multi-branch traceability index tree, the computer device performs field-level segmentation on the data assets. The purpose of field-level segmentation is to decompose the data assets into basic data fragments (i.e., data units) that can be independently addressed and independently verified, so that subsequent traceability verification can be accurate to the field level rather than the overall asset level.

[0044] Specifically, computer equipment automatically selects a segmentation strategy based on the type of data asset (such as MIME type), and the resulting products are collectively referred to as "data units." A globally unique unit identifier (also called UnitID) is generated for each data unit. The UnitID can be generated by using a hash algorithm to calculate the AssetID, data path, and unit sequence number, and using the result as the UnitID to ensure the uniqueness of each data unit globally. Different segmentation strategies can be adopted depending on the type of data asset. (i) For structured data (such as JSON, XML, Avro formats): Computer devices recursively parse the data according to semantic boundaries until they reach indivisible atomic fields, that is, basic semantic units existing in the form of key-value pairs. For example, for the following JSON data: { "user": { "name": "Zhang San", "age": 30, "address": { "city": "XX", "district": "YY" } } } Computer equipment can divide the data into three data units: {"name":"Zhang San"}, {"age":30}, and {"address":{"city":"XX","district":"YY"}}, or further refine it into four data units: {"name":"Zhang San"}, {"age":30}, {"city":"XX"}, and {"district":"YY"}. The specific granularity of the division can be configured according to business needs. For atomic fields whose values ​​exceed a preset threshold (e.g., 1MB), they can be transferred to the unstructured data processing flow for secondary division.

[0045] (ii) For unstructured data (such as text, images, audio, and binary files): The computer device continuously divides the data into fixed-size fragments according to a preset block size (configurable, for example, 1MB by default). Adjacent fragments can be associated with the same logical parent data block through parent node pointers (such as parent_unit_id) to support complete reconstruction. For example, a 5MB image file can be divided into five 1MB data fragments.

[0046] (iii) For mixed-type data: Computer devices can recursively apply the above strategies. For example, first parse the JSON structure, and then perform a second fixed-size split on excessively long text values ​​or Base64-encoded binary fields.

[0047] After obtaining M data units, the computer independently calculates the hash value (called UnitHash) of each data unit using a hash algorithm (such as SHA-256). Then, the computer constructs a Merkle tree using the UnitHashes of the M data units as leaf nodes. The root hash of this Merkle tree is the asset hash value of the data asset (called AssetRootHash); that is, the asset hash value is obtained based on the UnitHashes of the M data units in the Merkle tree. In other words, the asset hash value depends on the content of the data asset; any change in any data unit within the data asset will change the asset hash value. For example, suppose the Merkle tree includes the UnitHashes of 4 data units (leaf nodes 1-4), specifically represented as: Leaf1 = Hash(data unit 1) = UnitHash1, Leaf2 = Hash(data unit 2) = UnitHash2, Leaf3 = Hash(data unit 3) = UnitHash3, Leaf4 = Hash(data unit 4) = UnitHash4. The computer device can then concatenate two adjacent leaf nodes and perform a hash operation to obtain the node value of the next level, represented as: Node1_2 = Hash(UnitHash1 + UnitHash2), Node3_4 = Hash(UnitHash3 + UnitHash4). Furthermore, Root = Hash(Node1_2 + Node3_4) is the asset hash value of the data asset.

[0048] In one embodiment, the AssetRootHash is recorded in the root node of the multi-branch traceability index tree of the data asset and uploaded to the blockchain for notarization, thereby achieving global verifiability of the data asset. That is, in addition to the globally unique code of the data asset, the root node of the multi-branch traceability index tree also includes the asset hash value of the data asset.

[0049] In one implementation, the root node (globally unique code) of the multi-branch traceability index tree of the data asset can serve as the query entry point for the data asset, while the asset hash value of the data asset can be used to verify the integrity of the data asset.

[0050] In this embodiment, field-level segmentation and independent hash calculation are not two isolated preprocessing operations, but rather closely coordinated: field-level segmentation decomposes data assets into independently verifiable basic units, providing a data foundation for subsequent field-level tampering location; while independent hash calculation assigns a unique "digital fingerprint" to each data unit, enabling each data unit to be independently verified. Without field-level segmentation, independent hash calculation can only be performed on the asset as a whole, failing to achieve precise field-level location; without independent hash calculation, the individual data units obtained after field-level segmentation will lack independent verification criteria. The combination of these two methods allows the granularity of traceability verification to be reduced from the asset as a whole to the field level, effectively solving the problem of overly coarse traceability granularity.

[0051] S103. Create K first leaf nodes corresponding to M data units under the fragmented storage verification branch.

[0052] Each first leaf node contains a storage address pointer for the corresponding data unit. The storage address pointers for the M data units are obtained by uploading the M data units to the decentralized storage network, where K is a positive integer.

[0053] In this embodiment, to ensure the security of off-chain storage of data assets, the computer device can independently encrypt each data unit using a symmetric encryption algorithm (such as the Chinese national standard SM4 algorithm) before uploading the data unit to the decentralized storage network. The encryption key can be managed by the data owner, and the key itself is not recorded on the blockchain to ensure the confidentiality of the off-chain stored data. The advantage of encrypting each data unit independently rather than encrypting the entire data is that when it is necessary to access or verify a single field, it is not necessary to decrypt the entire data asset, thereby improving the efficiency and security of on-demand access.

[0054] After encryption, the computer device uploads each encrypted data unit to a decentralized storage network (such as IPFS). Upon successful upload, the decentralized storage network returns a pointer to the storage address of that data unit (e.g., a Content Identifier (CID) in IPFS). This storage address pointer is the sole basis for subsequently retrieving data units from the decentralized storage network.

[0055] To further improve the durability and availability of data, computer devices may adopt erasure coding or multi-replica strategies. For example, every N data units are encoded into N+M shards, and these shards are released to storage nodes in different geographical regions using the distributed hash table of a decentralized storage network. Meanwhile, the computer device can record a storage proof task, requiring storage nodes to periodically submit proofs of retrievability to the blockchain to prove that the data remains available. Through the aforementioned redundant storage mechanism, even if some storage nodes go offline or data is corrupted, the computer device can still recover data from other redundant copies, thereby guaranteeing the reliability of off-chain storage.

[0056] After a data unit is successfully uploaded to the decentralized storage network and a storage address pointer is obtained, the computer device creates a first leaf node (also referred to as a hash benchmark leaf node or a shard storage verification leaf node) for each data unit under the hash benchmark three-level node of the shard storage verification branch. Each first leaf node comprises at least one of the following: Data Unit Identifier (UnitID): used to associate the corresponding data unit; Storage Address Pointer (StoragePointer): the address identifier returned after the data unit is uploaded to the decentralized storage network; Data Unit Hash Value (UnitHash): the hash value of the data unit calculated in step S102; Timestamp: the creation or last update time of the leaf node.

[0057] The first leaf node serves as the "on-chain hash benchmark" for the data unit and is used for all subsequent verification operations. By storing the storage address pointer and hash value of each data unit on the blockchain, even if data in the decentralized storage network is tampered with, the on-chain hash benchmark can still be used as a reliable basis for authenticity determination.

[0058] S104, creating P second leaf nodes corresponding to M data units under the asset granularity index branch, and establishing a two-way mapping relationship between K first leaf nodes and P second leaf nodes through two-way hash anchor pointers.

[0059] Wherein P is a positive integer. Under normal circumstances, one data unit corresponds to one first leaf node and one second leaf node, that is, K=M and P=M, forming a one-to-one mapping relationship. In a mixed data scenario, when one data unit (such as a large field in structured data) is further divided into multiple sub-units, one second leaf node corresponding to the data unit may be associated with multiple first leaf nodes, in which case K>M and P<M. In field merging or data association scenarios, multiple second leaf nodes may also point to the same first leaf node, in which case K<M and P=M. The embodiment of the present application can maintain two-way traceability between data units and storage shards under the aforementioned multiple mapping relationships through the two-way hash anchor pointer mechanism.

[0060] In this embodiment, after creating the first leaf node under the sharded storage verification branch, the computer device creates a second leaf node (also called a field node or asset granularity leaf node) for each data unit under the third-level data unit node of the asset granularity index branch. The second leaf node is the main entry node for traceability query, and its data structure includes, but is not limited to, the following: Data unit identifier (UnitID): the identifier of the associated data unit; Data unit hash value (UnitHash): the hash value of the data unit calculated in step S102; Storage address pointer (StoragePointer): the address identifier returned after the data unit is uploaded to the decentralized storage network; Timestamp (Timestamp): the creation or last update time of the leaf node; Version number (Version): supports backtracking query of the historical state of the data unit.

[0061] The first and second leaf nodes mentioned above are located under different second-level fixed branches of the index tree and are structurally separate. To achieve precise field-level mapping and double verification, the computer device establishes a bidirectional mapping relationship between them through bidirectional hash anchor pointers. The so-called "bidirectional mapping" means that the first and second leaf nodes can look up and locate each other: the first leaf node can be found from the second leaf node, and all second leaf nodes pointing to it can also be found from the first leaf node.

[0062] In one implementation, the mapping relationship is established in the following way: On one hand, the computer device writes a positive anchor pointer to each second leaf node (located under the asset granularity index branch). The positive anchor pointer of any second leaf node records the node identifier pointing to the corresponding first leaf node (located under the sharded storage verification branch). Specifically, for a second leaf node corresponding to data unit A, its positive anchor pointer points to the first leaf node corresponding to the same data unit A. Through the positive anchor pointer, the hash base node of that field under the sharded storage verification branch can be quickly located from the field node.

[0063] On the other hand, the computer device writes a reverse anchor pointer to each first leaf node. The reverse anchor pointer of any first leaf node records a list of identifiers for all second leaf nodes that point to that first leaf node. Normally, a first leaf node is pointed to by one second leaf node (i.e., a one-to-one mapping), but in special scenarios such as field merging and data association, multiple second leaf nodes may point to the same first leaf node (i.e., a many-to-one mapping). Therefore, the reverse anchor pointers are in list form to support various mapping relationships. Through the reverse anchor pointers, it is possible to trace back from the hash base node to all field nodes that depend on that hash base.

[0064] The aforementioned forward and reverse anchor pointers together constitute the bidirectional hash anchor pointer mechanism. The core value of this mechanism lies in the following: First, through forward anchor pointers, tracing queries can directly locate the corresponding storage verification node from the field node, thereby obtaining the storage address pointer and pulling data from the decentralized storage network for direct verification. This provides efficient addressing capabilities for the first verification path (field direct verification). Second, through reverse anchor pointers, computer devices can start from the storage verification node and reverse-verify whether its association with the field node is correct. This is crucial for detecting whether the mapping relationship has been tampered with. Third, the bidirectional mapping relationship creates a strong association between data units and storage shards, and any break in the association in either direction can be detected, thereby improving the integrity and reliability of the evidence chain.

[0065] Through the above steps S101 to S104, the data asset completes the construction of a complete traceability chain from "asset as a whole" to "field unit" and then to "on-chain evidence storage + off-chain storage + bidirectional mapping", providing a complete data foundation for subsequent traceability queries and dual verification.

[0066] S105. In response to the traceability query request of data assets, locate the multi-branch traceability index tree through the globally unique code of the data assets, and perform verification on the data assets and output the traceability results based on the K first leaf nodes and P second leaf nodes in the multi-branch traceability index tree.

[0067] In this embodiment of the application, when a user initiates a traceability query request for a data asset, the request includes at least the globally unique code (AssetID) of the data asset. After receiving the traceability query request, the computer device uses the AssetID as an index to locate the root node of the multi-branch traceability index tree of the current valid version of the data asset in the blockchain.

[0068] It should be noted that the root node pointer of the multi-branch traceability index tree is updated and stored on the blockchain after each index tree structure change (including initial construction and subsequent dynamic reconstruction). Therefore, the latest valid version of the data asset index tree can always be located through AssetID.

[0069] After locating the index tree, the computer device performs double verification based on the bidirectional hash anchor pointer relationship between the first leaf node and the second leaf node. In one possible implementation, the data asset tracing query request may also include the identifier of the field to be queried or the identifier of the data unit to be queried. Based on the identifier of the field to be queried, the computer device locates the corresponding second leaf node under the asset granularity index branch, and then finds the corresponding first leaf node through the forward anchor pointer of that second leaf node.

[0070] After locating the first leaf node and the second leaf node of the target, the computer device executes two independent verification paths: The first verification path (direct field verification): The computer device retrieves the encrypted data unit corresponding to the queried field from the decentralized storage network based on the storage address pointer recorded in the first or second leaf node of the target. It should be noted that since the storage address pointer is recorded in both the first and second leaf nodes, the computer device can choose to obtain the storage address pointer from either node, and both point to the same storage location. This redundancy design further enhances the reliability of the verification path. Before retrieving the data, the computer device can first verify whether the storage node corresponding to the data unit has submitted a valid proof of retrievability on the chain; if the verification fails, the data is retrieved from other redundant replicas. After retrieving the encrypted data unit, the computer device decrypts it using the corresponding decryption key, and then calculates the hash value of the decryption result using the same hash algorithm (such as SHA-256) as in step S102 to obtain the verification hash value. The computer device compares the verification hash value with the hash value of the data unit stored in the blockchain. If they match, the first verification path passes, indicating that the data content stored off-chain is consistent with the data stored on-chain and has not been tampered with. If they do not match, the first verification path fails, indicating that the data unit may have been tampered with.

[0071] The second verification path (operation replay): The computer device determines the latest operation node of the data unit corresponding to the target first leaf node or target second leaf node based on the identifier (latest_operation_node_id) of the operation node recorded in the target first leaf node or target second leaf node, and traces back the entire operation history from that operation node along the hash pointer of the "previous operation" of the operation node. Each operation node records the hash value change (previous_hash and new_hash) before and after an operation. Starting from the earliest operation, the computer device replays all hash changes in a forward direction, calculates the theoretical hash value of the current data, and compares it with the current hash value of the data unit stored in the blockchain. If they match, it proves that the operation history is complete and has not been tampered with, thus indirectly confirming the legitimacy of the current data state; if they do not match, it indicates that the operation history may be missing or tampered with. This path does not depend on the availability of off-chain storage shards. Even if the data in the decentralized storage network is damaged or unreachable, the second verification path can still independently verify the legitimacy of the data state through the operation history.

[0072] After completing the two verification paths, the computer device outputs the tracing results based on the first and second verification results. For example, the verification results of the two paths (whether they are consistent, operation log summary, location of differences, etc.) can be encapsulated into a structured "dual chain of evidence" data packet and returned to the user. This data packet can contain information such as the hash value of the on-chain evidence, transaction ID, and operation record summary, which can be used for auditing or authentication. Optionally, the two verification paths mentioned above can also be used independently, that is, either the first verification result or the second verification result can be used alone as the verification result of the data asset.

[0073] Compared to using either the first or second verification result as the sole verification result for the data asset, the aforementioned dual verification path design offers significant synergistic enhancement. Specifically, the first verification path (direct field verification) directly verifies the consistency between off-chain stored data and on-chain evidence hashes, enabling rapid detection of data tampering. The second verification path (operation replay) verifies the legitimacy of the data state by completely replaying the operation history, independent of the availability of off-chain storage shards. The two paths are independent in terms of data source and verification method, forming a naturally redundant verification relationship. When the off-chain stored data is intact, the first verification path can quickly complete the verification; when the off-chain stored data is unavailable or damaged due to node failure, network problems, or malicious attacks, the second verification path can still independently complete the legitimacy verification through the operation history. Even when the data itself is intact, the second verification path can detect unauthorized operation records by comparing the consistency between the operation history and the current state. Cross-verification of the two paths significantly improves the reliability of data asset traceability results. Compared with existing technologies that rely on only a single hash evidence path, the dual verification mechanism of this application has obvious advantages in terms of the non-repudiation and anti-attack capabilities of the evidence chain.

[0074] Furthermore, in step S105, to improve the retrieval efficiency of the traceability query, the computer device does not need to traverse the entire index tree after locating the multi-branch traceability index tree. Instead, since the multi-branch traceability index tree has been divided according to functional branches (asset granularity index branch, operation behavior index branch, ownership change index branch, etc.), the computer device can quickly match the corresponding branch based on the query type in the traceability query request. For example, if the query type is "query field modification history", the computer device directly locates the third-level node of the data unit under the asset granularity index branch, and then searches downwards along that branch without accessing the operation behavior index branch or the ownership change index branch. This targeted query method makes the retrieval depth controllable, usually stabilized within the range of 3 to 5 levels, with short paths and low input / output overhead for each retrieval, effectively ensuring the response efficiency of the traceability query.

[0075] Through steps S101 to S105 above, the data asset tracing method provided in this application embodiment achieves precise tracing and tamper location at the field level. This method constructs a multi-branch tracing index tree containing a sharded storage verification branch and an asset-granularity index branch, and establishes bidirectional hash anchor pointers between the leaf nodes of the two branches, refining the verification granularity of data assets from the overall asset to each individual data unit. Based on the bidirectional anchor relationship, the tracing query cross-verifies the legality of the data unit's state through dual verification paths, effectively solving the problems of single verification paths, ambiguous tamper location, and insufficient reliability of the evidence chain in the prior art.

[0076] This application embodiment also provides a data asset traceability method, which, based on the above steps S101 to S105, may further include a synchronization processing flow during data asset editing and updating. The following will combine... Figure 1 The subsequent steps in the document describe the process in detail.

[0077] In one possible implementation, such as Figure 1 As shown, after step S105, the method may further include step S106, which involves synchronously updating the relevant index tree nodes and bidirectional mapping relationships in response to the editing operation of the data assets.

[0078] Specifically, when a user edits a target data unit of a data asset, that target data unit can be any one of M data units. The computer device first calculates the hash value (UnitHash_new) of the edited target data unit.

[0079] Then, the computer device creates a new fourth-level leaf node as the operation node under the corresponding third-level node (e.g., the "Edit" node) in the operation behavior index branch. This operation node includes at least: the identifier of the target data unit (UnitID), the hash value of the target data unit before the operation (previous_hash, i.e., UnitHash_old), the hash value of the target data unit after the operation (new_hash, i.e., UnitHash_new), and operation metadata (such as operator identifier, operation time, transaction identifier, etc.).

[0080] Next, the computer device updates the hash value corresponding to the target data unit in the first leaf node (located under the sharded storage verification branch) associated with the target data unit, changing it from UnitHash_old to UnitHash_new, and uses the identifier of the newly created operation node as the latest operation node pointer (latest_operation_node_id) of the first leaf node.

[0081] Simultaneously, the computer device updates the hash value corresponding to the target data unit in the second leaf node (located under the asset granularity index branch) associated with the target data unit, changing it from UnitHash_old to UnitHash_new, and uses the identifier of the newly created operation node as the latest operation node pointer (latest_operation_node_id) of the second leaf node. In other words, the operation node is created under the operation behavior index branch of the multi-branch tracing index tree, and the first and second leaf nodes record the identifier of the latest operation node for the corresponding data unit (i.e., the operation node is not created in the first or second leaf node).

[0082] To ensure data consistency, the computer device submits the above operations—namely, the creation of new operation nodes, the update of the first leaf node, and the update of the second leaf node—to the blockchain for notarization through the same transaction (e.g., associated through the same transaction identifier tx_id). The atomicity of the blockchain guarantees that these operations either all succeed or all fail, avoiding data inconsistencies such as hash values ​​being updated but operation records not being created, or operation records being created but the two-way anchoring relationships not being updated synchronously.

[0083] The aforementioned synchronous update process ensures that after data assets are edited, the second leaf node under the asset granularity index branch, the first leaf node under the sharded storage verification branch, and the operation node under the operation behavior index branch maintain information consistency. Specifically, updating the second leaf node ensures that the hash value recorded in the field node is always up-to-date; updating the first leaf node ensures that the hash value recorded in the hash base node is consistent with the field node, thereby maintaining the data consistency of the bidirectional mapping relationship; and the creation of the operation node accumulates operation history data for the second verification path (operation replay), enabling future traceability queries to verify the legality of the data status by tracing back the operation history. Together, these three constitute a complete traceability chain maintenance mechanism in the scenario of dynamic data asset updates.

[0084] This application also provides a data asset traceability method, which, in addition to the above steps, may further include a dynamic adaptive reconstruction process for the index tree. This process will be described in detail below.

[0085] In the long-term management of data assets, as the scale of data assets grows, the frequency of operations changes, and the distribution of query popularity becomes uneven, some branches of the multi-branch tracing index tree may become abnormally bloated or excessively sparse, leading to a decrease in retrieval efficiency. To address this issue, this application introduces a dynamic adaptive reconstruction mechanism for the index tree.

[0086] Please see Figure 2 , Figure 2 This is a schematic diagram illustrating a dynamic adaptive reconstruction process for an index tree, provided in an embodiment of this application. The reconstruction process may include the following steps S201 to S206.

[0087] S201. Collect dynamic indicators of each third-level management dimension node in the multi-branch traceability index tree.

[0088] In this embodiment, the computer device maintains and periodically updates a set of dynamic indicators for each third-level management dimension node in the multi-branch tracing index tree. These dynamic indicators may include: (1) Total number of leaf nodes (leaf_count): The total number of fourth-level leaf nodes attached to the current third-level node. This indicator reflects the scale of data managed by the current node.

[0089] (2) Number of newly added leaf nodes per unit time (operation_freq): The number of newly added fourth-level leaf nodes under the current third-level node within a preset time window (e.g., 1 hour, the duration of which is configurable). This indicator reflects the operational activity of the current node. It should be noted that the baseline value of operation frequency may vary greatly under different business scenarios. Therefore, the specific value corresponding to this indicator can be configured according to the actual business scenario. This application embodiment does not limit this.

[0090] (3) Number of source query hits per unit time (query_hotness): The number of times a source query starting from or targeting the current third-level node is hit within a preset time window. This indicator reflects the query popularity of the current node.

[0091] (4) Mapping complexity: The total number of different first leaf nodes associated with all valid fourth-level leaf nodes (i.e., second leaf nodes) under the current third-level node. This metric reflects the mapping complexity between the data units managed by the current node and the storage verification nodes. When the mapping complexity of a node is too high, it means that a large number of storage baseline nodes that need to be independently verified are attached to the node, resulting in a decrease in retrieval and verification efficiency.

[0092] The four dynamic metrics described above depict the operational status of each node in the index tree from different dimensions: the total number of leaf nodes and mapping complexity reflect the "static load" of the node, i.e., the amount of data currently accumulated and the complexity of the mapping relationship; the operation frequency reflects the "dynamic activity" of the node, i.e., the rate of change of data assets; and the query heat reflects the "access pressure" of the node, i.e., the frequency of being queried. The combination of these three metrics allows for a more comprehensive assessment of whether each node requires structural optimization. Among them, mapping complexity is one of the key metrics driving the reconstruction decision, directly related to the retrieval efficiency of the bidirectional mapping relationship, reflecting the synergistic relationship between the dynamic reconstruction mechanism and the bidirectional mapping mechanism in this embodiment.

[0093] S202. Determine whether the dynamic indicators of the three-level management dimension nodes meet the preset trigger conditions within at least two consecutive statistical periods.

[0094] In this embodiment, to avoid frequent refactoring (i.e., system turbulence) caused by instantaneous fluctuations, the computer device can set a cooling mechanism when determining whether to trigger a refactoring. Specifically, a refactoring proposal is only triggered when the dynamic indicators of a certain third-level management dimension node meet the preset triggering conditions in multiple consecutive statistical periods (e.g., three consecutive statistical periods T, T+1, T+2). The triggering conditions can be pre-configured in a smart contract.

[0095] Preset trigger conditions may include at least one of the following: (i) Upgrade Conditions: The total number of leaf nodes (leaf_count) under the third-level management dimension node exceeds the first threshold, and the number of newly added leaf nodes (operation_freq) per unit time exceeds the second threshold. This condition indicates that the third-level node is overloaded and needs to be upgraded to a new derived second-level branch node. The specific values ​​of the first and second thresholds can be configured according to the actual business scenario. For example, the first threshold can be set to 1000 and the second threshold to 500 times / hour, but these values ​​are only examples and do not constitute a limitation on this application.

[0096] (ii) Splitting condition: The total number of different first leaf nodes associated with all second leaf nodes under a third-level management dimension node (i.e., mapping_complexity) exceeds the third threshold. This condition indicates that a certain third-level node has become bloated due to managing too many independent data units and their storage base nodes, resulting in decreased retrieval and verification efficiency. It is necessary to split the node into multiple new third-level nodes and allocate corresponding fourth-level leaf nodes to them.

[0097] (iii) Degradation / Merger Conditions: The total number of leaf nodes under any derived second-level branch node in the multi-branch traceability index tree is less than the fourth threshold, and the number of times the derived second-level branch node is hit by traceability queries per unit time (query_hotness) is zero. This condition indicates that the branch has extremely low activity and can be downgraded and merged into the attribute field of the parent node to save on-chain storage space.

[0098] S203. When the dynamic indicators of any third-level management dimension node meet the preset trigger conditions, the third-level management dimension node initiates a reconstruction proposal.

[0099] In this embodiment, a third-level management node (referred to as a "proposal node") that meets the triggering conditions broadcasts a reconstruction proposal to the blockchain network. The reconstruction proposal may include the following: the path of the proposal node, the triggering condition indicators and their specific values, the reconstruction type (upgrade / downgrade / merge / split), a detailed plan for the change of the old and new tree structures, and a list of affected bidirectional mapping relationships.

[0100] S204. Verify the reconstruction proposal through a consensus mechanism.

[0101] In this embodiment, after receiving a reconstruction proposal, all consensus nodes in the blockchain network verify the authenticity of the metrics and the legality of the proposal. For example, they verify whether the dynamic metrics declared by the proposing node are consistent with the actually collected data, and whether the reconstruction scheme will lead to the loss of bidirectional mapping relationships. When more than a preset proportion (e.g., two-thirds) of the nodes agree, the proposal enters the execution phase. This preset proportion can be configured according to the specific consensus mechanism design, and this embodiment does not limit it.

[0102] S205, Reconstruct the index tree structure atomically through smart contracts.

[0103] In this embodiment of the application, the reconstruction process can adopt a "freeze-reconstruction-activation" model to ensure the consistency of the on-chain state.

[0104] Freeze Phase: After the reconstruction proposal is approved, the index tree of the data asset enters the "maintenance" state. At this time, all new write requests can be rejected (e.g., by returning an error code or asking the client to retry later), while read requests can still access the old tree data.

[0105] Restructuring Phase: Smart contracts atomically execute node creation, deletion, pointer updates, and bidirectional mapping migration. This process is completed within a single transaction. Since blockchain block times are typically in the second range, the perceptible interruption time for users during the entire restructuring process is usually short (on the order of several seconds to tens of seconds), which can meet actual business needs.

[0106] Activation Phase: After successful reconstruction, the computer device will point the global index tree root pointer to the new tree and remove it from maintenance mode. For write requests rejected during reconstruction, the client can retry according to its business strategy.

[0107] It is important to emphasize that the consistency of the bidirectional mapping relationship is maintained synchronously during the reconstruction process. Specifically, when a node split occurs, the fourth-level leaf nodes under the original node and their bidirectional anchor pointers are assigned to multiple new third-level nodes; when a node upgrade occurs, the original third-level node and its subordinate leaf nodes are migrated to new derived second-level branch nodes. Regardless of the reconstruction type, the bidirectional mapping relationship between the second leaf node and the corresponding first leaf node of each data unit remains unchanged after reconstruction—the forward anchor pointer still points to the same target node, and the node identifiers in the reverse anchor pointer list are also updated synchronously. This design ensures that dynamic reconstruction does not disrupt the bidirectional mapping relationship established in step S204, enabling the reconstruction mechanism and the bidirectional mapping mechanism to work together rather than conflict with each other.

[0108] S206. After the reconstruction is completed, update the root hash and generate a historical snapshot.

[0109] In this embodiment, after reconstruction, the computer device recalculates the root hash of the new index tree and uploads it to the blockchain. The old version of the index tree structure is packaged into a historical snapshot, compressed and stored in the historical state of the blockchain, to support backtracking queries on the data state at a specific point in the past.

[0110] Through the aforementioned dynamic reconstruction mechanism, the index tree structure can adaptively adjust according to the actual operating status of the data assets, avoiding the long-term performance degradation problem caused by a fixed-level index tree structure. More importantly, dynamic reconstruction and the bidirectional mapping mechanism form a synergistic and enhanced closed loop: on the one hand, the bidirectional mapping mechanism provides a data association foundation for field-level traceability, while the dynamic reconstruction mechanism ensures the efficiency of retrieval based on these associations by optimizing the tree structure; on the other hand, one of the triggering conditions for reconstruction—mapping complexity—directly originates from the data generated during the operation of the bidirectional mapping mechanism (i.e., the total number of different first leaf nodes associated with the second leaf node), enabling the reconstruction decision to accurately respond to the actual load of the bidirectional mapping mechanism. When the mapping complexity is too high, a split reconstruction is triggered, distributing the centralized mapping relationships to multiple nodes, thereby reducing the number of mappings that need to be traversed in a single retrieval; after reconstruction, the optimization of the tree structure further improves the retrieval efficiency based on bidirectional mapping. The two form a mutually reinforcing relationship of "verification-driven reconstruction and reconstruction-optimized verification," jointly ensuring the long-term stability and efficiency of traceability.

[0111] In the source retrieval process described in step S105 above, the efficiency of source retrieval is further guaranteed by combining the aforementioned dynamic reconstruction mechanism. Specifically, when a source retrieval query request arrives, the computer device first obtains the globally unique code (AssetID) of the data asset, and uses this code to locate the current valid version root node of the asset index tree in the blockchain. After locating the root node, the computer device does not traverse layer by layer from the root node, but instead matches the dynamic index directory according to the query type to quickly locate the valid branch.

[0112] The dynamic index directory is a "function-branch path" mapping table stored on the blockchain. This directory is automatically updated after each index tree reconstruction. For example, the dynamic index directory can record the following mapping relationship: {"Query field modification history": ["Asset granularity index branch", "Data unit"], "Query ownership change": ["Ownership change index branch"]}. When a user enters a query intent (e.g., "Query modification history of field A"), the computer device matches the dynamic index directory and directly locates the corresponding second- or third-level branch without traversing the entire tree.

[0113] After locating a valid branch, the computer device performs a downward query according to the currently valid tree structure. If the target branch has been promoted to a new second-level branch (e.g., the original third-level node to which the target branch belonged has been promoted to a derived second-level branch node), the computer device automatically continues the query along the new branch path; if the target branch has been merged, the computer device extracts serialized historical data from specific attribute fields of its parent node. The entire process is directional and non-recursive, and the retrieval depth is typically stabilized within the range of 3 to 5 levels. Each retrieval path is short, and the input / output overhead is small, thus effectively ensuring the response efficiency of the source tracing query.

[0114] Upon reaching the target leaf node, the computer device executes the aforementioned dual verification path (direct field verification and operation replay) and encapsulates the verification results of the two paths into a structured "dual evidence chain" data packet, which is then returned to the user. This data packet contains the hash values ​​and transaction identifiers of all on-chain evidence, and can be used for auditing or authentication.

[0115] The synergistic relationship between the aforementioned dynamic reconstruction and retrieval processes is reflected in the following ways: the dynamic reconstruction mechanism breaks down bloated nodes or promotes high-frequency nodes through operations such as splitting and upgrading, keeping the number of leaf nodes in each node within a reasonable range, thus ensuring controllable retrieval depth; while the use of dynamic index directories during the retrieval process further avoids the performance overhead caused by traversal retrieval. The combination of these two aspects ensures that even with the continuous growth of data asset scale, the response time for source tracing queries can remain at a relatively good level, solving the problem of retrieval efficiency continuously declining with the growth of data scale in existing technologies.

[0116] The methods of the embodiments of this application have been described in detail above. In order to facilitate better implementation of the above solutions of the embodiments of this application, the apparatus of the embodiments of this application is provided below.

[0117] Please see Figure 3 , Figure 3 This is a schematic diagram of a data asset traceability device provided in an embodiment of this application.

[0118] In one embodiment, Figure 3 The data asset traceability device shown can be installed in a gateway. Figure 3 The data asset traceability device shown can be used to perform the above. Figure 1 or Figure 2 Some or all of the functionality described in the method embodiments. Please refer to... Figure 3 The data asset traceability device includes: The acquisition unit 301 is used to acquire the data assets to be traced and to build a multi-branch traceability index tree for the data assets. The root node of the multi-branch traceability index tree includes the globally unique code of the data assets. The multi-branch traceability index tree includes a sharded storage verification branch and an asset granularity index branch. Processing unit 302 is used to perform field-level segmentation of data assets to obtain M data units, aggregate the hash values ​​of the M data units to generate the asset hash value of the data assets, and record the asset hash value in the root node of the multi-branch traceability index tree. The asset hash value is used to store the data assets in the blockchain, where M is a positive integer. And used to create K first leaf nodes corresponding to M data units under the sharded storage verification branch. Each first leaf node contains the storage address pointer of the corresponding data unit. The storage address pointers of the M data units are obtained by uploading the M data units to the decentralized storage network, and K is a positive integer. And used to create P second leaf nodes corresponding to M data units under the asset granularity index branch, and to establish a bidirectional mapping relationship between K first leaf nodes and P second leaf nodes through bidirectional hash anchor pointers. Each second leaf node contains the storage address pointer of the corresponding data unit, where P is a positive integer. And for responding to data asset traceability query requests, the multi-branch traceability index tree is located through the globally unique code of the data asset. The data asset traceability query request includes the field to be queried. Based on the storage address pointer recorded in the target first leaf node or target second leaf node in the multi-branch traceability index tree, the encrypted unit corresponding to the field to be queried is pulled from the decentralized storage network. The target first leaf node is the first leaf node corresponding to the field to be queried. The target first leaf node records the identifier of the target operation node. The target operation node is the latest operation node of the data unit corresponding to the target first leaf node. The target second leaf node is the second leaf node corresponding to the field to be queried. The verification hash value is compared with the hash value corresponding to the field to be queried in the blockchain to obtain the first verification result of the data asset. The verification hash value is obtained by hashing the decryption result of the encrypted unit. By tracing back the operation records of the data asset through the operation pointer in the target operation node, and inferring the theoretical hash value of the data asset based on the operation records; The theoretical hash value is compared with the hash value corresponding to the field to be queried in the blockchain to obtain the second verification result of the data asset. Based on the first and second verification results, the tracing results are output.

[0119] In one implementation, the multi-branch traceability index tree includes a first-level root node, second-level fixed branch nodes, third-level management dimension nodes, and fourth-level time-series leaf nodes; the sharded storage verification branch and the asset granularity index branch are contained in the second-level fixed branch nodes, and the second-level fixed branch nodes also include operation behavior index branches and ownership change index branches.

[0120] In one embodiment, the processing unit 302 is further configured to: In response to the edit operation of the target data unit, calculate the hash value of the edited target data unit, where the target data unit is any one of the M data units; Create an operation node corresponding to the edit operation under the operation behavior index branch. The operation node includes at least one of the following: the identifier of the target data unit, the hash value of the target data unit before the operation, the hash value of the target data unit after the operation, and the operation metadata. Update the hash value corresponding to the target data unit in the first leaf node associated with the target data unit, and set the operation node corresponding to the edit operation as the latest operation node pointed to by the first leaf node; and... Update the hash value corresponding to the target data unit in the second leaf node associated with the target data unit, and use the operation node corresponding to the edit operation as the latest operation node pointed to by the second leaf node; The update of the operation node corresponding to the editing operation, the update of the first leaf node associated with the target data unit, and the update of the second leaf node associated with the target data unit are stored on the blockchain through the same transaction.

[0121] In one embodiment, the processing unit 302 is further configured to: Collect dynamic metrics for each third-level management dimension node in the multi-branch traceability index tree. The dynamic metrics include: total number of leaf nodes, number of newly added leaf nodes per unit time, number of traceability query hits per unit time, and total number of different first leaf nodes associated with all second leaf nodes under the third-level management dimension node. When the dynamic indicators of any third-level management dimension node meet the preset triggering conditions within at least two consecutive statistical periods, the third-level management dimension node initiates a reconstruction proposal, which is used to restructure the multi-branch traceability index tree.

[0122] In one implementation, the preset triggering condition includes at least one of the following: The total number of leaf nodes under the three-level management dimension exceeds the first threshold, and the number of newly added leaf nodes per unit time exceeds the second threshold. The total number of different first leaf nodes associated with all second leaf nodes under the third-level management dimension node exceeds the third threshold. The total number of leaf nodes under any derived second-level branch node in the multi-branch traceability index tree is less than the fourth threshold, and the number of times that derived second-level branch node is hit by traceability queries within a unit of time is zero.

[0123] In one implementation, the processing unit 302 is configured to establish a bidirectional mapping relationship between K first leaf nodes and P second leaf nodes through bidirectional hash anchor pointers, specifically configured to: For K first leaf nodes, write reverse anchor pointers. The reverse anchor pointer of any first leaf node records a list of all the identifiers of the second leaf nodes that point to that first leaf node. For P second leaf nodes, write forward anchor pointers. The forward anchor pointer of any second leaf node records a list of identifiers of all first leaf nodes that point to that second leaf node.

[0124] According to one embodiment of this application, Figure 1 or Figure 2 The data asset traceability method shown may involve some steps that can be performed by... Figure 3 The data asset traceability device shown is executed by each unit within it. For example, Figure 1 Step S101 shown can be performed by Figure 3 The acquisition unit 301 shown is executed, and steps S102-S105 can be performed by... Figure 3 The processing unit 302 shown executes. Figure 2 Step S201 shown can be performed by Figure 3 The acquisition unit 301 shown is executed, and steps S202-S206 can be performed by... Figure 3 The processing unit 302 shown executes. Figure 3 The data asset traceability device shown can be composed of individual or combined units into one or more other units, or some of the units can be further divided into multiple functionally smaller units. This achieves the same operation without affecting the technical effects of the embodiments of this application. The above units are based on logical function division. In practical applications, the function of one unit can be implemented by multiple units, or the function of multiple units can be implemented by one unit. In other embodiments of this application, the data asset traceability device may also include other units. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented collaboratively by multiple units.

[0125] According to another embodiment of this application, a general-purpose computing device, such as a computer device including processing elements and storage elements such as a central processing unit (CPU), random access memory (RAM), and read-only memory (ROM), can perform operations such as... Figure 1 or Figure 2 The computer program (including program code) involved in each step of the corresponding method shown, to construct such... Figure 3 The data asset tracing apparatus shown herein, and the data asset tracing method for implementing the embodiments of this application, are described. A computer program may be recorded on, for example, a computer-readable recording medium, loaded onto the aforementioned computing device via the computer-readable recording medium, and run therein.

[0126] Based on the same inventive concept, the principle and beneficial effects of the data asset traceability device provided in the embodiments of this application are similar to the principle and beneficial effects of the data asset traceability method in the embodiments of this application. For details, please refer to the principle and beneficial effects of the method implementation. For the sake of brevity, these will not be repeated here.

[0127] Please see Figure 4 , Figure 4 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 4 As shown, the computer device includes at least a processor 401, a communication interface 402, and a memory 403. The processor 401, communication interface 402, and memory 403 can be connected via a bus or other means. The processor 401 (or Central Processing Unit, CPU) is the computing and control core of the computer device. It can parse various instructions within the computer device and process various data. For example, the CPU can parse power-on / off commands issued by objects to the computer device and control the computer device to perform power-on / off operations; it can also transmit various interactive data between internal structures of the computer device, and so on. The communication interface 402 may optionally include standard wired interfaces or wireless interfaces (such as Wi-Fi, mobile communication interfaces, etc.), and can be used to send and receive data under the control of the processor 401; the communication interface 402 can also be used for data transmission and interaction within the computer device. The memory 403 is the storage device in the computer device, used to store programs and data. It can be understood that the memory 403 here can include the computer device's built-in memory, or it can include extended memory supported by the computer device. The memory 403 provides storage space for storing the operating system of the computer device, which may include, but is not limited to, Android, iOS, Windows Phone, etc. This application does not limit this.

[0128] This application embodiment also provides a computer-readable storage medium (Memory), which is a memory device in a computer device used to store programs and data. It is understood that the computer-readable storage medium here can include both the built-in storage medium in the computer device and extended storage media supported by the computer device. The computer-readable storage medium provides storage space that stores the processing system of the computer device. Furthermore, the storage space also stores computer programs suitable for loading and execution by the processor 401. It should be noted that the computer-readable storage medium here can be high-speed RAM or non-volatile memory, such as at least one disk storage device; optionally, it can also be at least one computer-readable storage medium located remotely from the aforementioned processor.

[0129] In one embodiment, processor 401 performs the following operations by running a computer program stored in memory 403: Obtain the data assets to be traced and construct a multi-branch traceability index tree for the data assets. The root node of the multi-branch traceability index tree includes the globally unique code of the data assets. The multi-branch traceability index tree includes a sharded storage verification branch and an asset granularity index branch. The data asset is segmented at the field level to obtain M data units. The hash values ​​of the M data units are aggregated to generate the asset hash value of the data asset. The asset hash value is recorded in the root node of the multi-branch traceability index tree. The asset hash value is used to store the data asset in the blockchain. M is a positive integer. Under the sharded storage verification branch, create K first leaf nodes corresponding to M data units. Each first leaf node contains the storage address pointer of the corresponding data unit. The storage address pointers of the M data units are obtained by uploading the M data units to the decentralized storage network, and K is a positive integer. Under the asset granularity index branch, create P second leaf nodes corresponding to M data units, and establish a bidirectional mapping relationship between K first leaf nodes and P second leaf nodes through bidirectional hash anchor pointers. Each second leaf node contains the storage address pointer of the corresponding data unit, where P is a positive integer. In response to a data asset traceability query request, the multi-branch traceability index tree is located through the globally unique code of the data asset. The data asset traceability query request includes the field to be queried. Based on the storage address pointer recorded in the target first leaf node or target second leaf node in the multi-branch traceability index tree, the encrypted unit corresponding to the field to be queried is pulled from the decentralized storage network. The target first leaf node is the first leaf node corresponding to the field to be queried. The target first leaf node records the identifier of the target operation node. The target operation node is the latest operation node of the data unit corresponding to the target first leaf node. The target second leaf node is the second leaf node corresponding to the field to be queried. The verification hash value is compared with the hash value corresponding to the field to be queried in the blockchain to obtain the first verification result of the data asset. The verification hash value is obtained by hashing the decryption result of the encrypted unit. By tracing back the operation records of the data asset through the operation pointer in the target operation node, and inferring the theoretical hash value of the data asset based on the operation records; The theoretical hash value is compared with the hash value corresponding to the field to be queried in the blockchain to obtain the second verification result of the data asset. Based on the first and second verification results, the tracing results are output.

[0130] As an optional embodiment, the multi-branch traceability index tree includes a first-level root node, a second-level fixed branch node, a third-level management dimension node, and a fourth-level time-series leaf node; the sharded storage verification branch and the asset granularity index branch are contained in the second-level fixed branch node, and the second-level fixed branch node also includes the operation behavior index branch and the ownership change index branch.

[0131] As an optional embodiment, the processor 401, by running a computer program in the memory 403, also performs the following operations: In response to the edit operation of the target data unit, calculate the hash value of the edited target data unit, where the target data unit is any one of the M data units; Create an operation node corresponding to the edit operation under the operation behavior index branch. The operation node includes at least one of the following: the identifier of the target data unit, the hash value of the target data unit before the operation, the hash value of the target data unit after the operation, and the operation metadata. Update the hash value corresponding to the target data unit in the first leaf node associated with the target data unit, and set the operation node corresponding to the edit operation as the latest operation node pointed to by the first leaf node; and... Update the hash value corresponding to the target data unit in the second leaf node associated with the target data unit, and use the operation node corresponding to the edit operation as the latest operation node pointed to by the second leaf node; The update of the operation node corresponding to the editing operation, the update of the first leaf node associated with the target data unit, and the update of the second leaf node associated with the target data unit are stored on the blockchain through the same transaction.

[0132] As an optional embodiment, the processor 401, by running a computer program in the memory 403, also performs the following operations: Collect dynamic metrics for each third-level management dimension node in the multi-branch traceability index tree. The dynamic metrics include: total number of leaf nodes, number of newly added leaf nodes per unit time, number of traceability query hits per unit time, and total number of different first leaf nodes associated with all second leaf nodes under the third-level management dimension node. When the dynamic indicators of any third-level management dimension node meet the preset triggering conditions within at least two consecutive statistical periods, the third-level management dimension node initiates a reconstruction proposal, which is used to restructure the multi-branch traceability index tree.

[0133] As an optional embodiment, the preset triggering condition includes at least one of the following: The total number of leaf nodes under the three-level management dimension exceeds the first threshold, and the number of newly added leaf nodes per unit time exceeds the second threshold. The total number of different first leaf nodes associated with all second leaf nodes under the third-level management dimension node exceeds the third threshold. The total number of leaf nodes under any derived second-level branch node in the multi-branch traceability index tree is less than the fourth threshold, and the number of times that derived second-level branch node is hit by traceability queries within a unit of time is zero.

[0134] As an optional embodiment, the processor 401 establishes a bidirectional mapping relationship between K first leaf nodes and P second leaf nodes through bidirectional hash anchor pointers. For K first leaf nodes, write reverse anchor pointers. The reverse anchor pointer of any first leaf node records a list of all the identifiers of the second leaf nodes that point to that first leaf node. For P second leaf nodes, write forward anchor pointers. The forward anchor pointer of any second leaf node records a list of identifiers of all first leaf nodes that point to that second leaf node.

[0135] Based on the same inventive concept, the principle and beneficial effects of the computer device provided in the embodiments of this application in solving the problem are similar to the principle and beneficial effects of the data asset traceability method in the embodiments of this application in solving the problem. Please refer to the principle and beneficial effects of the implementation of the method. For the sake of brevity, they will not be repeated here.

[0136] This application also provides a computer-readable storage medium storing a computer program adapted to be loaded by a processor and execute the data asset tracing method of the above method embodiments.

[0137] This application also provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the aforementioned data asset tracing method.

[0138] The steps in the method of this application embodiment can be adjusted, combined, or deleted according to actual needs.

[0139] The modules in the device of this application embodiment can be merged, divided, and deleted according to actual needs.

[0140] In the embodiments of this application, the term "module" or "unit" refers to a computer program or part of a computer program with a predetermined function, which works together with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0141] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, etc.

[0142] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Those skilled in the art will understand that all or part of the processes for implementing the above embodiments and equivalent variations made in accordance with the claims of this application are still within the scope of this application.

Claims

1. A method for tracing the origin of data assets, characterized in that, include: Obtain the data assets to be traced and construct a multi-branch traceability index tree for the data assets. The root node of the multi-branch traceability index tree includes the globally unique code of the data assets. The multi-branch traceability index tree includes a sharded storage verification branch and an asset granularity index branch. The data asset is segmented at the field level to obtain M data units. The asset hash value of the data asset is generated by aggregating the hash values ​​of the M data units and the asset hash value is recorded in the root node of the multi-branch traceability index tree. The asset hash value is used to store the data asset in the blockchain. M is a positive integer. Under the sharded storage verification branch, create K first leaf nodes corresponding to the M data units. Each first leaf node contains a storage address pointer for the corresponding data unit. The storage address pointers for the M data units are obtained by uploading the M data units to the decentralized storage network, where K is a positive integer. Under the asset granularity index branch, create P second leaf nodes corresponding to the M data units, and establish a bidirectional mapping relationship between the K first leaf nodes and the P second leaf nodes through bidirectional hash anchor pointers. Each second leaf node contains a storage address pointer of the corresponding data unit, where P is a positive integer. In response to the traceability query request of the data asset, the multi-branch traceability index tree is located through the globally unique code of the data asset, and the traceability query request of the data asset includes the field to be queried; Based on the storage address pointer recorded in the target first leaf node or target second leaf node in the multi-branch tracing index tree, the encrypted unit corresponding to the field to be queried is pulled from the decentralized storage network. The target first leaf node is the first leaf node corresponding to the field to be queried. The target first leaf node records the identifier of the target operation node. The target operation node is the latest operation node of the data unit corresponding to the target first leaf node. The target second leaf node is the second leaf node corresponding to the field to be queried. The verification hash value is compared with the hash value corresponding to the field to be queried in the blockchain to obtain the first verification result of the data asset. The verification hash value is obtained by hashing the decryption result of the encryption unit. The operation records of the data asset are traced back through the operation pointer in the target operation node, and the theoretical hash value of the data asset is inferred based on the operation records; The theoretical hash value is compared with the hash value corresponding to the field to be queried in the blockchain to obtain the second verification result of the data asset. Based on the first verification result and the second verification result, the source tracing result is output.

2. The method as described in claim 1, characterized in that, The multi-branch traceability index tree includes a first-level root node, a second-level fixed branch node, a third-level management dimension node, and a fourth-level time-series leaf node; the sharded storage verification branch and the asset granularity index branch are contained in the second-level fixed branch node, and the second-level fixed branch node also includes an operation behavior index branch and an ownership change index branch.

3. The method as described in claim 2, characterized in that, The method further includes: In response to an edit operation on a target data unit, calculate the hash value of the edited target data unit, where the target data unit is any one of the M data units; Under the operation behavior index branch, create an operation node corresponding to the edit operation. The operation node includes at least one of the following: the identifier of the target data unit, the hash value of the target data unit before the operation, the hash value of the target data unit after the operation, and operation metadata. Update the hash value corresponding to the target data unit in the first leaf node associated with the target data unit, and use the operation node corresponding to the edit operation as the latest operation node pointed to by the first leaf node; and Update the hash value corresponding to the target data unit in the second leaf node associated with the target data unit, and take the operation node corresponding to the edit operation as the latest operation node pointed to by the second leaf node; The update of the operation node corresponding to the editing operation, the update of the first leaf node associated with the target data unit, and the update of the second leaf node associated with the target data unit are stored on the blockchain through the same transaction.

4. The method as described in claim 2, characterized in that, The method further includes: The dynamic indicators of each third-level management dimension node in the multi-branch traceability index tree are collected. The dynamic indicators include: the total number of leaf nodes, the number of newly added leaf nodes per unit time, the number of traceability query hits per unit time, and the total number of different first leaf nodes associated with all second leaf nodes under the third-level management dimension node. When the dynamic indicators of any third-level management dimension node meet the preset triggering conditions within at least two consecutive statistical periods, the third-level management dimension node initiates a reconstruction proposal, which is used to restructure the multi-branch traceability index tree.

5. The method as described in claim 4, characterized in that, The preset triggering condition includes at least one of the following: The total number of leaf nodes under the three-level management dimension nodes exceeds the first threshold, and the number of newly added leaf nodes per unit time exceeds the second threshold. The total number of different first leaf nodes associated with all second leaf nodes under the three-level management dimension node exceeds the third threshold. The total number of leaf nodes under any derived second-level branch node in the multi-branch traceability index tree is less than the fourth threshold, and the number of times the derived second-level branch node is hit by traceability queries within a unit of time is zero.

6. The method as described in claim 1, characterized in that, The step of establishing a bidirectional mapping relationship between the K first leaf nodes and the P second leaf nodes through bidirectional hash anchor pointers includes: For the K first leaf nodes, write reverse anchor pointers. The reverse anchor pointer of any first leaf node records a list of identifiers of all second leaf nodes that point to that first leaf node. For each of the P second leaf nodes, write a positive anchor pointer. The positive anchor pointer of any second leaf node records a list of identifiers of all first leaf nodes that point to that second leaf node.

7. A data asset traceability device, characterized in that, The data asset traceability device includes: The acquisition unit is used to acquire the data assets to be traced and construct a multi-branch traceability index tree for the data assets. The root node of the multi-branch traceability index tree includes the globally unique code of the data assets. The multi-branch traceability index tree includes a sharded storage verification branch and an asset granularity index branch. The processing unit is used to perform field-level segmentation on the data asset to obtain M data units, aggregate the hash values ​​of the M data units to generate the asset hash value of the data asset, and record the asset hash value at the root node of the multi-branch traceability index tree. The asset hash value is used to store the data asset in the blockchain, where M is a positive integer. And for creating K first leaf nodes corresponding to the M data units under the sharded storage verification branch, each first leaf node contains a storage address pointer of the corresponding data unit, the storage address pointers of the M data units are obtained by uploading the M data units to the decentralized storage network, and K is a positive integer; And for creating P second leaf nodes corresponding to the M data units under the asset granularity index branch, and establishing a bidirectional mapping relationship between the K first leaf nodes and the P second leaf nodes through bidirectional hash anchor pointers, each second leaf node contains a storage address pointer of the corresponding data unit, where P is a positive integer; And for responding to a traceability query request for the data asset, the multi-branch traceability index tree is located by the globally unique code of the data asset, wherein the traceability query request for the data asset includes the field to be queried; Based on the storage address pointer recorded in the target first leaf node or target second leaf node in the multi-branch tracing index tree, the encrypted unit corresponding to the field to be queried is pulled from the decentralized storage network. The target first leaf node is the first leaf node corresponding to the field to be queried. The target first leaf node records the identifier of the target operation node. The target operation node is the latest operation node of the data unit corresponding to the target first leaf node. The target second leaf node is the second leaf node corresponding to the field to be queried. The verification hash value is compared with the hash value corresponding to the field to be queried in the blockchain to obtain the first verification result of the data asset. The verification hash value is obtained by hashing the decryption result of the encryption unit. The operation records of the data asset are traced back through the operation pointer in the target operation node, and the theoretical hash value of the data asset is inferred based on the operation records; The theoretical hash value is compared with the hash value corresponding to the field to be queried in the blockchain to obtain the second verification result of the data asset. Based on the first verification result and the second verification result, the source tracing result is output.

8. A computer device, characterized in that, include: A memory, wherein a computer program is stored; A processor for loading the computer program to implement the data asset tracing method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded by a processor and executed as described in any one of claims 1-6.

Images