A blockchain-based verifiable provenance method and apparatus

Abstract

The application discloses a kind of verifiable traceability method and device based on block chain, user can carry out traceability query according to the state change of target entity and realize the self-verification of query result, PROV model is supported by expanding block structure and transaction content in chain query, and on the basis of realizing block chain traceability query method, further use the design of MBtree, VO construction and other methods to verify the correctness and integrity of traceability result, to improve the reliability and security of block chain traceability query system.In subgraph traceability query, three types of index structures will be constructed according to different arrangement of triplets, compressed as B+ tree to realize traceability query, and VO is constructed by extending index structure as MBtree to query result, so as to realize the verifiable query result.The application realizes the traceability information query of chain data and the traceability query of multi-modal data such as subgraph, and expands the application range of verifiable traceability query.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchains, and in particular to a verifiable traceability method and device based on a blockchain. BACKGROUND

[0002] Data traceability is a technology for tracing the original data and the evolution process of the target data, and its purpose is to track the origin of the data and reproduce the historical state of the data. In today's big data era, data analysis and evaluation are particularly important to ensure the credibility and security of scientific data, especially in the current industry, such as food safety, drug safety, information traceability, and logistics efficiency improvement. In recent years, the blockchain technology has developed rapidly, and its characteristics of decentralization, openness, tamper resistance, and distributed storage are very suitable for reliably storing traceability data.

[0003] The existing data traceability based on the blockchain is mostly a blockchain traceability system for a specific application scenario, such as a food safety traceability system based on the blockchain. The traceability system is mainly divided into a physical layer, a communication layer, a database layer, and an interface layer, and the blockchain technology is mainly applied to the database layer and the communication layer. In this food traceability system, the identity and parameter information of each product are digitized and stored in the blockchain network, and the identity of the product and the participants is used to maintain the order and reliability of the data through the smart contract. When the product involves a transaction process or the enterprise maintains information internally, the operation log is recorded through the blockchain, and the timestamp technology and asymmetric encryption technology are used to ensure that the data cannot be tampered with. All product information in the system is stored in the form of electronic documents and contains the signature information of the corresponding participants, and when the traceability query operation is performed, only the participants with access rights can read the document content using the key. Therefore, the existing data traceability based on the blockchain mostly implements the traceability query method in a specific application scenario and constructs a blockchain traceability system, but they do not consider the verification of the blockchain traceability query result, which cannot guarantee the correctness and integrity of the query result, making the traceability query system not completely reliable. SUMMARY

[0004] The present application provides a verifiable traceability method and device based on a blockchain, which aims to implement data traceability based on blockchain technology and ensure the verifiability of the query result to solve the practical problems existing in the prior art.

[0005] To achieve the above-mentioned purpose, the present application provides a verifiable traceability method based on a blockchain, which performs the following steps when tracing a series of snapshot partial order combinations of a target entity:

[0006] S11, first, based on the PROV provenance model, the block transaction content and block structure are extended, and the necessary metadata is added in the block chain transaction to support the provenance query;

[0007] S12, the MBtree is constructed for the extended block transaction content block by block, wherein the provenance code procode of each target entity is taken as the node key value for indexing, and the transaction content is stored in the leaf node as the value. Each node calculates the hash value of the value and stores it in the node for the subsequent VO construction;

[0008] S13, the MBtree is searched according to the provenance code of the target entity, and the corresponding search path and neighbor node are stored for the VO construction. Finally, the VO and the query result are returned to the user together;

[0009] S14, the user can recalculate a root hash according to the VO and the result data, and compare it with the root hash value stored in the block to verify the correctness of the provenance result;

[0010] When the graph data expressed in RDF triples of the target entity is traced, the following steps are performed:

[0011] S21, the query statement is constructed by the syntax rules of SPARQL language, the corresponding index structure is constructed in the construction manner of MBtree, and the data items in the triples are encoded from string form to integer ID according to the mapping relationship in the established mapping table. All triples are stored in the leaf nodes of the B+ tree in dictionary order. The hash value of each node is calculated from bottom to top using the MHT construction method, so that the index structure is expanded to MBtree for subsequent VO construction;

[0012] S22, when the query request is initiated, if only a single triple is involved, a range query is performed through the full index. If multiple triples are involved, the triple order is optimized by a connection sorting algorithm first, which can make the matching result of the previous triple as the query condition of the subsequent triple for matching, so as to reduce the number of intermediate results. When multiple intermediate results need to be connected, the selection rate estimation can be used to optimize the connection order. And in the case of selection rate estimation or including the de-duplication operation (DISTINCT) in the query statement, the aggregation index can be used to improve the query efficiency;

[0013] S23, build VO of query result by storing neighbor nodes on the search path of MBtree, if there is only one condition triple in the query statement, return the query result and VO to the user; if the query statement contains multiple condition triples, after optimizing the connection order of triples, build a VO of intermediate result for each selected MBtree index, and finally return the intermediate result, VO corresponding to the intermediate result and the final connection result to the user.

[0014] S24, for the query statement with only one condition triple, the user can calculate a root hash from bottom to top according to the VO and the result data, and compare it with the root hash of the stored MBtree to verify the correctness and integrity of the traceability result; for the query statement containing multiple condition triples, the user can calculate the root hash according to the received intermediate result and the corresponding VO, and compare it with the corresponding MBtree root hash, and re-connect the received intermediate result on the basis of verifying the correctness and integrity of the intermediate result to verify the correctness and integrity of the final traceability result.

[0015] Further, when tracing a series of snapshot partial order combinations of target entities, each target data is attached with a version number, and the version number of each snapshot of a target entity is saved when it is searched, and the continuity of the version number is checked to verify the integrity of the traceability information; at the same time, the critical version block is searched forward and backward, and the continuity of the first appearing target data version number in the block height smaller or larger than the query range and the version number of the critical target data in the query range is verified to ensure the integrity of the traceability information at the critical point of the query range.

[0016] Further, in order to support the PROV model in S11, the block structure and transaction content need to be expanded to include version number, traceability code (entity ID), operation start and end time and other contents that need to be expanded, and three basic classes corresponding to metadata Agent, Entity and Activity are added.

[0017] Further, the S23 selection rate estimation can be optimized by histogram and frequent path method, wherein the histogram estimation is used to estimate the cardinality or selectivity of the query result; the frequent path is used to estimate the selectivity of the path pattern involved in the query.

[0018] Further, the index structure of S21 mainly constructs full indexes for six arrangements of subject, predicate and object (SPO, SOP, OSP, OPS, PSO, POS) in graph data, and constructs additional aggregate indexes (SP, PS, SO, OS, PO, OP) with only two entries and single-value indexes.

[0019] Further, in S22, when the lexicographic compression is stored in triplets with the same index prefix, it can be stored continuously in the leaf node in lexicographic order, that is, only the value changing part is stored in the single leaf page.

[0020] The application also provides a verifiable traceability device based on blockchain, which comprises a chain query module and a subgraph query module, wherein the chain query module is a partial order combination of a series of snapshots of a target entity, comprising a block expansion submodule, an MBtree construction submodule, a VO construction submodule and a verification submodule.

[0021] The block expansion submodule is used to expand the block transaction content and the block structure and add necessary metadata to support traceability query.

[0022] The MBtree construction submodule constructs MBtree for the expanded block transaction content block by block, wherein the traceability code procode of each target entity is used as the node key value for indexing, and the transaction content is stored as value in the leaf node.

[0023] The VO construction submodule searches the MBtree according to the traceability code of the target entity and stores the corresponding search path and neighbor nodes to construct VO, and finally returns the VO and the query result to the user together.

[0024] The verification submodule recalculates a root hash according to the VO and the result data, and compares it with the root hash value stored in the block to verify the correctness of the traceability result.

[0025] The subgraph query module is to trace the graph data expressed in RDF triplets of the target entity, comprising an MBtree construction submodule, a query optimization submodule, a VO construction submodule and a verification submodule, wherein,

[0026] The MBtree construction submodule constructs a query statement according to the syntax rules of the SPARQL language, constructs a corresponding index structure in the construction mode of the MBtree, and encodes data items in triples from a string form into an integer ID according to the mapping relationship in the established mapping table, and compresses and stores all triples in the leaf nodes of the B+ tree in dictionary order, and calculates the hash value of each node from bottom to top using the method of constructing the MHT, thereby expanding the index structure into the MBtree for subsequent construction of the VO.

[0027] The query optimization submodule, when initiating a query request, if only a single triple is involved, performs a range query through the full index, if multiple triples are involved, first optimizes the triple order through a connection sorting algorithm, which can make the matching result of the previous triple serve as the query condition of the subsequent triple for matching, thereby reducing the number of intermediate results, when multiple intermediate results need to be connected, the selection rate estimation can be used to optimize the connection order, and the aggregation index can be used to improve the query efficiency in the case of selection rate estimation or de-duplication operation in the query statement.

[0028] The VO construction submodule constructs the VO of the query result by storing the neighbor nodes on the search path of the MBtree, if there is only one conditional triple in the query statement, the query result and the VO are returned to the user together, if the query statement contains multiple conditional triples, after optimizing the triple connection order, a VO of the intermediate result is constructed for each selected MBtree index, and the intermediate result, the VO corresponding to the intermediate result and the final connection result are returned to the user.

[0029] The verification submodule, when there is only one conditional triple in the query statement, the user can calculate a root hash from bottom to up according to the VO and the result data, and compare it with the stored root hash of the MBtree to verify the correctness and integrity of the traceability result, when the query statement contains multiple conditional triples, the user can calculate the root hash again according to the received intermediate result and the corresponding VO, and compare it with the corresponding MBtree root hash, and on the basis of verifying the correctness and integrity of the intermediate result, the received intermediate result is reconnected to verify the correctness and integrity of the final traceability result.

[0030] Compared with the prior art, the present application has the following advantages and beneficial effects:

[0031] (1) The traceability information query of the present application is directly based on the query of the MB+ tree, and in the query process, the corresponding verification object VO is established according to the neighbor nodes on the search path of the query result to verify the correctness of the query result.

[0032] (2) The chain traceability query of the present application will expand the block transaction structure, so that each transaction involving the target entity has a unique version number for the integrity verification of the traceability result.

[0033] (3) In the subgraph traceability query of the present application, the present application will construct three types of index structures according to different arrangement modes of triples, compress the storage as B+ tree to realize traceability query, and expand the index structure as MBtree to realize the VO construction of the query result, so as to realize the verifiable query result. BRIEF DESCRIPTION OF DRAWINGS

[0034] The accompanying drawings, which are included to provide a further understanding of the present application and constitute a part of this application, illustrate certain illustrative embodiments of the present application and together with the description serve to explain the present application. In the drawings:

[0035] Figure 1 A blockchain-based verifiable traceability method chain query flowchart is provided for the embodiments of the present application;

[0036] Figure 2 A blockchain-based verifiable traceability method subgraph query flowchart is provided for the embodiments of the present application;

[0037] Figure 3 A blockchain-based verifiable traceability device chain query module structure schematic diagram is provided for the embodiments of the present application;

[0038] Figure 4 A blockchain-based verifiable traceability device subgraph query module structure schematic diagram is provided for the embodiments of the present application;

[0039] Figure 5 A blockchain-based verifiable traceability method VO verification process schematic diagram is provided for the embodiments of the present application;

[0040] The implementation of the present application, functional features and advantages will be further described with reference to the accompanying drawings. DETAILED DESCRIPTION

[0041] In order to make the purpose, technical scheme and advantages of the embodiments of the present application more clear, the technical scheme of the embodiments of the present application will be described clearly and completely below with reference to the accompanying drawings. Obviously, the described embodiments are part of the embodiments of the present application, not all. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0042] The following is the interpretation of the relevant English words involved in the specification:

[0043] 1. PROV: Provenance is a model used to describe and represent the origin of data and entities. The PROV provenance model aims to reveal the source, evolutionary history, and interrelationships of data, entities, and activities. PROV defines three core data types and their relationships:

[0044] (1) Entity: An entity is a physical or digital object that is a materialized representation of data or generated during the data generation process; an entity can be a file, a database record, sensor data, etc.

[0045] (2) Activity: An activity represents an operation or process performed on an entity, including data processing, calculation, and transformation. Activities can create, use, or affect entities;

[0046] (3) Agent: An agent is an entity that performs activities, which can be a person, organization, system, etc.; the agent is responsible for performing activities and is responsible for the creation, use or influence of the entity.

[0047] PROV takes a data modeling perspective and considers the current state of technology in the fields of information representation and data sharing. Therefore, PROV provides classes, attributes, and constraints, and utilizes semantic web technologies (such as OWL2 ontology, XML, Dublin Core, etc.) to model source information.

[0048] Among the more important ones is PROV-DM (released as a W3C standard): the core concepts of the data model, a general vocabulary and concept used to describe traceability, applied to a set of constraints defined by PROV-CONSFRAINTS.

[0049] 2. VO, or Verifiable Object, in blockchain systems typically refers to an entity constructed by a Service Provider (SP) to verify the correctness of query results. A verifiable query is a mechanism used to verify whether query results returned by a remote or untrusted data source have been tampered with and are consistent with the expected query results. This invention introduces Verifiable Objects (VOs) to verify the reliability of query results. The role of a VO is to receive query results and verify their correctness using pre-shared information, algorithms, or keys. It can be an independent entity, service, program, or system responsible for verifying the integrity and trustworthiness of query results. Verifiable objects can ensure the security and consistency of results based on digital signatures, hash functions, cryptographic algorithms, or other verification mechanisms.

[0050] 3、MHT: Full name is Merkle Hash Tree, also known as Merkle tree or hash tree, which is a binary tree structure based on hash function. Its construction process mainly has the following steps:

[0051] (1) Data blocking: the data used to build MHT is blocked by a fixed size (usually a power of 2), if it cannot be divided into an integer block, it can be made into a power of 2 by padding and other ways;

[0052] (2) Hash operation: apply hash function to each data block to get the corresponding hash value;

[0053] (3) Building leaf nodes: the hash value of each data block is used as a leaf node, and the leaf node layer is built in left-to-right order;

[0054] (4) Construction of the whole MHT: starting from the leaf node layer, hash calculation is performed on every two adjacent nodes, that is, their hash values are concatenated and then the hash function is used to calculate the hash value of the parent node; calculate layer by layer upwards until the root node is obtained.

[0055] 4、RDF, namely Resource Description Framework, is a description method of graph database, or a kind of using protocol. It describes the direct relationship between things in the form of "triple". "Triple" is the core concept of RDF, which refers to two things and the relationship (predicate) between them. In syntax, it is presented as "subject + predicate + object", and the predicate must have a clear definition and each predicate has a clear URL. Each URL can contain multiple predicates, which are distinguished by the form of "prefix predicate".

[0056] 5、MBtree, namely Merkle-BTree, its working principle is similar to B+-tree, which is also composed of ordinary B+-tree nodes, these nodes are expanded to a hash value related to each pointer entry. The hash value related to the entry on the leaf node is calculated according to the database record itself, and the hash value related to the index node entry is calculated on the concatenation of the hash values of its child nodes.

[0057] 6、hash, mainly refers to the hash function, is an algorithm that converts input data into a fixed length output. It maps data of arbitrary length to a fixed length hash value (also known as digest, fingerprint or signature). Hash function is a one-way function, which cannot restore the original input data from the hash value. This makes the hash function play an important role in data security, integrity verification and encryption. In particular, in data integrity verification, by comparing the expected hash value and the actually calculated hash value, it can be verified whether the data has been tampered with during transmission or storage.

[0058] The prior art blockchain-based data traceability technology mostly realizes the traceability query method under a specific application scenario and constructs a blockchain traceability system, but they do not consider the verification problem of the traceability query result of the blockchain, which does not guarantee the correctness and integrity of the query result, making the traceability query system not completely reliable. The verifiable traceability method provided by the specification is mainly applicable to chain traceability query and traceability query for graph data. Chain traceability query refers to the traceability information of the query target entity stored in a series of versions, and subgraph query refers to the evolution history of the target entity stored in the graph database. Most of the traceability information in the application scenario can be stored in these two ways, so our invention can be applied to most application scenarios.

[0059] The technical solutions provided by the embodiments of the specification will be described in detail below with reference to the accompanying drawings.

[0060] The embodiments of the specification provide a verifiable traceability method based on a blockchain. When chain query is performed, that is, the traceability information of the target entity is traced in a series of snapshot partial order combinations, as shown in Figure 1 For example, the evolution history of the target entity in a certain time period is queried, the following steps are mainly performed:

[0061] S11, first, based on the PROV traceability model, the block transaction content and the block structure are extended, and necessary metadata is added to the blockchain transaction to support traceability query;

[0062] S12, the MBtree is constructed for each block transaction content, wherein the traceability code procode of each target entity is taken as the node key value for indexing, and the transaction content is stored as the value in the leaf node. Each node calculates the hash value of the value and stores it in the node for subsequent VO construction;

[0063] S13, search the MBtree according to the traceability code of the target entity and store the corresponding search path and neighbor nodes to construct the VO, and finally return the VO and the query result to the user together;

[0064] S14, the user can recalculate a root hash according to the VO and the result data, and compare it with the root hash value stored in the block to verify the correctness of the traceability result;

[0065] According to the design of the block transaction structure, each target data is attached with a version number, and the version number of each snapshot of a target entity is saved. The continuity of the version number is checked to verify the integrity of the traceability information. Meanwhile, the block before and after the critical block is searched to verify the continuity of the version number of the first target data in the block with a height less than or greater than the query range and the version number of the critical target data in the query range, so as to ensure the integrity of the traceability information at the critical point of the query range.

[0066] The expansion of the block structure mainly refers to embedding an MBtree as an index in each block for the construction of the traceability information and the VO in the chain traceability query. The transaction content in the general block is relatively simple, and several data items such as the version number, the traceability code (entity ID), the start and end time of the operation, etc. are needed to be added to improve the traceability information, so as to facilitate the query of the traceability information of the corresponding target entity. In order to support the PROV model, three basic classes corresponding to the metadata: Agent, Entity, Activity (corresponding to operation) are also needed to be added.

[0067] When the subgraph query is performed, that is, the graph data of the target entity is expressed in the form of RDF triples, the following steps are performed as shown in the following figure: Figure 2

[0068] S21, a query statement is constructed by using the syntax rules of SPARQL language, and an index structure is constructed by using the construction method of MBtree. According to the mapping relationship in the established mapping table, the data items in the triples are encoded from string form to integer ID in sequence, and all the triples are compressed and stored in the leaf nodes of the B+ tree in dictionary order. The hash value of each node is calculated from bottom to top by using the method of constructing MHT, so as to expand the index structure into MBtree for the construction of the subsequent VO;

[0069] ​S22, when initiating a query request, if only a single triple is involved, then a range query is performed through the full index; if multiple triples are involved, then the triple order is optimized through a connection sorting algorithm, which can make the matching result of the previous triple serve as the query condition for the subsequent triple matching, so as to reduce the number of intermediate results; when multiple intermediate results need to be connected, rate estimation can be performed to optimize the connection order; and in the case of rate estimation or the query statement including a de-duplication operation (DISTINCT), an aggregate index can be used to improve the query efficiency;

[0070] S23, a VO of the query result is constructed by storing the neighbor nodes on the search path of the MBtree, if there is only one conditional triple in the query statement, the query result and the VO are returned to the user together; if the query statement contains multiple conditional triples, after optimizing the triple connection order, a VO of the intermediate result is constructed for each selected MBtree index, and the intermediate result, the VO corresponding to the intermediate result and the final connection result are finally returned to the user.

[0071] S24, for the query statement with only one conditional triple, the user can calculate a root hash from the bottom up according to the VO and the result data, and compare it with the stored root hash of the MBtree to verify the correctness and integrity of the traceability result; for the query statement containing multiple conditional triples, the user can calculate the root hash again according to the received intermediate result and the corresponding VO, and compare it with the corresponding MBtree root hash, and on the basis of verifying the correctness and integrity of the intermediate result, the received intermediate result is reconnected to verify the correctness and integrity of the final traceability result.

[0072] Among them, the index structure is the most important data structure in the application, mainly aiming at the six arrangement modes of subject, predicate and object in graph data (SPO, SOP, OSP, OPS, PSO, POS) to construct full index, and to construct additional aggregate index (SP, PS, SO, OS, PO, OP) with only two entries and single value index.

[0073] Among them, the lexicographic compression storage can compress and store the triples with the same index prefix in the leaf node in lexicographic order, that is, only the value changing part is stored in the single leaf page.

[0074] Among them, the specific verification process of VO is as follows Figure 5The target data of the query is stored in node 1, and the query route root->v5|v7->v5|v6 and the neighbor nodes v1|v3 and v7|v8 of each node on the path, that is, node 2 in the figure, are recorded during the query process, and the ordered sequence of the neighbor nodes is the VO returned to the user. When the VO is verified, the user performs corresponding hash operations from bottom to top using the received result and the VO to obtain root', and then compares root' with root. If they are equal, it is proved that the query result is correct.

[0075] Histograms and frequent paths can be used in selectivity estimation for query optimization, where histograms are mainly used to estimate the cardinality or selectivity of query results. It mainly estimates the cardinality of individual triple patterns by (1) counting the number of triples, the cardinality of different prefixes, and the cardinality of individual triple patterns; (2) when literal is not part of the index prefix, the result cardinality is derived by reordering; (3) counting the result cardinality of triples in the bucket after joining with other triples. Therefore, by understanding the cardinality estimation information of each variable, the system can better select the plan for executing the query and optimize the order of query operations.

[0076] Frequent paths are a query optimization technique based on the frequency of path occurrence, which is used to estimate the selectivity of path patterns involved in the query. This method can precompute the most frequent paths and obtain their result cardinality and path description p1...pn. Using this information, the join cardinality of frequent paths appearing in the query can be accurately predicted. Compared with histograms, frequent paths are more accurate, but their scope of application is limited - they are suitable for some common join paths such as star-shaped graphs or chain-shaped paths.

[0077] The embodiment of the present application also provides a blockchain-based verifiable traceability device, which comprises a chain query module and a subgraph query module.

[0078] The chain query module is used to trace a series of snapshot partial order combinations of a target entity, and comprises a block expansion submodule, an MBtree construction submodule, a VO construction submodule and a verification submodule. Figure 3

[0079] The block expansion submodule is used to expand the block transaction content and the block structure and add necessary metadata to support traceability queries.

[0080] ​The MBtree construction submodule constructs the MBtree for the expanded block transaction content block by block, wherein the provenance code procode of each target entity is indexed as a node key value, and the transaction content is stored as a value in the leaf node. Each node calculates the hash value of the value and stores it in the node for subsequent VO construction;

[0081] The VO construction submodule searches the MBtree according to the provenance code of the target entity, stores the corresponding search path and neighbor nodes, and constructs the VO. Finally, the VO and the query result are returned to the user together;

[0082] The verification submodule recalculates a root hash according to the VO and the result data, and compares it with the root hash value stored in the block to verify the correctness of the provenance result;

[0083] The subgraph query module is to trace the graph data expressed in RDF triples of the target entity, including the MBtree construction submodule, the query optimization submodule, the VO construction submodule and the verification submodule, as shown in Figure 4

[0084] The MBtree construction submodule constructs the query statement by the syntax rules of the SPARQL language, constructs the corresponding index structure in the construction manner of the MBtree, encodes the data items in the triples from the string form to the integer ID according to the mapping relationship in the established mapping table, and compresses and stores all triples in the leaf nodes of the B+ tree in the dictionary order. The hash value of each node is calculated from bottom to top using the MHT construction method, so as to expand the index structure into the MBtree for subsequent VO construction;

[0085] The query optimization submodule, when initiating a query request, if only a single triple is involved, performs a range query through full indexing. If multiple triples are involved, the triple order is optimized through a connection sorting algorithm first, so that the matching result of the previous triple is used as the query condition of the subsequent triple for matching, to reduce the number of intermediate results. When multiple intermediate results need to be connected, the selection rate estimation can be used to optimize the connection order. In the case of selection rate estimation or including a de-duplication operation (DISTINCT) in the query statement, an aggregation index can be used to improve the query efficiency;

[0086] ​The VO construction submodule constructs the VO of the query result by storing the neighbor nodes on the search path of the MBtree. If the query statement contains only one conditional triple, the query result and the VO are returned to the user together. If the query statement contains multiple conditional triples, after optimizing the connection order of the triples, a VO of an intermediate result is constructed for each selected MBtree index, and the intermediate result, the VO corresponding to the intermediate result and the final connection result are finally returned to the user.

[0087] The verification submodule verifies the correctness and integrity of the traceability result by comparing the root hash calculated by the user from the VO and the result data with the root hash of the stored MBtree. For the query statement containing multiple conditional triples, the user can calculate the root hash from the received intermediate result and the corresponding VO, and compare it with the corresponding MBtree root hash. On the basis of verifying the correctness and integrity of the intermediate result, the received intermediate result is reconnected to verify the correctness and integrity of the final traceability result.

[0088] One embodiment is to illustrate the application of chain query method for traceability query of drug information:

[0089] In this application scenario, several types of drug information are stored in the blockchain system, including entity information such as inventory, sales, circulation, and location of the drug, and agent information such as drug manufacturers, drug wholesalers, drug retailers, and hospitals. The related operations on the entity include production, circulation, sales, and use. The transaction structure in the block is defined as follows:

[0090]

[0091]

[0092] The entity state database structure is defined as follows:

[0093] proCode EntityName amount parameters 023 Drug Inventory 500 Last Record Block Height

[0094] The user requires the inventory change information of drug a within the specified block height range [h, H]:

[0095] (1) Find the traceability code of drug a from the entity state database for query;

[0096] (2) Query the traceability information of each block within the specified block height range, search the MBtree of each block according to the traceability code to get the transaction record of the entity, and record the search path and the corresponding neighbor nodes for the construction of VO in the search process.

[0097] (3) From the block height h, search forward block by block, trace the inventory information transaction record involving the medicine a, verify the integrity of the query result by finding the continuity of the entity version in the first record and the first transaction record searched in [h, H], and search from the block height H to the rear.

[0098] (4) Return the traced information and the VO constructed for integrity and correctness verification to the customer.

[0099] Another embodiment is used to illustrate the application of subgraph trace information query in the method:

[0100] There is a graph data showing the life information of Abraham Lincoln, which is stored as a triple table in RDF language as shown in the following figure:

[0101]

[0102] (1) The triples are encoded into integer IDs for subsequent index construction, and the mapping table is as follows:

[0103] ID Value 0 y:Abraham_Lincoln 1 hasName 2 "Abraham Lincoln” 3 bornOnDate 4 "1809-02-12” 5 diedOnDate 6 "1865-04-15” 7 y:Washington_DC 8 "Washington D.C.” 9 foundingYear 10 "1790”

[0104] (2) For the encoded triples, construct full permutation index, aggregate index and single value index and compress them into MBtree, and the full index triple table is shown in the following figure.

[0105]

[0106] (3) The user initiates a query request to the system, if the query condition only involves a single triple, then according to the matching condition, select the appropriate full permutation index to convert into a range query processing; if the query condition involves multiple triples, first perform triple sorting optimization, then select the appropriate index structure for matching query, finally perform connection operation on the intermediate result to obtain the final subgraph matching result.

[0107] The application helps to create an industrial environment of information transparency, data security and value interconnection, so that users can trace the state change of target entities and realize self-verification of query results, and the application not only realizes trace information query of chain data, but also realizes trace information query of multi-modal data such as graph, which expands the application range of verifiable trace information query.

[0108] It should be apparent to those skilled in the art that the modules or steps of the application described above can be implemented with a general purpose computing device, which can be centralized on a single computing device or distributed over a network of multiple computing devices, and optionally implemented with program code executable by a computing device, which can be stored in a storage device and executed by a computing device, and in some cases, the steps shown or described can be executed in a different order than shown, or made into individual integrated circuit modules, or multiple modules or steps made into a single integrated circuit module. Thus, the application is not limited to any particular combination of hardware and software.

Claims

1. A blockchain-based verifiable provenance method, characterized in that, The method comprises the following steps: When tracing a target entity as a partial order combination of a series of snapshots, the following steps are performed: S11, first, extend the block transaction content and block structure based on the PROV provenance model, and support provenance query by adding necessary metadata in the block chain transaction; S12, build an MBtree for the extended block transaction content block by block, wherein the provenance code procode of each target entity is indexed as a node key value, and the transaction content is stored as a value in the leaf node. Each node calculates the hash value of the value and stores it in the node for subsequent VO construction; S13, search the MBtree according to the provenance code of the target entity, store the corresponding search path and neighbor nodes for VO construction, and finally return the VO and the query result to the user together; S14, the user can re-calculate a root hash according to the VO and the result data, and compare it with the root hash value stored in the block to verify the correctness of the provenance result; When tracing a target entity as graph data expressed in RDF triples, the following steps are performed: S21, build a query statement by constructing an index structure in the form of an MBtree according to the syntax rules of the SPARQL language; and according to the mapping relationship in the mapping table, encode the data items in the triples from a string form to an integer ID one by one, and compress all triples in dictionary order and store them in the leaf nodes of a B+ tree; use the MHT construction method to calculate the hash value of each node from bottom to top, thereby expanding the index structure into an MBtree for subsequent VO construction; S22, when initiating a query request, if only a single triple is involved, a range query is performed through the full index; if multiple triples are involved, first optimize the triple order through a connection sorting algorithm, which can make the matching result of the previous triple serve as the query condition for the subsequent triple matching to reduce the number of intermediate results; when multiple intermediate results need to be connected, a selection rate estimation can be performed to optimize the connection order; and in the case of selection rate estimation or de-duplication operation included in the query statement, an aggregation index can be used to improve query efficiency; S23, build a VO of the query result by storing the neighbor nodes on the search path of the MBtree, if there is only one conditional triple in the query statement, return the query result and the VO to the user; if the query statement contains multiple conditional triples, after optimizing the triple connection order, a VO of the intermediate result is constructed for each selected MBtree index, and the intermediate result, the VO corresponding to the intermediate result, and the final connection result are returned to the user; S24, for the query statement with only one condition triple, the user can calculate a root hash from bottom to top according to the VO and the result data, and compare it with the root hash of the stored MBtree to verify the correctness and integrity of the provenance result; for the query statement containing multiple condition triples, the user can calculate the root hash again according to the received intermediate result and the corresponding VO, and compare it with the corresponding MBtree root hash, and reconnect the received intermediate result on the basis of verifying the correctness and integrity of the intermediate result to verify the correctness and integrity of the final result of the provenance.

2. The blockchain-based verifiable provenance method of claim 1, wherein, When tracing a series of snapshot partial order combinations of target entities, each target data is attached with a version number, and the version number of each snapshot of the target entity is saved. The continuity of the version number is checked to verify the integrity of the provenance information. Meanwhile, the critical version block is searched forward and backward by block to verify the continuity of the first appearing target data version number in the block height smaller than or greater than the query range and the version number of the critical target data in the query range, so as to ensure the integrity of the provenance information at the critical point of the query range. 3.The blockchain-based verifiable provenance method of claim 1, wherein, In order to support the PROV model in S11, the version number, the provenance code, the operation start and end time and other contents to be expanded are added to the block structure and transaction content, and three basic classes corresponding to the metadata Agent, Entity and Activity are added. 4.The blockchain-based verifiable provenance method of claim 1, wherein, The selection rate estimation in S23 can be optimized by histogram and frequent path methods. The histogram estimation is used to estimate the cardinality or selectivity of the query result, and the frequent path is used to estimate the selectivity of the path pattern involved in the query. 5.The blockchain-based verifiable provenance method of claim 1, wherein, The index structure in S21 constructs full indexes for six permutation modes of subject, predicate and object in graph data, and constructs additional aggregate indexes and single value indexes with only two entries. 6.The blockchain-based verifiable provenance method of claim 1, wherein, In S22, when the triple has the same index prefix, the triples can be stored continuously in the leaf node in lexicographical order, that is, only the value changing part is stored in the single leaf page. 7.A blockchain-based verifiable provenance device for implementing the method of claim 1, characterized in that, The device comprises a chain query module and a subgraph query module. The chain query module traces a series of snapshot partial order combinations of target entities, and comprises a block expansion submodule, an MBtree construction submodule, a VO construction submodule and a verification submodule. The block expansion submodule is used to expand the block transaction content and the block structure and add necessary metadata to support provenance query. The MBtree construction submodule constructs MBtree for the expanded block transaction content block by block. The provenance code procode of each target entity is used as the node key value for indexing, and the transaction content is stored as the value in the leaf node. The hash value of the value of each node is calculated and stored in the node for subsequent VO construction. The VO construction submodule searches the MBtree according to the trace code of the target entity and stores the corresponding search path and neighbor nodes to construct the VO, and finally returns the VO and the query result to the user together; The verification submodule recalculates a root hash according to the VO and the result data, and compares it with the root hash value stored in the block to verify the correctness of the trace result; The subgraph query module traces the graph data expressed in RDF triples of the target entity, including an MBtree construction submodule, a query optimization submodule, a VO construction submodule, and a verification submodule, wherein, The MBtree construction submodule constructs a query statement in the syntax rules of the SPARQL language, constructs a corresponding index structure in the construction mode of the MBtree, encodes the data items in the triples from a string form to an integer ID according to the mapping relationship in the established mapping table, and compresses and stores all triples in the leaf nodes of the B+ tree in dictionary order; the hash value of each node is calculated from bottom to top using the MHT construction method, so as to expand the index structure into the MBtree for subsequent VO construction; The query optimization submodule, when initiating a query request, if only a single triple is involved, performs a range query through full indexing; if multiple triples are involved, the triple order is optimized through a connection sorting algorithm first, so that the matching result of the previous triple is used as the query condition of the subsequent triple for matching to reduce the number of intermediate results; when multiple intermediate results need to be connected, selection rate estimation can be performed to optimize the connection order; and in the case of selection rate estimation or de-duplication operation included in the query statement, an aggregation index can be used to improve query efficiency; The VO construction submodule constructs the VO of the query result by storing the neighbor nodes on the search path of the MBtree; if the query statement contains only one conditional triple, the query result and the VO are returned to the user together; if the query statement contains multiple conditional triples, after optimizing the triple connection order, a VO of the intermediate result is constructed for each selected MBtree index, and the intermediate result, the VO corresponding to the intermediate result, and the final connection result are returned to the user; For a query statement containing only one conditional triple, the user can calculate a root hash from bottom to top according to the VO and the result data, and compare it with the root hash of the stored MBtree to verify the correctness and integrity of the trace result; for a query statement containing multiple conditional triples, the user can calculate a root hash according to the received intermediate result and the corresponding VO, and compare it with the corresponding MBtree root hash, and on the basis of verifying the correctness and integrity of the intermediate result, the received intermediate result is reconnected to verify the correctness and integrity of the final trace result.

Images