A blockchain data traceability query optimization method

Abstract

The application discloses a kind of blockchain data traceability query optimization methods, by introducing the method of cache optimization, utilize cache to reduce the number of disk IO in traceability, improve the efficiency of traceability search, while multi-level cache structure is designed, the problem that cache hit rate is not high under the condition that the memory resource of full node is limited is solved, that is, while giving consideration to the consumption of memory resource in the improvement of cache hit rate, reduce the burden of full node.A kind of blockchain data traceability query optimization method first by the node in network to full node of blockchain initiates traceability query request, then in full node query cache, finally carries out consistency check to full node, realizes blockchain data traceability query.The application improves the traceability query efficiency of blockchain system, query credibility, with certain practicality.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of blockchain data query, and particularly relates to a blockchain data traceability query optimization method. BACKGROUND

[0002] With the rise of concepts such as Ethereum, WEB3.0, the underlying core blockchain technology has attracted more and more attention. "Blockchain" has entered the public view and become the focus of society. Blockchain technology is a decentralized distributed storage ledger realized by using encryption algorithms, consensus mechanisms and other technologies. In essence, a blockchain is a distributed shared database, and the data or information stored therein has the characteristics of "unforgeable", "full trace", "traceable", "transparent", "collective maintenance", etc. Blockchain provides new possibilities for solving data credible storage problems with its characteristics of decentralization, non-tamperability, multi-party sharing and trusted traceability. With the application of blockchain technology, more and more Internet key data will be stored on the blockchain, and data credible traceability has gradually become a hot topic.

[0003] In the blockchain, the consensus algorithm is responsible for data writing. In the prior art, many studies have made good progress in how to improve the efficiency of the consensus algorithm, but there are relatively few studies on the read performance of the blockchain database, i.e. query processing and traceability retrieval. Data traceability is an important feature of blockchain to ensure data credibility and traceability, and it has non-negligible application value in the fields of finance, supply chain, digital asset rights confirmation, etc. In the existing blockchain system, data traceability query mostly adopts the original retrieval method, i.e. traversing all historical blocks from the current block, or traversing all historical versions of the data according to the PreHash field in the data to obtain the complete data traceability link.

[0004] The original traceability query method of the blockchain system uses the method of sequential traceability, which brings a large number of disk IO and greatly limits the efficiency of traceability query. In the scenario where the demand for data traceability is increasing, the original traceability query method has become inadequate. To improve the traceability efficiency of the blockchain system and reduce the large amount of disk redundancy IO in traceability query, introducing a cache mechanism for traceability query is an effective method. However, the full node of the blockchain has consumed a large amount of computing and storage resources in network consensus and data storage, and in the case of limited computing and storage resources, there are problems such as low cache hit rate, low traceability query efficiency and heavy burden on the full node when designing traceability cache for the full node. SUMMARY

[0005] In order to overcome the deficiencies in the prior art, the application provides a blockchain data traceability query optimization method, which introduces a multi-level cache method to reduce the number of disk IO times in traceability by using cache, and designs a multi-level cache structure to alleviate the problem of low cache hit rate and no significant reduction in the number of disk IO times caused by limited memory resources in the existing cache technology in the traceability query process; the blockchain data traceability query optimization method can improve the traceability query cache hit rate and reduce the number of disk IO times in the traceability query process under limited storage consumption, so as to improve the efficiency of data traceability and provide more efficient query technology support for future large-scale blockchain traceability application scenarios.

[0006] The technical scheme of the application is:

[0007] A blockchain data traceability query optimization method, comprising the following steps:

[0008] Step 1, input the target data identification keyword key, and initiate a traceability query request by the node in the network to the blockchain full node, the request containing the traceability target data identification keyword key, the full node receiving the request, querying the latest version hash value LatestHash and the latest data LatestData of the key corresponding data in the current blockchain account, recorded as (LatestHash, LatestData);

[0009] Step 2, querying the key in the cache of the blockchain full node;

[0010] Step 2.1, if the key corresponding data does not exist in the cache of the blockchain full node, then (LatestHash, LatestData) is traversed in the current blockchain account to obtain the complete traceability chain (LatestHash, LatestData)→...(Hash_0, Data_0) and return, and finally the complete traceability chain obtained by the traversal is added to the key corresponding cache, and the traceability query of the key is ended;

[0011] Step 2.2, if the key corresponding data exists in the cache, then the complete traceability chain (Hash_n, Data_n)→(Hash_n-1, Data_n-1)...(Hash_0, Data_0) corresponding to the key is retrieved in the cache, and step 3 is executed;

[0012] Step 3, the full node performs consistency check, compares the LatestHash obtained in step 1 with the Hash_n in (Hash_n, Data_n) retrieved in the cache in step 2, and performs traceability integrity check;

[0013] Step 3.1, if the LatestHash is consistent with Hash_n, then the obtained (Hash_n, Data_n)→(Hash_n-1, Data_n-1)...(Hash_0, Data_0) in the cache is the complete traceability chain of the latest version, and the result is returned, and the traceability query of the key is ended.

[0014] Step 3.2, if the LatestHash is inconsistent with Hash_n, then (Hash_n, Data_n) is retrieved from (LatestHash, LatestData) to (Hash_n, Data_n) in the blockchain, (LatestHash, LatestData)→...(Hash_n, Data_n) is obtained, which is added to the cache corresponding to the key to ensure the consistency of the cache and the data in the blockchain ledger, and is spliced with (Hash_n, Data_n)→(Hash_n-1, Data_n-1)...(Hash_0, Data_0) retrieved in the cache of the full node of the blockchain in step 2 to form the complete traceability chain (LatestHash, LatestData)→...(Hash_n, Data_n)→(Hash_n-1, Data_n-1)...(Hash_0, Data_0) of the latest version, and the result is returned, and the traceability query of the key is ended.

[0015] Further, the cache in the full node in step 2 is a multi-level cache structure, including a first-level cache and a second-level cache, the first-level cache stores the hash values and data of each historical version of the data of a certain key identifier, i.e. (Hash_n, Data_n)→(Hash_n-1, Data_n-1)...(Hash_0, Data_0), and the second-level cache only stores the hash values of each historical version of the data, i.e. (Hash_n)→(Hash_n-1)...(Hash_0), when the first-level cache reaches the storage limit, a degradation mechanism is triggered to degrade the cache of the key data with lower query frequency to the second-level cache, and when the second-level cache reaches the upper limit, all data in the second-level cache is removed to save the memory space occupation and improve the cache hit rate.

[0016] Further, the complete traceability chain obtained by traversing in step 2.1 is added to the first-level cache corresponding to the key.

[0017] Further, in step 2.2, if the data corresponding to the key exists in the cache and exists in the first-level cache, the complete traceability chain stored in the cache is retrieved from the first-level cache, that is, (Hash_n, Data_n)→(Hash_n-1, Data_n-1)...(Hash_0, Data_0); if the data exists in the second-level cache, the hash values of each historical version (Hash_n)→(Hash_n-1)...(Hash_0) are taken out from the second-level cache, and then the data corresponding to each hash value is batched from the underlying database of the blockchain to obtain the traceability chain (Hash_n, Data_n)→(Hash_n-1, Data_n-1)...(Hash_0, Data_0), which is put into the first-level cache for cache upgrade.

[0018] The effect of the present application is that, compared with the prior art, the present application provides a blockchain data traceability query optimization method. In the process of blockchain data traceability query, a cache optimization method is introduced, the number of disk IO interactions in data traceability query is reduced, and the efficiency of traceability query is improved. At the same time, considering the limited computing and storage resources of the full node of the blockchain, a multi-level cache structure is designed for the full node, with small computing and storage resource overhead, the cache hit rate is improved, the efficiency of traceability query is improved, and it has certain practicality and application value. BRIEF DESCRIPTION OF DRAWINGS

[0019] Figure 1 is a flowchart of a blockchain data traceability query optimization method in an embodiment of the present application.

[0020] Figure 2 is a blockchain data storage model diagram in an embodiment of the present application.

[0021] Figure 3 is a multi-level cache structure diagram in an embodiment of the present application.

[0022] Figure 4 is a traceability query time comparison diagram in a comparative example of the present application. DETAILED DESCRIPTION

[0023] In order to make the above-mentioned purposes, features and advantages of the present application more apparent and easy to understand, the present application will be further described in detail below with reference to the drawings and specific embodiments. The following embodiments are used to illustrate the present application, but not to limit the scope of the present application.

[0024] EMBODIMENT

[0025] As shown in Figure 1 , a blockchain data traceability query optimization method includes the following steps:

[0026] In the present application, the full node blockchain ledger stores complete data, such as Figure 2 As shown, the data is identified by the key, and different data of the same key represents different versions of the data identified by the key. The PreHash in the data can be traced back to the previous historical version of the data, and in turn to the initial version, which constitutes the complete traceability chain of the key data, i.e. the historical modification track of the key data.

[0027] S1: The node in the network initiates a traceability query request to the blockchain full node, and the request contains a traceability target data identification key. After receiving the request, the full node queries the latest version hash and data (LatestHash, LatestData) of the key corresponding data in the current blockchain ledger, which specifically includes:

[0028] S1.1: The node in the network initiates a traceability query request to the blockchain full node, and the request contains a traceability query target key data identification, which aims to trace all historical version information of the data identified by the key to form a complete traceability chain for the data identified by the key.

[0029] S1.2: The full node processes the request. The full node stores the complete blockchain ledger at the current time. After receiving the request, the full node queries the latest version hash LatestHash and the latest data LatestData of the key corresponding data in the current blockchain ledger, denoted as (LatestHash, LatestData).

[0030] S2: Full node query cache. In particular, as shown in Figure 3 The cache in the full node is a multi-level cache structure composed of a first-level cache and a second-level cache. The first-level cache stores the hash values and data of each historical version of the data identified by a key, i.e. (Hash_n, Data_n)→(Hash_n-1, Data_n-1)...(Hash_0, Data_0). The second-level cache only stores the hash values of each historical version of the data, i.e. (Hash_n)→(Hash_n-1)...(Hash_0). When the first-level cache reaches the storage limit, a degradation mechanism is triggered to degrade the cache of the key data with lower query frequency to the second-level cache. When the second-level cache space reaches the upper limit, all data in the second-level cache is removed to save storage space and improve cache hit rate. The key in the S1 request is queried in the cache, which specifically includes:

[0031] S2.1: If the data corresponding to the key does not exist in the cache, then the latest version of the complete provenance chain (LatestHash, LatestData)→... (Hash_0, Data_0) is traversed in the current blockchain ledger by (LatestHash, LatestData) in turn, and the result is returned, and finally the result is added to the primary cache corresponding to the key, and the query is ended;

[0032] S2.2: If the data corresponding to the key exists in the cache and exists in the primary cache, the cached provenance chain (Hash_n, Data_n)→(Hash_n-1, Data_n-1)...(Hash_0, Data_0) is retrieved from the primary cache. If the data exists in the secondary cache, the hash values (Hash_n)→(Hash_n-1)...(Hash_0) of each historical version are taken out of the secondary cache, and the data corresponding to each hash value is batched from LevelDB to obtain the provenance chain (Hash_n, Data_n)→(Hash_n-1, Data_n-1)...(Hash_0, Data_0), which is put into the primary cache for cache upgrade, and then S3 is executed.

[0033] Among them, LevelDB is a typical key-value non-relational database, and most data items in the blockchain system are accessed by taking the data hash value as the key and the data content as the value.

[0034] S3: The full node performs consistency check, compares the LatestHash obtained in S1 with the Hash_n retrieved from the cache in S2, and performs provenance integrity check, which specifically includes:

[0035] S3.1: If the LatestHash and the Hash_n are consistent, then the provenance chain (Hash_n, Data_n)→(Hash_n-1, Data_n-1)...(Hash_0, Data_0) obtained in the cache is the latest version of the complete provenance chain, and the result is returned, and the query is ended;

[0036] S3.2: If the LatestHash is inconsistent with the Hash_n, retrieve from (LatestHash, LatestData) to (Hash_n, Data_n) in the blockchain, get (LatestHash, LatestData) ->... (Hash_n, Data_n), add it to the cache corresponding to the key to ensure the consistency of the cache and the data in the blockchain ledger, and splice the retrieved (Hash_n, Data_n) -> (Hash_n-1, Data_n-1) ->... (Hash_0, Data_0) in the cache in S2 into the latest version of the complete traceability chain (LatestHash, LatestData) ->... (Hash_n, Data_n) -> (Hash_n-1, Data_n-1) ->... (Hash_0, Data_0), return the result, and end the traceability query.

[0037] Comparative example

[0038] The original traceability query method of the blockchain adopts a sequential traceability manner, that is, the previous historical version of the data is sequentially taken out according to the PreHash field in the data field, until the complete data historical modification track link is traced out, and the complete data traceability link is obtained, and the data access during the period requires more disk IO.

[0039] It is verified by experiments that when the traceability query request quantity is 10000 times / s, the single traceability average time of the blockchain data traceability query optimization method proposed in the application, that is, the method of the embodiment and the comparative example method, is compared, as shown in Figure 4

[0040] When the request key is not repeated, since the cache does not intervene basically, the traceability time of the method of the embodiment and the traceability time of the comparative example method are almost the same; when the request key repetition ratio is 30%, the traceability time of the method of the embodiment is reduced to about 70%-75% of the traceability time of the comparative example method; when the request repetition ratio is increased to 60%, the cache hit rate is improved, and the traceability time of the method of the embodiment is further reduced to 50%-60% of the traceability time of the comparative example method; and as the request repetition ratio continues to increase, the trend of the traceability time of the method of the embodiment increasing due to the increase of the traceability version number gradually flattens, and the performance is better and more stable.

[0041] In summary, the traceability efficiency of the blockchain data traceability query optimization method proposed in the application is obviously improved compared with the original traceability method of the blockchain which adopts a sequential traceability manner, and the cache memory reading operation is more efficient than the disk reading, so that the blockchain data traceability query optimization method has practicality.

[0042] ​The principles and embodiments of the present application are described herein with reference to specific examples. The above description of the examples is merely intended to help understand the method of the present application and its core idea; meanwhile, for those skilled in the art, according to the idea of the present application, the specific implementation and application scope can be changed. In summary, the content of the specification should not be understood as a limitation of the present application.

Claims

1.A method for optimizing blockchain data provenance query, characterized in that, The steps include the following: Step 1, input target data identification keyword key, initiate a traceability query request from a node in the network to a full node of the blockchain, the request contains the traceability target data identification keyword key, after the full node receives the request, the latest version hash value LatestHash and the latest data LatestData of the data corresponding to the key are queried in the current blockchain ledger, recorded as (LatestHash, LatestData); Step 2, query the key in step 1 in the cache of the full node of the blockchain; Step 2.1, if the data corresponding to the key does not exist in the cache of the full node of the blockchain, then (LatestHash, LatestData) is used to traverse the latest version of the complete traceability chain (LatestHash, LatestData)→... (Hash_0, Data_0) in the current blockchain ledger in turn and return, finally the complete traceability chain obtained by the traversal is added to the cache corresponding to the key, and the traceability query of the key is ended; Step 2.2, if the data corresponding to the key exists in the cache, then the complete traceability chain (Hash_n, Data_n)→(Hash_n-1, Data_n-1)...(Hash_0, Data_0) corresponding to the key is retrieved in the cache, and step 3 is executed; Step 3, the full node performs consistency check, compares LatestHash obtained in step 1 with Hash_n in (Hash_n, Data_n) retrieved in the cache in step 2, and performs traceability integrity check; Step 3.1, if LatestHash is consistent with Hash_n, then (Hash_n, Data_n)→(Hash_n-1, Data_n-1)...(Hash_0, Data_0) obtained in the cache is the latest version of the complete traceability chain, the result is returned, and the traceability query of the key is ended; Step 3.2, if the LatestHash is inconsistent with Hash_n, then retrieve from (LatestHash, LatestData) to (Hash_n, Data_n) in the blockchain, get (LatestHash, LatestData)→... (Hash_n, Data_n), add it to the cache corresponding to the key to ensure the consistency of the cache and the data in the blockchain ledger, and splice it with the traceability chain retrieved in step 2 in the cache of the full node of the blockchain (Hash_n, Data_n)→(Hash_n-1, Data_n-1)...(Hash_0, Data_0) to form the latest version of the complete traceability chain (LatestHash, LatestData)→... (Hash_n, Data_n)→(Hash_n-1, Data_n-1)...(Hash_0, Data_0), return the result, and end the traceability query of the key; The cache in the full node of step 2 is a multi-level cache structure, including a first-level cache and a second-level cache, the first-level cache stores the hash values and data of each historical version of the key identification data, i.e. (Hash_n, Data_n)→(Hash_n-1, Data_n-1)...(Hash_0, Data_0), and the second-level cache only stores the hash values of each historical version of the data, i.e. (Hash_n)→(Hash_n-1)...(Hash_0), when the first-level cache reaches the storage limit, a degradation mechanism is triggered to degrade the key data cache with low query frequency to the second-level cache, and when the second-level cache space reaches the limit, all data in the second-level cache is removed. 2.The method of claim 1, wherein, The complete traceability chain obtained by traversing in step 2.1 is added to the first-level cache corresponding to the key. 3.The method of claim 1, wherein, In step 2.2, if the data corresponding to the key exists in the cache and is in the first-level cache, the complete traceability chain stored in the cache is retrieved from the first-level cache, i.e. (Hash_n, Data_n)→(Hash_n-1, Data_n-1)...(Hash_0, Data_0); if the data exists in the second-level cache, the hash values of each historical version (Hash_n)→(Hash_n-1)...(Hash_0) are taken out of the second-level cache, and the data corresponding to each hash value is batched from the underlying database of the blockchain to obtain the traceability chain (Hash_n, Data_n)→(Hash_n-1, Data_n-1)...(Hash_0, Data_0), which is put into the first-level cache for cache upgrade.

Images