CN111680317A - Block chain-oriented optimistic concurrency order-preserving coding method - Google Patents

Abstract

The invention discloses a block chain-oriented optimistic concurrent order-preserving coding method, wherein order-preserving coding is a coding method, the sequencing sequence of coding is matched with the sequencing sequence of a plaintext, and the order-preserving coding is applied to a privacy field of block chain transaction data, so that sensitive information can be protected from being leaked, and convenient query on a ciphertext is supported. The invention provides an order-preserving coding method suitable for a blockchain multi-client-multi-server model, wherein order-preserving coding is usually realized as an order-preserving coding dictionary, and the dictionary is maintained on each blockchain node to be shared among participants. In order to improve the system throughput, the invention provides an optimistic concurrent coding scheme, which comprises a concurrent coding stage and a conflict resolution stage. In addition, the invention provides a point query and range query method based on a ciphertext, and provides a cache-based method for range query in order to improve the query efficiency.

Description

Block chain-oriented optimistic concurrency order-preserving coding method

Technical Field

The invention belongs to the technical field of block chains, relates to privacy protection of data in a block chain, and particularly relates to a block chain-oriented order-preserving coding method.

Background

The blockchain is an untamperable, history data traceable distributed ledger, and has a wide application field, but in most of the current blockchain systems (such as etherhouses and superhedger fabrics), only a cryptographic signature is used to prevent the transaction from being tampered, and the transaction content is still stored in the clear text and can be seen by all participants. In fact, the privacy protection problem of blockchains is more important between participants who lack trust than other data sharing approaches.

A direct privacy data protection method is characterized in that privacy data are directly encrypted, a data owner uploads the encrypted privacy data to block chain link points and forwards the encrypted privacy data to a block chain network for consensus, and the data are stored on a local block chain account book of each node in a ciphertext mode after the data are known in the network. Various existing data encryption methods such as Homomorphic Encryption (HE), Searchable Encryption (SE) and the like exist, but the encryption methods are low in efficiency and high in cost.

The present invention employs more efficient order preserving encryption, otherwise known as Order Preserving Encoding (OPE). The order-preserving coding is a coding method, the ordering sequence of the coding is matched with the corresponding plaintext sequence, and the characteristic has the advantages that the system can execute the same ordering operation as the plaintext on the coding, thereby facilitating the point query and the range query on the coding. The ideal security of OPE is IND-OCPA (indestructibility under ordered choseng-onset attack, indistinguishable under an ordered choice of plaintext attack), i.e., no information is leaked in the plaintext except in order. There are many methods of order-preserving coding that achieve this security. The order-preserving code has the advantages of high efficiency, convenience in query and high safety, and is widely applied to privacy protection, encryption database (CryptDB) and the like in outsourced databases.

An OPE is typically implemented as a guaranteed-order encoded dictionary, which may be stored at the client or server. Most of the traditional order-preserving coding methods are only suitable for a single client-single server model, wherein the premise is that the client is credible and the server is incredible, the server stores ciphertext data uploaded by the client and does not know other information of a plaintext except the order, and a block chain is a multi-client-multi-server model; and the traditional order-preserving coding either does not consider concurrency control or suggests the use of fine-grained locks, which is very inefficient in the blockchain and risks the shutdown of the client blocking the entire system; further, unlike conventional databases, transactions in a blockchain are performed in batches, all nodes must perform transactions, and the same execution results are obtained. Therefore, the existing order-preserving coding methods are not suitable for the block chain scene.

Disclosure of Invention

The invention provides a block chain-oriented optimistic concurrent order-preserving coding method, which specifically comprises the following steps:

step 1: initializing local OPE trees by all nodes in the block chain network;

step 2: for a data entry needing to be uploaded, a data owner encrypts a plaintext value of a privacy field and sends a ciphertext to a block link point to request coding;

and step 3: the block chain link point calculates the order-preserving code of the received ciphertext and sends the coding result to the data owner; if the tree needs to be rebalanced in the encoding process, sending a rebalancing message to the data owner;

and 4, step 4: after receiving the coding result sent by the block chain node, the data owner initiates a TX _ ENC type transaction proposal, wherein a privacy field is a ciphertext, other non-privacy fields are plaintexts and comprise calculated order-preserving codes, the path of the transaction proposal on a tree and the version number of a current OPE tree are sent to a block chain main node together, and the main node is a block chain consensus algorithm; if the data owner receives the rebalancing message, initiating a TX _ UPD type transaction proposal to the host node;

and 5: after receiving a transaction proposal sent by a data owner, the main node stores the transaction proposal in a local transaction pool;

step 6: the main node takes out a fixed number of transactions from the transaction pool and packs the transactions into blocks, and each transaction in the blocks is executed in advance in series;

and 7: the master node carries out voting consensus on the blocks without conflict transactions among the slave nodes, the slave nodes carry out the same verification method as that of the master node in advance for each transaction in the blocks, if the conflict transactions exist in the block chain, the consensus voting is refused, and if the conflict transactions do not exist in the block chain, the consensus is continued;

and 8: the identified block is written into a local account book of each node, and a local OPE tree is also updated;

and step 9: authorizing a query user to perform point query on the ciphertext on the OPE tree;

step 10: authorizing the inquiry user to perform range inquiry on the ciphertext on the OPE tree;

step 11: and authorizing the inquiry user to perform cache-based range inquiry on the ciphertext on the OPE tree.

The encoding process in step 3 of the present invention specifically includes:

step 3-1: initializing an OPE tree by block chain link points, generating two boundary nodes of < Encrypt (-1, sk), -1>, < Encrypt (M, sk), N >, wherein sk is an encryption key, Encrypt is an encryption algorithm and can be symmetric encryption or asymmetric encryption, and returning a ciphertext through an incoming key and a plaintext to be encrypted;

step 3-2: the data owner encrypts a plaintext value x to be encoded by using a key sk and sends a ciphertext to a block chain node to request encoding;

step 3-3: the node calculates order-preserving codes for the received ciphertext, and the coding process specifically comprises the following steps:

step 3-3-1: if the root node is empty, directly calculating the median value of-1 and N as a code and sending the code to a data owner; otherwise, the block link node sends the ciphertext c' of the root node of the OPE tree to the data owner;

step 3-3-2: after receiving the ciphertext c ' of the root node, the data owner decrypts the ciphertext to obtain a plaintext x ' of the root node, compares the plaintext x ' with a value x to be coded, and sends a comparison result to the block chain node;

step 3-3-3: if x > x', the blockchain node sends the ciphertext of the right child node of the root node in the OPE tree to the data owner; if x < x', sending the ciphertext of the left child node; if x is x', directly returning the code of the root node to the data owner, otherwise, jumping to the step 3-4;

step 3-3-4: if there is no node in the OPE tree with a plaintext equal to x, the data owner and the blockchain node repeat the interactive process in steps 3-3-2 and 3-3-3 until the blockchain node traverses to an empty position in the OPE tree; two nodes v1 are set, v2 is two nodes which are arranged in order on the traversal path and enable corresponding plain texts x1 and x2 to meet the condition that x1 is not less than x and not more than x2, the code of v1 is y1, the code of v2 is y2, if the difference between y2 and y1 is not 1, the median value of y1 and y2 is calculated to be the code y of x, namely the code y of x is

Returning y to the data owner, otherwise, skipping to the step 3-3-5;

step 3-3-5: the difference between y2 and y1 is 1, which means that the coding field has insufficient space for coding, the whole OPE tree needs to be rebalanced to make the coding distribution more uniform, and thus the data owner needs to be sent a message of rebalancing.

Step 6 of the present invention specifically includes:

step 6-1: if the transaction type is TX _ ENC, firstly obtaining the version number in the transaction, comparing the version number with the version number of the current OPE tree, and if the version number is not equal, directly stopping the transaction; if the two are equal, firstly traversing to a position which is supposed to be written in the OPE tree according to a path in the transaction, if a node exists at the position, stopping the transaction, and otherwise, writing a ciphertext-coding pair in the transaction to the tree;

step 6-2: if the transaction type is TX _ UPD, the OPE tree needs to be rebalanced, the rebalancing updates codes on all the trees, the OPE tree is initialized to be two boundary nodes, then all different ciphertexts are recoded in sequence, the codes are calculated according to the same calculation method, namely, the median values of two corresponding codes with the plaintext smaller than the current plaintext and the plaintext larger than the current plaintext in a continuous sequence are calculated, the values in the middle of all the nodes in sequence are firstly compiled, then the median value in the left sequence is compiled, then the median value in the right sequence is compiled, and so on, the process is a recursive process, the temporarily balanced tree is finally generated, and then the version number of the global tree is added with 1.

Step 9 of the present invention specifically includes:

step 9-1: authorizing the inquiry user to encrypt the plaintext to be inquired and sending the ciphertext to the block chain node;

step 9-2: the block chain node sends the root node pair ciphertext of the OPE tree to the authorized inquiry user;

step 9-3: authorizing the inquiry user to decrypt the ciphertext of the root node, comparing the ciphertext with the plaintext value to be inquired, sending a comparison result to the block chain node, and sending the ciphertext of the left child or the right child of the root node by the block chain node according to the comparison result; repeating the interaction process until the query value is found, and then putting the corresponding transaction into a result set and returning the result set to the authorized query user; if not, an empty result set is returned to the authorized querying user.

In step 10 of the present invention, a query user initiates queries on plaintext xl and xr of two range boundaries to a block chain node, the block chain node queries by an interactive method similar to point query to obtain two tree nodes v1 and v2, so that the plaintext corresponding to v1 is the smallest among xl and the plaintext corresponding to v2 is the largest among xr, and then the block chain node puts transactions corresponding to all nodes between v1 and v2 into a result set and returns the result set to the query user.

Step 11 of the present invention specifically includes:

step 11-1: setting the plaintext of range query as [ xl, xr ], authorizing a query user to search two records e1 and e2 in a local cache table firstly, so that the plaintext of e1 meets the condition that the plaintext is smaller than the maximum of xl, and the plaintext of e2 meets the condition that the plaintext is larger than the minimum of xr, and then sending the code of e1 and the code of e2 to a block chain node;

step 11-2: after receiving the two codes, the block chain node directly performs range query on the OPE tree without interaction with an authorized query user, and then the corresponding transactions within the two code ranges are orderly put in a result set and returned to the authorized query user;

step 11-3: and after the authorized inquiry user receives the result set, decrypting the ciphertext, traversing from two sides, and filtering the transactions which do not meet the inquiry range until the transactions which meet the conditions are traversed.

The invention discloses an optimistic concurrent order-preserving coding method facing a block chain, which is called oOPE. The order-preserving coding is a coding method, the sequence of the coding is matched with the sequence of the plaintext, sensitive information can be protected from being leaked by applying the order-preserving coding to the privacy field of the block chain transaction data, and convenient query on a ciphertext is supported. However, the conventional order-preserving coding cannot be directly used on the blockchain because only a single client-single server model is supported. The present invention therefore proposes a method of order-preserving coding suitable for a blockchain, a multi-client-multi-server model, where the order-preserving coding is usually implemented as a order-preserving coding dictionary, which is usually in the form of a tree, called an encoding tree (OPE tree), and the present invention maintains the dictionary at each blockchain node for sharing among the participants. The traditional order-preserving coding does not support concurrency or uses fine-grained locks for concurrency, but is relatively low in efficiency for a block chain and has the risk of blocking the whole system after a client is down, so that the invention provides an optimistic concurrent coding scheme which comprises a concurrent coding stage and a conflict resolution stage in order to improve the system throughput. In addition, the invention provides a point query and range query method based on a ciphertext, and provides a cache-based method for range query in order to improve the query efficiency.

Drawings

FIG. 1 is a schematic diagram of order preserving coding;

FIG. 2 is a system architecture diagram of the present invention;

FIG. 3 is two stages of the order preserving coding scheme of the present invention;

FIG. 4 illustrates two types of collisions SCC and UC encoded in the present invention;

FIG. 5 and FIG. 6 are embodiments of an optimistic concurrent coding scheme oOPE in the present invention;

FIG. 7 is a ZOPE tree structure proposed by the present invention;

FIG. 8 is an embodiment of an order preserving coding scheme cr-oOPE based on a collision mitigation method;

FIG. 9 is a plot of write performance versus input data set size for different systems implemented;

FIG. 10 is a graph of write performance versus block size for different systems implemented;

FIG. 11 is a graph of write performance versus number of encoding threads for different systems implemented;

FIG. 12 is a plot of write performance versus capacity of an undetermined area for a system based on collision mitigation;

FIG. 13 illustrates throughput and latency for two result sets, with range queries and cache-based range queries performed concurrently in different systems implemented.

Detailed Description

The method is described in detail in connection with the following specific embodiments and the accompanying drawings. The overall process, conditions, experimental methods and the like for carrying out the method are all common knowledge in the art except for the contents specifically mentioned below, and the contents are not particularly limited in the present invention.

The invention provides an order-preserving coding method aiming at block chain privacy protection, which is called oOPE. The design includes three roles: 1) data owner, 2) blockchain node, 3) query user. The data owner maintains a security key to encrypt sensitive fields of the data set and sends the encrypted data entries to the blockchain node requesting order-preserving encoding. In order to make the order-preserving code shared among all participants, the invention maintains a dictionary on each blockchain node, where < ciphertext, order-preserving code > pairs are maintained, as shown in fig. 1. In the invention, the dictionary is implemented as a binary ordering tree called OPE tree, and the OPE tree can be regarded as an index of transactions in a blockchain. The inquiry user inquires data from the block chain nodes, if the data is inquired on the ciphertext and the authorization of the data owner needs to be obtained, the authorized inquiry user and the data owner share the same secret key, the inquiry is initiated by using the encrypted ciphertext, and the returned result set is decrypted. The system architecture is shown in fig. 2. It should be noted that, assuming the plaintext field size is M and the code field size is N, N is much larger than M in order to improve security.

In order to improve the system throughput, the present invention performs coding concurrently, a lock-based concurrency control protocol is less efficient, and if a client goes down, the whole system is blocked, so the present invention proposes an optimistic concurrency coding scheme, which includes two phases, a concurrency coding phase and a conflict resolution phase, as shown in fig. 3:

in the concurrent encoding stage, a data owner and block chain nodes interactively and concurrently encode the privacy field of the data set, the block chain nodes reply the calculated codes to the data owner, the data owner organizes a transaction, the privacy field is ciphertext, other fields are plaintext, and then a transaction proposal is initiated to a main node. Since the encoding process relies on data items in the OPE tree, collisions are unavoidable. Conflicts include two types: 1) encoding requests for different ciphertexts have the same traversal path on the OPE tree, and therefore the same encoding is calculated, as shown in fig. 4(a), such a collision is referred to as scc (same codecontext); 2) during processing of an encoding request or before writing to a tree node, the OPE tree may perform an update operation, so that all encodings on the tree are changed, and therefore the encoding calculated by the encoding request is also incorrect, as shown in fig. 4(b) and 4(c), and this conflict is called uc (update confllict).

Therefore, in the conflict resolution stage, the master node collects transactions initiated by the data owner, packages the blocks, performs pre-execution, detects conflicting transactions and rejects the conflicting transactions. For the first conflict (SCC), the solution is to detect if there is already a node at the location where a transaction of TX _ ENC type should be written in the OPE tree, and if so, to abort; for the second conflict (UC), a global version number v _ tree is set to the OPE tree and initialized to 0, the version number is incremented by 1 each time rebalancing occurs, the transaction proposal of TX _ ENC type is sent to the blockchain node together with the OPE tree version number at encoding, then the transaction is executed while checking whether the version number is equal to the version number of the current tree, and if not, the transaction is aborted. And then, performing consensus on the blocks without conflict in all the nodes, verifying the blocks by the slave nodes receiving the blocks by using the same detection method, if the blocks still have conflicts, indicating that the master node is a malicious node, rejecting voting, and if not, continuing to run a consensus algorithm to achieve consensus on the blocks and writing the consensus into a local account book.

The optimistic concurrency order-preserving coding method oOPE provided by the invention specifically comprises the following steps:

step 1: initializing local OPE trees by all nodes in the block chain network;

step 2: the data owner encrypts the plaintext of the privacy field of the data entry and sends the ciphertext to the block chain node to request coding;

and step 3: the block chain link point calculates order-preserving codes for the received ciphertext, and since the block chain link node cannot know the plaintext, the block chain link point needs to interactively judge the size of the data owner to traverse the OPE tree when the ciphertext data is subjected to order-preserving coding. The process of interactively calculating the order-preserving code specifically comprises the following steps:

step 3-1: the block chain link point firstly sends the ciphertext of the root node of the OPE tree to a data owner;

step 3-2: after the data owner decrypts the data, the size of the data owner is compared with the size of a plaintext to be coded, and a left child or a right child of a root node is requested according to a comparison result;

step 3-3: looping steps 3-1 and 3-2 until an empty location on the OPE tree is reached or the ciphertext to be encoded is found on the OPE tree;

step 3-4: and taking the continuous ordered sequence of all nodes on the OPE tree, calculating the median value of two adjacent codes of which the corresponding plaintext is smaller than x and the corresponding plaintext is larger than x as the order-preserving code of x, and replying the result to the data owner. If there is no integer that can be used as the code, i.e. when the median of two codes is calculated, the difference between the two codes is 1, which indicates that the OPE tree needs to be updated, and then an update message is sent to the data owner.

And 4, step 4: after receiving the coding result sent by the block chain node, the data owner initiates a TX _ ENC type transaction proposal; if the data owner receives the rebalancing message, initiating a TX _ UPD type transaction proposal to the host node;

and 5: after receiving a transaction proposal sent by a data owner, the main node stores the transaction proposal in a local transaction pool;

step 6: the main node takes out a fixed number of transactions from the transaction pool and packs the transactions into blocks, and performs each transaction in the blocks in advance in series, and the method specifically comprises the following steps:

step 6-1: if the transaction type is TX _ ENC, checking whether the version number of the OPE tree changes from the time of calculating codes or not, if so, directly stopping the transaction, otherwise, checking whether a node already exists in a position to be written in the OPE tree, if so, stopping the transaction, otherwise, writing a < ciphertext and code > pair in the transaction to the tree;

step 6-2: if the transaction type is TX _ UPD, rebalancing the OPE tree, i.e., updating the codes on all trees, creating a (temporarily) balanced tree, then adding 1 to the global tree version number;

and 7: the master node carries out voting consensus on the blocks without conflict transactions among the slave nodes, the slave nodes carry out a verification method which is the same as that of the master node in advance for each transaction in the blocks, if the conflict transactions exist in the block chain and indicate that the master node is bad, the consensus voting is refused, and if the consensus is not continued;

and 8: the agreed upon block will be written to the local ledger for each node and the local OPE tree will also be updated.

Aiming at the query of an authorized query user on an OPE tree ciphertext, the invention provides a processing point query and range query method. Point query requires traversing the OPE tree once, and the range query method is to traverse the OPE tree twice first to find two query ranges, and then return all the results in between. In order to improve the efficiency of range query, the invention provides a cache-based query method, which is characterized in that a cache table is maintained locally by an authorized query user, a plurality of plaintext-coding pairs are stored in the table, one plaintext-coding pair is recorded at regular intervals according to the number of records on an OPE tree, and the range query on the OPE tree based on the cache specifically comprises the following steps:

step 1: an authorized query user finds two items which just cover a query range in a cache, and then sends codes corresponding to the two items to a block chain node;

step 2: the block chain nodes are locally and directly inquired according to the codes without any interaction, and then the result set is returned to the authorized inquiry user;

and step 3: and the authorized inquiry user decrypts the result set and locally filters the transactions which do not meet the inquiry range.

In order to reduce the collisions referred to above, the present invention proposes a scheme based on collision mitigation, called cr-opope. The main idea is as follows:

first, the calculation method of the randomized coding of the present embodiment is to add a random number after the original coding method. Assuming that x is the plaintext value to be encoded, v1 and v2 are two nodes of the ordered arrangement on the path traversing the OPE tree such that the corresponding plaintext x1 and x2 satisfy x1 ≦ x2, and the encoding of v1 and v2 is y1 and y2, if the difference between y2 and y1 is not 1, then the encoding y for x is calculated as:

wherein it is a random number following a normal distribution, and the mathematical expectation is

Second, although code randomization reduces the probability that different plaintexts compute the same code, since the OPE tree is a binary ordered tree, the nodes that compute the code with y1 and y2 still need to be inserted into the same position in the OPE tree during computation, which does not reduce collisions. To solve this problem, this embodiment proposes a concept of undefined zone (UDZ for short), UDZ can put multiple tree nodes, whose codes are not order-preserving but all are in a certain range, i.e. between y1 and y 2. This embodiment puts UDZ's structure to the leaf node of the OPE tree and refers to the OPE tree with UDZ structure as a ZOPE tree. The structure of the ZOPE tree is shown in FIG. 7: the left child of a tree node may be a tree node or a UDZ, as may the right child. UDZ have neither left nor right children, so UDZ can only be leaves of the ZOPE tree. With the UDZ structure, the tree nodes that would otherwise need to be inserted into the same position in the OPE tree but encoded differently can be placed in one UDZ and the related transactions can be committed without being aborted.

Again, no nodes can be placed indefinitely in UDZ, so capacity needs to be limited. When one UDZ has been filled with nodes, other transactions related to tree nodes falling within this UDZ still need to be aborted. When a code request encounters a full UDZ while traversing the ZOPE tree, the blockchain node needs to re-group the UDZ into sub-trees to be hung on the ZOPE tree, which requires the assistance of the data owner because the code in UDZ is random and not order-preserving, and therefore the tree nodes in UDZ need to be re-ordered, i.e., each ciphertext is assigned a corresponding code, and the results of the ordering are sent to the blockchain node for re-group. If the ZOPE tree needs rebalancing, the blockchain nodes re-balance all the nodes in UDZ on the tree first, which also needs the help of the data owner, i.e. the blockchain nodes send all the nodes in UDZ to the data owner, the data owner sorts the nodes, sends the sorted nodes back to the blockchain nodes, and the blockchain nodes are re-recombined.

Finally, when rebalancing is performed, all UDZ nodes rearranged are incorrect because after sending all UDZ to the data owner at the block link node and before performing a rebalancing type transaction, the UDZ structure on the tree may change, such as some regroups and some newly placed nodes. Therefore, in order to perform verification at execution time, in addition to the above-mentioned tree version number v _ tree, a global version number v _ udz needs to be defined for all UDZ and initialized to 0, each time UDZ changes occur on the ZOPE tree, the version number is increased by 1, before rebalancing, it is checked whether the version number changes UDZ, and rebalancing can be performed if the version number does not change. In addition, to prevent multiple code requests from rearranging the same UDZ structure, which results in unnecessarily large aborts of transactions during execution, when a code request finds a full UDZ, its parent node is locked, during which time other code requests cannot access the node until UDZ has recombined to release the lock.

The optimistic concurrent order-preserving coding method cr-oOPE for reducing coding conflict specifically comprises the following steps:

step 1: initializing local ZOPE trees by all nodes in the block chain network;

step 2: the data owner encrypts the plaintext of the privacy field of the data entry and sends the ciphertext to the block chain node to request coding;

and step 3: the node calculates order-preserving codes for the received ciphertext, and the coding process specifically comprises the following steps:

step 3-1: traversing the ZOPE tree by the block chain nodes and the data owner in an interactive mode;

step 3-2: if the node of the block chain in the traversing process encounters a full UDZ, firstly, the randomized coding calculation method is used for calculating the currently encoded code, and then the calculation result together with all the nodes in UDZ is sent to the data owner to request the nodes to be sorted; the data owner rearranges the nodes after receiving the data and initiates a TX _ SORT type transaction proposal to the main node;

step 3-3: if the node of the block chain in the traversing process finds that the ZOPE tree needs to be rebalanced, all nodes in UDZ structures in the tree are sent to a data owner to request sorting; the data owner rearranges the nodes after receiving the data and initiates a TX _ SORT type transaction proposal to the main node;

step 3-4: if the current block is traversed to an empty position, calculating the currently encoded code by using a randomized code calculation method and initiating a TX _ ENC type transaction proposal to the main node;

and 4, step 4: after receiving a transaction proposal sent by a data owner, the main node stores the transaction proposal in a local transaction pool;

and 5: the main node takes out a fixed number of transactions from the transaction pool and packs the transactions into blocks, and performs each transaction in the blocks in advance in series, and the method specifically comprises the following steps:

step 5-1: if the transaction type is TX _ SORT, firstly checking whether the version number of the ZOPE tree changes from UDZ to the data owner or not, if so, directly stopping the transaction, otherwise, recombining the UDZ according to a rearranged node, and adding 1 to the global UDZ version number after recombining;

step 5-2: if the transaction type is TX _ UPD, the ZOPE tree needs to be rebalanced, whether the version number of the global UDZ changes from all UDZ data owners to the current is checked, if the version number changes, the transaction is directly stopped, otherwise, the whole ZOPE tree is rebalanced, and then the version number of the global tree is increased by 1, and the version number of the global UDZ is increased by 1;

step 5-3: if the transaction type is TX _ ENC, first check if the ZOPE tree version number changes from encoding to present, if so, directly abort the transaction, otherwise check the location on the ZOPE tree where it should be written: if there is already a node at this location and it is not equal to the code to be inserted, create UDZ at this location, put the already existing node and the node to be inserted into this UDZ, then add 1 to the global UDZ version number; if there is already a node in this location that is not full UDZ and where there is no node with a code equal to the code to be inserted, then place the node to be inserted into this UDZ and then add 1 to the global UDZ version number; if the position is empty, directly placing the node to be inserted in the position; otherwise, the transaction is stopped;

step 6: the master node carries out voting consensus on the blocks without conflict transactions among the slave nodes, the slave nodes carry out a verification method which is the same as that of the master node in advance for each transaction in the blocks, if the conflict transactions exist in the block chain and indicate that the master node is bad, the consensus voting is refused, and if the consensus is not continued;

and 7: the identified blocks will be written to the local ledger of each node and the local ZOPE tree will also be updated.

Point query, range query and cache-based range query on the ZOPE tree are similar to the OPE tree, except that if a blockchain node encounters an UDZ structure during the query process, whether full or not, it needs to reorganize UDZ first with the assistance of the data owner and then continue the query.

Example 1

The optimistic concurrency order-preserving coding method opope provided by the embodiment specifically includes the following steps:

step 1: initializing local OPE trees by all nodes in the block chain network;

step 2: for a data entry needing to be uploaded, a data owner encrypts a plaintext value of a privacy field and sends a ciphertext to a block link point to request coding;

and step 3: the block chain link point calculates order-preserving codes for the received ciphertext, and since the block chain link node cannot know the plaintext, the block chain link point needs to interactively judge the size of the data owner to traverse the OPE tree when the ciphertext data is subjected to order-preserving coding. The interactive encoding process specifically comprises the following steps:

step 3-1: if the root node is empty, directly calculating the median value of-1 and N as a code and sending the code to a data owner; otherwise, the block link node sends the ciphertext c' of the root node of the OPE tree to the data owner;

step 3-2: after receiving the ciphertext c ' of the root node, the data owner decrypts the ciphertext to obtain a plaintext x ' of the root node, compares the plaintext x ' with a value x to be coded, and sends a comparison result to the block chain node;

step 3-3: if x > x', the blockchain node sends the ciphertext of the right child node of the root node in the OPE tree to the data owner; if x < x', sending the ciphertext of the left child node; if x is x', directly returning the code of the root node to the data owner, otherwise, jumping to the step 3-4;

step 3-4: if there is no node in the OPE tree with plaintext equal to x, the data owner and the blockchain node repeat the interactive process in steps 3-2 and 3-3 until the blockchain node traverses to an empty location in the OPE tree. Is provided with two sectionsThe points v1 and v2 are two nodes of the ordered nodes on the traversal path, which enable the corresponding plaintexts x1 and x2 to satisfy x1 ≦ x2, and if the difference between y2 and y1 is not 1, the median value of y1 and y2 is calculated as the encoding y of x, namely the encoding y of x is calculated, assuming that the encoding of v1 is y1 and the encoding of v2 is y2

Returning y to the data owner, otherwise, skipping to the step 3-5;

step 3-5: the difference between y2 and y1 is 1, which means that the coding field has insufficient space for coding, the whole OPE tree needs to be updated to make the coding distribution more uniform, and then the message that the data owner needs to update is sent.

And 4, step 4: after receiving the coding result sent by the blockchain node, the data owner initiates a TX _ ENC type transaction proposal, wherein a privacy field is a ciphertext, other non-privacy fields are plaintexts and comprise calculated order-preserving codes, and the path of the order-preserving codes on the tree and the version number of the current OPE tree are sent to the main node; if the data owner receives the update message, initiating a TX _ UPD type transaction proposal to the main node;

and 5: after receiving a transaction proposal sent by a data owner, the main node stores the transaction proposal in a local transaction pool;

step 6: the main node takes out a fixed number of transactions from the transaction pool and packs the transactions into blocks, and performs each transaction in the blocks in advance in series, and the method specifically comprises the following steps:

step 6-1: if the transaction type is TX _ ENC, the version number in the transaction is firstly obtained and compared with the version number of the current OPE tree, and if the version number is not equal, the transaction is directly stopped. If the two are equal, firstly traversing to a position which is supposed to be written in the OPE tree according to a path in the transaction, if a node exists at the position, stopping the transaction, and otherwise, writing a ciphertext-coding pair in the transaction to the tree;

step 6-2: if the transaction type is TX _ UPD, the OPE tree needs to be rebalanced, the rebalancing updates the codes on all trees, the OPE tree is initialized to be two boundary nodes, then all (different) ciphertexts are recoded in sequence, the codes are calculated according to the same calculation method, namely, the median values of two corresponding codes with the plaintext smaller than the current plaintext and the plaintext larger than the current plaintext in a continuous sequence are calculated, the values in the middle of all the nodes in sequence are compiled in sequence, then the median value in the left sequence is compiled, then the median value in the right sequence is compiled, and so on, a recursive process is performed, and finally a (temporary) balanced tree is generated. It should be noted that the data owner does not need to participate in rebalancing, which can be performed without involving any interaction, even if the block chain node does not know the plaintext value, since it only needs to know the order information of the tree nodes, which information is already available from the tree;

and 7: the master node carries out voting consensus on the blocks without conflict transactions among the slave nodes, the slave nodes carry out a verification method which is the same as that of the master node in advance for each transaction in the blocks, if the conflict transactions exist in the block chain and indicate that the master node is bad, the consensus voting is refused, and if the consensus is not continued;

and 8: the agreed upon block will be written to the local ledger for each node and the local OPE tree will also be updated.

When an authorized inquiry user needs to perform inquiry on a ciphertext, the embodiment provides a processing point inquiry and range inquiry method, and since a block chain node cannot know the ciphertext, the block chain node still needs to interact with the authorized inquiry user in the inquiry process. In order to improve the efficiency of range query, the method provides a query method based on cache.

The point query on the OPE tree specifically includes the following steps:

step 1: authorizing the inquiry user to encrypt the plaintext to be inquired and sending the ciphertext to the block chain node;

step 2: the block chain node sends the root node pair ciphertext of the OPE tree to the authorized inquiry user;

and step 3: and authorizing the inquiry user to decrypt the ciphertext of the root node, comparing the ciphertext with the plaintext value to be inquired, sending the comparison result to the block chain node, and sending the ciphertext of the left child or the right child of the root node by the block chain node according to the comparison result. Repeating the interaction process until the query value is found, and then putting the corresponding transaction into a result set and returning the result set to the authorized query user; if not, returning an empty result set to the authorized inquiry user;

for range query on an OPE tree, the method is similar to point query, an authorized query user initiates query on plaintext xl and xr of two range boundaries to a block chain node, the block chain node is queried by an interactive method of similar point query to obtain two tree nodes v1 and v2, so that the plaintext corresponding to v1 is the smallest in the range larger than xl, the plaintext corresponding to v2 is the largest in the range smaller than xr, and then the block chain node puts transactions corresponding to all nodes between v1 and v2 into a result set and returns the transactions to the authorized query user.

For the range query on the OPE tree based on the cache, the method is to maintain a cache table locally of an authorized query user, a plurality of plaintext-coding pairs are stored in the table, one plaintext-coding pair is recorded at regular intervals in sequence according to the number of records on the OPE tree, and the range query on the OPE tree based on the cache specifically comprises the following steps:

step 1: setting the plaintext of range query as [ xl, xr ], authorizing a query user to search two records e1 and e2 in a local cache table firstly, so that the plaintext of e1 meets the condition that the plaintext is smaller than the maximum of xl, and the plaintext of e2 meets the condition that the plaintext is larger than the minimum of xr, and then sending the code of e1 and the code of e2 to a block chain node;

step 2: after receiving the two codes, the block chain node directly performs range query on the OPE tree without interaction with an authorized query user, and then the corresponding transactions within the two code ranges are orderly put in a result set and returned to the authorized query user;

and step 3: and after the authorized inquiry user receives the result set, decrypting the ciphertext, traversing from two sides, and filtering the transactions which do not meet the inquiry range until the transactions which meet the conditions are traversed.

Example 2

The optimistic concurrent order-preserving coding method cr-opope for reducing coding conflicts proposed by the embodiment specifically includes the following steps:

step 1: initializing local ZOPE trees by all nodes in the block chain network;

step 2: for a data entry needing to be uploaded, a data owner encrypts a plaintext value x of a privacy field by using a key sk and sends a ciphertext c to a block link point to request coding;

and step 3: the node calculates order-preserving codes for the received ciphertext, and the coding process specifically comprises the following steps:

step 3-1: traversing the ZOPE tree by the block chain nodes and the data owner in an interactive mode;

step 3-2: if the node of the block chain in the traversing process encounters a full UDZ, the randomized coding calculation method is used to calculate the currently encoded code y, and then c and y are sent to the data owner together with all the nodes in UDZ to request the nodes to be sorted; after receiving the data, the data owner rearranges the nodes and initiates a TX _ SORT type transaction proposal, wherein a privacy field is a ciphertext, other non-privacy fields are plaintexts, and the ciphertext, the other non-privacy fields, the path on the ZOPE tree and the version number v _ tree of the current ZOPE tree are sent to the main node together;

step 3-3: if the node of the block chain in the traversing process finds that the ZOPE tree needs to be rebalanced, all nodes in UDZ structures in the tree are sent to a data owner to request sorting; the data owner receives the data and rearranges the nodes, and initiates a TX _ SORT type transaction proposal, and the transaction proposal is sent to the main node together with the ordered nodes and the current global UDZ version number v _ udz;

step 3-4: if the last traversal reaches an empty position, the block chain node calculates the currently encoded code y by using a randomized code calculation method, and initiates a transaction proposal of a TX _ ENC type, and the path of the transaction proposal on the tree and the version number v _ tree of the current ZOPE tree are sent to the main node together with c and y;

and 4, step 4: after receiving a transaction proposal sent by a data owner, the main node stores the transaction proposal in a local transaction pool;

and 5: the main node takes out a fixed number of transactions from the transaction pool and packs the transactions into blocks, and performs each transaction in the blocks in advance in series, and the method specifically comprises the following steps:

step 5-1: if the transaction type is TX _ SORT, the version number in the transaction is firstly obtained and compared with the version number of the current ZOPE tree, and if the version number is not equal, the transaction is directly stopped. If the transaction is equal, firstly traversing UDZ on the ZOPE tree according to the path in the transaction, then recombining the UDZ according to the rearranged nodes, and adding 1 to the global UDZ version number after recombination;

step 5-2: if the transaction type is TX _ UPD, the ZOPE tree needs to be rebalanced, UDZ version number in the transaction is firstly obtained and compared with the current global UDZ version number, and if the version number is not equal, the transaction is directly stopped. If equal, the entire ZOPE tree is updated, then the global tree version number is incremented by 1 and the global UDZ version number is incremented by 1. Since the order of nodes in the transaction is not UDZ known, the order of nodes in all UDZ is known from the rearranged results in the transaction, so the update process does not require any interaction with the data owner;

step 5-3: if the transaction type is TX _ ENC, firstly obtaining the version number in the transaction, comparing the version number with the current ZOPE tree version number, and if the version number is not equal, directly stopping the transaction. If the paths are equal, firstly traversing to the position which should be written on the ZOPE tree according to the path in the transaction and judging: if there is already a node at this location and it is not equal to the code to be inserted, create UDZ at this location, put the already existing node and the node to be inserted into this UDZ, then add 1 to the global UDZ version number; if there is already a node in this location that is not full UDZ and where there is no node with a code equal to the code to be inserted, then place the node to be inserted into this UDZ and then add 1 to the global UDZ version number; if the position is empty, directly placing the node to be inserted in the position; otherwise, the transaction is stopped;

step 6: the master node carries out voting consensus on the blocks without conflict transactions among the slave nodes, the slave nodes carry out a verification method which is the same as that of the master node in advance for each transaction in the blocks, if the conflict transactions exist in the block chain and indicate that the master node is bad, the consensus voting is refused, and if the consensus is not continued;

and 7: the identified blocks will be written to the local ledger of each node and the local ZOPE tree will also be updated.

Point query, range query and cache-based range query on the ZOPE tree are similar to the OPE tree, but the difference is that if a blockchain node encounters an UDZ structure in the query process, whether the blockchain node is full or not, the block chain node needs to be reorganized UDZ under the assistance of a data owner and then query is continued, namely when a blockchain node encounters UDZ, the data owner sends UDZ to the data owner, the data owner reorders the nodes in UDZ, sends the ordered results back to the blockchain node, and the block chain node receives the results, reorganizes UDZ and inserts the subtrees into corresponding positions on the ZOPE tree, and then query is continued.

Example 3

The embodiment is an encoding method for carrying out order-preserving encoding on the privacy field of the data set. FIG. 5 is a 4-piece data set, where Glucose is the privacy field. For convenience of description, it is assumed that the plaintext field size M is 8 and the code field size N is 16, and the current OPE tree is shown in fig. 6 (a). In the concurrent encoding stage, the data owner encodes the plaintext of the privacy fields of the 4 records, taking 6.3 as an example, firstly, the data owner encrypts 6.3 into x18ce and sends the x18ce to the blockchain node, the blockchain node sends the OPE tree root node to the data owner for decryption, the data owner compares the size relationship of the decrypted 4.8 and 6.3, requests the right child of the root node from the blockchain node, and loops the step, and the plaintext 6.3 calculates the code 14. At the same time, the plaintext 7.5 also calculates the code 14. In computing the 4.4 encoding, it is found that the tree needs to be updated. Then the code of 3.6 is calculated to yield 1. The data owner receives these results and initiates a transaction proposal tx₁，tx₂，tx₃And tx₄. The OPE tree after the encoding stage is shown in fig. 6(b), noting that none of these results are written to the tree, since no transaction has yet been executed.

In the conflict resolution stage, the main node pre-executes the 4 transactions, and the execution sequence is set to tx₁，tx₂，tx₃，tx₄。tx₁After being successfully executed, tx is executed again₂When it detects that shouldThe write location has a node already, as shown in FIG. 6(c), and therefore, tx is aborted₂。tx₃After updating the tree, the version number of the tree is updated to 1, tx is executed₄When it is detected that the version number of the tree has changed, as shown in FIG. 6(d), so that tx is aborted₄。

Example 4

The embodiment is a data set uploading method based on a ZOPE tree. Assuming that the current ZOPE tree is as shown in FIG. 8(a), the capacity of UDZ is 2. In the concurrent encoding stage, in the encoding process of the plaintext 5.6, the block chain nodes traverse to the nodes<x217c,12>And the code 11 is obtained using a randomized code computation method, while another code request for plaintext 5.8 traverses to the same position, and the code 9 is computed, as shown in fig. 8 (b). In the conflict resolution phase, the two nodes are placed into one UDZ, as shown in FIG. 8 (c). Later on, when encoding the plaintext 4.9, the nodes are traversed<x217c,24>And this full UDZ is detected, the 4.9 corresponding code 10 is first computed using a randomized code computation method, and then the three nodes are added<x613b,11>，<x78fa,9>And<x972e,10>request reordering to the data owner to obtain the correct code, i.e.<x613d,10>，<x78fa,11>And<x972e,9>at the time of execution tx₃Then, these three tree nodes are recombined into subtrees and inserted into the ZOPE tree, as shown in FIG. 8 (d).

Example 5

The embodiment is a cache-based range query method on an OPE tree. The size of the plaintext field is set to be 8, the size of the ciphertext field is set to be 16, the size of the interval of the local cache of the authorized inquiry user is set to be 2, namely, one cache entry is stored in every 2 transaction records according to the plaintext sequence. If 8 transaction records are stored on the block chain node, 3 entries are set as (4.2,4), (4.8,8) and (6.3,12) in the local cache of the authorized query user. At this time, the authorized inquiry user needs to inquire the transaction with the plaintext range of 5 to 6, firstly two items which just can cover the inquiry range are searched in the local cache, namely (4.8,8) and (6.3,12), then the codes 8 and 12 are sent to the blockchain node, the blockchain node searches the transaction with the code range of 4 to 12 in the local, no interaction is needed, then the result set is returned to the authorized inquiry user, the authorized inquiry user receives the result set and then decrypts the transaction locally, and the transaction which is not in the inquiry range is filtered.

Example 6 (Experimental validation)

The present embodiment implements a prototype of a block chain system, called miniBC, based on PBFT used in fabric0.6, then the present invention integrates a serial order-preserving coding scheme with miniBC, called OPEBC, then the present invention integrates a proposed opope scheme with miniBC, called OPEBC +, and finally the present invention integrates a proposed cr0 opope scheme with miniBC, called OPEBC + +, and compares the read-write performance of these four systems to verify the validity of the invention. In miniBC, all transactions initiated by the data owner can be committed with the average execution time set to be the same as OPEBC. The plaintext field size M is 65536, and in practical applications, the ciphertext field size N is usually set to be much larger than the plaintext field size for better security and performance, and the ciphertext field size is set to be 65536 in this embodiment³And experiments prove that basically no updating operation occurs. In the OPEBC of the serial scheme, only one thread encodes and only one value is encoded and committed before the next value is encoded, so the block size is always 1. In addition, only OPEBC + and OPEBC + + will have aborted transactions, and the transactions in both other systems can be fully committed.

Fig. 9 shows the write performance versus input data set size for three systems, with a fixed number of encoding threads of 16, a fixed block size of 600 (600 transactions per block), and a fixed UDZ capacity of 200 for OPEBC +. The extra encryption and decryption and interactive encoding inevitably results in a loss of performance to the system, so miniBC is the highest throughput of the four systems. However, the optimistic concurrent coding scheme proposed by the present invention still has much better performance than the serial coding, and the performance basically meets the requirements of most applications, and the performance of OPEBC + + is much better than that of OPEBC + because more transactions can be submitted. Furthermore, as the size of the input data set increases, the throughput of the OPEBC + and OPEBC + + increases and then slowly decreases after reaching a peak, because the height of the code tree also increases and thus the communication overhead increases.

Fig. 10 shows the write performance versus block size for three systems, where the number of encoding threads is fixed at 16, the input data set size is fixed at 8192, and for OPEBC +, the capacity of UDZ is fixed at 200. When the block size is smaller, consensus occurs more often, transaction execution is slower, collisions are more, and thus miniBC, OPEBC and OPEBC + throughput is lower. As the block size increases, the transaction execution speed also increases, and the throughput of all three systems increases and gradually stabilizes. Of course miniBC is the highest throughput since no coding is required, and OPEBC + + is always higher than OPEBC due to the high transaction commit rate.

Fig. 11 shows the write performance versus number of encoding threads for three systems, where the block size is fixed at 600, the input data set size is fixed at 8192, and for OPEBC +, the capacity of UDZ is fixed at 200. As the number of encoding threads increases, the encoding speed increases and the throughput of all three systems increases. However, when the number of threads is sufficiently large, thread switching causes a large amount of overhead, and thus throughput may be degraded. At the same time, miniBC performance is still best, and OPEBC + + is always better than OPEBC +.

Fig. 12 shows the performance of OPEBC + + with UDZ capacity, fixed at 16 coding thread number, 600 block size, and 8192 input data set size. When UDZ capacity is small, fewer conflicting transactions can be submitted, thus the throughput is lower and the number of aborted transactions is higher. As UDZ capacity increases, the system may submit more conflicting transactions and thus the throughput will be higher. However, the continuous increase of UDZ capacity has adverse effect on performance, and each time block link point reordering UDZ requires that ciphertext of all nodes in UDZ be decrypted first, and then ciphertext and plaintext be ordered, which results in a large overhead, and thus, as UDZ capacity increases, throughput decreases and the number of aborted transactions increases.

Fig. 13 shows the throughput and latency for concurrent Range Query (RQ) and cache-based Range Query (RQC) on OPEBC + and OPEBC + + respectively, and for two result sets (RS 1-2000, RS 2-4000).

The cache-based range query has much better performance than the uncached range query because no interaction is needed when traversing the coding tree, and the query performance of OPEBC + is better than OPEBC + + because the user query needs to be rearranged UDZ when covering a full UDZ in OPEBC + +.

Furthermore, as the number of threads increases, the throughput of both queries increases to a peak and then slowly decreases, while the latency remains increased because the overhead of thread switching increases as the number of threads increases. Finally, when the result set size is large, throughput may be reduced and latency may be increased.

Note that the query throughput is slightly worse than the write throughput because the height of the tree is always high during the query, while it is initially low when data is inserted. And, for range query, it needs to query two boundary values, and traverses the tree twice, while the insertion only needs to traverse once.

The protection of the present invention is not limited to the above embodiments. Variations and advantages that may occur to those skilled in the art may be incorporated into the invention without departing from the spirit and scope of the inventive concept, and the scope of the appended claims is intended to be protected.

Claims (6)

1. An optimistic concurrent order-preserving coding method for a block chain is characterized by specifically comprising the following steps of:

step 1: initializing local OPE trees by all nodes in the block chain network;

step 2: for a data entry needing to be uploaded, a data owner encrypts a plaintext value of a privacy field and sends a ciphertext to a block link point to request coding;

and step 3: the block chain link point calculates the order-preserving code of the received ciphertext and sends the coding result to the data owner; if the tree needs to be rebalanced in the encoding process, sending a rebalancing message to the data owner;

and 4, step 4: after receiving the coding result sent by the block chain node, the data owner initiates a TX _ ENC type transaction proposal, wherein a privacy field is a ciphertext, other non-privacy fields are plaintexts and comprise calculated order-preserving codes, the path of the transaction proposal on a tree and the version number of a current OPE tree are sent to a block chain main node together, and the main node is a block chain consensus algorithm; if the data owner receives the rebalancing message, initiating a TX _ UPD type transaction proposal to the host node;

and 5: after receiving a transaction proposal sent by a data owner, the main node stores the transaction proposal in a local transaction pool;

step 6: the main node takes out a fixed number of transactions from the transaction pool and packs the transactions into blocks, and each transaction in the blocks is executed in advance in series;

and 7: the master node carries out voting consensus on the blocks without conflict transactions among the slave nodes, the slave nodes carry out the same verification method as that of the master node in advance for each transaction in the blocks, if the conflict transactions exist in the block chain, the consensus voting is refused, and if the conflict transactions do not exist in the block chain, the consensus is continued;

and 8: the identified block is written into a local account book of each node, and a local OPE tree is also updated;

and step 9: authorizing a query user to perform point query on the ciphertext on the OPE tree;

step 10: authorizing the inquiry user to perform range inquiry on the ciphertext on the OPE tree;

step 11: and authorizing the inquiry user to perform cache-based range inquiry on the ciphertext on the OPE tree.

2. The order-preserving coding method according to claim 1, wherein the coding process in step 3 specifically comprises:

step 3-1: initializing an OPE tree by block chain link points, generating two boundary nodes of < Encrypt (-1, sk), -1>, < Encrypt (M, sk), N >, wherein sk is an encryption key, Encrypt is an encryption algorithm and can be symmetric encryption or asymmetric encryption, and returning a ciphertext through an incoming key and a plaintext to be encrypted;

step 3-2: the data owner encrypts a plaintext value x to be encoded by using a key sk and sends a ciphertext to a block chain node to request encoding;

step 3-3: the node calculates order-preserving codes for the received ciphertext, and the coding process specifically comprises the following steps:

step 3-3-1: if the root node is empty, directly calculating the median value of-1 and N as a code and sending the code to a data owner; otherwise, the block link node sends the ciphertext c' of the root node of the OPE tree to the data owner;

step 3-3-2: after receiving the ciphertext c ' of the root node, the data owner decrypts the ciphertext to obtain a plaintext x ' of the root node, compares the plaintext x ' with a value x to be coded, and sends a comparison result to the block chain node;

step 3-3-3: if x > x', the blockchain node sends the ciphertext of the right child node of the root node in the OPE tree to the data owner; if x < x', sending the ciphertext of the left child node; if x is x', directly returning the code of the root node to the data owner, otherwise, jumping to the step 3-4;

step 3-3-4: if there is no node in the OPE tree with a plaintext equal to x, the data owner and the blockchain node repeat the interactive process in steps 3-3-2 and 3-3-3 until the blockchain node traverses to an empty position in the OPE tree; two nodes v1 are set, v2 is two nodes which are arranged in order on the traversal path and enable corresponding plain texts x1 and x2 to meet the condition that x1 is not less than x and not more than x2, the code of v1 is y1, the code of v2 is y2, if the difference between y2 and y1 is not 1, the median value of y1 and y2 is calculated to be the code y of x, namely the code y of x is

Returning y to the data owner, otherwise, skipping to the step 3-3-5;

step 3-3-5: the difference between y2 and y1 is 1, which means that the coding field has insufficient space for coding, the whole OPE tree needs to be rebalanced to make the coding distribution more uniform, and thus the data owner needs to be sent a message of rebalancing.

3. The order-preserving coding method according to claim 1, wherein the step 6 specifically comprises:

step 6-1: if the transaction type is TX _ ENC, firstly obtaining the version number in the transaction, comparing the version number with the version number of the current OPE tree, and if the version number is not equal, directly stopping the transaction; if the two are equal, firstly traversing to a position which is supposed to be written in the OPE tree according to a path in the transaction, if a node exists at the position, stopping the transaction, and otherwise, writing a ciphertext-coding pair in the transaction to the tree;

step 6-2: if the transaction type is TX _ UPD, the OPE tree needs to be rebalanced, the rebalancing updates codes on all the trees, the OPE tree is initialized to be two boundary nodes, then all different ciphertexts are recoded in sequence, the codes are calculated according to the same calculation method, namely, the median values of two corresponding codes with the plaintext smaller than the current plaintext and the plaintext larger than the current plaintext in a continuous sequence are calculated, the values in the middle of all the nodes in sequence are firstly compiled, then the median value in the left sequence is compiled, then the median value in the right sequence is compiled, and so on, the process is a recursive process, the temporarily balanced tree is finally generated, and then the version number of the global tree is added with 1.

4. The order-preserving coding method according to claim 1, wherein the step 9 specifically comprises:

step 9-1: authorizing the inquiry user to encrypt the plaintext to be inquired and sending the ciphertext to the block chain node;

step 9-2: the block chain node sends the root node pair ciphertext of the OPE tree to the authorized inquiry user;

step 9-3: authorizing the inquiry user to decrypt the ciphertext of the root node, comparing the ciphertext with the plaintext value to be inquired, sending a comparison result to the block chain node, and sending the ciphertext of the left child or the right child of the root node by the block chain node according to the comparison result; repeating the interaction process until the query value is found, and then putting the corresponding transaction into a result set and returning the result set to the authorized query user; if not, an empty result set is returned to the authorized querying user.

5. The order preserving coding method as claimed in claim 1, wherein in the step 10, the query user initiates queries on plaintext xl and xr at two range boundaries to the blockchain node, the blockchain node is queried by an interactive method similar to the point query to obtain two tree nodes v1 and v2, so that plaintext corresponding to v1 is greater than the minimum of xl, plaintext corresponding to v2 is less than the maximum of xr, and then the blockchain node puts the transactions corresponding to all nodes between v1 and v2 into the result set and returns the result set to the query user.

6. The order-preserving coding method according to claim 1, wherein the step 11 specifically comprises:

step 11-1: setting the plaintext of range query as [ xl, xr ], authorizing a query user to search two records e1 and e2 in a local cache table firstly, so that the plaintext of e1 meets the condition that the plaintext is smaller than the maximum of xl, and the plaintext of e2 meets the condition that the plaintext is larger than the minimum of xr, and then sending the code of e1 and the code of e2 to a block chain node;

step 11-2: after receiving the two codes, the block chain node directly performs range query on the OPE tree without interaction with an authorized query user, and then the corresponding transactions within the two code ranges are orderly put in a result set and returned to the authorized query user;

step 11-3: and after the authorized inquiry user receives the result set, decrypting the ciphertext, traversing from two sides, and filtering the transactions which do not meet the inquiry range until the transactions which meet the conditions are traversed.

Images