Data verification method and device based on block chain, equipment and medium

Abstract

The invention discloses a data verification method and device based on a block chain, equipment and a medium. A leaf hash value is calculated for any batch of source data sub-files of the data storage node, a Merkel root hash value and a corresponding Merkel proof path are generated, and a batch identifier, a data storage address, the Merkel root hash value and a generation timestamp are synchronized to a data index node through a log of a block chain technology; a data index node can obtain a Merkel proof path corresponding to a corresponding batch identifier from a data storage node, based on this, a verification client side calculates a local hash value for any target source data sub-file of a target batch identifier needing to be verified, and verifies the target source data sub-file according to a target Merkel proof path obtained from the data index node. And reconstructing the to-be-confirmed root hash value, comparing the to-be-confirmed root hash value with the target Merkel root hash value, and verifying the target source data sub-file of the target batch. And the authenticity and credibility of the data are ensured.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data verification method, apparatus, device, and medium based on blockchain. Background Technology

[0002] With the rapid development of IoT technology, massive amounts of smart devices are continuously generating high-frequency streaming data. This data is crucial for production efficiency monitoring, predictive equipment maintenance, and quality control, and is even a core asset for data transactions.

[0003] In related technologies, these data are typically stored in a centralized database, and the integrity and authenticity of the data are maintained by the operator of the centralized database.

[0004] However, for data storage methods that store data in centralized databases, if the centralized database is attacked from the outside, maliciously operated from within, or mismanaged, the data may be tampered with, affecting its authenticity. Since this data storage method cannot provide data verification, the data lacks credibility. Summary of the Invention

[0005] This application provides a blockchain-based data verification method, apparatus, device, and medium, which can verify any batch of data stored in advance to detect whether the data has been tampered with, and ensure the authenticity and credibility of the data.

[0006] Firstly, this application provides a blockchain-based data verification method applied to a data verification system, the data verification system comprising a verification client, a blockchain service node, a data storage node, and a data index node, including: The verification client obtains a list of data batches from the data index node and selects at least one target batch identifier from the list of data batches. The verification client determines the target data storage address corresponding to the target batch identifier, and downloads the corresponding target source data sub-file from the data storage node according to the target data storage address. The data storage node stores multiple data storage addresses corresponding to multiple data batches and multiple source data sub-files associated with each data storage address. The verification client calculates the local hash value of the target source data sub-file and obtains the corresponding target Merkle root hash value from the blockchain service node according to the target batch identifier; The verification client obtains the target Merkel proof path corresponding to the target batch identifier and the local hash value from the data index node, wherein the target Merkel proof path is obtained by the data index node from the data storage node according to the target batch identifier and the target data storage address; The verification client calculates the root hash value to be confirmed based on the target Merkel proof path and the local hash value; The verification client combines the root hash value to be confirmed with the target Merkle root hash value to verify the target source data sub-file.

[0007] In some implementations, the verification client calculates the root hash value to be confirmed based on the target Merkel proof path and the local hash value, including: The verification client determines the hash calculation path associated with the local hash value and multiple target-related hash values ​​corresponding to the hash calculation path based on the target Merkel proof path; Following the hash calculation path, a hash calculation is performed by combining the local hash value with the multiple target-related hash values ​​to obtain the root hash value to be confirmed.

[0008] In some implementations, the verification client combines the root hash value to be verified with the target Merkle root hash value to verify the target source data sub-file, including: The verification client compares the root hash value to be confirmed with the target Merkle root hash value to obtain the comparison result; When the comparison result shows that the root hash value to be confirmed is consistent with the target Merkel root hash value, it is determined that the verification of the target source data sub-file has passed. When the comparison result shows that the root hash value to be confirmed is inconsistent with the target Merkle root hash value, it is determined that the verification of the target source data sub-file fails.

[0009] In some embodiments, the data verification system further includes a data acquisition node and a data processing node, and the method further includes: The data acquisition node acquires the source dataset and corresponding batch identifier of the same data batch according to the preset data batch range, and divides the source dataset into multiple source data sub-files, each source data sub-file corresponding to a file identifier; The data processing node calculates the corresponding leaf hash value for each source data sub-file, combines the leaf hash values ​​of each source data sub-file to generate the Merkel root hash value and the Merkel proof path, and obtains the generation timestamp. The data processing node combines the generation timestamp, the batch identifier, the Merkel root hash value, the Merkel proof path, multiple leaf hash values, and multiple file identifiers to construct a metadata file, and sends the multiple source data sub-files and the metadata file to the data storage node for storage, so as to obtain the data storage address corresponding to the batch identifier; The data processing node sends the batch identifier, the Merkle root hash value, the data storage address, and the generation timestamp to the blockchain service node, so that the blockchain service node triggers the generation of data storage logs based on the batch identifier, the Merkle root hash value, the data storage address, and the generation timestamp; When the data index node detects the data storage log generated by the blockchain service node, it maps the batch identifier, Merkle root hash value, data storage address, generation timestamp, transaction hash, block identifier, and block timestamp obtained from parsing the data storage log into the database table structure to establish a data query index.

[0010] In some implementations, the verification client obtains a list of data batches from the data index node, including: The verification client sends a batch information query request through the metadata query interface provided by the data index node; The data index node responds to the batch information query request and generates a data batch list based on multiple batch information in the database table structure; The verification client receives the data batch list returned by the data index node through the batch query interface provided by the data index node.

[0011] In some implementations, before the verification client determines the target data storage address corresponding to the target batch identifier and downloads the corresponding target source data sub-file from the data storage node based on the target data storage address, the method further includes: The data index node reads the corresponding metadata file from the data storage node based on the batch identifier and the data storage address; Based on the metadata file, obtain multiple file identifiers corresponding to the multiple source data sub-files associated with the batch identifier.

[0012] In some implementations, the verification client determines the target data storage address corresponding to the target batch identifier, and downloads the corresponding target source data sub-file from the data storage node according to the target data storage address, including: The verification client sends a file identifier retrieval request through the metadata query interface provided by the data index node; The data index node determines the corresponding target metadata file based on the target batch identifier in the file identifier acquisition request, and reads the corresponding target data storage address and multiple file identifiers according to the target metadata file; The verification client receives the target data storage address and the multiple file identifiers returned by the data index node through the metadata query interface provided by the data index node, and selects a target file identifier from the multiple file identifiers; The verification client downloads the target source data sub-file corresponding to the target file identifier from the data storage node according to the target data storage address.

[0013] Secondly, this application provides a blockchain-based data verification system, which includes a verification client, a blockchain service node, a data storage node, a data index node, a data acquisition node, and a data processing node, comprising: The data acquisition node acquires the source dataset and corresponding batch identifier of the same data batch according to the preset data batch range, and divides the source dataset into multiple source data sub-files, each source data sub-file corresponding to a file identifier; The data processing node calculates the corresponding leaf hash value for each source data sub-file, combines the leaf hash values ​​of each source data sub-file to generate the Merkel root hash value and the Merkel proof path, and obtains the generation timestamp. The data processing node combines the generation timestamp, the batch identifier, the Merkel root hash value, the Merkel proof path, multiple leaf hash values, and multiple file identifiers to construct a metadata file, and sends the multiple source data sub-files and the metadata file to the data storage node for storage, so as to obtain the data storage address corresponding to the batch identifier; The data processing node sends the batch identifier, the Merkle root hash value, the data storage address, and the generation timestamp to the blockchain service node, so that the blockchain service node triggers the generation of data storage logs based on the batch identifier, the Merkle root hash value, the data storage address, and the generation timestamp; When the data index node detects the data storage log generated by the blockchain service node, it maps the batch identifier, Merkle root hash value, data storage address, generation timestamp, transaction hash, block identifier and block timestamp obtained from parsing the data storage log into the database table structure to establish a data query index. The verification client obtains a list of data batches from the data index node and selects at least one target batch identifier from the list of data batches. The verification client determines the target data storage address corresponding to the target batch identifier, and downloads the corresponding target source data sub-file from the data storage node according to the target data storage address; The verification client calculates the local hash value of the target source data sub-file and obtains the corresponding target Merkle root hash value from the blockchain service node according to the target batch identifier; The verification client obtains the target Merkel proof path corresponding to the target batch identifier and the local hash value from the data index node; The verification client calculates the root hash value to be confirmed based on the target Merkel proof path and the local hash value; The verification client combines the root hash value to be confirmed with the target Merkle root hash value to verify the target source data sub-file.

[0014] Thirdly, this application provides a blockchain-based data verification device applied to a verification client in a data verification system. The data verification system further includes a blockchain service node, a data storage node, and a data index node, comprising: The first acquisition unit is used to acquire a data batch list from the data index node and select at least one target batch identifier from the data batch list; The download unit is used to determine the target data storage address corresponding to the target batch identifier, and download the corresponding target source data sub-file from the data storage node according to the target data storage address, wherein the data storage node stores multiple data storage addresses corresponding to multiple data batches and multiple source data sub-files associated with each data storage address; The first computing unit is used to calculate the local hash value of the target source data sub-file and to obtain the corresponding target Merkle root hash value from the blockchain service node according to the target batch identifier; The second acquisition unit is used to acquire the target Merkel proof path corresponding to the target batch identifier and the local hash value from the data index node; The second calculation unit is used to calculate the root hash value to be confirmed based on the target Merkel proof path and the local hash value; The verification unit is used by the verification client to verify the target source data sub-file by combining the root hash value to be confirmed with the target Merkle root hash value.

[0015] In some embodiments, the second computing unit is further configured to: Based on the target Merkel proof path, determine the hash calculation path associated with the local hash value and multiple target-related hash values ​​corresponding to the hash calculation path; Following the hash calculation path, a hash calculation is performed by combining the local hash value with the multiple target-related hash values ​​to obtain the root hash value to be confirmed.

[0016] In some implementations, the verification unit is further configured to: The root hash value to be confirmed is compared with the target Merkel root hash value to obtain the comparison result; When the comparison result shows that the root hash value to be confirmed is consistent with the target Merkel root hash value, it is determined that the verification of the target source data sub-file has passed. When the comparison result shows that the root hash value to be confirmed is inconsistent with the target Merkle root hash value, it is determined that the verification of the target source data sub-file fails.

[0017] In some embodiments, the first acquiring unit is further configured to: The data index node sends a batch information query request through its metadata query interface, and the data index node responds to the batch information query request to generate a data batch list based on multiple batch information in the database table structure. The data batch list returned by the data index node is received through the batch query interface provided by the data index node.

[0018] In some embodiments, the download unit is further configured to: The data index node sends a file identifier retrieval request through the metadata query interface provided by the data index node. Based on the target batch identifier in the file identifier retrieval request, the data index node determines the corresponding target metadata file and reads the corresponding target data storage address and multiple file identifiers according to the target metadata file. The system receives the target data storage address and the plurality of file identifiers returned by the data index node through the metadata query interface provided by the data index node, and selects a target file identifier from the plurality of file identifiers. Based on the target data storage address, download the target source data sub-file corresponding to the target file identifier from the data storage node.

[0019] Furthermore, this application also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the aforementioned blockchain-based data verification method.

[0020] Furthermore, embodiments of this application also provide a computer-readable storage medium storing a plurality of instructions adapted for loading by a processor to execute the aforementioned blockchain-based data verification method.

[0021] This application embodiment applies to a data verification system, which includes a verification client, a blockchain service node, a data storage node, and a data index node. The verification client obtains a data batch list from the data index node and selects at least one target batch identifier from the data batch list. The verification client determines the target data storage address corresponding to the target batch identifier and downloads the corresponding target source data sub-file from the data storage node according to the target data storage address. The data storage node stores multiple data storage addresses corresponding to multiple data batches and multiple source data sub-files associated with each data storage address. The verification client calculates a local hash value for the target source data sub-file and obtains the corresponding target Merkle root hash value from the blockchain service node according to the target batch identifier. The verification client obtains the target Merkle proof path corresponding to the target batch identifier and the local hash value from the data index node. The target Merkle proof path is obtained by the data index node from the data storage node according to the target batch identifier and the target data storage address. The verification client calculates the root hash value to be confirmed based on the target Merkle proof path and the local hash value. The verification client combines the root hash value to be confirmed and the target Merkle root hash value to verify the target source data sub-file. In this way, the client can download the corresponding target source data sub-file from the data storage node, calculate the local hash value for the target source data sub-file, and calculate the root hash value to be confirmed by combining the local hash value with the obtained target Merkel proof path. The target source data sub-file is then verified by comparing the target Merkel root hash value with the root hash value to be confirmed, in order to determine whether the source data sub-files of the corresponding batch have been tampered with, thus ensuring the authenticity and credibility of the data.

[0022] As can be seen from the above, compared to data storage methods in related technologies, centralized databases are susceptible to data tampering due to external attacks, internal malicious attacks, or management errors, affecting data authenticity. Furthermore, this data storage method lacks data verification, resulting in a lack of data credibility. In contrast, this application calculates leaf hash values ​​for any batch of source data sub-files on pre-stored value data storage nodes, generating Merkle root hash values ​​and corresponding Merkle proof paths. This is achieved by synchronizing the batch identifier, data storage address, Merkle root hash value, and generation timestamp to the data index node via blockchain technology logs. Merkel proof paths corresponding to the batch identifiers can be obtained from the data storage nodes. Based on this, the verification client calculates a local hash value for any target source data sub-file of the target batch identifier to be verified, and reconstructs the root hash value to be confirmed according to the target Merkel proof path obtained from the data index node. Then, the root hash value to be confirmed is compared with the target Merkel root hash value. This realizes the verification of the target source data sub-files of the target batch previously stored on the data storage nodes according to blockchain technology. In this way, data verification is performed on any batch of data stored in advance to detect whether the data has been tampered with, and to ensure the authenticity and credibility of the data. Attached Figure Description

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

[0024] Figure 1 This is a schematic diagram of a blockchain-based data verification system provided in an embodiment of this application. Figure 2 An example architecture diagram of a blockchain-based data verification system provided in this application embodiment; Figure 3 A flowchart illustrating the steps of the blockchain-based data verification method provided in this application embodiment; Figure 4 This is a structural example diagram of the hash calculation path provided in the embodiments of this application; Figure 5 This is a schematic diagram of the structure of a blockchain-based data verification device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the terminal structure provided in the embodiments of this application; Figure 7 This is a schematic diagram of the server structure provided in an embodiment of this application. Detailed Implementation

[0025] To enable those skilled in the art to better understand the solutions of this application, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, other embodiments obtained by those skilled in the art without creative effort are all within the scope of protection of this application.

[0026] It is understood that, in the specific implementation of this application, data such as data batch list, target batch identifier, target data storage address, target source data sub-file, local hash value, target Merkle root hash value, and target Merkle proof path are involved. When the above embodiments of this application are applied to specific products or technologies, permission or consent from the target is required, and the collection, use and processing of related data must comply with relevant laws, regulations and standards.

[0027] Furthermore, when this application embodiment needs to obtain relevant data, it will obtain separate permission or separate consent for data such as data batch list, target batch identifier, target data storage address, target source data sub-file, local hash value, target Merkle root hash value, and target Merkle proof path through pop-up windows or redirection to a confirmation page. After clearly obtaining separate permission or separate consent for the relevant data such as data batch list, target batch identifier, target data storage address, target source data sub-file, local hash value, target Merkle root hash value, and target Merkle proof path, it will then obtain the necessary data for this application embodiment to operate normally.

[0028] It should be noted that while some processes described in the specification, claims, and accompanying drawings include multiple steps appearing in a specific order, it should be clearly understood that these steps may not be performed in the order they appear herein, or may be performed in parallel. The step numbers are merely used to distinguish different steps and do not represent any execution order. Furthermore, descriptions such as "first," "second," or "objective" in this document are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0029] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, other embodiments obtained by those skilled in the art without creative effort are all within the scope of protection of this application.

[0030] This application provides a blockchain-based data verification method, apparatus, device, and medium. Specifically, the blockchain-based data verification method of this application can be implemented in a computer device, which can be a server or a user terminal device. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The user terminal device can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, smart home appliance, vehicle terminal, smart voice interaction device, aircraft, drone, etc., but is not limited to these.

[0031] For ease of understanding, this application will describe the implementation process of the blockchain-based data verification method through several embodiments, as follows: This application provides a blockchain-based data verification method applied to a data verification system. The data verification system includes a verification client, a blockchain service node, a data storage node, and a data index node. The verification client obtains a data batch list from the data index node and selects at least one target batch identifier from the data batch list. The verification client determines the target data storage address corresponding to the target batch identifier and downloads the corresponding target source data sub-file from the data storage node according to the target data storage address. The data storage node stores multiple data storage addresses corresponding to multiple data batches and multiple source data sub-files associated with each data storage address. The verification client calculates a local hash value for the target source data sub-file and obtains the corresponding target Merkle root hash value from the blockchain service node according to the target batch identifier. The verification client obtains a target Merkle proof path corresponding to the target batch identifier and the local hash value from the data index node. The target Merkle proof path is obtained by the data index node from the data storage node according to the target batch identifier and the target data storage address. The verification client calculates a root hash value to be confirmed based on the target Merkle proof path and the local hash value. The verification client combines the root hash value to be confirmed and the target Merkle root hash value to verify the target source data sub-file. In this way, the client can download the corresponding target source data sub-file from the data storage node, calculate a local hash value for the target source data sub-file, and combine the local hash value with the obtained target Merkel proof path to calculate the root hash value to be confirmed. By comparing the target Merkel root hash value with the root hash value to be confirmed, the target source data sub-file is verified to determine whether the source data sub-files in the corresponding batch have been tampered with, ensuring the authenticity and credibility of the data. Please refer to the following specific implementation examples for details.

[0032] It should be noted that this blockchain-based data verification method can be executed by the terminal alone, or by the terminal and the server together.

[0033] For example, see Figure 1 This is a schematic diagram of an information push system provided in an embodiment of this application. The system includes a terminal 110 and / or a server 120.

[0034] The server 120 can be a single service node, a distributed system composed of multiple service nodes, or a service node in a distributed system. The server can include acquisition nodes, data processing nodes, data storage nodes, and data indexing nodes.

[0035] The data acquisition node obtains the source dataset and corresponding batch identifier for the same data batch according to a preset data batch range, and divides the source dataset into multiple source data sub-files, each corresponding to a file identifier. The data processing node calculates the corresponding leaf hash value for each source data sub-file, and combines the leaf hash values ​​of each source data sub-file to generate a Merkle root hash value and a Merkle proof path, and obtains the generation timestamp. The data processing node combines the generation timestamp, batch identifier, Merkle root hash value, Merkle proof path, multiple leaf hash values, and multiple file identifiers to construct a metadata file, and sends the multiple source data sub-files and the metadata file to... Data storage nodes store data to obtain the data storage address corresponding to the batch identifier; data processing nodes send the batch identifier, Merkle root hash value, data storage address, and generation timestamp to the blockchain service node, causing the blockchain service node to trigger the generation of data storage logs based on the batch identifier, Merkle root hash value, data storage address, and generation timestamp; when the data index node detects the data storage logs generated by the blockchain service node, it maps the batch identifier, Merkle root hash value, data storage address, generation timestamp, transaction hash, block identifier, and block timestamp obtained from parsing the data storage logs into the database table structure to establish a data query index.

[0036] The terminal 110 can be equipped with target applications (such as verification applications), which can be referred to as clients, i.e., verification clients. Specifically, the verification client obtains a list of data batches from the data index node and selects at least one target batch identifier from the list. The verification client determines the target data storage address corresponding to the target batch identifier and downloads the corresponding target source data sub-file from the data storage node based on the target data storage address. The data storage node stores multiple data storage addresses corresponding to multiple data batches and multiple source data sub-files associated with each data storage address. The verification client calculates a local hash value for the target source data sub-file and obtains the corresponding target Merkle root hash value from the blockchain service node based on the target batch identifier. The verification client obtains the target Merkle proof path corresponding to the target batch identifier and the local hash value from the data index node. The target Merkle proof path is obtained by the data index node from the data storage node based on the target batch identifier and the target data storage address. The verification client calculates the root hash value to be confirmed based on the target Merkle proof path and the local hash value. The verification client combines the root hash value to be confirmed and the target Merkle root hash value to verify the target source data sub-file.

[0037] To facilitate understanding of the data verification system in this application embodiment, the data verification system will be described below. Figure 2 This is an example architecture diagram of a blockchain-based data verification system provided in the embodiments of this application, combined with... Figure 2 As shown, the data verification system includes data acquisition nodes, data processing nodes, data storage nodes, data indexing nodes, blockchain service nodes, and verification clients. Specifically, the processing flow of this blockchain-based data verification system is as follows: The data acquisition node obtains the source dataset and corresponding batch identifier of the same data batch according to the preset data batch range, and divides the source dataset into multiple source data sub-files, each source data sub-file corresponding to a file identifier; The data processing node calculates the corresponding leaf hash value for each source data sub-file, combines the leaf hash values ​​of each source data sub-file to generate the Merkel root hash value and the Merkel proof path, and obtains the generation timestamp; The data processing node combines the generated timestamp, batch identifier, Merkel root hash value, Merkel proof path, multiple leaf hash values, and multiple file identifiers to construct a metadata file, and sends multiple source data sub-files and the metadata file to the data storage node for storage in order to obtain the data storage address corresponding to the batch identifier; The data processing node sends the batch identifier, Merkle root hash value, data storage address, and generation timestamp to the blockchain service node, which then triggers the generation of data storage logs based on the batch identifier, Merkle root hash value, data storage address, and generation timestamp. When a data index node detects a data storage log generated by a blockchain service node, it maps the batch identifier, Merkle root hash value, data storage address, generation timestamp, transaction hash, block identifier, and block timestamp obtained from parsing the data storage log to the database table structure to establish a data query index. The client verifies that it retrieves a list of data batches from the data index node and selects at least one target batch identifier from the list of data batches. The client verifies the target batch identifier and determines the target data storage address, and downloads the corresponding target source data sub-file from the data storage node based on the target data storage address; The verification client calculates the local hash value of the target source data sub-file and obtains the corresponding target Merkle root hash value from the blockchain service node according to the target batch identifier; The verification client retrieves the target Merkel proof path corresponding to the target batch identifier and local hash value from the data index node; The verification client calculates the root hash value to be confirmed based on the target Merkel proof path and the local hash value; The verification client combines the root hash value to be confirmed with the target Merkle root hash value to verify the target source data sub-file.

[0038] Therefore, compared to data storage methods in related technologies, centralized databases are susceptible to data tampering due to external attacks, internal malicious attacks, or management errors, affecting data authenticity. Furthermore, this data storage method lacks data verification, resulting in a lack of data credibility. In contrast, this application calculates leaf hash values ​​for any batch of source data sub-files on pre-stored value data storage nodes, generating Merkle root hash values ​​and corresponding Merkle proof paths. This is achieved by synchronizing batch identifiers, data storage addresses, Merkle root hash values, and generation timestamps to data index nodes via blockchain technology logs. The data index nodes can then... The verification client obtains the Merkel proof path corresponding to the batch identifier from the data storage node. Based on this, for any target source data sub-file of the target batch identifier to be verified, it calculates the local hash value and reconstructs the root hash value to be confirmed according to the target Merkel proof path obtained from the data index node. Then, it compares the root hash value to be confirmed with the target Merkel root hash value to verify the target source data sub-file of the target batch previously stored on the data storage node according to blockchain technology. In this way, data verification is performed on any batch of data that has been stored in advance to detect whether the data has been tampered with, and to ensure the authenticity and credibility of the data.

[0039] For ease of understanding, the steps of the blockchain-based data verification method will be described in detail below. It should be noted that the order of the following embodiments is not intended to limit the preferred order of the embodiments.

[0040] See Figure 3 , Figure 3 The schematic diagram illustrates the steps of a blockchain-based data verification method provided in this embodiment. In this embodiment, the blockchain-based data verification method can be executed by a computer device, such as a data verification system composed of a terminal and a server, to jointly execute the blockchain-based data verification method. The specific process is as follows: 101. Verify that the client obtains the data batch list from the data index node and selects at least one target batch identifier from the data batch list.

[0041] With the rapid development of IoT technology, massive amounts of smart devices are continuously generating high-frequency streaming data. This data is crucial for production efficiency monitoring, predictive equipment maintenance, and quality control, and is even a core asset for data transactions.

[0042] Related technologies typically store this data in a centralized database, with the database operator maintaining its integrity and authenticity. However, this data storage method is vulnerable to data tampering if the centralized database is attacked externally, maliciously operated from within, or mismanaged, compromising its authenticity. Furthermore, because this data storage method lacks data verification capabilities, the data lacks credibility.

[0043] To address the above issues, this application embodiment applies to a data verification system. The data verification system includes a verification client, a blockchain service node, a data storage node, and a data index node. The verification client obtains a data batch list from the data index node and selects at least one target batch identifier from the data batch list. The verification client determines the target data storage address corresponding to the target batch identifier and downloads the corresponding target source data sub-file from the data storage node based on the target data storage address. The data storage node stores multiple data storage addresses corresponding to multiple data batches and multiple source data sub-files associated with each data storage address. The verification client calculates a local hash value for the target source data sub-file and obtains the corresponding target Merkle root hash value from the blockchain service node based on the target batch identifier. The verification client obtains the target Merkle proof path corresponding to the target batch identifier and the local hash value from the data index node. The target Merkle proof path is obtained by the data index node from the data storage node based on the target batch identifier and the target data storage address. The verification client calculates the root hash value to be confirmed based on the target Merkle proof path and the local hash value. The verification client combines the root hash value to be confirmed and the target Merkle root hash value to verify the target source data sub-file. In this way, the client can download the corresponding target source data sub-file from the data storage node, calculate the local hash value for the target source data sub-file, and calculate the root hash value to be confirmed by combining the local hash value with the obtained target Merkel proof path. The target source data sub-file is then verified by comparing the target Merkel root hash value with the root hash value to be confirmed, in order to determine whether the source data sub-files of the corresponding batch have been tampered with, thus ensuring the authenticity and credibility of the data.

[0044] In this embodiment, the server may include a data acquisition node, a data processing node, a blockchain service node (any blockchain service node in the blockchain network system), a data storage node, and a data index node. For streaming data generated by smart devices (such as industrial equipment, mobile phones, and computers) and business scenarios (such as advertising push services, electronic ticketing services, and video services), such data (e.g., data collected by smart device sensors, click-through rates and conversion rates of business services like advertising push services, and video playback volume of video services), data collection nodes can collect data according to a preset data batch range to obtain the source datasets and batch identifiers for the same data batch. These source datasets are then preprocessed by the data collection nodes. Next, data processing nodes generate Merkle root hash values ​​and Merkle proof paths for the data in the same batch of source datasets, and store the metadata of the same batch, along with the preprocessed data, in the data storage nodes to obtain the data storage address. Then, the data processing nodes send the relevant metadata for this batch to the blockchain service node to generate data storage events and upload data storage logs to the blockchain. Finally, the index nodes can parse the relevant metadata based on the data storage logs on the blockchain and, combined with the corresponding metadata on the data storage nodes, map and store it in the database table structure on the data index nodes to establish a data query index. Subsequently, the verification client can query the target metadata related to the target batch identifier from the data index node according to the data query index method in order to verify the data of the target batch.

[0045] In some implementations, the source data for each batch is preprocessed, and leaf hash values, Merkle root hash values, and Merkle proof paths are generated for the preprocessed data. Metadata files are also generated, and the preprocessed data and metadata files are stored in a data storage node to obtain the data storage address. The batch identifier, Merkle root hash value, data storage address, and generation timestamp are sent to a blockchain service node to generate a data storage log. This log is then parsed to obtain relevant data for indexing and mapped into the database table structure. For example, before step 101, the following may be included: (A.1) The data acquisition node obtains the source dataset and corresponding batch identifier of the same data batch according to the preset data batch range, and divides the source dataset into multiple source data sub-files, each source data sub-file corresponding to a file identifier; (A.2) The data processing node calculates the corresponding leaf hash value for each source data sub-file, combines the leaf hash value of each source data sub-file to generate the Merkel root hash value and the Merkel proof path, and obtains the generation timestamp; (A.3) The data processing node combines the generated timestamp, batch identifier, Merkle root hash value, Merkle proof path, multiple leaf hash values, and multiple file identifiers to construct a metadata file, and sends multiple source data sub-files and metadata file to the data storage node for storage in order to obtain the data storage address corresponding to the batch identifier; (A.4) The data processing node sends the batch identifier, Merkle root hash value, data storage address and generation timestamp to the blockchain service node, so that the blockchain service node triggers the generation of data storage log based on the batch identifier, Merkle root hash value, data storage address and generation timestamp; (A.5) When the data index node detects the data storage log generated by the blockchain service node, it maps the batch identifier, Merkle root hash value, data storage address, generation timestamp, transaction hash, block identifier and block timestamp obtained from parsing the data storage log to the database table structure to establish a data query index.

[0046] The preset data batch range can be a range of data collected in batches. It can be based on a fixed data volume as the batch unit, such as 1KB, 1MB, 1GB, 1TB, 1PB, or 1EB. Alternatively, it can be based on a fixed time period, such as 1 minute, 1 hour, half a day, 1 day (24 hours), 1 week, or 1 month.

[0047] The source dataset can be a collection of data corresponding to a data batch, which includes multiple source data, i.e. multiple raw data. For example, taking multiple industrial devices on the same industrial production line as an example, the temperature data of the temperature sensor, the humidity data of the humidity sensor, the air pressure data of the air pressure sensor, etc. of each industrial device can be collected according to the preset data batch range. These data can be streaming data, i.e. sequential, large-scale, and continuous data sequences.

[0048] Here, the batch identifier refers to the batch name of the corresponding source dataset, such as batch 1, batch 2, batch 3, etc. It can be generated according to the batch sequence number or by time attribute, such as using "xx year xx month xx day xx hour xx minute" as the batch identifier, for example, "20251210-1230" as the batch identifier. The above are just examples. The target batch identifier can be the identifier of the selected data batch for verification, and its meaning is consistent with the description of "batch identifier".

[0049] Here, the source data sub-file refers to the file containing the corresponding source data. After obtaining the source dataset corresponding to the preset data batch range, the source dataset can be divided into multiple source data sub-files. For example, taking multiple industrial devices on the same industrial production line as an example, temperature data from the temperature sensor, humidity data from the humidity sensor, and air pressure data from the air pressure sensor of each industrial device can be collected according to the preset data batch range. Assuming that industrial device 1 contains temperature sensor 1 and temperature sensor 2, industrial device 2 contains humidity sensor 1 and humidity sensor 2, and industrial device 3 contains air pressure sensor 1 and air pressure sensor 2, the temperature data from temperature sensor 1 and temperature sensor 2 of industrial device 1 can be divided into two source data sub-files, and the humidity data from humidity sensor 1 and humidity sensor 2 of industrial device 2 can be divided into two source data sub-files. Similarly, the air pressure data from air pressure sensor 1 and air pressure sensor 2 of industrial device 3 can be divided into two source data sub-files. The above is only an example and is not limited here.

[0050] The leaf hash value can be obtained by hashing the corresponding data using a specific hash algorithm (such as SHA256). The Merkle root hash value refers to the Merkle root hash value constructed according to the smart contract of the blockchain network system. Specifically, it can be generated by combining the leaf hash values ​​corresponding to multiple source data sub-files. The Merkle proof path refers to the calculation path of multiple leaf hash values ​​when generating the Merkle root hash value. This Merkle proof path can reflect the sorting position, parent leaf node, and sibling leaf node information of each leaf hash value during the calculation process. Furthermore, the generation timestamp can be the timestamp used when generating the Merkle root hash value and the Merkle proof path.

[0051] The metadata file can be a file containing metadata such as the generation timestamp, batch identifier, Merkel root hash value, Merkel proof path, multiple leaf hash values, and multiple file identifiers for the same data batch. It can be in list form or other file forms, which are not limited here.

[0052] The data storage address can be the storage address of multiple source data sub-files and metadata files of the same data batch on the data storage node. Specifically, it can be the storage unit number on the data storage node. Through this data storage address, the corresponding target data storage unit can be quickly located among the large number of data storage units contained in the data storage node, thereby finding multiple source data sub-files and metadata files of the corresponding data batch.

[0053] Specifically, the data storage log can be a log of data storage events recorded on the blockchain. When a data processing node stores multiple source data sub-files and metadata files of a batch to a data storage node, a data storage event is triggered. This event may include or be associated with information such as batch identifier, Merkle root hash value, data storage address, and generation timestamp. This data storage event is sent to a corresponding blockchain service node in the blockchain network system. When the blockchain service node detects this data storage event, it triggers the generation of a data storage log according to the objective function in the smart contract and records it on the blockchain. In this way, the blockchain service nodes in the blockchain network system only need to perform consensus verification based on metadata, reducing data processing volume and saving computing resources. Furthermore, it eliminates the need to upload large amounts of source data to the blockchain, saving storage resources and reducing storage costs, as well as transaction costs, thus ensuring reliability.

[0054] The transaction hash can be the hash value of the blockchain service node when generating the data storage log. Since the generation of the data storage log is executed via blockchain transactions, this transaction hash is the hash value used to process the generation of the data storage log. The block identifier can be the block identifier of the target block on the blockchain that records the data storage log, and the block timestamp can be the generation timestamp of the target block that records the data storage log.

[0055] The database table structure can be a dedicated table created in the database of the data index node (such as PostgreSQL). The fields of the table correspond one-to-one with the storage information. For example, the table fields of the database table structure include batch identifier (batchId), Merkle root hash value (merkleRoot), storage location (storageLocation), generation timestamp (timestamp), transaction hash (transactionHash), block identifier (blockNumber), block timestamp (blockTimestamp), etc.

[0056] Specifically, firstly, data acquisition nodes can collect raw data streams in real time from various devices and data sources. The collected data undergoes necessary preprocessing, such as cleaning and format conversion, to ensure data quality and obtain preprocessed streaming data. The preprocessed streaming data is then divided into batches according to preset fixed time intervals (e.g., every hour, every 5 minutes) or fixed data volumes, with each batch assigned a unique batch identifier (Batch ID). The data content of each batch is then generated into one or more source data sub-files (e.g., bin, csv, json files), each with a corresponding file identifier.

[0057] Then, the data processing node calculates the cryptographic hash value of the content of each independent source data sub-file in a data batch, which serves as the leaf hash value of each source data sub-file. The leaf hash values ​​of multiple source data sub-files in the same data batch are combined and sorted as leaf nodes of the Merkle tree to generate the final Merkle root hash value. Further, a metadata file is generated by combining the generation timestamp, batch identifier, Merkle root hash value, Merkle proof path, multiple leaf hash values, and multiple file identifiers. This metadata file can be represented as "merkle_tree_metadata.json". The original data (i.e., multiple source data sub-files in the same data batch) and the metadata file are uploaded to a designated location on the data storage node to obtain the data storage address. It should be noted that the data storage node is used to securely and persistently store massive amounts of original device data files, while providing an interface to retrieve the original data based on file paths or identifiers. Specific data storage nodes can be centralized cloud storage services (such as Amazon S3) or decentralized storage networks (such as IPFS), selected based on requirements for decentralization, cost, performance, and data persistence.

[0058] Next, the data processing node invokes a blockchain smart contract to record core data, such as the Merkle root hash, onto the blockchain. Specifically, a smart contract is deployed on the blockchain network system, containing a target function that receives and stores the Merkle root hash, batch identifier, and the location identifier (i.e., data storage address) of the original data for each batch of data stored off-chain. Each time a blockchain service node successfully records the Merkle root hash, the smart contract triggers an event to generate a corresponding data storage log. This event contains key metadata such as batchId, MerkleRoot, and storageLocation, which are used for data indexing services to enable information retrieval.

[0059] Finally, this data index node acts as a bridge connecting on-chain and off-chain systems. It continuously monitors specific events (such as data storage logs) emitted by on-chain smart contracts. The received data storage logs are parsed, extracting metadata such as batch ID, Merkle root hash, storage location, generation timestamp, transaction hash, block number, and block timestamp. This metadata is then stored in an off-chain database, specifically mapped to database table structures for data insertion. Database indexes are created for frequently used fields in the database tables (such as batch ID, Merkle root, and block number), forming data query indexes. Furthermore, this data index node provides a RESTful API interface to offer data query services to verification clients, enabling them to quickly find corresponding data based on information from the data query index.

[0060] In this way, on the one hand, by leveraging cryptographic hashing and the immutability of blockchain, an end-to-end integrity verification mechanism is provided for streaming data without the need to trust a third party, fundamentally solving the trust problem of data tampering and enhancing the credibility of the data; on the other hand, it avoids the high storage and transaction costs of directly putting massive amounts of raw data on the blockchain, requiring only periodic uploading of a fixed size of Merkle root and related information, greatly optimizing the efficiency of blockchain resource utilization and operating costs.

[0061] In this embodiment of the application, relevant personnel can choose to verify any one or more batches of historical raw data. Specifically, relevant personnel can obtain a list of data batches from the data index node through the verification client, and select one or more target batch identifiers from the list of data batches so that the relevant raw data of the target batch identifier can be queried and verified in the future, thereby improving the data credibility of the data storage node (i.e., the data storage center).

[0062] In some implementations, the data index node provides a metadata query interface, through which the verification client can obtain a data batch list from the data index node. For example, step 101, "the verification client obtains a data batch list from the data index node," can include: the verification client sending a batch information query request through the metadata query interface provided by the data index node; the data index node responding to the batch information query request and generating a data batch list based on multiple batch information in the database table structure; and the verification client receiving the data batch list returned by the data index node through the batch query interface provided by the data index node.

[0063] The data batch list can be a list containing batch identifiers for the corresponding historical time period, or it can be a list containing all batch identifiers, depending on the actual situation. No limitation is made here.

[0064] It should be noted that the metadata query interface provided by the data index node allows the verification client to interact with the data index node to obtain the corresponding data batch list. Specifically, relevant personnel can send batch information query requests through the verification client based on the metadata query interface provided by the data index node. These requests can carry a specific target historical time period, such as the past day, past week, past month, or past year. The metadata query interface (RESTful API) can be either `GET / api / data-batches / latest` or `GET / api / data-batches?startTime=`. <ts>&endTime= <ts>&batchId= <id>Interfaces such as...

[0065] The data index node stores a database table structure containing multiple batch identifiers and metadata associated with each batch identifier, including the Merkle root hash, storage location, generation timestamp, transaction hash, block number, and block timestamp. Therefore, upon receiving a batch information query request, the data index node can filter out one or more candidate batch identifiers corresponding to one or more target generation timestamps matching the target historical period from the database table structure, based on the target historical period that the query request may contain. It then combines these candidate batch identifiers to generate a data batch list. It should be noted that if the batch information query request does not contain a specific target historical period, the default is the entire historical period. In this case, the data index node extracts all batch identifiers from the database table structure and combines them to generate a data batch list. Thus, this data batch list contains multiple batch information items, i.e., multiple batch identifiers, pre-stored on the data storage node. Finally, the data index node returns this data batch list to the verification client. This allows verification clients to select one or more target batch identifiers from the data batch list, enabling subsequent querying and verification of the relevant original data for that target batch identifier, thereby enhancing the data credibility of the data storage node (i.e., the data storage center).

[0066] By using the above methods, the client can obtain a list of data batches from the data index node, select one or more target batch identifiers from the list, and then query and verify the relevant original data of the target batch identifier, thereby improving the data credibility of the data storage node (i.e., the data storage center).

[0067] 102. Verify that the client determines the target data storage address corresponding to the target batch identifier, and downloads the corresponding target source data sub-file from the data storage node according to the target data storage address.

[0068] In this embodiment of the application, after selecting one or more target batch identifiers, the verification client can determine the target data storage address corresponding to the target batch identifier. For example, it can query the target data storage address corresponding to the target batch identifier through the data index node, and download the corresponding target source data sub-file from the data storage node according to the target data storage address, so as to perform data verification on the target source data sub-file in the future to determine whether the target source data sub-file has been tampered with, thereby improving the credibility of the data on the data storage node.

[0069] The target data storage address can be the storage address of data related to the target batch identifier. Specifically, it refers to the storage location information of multiple source data sub-files and metadata files related to the target batch identifier on the data storage node. For example, multiple source data sub-files and metadata files related to each batch identifier are stored in the same data storage unit on the data storage node, and the target data storage address can be the number of the corresponding data storage unit, which is not limited here. Using this target data storage address, the corresponding target data storage unit can be quickly located among a large number of data storage units on the data storage node, thereby downloading the corresponding target source data sub-file.

[0070] The data storage nodes store multiple data storage addresses corresponding to multiple data batches, as well as multiple source data sub-files and corresponding metadata files associated with each data storage address.

[0071] In some implementations, after constructing the data query index, the data index node can also read multiple file identifiers corresponding to each batch identifier from the metadata file corresponding to each data storage address on the data storage node. For example, before step 102, the implementation may include: the data index node reading the corresponding metadata file from the data storage node based on the batch identifier and the data storage address; and obtaining multiple file identifiers corresponding to multiple source data sub-files associated with the batch identifier based on the metadata file.

[0072] The metadata file contains information such as the generation timestamp associated with the corresponding batch identifier, the batch identifier, the Merkle root hash value, the Merkle proof path, multiple leaf hash values, and multiple file identifiers. Therefore, data index nodes can retrieve the relevant metadata based on the corresponding batch identifier.

[0073] Specifically, after constructing the data query index, the data index node can combine the batch identifier and data storage address to locate the data storage unit corresponding to the data storage address on the data storage node, and read the corresponding metadata file from the data storage unit. Further, the data index node reads multiple file identifiers corresponding to multiple source data sub-files corresponding to the batch identifier from this metadata file. This allows the multiple file identifiers corresponding to the batch identifier to be returned to the verification client for selection, in order to verify the corresponding source data sub-file.

[0074] In some implementations, the verification client obtains the target data storage address corresponding to the target batch identifier and multiple associated file identifiers through the metadata query interface provided by the data index node, and downloads the target source data sub-file corresponding to the target file identifier from the data storage node according to the target data storage address and the multiple associated file identifiers. For example, step 102 may include: the verification client sending a file identifier acquisition request through the metadata query interface provided by the data index node; the data index node determining the corresponding target metadata file based on the target batch identifier in the file identifier acquisition request, and reading the corresponding target data storage address and multiple file identifiers according to the target metadata file; the verification client receiving the target data storage address and multiple file identifiers returned by the data index node through the metadata query interface provided by the data index node, and selecting a target file identifier from the multiple file identifiers; The verification client downloads the target source data sub-file corresponding to the target file identifier from the data storage node based on the target data storage address.

[0075] It should be noted that the metadata query interface provided by the data index node, such as GET / api / data-batches / latest or GET / api / data-batches?startTime= <ts>&endTime= <ts>&batchId= <id>The verification client can interact with the data index node through the metadata query interface provided by the data index node to obtain the target data storage address and multiple file identifiers corresponding to the target batch identifier. Specifically, relevant personnel can send a file identifier retrieval request through the verification client based on the metadata query interface provided by the data index node. This file identifier retrieval request can carry the target batch identifier.

[0076] The data index node stores a database table structure containing multiple batch identifiers and metadata associated with each batch identifier, including the Merkle root hash, storage location, generation timestamp, transaction hash, block number, and block timestamp. Therefore, upon receiving a file identifier retrieval request, the data index node can filter the corresponding target data storage address from the database table structure based on the target batch identifier carried in the request. It then retrieves multiple file identifiers corresponding to multiple source data sub-files from the corresponding target metadata file on the data storage node according to that target data storage address. Alternatively, the data index node can pre-synchronize multiple file identifiers corresponding to the target batch identifier from the data storage node; this is not a limitation. Further, the data index node returns the target data storage address corresponding to the target batch identifier and the associated multiple file identifiers to the verification client through a metadata query interface.

[0077] Finally, the verification client receives the target data storage address and multiple file identifiers returned by the data index node through the metadata query interface, and selects a target file identifier from these identifiers. Furthermore, the verification client can quickly locate the corresponding target data storage unit on the data storage node according to the target data storage address, and download the target source data sub-file corresponding to the target file identifier from that target data storage unit. This facilitates subsequent verification of the target source data sub-file corresponding to the target batch identifier, improving the data credibility of the data storage node (i.e., the data storage center).

[0078] It should be noted that when it is necessary to verify multiple target source data sub-files corresponding to the target batch identifier, multiple target source data sub-files can be downloaded, depending on the actual situation.

[0079] Through the above methods, the verification client can determine the target data storage address corresponding to the target batch identifier. For example, it can query the target data storage address corresponding to the target batch identifier through the data index node, and download the corresponding target source data sub-file from the data storage node based on the target data storage address. This allows for subsequent data verification of the target source data sub-file to determine whether it has been tampered with, thereby improving the credibility of the data on the data storage node.

[0080] 103. Verify that the client calculates the local hash value of the target source data sub-file and obtains the corresponding target Merkle root hash value from the blockchain service node according to the target batch identifier.

[0081] In this embodiment, after downloading the target source data sub-file, the verification client can calculate the corresponding local hash value for the target source data sub-file in order to verify it. It should be noted that when multiple target source data sub-files corresponding to the target batch identifier are downloaded, the corresponding local hash value can be calculated separately for each target source data sub-file. At the same time, the verification client also obtains the target Merkle root hash value corresponding to the target batch identifier on the blockchain through the blockchain service node, so as to combine the local hash value corresponding to the target source data sub-file and the pre-calculated target Merkle root hash value to verify the authenticity of the data in the target source data sub-file, thereby determining whether the target source data sub-file has been tampered with and improving the credibility of the data on the data storage node.

[0082] The verification client can perform hash calculations on the data in the target source data subfile according to a hash algorithm (such as SHA256) to obtain the corresponding local hash value.

[0083] The verification client can obtain the target block identifier and target block timestamp associated with the target batch identifier through the metadata query interface provided by the data index node. Combining the target block identifier and target block timestamp, it can obtain the corresponding target Merkle root hash value from the blockchain service node. Since the target Merkle root hash value is obtained directly from the blockchain, it has authority and credibility.

[0084] Through the above methods, the verification client can calculate the corresponding local hash value for the target source data sub-file. At the same time, the verification client also obtains the target Merkle root hash value corresponding to the target batch identifier on the blockchain through the blockchain service node. This allows for subsequent verification of the authenticity of the data in the target source data sub-file by combining the local hash value corresponding to the target source data sub-file with the pre-calculated target Merkle root hash value, thereby determining whether the target source data sub-file has been tampered with and improving the credibility of the data on the data storage node.

[0085] 104. The verification client obtains the target Merkel proof path corresponding to the target batch identifier and local hash value from the data index node.

[0086] In this embodiment, after the verification client calculates the local hash value corresponding to the target source data sub-file and obtains the target Merkle root hash value, in order to verify the target source data sub-file according to the hash value method, it also needs to obtain the target Merkle proof path associated with the target batch identifier. For example, the verification client can obtain the target Merkle proof path corresponding to the target batch identifier and the local hash value from the data index node. In this way, the target Merkle proof path, the target Merkle root hash value, and the local hash value corresponding to the target source data sub-file can be combined to verify the authenticity of the target source data sub-file, so as to detect whether the target source data sub-file has been tampered with and improve the credibility of the data on the data storage node.

[0087] The target Merkel proof path is obtained by the data index node from the data storage node based on the target batch identifier and the target data storage address.

[0088] Specifically, the verification client can send a proof path retrieval request through the metadata query interface provided by the data index node; the data index node can determine the associated target data storage address from the database table structure based on the target batch identifier carried in the proof path retrieval request, and read the corresponding target Merkel proof path from the corresponding target metadata file on the data storage node according to the target data storage address and the target batch identifier; then, the verification client receives the target Merkel proof path returned by the data index node through the metadata query interface provided by the data index node.

[0089] Through the above methods, the verification client can obtain the target Merkel proof path associated with the target batch identifier. This allows for subsequent verification of the authenticity of the target source data sub-file by combining the target Merkel proof path, the target Merkel root hash value, and the local hash value corresponding to the target source data sub-file. This helps detect whether the target source data sub-file has been tampered with, thereby improving the credibility of the data on the data storage node.

[0090] 105. The verification client calculates the root hash value to be confirmed based on the target Merkel proof path and the local hash value.

[0091] In this embodiment, after obtaining the target Merkel proof path, the target Merkel root hash value, and the local hash value corresponding to the target source data sub-file, the verification client can combine the target Merkel proof path and the local hash value to recalculate a root hash value to be confirmed. This root hash value to be confirmed is reconstructed based on the local hash value according to the target Merkel proof path. Subsequently, by comparing this root hash value to be confirmed with the corresponding target Merkel root hash value, it can be detected whether the target source data sub-file has been tampered with, thereby improving the credibility of the data on the data storage node.

[0092] In some implementations, the root hash value to be confirmed can be calculated on the local hash value according to the target Merkel proof path. Step 105 may include: the verification client determining the hash calculation path associated with the local hash value and multiple target-related hash values ​​corresponding to the hash calculation path based on the target Merkel proof path; and performing hash calculation according to the hash calculation path, combining the local hash value and the multiple target-related hash values ​​to obtain the root hash value to be confirmed.

[0093] Here, the hash calculation path can be the root hash calculation path corresponding to the local hash value in the target Merkel proof path, and this hash calculation path includes the calculation path from the local hash value to the target Merkel root hash value. The target-related hash value refers to the sibling node hash value and parent node hash value that participate in the calculation of the root hash on this hash calculation path.

[0094] Specifically, after obtaining the target Merkel proof path, the verification client can determine the target leaf hash value corresponding to the local hash value from this path. Then, starting from this target leaf hash value, it searches the target Merkel proof path for a hash calculation path from the target leaf hash value to the target Merkel root hash value. Simultaneously, it determines the sibling leaf hash values ​​adjacent to the target leaf hash value, as well as the hash values ​​of other parent nodes participating in the hash calculation along this path, obtaining multiple target-related hash values. Finally, following the direction of the hash calculation path, it hashes the local node with its sibling leaf hash values ​​to obtain the first target parent node hash value. This target parent node hash value is then hashed with other adjacent parent node hash values ​​to obtain the second target parent node hash value. This process continues upwards until the top-level unconfirmed root hash value is calculated. This allows for subsequent verification of the data authenticity of the target source data sub-file by combining the unconfirmed root hash with the target Merkel root hash value corresponding to the target batch identifier, thereby improving the data's credibility.

[0095] It should be noted that when the verification client calculates multiple local hash values ​​corresponding to multiple target source data sub-files for the target batch identifier, it can calculate each unconfirmed root hash value separately based on the target Merkel proof path and each local hash value, that is, obtain a reconstructed unconfirmed root hash value corresponding to each local hash value; in addition, it can combine multiple local hash values ​​to reconstruct an unconfirmed root hash value together according to the target Merkel proof path.

[0096] By combining the target Merkel proof path and the local hash value, a new root hash value can be recalculated. This root hash value is reconstructed based on the local hash value and the target Merkel proof path. Subsequently, by comparing this root hash value with the corresponding target Merkel root hash value, it can be determined whether the target source data sub-file has been tampered with, thereby improving the credibility of the data on the data storage node.

[0097] 106. The verification client combines the root hash value to be confirmed with the target Merkle root hash value to verify the target source data sub-file.

[0098] In this embodiment of the application, after obtaining the target Merkle root hash value and the calculated root hash value to be confirmed, the verification client can compare the root hash value to be confirmed with the target Merkle root hash value associated with the target batch identifier to determine whether the two are consistent, thereby detecting whether the target source data sub-file has been tampered with, and improving the credibility of the data on the data storage node.

[0099] In some implementations, the verification client verifies the target source data sub-file based on the comparison result between the root hash value to be verified and the target Merkle root hash value. For example, step 106 may include: the verification client comparing the root hash value to be verified with the target Merkle root hash value to obtain a comparison result; when the comparison result shows that the root hash value to be verified and the target Merkle root hash value are consistent, it is determined that the verification of the target source data sub-file has passed; when the comparison result shows that the root hash value to be verified and the target Merkle root hash value are inconsistent, it is determined that the verification of the target source data sub-file has failed.

[0100] Specifically, after the verification client reconstructs a root hash value to be confirmed based on the local hash value of the target source data sub-file, it compares this root hash value with the target Merkle root hash value. The comparison result determines whether the root hash value matches the target Merkle root hash value. If the result is that the original data in the target source data sub-file has not been tampered with, the data in the target source data sub-file is complete, and the original data corresponding to the target source data sub-file is trustworthy. In this case, the verification of the target source data sub-file is successful. Conversely, if the result is that the root hash value does not match the target Merkle root hash value, the original data in the target source data sub-file has been tampered with, the data in the target source data sub-file is incomplete, and the original data corresponding to the target source data sub-file is untrustworthy. In this case, the verification of the target source data sub-file fails. This process completes the verification of the authenticity and integrity of the target source data sub-file corresponding to the target batch identifier, improving the credibility of the data in the data storage node (i.e., the data storage center).

[0101] By using the above methods, the verification client can compare the root hash value to be confirmed with the target Merkle root hash value associated with the target batch identifier to determine whether the two are consistent, thereby determining the data integrity of the target source data sub-file and detecting whether the target source data sub-file has been tampered with, thus improving the credibility of the data on the data storage node.

[0102] To better understand the embodiments of this application, in conjunction with Figure 2 The system architecture of this application embodiment is described by example as follows: First, the data acquisition node is responsible for streaming data acquisition and preprocessing. Specifically, the data acquisition node is responsible for acquiring raw data streams in real time from various devices and data sources, performing necessary preprocessing such as cleaning and format conversion to ensure data quality. The preprocessed massive streaming data is then divided into batches according to preset fixed time intervals (e.g., every hour, every 5 minutes) or fixed data volumes, with each batch assigned a unique batch identifier (Batch ID). The data content of each batch is then generated into one or more source data sub-files (e.g., bin, csv, json files).

[0103] Then, the data processing node calculates the cryptographic hash value of the content of each independent source data sub-file in the data batch, obtaining the leaf node hash value. These hash values ​​are then sorted as leaf nodes of the Merkle tree to generate the final Merkle root hash. A metadata file (e.g., merkle_tree_metadata.json) is generated, and the original data and metadata file are uploaded to the specified location in the data storage module. Finally, a smart contract is invoked to record core data such as the Merkle root hash onto the blockchain.

[0104] Next, a blockchain smart contract is deployed on any blockchain service node in the blockchain network system. This smart contract contains a target function that receives and stores the Merkle root hash, batch identifier, and the location identifier of the original data in that batch off-chain, i.e., the target data storage address, for each batch of data. When the blockchain service node successfully records the Merkle root hash value each time, the smart contract triggers an event, generating an event log, i.e., the data storage log. This event contains key metadata such as batch identifier, Merkle root hash value, data storage address, generation timestamp, transaction hash, block identifier, and block timestamp. These events are used by data index nodes to perform information searches.

[0105] Furthermore, data storage services on data storage nodes are used to securely and persistently store massive amounts of raw device data files, while providing data read interfaces to retrieve raw data based on file paths or identifiers (such as data storage addresses). Specific data storage can utilize centralized cloud storage services (such as Amazon S3) or decentralized storage networks (such as IPFS). The choice depends on the requirements for decentralization, cost, performance, and data persistence.

[0106] Finally, the data index node provides a data indexing service, acting as a bridge connecting the on-chain and off-chain worlds. This service continuously monitors specific events emitted by on-chain smart contracts, namely data storage logs. It parses the received data storage logs, extracting metadata such as batch identifiers, Merkle root hashes, data storage addresses, generation timestamps, transaction hashes, block identifiers, and block timestamps, and stores this metadata in an off-chain database. It also provides a RESTful API interface for users to query data.

[0107] Based on the above, relevant personnel can use the data verification client to query and download data and verify data integrity.

[0108] Furthermore, to better understand the above blockchain-based data verification system architecture, a specific blockchain-based data verification example will be introduced below: The first step is system initialization, which includes deploying smart contracts, configuring data storage, and starting the data indexing service.

[0109] Smart contract deployment refers to deploying smart contracts, which define the logic for batch data uploading to the blockchain, onto the blockchain network system. Data storage configuration refers to configuring and initializing the data storage system (such as an S3 bucket or IPFS node). Data indexing service startup refers to deploying and starting the data indexing service, configuring it to connect to the blockchain nodes, and starting to listen for events emitted by the deployed smart contracts. Simultaneously, it configures a high-performance database (such as PostgreSQL or MongoDB) to store the index data.

[0110] The second step is data acquisition and processing. Data acquisition nodes continuously obtain real-time streaming data from the devices. Based on a preset period (e.g., hourly), the raw data from all devices within that period is aggregated into independent data batches. Each batch is assigned a unique batch ID. Then, the data content of each batch is written to one or more independent source data sub-files. For example, all temperature sensor data for one hour might be written to a single source data sub-file; for instance, this source data sub-file for temperature sensor data could be DeviceA_temperature_20250722_2000.json, while pressure data would be written to DeviceA_pressure_20250722_2000.json. This is just an example.

[0111] The third step is to generate the Merkle root hash value.

[0112] (1) Data file hashing. For each independent source data sub-file in the data batch, calculate the hash value of its content (using the SHA-256 algorithm). These hash values ​​are used as leaf nodes of the Merkle tree, i.e., leaf hash values.

[0113] (2) Deterministic sorting. Before constructing the Merkle tree, all leaf hashes (or their corresponding file identifiers) are strictly and deterministically sorted. For example, they can be sorted by filename lexicographical order, by the device ID contained in the file plus the smallest timestamp, or directly by the leaf node hashes in lexicographical order. This sorting rule is consistent throughout the entire system (generation and verification).

[0114] (3) Merkle tree construction and Merkle proof generation. Based on the sorted list of leaf hashes, a Merkle tree is constructed using a bottom-up, pairwise hash concatenation and recursive calculation of parent hashes. If the number of hashes in the current layer is odd, the last hash is copied and paired with itself. The resulting unique hash value is the Merkle root of that batch.

[0115] For example, to better understand "step three", the following is an example of generating Merkle root hash values: Suppose that at a fixed period (e.g., 10:00 AM on July 22, 2025), the system collects streaming data from multiple data sources, generating 10 source data sub-files. These files are identified by their filenames, but their final order in the Merkle tree will be determined by strict sorting rules. The file identifiers of the 10 source data sub-files are as follows: DeviceA_Sensor1_20250722_2000.json DeviceA_Sensor2_20250722_2000.json DeviceB_Sensor1_20250722_2000.json … DeviceE_Sensor1_20250722_2000.json DeviceE_Sensor2_20250722_2000.json First, the data file content is hashed (generating leaf nodes). The hash value of the complete content of each data file is calculated and used as a leaf node in the Merkle tree. The leaf hash values ​​of each source data sub-file are as follows: h1=SHA256(DeviceA_Sensor1_20250722_2000.json); h2=SHA256(DeviceA_Sensor2_20250722_2000.json); … H10=SHA256(DeviceE_Sensor2_20250722_2000.json).

[0116] Thus, we obtain 10 original leaf hashes: [h1, h2, h3, h4, h5, h6, h7, h8, h9, h10].

[0117] Next, deterministic sorting is performed. This step ensures that the same Merkle root is obtained each time the same set of files is built. For example, sorting in ascending order by the lexicographical order of the leaf hashes (string comparison). It is assumed that the order of the leaf hashes after lexicographical sorting may differ from the original file naming order. For clarity, let's assume that after sorting, their logical order is H1 to H10, forming an ordered list of leaf hashes: [H1, H2, H3, H4, H5, H6, H7, H8, H9, H10].

[0118] Finally, construct the Merkle tree (a layer-by-layer aggregated hash). Figure 4 This is a structural example diagram of the hash calculation path provided in the embodiments of this application, combined with... Figure 4 As shown, specifically starting from the sorted leaf hashes, every two adjacent hash values ​​are concatenated, and then the SHA-256 hash of this concatenated string is calculated. This process continues upwards until only one hash value remains—the Merkle root. If the number of hashes in the current layer is odd, the last hash is copied and paired with its own hash.

[0119] The fourth step involves the data processing node generating a metadata file named merkle_tree_metadata.json. This file contains: a unique identifier for the current data batch (batchId), the Merkle root calculated for this batch (as a secondary reference), a metadata generation timestamp (generatedTime), and a sorted list (leafNodes array) containing the hashes of all leaf nodes and their corresponding original filenames.

[0120] The leafNodes array includes the following fields: Hash, originalFileName, and proofPath.

[0121] The Hash field contains the SHA-256 hash value of each source data subfile, usually represented as a hexadecimal string. The hash values ​​in this list must be strictly sorted in lexicographical order.

[0122] The `originalFileName` field contains the file identifier of the source data sub-file. For example, this file identifier could be `DeviceA_Sensor1_20250722_2000.json`. This information helps users quickly locate the original data file that was recorded and verified.

[0123] The `proofPath` field refers to the Merkel proof path. To avoid the indexing service reconstructing the proof path by traversing leafNodes in real time every time a verification request is received, the data security processing module should pre-calculate and store the complete Merkel proof path from each leaf node to the root when generating the Merkel tree. This file (or database table) contains a mapping from the "leaf hash" to its "proof path".

[0124] For example, the content of the metadata file is as follows: { "batchId": "20250722_001", "merkleRoot": "0x1234567890abcdef...", "generatedTime": 1678886400, / / Metadata generation timestamp "leafNodes": [ { "hash": "0xabcdef123456...", "originalFileName": "DeviceA_Sensor1_20250722_2000.json", "proofPath": [ { "hash": "0xbbbbbbbbbbbb...", "position": "right"}, { "hash": "0xdddddddddddd...", "position": "left"} ] }, { "hash": "0xbbbbbbbbbbbbbb...", "originalFileName": "DeviceA_Sensor2_20250722_2000.json", "proofPath": [ { "hash": "0xabcdef123...", "position": "left"}, { "hash": "0xdddddddddddd...", "position": "left"} ] } / / ... Complete information about all N files in the batch... ] }” The fifth step is to store off-chain data and upload metadata information to the blockchain.

[0125] The data processing node uploads a batch of raw data files and the metadata file merkle_tree_metadata.json to a directory in a configured off-chain storage system (such as S3 or IPFS) and obtains its storage address, storageLocation. storageLocation points to the location of the folder (directory) containing all files and metadata files in this batch.

[0126] Data processing nodes use blockchain client libraries (such as Ethers.js or Web3.js) to call the corresponding functions of smart contracts, sending the batch number (batchId), the calculated Merkle Root, the storage location (storageLocation), and the timestamp (timestamp) of the data generation as parameters to the blockchain for recording.

[0127] The following is an example of the on-chain data from the data processing node: batchId: 20250722_2000 merkleRoot: 0x1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b storageLocation: s3: / / s3-bucket / batch_20250722_2000 / or ipfs: / / Qm... timestamp: 1753149600 The smart contract stores the received batchId, merkleRoot, and storageLocation in its state variables. Once this data is on the blockchain, it acquires the immutability of the blockchain.

[0128] Subsequently, the smart contract triggers an event (e.g., DataBatchRecorded) using the `emit` keyword. Events are lightweight logs on the blockchain, not directly stored in the contract's state variables, but recorded as a byproduct of transaction execution in the transaction receipt. The event itself does not affect the contract's state, but provides an auditable record of the contract's execution history. Once triggered, an event is immutable and permanently recorded on the blockchain.

[0129] The core logic of the smart contract code is as follows: "event DataBatchRecorded( string indexed batchId, / / indexed: indexable, facilitating off-chain lookups bytes32 indexed merkleRoot, / / indexed string storageLocation, address recorder, / / Transaction sender address uint256 timestamp / / Timestamp when the data was generated ); function recordDataBatch(string memory batchId, bytes32 merkleRoot, string memory storageLocation, uint256 timestamp) public { / / ... Storage logic... emit DataBatchRecorded(batchId, merkleRoot, storageLocation, msg.sender, timestamp); / / Trigger the event }” The sixth step involves the data index node detecting and processing events to provide users with data query services. This includes the following three parts: Part 1: Event Listening and Parsing. The data indexing service continuously monitors events emitted by smart contracts, and parses the events once a new event is captured.

[0130] Specifically, when the data indexing service starts for the first time, or restarts after a shutdown, the data indexing nodes need to catch up on events that occurred on the blockchain during the offline period. The indexer first queries its internal synchronization progress database. If there is no record in the database, it means this is the first run, and the synchronization starting point will be the block number of the smart contract deployment. If there is a record in the database, the synchronization starting point is the last synchronized block number plus 1 (last_synced_block + 1). The indexer iterates through every block from the synchronization starting point to the latest block on the current chain. For each block N, the `contract.queryFilter(eventFilter, fromBlock, toBlock)` method queries the blockchain nodes for specific contract events. This method of event retrieval by the blockchain nodes is more efficient than downloading the entire block and then parsing the log.

[0131] After the data index node completes historical data synchronization, the indexer switches to real-time mode to listen for new events occurring on the blockchain. The indexer connects to the blockchain node via WebSocket and subscribes to the newHeads event (new block header). When a new block header notification is received, the indexer retrieves the detailed information of that block, performing "querying specific contract events" and "parsing event data".

[0132] The event logs obtained by the data index node from the blockchain node are raw byte data, which needs to be decoded through the smart contract's ABI (Application Binary Interface). The underlying development library has already encapsulated this low-level decoding logic. You only need to provide the smart contract's ABI and call the `getPastEvents` method to decode the raw log data into easily understandable JavaScript objects. From these objects, you can extract information such as `batchId`, `merkleRoot`, `storageLocation`, `timestamp`, `transactionHash`, `blockNumber` (block number), and `blockTimestamp` (block timestamp).

[0133] Events are "lightweight logs" of the blockchain, which do not occupy expensive smart contract state variable storage space, but are stored in the blockchain's "receipts" at extremely low cost.

[0134] Example of data storage log: { "address": "0x123...abc", / / Address of the smart contract "topics": [ "0x9a7...123", / / Hash of the event signature (used to identify this as a DataBatchRecorded event) "0x000...20250722_2000", / / indexed parameter: batchId (hash or encoded) [cite: 189] "0x1a2b3c4d5e6f7a8b..." / / indexed parameter: merkleRoot [cite: 190] ], "data": "0x000...00000064...", / / Non-indexed parameters: storageLocation, timestamp, etc. [cite: 191, 193] "blockNumber": "0x112233", "transactionHash": "0xabc...def" } The indexing service uses the smart contract's ABI (Interface Specification File) to decode the raw data. After decoding, it becomes an object that developers and the database can directly use. { "eventName": "DataBatchRecorded", "args": { "batchId": "20250722_2000", "merkleRoot": "0x1a2b3c4d5e6f...", "storageLocation": "s3: / / s3-bucket / batch_20250722_2000 / ", "recorder": "0x71C...fe3", / / Transaction sender address "timestamp": 1753149600 / / Data generation timestamp }, "blockNumber": 1122867, / / Block height "transactionHash": "0xabc...def", / / Transaction hash, used for tracing "blockTimestamp": 1753149615 / / Actual time of block packaging }” Part 2, Data Storage. The parsed event data is stored in a high-performance off-chain database (such as PostgreSQL) and indexed.

[0135] Specifically, the data index node persists the parsed event data. It maps the decoded event parameters and attached blockchain metadata (such as transactionHash, blockNumber, and blockTimestamp) to the database table structure for data insertion. Database indexes are created for fields frequently used for querying, sorting, or filtering in the database table (such as batchId, merkleRoot, and blockNumber).

[0136] Part 3, Data Query Interface: The data indexing service provides a RESTful API interface. The RESTful API interface includes the following: <1> The GET command ` / api / data-batches / latest` is used to query the metadata of the latest uploaded data batch.

[0137] <2> GET / api / data-batches?startTime= <ts>&endTime= <ts>&batchId= <id>Used to query metadata for batches of data within a specified time period, primarily for data discovery and retrieval.

[0138] The merkleRoot returned by this interface should not be used by clients for final integrity verification; it is only for reference information in the indexing service. The authoritative merkleRoot must be obtained from the blockchain.

[0139] <3> The GET / api / data-batches / {batchId} / proof command is used to retrieve the Merkle proof path for a specific data file within a specified batch.

[0140] For example, query parameters may include leafHash (string, required): verifying the hash value of the file to be verified, calculated locally on the client side.

[0141] For example, a client verifies a file in batchId=20250722_2000 whose local hash is 0xabcdef... This is done via a GET request to / api / data-batches / 20250722_2000 / proof?leafHash=0xabcdef123456... The data indexing service then returns the following: it looks up the leafHash in the database (or via the metadata file) and returns a list of "sibling node" hashes required to navigate to the Merkle root, along with their relative positions.

[0142] Step 7: The verification client queries historical data through the data indexing service's API interface (GET / api / data-batches), browses the returned batch information, selects the batch of interest, obtains the storage location, and downloads the specific raw data file from the storage service. When a user has doubts about the authenticity or tamper-proof nature of a downloaded raw data file, the data verification process can be triggered. Data verification allows any user who possesses the file to be verified and knows its batch to independently and without trusting the data indexing service or data storage service to confirm the file's integrity and tamper-proof nature. The sole anchor of trust for verification is the blockchain smart contract. The client provides a "Verify Data Integrity" button or function, allowing users to select a raw data file they have downloaded locally for verification.

[0143] The verification process is as follows: First, local hash calculation. The client obtains the information required for verification (batchId) and calculates the hash value (localDataHash) of the content of the file to be verified locally.

[0144] Then, obtain the authoritative Merkle root (security anchor). [Security Optimization] The client connects directly to the blockchain node (or trusted RPC gateway) based on the batchId of the file, calls the read-only function of the smart contract (e.g., getMerkleRoot(batchId)) to obtain the authoritative, tamper-proof onChainMerkleRoot for that batch.

[0145] Next, the Merkel proof path is obtained (efficiency optimization). The client sends an API request to the index service to obtain the Merkel proof path corresponding to localDataHash.

[0146] For example, a request to the ` / api / data-batches / {batchId} / proof?leafHash={localDataHash}` API is used to retrieve the Merkel proof path. The data index node performs a fast lookup using its database table structure and returns a concise list of `proofPath` values. If the indexing service returns an error (such as a 404 NotFound), it means that the file hash does not exist in the batch, and verification fails immediately.

[0147] Next, the Merkel root hash to be confirmed is reconstructed locally. The client combines the localDataHash with the proofPath list, and according to the standard Merkel validation algorithm, starts with localDataHash and iteratively applies the hashes of sibling nodes in proofPath for merging and hashing. Ultimately, this calculation produces a single root hash value to be confirmed, which is the "validation root".

[0148] Finally, the verification client compares the locally calculated validationRoot with the Merkle root hash value onChainMerkleRoot obtained directly from the blockchain. If the two match perfectly, the client can independently confirm that its local data is complete and tamper-proof without trusting any third party. Otherwise, it indicates that there is a problem with the data.

[0149] Through the above examples, cryptographic hashing and the immutability of blockchain provide an end-to-end integrity verification mechanism for streaming data without the need for a trusted third party. This fundamentally solves the trust problem of data tampering and enhances the credibility of the data. It also avoids the high storage and transaction costs of directly uploading massive amounts of raw data to the blockchain, requiring only periodic uploading of a fixed size of Merkle root and related information, greatly optimizing the efficiency of blockchain resource utilization and reducing operating costs. Furthermore, verifiers do not need to download or process all historical data; they only need to obtain the specific streaming data fragment and metadata file to be verified to quickly complete the verification locally, significantly improving verification efficiency. In addition, the raw data can be flexibly stored in centralized cloud storage or decentralized storage, balancing performance, cost, privacy, and decentralization requirements. Moreover, the system architecture design has excellent modularity and layering characteristics, easily coping with the continuous growth of data volume and supporting horizontal scaling.

[0150] As can be seen from the above embodiments, this application embodiment is applied to a data verification system. The data verification system includes a verification client, a blockchain service node, a data storage node, and a data index node. The verification client obtains a data batch list from the data index node and selects at least one target batch identifier from the data batch list. The verification client determines the target data storage address corresponding to the target batch identifier and downloads the corresponding target source data sub-file from the data storage node according to the target data storage address. The data storage node stores multiple data storage addresses corresponding to multiple data batches and multiple source data sub-files associated with each data storage address. The verification client calculates a local hash value for the target source data sub-file and obtains the corresponding target Merkle root hash value from the blockchain service node according to the target batch identifier. The verification client obtains the target Merkle proof path corresponding to the target batch identifier and the local hash value from the data index node. The target Merkle proof path is obtained by the data index node from the data storage node according to the target batch identifier and the target data storage address. The verification client calculates the root hash value to be confirmed based on the target Merkle proof path and the local hash value. The verification client combines the root hash value to be confirmed and the target Merkle root hash value to verify the target source data sub-file. In this way, the client can download the corresponding target source data sub-file from the data storage node, calculate the local hash value for the target source data sub-file, and calculate the root hash value to be confirmed by combining the local hash value with the obtained target Merkel proof path. The target source data sub-file is then verified by comparing the target Merkel root hash value with the root hash value to be confirmed, in order to determine whether the source data sub-files of the corresponding batch have been tampered with, thus ensuring the authenticity and credibility of the data.

[0151] Therefore, compared to data storage methods in related technologies, centralized databases are susceptible to data tampering due to external attacks, internal malicious attacks, or management errors, affecting data authenticity. Furthermore, this data storage method lacks data verification, resulting in a lack of data credibility. In contrast, this application calculates leaf hash values ​​for any batch of source data sub-files on pre-stored value data storage nodes, generating Merkle root hash values ​​and corresponding Merkle proof paths. This is achieved by synchronizing batch identifiers, data storage addresses, Merkle root hash values, and generation timestamps to data index nodes via blockchain technology logs. The data index nodes can then... The verification client obtains the Merkel proof path corresponding to the batch identifier from the data storage node. Based on this, for any target source data sub-file of the target batch identifier to be verified, it calculates the local hash value and reconstructs the root hash value to be confirmed according to the target Merkel proof path obtained from the data index node. Then, it compares the root hash value to be confirmed with the target Merkel root hash value to verify the target source data sub-file of the target batch previously stored on the data storage node according to blockchain technology. In this way, data verification is performed on any batch of data that has been stored in advance to detect whether the data has been tampered with, and to ensure the authenticity and credibility of the data.

[0152] To facilitate better implementation of the blockchain-based data verification method provided in this application, this application also provides a blockchain-based data verification device. The meanings of the terms used are the same as in the blockchain-based data verification method described above, and specific implementation details can be found in the descriptions within the method embodiments.

[0153] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of a blockchain-based data verification device provided in an embodiment of this application. The blockchain-based data verification device is integrated into the computer equipment of this application, such as a terminal. It is applied to a verification client in a data verification system. The data verification system also includes a blockchain service node, a data storage node, and a data index node. The blockchain-based data verification device may include a first acquisition unit 401, a download unit 402, a first calculation unit 403, a second acquisition unit 404, a second calculation unit 405, and a verification unit 406.

[0154] The first acquisition unit 401 is used to acquire a data batch list from the data index node and select at least one target batch identifier from the data batch list. Download unit 402 is used to determine the target data storage address corresponding to the target batch identifier, and download the corresponding target source data sub-file from the data storage node according to the target data storage address. The data storage node stores multiple data storage addresses corresponding to multiple data batches and multiple source data sub-files associated with each data storage address. The first calculation unit 403 is used to calculate the local hash value of the target source data sub-file and to obtain the corresponding target Merkle root hash value from the blockchain service node according to the target batch identifier. The second acquisition unit 404 is used to acquire the target Merkel proof path corresponding to the target batch identifier and the local hash value from the data index node; The second calculation unit 405 is used to calculate the root hash value to be confirmed based on the target Merkel proof path and the local hash value. Verification unit 406 is used to verify the client's verification of the target source data sub-file by combining the root hash value to be confirmed with the target Merkle root hash value.

[0155] In some embodiments, the second computing unit 405 is further configured to: Based on the target Merkel proof path, determine the hash calculation path associated with the local hash value and the multiple target-related hash values ​​corresponding to the hash calculation path; Following the hash calculation path, a hash calculation is performed by combining the local hash value with multiple target-related hash values ​​to obtain the root hash value to be confirmed.

[0156] In some implementations, the verification unit 406 is further configured to: The root hash value to be confirmed is compared with the target Merkel root hash value to obtain the comparison result; When the comparison result shows that the root hash value to be confirmed is consistent with the target Merkel root hash value, the verification of the target source data sub-file is confirmed to be successful. When the comparison result shows that the root hash value to be confirmed is inconsistent with the target Merkel root hash value, it is determined that the verification of the target source data sub-file fails.

[0157] In some embodiments, the first acquisition unit 401 is further configured to: By sending a batch information query request through the metadata query interface provided by the data index node, the data index node responds to the batch information query request and generates a data batch list based on multiple batch information in the database table structure. Receive the list of data batches returned by the data index node through the batch query interface provided by the data index node.

[0158] In some embodiments, the download unit 402 is further configured to: By sending a file identifier retrieval request through the metadata query interface provided by the data index node, the data index node can determine the corresponding target metadata file based on the target batch identifier in the file identifier retrieval request, and read the corresponding target data storage address and multiple file identifiers based on the target metadata file; The target file identifier is selected from the target file identifier by using the metadata query interface provided by the data index node. Based on the target data storage address, download the target source data sub-file corresponding to the target file identifier from the data storage node.

[0159] As described above, this application calculates leaf hash values ​​for any batch of source data sub-files on a pre-stored value data storage node, and generates Merkel root hash values ​​and corresponding Merkel proof paths. The batch identifier, data storage address, Merkel root hash value, and generation timestamp are synchronized to the data index node via blockchain logs. The data index node can obtain the Merkel proof path corresponding to the batch identifier from the data storage node. Based on this, the verification client calculates a local hash value for any target source data sub-file of the target batch identifier to be verified, and reconstructs the root hash value to be confirmed according to the target Merkel proof path obtained from the data index node. The root hash value to be confirmed is then compared with the target Merkel root hash value. This verifies the target source data sub-files of the target batch previously stored on the data storage node using blockchain technology. In this way, data verification is performed on any pre-stored batch of data to detect whether the data has been tampered with, ensuring the authenticity and credibility of the data.

[0160] The specific implementation of each of the above units can be found in the previous embodiments, and will not be repeated here.

[0161] Figure 6 To implement the structural block diagram of a terminal in this embodiment of the application, the terminal 110 includes: a radio frequency (RF) circuit 510, a memory 515, an input unit 530, a display unit 540, a sensor 550, an audio circuit 560, a wireless fidelity (WiFi) module 570, a processor 580, and a power supply 590, among other components. Those skilled in the art will understand that the terminal 110 structure shown in the figures does not constitute a limitation on a mobile phone or computer, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0162] The RF circuit 510 can be used to receive and transmit signals during information transmission or calls. In particular, it receives downlink information from the base station and processes it with the processor 580; in addition, it transmits uplink data to the base station.

[0163] The memory 515 can be used to store software programs and modules. The processor 580 executes various functional applications and data processing of the terminal by running the software programs and modules stored in the memory 515.

[0164] The input unit 530 can be used to receive input numeric or character information, and to generate key signal inputs related to the terminal's settings and function control. Specifically, the input unit 530 may include a touch panel 531 and other input devices 532.

[0165] The display unit 540 can be used to display input or provided information, as well as various menus of the terminal. The display unit 540 may include a display panel 541.

[0166] Audio circuit 560, speaker 561, and microphone 562 provide an audio interface.

[0167] In this embodiment, the processor 580 included in the terminal 110 can execute the blockchain-based data verification method of the previous embodiment.

[0168] The terminal 110 in this application embodiment includes, but is not limited to, mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, aircraft, etc. This invention embodiment can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, and assisted driving.

[0169] Figure 7 This is a partial structural block diagram of a server implementing an embodiment of this application. The server 120 can vary significantly due to different configurations or performance, and may include one or more Central Processing Units (CPUs) 622 (e.g., one or more processors) and a memory 632, and one or more storage media 620 (e.g., one or more mass storage devices) for storing application programs 642 or data 644. The memory 632 and storage media 620 may be temporary or persistent storage. The program stored in the storage media 620 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the server 120. Furthermore, the CPU 622 may be configured to communicate with the storage media 620 and execute the series of instruction operations in the storage media 620 on the server 120.

[0170] Server 120 may also include one or more power supplies 626, one or more wired or wireless network interfaces 650, one or more input / output interfaces 658, and / or one or more operating systems 641, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0171] The central processing unit 622 in server 120 can be used to execute the blockchain-based data verification method of the embodiments of this application.

[0172] This application also provides a computer-readable storage medium for storing program code for executing the blockchain-based data verification methods of the foregoing embodiments.

[0173] This application also provides a computer program product, which includes a computer program. A processor of a computer device reads and executes the computer program, causing the computer device to perform the aforementioned blockchain-based data verification method.

[0174] Furthermore, the terms "comprising" and "including," and any variations thereof, are intended to cover non-exclusive inclusion, such that a process, method, apparatus, product, or device that includes a series of steps or units is not necessarily limited to those steps or units that are expressly listed, but may include other steps or units that are not expressly listed or that are inherent to such process, method, product, or device.

[0175] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0176] It should be understood that in the description of the embodiments of this application, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

[0177] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed between them may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0178] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0179] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0180] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0181] It should also be understood that the various implementation methods provided in this application can be combined arbitrarily to achieve different technical effects.

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

[0183] The above is a detailed description of the embodiments of this application. However, this application is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this application. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.< / id> < / ts> < / ts> < / id> < / ts> < / ts> < / id> < / ts> < / ts>

Claims

1. A data verification method based on blockchain, characterized in that, Applied to a data verification system, the data verification system comprising a verification client, a blockchain service node, a data storage node, and a data index node, the method includes: The verification client obtains a list of data batches from the data index node and selects at least one target batch identifier from the list of data batches. The verification client determines the target data storage address corresponding to the target batch identifier, and downloads the corresponding target source data sub-file from the data storage node according to the target data storage address. The data storage node stores multiple data storage addresses corresponding to multiple data batches and multiple source data sub-files associated with each data storage address. The verification client calculates the local hash value of the target source data sub-file and obtains the corresponding target Merkle root hash value from the blockchain service node according to the target batch identifier; The verification client obtains the target Merkel proof path corresponding to the target batch identifier and the local hash value from the data index node, wherein the target Merkel proof path is obtained by the data index node from the data storage node according to the target batch identifier and the target data storage address; The verification client calculates the root hash value to be confirmed based on the target Merkel proof path and the local hash value; The verification client combines the root hash value to be confirmed with the target Merkle root hash value to verify the target source data sub-file.

2. The method according to claim 1, characterized in that, The verification client calculates the root hash value to be confirmed based on the target Merkel proof path and the local hash value, including: The verification client determines the hash calculation path associated with the local hash value and multiple target-related hash values ​​corresponding to the hash calculation path based on the target Merkel proof path; Following the hash calculation path, a hash calculation is performed by combining the local hash value with the multiple target-related hash values ​​to obtain the root hash value to be confirmed.

3. The method according to claim 2, characterized in that, The verification client combines the root hash value to be confirmed with the target Merkle root hash value to verify the target source data sub-file, including: The verification client compares the root hash value to be confirmed with the target Merkle root hash value to obtain the comparison result; When the comparison result shows that the root hash value to be confirmed is consistent with the target Merkel root hash value, it is determined that the verification of the target source data sub-file has passed. When the comparison result shows that the root hash value to be confirmed is inconsistent with the target Merkle root hash value, it is determined that the verification of the target source data sub-file fails.

4. The method according to any one of claims 1 to 3, characterized in that, The data verification system also includes a data acquisition node and a data processing node. Before the verification client obtains the data batch list from the data index node, the method further includes: The data acquisition node acquires the source dataset and corresponding batch identifier of the same data batch according to the preset data batch range, and divides the source dataset into multiple source data sub-files, each source data sub-file corresponding to a file identifier; The data processing node calculates the corresponding leaf hash value for each source data sub-file, combines the leaf hash values ​​of each source data sub-file to generate the Merkel root hash value and the Merkel proof path, and obtains the generation timestamp. The data processing node combines the generation timestamp, the batch identifier, the Merkel root hash value, the Merkel proof path, multiple leaf hash values, and multiple file identifiers to construct a metadata file, and sends the multiple source data sub-files and the metadata file to the data storage node for storage, so as to obtain the data storage address corresponding to the batch identifier; The data processing node sends the batch identifier, the Merkle root hash value, the data storage address, and the generation timestamp to the blockchain service node, so that the blockchain service node triggers the generation of data storage logs based on the batch identifier, the Merkle root hash value, the data storage address, and the generation timestamp; When the data index node detects the data storage log generated by the blockchain service node, it maps the batch identifier, Merkle root hash value, data storage address, generation timestamp, transaction hash, block identifier, and block timestamp obtained from parsing the data storage log into the database table structure to establish a data query index.

5. The method according to claim 4, characterized in that, The verification client obtains a list of data batches from the data index node, including: The verification client sends a batch information query request through the metadata query interface provided by the data index node; The data index node responds to the batch information query request and generates a data batch list based on multiple batch information in the database table structure; The verification client receives the data batch list returned by the data index node through the batch query interface provided by the data index node.

6. The method according to claim 4, characterized in that, Before the verification client determines the target data storage address corresponding to the target batch identifier and downloads the corresponding target source data sub-file from the data storage node according to the target data storage address, the method further includes: The data index node reads the corresponding metadata file from the data storage node based on the batch identifier and the data storage address; Based on the metadata file, obtain multiple file identifiers corresponding to the multiple source data sub-files associated with the batch identifier.

7. The method according to claim 6, characterized in that, The verification client determines the target data storage address corresponding to the target batch identifier, and downloads the corresponding target source data sub-file from the data storage node according to the target data storage address, including: The verification client sends a file identifier retrieval request through the metadata query interface provided by the data index node; The data index node determines the corresponding target metadata file based on the target batch identifier in the file identifier acquisition request, and reads the corresponding target data storage address and multiple file identifiers according to the target metadata file; The verification client receives the target data storage address and the multiple file identifiers returned by the data index node through the metadata query interface provided by the data index node, and selects a target file identifier from the multiple file identifiers; The verification client downloads the target source data sub-file corresponding to the target file identifier from the data storage node according to the target data storage address.

8. A blockchain-based data verification system, characterized in that, The data verification system comprises verification clients, blockchain service nodes, data storage nodes, data indexing nodes, data acquisition nodes, and data processing nodes, including: The data acquisition node acquires the source dataset and corresponding batch identifier of the same data batch according to the preset data batch range, and divides the source dataset into multiple source data sub-files, each source data sub-file corresponding to a file identifier; The data processing node calculates the corresponding leaf hash value for each source data sub-file, combines the leaf hash values ​​of each source data sub-file to generate the Merkel root hash value and the Merkel proof path, and obtains the generation timestamp. The data processing node combines the generation timestamp, the batch identifier, the Merkel root hash value, the Merkel proof path, multiple leaf hash values, and multiple file identifiers to construct a metadata file, and sends the multiple source data sub-files and the metadata file to the data storage node for storage, so as to obtain the data storage address corresponding to the batch identifier; The data processing node sends the batch identifier, the Merkle root hash value, the data storage address, and the generation timestamp to the blockchain service node, so that the blockchain service node triggers the generation of data storage logs based on the batch identifier, the Merkle root hash value, the data storage address, and the generation timestamp; When the data index node detects the data storage log generated by the blockchain service node, it maps the batch identifier, Merkle root hash value, data storage address, generation timestamp, transaction hash, block identifier and block timestamp obtained from parsing the data storage log into the database table structure to establish a data query index. The verification client obtains a list of data batches from the data index node and selects at least one target batch identifier from the list of data batches. The verification client determines the target data storage address corresponding to the target batch identifier, and downloads the corresponding target source data sub-file from the data storage node according to the target data storage address; The verification client calculates the local hash value of the target source data sub-file and obtains the corresponding target Merkle root hash value from the blockchain service node according to the target batch identifier; The verification client obtains the target Merkel proof path corresponding to the target batch identifier and the local hash value from the data index node; The verification client calculates the root hash value to be confirmed based on the target Merkel proof path and the local hash value; The verification client combines the root hash value to be confirmed with the target Merkle root hash value to verify the target source data sub-file.

9. A blockchain-based data verification device, characterized in that, A verification client is used in a data verification system, which further includes blockchain service nodes, data storage nodes, and data index nodes, including: The first acquisition unit is used to acquire a data batch list from the data index node and select at least one target batch identifier from the data batch list; The download unit is used to determine the target data storage address corresponding to the target batch identifier, and download the corresponding target source data sub-file from the data storage node according to the target data storage address, wherein the data storage node stores multiple data storage addresses corresponding to multiple data batches and multiple source data sub-files associated with each data storage address; The first computing unit is used to calculate the local hash value of the target source data sub-file and to obtain the corresponding target Merkle root hash value from the blockchain service node according to the target batch identifier; The second acquisition unit is used to acquire the target Merkel proof path corresponding to the target batch identifier and the local hash value from the data index node; The second calculation unit is used to calculate the root hash value to be confirmed based on the target Merkel proof path and the local hash value; The verification unit is used by the verification client to verify the target source data sub-file by combining the root hash value to be confirmed with the target Merkle root hash value.

10. A computer device, characterized in that, The computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the blockchain-based data verification method according to any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a plurality of instructions adapted for loading by a processor to execute the blockchain-based data verification method according to any one of claims 1 to 8.

Images