Distributed traceability method and system for data operation in trusted data space
By combining blockchain storage and chained hash calculation with a cross-node consensus mechanism, the problems of easy tampering and poor consistency of logs in the trusted data space are solved, and trusted traceability and efficient auditing of data operations are realized.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-11
- Publication Date
- 2026-03-10
AI Technical Summary
In a trusted data space, data operation logs are easily tampered with, cross-node consistency is poor, auditing efficiency is low, there is a lack of a unified consensus verification mechanism, and it is difficult to achieve full-chain traceability.
By introducing the decentralized storage, chained hash association, and cross-node consensus mechanism of blockchain, the logs are ensured to be immutable through encrypted logs and hash calculations, and a consistent traceability of the entire chain is formed on the blockchain.
It achieves tamper-proof evidence storage of data operation logs, ensures the credibility and integrity of traceability results, improves audit efficiency, and protects the privacy of sensitive information.
Smart Images

Figure CN121644138A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of trusted data spaces, and more particularly to a distributed tracing method and system for data operations in trusted data spaces. Background Technology
[0002] In a trusted data space, data needs to be securely shared, accessed, and processed among multiple entities (such as enterprises, institutions, and node servers), and the traceability of data operations is one of the core requirements for ensuring "trustworthiness".
[0003] In existing technologies, data operation logs are typically stored on centralized servers or single nodes, which has the following drawbacks: 1) Logs are easily tampered with: Logs stored in a centralized manner may be maliciously modified or deleted, making the traceability results unreliable; 2) Poor cross-node consistency: When multiple nodes collaborate, the log recording rules of each node are not consistent, making it difficult to form a complete end-to-end traceability chain; 3) Low audit efficiency: Post-audit requires retrieving logs across nodes, lacks a unified consensus verification mechanism, and is prone to log conflicts or missing logs.
[0004] There is currently no effective solution to the above problems in existing technologies. Summary of the Invention
[0005] To address the aforementioned issues, this invention provides a distributed traceability method and system for data operations in a trusted data space. By introducing decentralized storage, chained hash association, and cross-node consensus mechanisms from blockchain, it achieves tamper-proof evidence preservation, end-to-end consistent traceability, and efficient and reliable auditing of data operation logs.
[0006] To achieve the above objectives, this invention provides a distributed tracing method for data operations in a trusted data space, comprising: acquiring data operation logs of execution nodes; encrypting the data operation logs using an encryption key to obtain a current encrypted log; performing hash calculation based on the hash of the previous encrypted log and the current encrypted log to obtain a current log hash; when the execution node participates in cross-node interaction, sending the current encrypted log and the current log hash to a consensus node for consensus; after consensus is completed, packaging the consensus result, the current encrypted log, and the current log hash into a block and writing it into the blockchain; when tracing the source of target data is required, retrieving the target encrypted log related to the target data from the blockchain, decrypting the target encrypted log using the corresponding decryption key to obtain the log plaintext; performing integrity verification based on the target log hash corresponding to the target encrypted log, and generating a tracing report based on the verification result.
[0007] Further optionally, the step of performing hash calculation based on the hash of the previous log corresponding to the previous encrypted log and the current encrypted log to obtain the current log hash includes: concatenating the current encrypted log with the hash of the previous log to obtain a concatenation result; and performing hash calculation on the concatenation result using a hash algorithm to obtain the current log hash.
[0008] Optionally, the step of performing integrity verification based on the target log hash corresponding to the target encrypted log and generating a traceability report based on the verification result includes: performing correlation verification based on the target log hash and its previous log hash; recording the log plaintext that passes the correlation verification as valid logs, establishing the operation chain of the target data based on all valid logs, and obtaining the traceability report; recording the log plaintext that fails the correlation verification as abnormal logs, determining the abnormal type based on the abnormal logs, and marking and reminding the user.
[0009] Further optionally, obtaining the data operation log of the execution node includes: collecting operation-related information in real time when the execution node performs data operations on the data; and encapsulating the operation-related information according to a predefined structured format to obtain the data operation log.
[0010] On the other hand, the present invention also provides a distributed traceability system for data operations in a trusted data space, comprising: a log acquisition module for acquiring data operation logs of execution nodes; an encryption module for encrypting the data operation logs using an encryption key to obtain a current encrypted log; a chained hash calculation module for performing hash calculation based on the hash of the previous encrypted log and the current encrypted log to obtain a current log hash; an on-chain module for sending the current encrypted log and the current log hash to a consensus node for consensus when the execution node participates in cross-node interaction, and after consensus is completed, packaging the consensus result, the current encrypted log, and the current log hash into a block and writing it into the blockchain; and a traceability module for retrieving target encrypted logs related to the target data from the blockchain when traceability of target data is required, decrypting the target encrypted logs using a corresponding decryption key to obtain the log plaintext; performing integrity verification based on the target log hash corresponding to the target encrypted logs, and generating a traceability report based on the verification result.
[0011] Further optionally, the chained hash calculation module includes: a splicing submodule, used to splice the current encrypted log with the hash of the previous log to obtain a splicing result; and a hash calculation submodule, used to calculate the hash of the current log using a hash algorithm on the splicing result.
[0012] Further optionally, the tracing module includes: a verification submodule, used to perform correlation verification based on the target log hash and its previous log hash; a report generation submodule, used to record the log plaintext that passes the correlation verification as valid logs, establish the operation chain of the target data based on all valid logs, and obtain the tracing report; and an anomaly marking submodule, used to record the log plaintext that fails the correlation verification as an anomaly log, determine the anomaly type based on the anomaly logs, and mark and remind users.
[0013] Further optionally, the log acquisition module includes: a real-time acquisition submodule, used to collect operation-related information in real time when the execution node performs data operations on the data; and an encapsulation submodule, used to encapsulate the operation-related information according to a predefined structured format to obtain the data operation log.
[0014] On the other hand, the present invention also provides a distributed traceability device for data operations in a trusted data space, including the aforementioned distributed traceability system for data operations in a trusted data space.
[0015] On the other hand, the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the distributed tracing method for data operations in a trusted data space as described above.
[0016] The above technical solution has the following beneficial effects: By using blockchain storage and chained hash calculation, it ensures that neither single-node logs nor cross-node logs can be maliciously tampered with, and the traceability results are reliable; by combining single-node chained hashing and cross-node consensus, it enables the complete traceability of data operations from local to cross-node flow; audit nodes can directly retrieve logs from the blockchain and quickly confirm log integrity through hash verification, improving audit efficiency; encrypted log storage and access control ensure that sensitive operation information is only visible to authorized parties, balancing traceability and privacy protection. Attached Figure Description
[0017] 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.
[0018] Figure 1 This is a flowchart of the distributed tracing method for data operations in a trusted data space provided in an embodiment of the present invention; Figure 2 This is a flowchart of the log hash calculation method provided in an embodiment of the present invention; Figure 3This is a flowchart of the data tracing method provided in the embodiments of the present invention; Figure 4 This is a flowchart of the data operation log acquisition method provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of the distributed tracing system for data operations in a trusted data space provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the chain hash calculation module provided in an embodiment of the present invention; Figure 7 This is a schematic diagram of the traceability module provided in an embodiment of the present invention; Figure 8 This is a schematic diagram of the log acquisition module provided in an embodiment of the present invention.
[0019] Figure labeling: 100-Log acquisition module; 1001-Real-time acquisition submodule; 1002-Encapsulation submodule; 200-Encryption module; 300-Chain hash calculation module; 3001-Concatenation submodule; 3002-Hash calculation submodule; 400-On-chain module; 500-Tracing module; 5001-Verification submodule; 5002-Report generation submodule; 5003-Anomaly marking submodule. Detailed Implementation
[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0021] To address the problems of log tampering, poor cross-node consistency, and low auditing efficiency in existing technologies, this invention provides a distributed tracing method for data operations in a trusted data space. Figure 1 This is a flowchart of the distributed tracing method for data operations in a trusted data space provided in an embodiment of the present invention, such as... Figure 1 As shown, the method includes: S1. Obtain the data operation log of the execution node.
[0022] An execution node is a computing entity that participates in data processing and interaction within a trusted data space, including but not limited to data provider nodes, data user nodes, data exchange nodes, or relay service nodes. Execution nodes possess data access, processing, and communication capabilities, and are used to perform operations such as reading, writing, modifying, transmitting, or deleting data within their local environment.
[0023] When the execution node performs operations such as accessing, modifying, transferring or deleting target data, it collects information related to the operation in real time and generates corresponding data operation logs.
[0024] S2. Encrypt the data operation log using the encryption key to obtain the current encrypted log.
[0025] After generating the data operation log, the execution node calls its local security module to encrypt the log content, obtaining the current encrypted log. The execution node's security module (such as a hardware security chip HSM or a trusted execution environment TEE) generates and stores an encryption key, which is used to perform a symmetric encryption algorithm (such as AES-256) on the log content. In addition, it ensures that only nodes with key authorization or auditors (such as business nodes) can obtain the corresponding decryption key.
[0026] S3. Perform hash calculation based on the hash of the previous encrypted log and the current encrypted log to obtain the hash of the current log.
[0027] The previous encrypted log and its corresponding hash value are obtained and combined with the current encrypted log as input data for hash calculation, resulting in a chain of hashes linking logs. In other words, the current log hash is obtained by performing a joint hash calculation with the previous log hash.
[0028] Hash algorithms can employ secure hashing algorithms (such as the SHA series or SM3 algorithms) to represent the characteristics of log content with a fixed-length hash value.
[0029] S4. When the execution node participates in cross-node interaction, it sends the current encrypted log and the current log hash to the consensus node for consensus. After the consensus is completed, the consensus result, the current encrypted log and the current log hash are packaged into a block and written into the blockchain.
[0030] When an execution node participates in data interaction (e.g., data is transferred from one node to another), after completing log encryption and hash calculation, the execution node sends the current encrypted log and its corresponding log hash to the consensus node in the blockchain network. Upon receiving the log information from each participating node, the consensus node verifies its source, format, and timestamp, and verifies the consistency of the log content using a pre-defined distributed consensus algorithm (such as the Byzantine Fault Tolerance (PBFT) algorithm).
[0031] During the consensus process, multiple consensus nodes compare and vote on the log data of the same interaction event. Only when more than a predetermined proportion (e.g., more than two-thirds) of the nodes confirm that the log matches is the log record considered valid, and the consensus is completed.
[0032] Once consensus is reached, the consensus result, along with the corresponding encrypted logs and log hashes, is packaged together to form a block and written into the distributed ledger of the blockchain. The block contains a block header (previous block hash, timestamp, Merkle root) and a block body (a set of encrypted logs).
[0033] S5. When it is necessary to trace the source of target data, retrieve the target encrypted log related to the target data from the blockchain, decrypt the target encrypted log with the corresponding decryption key to obtain the log plaintext; perform integrity verification based on the target log hash corresponding to the target encrypted log, and generate a traceability report based on the verification result.
[0034] When a business node or audit node initiates a tracing request, it first retrieves a set of encrypted logs associated with the unique identifier of the target data from the blockchain distributed ledger. This set includes one or more target encrypted logs. Since these logs have all undergone consensus and notarization on the blockchain, the authenticity and completeness of the retrieval results can be ensured.
[0035] Using the authorized decryption key corresponding to each target encrypted log, the retrieved target encrypted logs are decrypted sequentially to obtain the plaintext log content. The plaintext log includes information such as the operation subject, operation type, operation time, and associated nodes, which can reflect the flow trajectory of target data in the trusted data space.
[0036] After decryption, integrity verification is performed based on the target log hash corresponding to each log entry to confirm whether the log records remain continuous and whether they have been tampered with or lost. When all log hashes match and the correlation is continuous, the log chain is considered complete and trustworthy; if hash inconsistencies or chain breaks are detected, abnormal logs are identified and abnormal node information is recorded.
[0037] As an optional implementation method, Figure 2 This is a flowchart of the log hash calculation method provided in an embodiment of the present invention, such as... Figure 2 As shown, the current log hash is obtained by performing a hash calculation based on the hash of the previous encrypted log and the current encrypted log, including: S301. Concatenate the current encrypted log with the hash of the previous log to obtain the concatenation result.
[0038] S302. Calculate the hash of the current log by using a hash algorithm on the concatenation result.
[0039] To achieve ordered association and tamper-proof verification between log records, the current encrypted log is hashed by combining the hash value of the previous encrypted log after it is generated, so as to generate a current log hash that can uniquely identify the log.
[0040] Specifically, the current encrypted log is first concatenated with the hash value of the previous log to form the hash input data; then, a hash operation is performed on the concatenated result to obtain the hash value corresponding to the current log, as shown in the following formula: Current log hash = SHA-256(encrypted log + previous log hash).
[0041] Through the above calculation method, the current log hash not only reflects the content characteristics of this log entry, but also establishes a chain-like relationship with the previous log entry, thereby ensuring the continuity and immutability of log records in time series. Once any log entry is modified, its hash chain relationship will be broken, and audit nodes can quickly identify abnormal logs through verification results, improving the security and reliability of log management.
[0042] As an optional implementation method, Figure 3 This is a flowchart of the data tracing method provided in the embodiments of the present invention, such as... Figure 3 As shown, integrity verification is performed based on the target log hash corresponding to the target encrypted log, and a traceability report is generated based on the verification result, including: S501. Verify the correlation between the target log hash and its previous log hash.
[0043] During data tracing, each target encrypted log related to the target data in the blockchain is read sequentially, and the target log hash and its predecessor hash are obtained for each target encrypted log. Subsequently, the hash values of adjacent logs are compared and verified to confirm whether the correlation between the logs conforms to the expected link structure.
[0044] S502. Record the plaintext logs that pass the correlation verification as valid logs, establish the operation chain of the target data based on all valid logs, and obtain the traceability report.
[0045] Logs that pass hash correlation verification are marked as valid logs. These logs accurately reflect various operations performed on the data within the trusted data space. Subsequently, based on the operation timestamps, operation subject identifiers, operation types, and associated node information recorded in the valid logs, the operation events of the target data are sequentially sorted and logically correlated to form a complete operation chain for the target data, which is then integrated into a traceability report.
[0046] S503. Record plaintext logs that fail the correlation verification as abnormal logs, determine the abnormal type based on the abnormal logs, and mark and remind the user.
[0047] When a log entry is detected to have a mismatch between its target log hash and its preceding log hash, or if the hash is missing or broken, the log entry is deemed to have failed the correlation verification and is recorded as an abnormal log entry. Abnormal log entries typically indicate risks such as potential tampering, deletion, forgery, or missing records.
[0048] After identifying abnormal logs, the system determines the type of abnormality based on its characteristics, such as hash chain breakage, timestamp reversal, or node signature inconsistency. The abnormal logs and their corresponding node identifiers are then marked and archived, and a pre-defined alert mechanism is triggered to send alarm information to the management node or auditor.
[0049] As an optional implementation method, Figure 4 This is a flowchart of the data operation log acquisition method provided in an embodiment of the present invention, such as... Figure 4 As shown, the data operation log of the execution node is obtained, including: S101. When the execution node performs data operations on the data, collect relevant operation information in real time.
[0050] When an execution node performs operations such as accessing, modifying, transferring, or deleting target data, the log collection module is automatically triggered to capture relevant information about the operation in real time.
[0051] The relevant operational information includes: Operation subject identifier (such as node ID, user ID); Operation object identifier (such as unique data ID, data fingerprint); Operation type (e.g., access, modification, transfer); Operation timestamp; Operation result (success / failure); Associated node information (such as the target node ID for transmission, if it is a transmission operation).
[0052] S102. Encapsulate the operation-related information according to a predefined structured format to obtain the data operation log.
[0053] After obtaining the operation-related information collected by the execution node, the information is encapsulated according to a pre-defined log template or data structure standard. This structured format can be in key-value pair form, JSON object, log line format, or a specific protocol data structure, used to clearly distinguish each information field and its corresponding content, such as operation subject, operation object, operation type, operation time, operation result, and associated node information.
[0054] This invention provides a distributed tracing system for data operations in a trusted data space. Figure 5 This is a schematic diagram of the structure of a distributed tracing system for data operations in a trusted data space provided in an embodiment of the present invention, as shown below. Figure 5 As shown, the system includes: The log acquisition module 100 is used to acquire the data operation logs of the execution node.
[0055] An execution node is a computing entity that participates in data processing and interaction within a trusted data space, including but not limited to data provider nodes, data user nodes, data exchange nodes, or relay service nodes. Execution nodes possess data access, processing, and communication capabilities, and are used to perform operations such as reading, writing, modifying, transmitting, or deleting data within their local environment.
[0056] When the execution node performs operations such as accessing, modifying, transferring or deleting target data, it collects information related to the operation in real time and generates corresponding data operation logs.
[0057] The encryption module 200 is used to encrypt the data operation log using an encryption key to obtain the current encrypted log.
[0058] After generating the data operation log, the execution node calls its local security module to encrypt the log content, obtaining the current encrypted log. The execution node's security module (such as a hardware security chip HSM or a trusted execution environment TEE) generates and stores an encryption key, which is used to perform a symmetric encryption algorithm (such as AES-256) on the log content. In addition, it ensures that only nodes with key authorization or auditors (such as business nodes) can obtain the corresponding decryption key.
[0059] The chain hash calculation module 300 is used to perform hash calculation based on the hash of the previous encrypted log and the current encrypted log to obtain the hash of the current log.
[0060] The previous encrypted log and its corresponding hash value are obtained and combined with the current encrypted log as input data for hash calculation, resulting in a chain of hashes linking logs. In other words, the current log hash is obtained by performing a joint hash calculation with the previous log hash.
[0061] Hash algorithms can employ secure hashing algorithms (such as the SHA series or SM3 algorithms) to represent the characteristics of log content with a fixed-length hash value.
[0062] The on-chain module 400 is used to send the current encrypted log and the current log hash to the consensus node for consensus when the execution node participates in cross-node interaction. After the consensus is completed, the consensus result, the current encrypted log and the current log hash are packaged into a block and written to the blockchain.
[0063] When an execution node participates in data interaction (e.g., data is transferred from one node to another), after completing log encryption and hash calculation, the execution node sends the current encrypted log and its corresponding log hash to the consensus node in the blockchain network. Upon receiving the log information from each participating node, the consensus node verifies its source, format, and timestamp, and verifies the consistency of the log content using a pre-defined distributed consensus algorithm (such as the Byzantine Fault Tolerance (PBFT) algorithm).
[0064] During the consensus process, multiple consensus nodes compare and vote on the log data of the same interaction event. Only when more than a predetermined proportion (e.g., more than two-thirds) of the nodes confirm that the log matches is the log record considered valid, and the consensus is completed.
[0065] Once consensus is reached, the consensus result, along with the corresponding encrypted logs and log hashes, is packaged together to form a block and written into the distributed ledger of the blockchain. The block contains a block header (previous block hash, timestamp, Merkle root) and a block body (a set of encrypted logs).
[0066] The traceability module 500 is used to retrieve target encrypted logs related to the target data from the blockchain when it is necessary to trace the target data, decrypt the target encrypted logs with the corresponding decryption key to obtain the log plaintext, perform integrity verification based on the target log hash corresponding to the target encrypted log, and generate a traceability report based on the verification result.
[0067] When a business node or audit node initiates a tracing request, it first retrieves a set of encrypted logs associated with the unique identifier of the target data from the blockchain distributed ledger. This set includes one or more target encrypted logs. Since these logs have all undergone consensus and notarization on the blockchain, the authenticity and completeness of the retrieval results can be ensured.
[0068] Using the authorized decryption key corresponding to each target encrypted log, the retrieved target encrypted logs are decrypted sequentially to obtain the plaintext log content. The plaintext log includes information such as the operation subject, operation type, operation time, and associated nodes, which can reflect the flow trajectory of target data in the trusted data space.
[0069] After decryption, integrity verification is performed based on the target log hash corresponding to each log entry to confirm whether the log records remain continuous and whether they have been tampered with or lost. When all log hashes match and the correlation is continuous, the log chain is considered complete and trustworthy; if hash inconsistencies or chain breaks are detected, abnormal logs are identified and abnormal node information is recorded.
[0070] As an optional implementation method, Figure 6 This is a schematic diagram of the chain hash calculation module provided in an embodiment of the present invention, as shown below. Figure 6 As shown, the chained hash calculation module 300 includes: The splicing submodule 3001 is used to splice the current encrypted log with the hash of the previous log to obtain the splicing result.
[0071] The hash calculation submodule 3002 is used to calculate the hash of the current log by using a hash algorithm on the concatenation result.
[0072] To achieve ordered association and tamper-proof verification between log records, the current encrypted log is hashed by combining the hash value of the previous encrypted log after it is generated, so as to generate a current log hash that can uniquely identify the log.
[0073] Specifically, the current encrypted log is first concatenated with the hash value of the previous log to form the hash input data; then, a hash operation is performed on the concatenated result to obtain the hash value corresponding to the current log, as shown in the following formula: Current log hash = SHA-256(encrypted log + previous log hash).
[0074] Through the above calculation method, the current log hash not only reflects the content characteristics of this log entry, but also establishes a chain-like relationship with the previous log entry, thereby ensuring the continuity and immutability of log records in time series. Once any log entry is modified, its hash chain relationship will be broken, and audit nodes can quickly identify abnormal logs through verification results, improving the security and reliability of log management.
[0075] As an optional implementation method, Figure 7 This is a schematic diagram of the traceability module provided in an embodiment of the present invention, as shown below. Figure 7 As shown, the traceability module 500 includes: The verification submodule 5001 is used to perform correlation verification based on the target log hash and its previous log hash.
[0076] During data tracing, each target encrypted log related to the target data in the blockchain is read sequentially, and the target log hash and its predecessor hash are obtained for each target encrypted log. Subsequently, the hash values of adjacent logs are compared and verified to confirm whether the correlation between the logs conforms to the expected link structure.
[0077] The report generation submodule 5002 is used to record the plaintext logs that have passed the correlation verification as valid logs, establish the operation chain of the target data based on all valid logs, and obtain the source tracing report.
[0078] Logs that pass hash correlation verification are marked as valid logs. These logs accurately reflect various operations performed on the data within the trusted data space. Subsequently, based on the operation timestamps, operation subject identifiers, operation types, and associated node information recorded in the valid logs, the operation events of the target data are sequentially sorted and logically correlated to form a complete operation chain for the target data, which is then integrated into a traceability report.
[0079] The exception marking submodule 5003 is used to record plaintext logs that fail the correlation verification as exception logs, determine the exception type based on the exception logs, and mark and alert the user.
[0080] When a log entry is detected to have a mismatch between its target log hash and its preceding log hash, or if the hash is missing or broken, the log entry is deemed to have failed the correlation verification and is recorded as an abnormal log entry. Abnormal log entries typically indicate risks such as potential tampering, deletion, forgery, or missing records.
[0081] After identifying abnormal logs, the system determines the type of abnormality based on its characteristics, such as hash chain breakage, timestamp reversal, or node signature inconsistency. The abnormal logs and their corresponding node identifiers are then marked and archived, and a pre-defined alert mechanism is triggered to send alarm information to the management node or auditor.
[0082] As an optional implementation method, Figure 8 This is a schematic diagram of the log acquisition module provided in an embodiment of the present invention, as shown below. Figure 8 As shown, the log acquisition module 100 includes: The real-time acquisition submodule 1001 is used to collect operation-related information in real time when the execution node performs data operations on the data.
[0083] When an execution node performs operations such as accessing, modifying, transferring, or deleting target data, the log collection module is automatically triggered to capture relevant information about the operation in real time.
[0084] The relevant operational information includes: Operation subject identifier (such as node ID, user ID); Operation object identifier (such as unique data ID, data fingerprint); Operation type (e.g., access, modification, transfer); Operation timestamp; Operation result (success / failure); Associated node information (such as the target node ID for transmission, if it is a transmission operation).
[0085] The encapsulation submodule 1002 is used to encapsulate operation-related information according to a predefined structured format to obtain a data operation log.
[0086] After obtaining the operation-related information collected by the execution node, the information is encapsulated according to a pre-defined log template or data structure standard. This structured format can be in key-value pair form, JSON object, log line format, or a specific protocol data structure, used to clearly distinguish each information field and its corresponding content, such as operation subject, operation object, operation type, operation time, operation result, and associated node information.
[0087] This invention also provides a distributed traceability device for data operations in a trusted data space, including the aforementioned distributed traceability system for data operations in a trusted data space.
[0088] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned distributed tracing method for data operations in a trusted data space.
[0089] The aforementioned storage media include, but are not limited to: optical discs, floppy disks, hard disks, and rewritable memory.
[0090] The following is a specific example: 1) In a cross-node data transmission scenario, connector A transmits data to connector B. After the data transmission, connector A, as the executing node, generates a "transmission operation" log. This log includes: A's node ID, data ID "D001", operation type "transmission", timestamp "T1", and the ID of the target connector B. Connector A encrypts the "transmission operation" log with its local AES key and establishes a connection with the hash value H0 of the previous log to obtain the current log hash H1 = SHA-256(encrypted log + hash H0 of connector A's previous log). 2) After receiving data, connector B, as the execution node, generates a "receive operation" log. The log content includes: B's node ID, data ID "D001", operation type "receive", timestamp "T2", and the ID of the source connector A. Connector B encrypts the "receive operation" log with its local AES key and establishes a connection with the hash value H0' of the previous log to obtain the current log hash H2 = SHA-256 (encrypted log + hash H0' of the previous log of connector B). 3) In the cross-node consensus node phase, connectors A and B send their local encrypted logs and corresponding log hashes (i.e., H1 and H2) to the consensus node respectively; the consensus node verifies the consistency of the data ID and node ID in the encrypted log (confirming that it is the same transmission operation), and reaches consensus through the PBFT algorithm; the consensus result, the encrypted logs, H1, and H2 are packaged into a block and written to the blockchain. The block header contains the hash of the previous block and the Merkle root (used to quickly verify the integrity of the block). 4) During the traceability audit phase, when a business node needs to trace the transmission trajectory of data with data ID "D001", it retrieves the relevant encrypted logs of connectors A and B from the blockchain; after decryption with the authorized key, it verifies that the logs have not been tampered with by associating H1 with H0 and H2 with H0'; combined with timestamps T1 and T2, it confirms the data transmission process from A to B and forms a traceability report.
[0091] The above technical solution has the following beneficial effects: By using blockchain storage and chained hash calculation, it ensures that neither single-node logs nor cross-node logs can be maliciously tampered with, and the traceability results are reliable; by combining single-node chained hashing and cross-node consensus, it enables the complete traceability of data operations from local to cross-node flow; audit nodes can directly retrieve logs from the blockchain and quickly confirm log integrity through hash verification, improving audit efficiency; encrypted log storage and access control ensure that sensitive operation information is only visible to authorized parties, balancing traceability and privacy protection.
[0092] The above-described specific embodiments of the invention further illustrate the purpose, technical solution, and beneficial effects of the invention. It should be understood that the above content is only for specific embodiments of the invention and is not intended to limit the scope of protection of the invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the invention should be included within the scope of protection of the invention.
Claims
1. A method for distributed provenance of data operations in a trusted data space, characterized in that, The method comprises the following steps: obtaining a data operation log of an execution node; encrypting the data operation log by using an encryption key to obtain a current encrypted log; calculating a current log hash by hashing the previous log hash corresponding to the previous encrypted log and the current encrypted log; when the execution node participates in cross-node interaction, sending the current encrypted log and the current log hash to a consensus node for consensus, and after the consensus is completed, packing the consensus result, the current encrypted log and the current log hash into a block and writing the block into a block chain; when it is necessary to trace a target data, retrieving a target encrypted log related to the target data from the block chain, decrypting the target encrypted log by using a corresponding decryption key to obtain a log plaintext, verifying the integrity according to a target log hash corresponding to the target encrypted log, and generating a trace report according to the verification result.
2. The method of claim 1, wherein, The method of calculating the current log hash by hashing the previous log hash corresponding to the previous encrypted log and the current encrypted log comprises the following steps: splicing the current encrypted log and the previous log hash to obtain a splicing result; calculating the current log hash by hashing the splicing result. 3.The method of claim 1, wherein, The method of verifying the integrity according to the target log hash corresponding to the target encrypted log and generating the trace report according to the verification result comprises the following steps: verifying the relevance according to the target log hash and the previous log hash thereof; recording the log plaintext that passes the relevance verification as a valid log, establishing an operation link of the target data according to all the valid logs, and obtaining the trace report; recording the log plaintext that fails the relevance verification as an abnormal log, determining an abnormal type according to the abnormal log, and marking and reminding.
4. The method of claim 1, wherein, The method of obtaining the data operation log of the execution node comprises the following steps: when the execution node performs a data operation on data, collecting operation related information in real time; packaging the operation related information in a pre-defined structured format to obtain the data operation log. 5.A distributed provenance system for data operations in a trusted data space, characterized in that, The method comprises the following steps: a log obtaining module is configured to obtain a data operation log of an execution node; an encryption module is configured to encrypt the data operation log by using an encryption key to obtain a current encrypted log; a chained hash calculation module is configured to calculate a current log hash by hashing a previous log hash corresponding to a previous encrypted log and the current encrypted log; a chain uploading module is configured to, when the execution node participates in cross-node interaction, send the current encrypted log and the current log hash to a consensus node for consensus, and after the consensus is completed, pack the consensus result, the current encrypted log and the current log hash into a block and write the block into a block chain; a trace module is configured to, when it is necessary to trace a target data, retrieve a target encrypted log related to the target data from the block chain, decrypt the target encrypted log by using a corresponding decryption key to obtain a log plaintext, verify the integrity according to a target log hash corresponding to the target encrypted log, and generate a trace report according to the verification result. 6.The distributed provenance system for data operations in a trusted data space of claim 5, wherein, The chained hash calculation module comprises: a splicing sub-module configured to splice the current encrypted log and the previous log hash to obtain a splicing result; The hash calculation submodule is configured to calculate the spliced result by using a hash algorithm to obtain the current log hash.
7. The system of claim 5, wherein, The traceability module comprises: The verification submodule is configured to perform relevance verification on the target log hash and the previous log hash thereof. The report generation submodule is configured to record log plaintexts that pass the relevance verification as valid logs, establish an operation link of target data according to all valid logs, and obtain the traceability report. The abnormality marking submodule is configured to record log plaintexts that fail the relevance verification as abnormal logs, determine an abnormal type according to the abnormal logs, and perform marking and reminding. 8.The system of claim 5, wherein, The log acquisition module comprises: The real-time collection submodule is configured to collect operation-related information in real time when a data operation is performed on data by an execution node. The encapsulation submodule is configured to encapsulate the operation-related information in a predefined structured format to obtain the data operation log. 9.A device for distributed provenance of data operations in a trusted data space, characterized in that, The program is executed by a processor to implement the method for distributed traceability of data operations in a trusted data space according to any one of claims 1-4.
10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The program is executed by a processor to implement the method for distributed traceability of data operations in a trusted data space according to any one of claims 1-4.