An automated blockchain notarization system combined with a smart contract

Abstract

This invention discloses an automated blockchain-based evidence storage system incorporating smart contracts, relating to the fields of blockchain technology and electronic data evidence storage technology. The system includes: a data acquisition module for collecting raw data and generating standardized data packets; a hash calculation module for calculating data fingerprints; a smart contract evidence storage module deployed on the blockchain, embedding multiple triggering rules such as time, data volume, and event signals, automatically packaging the data fingerprints, calculating Merkle root hashes, and uploading them to the blockchain when the rules are met; and an evidence storage monitoring and feedback module for monitoring transaction status, generating vouchers, and establishing local associations. The system achieves automated execution of evidence storage decisions through smart contracts, supports rapid response to urgent priorities, and realizes full-process automation from data generation to on-chain solidification, thereby improving the efficiency and credibility of high-frequency real-time evidence storage.

Description

Technical Field

[0001] This invention relates to the fields of blockchain technology and electronic data storage technology, and more specifically, to an automated blockchain storage system that incorporates smart contracts. Background Technology

[0002] With the deepening of digital transformation, electronic data is playing an increasingly important role in scenarios such as judicial litigation, intellectual property protection, administrative supervision, and corporate internal auditing. Whether electronic data has legal evidentiary effect depends on whether the authenticity and integrity of its generation, storage, and transmission process can be effectively proven. Traditional electronic data preservation mainly relies on centralized trusted third-party institutions such as notary offices, judicial appraisal centers, and trusted timestamp service centers, where users actively submit data files and the institutions issue certificates with electronic signatures. However, the above-mentioned centralized evidence storage model has the following problems in practical applications: Evidence preservation is costly and inefficient. Users need to manually log in to the evidence preservation platform, upload files, fill in information, pay fees, and wait for manual review and issuance of certificates. The process is cumbersome and time-consuming, making it difficult to meet the demand for automated evidence preservation with high frequency, large scale, and real-time requirements. For example, IoT devices generate thousands of sensor readings per second, and financial transaction systems generate millions of logs per day. Evidence preservation based on manual operation is not feasible. Second, centralized storage poses security risks. Servers of centralized institutions may be subject to hacker attacks, malicious tampering by internal personnel, or hardware failures leading to data loss. In the event of a dispute, the evidentiary value of data stored in centralized institutions may be questioned. Although some solutions employ digital signature technology for tamper-proof protection, the signing private key is still controlled by the central institution, which cannot solve the problem of unilateral tampering. Blockchain technology, with its decentralized, immutable, and traceable characteristics, is considered an ideal technology for solving the trust problem in electronic data storage. Currently, there are some technical solutions that apply blockchain to storage. The basic idea is that users calculate the hash value of the document to be stored, send the transaction through wallet signature, and write the hash value into the blockchain ledger. However, such solutions usually only solve the immutability of the storage record. Data collection, triggering decision-making, and certificate feedback still rely on manual or external program intervention, and have not achieved true full-process automated storage. Therefore, it is necessary to design a fully automated blockchain evidence storage system that can automatically collect data from the source, intelligently trigger on-chain data collection, and provide real-time feedback of credentials. Summary of the Invention

[0003] In view of the shortcomings of the existing technology, the purpose of this invention is to provide an automated blockchain evidence storage system that combines smart contracts to solve the problems existing in the background technology.

[0004] The above-mentioned technical objective of the present invention is achieved through the following technical solution: an automated blockchain evidence storage system combined with smart contracts, comprising: a data acquisition module, used to collect raw data to be stored from a preset data source in real time or at regular intervals, and to perform format standardization processing and content preprocessing on the raw data to generate a standardized data packet; A hash calculation module is used to connect to the data acquisition module to perform cryptographic hash operations on the standardized data packets, thereby generating a unique corresponding data fingerprint. The smart contract notarization module is set up in the blockchain network and has embedded notarization triggering rule set and notarization execution logic. The notarization triggering rule set includes several different types of notarization triggering rules. After receiving the data fingerprint, the smart contract notarization module is used to determine whether any preset triggering rule in the notarization triggering rule set is satisfied based on the current system state. When the determination is satisfied, it automatically calls the underlying blockchain interface to package the data fingerprint and associated standardized data packet into notarization transaction and write it into the blockchain ledger. The evidence storage monitoring and feedback module is used to obtain the confirmation status of the evidence storage transaction in the blockchain network, and after confirming that the evidence storage transaction has been successfully uploaded to the chain, generate an evidence storage certificate containing a transaction hash and a trusted timestamp, and feed the evidence storage certificate back to the preset receiving end.

[0005] Optionally, the data acquisition module includes a data desensitization unit, which is used to identify sensitive fields in the original data and replace, mask, or encrypt the sensitive fields according to a preset desensitization strategy. The hash calculation module is specifically used to perform hash operations on the standardized data packets processed by the data desensitization unit.

[0006] Optionally, the data desensitization unit is configured with a sensitive field identification engine based on a machine learning classification model, and a desensitization strategy library containing at least one desensitization algorithm mapping table; the desensitization algorithm mapping table records the association between different sensitive field types and their corresponding desensitization algorithms.

[0007] Optionally, the evidence storage triggering rule set in the smart contract evidence storage module includes at least two of the following: time-triggered rules, data volume-triggered rules, and event signal-triggered rules, specifically: The time triggering rule is preset to be: when the time interval between the current system time and the time of the last successful execution of the evidence storage operation by the smart contract is greater than or equal to a preset time threshold, the evidence storage operation is triggered. The data volume triggering rule is preset to be: when the number of data fingerprints received but not yet uploaded to the chain in the temporary storage area inside the smart contract notarization module is greater than or equal to a preset number threshold, the notarization operation is triggered. The event signal triggering rule is preset to be: when the smart contract notarization module receives a specific notarization instruction signal with a preset priority identifier from an external system or internal module, the notarization operation is triggered.

[0008] Optionally, the smart contract notarization module is internally configured with a cache mapping table and a state counter for temporarily storing fingerprints of data to be uploaded to the blockchain. After receiving the data fingerprint, the smart contract notarization module first writes the data fingerprint into the cache mapping table and increments the state counter. When performing notarization operations, the smart contract notarization module reads all or part of the data fingerprints in the cache mapping table, calculates the corresponding Merkle root hash value, and uploads the Merkle root hash value as the payload data for this notarization transaction to the blockchain.

[0009] Optionally, the event signal triggering rule is further set as follows: when the received evidence storage instruction signal carries an emergency priority identifier, the smart contract evidence storage module suspends the judgment of the time triggering rule and the data volume triggering rule, immediately reads all the temporarily stored data fingerprints in the current cache mapping table and the current data fingerprint that triggers the emergency priority identifier, and performs a one-time evidence storage and on-chain operation.

[0010] Optionally, the evidence storage monitoring and feedback module is also used to write the transaction hash and the trusted timestamp into the local log database associated with the data collection module after the evidence storage transaction is confirmed on the chain, so as to establish a traceable association between the local original data record and the on-chain evidence storage record.

[0011] Optionally, it also includes an evidence verification module, which is used for: Receive the data to be verified, perform the same cryptographic hash operation on the data to be verified as that of the hash calculation module, and generate a fingerprint of the data to be verified. Call the on-chain query interface provided by the smart contract notarization module to search the blockchain ledger for whether there is a historical notarization record that matches the fingerprint of the data to be verified. If a consistent notarization record is found, the notarization transaction hash, block height, and notarization timestamp corresponding to that notarization record are extracted, and a verification result report containing the above information is output; if no notarization record is found, a prompt message indicating that the data has not been notarized or has been tampered with is output.

[0012] An automated blockchain evidence storage method applied to the aforementioned automated blockchain evidence storage system incorporating smart contracts includes the following steps: Step S1: Obtain the original data to be stored through the data acquisition module, and perform format standardization and content preprocessing on the original data to obtain a standardized data packet; Step S2: Perform cryptographic hash operations on the standardized data packet using the hash calculation module to generate a unique corresponding data fingerprint; Step S3: Send the data fingerprint to the smart contract notarization module deployed in the blockchain network. The smart contract notarization module determines whether the current system state meets any of the preset triggering rules according to its internal preset notarization triggering rule set. Step S4: When it is determined that the preset triggering rule is met, the smart contract notarization module automatically calls the underlying blockchain interface to package at least one data fingerprint and associated metadata currently accumulated into a notarization transaction, and broadcasts the notarization transaction to the blockchain network for consensus confirmation. Step S5: Obtain the confirmation status of the evidence storage transaction in the blockchain network through the evidence storage monitoring and feedback module. After obtaining the transaction hash and block confirmation information corresponding to the evidence storage transaction, generate an evidence storage certificate containing the transaction hash and trusted timestamp, and feed the evidence storage certificate back to the preset receiving end.

[0013] In summary, the present invention has the following beneficial effects: 1. Through the collaborative work of the data acquisition module, hash calculation module, smart contract notarization module, and notarization monitoring and feedback module, the system achieves fully automated notarization throughout the entire process. No manual login, uploading, or confirmation is required, thus improving notarization efficiency.

[0014] 2. The system has a flexible triggering mechanism driven by smart contracts, which embeds the evidence storage triggering rules into the smart contracts and supports the combined use of various rules such as time triggering, data volume triggering, and event signal triggering. The smart contracts automatically determine the evidence storage timing based on the system status, thus decoupling the evidence storage logic from the business logic.

[0015] 3. The system implements data privacy protection and on-chain storage optimization. By setting up a data desensitization unit to desensitize sensitive fields before hash calculation, it ensures that the data fingerprint uploaded to the blockchain does not leak the original data privacy. At the same time, Merkle root hash is used as the payload data for batch notarization, compressing multiple data fingerprints into a fixed-length hash value for on-chain storage, which significantly reduces blockchain storage overhead and transaction fees.

[0016] 4. The system has the ability to respond quickly to emergency evidence storage. For abnormal events or high-priority evidence storage needs, an emergency priority identification mechanism is designed. When the smart contract receives an instruction signal carrying an emergency identification, it can immediately stop the waiting logic of the regular triggering rules and put all the currently cached data to be stored on the chain at once to ensure that the key evidence data obtains tamper-proof timestamp proof as soon as possible.

[0017] 5. The system features closed-loop verification and traceability. The evidence storage monitoring and feedback module writes the on-chain transaction hash back to the local log database, establishing a one-to-one correspondence between the local original data and the on-chain evidence storage records. The evidence storage verification module supports independent verification of the data to be verified by any third party. It only needs to calculate the hash value and query the blockchain to verify the authenticity, integrity, and storage time of the data, without relying on any centralized authoritative institution. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the system architecture process logic of the present invention; Figure 2 This is a schematic diagram of the implementation method of the present invention. Detailed Implementation

[0019] To make the objectives, features, and advantages of the present invention more apparent and understandable, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Several embodiments of the present invention are shown in the drawings. However, the present invention can be implemented in many different forms and is not limited to the embodiments described herein.

[0020] In this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," "linking," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances. The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature.

[0021] In this invention, unless otherwise expressly specified and limited, "above" or "below" a second feature can include direct contact between the first and second features, or contact between the first and second features through another feature between them. Furthermore, "above," "over," and "on top" of a second feature includes the first feature being directly above or diagonally above the second feature, or simply indicates that the first feature is at a higher horizontal level than the second feature. "Below," "below," and "under" of a second feature includes the first feature being directly below or diagonally below the second feature, or simply indicates that the first feature is at a lower horizontal level than the second feature. The terms "vertical," "horizontal," "left," "right," "above," "below," and similar expressions are for illustrative purposes only and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed or operated in a specific orientation, and therefore should not be construed as limiting the invention.

[0022] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0023] This invention provides an automated blockchain-based evidence storage system that incorporates smart contracts, such as... Figure 1 As shown, the modules include a data acquisition module, a hash calculation module, a smart contract notarization module, and a notarization monitoring and feedback module. Optionally, the system may also include a data desensitization unit built into the data acquisition module and an evidence verification module; The data acquisition module communicates with the hash calculation module; the hash calculation module communicates with the smart contract notarization module. Specifically, the hash calculation module calls the public functions of the smart contract notarization module through the JSON-RPC, RESTful API, or WebSocket interface provided by the blockchain node. The smart contract notarization module is deployed and runs on several consensus nodes in the blockchain network. The notarization monitoring and feedback module runs independently and obtains the confirmation status of the notarization transaction by acquiring the event log of the blockchain network or polling transaction receipts. The notarization verification module is connected to the hash calculation module and the blockchain network respectively and is used to perform post-notarization verification.

[0024] Furthermore, in this embodiment, the data acquisition module is the data entry component of the automated blockchain evidence storage system. It is used to collect the original data to be stored from a preset data source in real time or at regular intervals, and to perform format standardization and content preprocessing on the original data to generate standardized data packets. The data acquisition module can be deployed in a computing environment close to the data source, such as a business server, industrial gateway, IoT edge computing node or cloud virtual machine instance. The data acquisition module further includes the following functional sub-units: Data source adaptation unit: Used to establish communication connections with different types of data sources and obtain the original data to be stored from the data sources. Data Acquisition Scheduling Unit: Used to control the triggering timing of data acquisition, supporting two working mechanisms: real-time monitoring mode and timed polling mode; Data standardization processing unit: used to perform format conversion and structure unification processing on raw data, converting heterogeneous data into a predefined structured data representation; Data desensitization unit: used to identify sensitive fields in the original data and perform desensitization processing on the sensitive fields according to the preset desensitization strategy; Standardized data packet assembly unit: used to combine the data content after standardization and desensitization with the collected metadata into a standardized data packet, and send the standardized data packet to the hash calculation module through the data output interface; Data is transmitted between the sub-units via an internal data bus, and a configuration management interface is provided to the outside to support dynamic adjustment of acquisition strategies, desensitization rules and output format parameters; The data source adaptation unit is used to shield the differences in access protocols and data formats between different data sources, and provides a unified data acquisition interface for the upper-layer data processing flow. It can be used to adapt and connect to various types of data sources: File system data source: When the preset data source is a server log file or an application output file, the data source adaptation unit obtains incremental change events of file content in the file system in real time by calling the file change monitoring mechanism provided by the operating system. Message queue data source: When the preset data source is streaming data transmitted through message middleware, the data source adaptation unit acts as a message receiver and obtains the specified topic or queue from the message middleware. Database data source: When the preset data source is incremental data in a relational database or a non-relational database, the data source adaptation unit obtains the newly added or changed data records by acquiring the database change data capture log or periodically executing incremental structured query statements. Network interface data source: When the preset data source is data reported through the application layer network protocol, the data source adaptation unit starts the embedded Hypertext Transfer Protocol server, connects to the specified network port, and receives data submitted by the external system through the Hypertext Transfer Protocol as the original data to be stored.

[0025] The data acquisition scheduling unit is used to control the triggering timing of data acquisition operations. It can be configured and selected according to the characteristics of the data source and business requirements by using the following two data acquisition scheduling modes. Real-time acquisition mode: This mode is suitable for scenarios where the data source continuously generates incremental data. In real-time monitoring mode, the acquisition scheduling unit maintains a continuous acquisition state of the data source. When an event notification of new data arrival from the data source is detected, the acquisition scheduling unit immediately wakes up the data source adaptation unit to perform the data acquisition operation; Scheduled Acquisition Mode: This mode is suitable for scenarios where the data source does not support an active push mechanism or where the real-time requirements for data acquisition are relatively low. In scheduled mode, the acquisition scheduling unit maintains a configurable scheduled task scheduling table and periodically triggers acquisition tasks according to preset time interval parameters. The preset time interval parameters can be configured to a fixed duration value according to actual needs, such as every five seconds, every minute, or every hour. When a scheduled task is triggered, the scheduling unit notifies the data source adaptation unit to actively initiate a data query request to the data source to obtain the available raw data to be stored in the data source at the current time. Furthermore, the acquisition scheduling unit can be configured to simultaneously enable real-time acquisition mode and timed acquisition mode to adapt to the differentiated acquisition needs in a mixed data source environment.

[0026] Specifically, since the raw data generated from different data sources have obvious differences in format and structure, such as unstructured plain text log content, semi-structured JSON or Extensible Markup Language documents, and structured relational database records, the role of the data standardization processing unit is to convert heterogeneous raw data into a unified, structured data representation form to facilitate subsequent hash operations and metadata association operations. The data standardization processing unit performs the following processing steps on each piece of raw data obtained: Format recognition and parsing steps: Based on the type identification information provided by the data source adaptation unit, or by analyzing the characteristic patterns of the data content itself, the current format of the original data is automatically identified; specifically, if the data content starts with a left curly brace character and can be successfully parsed into an object structure that conforms to the JSON specification, then the current format is identified as JSON format; if the data content conforms to a preset regular expression pattern, such as starting with a four-digit year followed by a series of characters followed by a two-digit month, then the current format is identified as a log text format with a timestamp prefix; Field extraction and mapping steps: Based on a pre-configured set of parsing rules, extract key fields with evidentiary value from the raw data; parsing rules include, but are not limited to: regular expression capture group rules, JSONPath path expressions, XPath path expressions, and fixed offset position truncation rules; specifically, for Apache Hypertext Transfer Protocol server access logs, extractable fields include client Internet Protocol address, request reception timestamp, request method, Uniform Resource Locator path, response status code, and response data body size; for JSON format sensor telemetry messages, extractable fields include device identifier, sensor type identifier, measurement value, measurement unit, and acquisition timestamp; The structural reorganization step involves reorganizing the extracted key fields into a unified structured data object according to a predefined standardized data pattern. In a preferred embodiment of the invention, JSON object format is used as the internal representation format of the standardized data packet. The standardized data packet generated after processing by the data standardization unit consists of the following two types of information: Business data content section: contains the core content to be stored after being extracted and reorganized from the raw data; for example, the message text of an application log record, the measurement value of a sensor reading, etc.

[0027] The evidence storage metadata section includes additional contextual description information to ensure the integrity and traceability of the evidence storage records. The evidence storage metadata includes, but is not limited to, the following items: data generation timestamp (if the original data already contains a timestamp field, the value of that field will be used first; otherwise, the system time at the time of data collection will be used as the collection timestamp), data source identification information (such as the server hostname, Internet protocol address, device identifier, and source file storage path that generated the data), version number of the standardized data format, collection batch identifier, etc. Specifically, to avoid the risk of leakage of personal privacy information or commercially sensitive information that may be contained in the original data during subsequent processing and evidence preservation, the data acquisition module further includes a data desensitization unit. The data desensitization unit is used to identify sensitive fields in the original data and replace, mask, or encrypt the sensitive fields according to a preset desensitization strategy. The data desensitization unit performs desensitization operations on the business data content in the standardized data packet, especially the free text fields. Only after the data content has been desensitized is it passed to the hash calculation module for data fingerprint calculation. The data desensitization unit is equipped with a sensitive field recognition engine based on a machine learning classification model, which is used to automatically detect predefined sensitive information fields from unstructured or semi-structured text content; In a preferred embodiment of the present invention, the sensitive field recognition engine adopts a named entity recognition model architecture based on deep neural networks. Specifically, the model uses a pre-trained language model based on the Transformer architecture as a text encoder, and superimposes a bidirectional long short-term memory network layer and a conditional random field sequence labeling layer on its output layer to form a three-layer cascaded architecture of pre-trained language model, bidirectional long short-term memory network, and conditional random field. The sensitive entity categories that the model can identify include, but are not limited to, the following types: Chinese names, ID card numbers, mobile phone numbers, landline numbers, bank card numbers, email addresses, Internet Protocol version 4 addresses, Internet Protocol version 6 addresses, license plate numbers, passport numbers, detailed address information, and company names; Let the input text sequence be ,in This represents the i-th character in the input text sequence, where n is the total number of characters in the input text sequence. After processing the input text sequence, the sensitive field recognition engine outputs a label sequence of the same length as the input sequence. ,in L is a predefined set of entity tags. The tag set L adopts the BIO annotation system, where B is the starting character representing a certain type of entity, l is the internal or ending character representing a certain type of entity, and O represents ordinary characters that are not entities. During the system initialization phase, the sensitive field recognition engine loads the pre-trained model parameter file and builds an inference computation session. When it is necessary to identify sensitive information in a piece of text to be analyzed, the sensitive field recognition engine converts the text into the model input format, performs forward computation, and obtains the label sequence Y. By decoding the label sequence Y, the entity category of each sensitive entity fragment and its start and end character position index in the original text can be extracted. In other embodiments, in addition to the machine learning model-based identification method described above, the sensitive field identification engine can also be configured with a set of regular expression-based rule recognizers as a supplementary identification method. The rule recognizers are used to identify sensitive information types with highly fixed formats and that conform to specific encoding rules, such as 18-digit ID card numbers that conform to national standard encoding rules, mobile phone numbers that conform to telecommunications network numbering plans, etc. The identification priority of the rule recognizers is set to be lower than that of the machine learning model, that is, it is only used as a backup identification strategy when the machine learning model fails to identify any entity. The data desensitization unit is further equipped with a desensitization strategy library, which contains at least one desensitization algorithm mapping table. The desensitization algorithm mapping table is used to record the preset association between different sensitive field types and corresponding desensitization algorithms, so that the data desensitization unit can automatically select the matching desensitization algorithm and perform the corresponding desensitization processing operation according to the identified sensitive field type.

[0028] The de-identification algorithm mapping table includes, but is not limited to, the following types of de-identification algorithms: Fixed string replacement algorithm: This algorithm replaces all identified sensitive fields with a pre-defined fixed string constant. Let the identified sensitive text be S, and the pre-defined replacement constant be C. Then the desensitized output D satisfies: D=C. For example, it can uniformly replace all Chinese names with the string " ”; The middle character masking algorithm: Retains a certain number of characters at the beginning and end of the sensitive field, and replaces all characters in the middle with a specified mask character. Let the identified sensitive field text be S, and its total character length be |S|; the preset number of characters to retain at the beginning is h, the number of characters to retain at the end is t, and the mask character is m; then the desensitized output D is defined by the following piecewise function: the first h characters of D are equal to the first h characters of S, the last t characters of D are equal to the last t characters of S, and the middle characters of D... All characters are replaced with the mask character 'm'; for example, for mobile phone numbers, the default is... The original number "138...5678" will output "138" after being de-sensitized. 5678”; The suffix-only masking algorithm retains only a few characters at the end of the sensitive field, replacing all other characters before it with a specified mask character. Let the identified sensitive field text be S, and its total character length be |S|; the preset number of characters to retain at the end is t, and the mask character is m; then the desensitized output D satisfies: the last t characters of D are equal to the last t characters of S, and the first |S|-t characters of D are all replaced with the mask character m; Network address generalization algorithm: For Internet Protocol address type data, the low-order part of the address that identifies the specific host is zeroed, and only the high-order part that identifies the network prefix is ​​retained; Let the original Internet Protocol address be A, and the preset number of network prefix bits to be retained be p, then the generalized address A' satisfies: A' = A bitwise AND (subnet mask), where the first p bits of the subnet mask are binary 1s and the remaining bits are binary 0s; Hash substitution algorithm: The original content of the sensitive field is taken as input, its hash value is calculated by a cryptographic hash function, and the first few characters of the hash value are truncated as the desensitized replacement output; Let the original sensitive field be S, the cryptographic hash function used be H(·), and the number of truncation bits be k, then the desensitized output result D satisfies: D = substring(H(S), 1, k); To elaborate further, after the data standardization processing unit completes the format standardization process, the generated standardized data packet is sent to the data desensitization unit. The desensitization process includes the following steps: Step A1: Search the standardized data packets for target fields that are pre-configured to require de-identification processing; by default, the target fields are free text message fields in the business data content. Step A2: For the text content of each target field, call the sensitive field recognition engine to analyze and process the text content to obtain a list of sensitive entities; each record in the sensitive entity list contains the following information: entity type identifier, the starting character position index and the ending character position index of the entity in the text; Step A3: Sort the list of sensitive entities in descending order according to the starting character position index of their entities, that is, arrange them in the order from the end of the text to the beginning of the text; the purpose of taking the descending order is to avoid the original position index of subsequent entities becoming invalid due to changes in text length after the desensitization and replacement of previous entities. Step A4: Search each sensitive entity record in the sorted sensitive entity list sequentially, performing the following sub-steps: Sub-step A4.1: Based on the entity type identifier of the current sensitive entity, query the de-identification algorithm mapping table to obtain the target de-identification algorithm identifier associated with the entity type and the parameter configuration value corresponding to the target de-identification algorithm; Sub-step A4.2: Call the desensitization algorithm processing function corresponding to the target desensitization algorithm identifier, pass in the original text fragment of the current sensitive entity and the parameter configuration value as input parameters, and calculate to obtain the desensitized replacement text string; Sub-step A4.3: In the original text content of the target field, replace the character fragments from the starting character position index to the ending character position index with the replacement text string; Step A5: After all records in the sensitive entity list have been processed, write the de-identified and replaced text content back to the corresponding field position in the standardized data packet; After processing by the data standardization unit and desensitization by the data desensitization unit, the standardized data packet assembly unit is responsible for the final encapsulation of the processed data content and sending the standardized data packet to the hash calculation module through the data output interface. The standardized data packet assembly unit serializes structured data objects in memory into byte sequences with a specific character encoding format. The data acquisition module then transmits the serialized standardized data packets to the hash calculation module through a preset data output interface. Furthermore, to ensure the reliability of the original data to be stored during the collection and transmission process and to prevent data loss, the data collection module has a collection confirmation mechanism and a failure retry mechanism. The data acquisition confirmation mechanism works as follows: After a standardized data packet is successfully sent to the hash calculation module and a confirmation message indicating successful processing is received, the data acquisition module records the current data acquisition point information in local persistent storage. The acquisition point information varies depending on the data source type. For example, for file system data sources, the acquisition point information is the offset of the file that has been successfully processed and confirmed; for message queue data sources, it is the offset of the message that has been successfully confirmed; and for database data sources, it is the timestamp boundary value of the currently successfully confirmed change data capture log or incremental query.

[0029] The workflow of the failure retry mechanism is as follows: If the sending operation of the standardized data packet fails to be completed successfully or a valid processing success response confirmation is not received, the data acquisition module initiates a retry operation according to the preset retry strategy; the preset retry strategy includes the maximum number of retry threshold and the retry interval duration parameter. Preferably, the retry interval parameter is calculated using the exponential backoff algorithm, that is, the waiting time between the i-th retry and the previous retry. ,in The initial baseline waiting time is denoted by i, which is the ordinal number of the retry count. If all retries fail within the maximum retry count threshold, the data acquisition module will temporarily store the unsuccessfully sent standardized data packets in the local persistent buffer storage area, and resend them after the downstream service resumes normal operation.

[0030] In a specific embodiment, the first end of the hash calculation module is communicatively connected to the data acquisition module to receive the standardized data packets output by the data acquisition module; the second end of the hash calculation module is communicatively connected to the smart contract notarization module to send the calculated data fingerprint to the smart contract notarization module. The main function of the hash calculation module is to perform cryptographic hash operations on the received standardized data packets, thereby generating a unique corresponding data fingerprint; the data fingerprint is a cryptographic digest of the content of the standardized data packet. The hash calculation module can be deployed on the same computing node as the data acquisition module, or it can be deployed independently on a dedicated computing server. When a distributed deployment architecture is adopted, the data acquisition module and the hash calculation module transmit data through a message queue or remote procedure call protocol. In this embodiment, the SHA-256 algorithm is selected. The input data received by the hash calculation module is the standardized data packet generated by the data acquisition module. According to the specific implementation of the aforementioned data acquisition module, the standardized data packet is a structured data object obtained after format standardization processing and content preprocessing (including optional data desensitization processing). Specifically, the standardized data packet is represented in JSON format and serialized into a byte sequence in UTF-8 character encoding format.

[0031] Before performing hash operations on standardized data packets, the hash calculation module first performs integrity checks on the received data to ensure that the data has not been damaged or truncated during transmission. If the data reception is incomplete or the check fails, the hash calculation module returns an error response to the data acquisition module, triggering the failure retry mechanism of the data acquisition module. Before performing the calculation, in order to ensure that the hash calculation module can generate completely consistent data fingerprints for two pieces of data to be stored with identical content, it must ensure that the byte sequence input to the hash function is deterministic; furthermore, for standardized data packets with the same logical content, regardless of when they come from or what serialization program they are generated by, the byte sequence input to the hash function must be completely equal byte by byte. Therefore, before passing the standardized data packet into the hash operation function, the hash calculation module performs serialization processing on the standardized data packet according to the following normalization rules: Attribute sorting rules: If the standardized data package is represented in JSON object format, all attribute items inside the object are arranged in lexicographical order of the attribute names; lexicographical order is defined as an ascending order based on Unicode code point values; that is, for any two attribute names A and B, the Unicode code point sequence of their strings is compared, and the one with the smaller code point value is listed first. Whitespace character elimination rules: The serialized output byte sequence does not contain any whitespace characters used only for formatting purposes, including but not limited to: newline character (Unicode code point U+000A), carriage return character (Unicode code point U+000D), horizontal tab character (Unicode code point U+0009), and space character (Unicode code point U+0020) outside the structure.

[0032] String delimiting and escaping rules: Double quotes (Unicode code point U+0022) are used as start and end delimiters for string type property values; special characters that need to be escaped in the string content are processed according to the minimum escape set defined by the JSON specification; except for characters that are required to be escaped by the JSON specification, other Unicode characters are output directly in their original encoded form without additional hexadecimal escaping serialization.

[0033] Numeric representation rules: Numeric attribute values ​​are serialized according to JSON numeric syntax, excluding leading zeros, positive prefixes, and meaningless trailing zeros; Through the above serialization rules, the hash calculation module ensures that for standardized data packets with the same content, the byte sequence generated by each serialization has bit-level consistency, thereby guaranteeing the determinism and reproducibility of subsequent hash operation results. During the calculation process, it can be mathematically defined as a deterministic compression function mapping. Let the input data received by the hash calculation module be a serialized byte sequence M, where the length of M is any non-negative integer number of octets. The SHA-256 hash algorithm defines a function mapping from a bit string of arbitrary length to a fixed-length 256-bit string, denoted as: H=SHA256(M). Where M is the input message byte sequence; H is the output hash value, which is a binary sequence of 256 bits, usually represented as 64 consecutive hexadecimal digit characters; The internal computation process of the SHA-256 algorithm includes the following main steps: Message padding steps: Append a bit "1" to the end of the input message M, followed by several bits "0", so that the total bit length of the padded message is congruent to 448 mod 512 (i.e., length ≡ 448 mod 512); finally, append a 64-bit binary representation, the value of which is equal to the bit length of the original message M; the total bit length of the padded message M' is an integer multiple of 512. Initial hash value setting: The SHA-256 algorithm defines eight 32-bit initial hash variables, denoted as follows: Its value is derived from the first thirty-two bits of the fractional part of the square root of the first eight prime numbers; Message packet processing steps: Divide the padded message M' into several message packets of length 512 bits, denoted as... Where n is the total number of groups; for each message group The process involves iterating through message scheduling expansion and compression functions, updating the intermediate state values ​​of eight hash variables; this process involves message words. Extended generation The round function operation updates the values ​​of eight working variables a, b, c, d, e, f, g, and h in each round.

[0034] Output steps: After processing all n message groups, output the final eight hash variables. By concatenating these bits sequentially, a hash value H of 256 bits is obtained. The data fingerprint H calculated by the hash calculation module is stored and transmitted internally as a 32-byte binary array. When interacting with the smart contract notarization module, the data fingerprint H is converted to a bytes32 data format to conform to the type definition convention of fixed-length byte arrays in smart contract programming languages. The bytes32 type is the standard type for representing fixed-length 32-byte binary data in the Ethereum Virtual Machine and compatible blockchain platforms.

[0035] When the data fingerprint H needs to be logged, displayed as credentials, or used for interface interaction in a human-readable format, the hash calculation module converts H into a hexadecimal numeric string representation. The hexadecimal string consists of sixty-four consecutive hexadecimal numeric characters (character values ​​range from numeric characters "0" to "9" and lowercase letters "a" to "f" or uppercase letters "A" to "F"). In a preferred embodiment of this invention, lowercase letters are used to represent hexadecimal values. Based on the descriptions of the components above, the hash calculation module performs the following workflow in a complete hash operation task: Step B1: Receive standardized data packets from the data acquisition module through the data input interface.

[0036] Step B2: Perform data integrity verification on the received standardized data packets. If the verification passes, proceed to step B3; if the verification fails, return an error response to the data acquisition module and terminate the current processing flow.

[0037] Step B3: Serialize the standardized data packet according to preset serialization normalization rules to generate a deterministic byte sequence M. The serialization normalization rules include attribute sorting rules, whitespace elimination rules, string delimiting and escaping rules, and numerical representation rules.

[0038] Step B4: Call the SHA-256 hash function from the cryptographic hash algorithm implementation library, passing the byte sequence M as the input parameter. The hash function performs internal calculations such as message padding, block compression, and result output, ultimately returning a hash value H of 256 bits.

[0039] Step B5: Use the hash value H as a data fingerprint and send it to the smart contract notarization module through the data output interface. The sending operation can be completed using synchronous calls or asynchronous message passing.

[0040] Step B6: Depending on the system configuration, the data fingerprint H and the corresponding data source identification information can be optionally recorded in the local log storage for subsequent data traceability and audit query.

[0041] Step B7: Return a successful processing response to the data acquisition module to trigger the data acquisition module's acquisition confirmation mechanism.

[0042] In a specific embodiment, the smart contract notarization module is the core execution component in the system that realizes automated notarization decision-making and on-chain data solidification; the smart contract notarization module is set in the blockchain network, specifically, it is deployed and runs on several consensus nodes of the blockchain network in the form of smart contract program code. The position of the smart contract notarization module in the system architecture and its interaction with upstream and downstream components are as follows: The first input of the smart contract notarization module is connected to the hash calculation module to receive the data fingerprint generated by the hash calculation module; the second input of the smart contract notarization module is connected to the external system or internal monitoring module to receive notarization instruction signals with preset priority identifiers; the output of the smart contract notarization module broadcasts the notarization transaction containing the data fingerprint and associated metadata to the blockchain network by calling the underlying blockchain application programming interface, and finally writes it into the blockchain ledger. The smart contract notarization module has an embedded notarization triggering rule set and notarization execution logic. The notarization triggering rule set includes several different types of notarization triggering rules, which are used to determine whether the preconditions for starting the notarization operation are met. The notarization execution logic defines the specific execution steps for how to perform batch processing, cryptographic digest calculation and on-chain transaction construction on the accumulated fingerprints of data to be notarized after the triggering conditions are met. In a preferred embodiment of the present invention, the blockchain network is an Ethereum Virtual Machine compatible blockchain platform, including but not limited to the public Ethereum network, the Hyperledger Besu network under the consortium blockchain framework, or the FISCO BCOS network; the smart contract notarization module is written in the Solidity programming language, compiled into Ethereum Virtual Machine bytecode by a compiler, and creates a contract instance on the blockchain network by deploying transactions, and obtains a unique contract account address; after deployment, the smart contract notarization module is in a continuous running state, responding to and processing function call requests sent to the contract address from the outside.

[0043] The smart contract notarization module's embedded notarization trigger rule set includes three types: time-triggered rules, data volume-triggered rules, and event signal-triggered rules. Upon receiving a data fingerprint, the smart contract notarization module determines whether any preset trigger rule in the notarization trigger rule set is met based on the current system state. If the determination is satisfied, it automatically calls the underlying blockchain interface to perform the notarization operation, specifically including: Time-triggered rule: When the time interval between the current system time and the time of the last successful execution of the notarization operation by the smart contract is greater than or equal to a preset time threshold, the notarization operation is triggered. Let the timestamp of the last successful evidence storage operation be . The current system time is The preset time threshold is Then the judgment condition of the time triggering rule can be expressed as: When the above inequality holds true, the smart contract notarization module determines that the time triggering rule is met.

[0044] Preferably, timestamp and All use block timestamps provided by the blockchain network. These timestamps are generated by the block-producing nodes according to the consensus mechanism and are trustworthy and immutable; preset time thresholds are also used. It can be configured according to the needs of actual application scenarios, such as 60 seconds, 300 seconds or 1800 seconds; when the data frequency generated by the data acquisition module is low or uneven, the time triggering rule can ensure that the data will not be indefinitely stuck in the cache area because it has not accumulated to the data volume threshold for a long time, thereby ensuring the timeliness limit of the evidence storage operation. It should be noted that the time-triggered rule check can be driven by an external timed call mechanism; that is, a timed scheduling service independent of the smart contract notarization module can be set up. This service sends a check request to the smart contract notarization module at preset time intervals (e.g., every ten seconds or every thirty seconds), triggering the smart contract notarization module to execute the time-triggered condition judgment logic. In this way, the timed wake-up function is placed off-chain, avoiding the complexity and resource consumption of implementing active timed logic inside the smart contract.

[0045] Data volume triggering rule: When the number of data fingerprints received but not yet uploaded to the chain in the temporary storage area inside the smart contract notarization module is greater than or equal to a preset threshold, the notarization operation is triggered. Let the number of data fingerprints accumulated in the current internal temporary storage area be . The preset quantity threshold is The criteria for triggering the data volume rule can be expressed as: When the above inequality holds, the smart contract notarization module determines that the data volume triggering rule is met. Preferably, a preset quantity threshold is used. It can be configured comprehensively based on actual business needs and blockchain transaction costs; for example, in log auditing scenarios, It can be set to ten or twenty; in high-frequency IoT data scenarios, to reduce the frequency of on-chain transactions and cumulative transaction fees, It can be set to one hundred, five hundred or higher values; the data volume trigger rule has advantages in scenarios with high data generation frequency, and can automatically collect and package multiple data fingerprints into one on-chain notarization transaction, effectively distributing the notarization cost of a single data item.

[0046] Event signal triggering rules: When the smart contract notarization module receives a specific notarization instruction signal with a preset priority identifier from an external system or internal module, the notarization operation is triggered; the specific notarization instruction signal is an independent function call that is different from the regular data fingerprint submission call, and its call message carries a preset priority identifier parameter; the preset priority identifier is used to indicate the urgency of the current notarization request; Preferably, the preset priority identifier includes two values: a normal priority identifier and an emergency priority identifier.

[0047] When the smart contract notarization module receives a notarization instruction signal carrying a normal priority identifier, its behavior is consistent with that when the time trigger rule or data volume trigger rule is met, that is, it executes the standard notarization operation process. When the smart contract notarization module receives a notarization instruction signal carrying an emergency priority identifier, the event signal triggering rule is further set as follows: the smart contract notarization module suspends the judgment of the time triggering rule and the data volume triggering rule, immediately reads all the temporarily stored data fingerprints in the current cache mapping table and the current data fingerprint that triggers the emergency priority identifier, and performs a one-time notarization and on-chain operation. This mechanism ensures that in the event of an emergency, such as a system security alarm, an equipment malfunction alarm, or a compliance audit spot check, the relevant data can be confirmed and solidified with a blockchain timestamp in the first instance, without being subject to the waiting delays of conventional batch collection strategies.

[0048] Specifically, in order to achieve efficient collaborative work among the various triggering rules and unified management of batch data fingerprints, the smart contract notarization module has a cache mapping table for temporarily storing data fingerprints to be uploaded to the blockchain and a state counter.

[0049] The cache mapping table is a key-value pair mapping data structure used to temporarily store data fingerprints received from the hash calculation module that have not yet been written into the blockchain ledger. The keys of the cache mapping table are auto-incrementing integer index values, with values ​​starting from zero and increasing sequentially. The values ​​of the cache mapping table are fixed-length byte arrays, the length of which is consistent with the output length of the cryptographic hash algorithm used.

[0050] Let the cache mapping table be Its domain is a subset of the set of natural numbers {0,1,2,…}, and its range is the value space of the data fingerprint, that is, the set of binary strings of length 256 bits. For the i-th data fingerprint that has been stored, denoted as F_i, it satisfies: , where i is the index number indicated by the current value of the status counter before it was written; The cache mapping table occupies a corresponding storage area in the persistent storage space of the smart contract notarization module. Since writing to the blockchain storage space requires computing resources, the cache mapping table is designed to clean up the processed entries after each successful notarization operation, so as to release storage space and reduce the storage writing overhead of subsequent operations.

[0051] The state counter is an unsigned integer state variable used to record in real time the number of data fingerprints that have been accumulated in the current cache mapping table but have not yet been put on the chain.

[0052] Let the state counter be Its initial value is zero. Whenever the aforementioned data fingerprint submission function is called and a data fingerprint is successfully written to the cache mapping table, the state counter increments, i.e.: Once the smart contract notarization module performs a notarization operation and completes the on-chain transaction sending, the status counter is reset to zero, indicating that the cache area has been cleared and is waiting for the next accumulation cycle.

[0053] Suppose that in the j-th cumulative cycle, the smart contract notarization module receives a total of If there is a data fingerprint, then within that period, the state counter... Incrementing gradually from zero to It is reset to zero after the evidence storage operation is performed.

[0054] Specifically, the smart contract notarization module provides a publicly callable data fingerprint submission function for the hash calculation module or other authorized callers. Once the hash calculation module generates a data fingerprint, it sends a function call transaction to the smart contract notarization module's contract address via the remote procedure call interface provided by the blockchain node, passing the data fingerprint as a call parameter.

[0055] The execution logic of the data fingerprint submission function is as follows: Step C1: Receive the data fingerprint parameter passed in by the caller. , It is a fixed-length byte array with a length of 256 bits; Step C2: Obtain the current value of the current state counter, denoted as... ; Step C3: Fingerprint the data The key to write to the cache mapping table is The storage location where the assignment operation is performed. ; Step C4: Set the state counter The value is updated to ; Step C5: Check whether the updated state counter value meets the judgment condition of the data volume triggering rule. That is, judge the inequality. ≥ If the condition is met, the internal evidence storage execution function is called to start the evidence storage operation process; if the condition is not met, the current function call ends and the process waits for the subsequent triggering conditions to be met.

[0056] Specifically, when the smart contract notarization module determines that any preset trigger rule in the notarization trigger rule set is met, the notarization execution logic is activated, automatically calling the underlying blockchain interface to perform the notarization operation. The notarization execution logic includes the following steps: Step D1: Read all or part of the data fingerprints in the current cache mapping table. In standard execution mode, read the indexes in the cache mapping table from zero to... All data fingerprints constitute a data fingerprint sequence, denoted as ; Step D2: Data fingerprint sequence Perform a Merkel root hash calculation to obtain a Merkel root hash value. ; Step D3: Hash the Merkle tree root value The payload data for this evidence storage transaction, together with the associated metadata, is packaged into a single evidence storage transaction; the associated metadata includes, but is not limited to: the current batch identifier, the current block timestamp, and the caller's identity information; Step D4: Broadcast the notarized transaction to the blockchain network by calling the underlying blockchain interface, and write it into the blockchain ledger after confirmation through the consensus process; Step D5: Set the state counter Reset to zero and clear the processed data fingerprint entries in the cache mapping table; Step D6: Update the timestamp variable of the last successful evidence storage operation. The value is the timestamp of the current block.

[0057] Specifically, a Merkle tree is a tree-like data structure built on a cryptographic hash function. Its leaf nodes are the fingerprints of the data to be proven, and the value of each non-leaf node is the concatenated hash result of the values ​​of all its child nodes. The root hash value of the Merkle tree is the root node value of the tree structure, which can serve as a compact cryptographic proof of the integrity of the data in all its leaf nodes. Let the data fingerprint sequence to be processed be... Where k is the number of data fingerprints contained in the current batch, i.e. Merkel root hash value The calculation process is recursively defined as follows: (1) If k=0, that is, there are no fingerprints to be stored in the current batch, then the storage operation will not be performed.

[0058] (2) If k=1, that is, it contains only a single data fingerprint, then the Merkle root hash value is directly equal to the data fingerprint itself, that is: ; (3) If k>1, then construct a complete binary tree; first, use the data fingerprint sequence as the leaf node layer of the tree, denoted as If k is odd, then copy the last leaf node at the end to make an even number of nodes, i.e., let k = k. ; Then, perform hash calculations layer by layer upwards on the leaf node layer; let the node sequence of the j-th layer be... ,in The number of nodes in this layer; then the number of nodes in the (j+1)th layer. From its two child nodes at the next level The result, obtained by cryptographic hashing after concatenation, is: ; Here, H(·) represents a cryptographic hash function, and the symbol "‖" represents a concatenation operation of byte sequences; the above process is repeated until a certain layer contains only a single node. This unique node is the Merkle root hash value. .

[0059] Specifically, when the smart contract notarization module receives a notarization instruction signal carrying an urgent priority identifier, its processing flow is as follows: The smart contract notarization module provides a public function interface specifically for receiving urgent notarization requests. When an external system or internal monitoring module detects an abnormal event requiring immediate notarization, it calls this function interface and sends the current data fingerprint that triggered the urgent notarization request. Passed as a parameter; When the emergency evidence storage function is called, the smart contract evidence storage module executes the following emergency evidence storage logic: Step E1: Suspend the judgment of time-triggered rules and data volume-triggered rules; that is, during the emergency evidence storage execution period, the judgment of regular triggering conditions is not performed, nor is the timed scheduling service triggered. Step E2: Read the fingerprints of all data that are temporarily stored but not yet uploaded to the chain in the current cache mapping table. Let the current state counter value be... The read data fingerprint sequence is ; Step E3: Obtain the current data fingerprint that triggered the emergency evidence storage request. Appended to the end of the data fingerprint sequence to form the data fingerprint sequence for the emergency batch. ; Step E4: Data fingerprint sequence for emergency batches Perform the Merkel root hash calculation as before to obtain the Merkel root hash value for the emergency batch. ; Step E5: Immediately call the underlying blockchain interface to include the Merkle root hash value. And the notarized transaction broadcast of associated metadata; Step E6: Set the state counter Reset to zero and clear the cache mapping table.

[0060] Step E7: Update the timestamp variable of the last successful evidence storage operation. The value is the timestamp of the current block; Furthermore, after the notarized transaction constructed by the smart contract notarization module is broadcast to the blockchain network, it is verified and processed by the consensus nodes in the network. In a blockchain network that adopts consensus mechanisms such as proof-of-work, proof-of-stake, or practical Byzantine fault tolerance, the notarized transaction is considered to be finally confirmed after it is included in a valid block and receives confirmation from a sufficient number of subsequent blocks. The evidence storage monitoring and feedback module obtains the transaction hash, block height, and block timestamp corresponding to the event by acquiring the event's occurrence, and then generates evidence storage certificates and triggers the subsequent feedback process.

[0061] In a specific embodiment, the evidence storage monitoring and feedback module is the output component of the system responsible for confirming the evidence storage result and providing feedback on the certificate. The first end of the evidence storage monitoring and feedback module is connected to the blockchain network to obtain the confirmation status of the evidence storage transaction in the blockchain network. The second end of the evidence storage monitoring and feedback module is connected to the local log database associated with the data acquisition module to write back the on-chain evidence storage information to local storage to establish a traceable association. The third end of the evidence storage monitoring and feedback module is connected to the preset receiving end to provide feedback on the generated evidence storage certificate to the user or the upper-layer business system. The evidence storage monitoring and feedback module is used to obtain evidence storage events issued by the smart contract evidence storage module on the blockchain network. After confirming that the evidence storage transaction has been successfully uploaded to the chain, it generates an evidence storage certificate containing the transaction hash and a trusted timestamp, and feeds the evidence storage certificate back to the preset receiving end. The evidence storage monitoring and feedback module can be deployed on a separate monitoring server, or it can be deployed on the same computing node as the data acquisition module or hash calculation module. In a distributed deployment architecture, the evidence storage monitoring and feedback module runs continuously as an independent background service program, maintaining a stable network connection with the blockchain node.

[0062] Specifically, when performing the notarization operation, the smart contract notarization module writes the notarization information into the blockchain ledger by issuing an event log in a predefined format; preferably, the event log is named EvidenceStored, and the parameters it contains have been defined in the specific implementation of the aforementioned smart contract notarization module; the notarization monitoring and feedback module listens to the event log records issued by the contract address of the smart contract notarization module whose event signatures match the EvidenceStored event. The evidence storage monitoring and feedback module monitors blockchain events using one of the following two methods: Event Subscription Mode: The evidence storage monitoring and feedback module establishes a persistent connection with any full node in the blockchain network based on the WebSocket protocol or the Transmission Control Protocol, and sends an event subscription request to that node. The subscription request specifies the filtering conditions for the events to be monitored, including but not limited to: contract address, event signature hash value, and optional index parameter filtering conditions. When the blockchain network generates a new block and the block contains event logs that meet the filtering conditions, the blockchain node actively pushes the event logs and their associated transaction information to the evidence storage monitoring and feedback module. This mode has the advantages of strong real-time response and low network overhead. Block polling mode: If the blockchain node does not support the event subscription function, the evidence storage monitoring and feedback module can adopt a timed polling method; the evidence storage monitoring and feedback module sends a request to the blockchain node according to the preset polling interval (e.g., every five seconds or every ten seconds) to query the log records within the range of newly generated blocks since the last query of the block height, and filters and matches them according to the contract address and event signature; this mode has good compatibility, but its real-time performance is lower than that of the event subscription mode; Preferably, the evidence storage monitoring and feedback module prioritizes the event subscription mode and configures a polling mode as a backup mechanism. When the event subscription connection is abnormally interrupted, it automatically switches to the polling mode and switches back to the subscription mode after the connection is restored, so as to ensure the continuity and reliability of the monitoring.

[0063] Specifically, after the evidence storage monitoring and feedback module detects the EvidenceStored event, it does not immediately conclude that the evidence storage operation has been successfully completed. Instead, it further determines the confirmation status of the evidence storage transaction based on the characteristics of the consensus mechanism adopted by the blockchain network.

[0064] Suppose the notarized transaction is included in a block of height H_block. The notarization monitoring and feedback module maintains the latest block height of the current blockchain network. The number of block confirmations currently obtained for the evidence storage transaction satisfy: The evidence storage monitoring and feedback module has a preset confirmation threshold. The notarized transaction is deemed to have been successfully uploaded to the blockchain and received final confirmation when the following inequalities are satisfied: ; Confirmation threshold The threshold for confirmation depends on the specific characteristics of the blockchain network. For public blockchain networks that use a proof-of-work consensus mechanism, the confirmation threshold is usually set to six to twelve blocks to ensure that the probability of a transaction being reversed is reduced to an acceptablely low level. For consortium blockchain networks that use deterministic consensus mechanisms such as practical Byzantine fault tolerance, since a transaction is finalized once it is written into a block, the confirmation threshold can be set to zero or one. While waiting for sufficient block confirmations for the evidence storage transactions, the evidence storage monitoring and feedback module temporarily stores the evidence storage records to be confirmed in an in-memory waiting queue, and continuously updates the confirmation count of each record as new blocks are generated. When the confirmation count of a certain evidence storage record reaches the confirmation count threshold, the record is marked as confirmed and enters the subsequent certificate generation and feedback processing flow.

[0065] Specifically, once the evidence monitoring and feedback module confirms that the evidence transaction has been successfully uploaded to the blockchain, the process of generating the evidence certificate is initiated. The evidence certificate is an electronic certificate issued to the user or the upper-level business system to prove that specific data has been stored and solidified through the blockchain at a specific point in time. The evidence storage certificate generated by the evidence storage monitoring and feedback module should contain at least the following information items: Transaction hash: A unique identifier for a notarized transaction within the blockchain network, typically represented as a 64-character hexadecimal string (corresponding to a 32-byte binary hash value); the transaction hash is assigned by the blockchain network during transaction broadcasting and can be used to retrieve and verify the transaction details in a blockchain explorer. Trusted timestamp: The time when a notarized transaction is written into the blockchain ledger; this timestamp comes from the timestamp field in the block header of the notarized transaction; since the block timestamp is generated by the block-producing node according to consensus rules and confirmed by network consensus, it has the characteristics of being immutable and verifiable, and constitutes a trusted timestamp in a legal sense. Batch Identifier: The batch identifier batchId obtained from the EvidenceStored event parameters is used to identify the batch number corresponding to this evidence storage operation; Merkle root hash: The Merkle root hash value merkleRoot obtained from the EvidenceStored event parameters serves as the cryptographic digest proof of all data fingerprints in this batch of evidence storage; Block height: The block height H_block of the transaction where the evidence is stored, used to quickly locate the transaction's position in the blockchain ledger; Data volume for evidence storage: The number of data fingerprints included in this batch of evidence storage operations; this information can be obtained by querying the internal state of the smart contract evidence storage module or by parsing event association information; Voucher generation time: The system time when the evidence storage monitoring and feedback module generated the voucher; Unique identifier for the certificate: A unique identifier assigned to each certificate for the management and retrieval of the certificate; Furthermore, the evidence storage certificates generated by the evidence storage monitoring and feedback module can be represented and transmitted in multiple formats to meet the needs of different receiving ends: Structured text format: The above information items are organized in JSON format to form machine-readable structured voucher data; this format facilitates automated parsing and processing by upper-level business systems; Human-readable text format: The voucher content is organized in Markdown or plain text format, including formatted headings, paragraphs and key information highlighting, suitable for sending notification messages to administrators via instant messaging tools; Electronic document format: As needed, the evidence can be rendered into a portable document format and stamped with an electronic signature, serving as a legally valid formal evidence document.

[0066] Specifically, after generating the evidence storage certificate, the evidence storage monitoring and feedback module sends the certificate back to the preset receiving end. The preset receiving end can be configured as one or more of the following types of receiving targets, depending on the actual application scenario: The evidence storage monitoring and feedback module can be configured with one or more network hook addresses of instant messaging robots as preset receiving ends; after the evidence storage certificate is generated, the evidence storage monitoring and feedback module will encapsulate the certificate content according to the message format supported by the instant messaging platform and send it to the network hook address via the Hypertext Transfer Protocol. Optionally, in scenarios requiring deep integration with upper-layer business systems, the evidence storage monitoring and feedback module can send the generated evidence storage certificate in JSON format to a specified message queue topic; the business system, as a message consumer, retrieves the evidence storage certificate from the message queue topic and automatically updates the evidence storage status field of the corresponding record in the business database based on the batch identifier and data fingerprint information in the certificate. Optionally, the evidence storage monitoring and feedback module supports sending Hypertext Transfer Protocol requests to pre-registered callback Uniform Resource Locator addresses, pushing the evidence storage certificate as the request body to external systems. This method achieves near real-time callback notification of evidence storage results and is suitable for scenarios that require close linkage between evidence storage status and business processes. Optionally, the evidence storage monitoring and feedback module can also persistently store the generated evidence storage certificates in the form of files in a specified directory as local archive records of the evidence storage operation, which facilitates subsequent offline auditing and retrieval.

[0067] In other embodiments, the evidence storage monitoring and feedback module is also used to write the transaction hash and trusted timestamp into the local log database associated with the data collection module after the evidence storage transaction is confirmed on the chain, thereby establishing a traceable association between the local original data record and the on-chain evidence storage record.

[0068] Based on the descriptions of the components above, the evidence storage monitoring and feedback module executes the following workflow in a complete evidence storage monitoring and feedback task: Step G1: When the system starts, initialize the connection with the blockchain node, establish event subscription or configure polling timer tasks, and load the last processing status information stored locally. Step G2: Continuously monitor the EvidenceStored event emitted by the smart contract notarization module in the blockchain network; Step G3: When the EvidenceStored event is captured, parse the following information from the event log and the associated transaction receipt: batch identifier, Merkle root hash value, block timestamp, transaction hash, and block height; Step G4: Add the parsed evidence records to the waiting queue for confirmation, and continuously update the block confirmation count of each record to be confirmed according to the latest block height of the current blockchain network; Step G5: When the number of block confirmations for a certain evidence storage record reaches the preset confirmation threshold, it is determined that the evidence storage transaction has been finally confirmed. Step G6: Determine the range of data fingerprints included in this batch of evidence storage based on the batch identifier, connect to the local log database, update the associated binding fields of the corresponding data records, and establish a traceable association between the local original data and the on-chain evidence storage records; Step G7: Generate a certificate of evidence storage. The certificate of evidence storage includes information such as transaction hash, trusted timestamp, batch identifier, Merkle root hash value, block height, and amount of evidence storage data. Step G8: Send the generated evidence to one or more preset receiving terminals according to the preset feedback method, including instant messaging notification, message queue push, application programming interface callback or local file storage; Step G9: Persist the final block height or other state information of this process to local storage for restoring the processing progress on the next startup.

[0069] In a specific embodiment, the evidence verification module is a functional component in the system used for post-event data verification and confirmation of evidentiary validity. The evidence verification module runs independently of the main evidence storage process and can be called by users, third-party auditing institutions or upper-level business systems at any time to verify whether a certain piece of data to be verified has indeed been stored on the blockchain through this system, and whether the data has remained intact and untampered since it was stored. The first input terminal of the evidence verification module receives the data to be verified, which can be an electronic file uploaded by the user, a record in the business system database, or any form of electronic data content. The second terminal of the evidence verification module communicates with the hash calculation module to invoke the cryptographic hash calculation function, which is exactly the same as the original evidence preservation process. The third terminal of the evidence verification module communicates with the smart contract evidence preservation module in the blockchain network to invoke the on-chain query interface provided by the smart contract evidence preservation module to retrieve evidence records in the blockchain ledger.

[0070] Specifically, the evidence verification module provides a unified verification service interface, allowing users or external systems to submit data to be verified in the following ways: File upload method: Users upload the electronic files to be verified in binary form to the evidence verification module through a web interface or application programming interface. Text input method: Users can directly paste or enter the text to be verified on the verification interface.

[0071] Data record identification method: For data already stored in the local database, the user can provide a unique identifier for the data record. The evidence verification module will then extract the corresponding data content from the local database based on the identifier for verification. To ensure the accuracy of the verification results, the data to be verified must undergo the same preprocessing process as the original evidence before entering the hash operation step. After the above preprocessing process, a standardized data packet to be verified with the same format as the original evidence is generated. The evidence storage and verification module transmits the preprocessed standardized data packet to be verified to the hash calculation module, which calls the cryptographic hash operation function that is exactly the same as the original evidence storage process to generate the fingerprint of the data to be verified. The evidence verification module calls the on-chain query interface provided by the smart contract evidence storage module to search the blockchain ledger for the existence of a fingerprint matching the data to be verified. Consistent historical evidence records; depending on whether the user can provide auxiliary location information, the retrieval method is divided into the following two scenarios: Fast verification using known batch identifiers: If a user provides the corresponding batch identifier (batchId) when submitting data to be verified (e.g., obtained through a local database query), the verification module directly performs verification operations on that specific batch. The verification process only requires confirmation. Whether it is included in the batch of evidence records, the retrieval efficiency is relatively high.

[0072] Full retrieval of unknown batch identifiers: If the user only submits data to be verified without providing any auxiliary location information, the evidence verification module needs to traverse all historical evidence batch records of the smart contract evidence storage module and judge them sequentially. Does it exist in a certain batch of evidence storage records? To improve retrieval efficiency, the evidence storage verification module can maintain an on-chain evidence storage batch index database locally, pre-synchronize the data fingerprint range or Bloom filter contained in each batch to the local database, complete the initial screening locally, and then perform precise on-chain verification. To elaborate further, the smart contract notarization module only stores the Merkle root hash values ​​of multiple data fingerprints during the notarization process. Instead of recording each data fingerprint individually on the blockchain ledger, the data is written to the blockchain ledger. Therefore, verifying a specific data fingerprint... Whether something belongs to a particular batch of evidence needs to be determined through the Merkel proof mechanism.

[0073] Let the batch identifier to be verified be batchId. The evidence storage record corresponding to this batch contains k data fingerprints, and its Merkle root hash value is... ,verify The process for determining whether something belongs to this batch is as follows: Step H1: Obtain the batch The corresponding Merkel proof path is a sequence of hash values, denoted as . Where m is the length of the proof path, satisfying Prove each element in the path , for from The hash value of the sibling node required for the leaf node to reach the root node of the Merkle tree.

[0074] Step H2: From Starting from the path P, calculate the hash values ​​of intermediate nodes layer by layer upwards until a root hash value is obtained. The calculation process is recursively defined as follows: Let the current calculated hash value be... ; for ,according to The position index in the tree determines the left and right order of sibling nodes, and the hash value of the next level is calculated. : like The path position indicates that the sibling node is on the right. ;like The path position indicates that the sibling node is on the left. Where H(·) is the SHA-256 hash function, and the symbol "‖" represents the concatenation operation of byte sequences. After m rounds of calculation, the root hash value is obtained. .

[0075] Step H3: Calculate the root hash value Compared with the Merkel tree root hash value stored on the blockchain Perform a comparison. If the two are equal bit by bit, then... Then prove It is indeed a record belonging to this batch; otherwise, proof It does not belong to this batch or the provided proof path is incorrect.

[0076] The above-mentioned verification method based on Merkel proof makes the computational complexity of the verification process logarithmically related to the batch size k. Even if a batch of evidence contains tens of thousands of data fingerprints, the verification process only needs to perform dozens of hash operations, which has extremely high verification efficiency. Then, based on the results of on-chain retrieval and verification, the evidence verification module generates and outputs a verification result report in a standard format. In practical implementation, an automated blockchain evidence storage method applied to the aforementioned automated blockchain evidence storage system combined with smart contracts includes the following steps: Step S1: Obtain the original data to be stored through the data acquisition module, and perform format standardization and content preprocessing on the original data to obtain a standardized data packet; Step S2: Perform cryptographic hash operations on the standardized data packet using the hash calculation module to generate a unique corresponding data fingerprint; Step S3: Send the data fingerprint to the smart contract notarization module deployed in the blockchain network. The smart contract notarization module determines whether the current system state meets any of the preset triggering rules according to its internal preset notarization triggering rule set. Step S4: When it is determined that the preset triggering rule is met, the smart contract notarization module automatically calls the underlying blockchain interface to package at least one data fingerprint and associated metadata currently accumulated into a notarization transaction, and broadcasts the notarization transaction to the blockchain network for consensus confirmation. Step S5: Obtain the confirmation status of the evidence storage transaction in the blockchain network through the evidence storage monitoring and feedback module. After obtaining the transaction hash and block confirmation information corresponding to the evidence storage transaction, generate an evidence storage certificate containing the transaction hash and trusted timestamp, and feed the evidence storage certificate back to the preset receiving end.

[0077] This invention discloses an automated blockchain evidence storage system incorporating smart contracts. Through the collaborative work of a data acquisition module, a hash calculation module, a smart contract evidence storage module, and an evidence storage monitoring and feedback module, the system achieves fully automated evidence storage throughout the entire process. No manual login, uploading, or confirmation is required, significantly improving efficiency. The system features a flexible triggering mechanism driven by smart contracts, embedding evidence storage triggering rules within the smart contracts and supporting combinations of various rules such as time-based triggering, data volume triggering, and event signal triggering. The smart contracts automatically determine the evidence storage timing based on the system status, decoupling the evidence storage logic from the business logic. The system also implements data privacy protection and on-chain storage optimization. A data desensitization unit desensitizes sensitive fields before hash calculation, ensuring that the data fingerprint uploaded to the blockchain does not reveal the original data. Prioritizing data privacy, the system employs Merkle root hashing as the payload for batch notarization, compressing multiple data fingerprints into a single fixed-length hash value for on-chain storage, significantly reducing blockchain storage overhead and transaction fees. The system features rapid response capabilities for emergency notarization, incorporating an emergency priority identification mechanism for abnormal events or high-priority notarization needs. When a smart contract receives an instruction signal carrying an emergency identifier, it immediately suspends the waiting logic of the regular trigger rules, instantly uploading and solidifying all currently cached notarized data onto the blockchain, ensuring that critical evidence data receives immutable timestamp proof immediately. The system also boasts closed-loop verification and traceability; the notarization monitoring and feedback module writes on-chain transaction hashes back to the local log database, establishing a one-to-one correspondence between local original data and on-chain notarization records. The notarization verification module supports independent verification of the data by any third party, requiring only hash value calculation and blockchain query to verify the data's authenticity, integrity, and notarization time, without relying on any centralized authority.

[0078] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. An automated blockchain-based evidence storage system incorporating smart contracts, characterized in that, include: The data acquisition module is used to collect raw data to be stored from a preset data source in real time or at regular intervals, and to perform format standardization and content preprocessing on the raw data to generate a standardized data packet. A hash calculation module is used to connect to the data acquisition module to perform cryptographic hash operations on the standardized data packets, thereby generating a unique corresponding data fingerprint. The smart contract notarization module is set up in the blockchain network and has embedded notarization triggering rule set and notarization execution logic. The notarization triggering rule set includes several different types of notarization triggering rules. After receiving the data fingerprint, the smart contract notarization module is used to determine whether any preset triggering rule in the notarization triggering rule set is satisfied based on the current system state. When the determination is satisfied, it automatically calls the underlying blockchain interface to package the data fingerprint and associated standardized data packet into notarization transaction and write it into the blockchain ledger. The evidence storage monitoring and feedback module is used to obtain the confirmation status of the evidence storage transaction in the blockchain network, and after confirming that the evidence storage transaction has been successfully uploaded to the chain, generate an evidence storage certificate containing a transaction hash and a trusted timestamp, and feed the evidence storage certificate back to the preset receiving end.

2. The automated blockchain evidence storage system combining smart contracts according to claim 1, characterized in that, The data acquisition module includes a data desensitization unit, which is used to identify sensitive fields in the original data and replace, mask, or encrypt the sensitive fields according to a preset desensitization strategy. The hash calculation module is specifically used to perform hash operations on the standardized data packets processed by the data desensitization unit.

3. The automated blockchain evidence storage system combining smart contracts according to claim 2, characterized in that, The data desensitization unit is equipped with a sensitive field identification engine based on a machine learning classification model, and a desensitization strategy library containing at least one desensitization algorithm mapping table; the desensitization algorithm mapping table records the association between different sensitive field types and their corresponding desensitization algorithms.

4. The automated blockchain evidence storage system combining smart contracts according to claim 1, characterized in that, The evidence storage triggering rule set in the smart contract evidence storage module includes at least two of the following: time-triggered rules, data volume-triggered rules, and event signal-triggered rules. Specifically: The time triggering rule is preset to be: when the time interval between the current system time and the time of the last successful execution of the evidence storage operation by the smart contract is greater than or equal to a preset time threshold, the evidence storage operation is triggered. The data volume triggering rule is preset to be: when the number of data fingerprints received but not yet uploaded to the chain in the temporary storage area inside the smart contract notarization module is greater than or equal to a preset number threshold, the notarization operation is triggered. The event signal triggering rule is preset to be: when the smart contract notarization module receives a specific notarization instruction signal with a preset priority identifier from an external system or internal module, the notarization operation is triggered.

5. The automated blockchain evidence storage system combining smart contracts according to claim 4, characterized in that, The smart contract notarization module is equipped with a cache mapping table and a status counter for temporarily storing fingerprints of data to be uploaded to the blockchain. After receiving the data fingerprint, the smart contract notarization module first writes the data fingerprint into the cache mapping table and increments the state counter. When performing notarization operations, the smart contract notarization module reads all or part of the data fingerprints in the cache mapping table, calculates the corresponding Merkle root hash value, and uploads the Merkle root hash value as the payload data for this notarization transaction to the blockchain.

6. The automated blockchain evidence storage system combining smart contracts according to claim 4, characterized in that, The event signal triggering rule is further set as follows: when the received evidence storage instruction signal carries an emergency priority identifier, the smart contract evidence storage module suspends the judgment of the time triggering rule and the data volume triggering rule, immediately reads all the temporarily stored data fingerprints in the current cache mapping table and the current data fingerprint that triggers the emergency priority identifier, and performs a one-time evidence storage and on-chain operation.

7. The automated blockchain evidence storage system combining smart contracts according to claim 1, characterized in that, The evidence storage monitoring and feedback module is also used to write the transaction hash and the trusted timestamp into the local log database associated with the data collection module after the evidence storage transaction is confirmed on the chain, thereby establishing a traceable association between the local original data record and the on-chain evidence storage record.

8. The automated blockchain evidence storage system combining smart contracts according to claim 1, characterized in that, It also includes an evidence verification module, which is used for: Receive the data to be verified, perform the same cryptographic hash operation on the data to be verified as that of the hash calculation module, and generate a fingerprint of the data to be verified. Call the on-chain query interface provided by the smart contract notarization module to search the blockchain ledger for whether there is a historical notarization record that matches the fingerprint of the data to be verified. If a consistent notarization record is found, the notarization transaction hash, block height, and notarization timestamp corresponding to that notarization record are extracted, and a verification result report containing the above information is output; if no notarization record is found, a prompt message indicating that the data has not been notarized or has been tampered with is output.

9. An automated blockchain evidence storage method applied to the automated blockchain evidence storage system combined with smart contracts as described in claims 1-8, characterized in that, Includes the following steps: Step S1: Obtain the original data to be stored through the data acquisition module, and perform format standardization and content preprocessing on the original data to obtain a standardized data packet; Step S2: Perform cryptographic hash operations on the standardized data packet using the hash calculation module to generate a unique corresponding data fingerprint; Step S3: Send the data fingerprint to the smart contract notarization module deployed in the blockchain network. The smart contract notarization module determines whether the current system state meets any of the preset triggering rules according to its internal preset notarization triggering rule set. Step S4: When it is determined that the preset triggering rule is met, the smart contract notarization module automatically calls the underlying blockchain interface to package at least one data fingerprint and associated metadata currently accumulated into a notarization transaction, and broadcasts the notarization transaction to the blockchain network for consensus confirmation. Step S5: Obtain the confirmation status of the evidence storage transaction in the blockchain network through the evidence storage monitoring and feedback module. After obtaining the transaction hash and block confirmation information corresponding to the evidence storage transaction, generate an evidence storage certificate containing the transaction hash and trusted timestamp, and feed the evidence storage certificate back to the preset receiving end.

Images