A Blockchain Query Optimization Method Based on On-chain and Off-chain Collaboration

Abstract

A blockchain query optimization method based on on-chain and off-chain collaboration belongs to the field of blockchain technology. Aiming at the low query efficiency of the original blockchain system, the present invention adopts an on-chain and off-chain collaborative query method, and finally achieves the goal of optimizing the query performance of the original blockchain under the condition of not affecting the security performance and construction cost of the original blockchain and ensuring the reliability of off-chain queries. On the basis of using an off-chain database for additional backup to replace blockchain queries, the present invention provides an on-chain and off-chain collaborative query optimization model embedded in the original blockchain system, which not only improves the query speed and expands the query function through off-chain relational database queries, but also uses the characteristics of the blockchain to ensure the reliability of off-chain query results, thereby improving the overall query performance of the original blockchain.

Description

Technical Field

[0001] The present invention belongs to the technical field of blockchain. Background Art

[0002] SQL database: Relational database

[0003] NoSQL database: Non-relational database

[0004] Hash: Hash

[0005] Invalid transaction: A transaction in the blockchain where the data is illegal and does not update the state database

[0006] Valid transaction: A transaction in the blockchain where the data is verified as legal and updates the state database

[0007] Abnormal transaction: A transaction where the data content in the off-chain database has been illegally tampered with

[0008] Normal transaction: A transaction where the data content in the off-chain database has not been tampered with

[0009] Blockchain originated from the core technology of Bitcoin. Essentially, it is a decentralized distributed shared ledger responsible for recording all transaction information and states in the entire network. The data on the blockchain is stored in the form of blocks. Starting from the first generated block, sorted by time, each block points to the previous block through the Hash value of the previous block, and the blocks are connected in sequence to form a chain structure. Each block consists of two parts: a block header and a block body. The block header contains metadata information such as timestamps, the Hash value of the previous block, and the Hash value of the current block. The block body is composed of several transaction data. Blockchain technology integrates multiple basic technologies, including distributed consensus algorithms, hash operations, digital signatures, P2P networks, and smart contracts. Blockchain has the characteristics of decentralization, immutability, privacy, and auditability, and is suitable for solving problems such as high costs, low efficiency, and data tampering in traditional centralized institutions. Therefore, blockchain technology has attracted more and more attention in commercial or public welfare fields such as financial services, commodity traceability, medical education, and scientific publishing.

[0010] However, the current blockchain shows low query efficiency and lack of query functions in the scenario of querying transaction data, which makes it difficult to meet the actual needs of modern blockchain applications and has become a performance bottleneck restricting the development of blockchain technology. Because when the blockchain was designed, it emphasized data write consistency rather than query efficiency, which is mainly reflected in two aspects: the data structure and storage mode of the blockchain. In terms of the data structure, the chained structure of blockchain data storage is an inherent defect. When querying transaction data, it is necessary to sequentially traverse the entire blockchain, which results in slower query speed as the number of blocks increases. In addition, in terms of the storage mode, most existing blockchain systems use non-relational data storage modes such as key-value storage or file storage as the basic storage mode. Therefore, the ledger data and state data of the blockchain system are usually stored by the file system and non-relational databases. For example, Ethereum uses the open-source database LevelDB provided by Google to record state data and ledger data; the state database of Hyperledger Fabric can choose to use CouchDB or LevelDB, while the ledger data is stored in the file system. Compared with relational databases, NoSQL databases have the following four deficiencies in querying: 1) Weak read performance and high query cost; 2) Without transaction processing, the integrity of query operation results cannot be guaranteed; 3) Lack of data index structures for various queries, and the query efficiency is very low; 4) The data structure is relatively complex and it is difficult to support complex advanced queries.

[0011] In summary, how to improve the query efficiency of the blockchain and enable it to support advanced query functions is a problem worthy of solution.

[0012] For the query performance optimization of the current blockchain system, one type of solution is to modify the kernel of the original blockchain by adding semantics and building indexes, modifying or replacing the underlying database of the blockchain, etc., to improve the query performance of the blockchain system itself.

[0013] Solution of Existing Method 1

[0014] BlockchainDB is an implementation of the above type of solution. As Figure 1 shown, it adopts an index structure that combines a red-black tree and a Merkle tree in the block structure, and accelerates the query of the original blockchain based on Hash pointers. In this index, the leaf nodes are responsible for storing data, while the non-leaf nodes only store keywords and the total Hash value of the child nodes. Moreover, its left subtree stores data less than or equal to the node keyword, and the right subtree stores data greater than the node keyword. This solution ensures the immutability of the index while having good blockchain read and write performance.

[0015] The disadvantage of the existing Method 1 is that the increase in its construction cost may affect the security of the original blockchain. Secondly, Method 1 can only build indexes for single keywords, enabling multi-value queries and range queries for single fields in the blockchain, but it does not support complex queries like SQL databases.

[0016] The solution of the existing Method 2

[0017] Regarding the query performance optimization of the current blockchain system, another type of solution idea is not to modify the original blockchain kernel, but to transfer the transaction data on the blockchain to an off-chain database for query instead, thereby accelerating the query efficiency.

[0018] FabricSQL is an implementation in this type of solution. As Figure 2 shown, the solution is divided into two parts: 1) Through the block listening and conversion mechanism, the valid transactions on Hyperledger Fabric are converted and synchronized to be stored in the off-chain MySQL; 2) Each transaction data corresponds to a Hash value of an off-chain record, and this Hash value is obtained by salting and hashing with the previous transaction Hash value, which is used to verify the data integrity when accessing off-chain data, thereby ensuring the security of off-chain data.

[0019] Although Method 2 uses the method of verifying data integrity with salted Hash values to reduce the risk of off-chain data tampering, the Hash values used for verification are stored off-chain, and there is still a major risk that all the Hash values will be tampered with, resulting in the failure of the verification mechanism. In addition, Method 2 does not mention how to detect and recover in the case of off-chain data being tampered with. Over time, there will be a problem of reduced query accuracy. Summary of the Invention

[0020] Aiming at the low query efficiency of the original blockchain system, the present invention adopts an on-chain and off-chain collaborative query method, and finally achieves the goal of optimizing the query performance of the original blockchain under the conditions of not affecting the security performance and construction cost of the original blockchain and ensuring the reliability of off-chain queries.

[0021] On the basis of using an off-chain database for additional backup to replace blockchain queries, the present invention provides an on-chain and off-chain collaborative query optimization model embedded in the original blockchain system, which not only improves the query speed and expands the query function through off-chain relational database queries, but also uses the blockchain characteristics to ensure the reliability of off-chain query results, thereby enhancing the overall query performance of the original blockchain. The specific implementation method is as Figure 3 shown:

[0022] 1) Design an on-chain to off-chain data synchronization mechanism, which includes a data processing process: First, listen for the generation of new blocks on the transaction blockchain (i.e., the original blockchain) to determine the transaction data that can be written into the off-chain SQL database; then, through a set of data model conversion methods, the system converts the on-chain transaction data into relational data and stores it in the off-chain relational database to achieve fast query and complex query support for the original blockchain.

[0023] 2) Design a set of on-chain to off-chain verification and query processes, including: Hash on-chain process, data query process, and data detection process. For off-chain query requests, set up a verification blockchain that specifically stores the Hash values of the corresponding transaction data to ensure the high accuracy of off-chain query results; through an offline perception mechanism for abnormal transaction data, detect the tampered transaction data that cannot be discovered by query verification off-chain.

[0024] 3) By transforming the verification chain blocks and constructing a block index exclusive to the verification chain, accelerate the verification query process and achieve an improvement in the verification rate of transaction integrity.

[0025] 1. On-chain to off-chain data synchronization mechanism

[0026] The process of the on-chain to off-chain data synchronization mechanism is as Figure 4 shown below:

[0027] 1.1) Wait for the blockchain system to complete block packing and verification to generate a new block;

[0028] 1.2) After the new block is generated, add it to the blockchain file system stored locally on the node;

[0029] 1.3) After the new block is added, trigger the block listening module to read out the transaction data in the new block;

[0030] 1.4) If the blockchain system does not filter out invalid transactions, mark the invalid transactions in the transaction set according to the metadata identifier recorded in the block and do not participate in the data conversion process;

[0031] 1.5) Perform data model conversion processing on each valid transaction data in the new block to convert it into relational data;

[0032] 1.5.1) According to the types of data that need to be on-chain set by the user, create an off-chain database table with each type of data as a single field in the off-chain database table;

[0033] 1.5.2) By excluding the invalid transactions marked in step 1.4, screen out all the valid transactions in the transaction set of the new block;

[0034] 1.5.3) Sequentially extract the value of the historical data types uploaded by users in the transaction, and convert them into corresponding numerical or character data according to the data types of the off-chain fields;

[0035] 1.5.4) After all the current transaction data has been extracted, use SQL to insert all the extracted values as a new record into the off-chain SQL database;

[0036] 1.5.5) Process the valid transaction data of the next unprocessed data model conversion within the block until all are processed;

[0037] 1.6) Insert the converted relational data into the relational database in sequence, and the primary key ID increases by one in sequence.

[0038] 2. On-chain - off-chain verification query model

[0039] As Figure 5 shown, the block structure on the verification chain is divided into two parts: the block header and the block body.

[0040] The block header in the verification chain not only contains the original metadata information, including the block Hash value, the Hash value of the previous block, and the timestamp, but also additionally records: 1) The total Hash value of each column of the relational data of all transactions within the transaction chain block (the number of columns is equal to the number of total Hash values), which is used for offline detection of maliciously tampered data off-chain; 2) The primary key ID number of the first transaction Hash in the transaction Hash value array stored in the verification chain block, which is used as the keyword for constructing the block index.

[0041] The block body in the verification chain only records one transaction, and the transaction content contains a transaction Hash value array. This array stores the Hash values calculated after hashing the relational data of all valid transactions within the corresponding transaction chain block in sequence, and the length of each Hash value is the same.

[0042] 3. Off-chain transaction Hash value on-chain process

[0043] Figure 6 Shows the Hash on-chain process of the on-chain - off-chain data verification model:

[0044] 2.1) First, through the on-chain - off-chain data synchronization mechanism, after converting each valid transaction data in the new block into relational data and inserting it into the off-chain relational database in sequence, read out a new transaction sequentially;

[0045] 2.2) Calculate the Hash value of the off-chain transaction data through the MD5 algorithm;

[0046] 2.3) Store the Hash value in a Hash string array, which is responsible for recording the Hash values of the relational data of all valid transactions within the new block;

[0047] 2.4) If the number of transactions that have undergone Hash processing reaches the total number of valid transactions in the new block, it means that all the transaction Hash values in the new block in the SQL database have been processed completely. Then execute step 2.5. If not, return to execute step 2.1;

[0048] 2.5) A node on the verification chain initiates a transaction and submits it to the verification chain. The transaction content includes the Hash string array in step 2.3;

[0049] 2.6) The verification chain will package this transaction into a block through a packaging strategy and add Figure 5 the remaining block information in it to generate a new block and add it to the verification chain ledger.

[0050] 4. Verification query process

[0051] The on-chain - off-chain query verification process is as Figure 7 shown, and there are a total of 7 specific steps:

[0052] 3.1) The user side initiates a transaction data query request;

[0053] 3.2) Query data in the off-chain SQL database through SQL query;

[0054] 3.3) Obtain the query result;

[0055] 3.4) Locate each transaction involved in the query result and calculate the Hash value of each transaction through the MD5 algorithm;

[0056] 3.5) Search for the corresponding record's Hash value on the verification chain;

[0057] 3.6) Compare the calculated Hash value with the corresponding Hash value recorded on the verification chain;

[0058] 3.7) If the Hash values are the same, it proves that the query result is correct and reliable, and return the query result to the user; otherwise, it indicates that there are abnormal data with tampered transactions. Return a notification message of transaction data verification error, including the verification error status value 0, the ID of the abnormal transaction, and the block number, and then wait for the SQL database to repair the tampered abnormal transaction and re - execute the verification or return to query on the original transaction chain.

[0059] 5. Off-chain abnormal data offline perception mechanism

[0060] As Figure 8As shown in the figure, the off-chain abnormal data offline perception mechanism detects abnormal transactions maliciously tampered with in the off-chain database by extracting Hash verification codes bidirectionally in rows and columns. The extraction of the Hash verification code of the data in the off-chain relational database is divided into two parts: 1) Horizontally, calculate the Hash value of each transaction data and synthesize a Hash array; 2) Vertically, for all transactions within a block, perform a salted Hash operation on the attribute values in the same column and the primary key ID number of the first transaction in the block to generate a column total Hash value, which is stored in the block header of the verification chain block structure.

[0061] The off-chain abnormal data offline perception mechanism starts and detects tampered abnormal transactions regularly. The specific process of the off-chain data offline detection method is divided into the following steps:

[0062] 4.1) Select a field in the current SQL database table;

[0063] 4.2) Read each off-chain transaction data;

[0064] 4.2) For transactions belonging to the same transaction chain block, merge all the values of these transactions under this field, and calculate its Hash value as the column total Hash value of this field;

[0065] 4.3) After obtaining the column total Hash value of the current field, execute the calculation of the column total Hash value of the next field until all fields are executed;

[0066] 4.4) Compare the column total Hash value generated off-chain with the total Hash value of this column stored in the block header in sequence;

[0067] 4.5) If the Hash values are the same, return the status value 1 indicating that the transaction data is normal; if the Hash values are inconsistent, it means that there is tampered data in this column. At this time, the query requests related to this column will not be processable, and return the off-chain detection abnormal information, including the status value 0 of the off-chain detection exception, the field name of the abnormal column, and the block number. However, the query requests not related to this column can still be processed normally by the system.

[0068] 6. Verification chain block index

[0069] The block index structure of the verification chain is as Figure 9 shown. The verification chain uses the primary key ID number (hereinafter referred to as ID firstTX ) of the first transaction Hash recorded in the block header of each block as the keyword, and constructs a block index using the B+ tree structure. The pointer of the leaf node points to the storage location of the block. Since ID firstTX is unique and increases as the block increases, the order in which the leaf nodes are linked in sequence according to the keyword size is consistent with the chain order of the blockchain.

[0070] 7. Fast Verification Method for On-chain and Off-chain Query Data

[0071] The detailed process of the fast verification method for on-chain and off-chain data is as follows Figure 10 shown below

[0072] 5.1) Obtain the transaction data to be verified from the off-chain SQL database;

[0073] 5.2) Calculate the Hash of the transaction data to be verified as the Hash value to be verified;

[0074] 5.3) Quickly determine the block where the target transaction Hash value is located through the verification chain block index. If the ID number of the transaction to be verified is within the left-closed and right-open interval of the ID firstTX recorded in the current block and the ID firstTX recorded in the next block, then the target transaction Hash value is in the current target block; otherwise, search in the next block;

[0075] 5.4) Calculate the address offset according to the difference between the ID number of the transaction to be verified and the ID firstTX recorded in the target block and the fixed length of the Hash value;

[0076] 5.5) Determine the address of the Hash array in the transactions of the target block, and find the corresponding stored target transaction Hash value through the address offset;

[0077] 5.6) Compare the Hash value to be verified with the target transaction Hash value;

[0078] 5.7) If the Hash values are the same, return the status value 1 indicating verification passed; otherwise, return the status value 0 indicating verification error.

[0079] Through the on-chain and off-chain collaborative query optimization model, the present invention uses an off-chain relational database to improve the query speed and expand the query function, thereby enhancing the overall query performance of the original blockchain. Secondly, by designing the verification chain and the acceleration verification method, the reliability of the off-chain query results is strengthened. In addition, the on-chain and off-chain collaborative query optimization model can be externally embedded in the original blockchain system, improving the universality of the model. BRIEF DESCRIPTION OF THE DRAWINGS

[0080] Figure 1 This is the solution of Related Existing Method 1 of the present invention.

[0081] Figure 2 This is the solution of Related Existing Method 2 of the present invention.

[0082] Figure 3 This is the design solution of the on-chain and off-chain collaborative query optimization model of the present invention.

[0083] Figure 4 This is the on-chain / off-chain data synchronization flow chart of the present invention.

[0084] Figure 5 This is the verification chain block structure diagram of the present invention.

[0085] Figure 6 This is the Hash on-chain flow chart of the present invention.

[0086] Figure 7 This is the on-chain / off-chain query verification flow chart of the present invention.

[0087] Figure 8 This is the schematic diagram of two-way row-column extraction of Hash verification codes of the present invention.

[0088] Figure 9 This is the verification chain block index structure diagram of the present invention.

[0089] Figure 10 This is the on-chain / off-chain data quick verification flow chart of the present invention.

[0090] Figure 11 This is the deployment diagram of the multi-machine and multi-node system of the present invention. Detailed implementation manners

[0091] In Figure 11 the target system shown, the implementation of the transaction chain and the verification chain are both based on Hyperledger Fabric. The target system is deployed on fourteen servers. The transaction chain and the verification chain both adopt the raft consensus mechanism, each with three orderer nodes as the sorting cluster, and two peer organizations, each organization containing two peer nodes. The target system uses MySQL as the off-chain database. The specific configurations of the servers are shown in the following table.

[0092] Node Name Node Type Affiliated Organization Affiliated Blockchain Orderer0 Ordering Node Orderer Organization 1 Transaction Chain Orderer1 Ordering Node Orderer Organization 1 Transaction Chain Orderer2 Ordering Node Orderer Organization 1 Transaction Chain Orderer3 Ordering Node Orderer Organization 2 Verification Chain Orderer4 Ordering Node Orderer Organization 2 Verification Chain Orderer5 Ordering Node Orderer Organization 2 Verification Chain Peer0.org1 Peer Master Node Peer Organization 1 Transaction Chain Peer1.org1 Peer Slave Node Peer Organization 1 Transaction Chain Peer0.org2 Peer Master Node Peer Organization 2 Transaction Chain Peer1.org2 Peer Slave Node Peer Organization 2 Transaction Chain Peer0.org3 Peer Master Node Peer Organization 3 Verification Chain Peer1.org3 Peer Slave Node Peer Organization 3 Verification Chain Peer0.org4 Peer Master Node Peer Organization 4 Verification Chain Peer1.org4 Peer Slave Node Peer Organization 4 Verification Chain

[0093] After the system is deployed, the orderer0, orderer1, and orderer2 nodes of the transaction chain form an orderer organization 1. On the transaction chain channel, all transactions are sorted according to the set sorting conditions, and then packaged into new transaction chain blocks according to the block generation mechanism and broadcast to the primary nodes Peer0.org1 and Peer0.org2 of peer organization 1 and peer organization 2 for transaction information verification. Among them, invalid transactions are added with metadata records for exclusion. After the verification is completed, the primary nodes communicate with other nodes in the organization and append the block to the local transaction chain channel. At this time, the block listening module of the client triggers a data synchronization event, performs data model conversion processing on each valid transaction data in the new block, and inserts it into the off-chain MySQL database in the form of relational data in sequence. After the off-chain data synchronization is completed, the system calculates the Hash value of each off-chain transaction data in the new block through the MD5 algorithm, stores it in a Hash string array, and selects the Peer0.org3 node of server A to initiate a transaction containing this Hash string array and submit it to the verification chain. The Orderer organization 2 will package this transaction into a verification chain block separately on the verification chain channel and broadcast it to the primary nodes Peer0.org3 and Peer0.org4 of peer organization 3 and peer organization 4 for transaction information verification and communication with other nodes in the organization, and store the block on the local verification chain channel.

[0094] When the client sends a query transaction request, it performs an off-chain SQL query through the MySQL database, temporarily stores the query results in the system, calculates the Hash value of each transaction included in the query results through the MD5 algorithm, and then the system searches for the Hash value of the corresponding record on the verification chain and compares them. If the values are the same, the off-chain SQL query results will be returned to the user end; otherwise, the verification fails, and the system will call the original fabric SDK interface to perform a blockchain query. In addition, for all peer nodes (Peer0.org3, Peer0.org4, Peer1.org3, Peer1.org4) that have joined the verification chain channel, the system will execute an off-line perception mechanism for abnormal transaction data every 2 hours, record the off-chain tampered data found, and find the corresponding transaction on the transaction chain for resynchronization and update.

Claims

1. A method for optimizing blockchain queries based on on-chain and off-chain collaboration, characterized in that: 1) Design an on-chain and off-chain data synchronization mechanism, which includes a data processing process: First, listen for the generation of new blocks on the transaction blockchain, that is, the original blockchain, to determine the transaction data that can be written into the off-chain SQL database; Then, through a set of data model conversion methods, the system converts the on-chain transaction data into relational data and stores it in the off-chain relational database, realizing fast queries and complex query support for the original blockchain; 2) Design a set of on-chain and off-chain verification query processes, including: Hash on-chain process, data query process, data detection process; For off-chain query requests, set up a verification blockchain that specifically stores the Hash values of the corresponding transaction data; Through the offline perception mechanism of abnormal transaction data, detect the tampered transaction data that cannot be discovered by query verification off-chain; The offline perception mechanism detects abnormal transactions maliciously tampered with in the off-chain database by extracting Hash verification codes bidirectionally row by row; The extraction of the Hash verification code of the data in the off-chain relational database is divided into two parts: Horizontally, calculate the Hash value of each transaction data and synthesize a Hash array; Vertically, for all transactions within a block, perform a salted Hash operation on the attribute values in the same column and the primary key ID number of the first transaction in the block to generate a column total Hash value, which is stored in the block header of the verification chain block structure; The offline perception mechanism for off-chain abnormal data starts and detects tampered abnormal transactions regularly. The specific process of the off-chain data offline detection method is divided into the following steps: 4.1) Select a field in the current SQL database table; 4.2) Read each off-chain transaction data; 4.2) For transactions belonging to the same transaction chain block, merge all the values of these transactions under this field and calculate their Hash value as the column total Hash value of this field; 4.3) After obtaining the column total Hash value of the current field, perform the calculation of the column total Hash value of the next field until all fields are completed; 4.4) Compare the column total Hash value generated off-chain with the total Hash value of this column stored in the block header in sequence; 4.5) If the Hash values are the same, return the status value 1 indicating normal transaction data; If there is a Hash value inconsistency, it means that there is tampered data in this column. At this time, the query requests related to this column will not be processable, and return the abnormal transaction data information, including the status value 0 of the offline detection exception, the field name of the abnormal column, and the block number. For query requests that do not involve this column, the system can still be processed normally; 3) Accelerate the verification query process by transforming the verification chain block and constructing a block index exclusive to the verification chain.

2. The method for optimizing blockchain queries based on on-chain and off-chain collaboration according to claim 1, characterized in that: On-chain and off-chain data synchronization mechanism 1.1) Wait for the blockchain system to complete block packaging and verification to generate a new block; 1.2) After the new block is generated, add it to the blockchain file system stored locally on the node where it is located; 1.3) After the new block is added, trigger the block listening module to read out the transaction data in the new block; 1.4) If the blockchain system does not filter invalid transactions, mark the invalid transactions in the transaction set according to the metadata identifier recorded in the block and do not participate in the data conversion process; 1.5) Perform data model conversion processing on each valid transaction data in the new block and convert it into relational data; 1.5.1) Create an off-chain database table with each type of data as a single field of the off-chain database table according to the types of data to be chained set by the user; 1.5.2) Screen out all valid transactions in the transaction set of the new block by excluding the invalid transactions marked in step 1.4; 1.5.3) Extract the value of the historical data types uploaded by the user in the transaction in sequence and convert it into the corresponding numerical data or character data according to the data type of the off-chain field; 1.5.4) After all the current transaction data is extracted, use SQL to insert all the extracted values as a new record into the off-chain SQL database; 1.5.5) Process the valid transaction data in the next unprocessed block in the block until all are processed; 1.6) Insert the converted relational data into the relational database in sequence, and the primary key ID increases by one in sequence.

3. The method for optimizing blockchain query based on on-chain and off-chain collaboration according to claim 1, characterized in that: On-chain and off-chain verification query Verify that the block structure on the chain is divided into two parts: the block header and the block body; Verify that the block header in the chain not only contains the original metadata information, including the block Hash value, the Hash value of the previous block, and the timestamp, but also additionally records: 1) The total Hash value of each column of the relational data of all transactions in the transaction chain block, and the number of columns is equal to the number of total Hash values, which is used for off-line detection of maliciously tampered data off the chain; 2) The primary key ID number of the first transaction Hash in the transaction Hash value array stored in the verification chain block, which is used as the keyword for constructing the block index; Verify that the block body in the chain only records one transaction, and the transaction content contains a transaction Hash value array, in which the Hash values calculated after the relational data of all valid transactions in the corresponding transaction chain block are stored in sequence, and the length of each Hash value is the same.

4. The method for optimizing blockchain query based on on-chain and off-chain collaboration according to claim 1, characterized in that: Process of uploading off-chain transaction Hash value to the chain 2.1) First, through the on-chain and off-chain data synchronization mechanism, after converting each valid transaction data in the new block into relational data and inserting it into the off-chain relational database in sequence, read out a new transaction in sequence; 2.2) Calculate the Hash value of the off-chain transaction data through the MD5 algorithm; 2.3) Store the Hash value in a Hash string array, and this Hash string array is responsible for recording the Hash values of the relational data of all valid transactions in the new block; 2.4) If the number of transactions that have been hashed reaches the total number of valid transactions in the new block, then all the transaction hash values in the new block in the SQL database have been processed, and step 2.5 is executed. If not, return to step 2.1; 2.5) The node of the verification chain initiates a transaction and submits it to the verification chain. The transaction content includes the array of hash strings in step 2.3; 2.6) The verification chain will package this transaction into a block through the packaging strategy and add the remaining block information to generate a new block, which is added to the verification chain ledger.

5. The method for optimizing blockchain query based on on-chain and off-chain collaboration according to claim 1, characterized in that: Verification query process There are a total of 7 specific steps: 3.1) The user side initiates a transaction data query request; 3.2) Query data in the off-chain SQL database through SQL query; 3.3) Obtain the query result; 3.4) Find each transaction involved in the query result and calculate the hash value of each transaction through the MD5 algorithm; 3.5) Search for the corresponding hash value of the record on the verification chain; 3.6) Compare the calculated hash value with the corresponding hash value recorded on the verification chain; 3.7) If the hash values are the same, it proves that the query result is correct and reliable, and the query result is returned to the user; otherwise, it indicates that there is abnormal data in the transaction that has been tampered with, and a notification message of transaction data verification error is returned, including the status value 0 of the verification error, the ID of the abnormal transaction, and the block number. Then wait for the SQL database to repair the tampered abnormal transaction and re-execute the verification or return to the original transaction chain for query.

6. The method for optimizing blockchain query based on on-chain and off-chain collaboration according to claim 1, characterized in that: Verification chain block index The verification chain uses the primary key ID number of the hash of the first transaction recorded in the block header of each block, hereinafter referred to as ID firstTX ; Using this as the keyword, a block index is constructed using the B+ tree structure, and the pointer of the leaf node points to the location where the block is stored; because ID firstTX is unique and increases as the block increases, so the order in which the leaf nodes are linked in sequence according to the keyword size is consistent with the chain order of the blockchain.

7. The method for optimizing blockchain query based on on-chain and off-chain collaboration according to claim 1, characterized in that: Quick verification of on-chain and off-chain query data 5.1) Obtain the transaction data to be verified from the off-chain SQL database; 5.2) Calculate the hash of the transaction data to be verified as the hash value to be verified; 5.3) Quickly determine the block where the target transaction Hash value is located through the verified chain block index. If the ID number of the transaction to be verified is within the left-closed and right-open interval of the ID firstTX recorded in the current block and the ID firstTX recorded in the next block, then the target transaction Hash value is within the current target block; Otherwise, proceed to the next block for search; 5.4) Calculate the address offset based on the difference between the ID number of the transaction to be verified and the ID firstTX recorded in the target block and the fixed length of the Hash value; 5.5) Determine the address of the hash array in the transaction of the target block, and find the corresponding stored target transaction hash value through the address offset; 5.6) Compare the hash value to be verified with the target transaction hash value; 5.7) If the hash values are the same, return the status value 1 of verification passed; otherwise, return the status value 0 of verification error.

Images