CN109165224B - Indexing method for key words on block chain database - Google Patents
Indexing method for key words on block chain database Download PDFInfo
- Publication number
- CN109165224B CN109165224B CN201810971875.4A CN201810971875A CN109165224B CN 109165224 B CN109165224 B CN 109165224B CN 201810971875 A CN201810971875 A CN 201810971875A CN 109165224 B CN109165224 B CN 109165224B
- Authority
- CN
- China
- Prior art keywords
- transaction
- key
- hash
- node
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6227—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database where protection concerns the structure of data, e.g. records, types, queries
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- General Health & Medical Sciences (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- Accounting & Taxation (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- General Business, Economics & Management (AREA)
- Strategic Management (AREA)
- Finance (AREA)
- Databases & Information Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention provides an indexing method for key words on a block chain database, and relates to the technical field of block chain data query. Firstly, generating a transaction record by a common node according to original data with a keyword key input by a user; the storage node packs the transaction into a block; additionally writing the block data into a disk file; inquiring the transaction data according to the key value, and outputting an inquiry result; and the ordinary user verifies the credibility of the result. The invention directly indexes according to the data keywords to realize the queryability of the data; the transaction structure in the traditional block chain is expanded to a mode structure which can be stored and is similar to a traditional database, so that the applicability is improved; data authority is managed according to a digital signature technology, and data security is improved; whether the index is falsified is sensed according to the MerklerBTree self-sensing, and whether the transaction is falsified is sensed according to the transaction hash, so that the data can not be falsified; meanwhile, the data verification function of the lightweight node is realized, so that the query end can effectively detect the credibility of the data.
Description
Technical Field
The invention relates to the technical field of block chain data query, in particular to an indexing method aiming at key words on a block chain database.
Background
With the rise of a series of cryptocurrencies such as bitcoin and ethernet, the underlying blockchain technology has received more and more attention. The most central intention of bitcoin is to achieve decentralization, i.e. to enable digital currency transactions of two peer entities without the participation of a third party trust authority. However, there are many natural centers inevitable in the real world, such as banks offering loans, telecommunication operators offering telecommunication services, and the like. Although these central authorities may be considered peer entities that record their transactions with the user on the blockchain, such as using bitcoins to pay the fee, this is impractical because it does not facilitate the authorities managing the user data (including the user's credit rating, etc.). In fact, the existing central authorities manage their databases storing user-related information by themselves, but this model has many drawbacks: 1) different databases may store the same basic identity information of the user, resulting in high data redundancy; 2) different central authorities manage their own data respectively, which is not beneficial to the data sharing among the authorities; 3) each database is mostly managed by a single organization in a centralized manner, so that a user must trust the organization unconditionally, and the centralized problem exists; 4) the user cannot independently verify the correctness of the data, and if the data is maliciously tampered, the user and the mechanism cannot perceive the data.
The blockchain technology has the characteristics of decentralization, tamper resistance and public transparency, and provides possibility for solving the problems. For this reason, it is desirable to have an efficient consensus algorithm to improve the throughput of the system and an efficient query algorithm to enable data retrieval on the blockchain. Currently, there have been many studies on consensus algorithms, such as POW, POS, PBFT. However, research on query of the block chain is relatively few, most of the research is to synchronize transaction data to a traditional database by using a synchronization technology, and an index is established according to each data item, so that fast query is realized, but the method cannot guarantee that the index cannot be tampered, so that the property that the block chain cannot be tampered is lost.
Disclosure of Invention
The technical problem to be solved by the present invention is to provide an indexing method for keyword keys on a block chain database, to solve the problem of query of block chains, and to implement a non-falsifiable index.
In order to solve the technical problems, the technical scheme adopted by the invention is as follows:
an indexing method for key words on a blockchain database, comprising the steps of:
step 1: the common node generates a transaction record according to original data with a keyword key input by a user, and the method specifically comprises the following steps:
step 1-1: generating transaction default information which comprises block chain version number information and timestamp information of data creation time;
step 1-2: appointing a precursor PreHash of the transaction, if the keyword key appears for the first time, setting the precursor PreHash as Null, otherwise, the precursor is the hash value of the latest transaction corresponding to the keyword key;
step 1-3: generating data authority information and a data signature; assigning the scriptPubk as a next public key capable of modifying the key data, and signing the transaction data according to a private key of the scriptPubk by using an ECDSA algorithm;
step 2: the storage node packs the transaction into a block, and specifically includes:
step 2-1: verifying whether the transaction format meets the specification, and filtering the transaction which cannot be identified;
step 2-2: verifying whether the transaction signature is valid; retrieving a transaction index TxIndex of the PreHash value from a k-v database, retrieving a precursor transaction PreTx according to the TxIndex, and taking the appointed next public key information PreTx. ScriptPubk; performing signature verification according to a verify () function of the ECDSA algorithm, wherein if verify (pretx.script pubk, tx.script sig, Tx) ═ True, the signature is valid, otherwise, the signature is invalid, and discarding the transaction;
step 2-3: detecting the honeysuckle; reading a PreHash field of the transaction, if the PreHash field is not empty, searching a precursor transaction index TxIndex from a k-v database according to the PreHash value, if the index indicates that a subsequent transaction of the precursor transaction is not empty, indicating that the transaction to be verified is a double-flower transaction, and judging that the transaction is invalid; if the subsequent transaction is empty, assigning the subsequent transaction as the hash value of the transaction to be verified, wherein the transaction to be verified is valid; if the PreHash field of the transaction is empty, namely the creator of the transaction considers that the transaction which is the same as the transaction key does not exist before, whether the transaction with the key can be searched in the system or not is searched, if yes, the transaction is invalid, and if not, the transaction is valid;
step 2-4: after the transaction is verified to be valid, the transaction is inserted into a key-ordered transaction array vTx [ ] in the block body, and the MerklerBTree index is updated;
the rule for updating the MerkleRBTree is as follows: initializing a current node as Merkleroot, comparing a key of the node to be inserted with a key of the current node, namely NodeKey, if the key is less than NodeKey, inserting the key into a left subtree of the current node, updating the current node as a left child of the current node, otherwise, inserting the key into a right subtree, updating the current node as a right child of the current node, and sequentially recursing until the last layer of branch nodes; after the transaction is inserted, the tree is rotated to ensure black balance, and the Hash value of the branch node is recursively updated upwards to be Hash (rigthhash, key); the branch node is inserted into the node at the last layer according to the following 4 conditions:
case 1: if the branch node is empty, the situation only occurs when the Merkleroot is empty, then the transaction is subjected to Sha256 double-hash operation to obtain the hash value Hash (Tx) of the branch node, then a branch node is newly built, the key value of the branch node is defined to be key, the left hash value is the leaf node Hash value, and the right hash value is 0, which is similar to (Hash (Tx), 0 and key);
case 2: if the key value of the data to be inserted is smaller than the NodeKey value of the node, the data is inserted into the left side of the node; firstly, carrying out Sha256 double-hash operation on a transaction to obtain a hash value Hash (Tx) of the transaction, then newly building a red branch node, wherein a key word of the red branch node is a key to be inserted, the left Hash is Hash (Tx), and the right Hash is the left Hash of the original branch node, namely (Hash (Tx), Oldlefthash, key); note Hash (tx), Oldlefthash, key), then update parent node as (Hash, Oldrighthash, oldkey);
case 3: if the key value of the data to be inserted is larger than the NodeKey value of the node and the right hash of the node is 0, performing Sha256 double hash operation on the transaction to obtain the hash value Hash (Tx), and then updating the branch node to be (Oldlefthash, Hash (Tx), Oldkey);
case 4: if the key value of the data to be inserted is larger than the NodeKey value of the node and the right Hash of the node is not 0, firstly carrying out Sha256 double Hash operation on the transaction to obtain the Hash value Hash (Tx) of the data, then newly building a red branch node, wherein the key value of the branch node is the smaller of the key value of the data to be inserted and the key value of the right child of the original branch node, the left child is the smaller of the key value of the data to be inserted and the right child of the original branch node, and the right child is the larger of the key value; finally, updating the right hash of the father node of the node to be the hash of the newly-built branch node;
and step 3: additionally writing the block data into the disk file, specifically comprising:
step 3-1: serializing a transaction array vTx [ ] storing transaction original data in a block head and a block body, sequentially writing the serialized transaction array into a disk file blk000x, and returning the position nFile and BlockPos of the block in the disk;
step 3-2: generating metadata TxIndex (nFile, BlockPos, n) of each transaction, wherein nFile specifies the number of files, BlockPos specifies the offset of the block in the file, n specifies the subscript of the transaction corresponding to the ordered array, and storing the metadata information of each transaction into a k-v database in the format of k ═ hash (tx), and v ═ TxIndex;
step 3-3: storing the MerkleRBTree index entry in a k-v database, wherein k is Hash (righthash, key) and v is Hash (righthash, key);
and 4, step 4: inquiring the transaction according to the key and returning an inquiry result; starting to search the transaction from the latest block, and inquiring the previous block if the block is not searched;
the searching method in a single block is as follows: entering Merklerroot from the block head into MerklerBTree, comparing a target keyword key with a current node keyword Ckey from the Merklerroot, if the key is less than or equal to Ckey, searching a left child of the target keyword key, and pressing a right child and the node keyword into a verification path stack, otherwise, searching a right child of the target keyword key, and pressing the left child and the node keyword into the verification path stack, and sequentially executing the steps until leaf nodes are reached; if the leaf node key value key is equal to the query key, the query hits; according to the transaction hash value Hash (Tx) inquired at the leaf node, with Hash (Tx) as k, inquiring index information TxIndex corresponding to the transaction on a disk in a k-v database, and finally reading transaction information Tx in a disk file according to TxIndex; finally, returning the verification path stack and the original transaction information to the common user;
and 5: the ordinary user carries out credibility verification on the query result;
after receiving the verification path stack and the transaction information, the common user firstly carries out Sha256 double-hash operation on the transaction to obtain a transaction hash value Hash (Tx), then carries out Sha256 double-hash operation on the transaction hash value and a value popped out from the verification path stack, and continuously hashes the obtained hash value and the next value popped out from the stack until the stack is empty; and comparing whether the obtained hash value is equal to the Merkleroot value in the local block header, if so, the data is credible, otherwise, the data is not credible.
Adopt the produced beneficial effect of above-mentioned technical scheme to lie in: the index method for the key on the block chain database can directly index according to the data key instead of the existing block chain, so that the data queryability is realized; the transaction structure in the traditional block chain is expanded to a mode structure which can be stored and is similar to a traditional database, so that the applicability is improved; data authority is managed according to the digital signature technology, and data security is improved; whether the index is falsified can be self-perceived according to the MerklerBTree, and whether the transaction is falsified can be perceived according to the transaction hash, so that the non-tampering property of the data is ensured; meanwhile, the data verification function of the lightweight node is realized, so that the query end can effectively detect the credibility of the data.
Drawings
FIG. 1 is a diagram of a transaction architecture provided by an embodiment of the present invention;
FIG. 2 is a block diagram according to an embodiment of the present invention;
FIG. 3 is a structural diagram of a MerklerBTree according to an embodiment of the present invention;
fig. 4 is an exemplary diagram of a data insertion rule according to an embodiment of the present invention, where (a) is an empty node insertion result in case 1, (b) is a left side insertion result in case 2, (c) is a right side insertion result in case 3 when the right child is empty, and (d) is a right side insertion result in case 4 when the right child is not empty.
Detailed Description
The following detailed description of embodiments of the present invention is provided in connection with the accompanying drawings and examples. The following examples are intended to illustrate the invention but are not intended to limit the scope of the invention.
The block chain technical terms designed by the invention are explained as follows:
hash pointer: the hash pointer of one data item refers to that the content of the data item is subjected to hash operation to obtain a hash value with a fixed length, meanwhile, the hash value is taken as a key, the content of the data item is a value, the k-v pair is stored in a k-v database, and the key is the hash pointer of the data item;
trading: as shown in fig. 1, a Transaction structure diagram is shown, a Transaction is divided into two parts, namely a Transaction header (Transaction) and a Schema (Schema), and the Transaction header includes: version number (Version), parent transaction hash (PreHash), transaction time (nTime), transaction Next owner public Key (scriptPubk), signature (scriptSig) to prove this transaction valid; the schema part is similar to the table structure in the traditional database, and comprises key words and fields (fields);
block chains: the block chain is that the blocks are connected end to end according to the hash pointer, and each block cannot be changed once being formed; as shown in fig. 2, the block structure diagram is a block structure diagram, and the block is divided into a block head and a block body, where the block head includes: the version number, the previous block hash pointer (obtained by hashing the previous block header data), the timestamp when the block is formed, the Merkle root obtained by hashing the transaction from bottom to top in the block body, the random number used for workload certification and the target hash; all transaction records in the block are stored in the block body;
block chain database: the database is provided with a plurality of block chains, each block chain is equivalent to a table in the traditional database, all central mechanisms serve as storage nodes of data, all the storage nodes generate the block chains according to a consensus algorithm, and all the nodes (including users) store block header information and can retrieve records from the block header information and verify the correctness of the records;
MerkleRBTree: combining the Merkle tree with the red-black tree for indexing the transaction data in the block body; as shown in fig. 3, the MerkleRBTree structure diagram is a MerkleRBTree structure diagram, each node stores key information, data with a key value less than or equal to a key of the node is stored in a left sub-tree from a root node, and data with a key value greater than the key of the node is stored in a right sub-tree; the leaf nodes store hash pointers of the transaction data, and the non-leaf node values are obtained by hashing the left child node and the right child node in pairs.
Aiming at the defects that only transaction hash values can be inquired and a general data structure cannot be stored in the existing block chain database, the invention provides an indexing method aiming at key words on the block chain database, which comprises the following specific steps.
And step 1-1, generating default information.
And generating block chain version number information and timestamp information of data creation time.
And step 1-2, generating precursor information.
In the invention, for the data with the same key, only the newest data is considered to be effective all the time, and the old data is considered to be the precursor of the new data, so that a chain structure is generated for the data with the same key logically end to end. When writing data with key as key, designating the precursor of the data object, if there is no precursor, the precursor is Null.
And 1-3, generating data authority information and a data signature.
In the invention, the data written into the database can not be deleted, and the data modification is realized by rewriting a data item of the same key word. The authority information of the data refers to conditions which can be specified by a creator of the transaction data and need to be met when the data is modified. The ECDSA algorithm is introduced here, specifying the next public key that can be modified for that data item and assigning it to ScriptPubk. And finally, the data creator signs the transaction by using a private key of the data creator for later proving that the data creator has the right to modify the data.
And 2, packaging the transaction into a block.
And 2-1, verifying the correctness of the transaction.
The correctness verification of the transaction mainly verifies the format of the transaction and the data authority information. And the transaction which cannot be identified is removed by format verification, so that the system safety is ensured. The ECDSA algorithm is introduced into the authorization verification of the transaction, SicriptPubk in the transaction is a public key of a next authorization owner, and ScriptSig is digital signature information generated by a creator of the transaction. The authority verification is to verify whether the script sig of the transaction is matched with the script pubk of the predecessor transaction through a verify () function, if so, the creator of the transaction is proved to have a private key required by the predecessor transaction, the predecessor of the transaction can be modified, and if not, no related authority exists, and the transaction is invalid.
And 2-2, detecting the honeysuckle.
The data authority verification ensures that the transaction precursor can be modified only by owning the corresponding private key, but when the owner of the transaction transfers the authority to the next successor, the owner of the transaction can still transfer the authority of the transaction to other successors and modify the transaction, so that data inconsistency is caused, which is called double-flower. And after receiving the transaction record, the storage node reads a pre-hash field of the transaction, retrieves a precursor transaction index TxIndex from a k-v database according to the pre-hash value, and if the index indicates that a subsequent transaction of the precursor transaction is not empty, the transaction to be verified is a double-flower transaction, and the transaction is judged to be invalid. And if the subsequent transaction is empty, assigning the subsequent transaction as the hash value of the transaction to be verified, wherein the transaction to be verified is valid. If the pre-hash field of the transaction is empty, that is, the creator of the transaction considers that no transaction with the same key as the transaction key exists before, the double-flower verification at this time is to find whether the transaction with the key as the key can be retrieved in the system, if so, the transaction to be verified is invalid, and if not, the transaction is valid.
And 2-3, updating the block index.
After the transaction is verified to be valid, the original data Tx of the transaction is stored in an array vTx [ ] with ordered KEY, the Tx is subjected to double Sha256 hash operation to obtain a storage KEY (hash (Tx)) of the transaction, and the storage KEY is inserted into the MerkleRBTree. The merklrbtree is a combination of a red black tree and a Merkle tree, and each node is a k-v pair, where k is hash (val) and v is key. Inserting data from a root node, comparing a key of a node to be inserted with a key NodeKey of a Merkleroot node, inserting the key into a left subtree if the key is less than NodeKey, or inserting the key into a right subtree until a last layer of branch nodes. After the transaction is inserted, the tree is rotated to ensure black balance and the branch node Hash value is recursively updated up to Hash (1 efthash). The branch node is inserted into the node at the last layer according to the following 4 conditions:
case 1: if the branch node is empty (only appears when Merkleroot is empty), the transaction is subjected to Sha256 double hash operation to obtain a hash value hash (Tx), then a branch node is newly established, the key value of the branch node is defined to be key, the left hash is a leaf node hash value, the right hash is 0, the shape is (hash (Tx), 0 and key), and the insertion result is shown in FIG. 4 (a). This also means that a tree must not have its branch nodes empty, and the key value of the last level branch node must be the same as its left child key value, as long as it is not empty.
Case 2: if the key value of the data to be inserted is smaller than the NodeKey value of the node, the data should be inserted into the left side of the node, but as can be seen from the case 1, the left child of the node must not be empty and is a leaf node. Firstly, Sha256 double hash operation is carried out on a transaction to obtain a hash value Hash (Tx), then a red branch node is newly built, the key word of the branch node is a key to be inserted, the left Hash is Hash (Tx), and the right Hash is the left Hash of the original branch node, namely (Hash (Tx), Oldlefthash, key). Note that the Hash is Hash (tx), Oldlefthash, key), the update parent node is (Hash, Oldrighthash, Oldkey), and the insertion result is shown in fig. 4 (b).
Case 3: if the key value of the data to be inserted is greater than the node NodeKey value of the node, and the right hash of the node is 0, the transaction is subjected to Sha256 double hash operation to obtain the hash value Hash (Tx), then the branch nodes are updated to be (Oldlefthash, Hash (Tx), Oldkey), and the insertion result is shown in FIG. 4 (c).
Case 4: if the key value of the data to be inserted is larger than the NodeKey value of the node and the right hash of the node is not 0. Performing Sha256 double-hash operation on the transaction to obtain a hash value Hash (Tx) of the transaction, and then newly building a red branch node, wherein the key value of the branch node is the smaller of the key value of the data to be inserted and the key value of the right child of the original branch node, the left child is the smaller of the key value of the data to be inserted and the right child of the original branch node, and the right child is the larger; and finally, updating the right hash of the parent node of the node to be the hash of the newly-built branch node, wherein the insertion result is shown in fig. 4 (d).
And 3, additionally writing the block data into the disk file.
The data writing is carried out by taking a block as a unit, and when the transaction quantity in the block reaches a fixed threshold value, the data in the block is written into a disk. First, the transaction array vTx [ ] holding the transaction original data in the block header and the block body are sequentially written into the disk file blk000 x. The MerklerBTree built in the block body is stored in a k-v database. Simultaneously generating metadata of the Block index storage block for searching the block; the TxIndex is generated to hold the memory location of the transaction.
And 4, searching data.
And inquiring the transaction according to the key of the data, wherein all the blocks are connected end to end, and the latest block is searched according to the key. In a single block, Merklerroot at the head of the block enters MerklerTree, target key and current node key Ckey are compared from Merklerroot, if key is less than or equal to Ckey, the left child is searched, otherwise, the right child is searched, the steps are sequentially executed until a leaf node is searched, and the complexity of query time in the block of N nodes is O (lgN). If the transaction is in the block, the transaction hash value Hash (Tx) is finally inquired at the leaf node, the index information TxIndex of the transaction on the disk can be inquired in the k-v database by taking the Hash (Tx) as k, and the transaction information TxIndex is finally read in the disk file according to the TxIndex. If the transaction is not in the current block, it is looked up in its predecessor block in the same way.
The data in the invention can not be tampered in the following aspects: (1) in the process of obtaining the hash (Tx) from the key, the root node is searched downwards according to the MerklerBTree, because the tree is hashed by the leaf nodes when being generated, the leaf nodes can be finally searched certainly, if a certain branch node is not inquired in the process, the data of the last branch node is tampered or the data of the next node is lost; (2) in the process of obtaining Tx from hash (Tx), since the hash (Tx) is obtained by the hash operation of Tx, whether the transaction Tx is tampered can be detected according to the hash (Tx).
And 5, verifying the data.
The lightweight node only stores the block head information, and the storage node stores the block head and the block body. When the lightweight node queries data, the storage node returns a query result and a verification path. When the lightweight node receives data, the data are hashed two by two from the query result, and finally verification MerkLeroot is generated, and whether the query result is valid is verified by comparing whether the MerkLeroot is consistent with MerkLeroot in a locally stored block header.
The method for indexing block chain data according to the present invention is further described below according to an embodiment. Table 1 is the data that the user wants to store into the blockchain database.
Table 1 data to be stored in blockchain database
| Key | Name | Sex | Account |
| 1600005 | Bob | Male | 7000 |
| 1600004 | Alice | Female | 6000 |
| 1600007 | Tom | Male | 5000 |
| 1600006 | Jack | Male | 8000 |
In this embodiment, the indexing process of data in the MerkleRBTree is mainly demonstrated, so that control information such as transaction Prehash, PubKey, ScriptSig and the like is omitted. Assuming that the current block is empty, the four transactions in table 1 come in sequence, and the storage node packs the transactions into the block in sequence.
When the node receives the 1 st transaction, which is empty, according to the case 1 in step 2-3 of this embodiment, first, the transaction is subjected to a double Sha256 hash operation to obtain a hash value of 747d51d1007b4fb1be01aeb633e78f66 cbdeee 393aa 200e73627498b2551df (only the first 8 bits are shown for convenience of writing), then a branch node is generated, the transaction hash value is used as its left hash, the right hash is 0, the node key is 1600005, and a MerkleRBTree index entry is generated as shown in table 2, where k is hash (v).
TABLE 2 MerklerbTree index entry generated at transaction 1
When the node is inserted into the 2 nd transaction again, the MerkleRoot node key is 1600005, the transaction key to be inserted is 1600004, which is smaller than the root node key, and should be inserted into the left subtree, and because the MerkleRoot is the last level branch node on the left side (there is no table entry where k is 747d51d1 in the index entry table), the case is consistent with the case 2 in step 2-3, the operation step is: firstly, carrying out Sha256 double-hash operation on transaction 2 to obtain a transaction hash value dca 0e32, newly generating a branch node, wherein the left hash is dca 0e32, the right hash is father node left hash 747d51d1, and the keyword is 1600004; and then updating the father node upwards, wherein the left hash of the father node is the hash of the new component branch node, the father node k is correspondingly changed, and the MerklerBTree index entry after updating is shown in the table 3.
Table 3 inserts MerklerBTree index entry after 2 nd transaction
When a node is inserted into the 3 rd transaction, the MerkleRoot keyword is 1600005, the keyword of the node to be inserted is 1600007, and if the keyword is larger than the MerkleRoot keyword, the node to be inserted should be inserted into the right subtree of the node, and because the MerkleRoot is the last layer of branch node on the right side at the moment, the situation is consistent with the situation 3 in the step 2-3, the following steps are performed: and performing Sha256 double-hash operation on the transaction to obtain a transaction hash value b178577f, updating the Merklerroot right hash value b178577f, correspondingly changing k of the Merklerroot, and finally, enabling the MerklerRBTree index entry to be shown in Table 4.
Table 4 inserts the MerklerBTree index entry after the 3 rd transaction
Although there is no record of key 1600007 in the index table after inserting the transaction with key 1600007, at query time, 1600007 > 1600005, so its right hash b178577f is found, and b178577f is the transaction hash corresponding to key 1600007, i.e. the right hash of 1600005 records the record of key > 1600005 (1600007).
When the node inserts the 4 th transaction, the MerkleRoot key is 1600005, the key of the node to be inserted is 1600006, which is larger than the MerkleRoot key, the right subtree should be inserted, the MerkleRoot is the last layer of branch node on the right side, which is consistent with the case 4 in the step 2-3, and then the operation is: and carrying out hash operation on the transaction to obtain a transaction hash value of 228de82e, newly generating branch nodes, wherein the left hash of each node is 228de82e, the right hash of each node is b178577f, the key word of each node is 1600006, then updating the right hash of the parent node upwards to be the hash of the branch node, and finally updating the k value of the Merkleroot. The MerkleRBTree index entry after updating is shown in table 5.
Table 5 inserts the MerklerBTree index entry after the 4 th transaction
Assuming that the block size reaches a threshold (in practice thousands of transactions per block), it is ready for storage to disk. The Merklerroot value in the zone block header corresponds to d90f7e2e, the transaction array in the zone block is the transaction original data in the table 1, and the MerklerTree index entry is directly written into the k-v database. Firstly serializing transaction array data in a block header and a block body, sequentially adding the serialized transaction array data to a disk file blk0001.dat, returning a block with a disk offset of nFile 1 and a blockapos 8, then generating metadata TxIndex (nFile, blockapos, n, nextchah) of each transaction, wherein nFile designates the next file, blockapos designates the offset of the block in the file, n designates a subscript of the transaction corresponding to the ordered array, nextchah designates a transaction successor (for detecting that double flowers are omitted here), and finally storing the metadata information of each transaction in a k-v database, wherein the metadata is shown in table 6.
TABLE 6 metadata information for each transaction
| Txhash | nFile | | n |
| dcaa0e32 | |||
| 1 | 8 | 0 | |
| |
1 | 8 | 1 |
| |
1 | 8 | 2 |
| |
1 | 8 | 3 |
To facilitate the explanation of the problem, the hash values for each transaction are listed as follows:
TABLE 7 Hash values for various transactions
| TxHash | Key | Name | Sex | Account |
| dcaa0e32 | 1600004 | Alice | Female | 6000 |
| eaf1e7ec | 1600005 | Bob | Male | 7000 |
| 228de82e | 1600006 | Jack | Male | 8000 |
| b178577f | 1600007 | Tom | Male | 5000 |
When a transaction with a key of 160006 is queried, first, based on the MerkleRoot value d90f7e2e of the block header, MerkleRoot values (baa d30a, be149016, 1600005), 1600006 > 1600005 are retrieved from the k-v database, so k be149016 is retrieved from the k-v database, MerkleRBTree index values (228de82e, b178577f, 1600006), 1600006 be 1600006 are retrieved from the k-v database, so k be 228de82e is retrieved from the k-v database, transaction metadata (1, 8, 3) is obtained, and finally deserialization is performed in the disk file to obtain the transaction raw data (1600006, Jack, Male, 8000), while the path is verified to be the Hash value on the side that is not hit in the query, in the embodiment ((baa d a, 1600005 b), (368747, 178577f, baa) is returned to the Hash node baa, baa b 72, baa (baa, jack, Male, 8000), b178577f, 1600006), 1600005) is equal to the local MerkleRoot value to verify the authenticity of the query result.
Finally, it should be noted that: the above examples are only intended to illustrate the technical solution of the present invention, but not to limit it; although the present 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 solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; such modifications and substitutions do not depart from the spirit of the corresponding technical solutions and scope of the present invention as defined in the appended claims.
Claims (3)
1. An indexing method for key words on a block chain database, characterized in that: the method comprises the following steps:
step 1: the common node generates a transaction record according to original data with a keyword key input by a user, and the method specifically comprises the following steps:
step 1-1: generating transaction default information which comprises block chain version number information and timestamp information of data creation time;
step 1-2: appointing a precursor PreHash of the transaction, if the keyword key appears for the first time, setting the precursor PreHash as Null, otherwise, the precursor is the hash value of the latest transaction corresponding to the keyword key;
step 1-3: generating data authority information and a data signature; assigning the public key scriptPubk of the next owner of the transaction as the next public key capable of modifying the key data, and signing the transaction data according to the private key of the public key by using an ECDSA algorithm;
step 2: the storage node packs the transaction into a block, and specifically includes:
step 2-1: verifying whether the transaction format meets the specification, and filtering the transaction which cannot be identified;
step 2-2: verifying whether the transaction signature is valid; retrieving a transaction index TxIndex of the PreHash value from a key-value database, retrieving a precursor transaction PreTx according to the TxIndex, and taking the appointed next public key information PreTx. Performing signature verification according to a verify () function of the ECDSA algorithm, wherein if verify (pretx.script pubk, tx.script sig, Tx) ═ True, the signature is valid, otherwise, the signature is invalid, and discarding the transaction; the key-value database is called k-v database for short;
step 2-3: detecting the honeysuckle; reading a PreHash field of the transaction, if the PreHash field is not empty, searching a precursor transaction index TxIndex from a k-v database according to the PreHash value, if the index indicates that a subsequent transaction of the precursor transaction is not empty, indicating that the transaction to be verified is a double-flower transaction, and judging that the transaction is invalid; if the subsequent transaction is empty, assigning the subsequent transaction as the hash value of the transaction to be verified, wherein the transaction to be verified is valid; if the PreHash field of the transaction is empty, namely the creator of the transaction considers that the transaction which is the same as the transaction key does not exist before, whether the transaction with the key can be searched in the system or not is searched, if yes, the transaction is invalid, and if not, the transaction is valid;
step 2-4: after the transaction is verified to be valid, the transaction is inserted into a key-ordered transaction array vTx [ ] in the block body, and the MerklerBTree index is updated;
the rule for updating the MerkleRBTree is as follows: initializing a current node as Merkleroot, comparing a key of the node to be inserted with a key of the current node, namely NodeKey, inserting the key into a left subtree of the current node if the key is less than NodeKey, then updating the current node as a left child of the current node, otherwise inserting the key into a right subtree, then updating the current node as a right child of the current node, and sequentially recursing until the last layer of branch nodes; after the transaction is inserted, the tree is rotated to ensure black balance, and the Hash value of the branch node is recursively updated upwards to be Hash (rigthhash, key);
and step 3: additionally writing the block data into the disk file, specifically comprising:
step 3-1: serializing a transaction array vTx [ ] storing transaction original data in a block head and a block body, sequentially writing the serialized transaction array into a disk file blk000x, and returning the position nFile and BlockPos of the block in the disk;
step 3-2: generating metadata TxIndex (nFile, BlockPos, n) of each transaction, wherein nFile specifies the number of files, BlockPos specifies the offset of the block in the file, n specifies the subscript of the transaction corresponding to the ordered array, and storing the metadata information of each transaction into a k-v database in the format of k ═ hash (tx), and v ═ TxIndex;
step 3-3: storing the MerkleRBTree index entry in a k-v database, wherein k is Hash (righthash, key) and v is Hash (righthash, key);
and 4, step 4: inquiring the transaction according to the key and returning an inquiry result; starting to search the transaction from the latest block, and inquiring the previous block if the block is not searched;
and 5: the ordinary user carries out credibility verification on the query result;
after receiving the verification path stack and the transaction information, the common user firstly carries out Sha256 double-hash operation on the transaction to obtain a transaction hash value Hash (Tx), then carries out Sha256 double-hash operation on the transaction hash value and a value popped out from the verification path stack, and continuously hashes the obtained hash value and the next value popped out from the stack until the stack is empty; and comparing whether the obtained hash value is equal to the Merkleroot value in the local block header, if so, the data is credible, otherwise, the data is not credible.
2. The method of claim 1, wherein the key is indexed on a blockchain database by: in the step 2-4, the branch node is inserted into the last layer of branch node according to the following 4 conditions:
case 1: if the branch node is empty, the situation only occurs when the Merkleroot is empty, then the transaction is subjected to Sha256 double-hash operation to obtain the hash value Hash (Tx) of the branch node, then a branch node is newly built, the key value of the branch node is defined to be key, the left hash value is the leaf node Hash value, and the right hash value is 0, which is similar to (Hash (Tx), 0 and key);
case 2: if the key value of the data to be inserted is smaller than the NodeKey value of the node, the data is inserted into the left side of the node; firstly, carrying out Sha256 double-hash operation on a transaction to obtain a hash value Hash (Tx) of the transaction, then newly building a red branch node, wherein a key word of the red branch node is a key to be inserted, the left Hash is Hash (Tx), and the right Hash is the left Hash of the original branch node, namely (Hash (Tx), Oldlefthash, key); note Hash (tx), Oldlefthash, key), then update parent node as (Hash, Oldrighthash, oldkey);
case 3: if the key value of the data to be inserted is larger than the NodeKey value of the node and the right hash of the node is 0, performing Sha256 double hash operation on the transaction to obtain the hash value Hash (Tx), and then updating the branch node to be (Oldlefthash, Hash (Tx), Oldkey);
case 4: if the key value of the data to be inserted is larger than the NodeKey value of the node and the right Hash of the node is not 0, firstly carrying out Sha256 double Hash operation on the transaction to obtain the Hash value Hash (Tx) of the data, then newly building a red branch node, wherein the key value of the branch node is the smaller of the key value of the data to be inserted and the key value of the right child of the original branch node, the left child is the smaller of the key value of the data to be inserted and the right child of the original branch node, and the right child is the larger of the key value; and finally, updating the right hash of the father node of the node to be the hash of the newly-built branch node.
3. The method of claim 2, wherein the key is indexed on a blockchain database by: in step 4, the method for searching a single block includes: entering Merklerroot from the block head into MerklerBTree, comparing a target keyword key with a current node keyword Ckey from the Merklerroot, if the key is less than or equal to Ckey, searching a left child of the target keyword key, and pressing a right child and the node keyword into a verification path stack, otherwise, searching a right child of the target keyword key, and pressing the left child and the node keyword into the verification path stack, and sequentially executing the steps until leaf nodes are reached; if the leaf node key value key is equal to the query key, the query hits; according to the transaction hash value Hash (Tx) inquired at the leaf node, with Hash (Tx) as k, inquiring index information TxIndex corresponding to the transaction on a disk in a k-v database, and finally reading transaction information Tx in a disk file according to TxIndex; and finally, returning the verification path stack and the original transaction information to the ordinary user.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810971875.4A CN109165224B (en) | 2018-08-24 | 2018-08-24 | Indexing method for key words on block chain database |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810971875.4A CN109165224B (en) | 2018-08-24 | 2018-08-24 | Indexing method for key words on block chain database |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109165224A CN109165224A (en) | 2019-01-08 |
| CN109165224B true CN109165224B (en) | 2021-02-19 |
Family
ID=64896704
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810971875.4A Active CN109165224B (en) | 2018-08-24 | 2018-08-24 | Indexing method for key words on block chain database |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109165224B (en) |
Families Citing this family (52)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109766389B (en) * | 2019-01-09 | 2020-09-22 | 华东师范大学 | Block chain light client verification query method based on bitmap index |
| CN109885615B (en) * | 2019-01-24 | 2020-09-22 | 华东师范大学 | Index-based block chain light client-oriented range query verifiable query method |
| CN110059084B (en) * | 2019-01-31 | 2023-08-01 | 创新先进技术有限公司 | Data storage method, device and equipment |
| CN109918375B (en) * | 2019-02-26 | 2021-07-30 | 杭州云象网络技术有限公司 | Large text storage, indexing and retrieval method based on block chain and distributed storage |
| KR102322729B1 (en) * | 2019-03-04 | 2021-11-05 | 어드밴스드 뉴 테크놀로지스 씨오., 엘티디. | Blockchain World State Merkle Patricia Trie Subtree Update |
| CN111695885B (en) * | 2019-03-14 | 2023-08-29 | 中国科学技术大学 | Digital voucher block chain compression method based on reduced transaction input |
| CN110083635A (en) * | 2019-03-21 | 2019-08-02 | 深圳壹账通智能科技有限公司 | Data query and display methods and device based on block chain |
| CN110059089B (en) * | 2019-03-27 | 2021-01-22 | 深圳前海达闼云端智能科技有限公司 | Data synchronization method and device, storage medium and electronic equipment |
| CN110162662B (en) * | 2019-04-18 | 2023-02-28 | 创新先进技术有限公司 | Verification method, device and equipment for data records in block chain type account book |
| WO2020211569A1 (en) * | 2019-04-18 | 2020-10-22 | 创新先进技术有限公司 | Method for constructing index of data record |
| US10990705B2 (en) | 2019-04-18 | 2021-04-27 | Advanced New Technologies Co., Ltd. | Index creation for data records |
| CN110175840B (en) * | 2019-04-19 | 2021-08-03 | 华中科技大学 | Method, client, alliance chain and system for realizing light wallet mechanism in alliance chain |
| CN110263015A (en) * | 2019-05-07 | 2019-09-20 | 深圳壹账通智能科技有限公司 | Data source tracing method, device, equipment and readable storage medium storing program for executing based on block chain |
| CN110231979A (en) * | 2019-05-07 | 2019-09-13 | 深圳壹账通智能科技有限公司 | Transaction methods, device, equipment and storage medium based on block chain |
| SG11202001890UA (en) * | 2019-05-14 | 2020-03-30 | Alibaba Group Holding Ltd | Methods and devices for data traversal |
| CN110096522B (en) * | 2019-05-15 | 2023-07-28 | 西安电子科技大学 | Block chain data processing method, device and equipment supporting relational retrieval |
| CN110175188B (en) * | 2019-05-31 | 2021-05-11 | 杭州复杂美科技有限公司 | Block chain state data caching and querying method, equipment and storage medium |
| CN110209675A (en) * | 2019-06-18 | 2019-09-06 | 北京艾摩瑞策科技有限公司 | Credit data querying method and its device on block chain |
| US10789222B2 (en) | 2019-06-28 | 2020-09-29 | Alibaba Group Holding Limited | Blockchain-based hierarchical data storage |
| US11036720B2 (en) | 2019-06-28 | 2021-06-15 | Advanced New Technologies Co., Ltd. | Blockchain-based hierarchical data storage |
| CN110334154B (en) * | 2019-06-28 | 2020-07-21 | 阿里巴巴集团控股有限公司 | Block chain based hierarchical storage method and device and electronic equipment |
| CN110442577A (en) * | 2019-07-15 | 2019-11-12 | 杭州复杂美科技有限公司 | A kind of storage of status data, inquiry and management method, equipment and storage medium |
| CN110688377B (en) * | 2019-08-30 | 2020-07-17 | 阿里巴巴集团控股有限公司 | Method and device for updating state Merck tree |
| US10992459B2 (en) | 2019-08-30 | 2021-04-27 | Advanced New Technologies Co., Ltd. | Updating a state Merkle tree |
| CN110704428A (en) * | 2019-09-06 | 2020-01-17 | 深圳壹账通智能科技有限公司 | Data indexing method and device for block chain, computer equipment and storage medium |
| CN110837505B (en) * | 2019-11-06 | 2022-07-19 | 杭州复杂美科技有限公司 | State data storage method, state data synchronization device and storage medium |
| CN110874365B (en) * | 2019-11-20 | 2023-11-17 | 深圳市迅雷网络技术有限公司 | Information query method and related equipment thereof |
| CN110971393B (en) * | 2019-11-29 | 2020-11-06 | 中南大学 | Keyword query verification method and device based on block chain dynamic social outsourcing data |
| CN111080298B (en) * | 2019-12-26 | 2023-12-29 | 电子科技大学 | Block generation and transaction verification method suitable for energy block chain |
| US11461362B2 (en) * | 2020-01-29 | 2022-10-04 | EMC IP Holding Company LLC | Merkle super tree for synchronizing data buckets of unlimited size in object storage systems |
| US11711204B2 (en) * | 2020-01-29 | 2023-07-25 | EMC IP Holding Company LLC | Using sparse merkle trees for smart synchronization of S3 |
| US11455319B2 (en) * | 2020-01-29 | 2022-09-27 | EMC IP Holding Company LLC | Merkle tree forest for synchronizing data buckets of unlimited size in object storage systems |
| CN111488358A (en) * | 2020-04-08 | 2020-08-04 | 北京瑞策科技有限公司 | Data query method and device based on service data block chain |
| CN111680317B (en) * | 2020-04-27 | 2021-05-25 | 华东师范大学 | Block chain-oriented optimistic concurrency order-preserving coding method |
| CN111581215B (en) * | 2020-05-07 | 2020-12-15 | 钟士平 | Array tree data storage method, fast search method and readable storage medium |
| CN111596862B (en) * | 2020-05-20 | 2022-11-01 | 南京如般量子科技有限公司 | Independent optimization method and system for block chain historical transaction data |
| CN111639080B (en) * | 2020-06-01 | 2021-07-27 | 腾讯科技（深圳）有限公司 | Data processing method and device, node equipment and storage medium |
| CN111626680B (en) * | 2020-06-02 | 2023-07-25 | 重庆云创科技有限公司 | Transaction data chain type storage method and blockchain type storage method for reputation evaluation |
| CN111898164B (en) * | 2020-07-02 | 2024-03-29 | 武汉纺织大学 | Data integrity auditing method supporting label block chain storage and query |
| CN112487027B (en) * | 2020-12-02 | 2022-08-23 | 山东浪潮科学研究院有限公司 | Efficient data query implementation method based on block chain electronic transaction |
| CN112765155B (en) * | 2020-12-14 | 2022-05-31 | 杭州趣链科技有限公司 | Block chain-based key value storage method and device, terminal equipment and medium |
| CN112800065A (en) * | 2021-02-09 | 2021-05-14 | 北京工业大学 | Efficient data retrieval method based on improved block storage structure |
| CN112966001B (en) * | 2021-02-26 | 2023-08-04 | 东北大学 | BCTkPQ query method based on blockchain |
| CN113468571B (en) * | 2021-07-15 | 2023-05-12 | 湖北央中巨石信息技术有限公司 | Source tracing method based on block chain |
| CN113901131B (en) * | 2021-09-02 | 2024-06-07 | 北京邮电大学 | Index-based on-chain data query method and device |
| CN114153827B (en) * | 2021-10-11 | 2023-01-10 | 北京天德科技有限公司 | Transaction data removing method based on block chain system |
| CN114020737B (en) * | 2021-10-20 | 2024-06-18 | 大连理工江苏研究院有限公司 | Efficient and reliable indexing method for blockchain data |
| CN114519078B (en) * | 2022-04-19 | 2022-08-09 | 北京理工大学 | Cross-chain credible query method and system based on block chain |
| CN115037755B (en) * | 2022-04-27 | 2023-04-07 | 东北大学 | Block chain lightweight storage method based on data redistribution and dynamic node strategy |
| CN115052008B (en) * | 2022-05-26 | 2023-07-25 | 南京邮电大学 | Block chain data under-chain storage method based on cloud storage |
| CN115081031A (en) * | 2022-07-26 | 2022-09-20 | 成都云智数安科技有限公司 | Tamper-proof block chain data storage method and system |
| CN115619555B (en) * | 2022-08-08 | 2023-06-09 | 深圳市喜达科技有限公司 | Electronic commerce transaction system with data encryption transmission function |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106227833A (en) * | 2016-07-26 | 2016-12-14 | 宁圣金融信息服务（上海）有限公司 | Block chaining search engine method, system and device |
| CN107729371A (en) * | 2017-09-12 | 2018-02-23 | 深圳先进技术研究院 | The data directory and querying method of block chain, device, equipment and storage medium |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10691763B2 (en) * | 2016-11-11 | 2020-06-23 | International Business Machines Corporation | Trustable web searching verification in a blockchain |
-
2018
- 2018-08-24 CN CN201810971875.4A patent/CN109165224B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106227833A (en) * | 2016-07-26 | 2016-12-14 | 宁圣金融信息服务（上海）有限公司 | Block chaining search engine method, system and device |
| CN107729371A (en) * | 2017-09-12 | 2018-02-23 | 深圳先进技术研究院 | The data directory and querying method of block chain, device, equipment and storage medium |
Non-Patent Citations (2)
| Title |
|---|
| Formal Modeling and Verification of Blockchain System;Zhangbo DUAN等;《2018 Association for Computing Machinery》;20180110;全文 * |
| 区块链技术：架构及进展;邵奇峰等;《计算机学报》;20171231;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109165224A (en) | 2019-01-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109165224B (en) | Indexing method for key words on block chain database | |
| US20220414090A1 (en) | Blockchain data index method, blockchain data storage method and device | |
| US11283616B2 (en) | Method for index-based and integrity-assured search in a blockchain | |
| AU2020204053B2 (en) | Methods and apparatus for efficiently implementing a fast-copyable database | |
| US11520780B2 (en) | Distributed database systems and structures | |
| CN108039943B (en) | Verifiable encryption searching method | |
| Niaz et al. | Merkle hash tree based techniques for data integrity of outsourced data. | |
| CN102122285B (en) | Data cache system and data inquiry method | |
| US20210109917A1 (en) | System and Method for Processing a Database Query | |
| WO2020167887A1 (en) | Hybrid blockchains and streamchains using non-crypto hashes for securing audio-, video-, image-, and speech-based transactions and contracts | |
| US8316417B2 (en) | Method for dynamic secure management of an authenticated relational table in a database | |
| CN111209591B (en) | Storage structure sorted according to time and quick query method | |
| CN102890678A (en) | Gray-code-based distributed data layout method and query method | |
| US20240289350A1 (en) | Centralized database management system for database synchronization using same-size invertible bloom filters | |
| CN114461673A (en) | Block chain query optimization method based on-chain and off-chain cooperation | |
| Zhang et al. | Verifiable fuzzy keyword search supporting sensitive information hiding for data sharing in cloud-assisted e-healthcare systems | |
| Wei et al. | Integrity assurance for outsourced databases without DBMS modification | |
| US20240143569A1 (en) | Centralized database management system for database synchronization using invertible bloom filters | |
| US11847137B2 (en) | Database synchronization using resizable invertible bloom filters with database snapshots | |
| EP4394619A1 (en) | Data processing method and apparatus based on blockchain, and device and readable storage medium | |
| Qian | Improved authenticated data structures for blockchain synchronization | |
| Zegour | Scalable distributed compact trie hashing (CTH*) | |
| CN115081031A (en) | Tamper-proof block chain data storage method and system | |
| CN116662329A (en) | Index research for multi-dimensional data capable of inquiring and verifying | |
| WO2020223901A1 (en) | Data query method, and server |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |