CN113535732B

CN113535732B - Verifiable query optimization method for reputation-behavior correlation-oriented double-block chain

Info

Publication number: CN113535732B
Application number: CN202110839618.7A
Authority: CN
Inventors: 于尧; 张中源; 张荟; 胡文健; 郭磊
Original assignee: 东北大学
Priority date: 2021-07-23
Filing date: 2021-07-23
Publication date: 2023-07-25
Anticipated expiration: 2041-07-23
Also published as: CN113535732A

Abstract

The invention discloses a verifiable query optimization method for a reputation-behavior association double-block chain, which comprises the following steps: calculating the number of all nodes in the tree framework when a certain transaction number or a preset block number is calculated, and creating the tree framework; designing and writing an efficient inter-block index structure based on a jump list, and efficiently saving the query time of a traversal block; designing and considering a reputation intra-chain intra-block index structure and a behavior data intra-chain intra-block index structure under the condition that the attributes exist in the same way, and having a query mode of multiple attributes; and designing a reputation chain verification index structure and a behavior data chain verification index structure, and efficiently ensuring the integrity of the query result set. The invention realizes the verifiable query optimization method oriented to the reputation-behavior association double-block chain, solves the problems of single association double-chain query mode, low query performance and poor query verification efficiency, and further meets the requirements of data tracing or data evidence obtaining.

Description

Verifiable query optimization method for reputation-behavior correlation-oriented double-block chain

Technical Field

The invention relates to the technical field of data tracing and blockchain, in particular to a verifiable query optimization method for reputation-behavior association-oriented double-blockchain.

Background

The blockchain is a linked list structure of all blocks in one-way connection, and the whole linked list needs to be traversed when inquiring historical transaction, so that the inquiry time is higher, the time complexity is higher, only few inquires using transaction hash as a keyword and the like are supported, under the condition, quick and efficient inquiry is difficult to realize by tracing and tracing, and the basic inquiry requirement cannot be met completely. In order to solve the problem of low query efficiency caused by the blockchain linked list structure, most of the prior methods for improving the query performance of the blockchain system provide more query services by copying the block data to the database under the chain, but the additional storage mode of the block data greatly increases the storage cost, and the query services must meet the data tracing requirements of user behavior tracks and the like through reputation index in the application on the basis of ensuring the storage cost.

The reputation-behavior association double-block-chain system is used as a distributed account book commonly maintained by multiple parties which are not trusted by each other, and the data query service provided by the system outwards must meet the requirements that a query result set is not tampered and the integrity can be verified so as to ensure that query data is truly available. However, existing blockchains only support simple proof of transaction existence and cannot verify the integrity of the query result set. To ensure the integrity of queries on the blockchain database, the querying user may join the blockchain network as a complete node. The user can then download and verify the entire data and process the query locally without affecting the integrity of the query. However, maintaining a complete copy of the entire data can be too expensive for an average user because it requires considerable storage, computation, and bandwidth resources. To meet the resource-limited query users, a more attractive option is to delegate storage and query services to a powerful full node, while the query user receives results as a light node only. However, how to ensure the integrity of the query results remains a challenge because the complete node is not trusted and is an inherent assumption of blockchains.

Thus, there is a need for a reputation-behavior dual-blockchain based efficient transaction verifiable query optimization technique to improve the query and verification efficiencies of an associated dual-blockchain system.

Disclosure of Invention

Aiming at the defects of the prior art, the invention provides a verifiable query optimization method for a reputation-behavior association double-block chain, which designs an inter-block index structure, a reputation intra-block index structure, a verification index structure, a behavior data intra-block index structure and a verification index structure based on a jump list, and simultaneously introduces a tree skeleton method to form a writing efficient index construction method so as to reduce the influence of index updating on the writing performance of the double-block chain as much as possible, and adopts a multi-keyword diversified query mode to enable the association double-block chain to have rich query types, improve the query efficiency of the double-block chain and the efficiency of verifying the integrity of a query result set.

For this purpose, the invention provides the following technical scheme:

the invention provides a verifiable query optimization method for a reputation-behavior association double-block chain, which comprises the following steps:

the common node sends a query request to the edge node; an index structure and a verification index structure are built in the edge nodes, root node hash values of the index structure and verification index structure roots are stored in the block heads, and consensus is achieved in the whole network along with the blocks; the system comprises an index structure, a verification index structure and a data link verification index structure, wherein the index structure comprises an inter-block index structure, a reputation link intra-block index structure and a behavior data link intra-block index structure, the verification index structure comprises a reputation link verification index structure and a behavior data link verification index structure, and the inter-block index is an MBerkle tree mountain index structure based on a tree skeleton and a skip list; the index in the reputation chain block is a multi-keyword query-oriented two-layer HMFBerkle tree; the index in the behavior data chain block is an HMBerkle tree;

After receiving the query request, the edge node queries based on the index structure to obtain a query result set; constructing a verification object based on the verification index structure, and returning the query result set and the verification object to the common node; wherein querying based on the inter-block index structure comprises: judging which search code is according to the query key words, comparing the search code with the root node of the jump list, and if the search code is larger than the root node of the jump list, querying in the current latest MBerkle tree; otherwise, inquiring in the leaf nodes of the jump list according to the interpolation inquiring method, finding out pointers pointing to corresponding MBerkle trees, and inquiring in the indexes; sequentially judging whether the subtrees on the left and right of the node meet the query conditions by taking the MBerkle tree root node as a starting point, if so, querying downwards until the leaf node, obtaining a pointer pointing to the queried block and acquiring a corresponding block, otherwise, ending the query; querying based on the reputation intra-chain index includes: when inquiring in the top index of the index, taking the top index root node as a starting node, and inquiring downwards from the left subtree and the right subtree of the node according to a first preset inquiry sequence until the corresponding bottom index root node is inquired; when inquiring in the bottom index, taking the bottom index root node as a starting node, and inquiring downwards from left and right subtrees of the node according to a first preset inquiring sequence or a second preset inquiring sequence; querying based on the intra-behavioral chain index includes: taking the root node as an initial node, and inquiring from left and right subtrees of the node according to a first preset inquiry sequence or a third preset inquiry sequence;

If the behavior data transaction is inquired and the behavior shows the hash value, sending a request for downloading the real behavior data to the IPFS network and verifying whether the real behavior data is consistent or not;

the common node verifies the integrity of the query result set based on the verification object and the verification index structure root stored in the block header.

Further, the construction of the inter-block index structure includes:

presetting a packet size N _block Calculating the number N of the corresponding leaf nodes _leaf ＝N _block And the number of non-leaf nodesWherein->Representing a tree boneHeight of rack, N _b Representing the number of sub-nodes contained in non-leaf nodes, applying for node arrays with corresponding sizes in batches according to the number of all nodes in the tree skeleton, constructing the tree skeleton, pre-distributing certain space for indexes among grouping blocks, and constructing the tree skeleton in the sequence of from left to right and from bottom to top;

when a new block is generated and the block number is 1, triggering inter-block index updating, storing search code value information, namely the block number, the last transaction number and a time stamp in the block, a pointer pointing to a storage position of the block and a hash value of the node, at a first free leaf node, and storing the pointer pointing to the node by a tree root node;

when a new area block is generated, information such as a search code value is sequentially placed at the right node of a non-idle leaf node, and is updated in an upward recursion mode, if the highest node loaded at present is not a root node, the tree root node stores a pointer pointing to the highest node;

When the block number of the new block is N _block And when +1, the preset inter-block index is fully loaded, the skip list needs to be updated, namely, the search code value information of the previous block, a pointer pointing to the inter-block index of the group and the maximum search code value in the root node are additionally stored in the leaf node of the skip list, and the steps are repeated to create a new inter-block index and update the skip list when the index is fully loaded.

Further, the construction of the index structure in the reputation chain block comprises the following steps:

in the process of receiving credit transaction, cutting is carried out according to a certain time window to form continuous fragments; after receiving a complete fragment credit transaction, classifying the last fragment according to an evaluated person in parallel while receiving the next fragment credit transaction, merging the classified fragments by using a thread, and after the last fragment classification is finished, merging for the last time to enable the credit transaction to be classified completely and sorting according to the classification;

using multithreading parallel to conduct transaction ordering on all classifications by adopting a bucket ordering method;

each time a new block is generated, a new intra-block index structure is constructed, wherein the intra-block index structure is a two-layer index structure and is divided into a bottom layer structure and a top layer structure;

Calculating the number of leaf nodes and the number of non-leaf nodes required in the corresponding bottom layer structure according to the number of the classified and ordered credit transaction subsets, applying for node arrays with corresponding sizes in batches according to the number of all the nodes, and constructing a tree skeleton, wherein a space is pre-allocated for the bottom layer index, and the tree skeleton construction sequence is from left to right and from bottom to top;

selecting a reputation value and an evaluation party as search code values, loading the search code values to each bottom index in batches in a bottom-up mode by using multithreading, wherein the non-leaf nodes store lMinrep and rMaxrep, lMinrep represents the minimum reputation value in a left subtree and rMaxrep represents the maximum reputation value in a right subtree, and binary bits are used for replacing the direct storage evaluation party; the SHBF of the parent node initializing all leaf nodes has m bits and is 0, and hash ₁ (eva)％m,...,hash _k/2 (eva)％m,hash ₁ (eva)％m+o(eva),...,hash _k/2 (eva)% m+o (eva) is set at 1, where eva represents any evaluation party contained in the node, k represents the number of hash functions, o (eva) represents the offset, andwherein the method comprises the steps ofAnd omega represents the number of bytes of the machine, and the SHBF of nodes at other layers in the index is sequentially increased by 2 times;

calculating the number of leaf nodes and the number of non-leaf nodes required in the top layer structure according to the classified number of the credit transaction sets, applying for node arrays with corresponding sizes in batches according to the number of all the nodes, and constructing a tree skeleton, wherein a space is pre-allocated for top layer indexes, and the tree skeleton construction sequence is from left to right and from bottom to top;

And selecting an evaluated party as a search code value, loading a pointer pointing to the index and the evaluated party into a leaf node of the top tree skeleton every time one bottom index is built, merging if peak top nodes with two peaks with the same height appear, until all spaces of the top tree skeleton are full, namely, the index in the reputation chain block is built, and putting the hash value of the top index root node into a block head.

Further, the construction of the index structure in the behavior data chain block comprises the following steps:

in the process of receiving the behavioral data transaction, dividing the behavioral data transaction by a certain time window to form continuous fragments; after receiving a complete sliced behavioral data transaction, classifying the last sliced data transaction according to a sender in parallel while receiving the next sliced data transaction, merging the classified sliced data by using a thread, and after the last sliced data transaction is classified, performing the last merging to enable the behavioral data transaction to be classified completely and sorting the behavioral data transactions according to the classifications;

each time a new behavioural data block is generated, a new intra-block index structure is constructed;

calculating the number of leaf nodes and the number of non-leaf nodes required in the tree skeleton according to the number of the classified behavioral data transaction sets, applying for node arrays with corresponding sizes in batches according to the number of all the nodes, and constructing the tree skeleton, wherein the space is pre-allocated for the index in the block, and the construction sequence of the tree skeleton is from left to right and from bottom to top;

And selecting the behavior data transaction number, the sender and the receiver as search code values, loading the search code values into a tree framework in a bottom-up mode, replacing the direct storage sender and the receiver with binary digits in non-leaf nodes of the structure, and storing the maximum value of the transaction numbers of the left subtree and the right subtree.

Further, the construction of the reputation chain verification index structure includes:

initializing an OBF with mm bits and 0 according to the number n of the classification of the credit transaction sets, wherein mm=10·n;

the OKBF was divided into k portions and (mm) _i ,mm _j ) =1, 1. Ltoreq.i < j.ltoreq.k, where (mm) _i ,mm _j ) Expressed in mm _i And mm _j Greatest common divisor of (2), or mm _i And mm _j Are prime to each other, and

hash values of root nodes of all the substructures are respectively passed through the substructures in mm _i And performing modular operation for the module, setting the binary position of the corresponding position on the OBF as 1, and putting the binary position into the block head after all the binary positions are finished.

Further, the construction of the behavior data chain verification index structure comprises the following steps:

selecting an intermediate layer from indexes in a behavior data chain block as a verification layer, and initializing the OKBF with mm bits and 0 according to the number of nodes of the verification layer;

the hash value of each node of the verification layer is respectively passed through the hash value of each node in mm _i And performing modular operation for the module, setting the binary position of the corresponding position of the OKBF as 1, and putting the binary position into the block head after all the binary positions are finished.

Further, constructing the verification object based on the verification index structure includes:

adding the leaf node information queried in the intra-block index and the brother node information of the same father node into the verification object, acquiring the father node of the node, and if the node is not in the verification layer, continuing to add the leaf node information and the brother node of the same father node into the verification object; if the verification layer is in the verification layer, adding the verification layer into the verification object, and completing the construction of the verification object.

Further, the common node verifies the integrity of the query result set according to the verification object and the verification index structure root stored in the block header, including:

and converting the hash value of the node into binary bits according to the node reconstructed to the verification layer by the verification object, comparing with the OKBF in the block head, if the OKBF exists, completing the query result set, otherwise, indicating that the query is incomplete, and querying that the error exists.

Further, the index structure further includes: a cross-chain indexing structure.

Further, the construction of the cross-chain index structure includes:

when generating the credit new block, the credit new block is made to record the hash value of the current latest action block, and a cross-chain structure capable of tracing back to the action block is formed based on the hash pointer.

The invention has the advantages and positive effects that:

the invention provides a verifiable query optimization method for a reputation-behavior association double-block chain, which is characterized in that firstly, edge nodes are introduced because of limited computing, storage and other resources of common users, double-block chain complete information is stored in an edge node layer, and the common users only store block head information. Secondly, in order to improve the query performance and verification performance of the double-block chain and meet the data tracing requirement on the double-block chain, an inter-block index structure, a reputation chain intra-block index structure and verification data structure based on a jump list, a behavior data chain intra-block index structure and verification data structure, a tree skeleton-based writing efficient index construction method and a query method with multiple keywords are designed. Compared with the prior art, the technical scheme reduces the interference of index updating on the writing performance of the double-block chain as much as possible, ensures that the double-block chain has rich and diversified query types, improves the query efficiency of double chains and verifies the integrity of the query result set.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described, and it is obvious that the drawings in the following description are some embodiments of the present invention, and other drawings may be obtained according to the drawings without inventive effort to a person skilled in the art.

FIG. 1 is a system model diagram of verifiable query optimization based on an associated dual-blockchain in an embodiment of the present invention;

FIG. 2 is a schematic diagram of an inter-block index structure of a reputation chain or a behavioral data chain in accordance with an embodiment of the present invention;

FIG. 3 is a schematic diagram of an index structure and a validation index structure within a reputation chain block according to an embodiment of the present invention;

FIG. 4 is a schematic diagram of an index structure and a verification index structure in a data link block according to an embodiment of the present invention;

FIG. 5 is a graph showing the relationship between single-value query performance and query integrity rate with the same number of reputations, wherein the reputations are used as keywords in the embodiment of the invention;

FIG. 6 is a graph showing the relationship between the query performance and the query integrity rate with the same number of reputations in the range using reputation as the key word in the embodiment of the invention;

FIG. 7 is a graph showing the query performance of discrete attributes under a single block as a function of the number of transactions in the block according to an embodiment of the present invention;

FIG. 8 is a graph showing the relationship between the number of false positive rate-dependent reputation transactions in an index in a block or the number of leaf nodes in an index in a block using discrete attributes as keys in an embodiment of the present invention;

FIG. 9 is a graph showing the relationship between false positive rate and index size in an index using discrete attributes as keys according to an embodiment of the present invention;

FIG. 10 is a graph showing the relationship between the number of transactions or index leaf nodes in a storage size reputation block occupied by an index according to an embodiment of the present invention;

FIG. 11 is a graph showing the relationship between the block inquiry time and the number of blocks according to the embodiment of the present invention;

FIG. 12 is a graph of the relationship of the change in the number of query time reputation blocks for a retrospective query in accordance with an embodiment of the present invention;

FIG. 13 is a graph showing the relationship between the query time of a trace-back query and the scale of the query result according to the embodiment of the invention;

FIG. 14 is a graph showing the relationship between the query time of a time window query and the time window change in an embodiment of the present invention;

FIG. 15 is a graph illustrating the verification time of multiple query result sets under intra-block indexing in a behavioral data chain as a function of query result set size in accordance with an embodiment of the present invention.

Detailed Description

In order that those skilled in the art will better understand the present invention, a technical solution in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in which it is apparent that the described embodiments are only some embodiments of the present invention, not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the present invention without making any inventive effort, shall fall within the scope of the present invention.

Referring to FIG. 1, a system model of a verifiable query in an associated dual blockchain system in an embodiment of the present invention is shown. Because the IIOT (Industrial Internet of Things ) equipment has limited storage resources and computing resources, the invention introduces an edge node layer to support the operations of storage, computation, inquiry and the like of an associated double-block-chain system, and constructs an associated double-block-chain model based on a user-edge two-layer, wherein the IIOT equipment is regarded as a common node, can only send transactions to the edge node, has no right to record the transactions, and can record block heads of double-block-chains; the edge nodes are divided into ordering nodes and full nodes because of different responsibilities in different periods, and have a query function, wherein the full nodes store all block data, and the ordering nodes are responsible for packaging transactions and storing all block data. In fig. 1, the system model mainly includes an IPFS network (InterPlanetary File System, interstellar file system) 100, a common node 200 and a full node 300, wherein the full node 300 may not be trusted, and a write-efficient inter-block index structure, an intra-block index structure and a verification index structure are constructed to provide an efficient verifiable query service, and root node hash values of intra-block indexes and root of verification index structures are stored in a block header to achieve consensus with blocks in the full network. Since the block header has reached a consensus throughout the network, the generic node 200 can root-validate the query result according to the verifiable index structure stored therein. The flow of the query processing is as follows: first, the general node 200 issues a query request to the edge node 300; secondly, after receiving the query request, the edge node 300 queries based on the index structure to obtain a query result set, constructs a verification object based on the verifiable index structure, and returns the query result set and the verification object to the common node 200; then, if the behavior data transaction is queried and the behavior shows the hash value, sending a request for downloading the real behavior data to the IPFS network 100 and verifying whether the behavior data is consistent; finally, the generic node 200 verifies the integrity of the query result set based on the verification object and the verifiable index structure root stored in the block header.

The verifiable query optimization method for the reputation-behavior association double-block chain comprises the following steps of:

1.1 query semantic addition

Missing query semantics can make it difficult for an associated dual blockchain system to support complex queries, and query semantics are added first to support rich queries on blockwise data. Attributes with identity, such as raters, ratees, and reputation values in reputation transactions, senders, recipients, and transaction serial numbers in data transactions, may be selected from the transactions. Name field is called discrete attribute, and value field is called value attribute; specific attributes may also be selected from the tile header, such as the tile number, the last transaction number in the tile, and the timestamp of the tile.

1.2 query definition

In the embodiment of the invention, three query modes exist: on-chain querying, i.e., querying data stored in an associated dual-block chain; an under-chain query, i.e. querying the real behavior data stored in the IPFS; the joint inquiry on the chain and the downlink is needed. The invention is mainly oriented to on-chain query as the under-chain query can download behavior data only by requesting to the IPFS network.

The on-chain queries are classified into three categories, the first category being cross-chain queries for checking and verifying, through reputation playback behavior, that there is an abnormal behavior or reputation assessment mechanism and preventing as much as possible the threat from occurring; the second category is a reputation chain single-chain query for predicting user reputation, etc., based on historical reputation; the third category is behavioral data chain single-chain queries for value analysis or the like based on historical behavior.

The cross-chain query, as the name implies, refers to the steps of firstly querying on a reputation chain, querying a certain reputation block or transaction, acquiring the associated information in the block or transaction, crossing the cross-chain index based on the hash pointer to a behavior data chain, and finding the corresponding behavior block or transaction, wherein the query types are as follows: 1. transaction inquiry, which is used for verifying the existence of the transaction and the association and checking the corresponding behavior through the credit value; 2. block inquiry, which is used for complementing the block or the block head and the index tamper-proof verification; 3. the trace back query is used for playing back all the action tracks through the reputation value; 4. and the time window query is used for querying the behavior track in the specific time period. A single-chain query is a query on a single chain, with the type of query supported being the same as a cross-chain query, but differing only slightly in effect in that it merely looks at historical reputation transactions or behavioral transactions.

1.3 inter-block index Structure design

The inter-block index is an MBerkle tree mountain index structure based on a tree skeleton and a jump list, and an MBerkle tree (MB tree for short) can work like a B+ tree and consists of common B+ tree expansion nodes, wherein the nodes are expanded by a hash value, and each hash value is associated with each pointer item. The calculation of the hash value on the node is similar to M-Tree. As shown in fig. 2, simply, the search code is a triplet (bid, tid, ts) formed by connecting a plurality of equal-height MBerkle trees through a jump list, where bid is a block number, tid is the last transaction number in the block, ts represents the timestamp of the block, and a leaf node stores a pointer to the storage location of the block. For two different blocks b on any single blockchain _i And b _j If b _i Ratio b _j Early in packaging, then (b) _i .bid＜b _j .bid)∩(b _i .tid＜b _j .tid)∩(b _i .Ts＜b _j Ts) is always true. For nodes in the inter-block index, the following definition is made.

Making hash (·) a hash function; ' is an operation connector; bhsh is the hash value of the block. For each leaf node in the equal-height MBerkle tree, the following definition is made:

hash _i ＝hash(bid|tid|Ts|bhash) (1)

making hash (·) a hash function; ' is an operation connector; l and r are divided into a left sub-node and a right sub-node of the node; bid _l Maximum block number, bid, stored for the left subtree _r The maximum value of the block numbers stored for the right subtree; tid (tid) _l Maximum transaction number, tid, stored for left subtree _r A transaction number maximum value stored for the right subtree; ts (Ts) _l The maximum value of the timestamp stored for the left subtree, ts _r The timestamp stored for the right subtree is maximum. For each non-leaf node in the equal-height MBerkle tree, the following definition is made:

making hash (·) a hash function; ' is an operation connector;hash value for skip block; l (L) _k Is a skip block. For each leaf node in the jumplist, it is defined as follows:

making hash (·) a hash function; ' is an operation connector;the maximum value of the block numbers stored for the right subtree;a transaction number maximum value stored for the right subtree; / >The timestamp maximum stored for the right subtree; l (L) _last Is the last block of the latest MBerkle tree. For each of the jumplistsA non-leaf node, defined as follows:

the specific steps for constructing the inter-block index structure are as follows:

s3.1, presetting the block size N of the grouping _block Calculating the number N of the corresponding leaf nodes _leaf ＝N _block And the number of non-leaf nodesWherein->Expressed as the height of the tree skeleton, N _b Representing the number of sub-nodes contained in non-leaf nodes, applying for node arrays with corresponding sizes in batches according to the number of all nodes in the tree skeleton, constructing the tree skeleton, pre-distributing a certain space for the inter-block index structure, and constructing the tree skeleton in the sequence of from left to right and from bottom to top;

s3.2, when a new block is generated and the block number is 1, triggering inter-block index updating, storing search code value information at a first free leaf node, namely the block number, the last transaction number and a time stamp in the block, a pointer pointing to a storage position of the block and a hash value of the node, and storing a pointer pointing to the node by a tree root node;

s3.3, when a new block is generated, sequentially placing information such as a search code value and the like on the right node of a non-idle leaf node, recursively updating upwards, and if the currently loaded highest-level node is not a root node, storing a pointer pointing to the node by the tree root node;

S3.4, when the block number of the new block is N _block When +1, the preset inter-block index is fully loaded, the jump list needs to be updated, i.e. the search code value information of the previous block and the maximum search code value in the pointer and root node pointing to the index are additionally stored in the leaf node, and the steps are repeated to create a new inter-block index structure and enter in timeLine jump list update.

The inter-block index query steps are: inputting a query keyword, judging which search code is compared with the root node of the jump list, and if the search code is larger than the comparison threshold, querying in the current latest MBerkle tree; otherwise, inquiring in the leaf nodes of the jump list according to the interpolation inquiring method, finding out pointers pointing to corresponding MBerkle trees, and inquiring in the indexes; and sequentially judging whether the subtrees on the left and right of the node meet the query conditions by taking the MBerkle tree root node as a starting point, if so, querying downwards until the leaf node, obtaining a pointer pointing to the queried block and acquiring a corresponding block, otherwise, ending the query.

1.4 reputation chain intra-block index design

The index in the credit chain block is a multi-keyword query-oriented two-layer HMFBerkle Tree, the Hybrid-Merkle-FB+ Tree (HMFBerkle Tree for short) is formed by combining common FB+ Tree expansion nodes and SHBF Tree expansion nodes, and meanwhile the nodes are expanded by a hash value, and each hash value is associated with each pointer item. The calculation of hash values on nodes is similar to a Merkle tree. It may operate as a fb+ tree or as an SHBF tree. Shifting Bloom filter-based index (SHBF tree based on shifted Bloom filter index) may work like a Bloom filter-based index (BFM filter-based index) with only the Bloom Filters (BF) of non-leaf nodes in the index replaced with the mobile BFM filters (SHBF). As shown in fig. 3, the search code is (beeva, eva, rep), where beeva is the rated party in the reputation transaction; eva is the evaluation side; rep is a reputation value. Because the reputation values in each reputation transaction within a reputation block may be the same, there is an error or omission in the query result, a two-layer index structure is designed and the parent node in the index preserves the reputation value ranges of the left and right subtrees. The two-layer index structure is divided into: top-level index, the query keyword is beeva; the index of the bottom layer, and the query keywords are eva and rep. While the discrete attributes are stored in binary form and stored in SHBF (Shifting Bloom Filter, mobile bloom filter), the elements queried can be retrieved efficiently in the collection. For nodes in the index within the reputation chain, the following definition is made.

Making hash (·) a hash function; ' is an operation connector; txhash is the reputation transaction hash value. For each leaf node in the underlying index, it is defined as follows:

hash _i ＝hash(txhash|eva|rep) (5)

making hash (·) a hash function; ' is an operation connector; l and r are divided into a left sub-node and a right sub-node of the node; rep type _l Reputation value minimum stored for left subtree, rep _r The maximum value of the reputation value stored for the right subtree; SHBF _i Filters stored for nodes. For each non-leaf node in the underlying index, it is defined as follows:

hash _i ＝hash(hash(hash _l |hash _r )|rep _l |rep _r |SHBF _i ) (6)

making hash (·) a hash function; ' is an operation connector; botrootdhash is the hash value of the transaction. For each leaf node in the top level index, it is defined as follows:

hash _i ＝hash(beeva|botRootHash) (7)

making hash (·) a hash function; ' is an operation connector; l and r are divided into a left sub-node and a right sub-node of the node; SHBF _i Filters stored for nodes. For each non-leaf node in the top level index, it is defined as follows:

hash _i ＝hash(hash(hash _l |hash _r )|SHBF _i ) (8)

the specific steps for constructing the index structure in the reputation chain block are as follows:

s4.1, in the process of receiving the credit transaction, cutting is carried out according to a certain time window, so that continuous fragments are formed. After receiving a complete fragment credit transaction, classifying the last fragment according to an evaluated person in parallel while receiving the next fragment credit transaction, merging the classified fragments by using a thread, and after the last fragment classification is finished, merging for the last time to enable the credit transaction to be classified completely and sorting according to the classification;

S4.2, carrying out transaction ordering on all classifications by adopting a bucket ordering method by using multithreading parallelism;

s4.3, constructing a new intra-block index structure every time a new block is generated, wherein the index structure is a two-layer index structure, namely a bottom-layer structure and a top-layer structure;

s4.4, calculating the number of leaf nodes and the number of non-leaf nodes required in the corresponding bottom layer structure according to the number of credit transaction subsets under each evaluated party, applying for node arrays with corresponding sizes in batches according to the number of all nodes, and constructing a tree skeleton, wherein a certain space is pre-allocated for the bottom layer index, and the tree skeleton construction sequence is from left to right and from bottom to top;

s4.5, selecting a reputation value and an evaluator as search code values, loading the search code values into each bottom layer in batches by using multithreading and adopting a bottom-up mode, wherein lMinrep and rMaxrep are stored in non-leaf nodes, lMinrep represents a minimum reputation value in a left subtree and rMaxrep represents a maximum reputation value in a right subtree, and binary bits are used for replacing direct storage evaluators. The SHBF of the parent node initializing all leaf nodes has m bits and is 0, and hash ₁ (eva)％m,...,hash _k/2 (eva)％m,hash ₁ (eva)％m+o(eva),...,hash _k/2 (eva)% m+o (eva) is set at 1, where eva represents any evaluation party contained in the node, k represents the number of hash functions, o (eva) represents the offset, and Wherein the method comprises the steps ofAnd omega represents the number of bytes of the machine, and the SHBF of nodes at other layers in the index is sequentially increased by 2 times;

s4.6, calculating the number of leaf nodes and the number of non-leaf nodes required in the top layer structure according to the number of the classification of the credit transaction set, applying for node arrays with corresponding sizes in batches according to the number of all nodes, and constructing a tree skeleton, wherein a certain space is pre-allocated for top layer indexes, and the tree skeleton construction sequence is from left to right and from bottom to top;

s4.7, selecting an evaluated party as a search code value, loading a pointer pointing to the structure and the evaluated party into a leaf node of a top tree skeleton every time one bottom layer structure is built, merging if two peak top nodes with the same height peak appear until all spaces of the top layer are full, and putting the hash value of a top layer root node into a block head.

Query process for index within reputation chain block: when inquiring discrete attributes in the top index of the index, sequentially judging whether the searched discrete attributes exist in left and right subtrees of the nodes by taking the top index root node as a starting node, and inquiring downwards (a first preset inquiry sequence) if the searched discrete attributes exist until the corresponding bottom index root node is inquired, otherwise, displaying that the searched discrete attributes do not exist; when querying discrete attributes in the bottom index, sequentially judging whether the searched discrete attributes exist in left and right subtrees of the nodes by taking a root node of the bottom index as a starting node, if so, querying downwards, otherwise, querying ends (a first preset querying sequence); when the numerical value attribute is inquired in the bottom index, the root node is taken as a starting node, whether the numerical value attribute exists in the node is judged, if yes, whether the numerical value attribute exists in the left subtree and the right subtree of the node is judged sequentially, if yes, the numerical value attribute is inquired downwards, and if not, the inquiry is ended (a second preset inquiry sequence).

1.5 behavioural data chain intra-block index design

The index in the behavior data chain block is an HMBerkle Tree, and a Hybrid-Merkle-B+Tree (HMBerkle Tree for short) is formed by combining a common B+tree expansion node and an SHBF Tree expansion node, and meanwhile, the nodes are expanded by a hash value, and each hash value is associated with each pointer entry. The calculation of hash values on nodes is similar to a Merkle tree. It may operate as a b+ tree or as an SHBF tree. As shown in fig. 4, the search code is (sen, rec, seqnum), where sen is the sender in the transaction; rec is the recipient; seqnum is the transaction number. The parent node in the index stores the maximum value of the numerical attributes of the left subtree and the right subtree, and meanwhile, the discrete attributes are stored in the form of binary bits and stored in the SHBF, so that the queried element can be efficiently retrieved in the set. For nodes in the index within the reputation chain, the following definition is made.

Making hash (·) a hash function; ' is an operation connector; txhash is the hash value of the behavioral data transaction. For each leaf node in the underlying index, it is defined as follows:

hash _i ＝hash(txhash|sen|rec|seqnum) (9)

making hash (·) a hash function; ' is an operation connector; l and r are divided into a left sub-node and a right sub-node of the node; sqenum _l Transaction number maximum, seqnum, stored for left subtree _r A transaction number maximum value stored for the right subtree; SHBF _i A sender's filter stored for the node; SHBF _i ' a filter of the receiver stored for the node. For each non-leaf node in the underlying index, it is defined as follows:

the specific steps for constructing the index structure in the behavior data chain block are as follows:

s5.1, in the process of receiving the behavioral data transaction, cutting the behavioral data transaction by a certain time window to form continuous fragments. After receiving a complete sliced behavioral data transaction, classifying the last sliced data transaction according to a sender in parallel while receiving the next sliced data transaction, merging the classified sliced data by using a thread, and after the last sliced data transaction is classified, performing the last merging to enable the behavioral data transaction to be classified completely and sorting the behavioral data transactions according to the classifications;

s5.2, constructing a new intra-block index structure every time a new behavior data block is generated;

s5.3, calculating the number of leaf nodes and the number of non-leaf nodes required in the tree skeleton according to the number of the detected behavior data transaction sets, applying for node arrays with corresponding sizes in batches according to the number of all the nodes, constructing the tree skeleton, and pre-distributing a certain space for indexes in blocks, wherein the tree skeleton construction sequence is from left to right and from bottom to top;

S5.4, selecting the transaction number of the behavior data, the sender and the receiver as search code values, loading the search code values into a tree framework in a bottom-up mode, replacing the direct storage sender and the receiver with binary bits in non-leaf nodes of the structure, and storing the maximum transaction number of the left subtree and the right subtree.

Query process of index in behavior data chain block: when inquiring discrete attributes, sequentially judging whether the searched discrete attributes exist in left and right subtrees of the nodes by taking the root node as an initial node, if so, inquiring downwards, otherwise, displaying absence (a first preset inquiring sequence); when inquiring the numerical value attribute, the root node is taken as the initial node, whether the node exists in the left subtree or the right subtree of the node is judged, if the node exists in the left subtree, the node is inquired about the left subtree of the node, otherwise, the node is inquired about the right subtree of the node until the leaf node is inquired (a third preset inquiry sequence).

1.6 Cross-chain index design

Based on the chain structure between the hash pointer and the blocks, a cross-chain index structure is designed, namely, when a reputation new block is generated, the hash value of the current latest behavior block is recorded, and then, based on the hash pointer, a cross-chain structure capable of tracing the behavior block is formed, so that the efficiency of searching the behavior data block in the cross-chain process is improved.

1.7 verification index Structure design

Constructing a verification index structure on a reputation chain, which comprises the following steps:

s7.1, initializing OHbF (One-Hashing Bloom Filter, single Hash bloom Filter) with mm bits and 0 according to the number n of the classified credit transaction sets, wherein mm=10·n;

s7.2 dividing OHbF into k portions and allowing (mm) _i ,mm _j ) =1, 1. Ltoreq.i < j.ltoreq.k, where (mm) _i ,mm _j ) Expressed in mm _i And mm _j Greatest common divisor of (2), or mm _i And mm _j Are prime to each other, and

s7.3, respectively passing the hash values of the root nodes of all the bottom structures by mm _i Taking out and transporting the mouldAnd (3) calculating, namely setting the corresponding position of the OKBF as 1, and putting the OKBF into the block header after all the OKBF is finished.

Constructing a verification index structure on a behavior data chain, and specifically comprising the following steps of:

s8.1, selecting an intermediate layer from an index structure in a data chain block to serve as a verification layer, and initializing OHEF with mm bits and 0 according to the number of nodes of the verification layer;

s8.2 dividing OHbF into k portions and allowing (mm) _i ,mm _j ) =1, 1. Ltoreq.i < j.ltoreq.k, where (mm) _i ,mm _j ) Expressed in mm _i And mm _j Greatest common divisor of (2), or mm _i And mm _j Are prime to each other, and

s8.3, respectively passing hash values of nodes of the verification layer by mm _i And performing modular operation for the module, setting the corresponding position of the OKBF as 1, and putting the OKBF into a block head after all the OKBF is finished.

Taking a behavior data chain as an example, when the query is finished, a verification object and a verification object need to be constructed to judge the integrity of the query result set.

The process of constructing the verification object is introduced first, then the verification process of the query result set is introduced, the verification object is input, and if the verification is passed, the query result set is complete.

And verifying an object construction process. Adding the leaf node information queried in the intra-block index and the brother node information of the same father node into the verification object, acquiring the father node of the node, and if the node is not in the verification layer, continuing to add the leaf node information and the brother node of the same father node into the verification object; if the node is in the verification layer, the node is added into the verification object, and the verification object is constructed and returned to the common node.

And (5) verifying an object verification process. And converting the hash value of the node into binary bits according to the node reconstructed to the verification layer by the verification object, comparing with the OKBF in the block head, if the OKBF exists, completing the query result set, otherwise, indicating that the query is incomplete, and querying that the error exists.

In summary, since various index structures are introduced and the hash value of the index root node is put into the block header, the block header structure is changed, and the block header structure of the behavior data chain is as follows:

Wherein, pre Hash _data A chunk header hash value representing a previous row of data chunks; index _data Representing behavior data block numbers; ts _data Representing the time of packing the behavior data block; skip root _data A root hash value representing a jumplist, the jumplist recording pointers to indices between a plurality of blocks of packets; intraIndroot _data Hash value for index root node in block; randNum _data Random numbers selected for the packing behavior blocks; ADSRoot is the root of the validation index structure.

The block head structure of the reputation chain is as follows:

wherein, pre Hash _rep A chunk header hash value representing a previous reputation chunk; index _rep Is a reputation block number; ts _rep Time for packaging reputation blocks; skip roo _r t _ep Hash value for root node of jumplist; intraIndexRo _r o _ep t is the root node hash value of the index in the block; randNum _rep A random number selected for packaging the reputation block; ADSRoot is the root of the validation index structure; curHash _data A block header hash value of the latest block of the current behavior data chain; index _data A block number that is the behavioral data block associated therewith.

The following is a comparative description of the method in the examples of the present invention with the method in the prior art:

traversing the query: for single-block inquiry, traversing all intra-block transactions, searching transactions meeting inquiry conditions, for multi-block inquiry, circularly calling each block, and inquiring each block based on a single-block inquiry mode;

In the SEBDB method, the inter-block index is continuously added to the rightmost leaf node when the index is updated, the influence of sharp deterioration on the writing performance and the query performance of a blockchain system when more blocks are not considered, the same condition of the query keywords is not considered in the intra-block index, and the defect that the query keywords are easy to tamper is not considered;

in the vChain method, an index node directly stores discrete attributes, and adverse effects on query performance when the index size and the number of transactions in a block are large are not considered;

binary bits are used to replace direct storage discrete attributes in the BF-based indexing method, but query performance and index size are not combined.

Verifiable query optimization analysis for reputation-behavior-related double-blockchain is as follows:

(1) Query performance and query completion rate analysis with reputation value as key word in reputation chain

Fig. 5-6 are graphs showing comparison of query performance and query integrity rate using reputation values as keywords when the same number of reputation transactions is selected, as compared with the SEBDB method of the present invention:

(1.1) Single value query Performance and query completion Rate analysis with reputation value as key

Assuming that all transactions within the index and reputation blocks within a block have been loaded into memory, FIG. 5 shows the trend of single value query performance and query integrity rate over the same number for multiple transactions under a single block, where there are 1024 reputation transactions within a block. FIG. 5 (a) shows a query performance comparison for a single-value query, where the query time of the Rep_intra method increases with increasing number, just beginning slightly worse than the SEBDB+Trav method, and then transitioning to be better than this method, because the Rep_intra method only has left-most and right-most queries regardless of the same number changes, and the SEBDB+Trav method also begins to increase significantly due to increasing number of traversals; although the query time of the SEBDB method remains unchanged all the time, the method can only find one query result. Fig. 5 (b) shows a comparison of the query integrity rate of a single-valued query, as in fig. 5 (b), with the same number of changes, the query integrity rate decreases all the time, but the other two methods always have complete, non-missing query results. Therefore, the Rep_intra method is superior to the other two methods to a certain extent from the aspect of combining the single-value query performance and the query integrity rate.

(1.2) Range query Performance and query completion Rate analysis with reputation value as key

Assuming that all transactions within the index and reputation blocks within a block have been loaded into memory, FIG. 6 shows the trend of the range query performance and query integrity rate varying with the same number of reputation values for a single block, where the range of transactions to be queried is 4 x, where x is the same number, and there are 1024 reputation transactions within a block. Fig. 6 (a) shows a query performance comparison of range query, where the query time of the rep_intra method is always better than that of the sebdb+trav method, but slightly worse than that of the SEBDB method, because the single query time of the rep_intra method is slightly worse than that of the SEBDB method, the range query performance herein is slightly worse than that of the SEBDB method, and the query time of the sebdb+trav method is also increased due to the continuous increase of the number of traversals, and the query performance is worst. However, in the query completion rate comparison of the range query shown in fig. 6 (b), the query using the SEBDB method always omits part of the query results, and as the same number of reputation values change, the query completion rate is always reduced, while the other two methods always have complete, non-missing query results. Thus, the Rep_intra method is superior to other methods in general.

(2) Query performance and occupied storage space analysis with discrete attributes as keywords

Fig. 7-10 are diagrams of the comparison of the present aspect with the comparison method, comparing query performance and occupied storage space with discrete attributes as keywords:

taking the reputation chain as an example, the performance of the index structure within a block is tested. Assuming that all transactions within the index and reputation blocks within a block have been loaded into memory, FIG. 7 shows the trend of query performance for discrete attributes under a single block as a function of the number of transactions within a block. It can be seen that the query times of the bf_based Indexing method and the Vchain method significantly increase exponentially, while the query time of the rep_intra method only increases linearly with a lower slope. When the credit transaction scale is smaller, the inquiry performance of the method is slightly poorer than that of the two comparison methods, but from the larger credit transaction scale, namely after the credit transaction number is more than or equal to 4096, the inquiry performance of the method is always better than that of the BF_based Indexing method, and the difference between the two methods is gradually increased; after the number of the credit transactions is larger than or equal to 32768, the method is superior to the Vchain method, and meanwhile, the query performance difference between the credit transactions is gradually increased. As shown by analysis experiment results, as the BF_based Indexing method adopts the same BF size of the non-leaf nodes, when the number of transactions is continuously increased, the left sub-node and the right sub-node of the non-leaf nodes are difficult to judge whether to inquire leftwards or rightwards, so that more nodes can be inquired and judged; because the Vchain method adopts a mode that the non-leaf nodes directly store discrete attributes, when the number of transactions is continuously increased, the non-leaf nodes contain more and more discrete attribute keywords, so that more time is consumed in inquiring to judge whether the nodes contain inquiry keywords or not; the Rep_intra method is not affected by the two factors affecting query performance.

Fig. 8 shows the trend of false positive rate in the intra-block index with discrete attributes as keys as a function of the number of reputation transactions or number of leaf nodes in the intra-block index, where the occupied memory space for both methods is the same for the same number of transactions. As can be seen, the false positive rate of the BF_based Indexing method shows a rapid increase trend, and the false positive rate reaches one hundred percent when the number of transactions is 256, and at this time, for any query keyword, the method considers that the keyword exists in the index and does not have the capability of discriminating invalid query keywords; whereas the false positive rate of the Rep intra method only increases slightly. This is because: although the index sizes of the two index methods are the same, the BF_based Indexing method adopts the same mode that the BF size of the non-leaf nodes is the same, and when the transaction number is continuously increased, all the BF positions in the non-leaf nodes close to the root node in the BF_based Indexing method are set to 1, while the Rep_intra method does not present the situation, and the false positive rate is slightly increased because the index layer number is increased along with the increase of the transaction number.

FIG. 9 shows the trend of false positive rate in an index keyed by discrete attributes as a function of index size, where the number of reputation transactions is 1024. In the figure, when the index size is small, the false positive rate of the rep_intra method is almost 0, whereas the false positive rate of the bf_based Indexing method can reach a small value only when the index size is particularly large, and the method does not have the ability to discriminate an invalid query keyword or the ability to discriminate an invalid keyword is poor when the index size is small; when the index size is large, the method has the ability to identify invalid keywords, but the consumed memory space is huge. Referring to fig. 7, 8 and 9, when the size of the reputation transaction in the block is larger or larger, if the bf_based Indexing method wants to keep the query response time low, the false positive rate must be low, however, the storage space occupied by the index is large, and conversely, if the occupied storage space is small, the query time is large, and even the index is increased; but the Rep_intra method can well give consideration to query response time, false positive rate and index size.

FIG. 10 shows the trend of index occupancy as a function of the number of transactions or index leaf nodes within a block of memory size reputation. It can be seen that the memory space occupied by the Rep intra method is always smaller than that of the Vchain method, and the difference between the two memory spaces is gradually enlarged. The increase trend of the storage space occupied by the Vchain method is more obvious, and if the index structure is stored in the memory, more memory space is occupied; if the data is stored in the disk, the disk I/O overhead is increased during inquiry. This is because: the Vchain method uses non-leaf nodes to directly store discrete attributes, while the Rep_intra method uses binary bits instead of direct storage. Combining the experimental results of fig. 7 and 10, it can be seen that the Rep-intra method gives good consideration to both query response time and index size when the in-block reputation trade size is large, and is superior to the Vchain method.

(3) Query performance contrast for query blocks under inter-block index

Fig. 12-14 are graphs showing comparison of the cross-chain query response time versus the traversal query method of the present invention:

assuming that the inter-block index and the block are loaded into the memory, taking reputation chain as an example, the experiment tests the query performance of the block query under four implementation methods, and tests the query performance by changing the reputation block size, wherein rep_inter (i=1, 2, 3) is a group divided into 1024, 2048 and 4096 block sizes respectively. In the experiment, the block number is used as a query keyword to perform block query. Fig. 11 shows the query performance of executing a block query. Experimental results show that the query performance of the Rep_intei method is obviously superior to that of the SEBDB method, and as the Rep_intei method decomposes the inter-block index structure into a plurality of equal-height group inter-block index structures, the index height is reduced, the pressure of inter-block index stored in a memory or the I/O overhead of a disk during disk storage is reduced, and particularly, the query performance difference between different methods is continuously changed in the process of increasing the block number scale from 4096 to 4194304.

(4) Query performance comparison between retrospective query and time window-based query in cross-chain query

First, the query performance of a retrospective query is tested. Fig. 12 and 13 show the query performance of a retrospective query. In fig. 12, the query performance of the retrospective query under different reputation block numbers is given, retrospective query using the block number and the evaluated party as keywords is performed, and assuming that the reputation block and the behavior data block are associated in one-to-one correspondence, the behavior data block number is the same as the reputation block number, and the transaction number in the block is 2048. In the figure, the size of the query result set is fixed to 16384 behavioral data transactions, and the query processing performance of the text index is obviously superior to that of the traversal index method in all cases. This is because the index here only needs to read the queried behavioural data transactions directly from disk, while traversing the index needs to read all transactions within the associated double-blockchain, resulting in a large query overhead.

Fig. 13 shows the query performance of the retrospective query under different query result scales, and retrospective query using the block number, the evaluated party and the single reputation value as keywords is performed, and the reputation blocks and the behavior data blocks are assumed to be associated in one-to-one correspondence, wherein the number of the blocks of the two chains is 1024, and the number of the transactions in the blocks is 1024. In the figure, query performance was tested for query result set sizes ranging from 2048 to 10240. Experimental results show that the query processing performance of the text index is significantly better than the walk index approach in all cases, because the text index only needs to read the queried transactions directly from disk, while the walk index needs to read all transactions of the associated dual-blockchain. However, as the size of the query result set increases, the performance difference between the method and the traversal index method is decreasing, because the I/O overhead of the method to read the disk increases, so that the query performance of the method decreases and the query response time increases; while the traversal index is not affected by the size of the query result because the method has scanned all transactions.

Then, the query performance of time window query under different time windows is tested, query with time stamp, evaluated party and range reputation value as key words is carried out by combining the inter-block index and the intra-block index, and the reputation blocks and the action data blocks are assumed to be in one-to-one correspondence, wherein the number of blocks in each chain is 1024, and the number of transactions in each block is 1024.TW (twinning tag) _i ＝[1024-1024/2 ⁱ ^-1 ,1024]Where i=1, 2,3,4,5, is a time window, representing a time period from (1024-1024/2) ^i-1 ) Query range of time stamps of blocks to 1024 th block. Fig. 14 shows the query performance of a time window query. It can be seen that the query processing performance of the text index is significantly better than the traversal index approach in all cases, because the text index can directly query the corresponding behavioural data transactions and only need to directly read the queried behavioural data transactions from disk, while the traversal index needs to read all transactions within the associated dual-blockchain. As the time window decreases, query performance increases as both the size of the query results and the number of blocks to be queried decrease.

(5) Verification object size and verification time comparison of query results

Taking a behavior data chain as an example, the verification performance of the multi-query result set is tested. FIG. 15 illustrates the validation performance of multiple query result sets under intra-block indexing in a behavioral data chain. In the figure, the number of behavioral data transactions in a block is 1024, and the verification layer selects layer 5 from the root node layer in the intra-block index. Fig. 15 (a) shows a comparison of verification times under multiple query results, wherein the trend of verification times for multiple query result sets with query result set size is shown, wherein the query result size varies from 1.5625% to 100%. It can be seen that the verification time of the multi-query result set of the method herein is always superior to the comparative method compared to the SEBDB method, and the advantage of the verification time tends to be gradually apparent, as the method employed herein gradually reduces the number of hash calculations more. Fig. 15 (b) shows a verification size comparison case under multiple query results, in which a trend of verification object sizes of multiple query result sets is displayed as a function of the query result set size, in which the query result size is changed from 1.5625% to 100%. In contrast to the SEBDB method, the verification object size of the multi-query result set of the method herein is always smaller than that of the comparative method, and the difference in verification object size is progressively larger because the method employed herein saves some non-leaf nodes that are loaded into the intra-block index structure.

Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present invention, and not for limiting the same; although the invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some or all of the technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit of the invention.

Claims

1. A verifiable query optimization method for reputation-behavior-related double-blockchain, comprising:

the common node sends a query request to the edge node; an index structure and a verification index structure are built in the edge nodes, root node hash values of the index structure and verification index structure roots are stored in the block heads, and consensus is achieved in the whole network along with the blocks; the system comprises an index structure, a verification index structure and a data link verification index structure, wherein the index structure comprises an inter-block index structure, a reputation link intra-block index structure and a behavior data link intra-block index structure, the verification index structure comprises a reputation link verification index structure and a behavior data link verification index structure, and the inter-block index is an MBerkle tree mountain index structure based on a tree skeleton and a jump list; the index in the reputation chain block is a two-layer tree structure facing multi-keyword query; the index in the behavior data chain block is of a single-layer tree structure;

2. The verifiable query optimization method of claim 1, wherein the construction of the inter-block index structure comprises:

presetting a packet size N _block Calculating the number N of the corresponding leaf nodes _leaf ＝N _block And the number of non-leaf nodesWherein->Representing the height of the tree skeleton, N _b Representing the number of sub-nodes contained in non-leaf nodes, applying for node arrays with corresponding sizes in batches according to the number of all nodes in the tree skeleton, constructing the tree skeleton, pre-distributing certain space for indexes among grouping blocks, and constructing the tree skeleton in the sequence of from left to right and from bottom to top;

when the block number of the new block is N _block When +1, the default inter-block index is full, and the jumplist needs to be updated, i.e. the leaves of the jumplistThe sub-node additionally stores the search code value information of the previous block and a pointer to the index between the block groups, updates the maximum search code value in the root node, and repeats the above steps, creating a new index between the block groups and updating the skip list when the index is full.

3. The verifiable query optimization method of claim 1, wherein the construction of the index structure in the reputation chain block comprises:

selecting a reputation value and an evaluation party as search code values, loading the search code values to each bottom index in batches in a bottom-up mode by using multithreading, wherein the non-leaf nodes store lMinrep and rMaxrep, lMinrep represents the minimum reputation value in a left subtree and rMaxrep represents the maximum reputation value in a right subtree, and binary bits are used for replacing the direct storage evaluation party; the SHBF of the parent node initializing all leaf nodes has m bits and is 0, and hash ₁ (eva)％m,...,hash _k/2 (eva)％m,hash ₁ (eva)％m+o(eva),...,hash _k/2 (eva)% m+o (eva) is set at 1, where eva represents any evaluation party contained in the node, k represents the number of hash functions, o (eva) represents the offset, and Wherein the method comprises the steps ofAnd omega represents the number of bytes of the machine, and the SHBF of nodes at other layers in the index is sequentially increased by 2 times;

4. The verifiable query optimization method of claim 1, wherein the construction of the index structure within a behavior data chain block comprises:

5. The verifiable query optimization method of claim 3, wherein the construction of the reputation chain verification index structure comprises:

6. The verifiable query optimization method of reputation-behavior association double-blockchain as in claim 4, wherein the construction of the behavior data chain verification index structure comprises:

7. The verifiable query optimization method of claim 5 or 6, wherein constructing a verification object based on a verification index structure comprises:

8. The method of verifiable query optimization for reputation-behavior-oriented dual-blockchain of claim 7, wherein the common node verifies the integrity of the query result set based on the verification object and the verification index structure root stored in the blockhead, comprising:

9. The verifiable query optimization method of reputation-behavior-oriented dual-blockchain of claim 1, wherein the index structure further comprises: a cross-chain indexing structure.

10. The verifiable query optimization method of reputation-behavior-oriented double-blockchain of claim 9, wherein the construction of the cross-chain index structure comprises: