Block chain verification query method and system based on improved Merkel tree and middleware
Through improved Merkel tree and middleware technology, real-time consistency verification and verifiable data query of on-chain data and verifiable data queries are achieved, solving the problem of slow data consistency verification and query speed in the existing technology, and improving the real-time and reliability of data queries.
Patent Information
- Application Number
- CN202510211731.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-02-25
- Publication Date
- 2025-06-27
AI Technical Summary
It is difficult for the prior art to realize high real-time on-chain off-chain data consistency verification and verifiable data query, especially in heterogeneous chains and complex application scenarios.
Using improved Merkle Tree and middleware technology, the local hash list is built and updated through service nodes and supervisory nodes, and the root hash value is compared and synchronized by message queue middleware to realize real-time consistency verification of on-chain data.
It realizes high real-time on-chain off-chain data consistency verification, improves data query speed, ensures data authenticity and immutability, and is suitable for complex and highly concurrency application scenarios.
Smart Images

Figure CN120216560A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of blockchain, and specifically relates to a method and system for blockchain verification and query based on an improved Merkle tree (BP-Merkel Tree) and middleware. Background Art
[0002] At present, the blockchain industrial chain continues to extend, gradually moving from virtual to real, and the trend of large-scale industry applications is obvious. Blockchain continues to empower multiple fields such as intelligent manufacturing, smart villages, finance, and government services. The upstream, midstream, and downstream of the industrial chain continue to expand, the technology R & D capabilities are improved, and the integration and development of blockchain with emerging technology industries such as edge computing, artificial intelligence, and the Internet of Things have given rise to a number of new tracks in the industrial chain such as software and hardware all-in-one machines, digital collections, the metaverse, and digital RMB.
[0003] With the development of blockchain technology, the number of heterogeneous chains will be increasing. Heterogeneous chains refer to blockchains of different types, architectures, and protocols, which need to be interconnected and communicate with each other to form a larger-scale blockchain network. These heterogeneous chains can be based on different development languages and architectures, or designed for different application scenarios and business requirements.
[0004] At the same time, the application requirements of blockchain in various industries have also been greatly improved, while large-scale data storage cannot be achieved on the chain. What is stored on the chain is mainly transaction orders, payment, and settlement information, and the specific data is stored off-chain. Therefore, ensuring the consistency of on-chain and off-chain data in the blockchain system has gradually become an issue that cannot be ignored. Due to the complexity of the distributed system, on-chain and off-chain consistency has become an important technical challenge.
[0005] On-chain and off-chain consistency refers to maintaining the synchronization and consistency of on-chain data and off-chain data in a blockchain or distributed system. It is an important feature of blockchain technology, aiming to solve the data inconsistency problem in distributed systems. On-chain data is the data that is written into blocks in the form of a ledger and stored by multiple parties after the nodes in the blockchain network reach an agreement through a consensus algorithm, and has the characteristics of decentralization and immutability. Off-chain data, on the other hand, is data manually entered, automatically collected by sensors, or generated by other systems, and is usually stored in an enterprise's internal database or other external systems. Since on-chain data and off-chain data may have different sources, generation methods, and data processing logics, there may be differences in status, value, or time between the two in actual applications.
[0006] Currently, the implementation of storing blockchain data in other databases in the academic community was first based on EtherQL of Ethereum. This method listens to the data uploaded to the blockchain, stores the data in MongoDB, and then provides a query interface. There are also methods that use MapReduce to synchronize blockchain data to a relational database. Or use ForkBase as an external database, which is a database that combines Merkle Tree and B+Tree. However, none of these existing methods have implemented a verifiable solution. There is also a VQL architecture in the prior art, which proposes the concept of database fingerprints and solves the data integrity mechanism and the on-chain and off-chain data collaboration mechanism to a certain extent. However, its synchronization depends on periodically pulling the data of the blockchain to build a micro-database, and for scenarios with high real-time requirements, the model based on this architecture is not applicable. Summary of the Invention
[0007] The present invention is made to solve the above problems, and aims to provide a method and system capable of realizing high-real-time on-chain and off-chain data consistency verification and verifiable data query. The present invention adopts the following technical solutions:
[0008] The present invention provides a blockchain verification and query method based on an improved Merkle tree and middleware. This method has the following technical features, which include the following steps: Step S1, the service node and the regulatory node respectively synchronize the latest data of the blockchain to their respective local databases; Step S2, the service node and the regulatory node respectively construct / update a local hash list based on the improved Merkle tree, which contains a root hash value with time sequence information, and the regulatory node obtains the root hash value from the service node through the message queue middleware; Step S3, when real-time consistency verification of on-chain and off-chain data is required, the regulatory node compares the root hash value of the service node with the root hash value of the regulatory node to judge its consistency. Among them, the improved Merkle tree includes a root node, non-leaf nodes, and leaf nodes. The leaf nodes represent data segments and store pointers to adjacent leaf nodes; the non-leaf nodes store hash values, which are calculated from the hash values of the non-leaf nodes' child nodes, and the non-leaf nodes also store pointers to each child node; the root node stores the root hash value, indicating the integrity of the data set composed of the data segments.
[0009] The blockchain verification and query method based on an improved Merkle tree and middleware provided by the present invention may further have the following technical features. Among them, step S1 includes the following sub-steps: Step S1-1, a blockchain event listener listens for block messages and sends the listened block messages to the synchronization service of the service node and the synchronization service of the regulatory node; Step S1-2, after the synchronization service of the service node and the synchronization service of the regulatory node receive the block messages, they write the latest data of the corresponding blocks into their local databases and perform on-chain verification on the data in their local databases during the writing process; Step S1-3, after the synchronization service of the service node and the synchronization service of the regulatory node complete data writing, they push the database change information to their consistency check service through their data processing middleware.
[0010] The blockchain verification and query method based on an improved Merkle tree and middleware provided by the present invention may further have the following technical features. Among them, the data processing middleware is Canal, and the message queue middleware is RocketMQ.
[0011] The blockchain verification and query method based on an improved Merkle tree and middleware provided by the present invention may further have the following technical features. Among them, step S2 includes the following sub-steps: Step S2-1, the improved Merkle tree generation service of the service node and the improved Merkle tree generation service of the regulatory node traverse the data sets in their local databases, calculate the hash values of the keys of each record in the data sets as the Merkle hash values of the leaf nodes of the corresponding improved Merkle tree; Step S2-2, starting from each leaf node, construct / update the non-leaf nodes layer by layer according to the structure of the B+ tree, calculate the Merkle hash value of the non-leaf node based on the hash values of all its child nodes, and recursively construct / update to the root node. The Merkle hash value of the root node is the root hash value of this improved Merkle tree; Step S2-3, the service node and the regulatory node each add the constructed / updated root hash value to their local hash lists for version recording or consistency verification.
[0012] The blockchain verification and query method based on an improved Merkle tree and middleware provided by the present invention may further have the following technical features. Among them, in step S2-2, the combination of the hash values of all child nodes of the non-leaf node is calculated as the Merkle hash value of the non-leaf node through the FNV-1a hash algorithm.
[0013] The blockchain verification and query method based on an improved Merkle tree and middleware provided by the present invention may further have the following technical features. Among them, step S2 further includes the following sub-steps: Step S2-4, the service node sends the root hash value with time sequence information to the message queue middleware; Step S2-5, the supervision node pulls the root hash value with time sequence information of the service node through the message queue middleware, and stores the pulled root hash value in the corresponding remote hash list locally in the supervision node according to the time sequence. In step S3, the supervision node compares the root hash value in the remote hash list with the root hash value in the local hash list of the supervision node to judge its consistency.
[0014] The blockchain verification and query method based on an improved Merkle tree and middleware provided by the present invention may further have the following technical features. Among them, step S3 includes the following sub-steps: Step S3-1, the query party requests the consistency verification result of a certain data table of the corresponding service node from the supervision node; Step S3-2, the supervision node compares each root hash value in the remote hash list and the local hash list of the supervision node one by one in descending order of time to detect whether there are consistent paired items; Step S3-3, when consistent paired items are detected, the supervision node sets the verification value of the data table at the corresponding timestamp to true and temporarily stores the verification value in its cache; Step S3-4, the supervision node deletes the root hash value in the remote hash list before the timestamp of the paired item; Step S3-5, the supervision node sends the consistency verification result to the query party.
[0015] The blockchain verification and query method based on an improved Merkle tree and middleware provided by the present invention may further have the following technical features. Among them, step S3 further includes the following sub-steps: Step S3-6, when the consistency verification result is passed, the query party applies to query the data of the service node; Step S3-7, the service node receives the query application and requests the corresponding public key from the supervision node; Step S3-8, the supervision node receives the public key request, and the private key signature service of the supervision node constructs a digital signature containing the public key and the private key; Step S3-9, the private key signature service of the supervision node sends the digital signature to the local database of the service node to update the signature field in the local database of the service node; Step S3-10, the service node verifies the signature of each piece of data with the public key; Step S3-11, when the public key verification result is passed, the service node provides the service to the query party.
[0016] The blockchain verification and query method based on an improved Merkle tree and middleware provided by the present invention may further have the following technical feature: in step S3-8, the private key signature service of the regulatory node determines whether corresponding public and private keys exist locally. If not, it generates public and private keys for the service node using PKCS8EncodedKey and stores them locally; if they exist, it reads the public and private keys into memory.
[0017] The present invention provides a blockchain verification and query system based on an improved Merkle tree and middleware. This system has the following technical features: it includes one or more service nodes, a regulatory node, and a message queue middleware. Among them, the service node and the regulatory node each have a local database. The service node and the regulatory node respectively synchronize the latest data of the blockchain to their respective local databases and respectively construct / update a local hash list based on the improved Merkle tree, which contains a root hash value with time sequence information. The regulatory node obtains the root hash value from the service node through the message queue middleware. When real-time consistency verification of on-chain and off-chain data is required, the regulatory node compares the root hash value of the service node with the root hash value of the regulatory node to determine its consistency. Among them, the improved Merkle tree includes a root node, non-leaf nodes, and leaf nodes. The leaf nodes represent data segments and store pointers to adjacent leaf nodes; the non-leaf nodes store hash values, which are calculated from the hash values of the child nodes of the non-leaf nodes. The non-leaf nodes also store pointers to each of the child nodes; the root node stores the root hash value, indicating the integrity of the data set composed of the data segments.
[0018] Functions and effects of the invention
[0019] According to the blockchain verification and query method and system based on an improved Merkle tree and middleware provided by the present invention, high-real-time on-chain and off-chain data consistency verification can be achieved, and it has good applicability, which is mainly reflected in the following two aspects:
[0020] First, by introducing a regulatory node and a BP-Merkle Tree, comparing the Root Hash of the regulatory node and the external service node can perform consistency verification. Moreover, based on the storage technology of the middleware, on-chain data and off-chain data can be synchronized to achieve high-speed query. Compared with the existing blockchain query speed, in the present invention, acceleration through the middleware can greatly improve the data query speed. And based on the relational database of MySQL, it can also expand the blockchain that does not support complex queries in the existing technology, which is of great significance for querying complex scenarios.
[0021] Second, the verifiable mechanism based on the BP-Merkle Tree and digital signature technology ensure the authenticity and reliability of the data of service nodes, and there will be no malicious tampering. In addition, the verification dimension is increased. The verification is divided into the verification of overall data addition and deletion and the verification of single data modification, which can effectively reduce the computing pressure of regulatory nodes.
[0022] In summary, the blockchain verification and query method and system based on the improved Merkle tree and middleware provided by the present invention can query the data on the blockchain while providing verifiable queries. Compared with some existing traditional methods, such as directly querying on the chain, it provides a faster query speed and richer query functions; while compared with existing accelerated query modes, such as VQL, it provides a dynamic query function in real-time scenarios. BRIEF DESCRIPTION OF THE DRAWINGS
[0023] Figure 1 is a schematic diagram of the architecture of the blockchain verification and query system based on the improved Merkle tree and middleware in an embodiment of the present invention;
[0024] Figure 2 is a schematic diagram for consistency verification in an embodiment of the present invention Figure 1 ;
[0025] Figure 3 is a schematic diagram for consistency verification in an embodiment of the present invention Figure 2 ;
[0026] Figure 4 is a schematic diagram of the data structure of the improved Merkle tree in an embodiment of the present invention;
[0027] Figure 5 is a flowchart of the blockchain verification and query method based on the improved Merkle tree and middleware in an embodiment of the present invention;
[0028] Figure 6 is a flowchart of step S1 in an embodiment of the present invention;
[0029] Figure 7 is a flowchart of step S2 in an embodiment of the present invention;
[0030] Figure 8 is a flowchart of step S3 in an embodiment of the present invention.
[0031] Reference Signs:
[0032] External service cluster 10; local database 11; synchronization service 12; data processing middleware 13; consistency verification service 14; trusted regulatory agency 20; local database 21; synchronization service replica 22; data processing middleware 23; consistency verification service 24; private key signature service 25; blockchain 30; block 31; blockchain event listener 40; blockchain query tool 50; message queue middleware 60. Detailed implementation
[0033] In order to make the technical means, creative features, achieved objectives and effects of the present invention easy to understand, the blockchain verification and query method and system based on the improved Merkle tree and middleware of the present invention will be specifically described below in conjunction with embodiments and drawings.
[0034] This embodiment provides a blockchain verification and query method and system based on an improved Merkle tree and middleware. Different from the traditional method of periodically pulling blockchain data, storing it and then calculating the verification value, the scenario faced by the method and system of this embodiment is the consistency verification of on-chain and off-chain data in a high-concurrency dynamic situation. Therefore, to address the challenges, BP-Merkle Tree is used as the core data structure for verification in this embodiment.
[0035] Figure 1 It is a schematic diagram of the architecture of the blockchain verification and query system based on the improved Merkle tree and middleware in this embodiment.
[0036] As Figure 1 shown, the system includes an external service cluster 10 ("synchronization cluster" in the figure), a trusted regulatory agency 20, a blockchain 30, a blockchain event listener 40, a blockchain query tool 50, and a message queue middleware 60 (RocketMQ).
[0037] Among them, the external service cluster 10 (including one or more external service nodes, hereinafter simply referred to as service nodes) includes one or more local databases 11 (only one is shown in the figure), a synchronization service 12, a data processing middleware 13 (Canal), and a consistency verification service 14. Among them, the data processing middleware 13 listens for events in the local database 11 and sends corresponding notifications to the consistency verification service 14.
[0038] The trusted regulatory agency 20 (regulatory node) includes a local database 21, a synchronization service replica 22, a data processing middleware 23 (Canal), a consistency verification service 24, and a private key signature service 25. Among them, the data processing middleware 23 also listens for events in the local database 21 of the regulatory node and sends corresponding notifications to the consistency verification service 24. The consistency verification service 24 can perform self-verification. The private key signature service 25 is used to provide private key signatures to the local database 11 of the synchronization cluster 10.
[0039] In this embodiment, both the local databases 11 and 21 are MySQL databases, which store multiple data tables.
[0040] Figure 2 is a schematic diagram of performing consistency check in this embodiment Figure 1 , Figure 3 is a schematic diagram of performing consistency check in this embodiment Figure 2 .
[0041] As Figure 2 and Figure 3 shown, the supervision node 20 also has a root node comparator, which realizes the consistency verification of on-chain and off-chain data by comparing the root hash value (Root Hash) list of the supervision node and the root hash value of the service node. The specific details will be further described in the following method steps.
[0042] The message queue middleware 60 (RocketMQ) is used to synchronously transmit the verification data of the consistency verification service 14 of the external service cluster 10 to the consistency verification service 24 of the supervision node 20.
[0043] As shown in the figure, the consistency verification services 14 and 24 respectively have an improved Merkle tree (BP Merkel Tree) generation service and a records generation service.
[0044] In this embodiment, in order to implement the real-time consistency verification function of on-chain and off-chain data, the supervision node 20 is introduced, and the BP Tree and the Merkle Tree are combined to form a new data structure BP-Merkle Tree, which has both the leaf node orderliness of the BPTree and the fast verification characteristics of the Merkle Tree.
[0045] Figure 4 is a schematic diagram of the data structure of BP-Merkle Tree in this embodiment.
[0046] As Figure 4 shown, the BP-Merkle Tree is a tree that stores Hash values, which includes a root node, one or more layers of non-leaf nodes, and multiple leaf nodes. Among them, the leaf node represents a data segment and stores the MerkleHash value of this data segment. In this embodiment, the data segment includes the key in the database, and each leaf node also stores a pointer to the adjacent leaf node; the non-leaf node is associated with multiple child nodes, and the Hash value stored in the non-leaf node is calculated from the concatenated Hash values of the child nodes. The non-leaf node also stores pointers to each child node; the root node stores the root hash value, which represents the integrity of the entire data set composed of multiple data segments, and also stores a pointer to its child node.
[0047] The blockchain 30 includes multiple blocks 31, and each block 31 stores corresponding on-chain data, a private key, and a symmetric key.
[0048] The blockchain event listener 40 is used to listen for events of each block 31 in the blockchain 30 and send corresponding event messages to the synchronization service 12 of the synchronization cluster 10 and the synchronization service replica 22 of the supervision node 20.
[0049] The blockchain query tool 50 is used for query verification by the querying party.
[0050] Among them, the data processing middleware 13 and 23 (Canal) can be configured in the following manner:
[0051] Download the installation package of Canal and decompress it. Authorize the Canal connection to the MySQL account to have the permission to act as a MySQL slave. If there is an existing account, you can directly grant it and modify the Canal configuration. Then, build a binlog record list for Canal, locally configure the relevant parameters of Canal, and set it to only receive the keys in the fields. Then, you can start the Canal listener to listen for the messages pushed by Canal. When a message is listened to, you can extract the message pushed by Canal and put it into the cache queue.
[0052] The method of this embodiment will be specifically described below in combination with the above architecture.
[0053] Figure 5 It is a flowchart of the blockchain verification and query method based on the Merkle tree and middleware in this embodiment.
[0054] As Figure 5 shown, the method includes the following steps:
[0055] Step S1, each service node and supervision node synchronize the latest data of the blockchain to their respective local databases.
[0056] Step S2, each service node and supervision node respectively construct / update the local hash list based on the improved Merkle tree. This local hash list contains the root hash value with time sequence information. The supervision node pulls the root hash value from the service node through the message queue middleware.
[0057] Step S3, when real-time consistency verification of on-chain and off-chain data is required, the supervision node compares the root hash value of the service node with the root hash value of the supervision node to determine its consistency.
[0058] The above steps will be described in detail below.
[0059] Step S1, each service node and supervision node synchronize the latest data of the blockchain to their respective local databases.
[0060] Figure 6 It is the flowchart of step S1 in this embodiment.
[0061] As Figure 6 shown, step S1 specifically includes the following sub-steps:
[0062] Step S1-1, the blockchain event listener monitors the block message, initializes the Producer locally, and sends the monitored block message to the synchronization service of the service node and the synchronization service of the supervision node.
[0063] Step S1-2, the synchronization services of the service node and the supervision node respectively initialize the PushConsumer. After receiving the block message, they write the latest data of the corresponding block into the local database, and synchronously verify the local data in the local database during the writing process.
[0064] Step S1-3, after the synchronization services of the service node and the supervision node complete the data writing, they push the database change information to their consistency verification service through their Canal.
[0065] Step S2, each service node and supervision node respectively constructs / updates the local hash list (Root Hash List) based on the improved Merkle tree (BP-MerkleTree). This local hash list contains the root hash value (Root Hash) with time series information of the service node. The supervision node pulls the root hash value from the service node through the message queue middleware (RocketMQ).
[0066] Figure 7 It is the flowchart of step S2 in this embodiment.
[0067] As Figure 7 shown, step S2 specifically includes the following sub-steps:
[0068] Step S2-1, the BP-Merkle Trees of the service node and the supervision node traverse the data sets in their local databases, calculate the hash value (Hash data) of the key of each record in the data set, and use it as the Merkle hash value of the leaf node of the BP-Merkle Tree.
[0069] Step S2-2: Starting from each leaf node, construct / update non-leaf nodes layer by layer according to the structure of the B+ tree. Calculate the combination of the Hash values of all child nodes of a non-leaf node as the MerkelHash of this non-leaf node through the FNV-1a hash algorithm, and recursively construct / update up to the root node. The Merkle Hash of the root node is the Root Hash of this tree.
[0070] In this embodiment, a BP-Merkle Tree generation algorithm executed in memory is adopted. Specifically, when constructing a BP-Merkle Tree, first extract key fields from the dataset (for example, it can be the primary key or other key fields that need to participate in verification), and insert the extracted key fields into a self-defined BP tree structure in memory according to the rules of the BP tree. During the insertion process, for each leaf node, first concatenate the key fields it contains in string form, and then use the SHA-256 algorithm to calculate the hash value of this leaf node as the verification value. After generating the hash values of all leaf nodes, according to the predetermined tree order or branching factor, concatenate the hash values of several adjacent leaf nodes in sequence, and then use SHA-256 to calculate the hash value of the parent node of these leaf nodes. This process is recursively performed from bottom to top until there is only one node left in the end, which is the root node. The hash value of the root node constitutes the root hash value of the entire tree, that is, the fingerprint of the entire dataset. Since the BP tree can maintain the order of leaf nodes when inserting and deleting data, even if the insertion order of the data is different, the finally constructed root hash value still remains consistent.
[0071] By using the BP-Merkle Tree constructed with keys, it can ensure the anti-tampering of data in the local database of service nodes at the level of addition and deletion.
[0072] Step S2-3: Both the service node and the regulatory node add the Root Hash constructed / updated each time to a local hash list in chronological order for version record or consistency verification.
[0073] Step S2-4: The service node sends the RootHash with chronological information to the message queue middleware (RocketMQ).
[0074] Step S2-5: The regulatory node pulls the Root Hash with chronological information of the service node through the PushConsumer of RocketMQ, and stores the pulled Root Hash in its local corresponding remote hash list (remoteHashs list) in chronological order.
[0075] Step S3, when real-time consistency verification of on-chain and off-chain data is required, the regulatory node compares the root hash value of the service node with that of the regulatory node to determine its consistency.
[0076] Figure 8 It is the flowchart of step S3 in this embodiment.
[0077] As Figure 8 shown, taking the scenario where the querying party conducts data query as an example, step S3 specifically includes the following sub-steps:
[0078] Step S3-1, the querying party requests the regulatory node for the consistency verification result of a certain data table of the corresponding service node.
[0079] Step S3-2, the regulatory node compares each Root Hash in the remote hash list and the local hash list of the regulatory node one by one in descending order of time to detect whether there are consistent paired items.
[0080] Step S3-3, when consistent paired items are detected in step S3-2, the regulatory node sets the verification value of the data table (SQL table) at the corresponding timestamp to True, and the verification values of the remaining timestamps to False, and temporarily stores the verification values in its cache for providing the consistency verification result externally.
[0081] Step S3-4, the regulatory node deletes the RootHash in its remote hash list that is earlier than the timestamp of this paired item.
[0082] Specifically, the regulatory node runs the verification algorithm through a timer. The verification algorithm includes null value judgment, reverse search for common hashes, pruning, and result recording. The null value judgment is specifically as follows: If both the local hash list and the remote hash list are empty, the data is considered consistent; if one is empty and the other is not, it is directly determined that the data is inconsistent. The reverse search for common hashes is specifically as follows: When both the local hash list and the remote hash list are not empty (that is, data exists on both sides), traverse the local hash list in reverse order (from the latest time to the oldest), and find the first hash value that exists in both the remote hash list and the local hash list, and regard it as the latest common consistent hash (newestConcistHash). The pruning is specifically as follows: Once the common consistent hash is found, delete all records earlier than (that is, the key value is less than) this common consistent hash, as well as the common consistent hash itself, from the local hash list and the remote hash list, so as to retain the latest part for subsequent comparison. The result recording is specifically as follows: Finally, update the search result (that is, whether the common consistent hash is found) to the global consistency status record.
[0083] Step S3-5: The regulatory node sends the consistency verification result to the querying party.
[0084] Step S3-6: When the consistency verification result is passed, the querying party applies to query the data of the service node.
[0085] Step S3-7: The service node receives the query application and requests the corresponding public key from the regulatory node.
[0086] Step S3-8: The regulatory node receives the public key request, and the private key signature service of the regulatory node constructs a digital signature.
[0087] Specifically, the private key signature service determines whether the corresponding public and private keys exist locally. If not, the regulatory node generates public and private keys for the service node using PKCS8EncodedKey and stores them locally. If they exist, they are read into memory.
[0088] Step S3-9: The private key signature service of the regulatory node sends the digital signature to the service node to update the signature field in the local database of the service node.
[0089] Step S3-10: The service node performs public key verification signatures on each piece of data applied for query by the querying party.
[0090] Step S3-11: When the public key verification result is passed, the service node provides (presents) the service to the querying party.
[0091] That is, the consistency verification of a single piece of data is performed through digital signature technology to ensure that a single piece of data stored in the local database of the service node is not tampered with.
[0092] Functions and effects of the embodiment
[0093] According to the blockchain verification and query method and system based on the improved Merkle tree and middleware provided in this embodiment, high-real-time on-chain and off-chain data consistency verification can be achieved, and it has good applicability, which is mainly reflected in the following aspects:
[0094] First, by introducing a regulatory node and a BP-Merkle Tree, comparing the Root Hash of the regulatory node and the external service node, consistency verification can be performed. And based on the storage technology of the middleware, on-chain data and off-chain data can be synchronized to achieve high-speed query. Compared with the existing blockchain query speed, in this embodiment, acceleration through the middleware can greatly improve the data query speed. And based on the relational database of MySQL, the blockchain that does not support complex queries in the existing technology can be extended, which is of great significance for complex scenario queries.
[0095] Second, based on the verifiable mechanism of BP-Merkle Tree and digital signature technology, it is ensured that the data of service nodes is true and reliable, and there will be no situation of being maliciously tampered with. Moreover, the verification dimension is increased. The verification is divided into the verification of overall data addition and deletion and the verification of single data modification, which can effectively reduce the computing pressure of regulatory nodes. BP-MerkleTree simultaneously has the leaf node orderliness of BP Tree and the fast verification characteristics of Merkle Tree. In the embodiment, a key is used to construct BP-Merkle Tree, and efficient and reliable verification can be realized based on the data structure of this tree.
[0096] In addition, in order to improve the generation rate of Hash values, a set of BP-MerkleTree generation algorithms executed in memory is designed in the embodiment, which can avoid the latency caused by storing BP Tree on disk in traditional databases such as MySQL, thereby further ensuring real-time on-chain and off-chain data verification.
[0097] In summary, the blockchain verification and query method and system based on the improved Merkle tree and middleware provided in this embodiment can query the data on the blockchain while providing verifiable queries. Compared with some existing traditional methods, such as directly querying on the chain, it provides a faster query speed and richer query functions; while compared with existing accelerated query modes, such as VQL, it provides a dynamic query function in real-time situations.
[0098] The above embodiments are only used to illustrate the specific implementation manners of the present invention, and the present invention is not limited to the description scope of the above embodiments. Those skilled in the art of this industry should understand that the present invention is not limited by the above embodiments. What is described in the above embodiments and the specification only explains the principle of the present invention. Without departing from the spirit and scope of the present invention, the present invention will have various changes and improvements, and these changes and improvements all fall within the scope of the present invention claimed. The scope of protection claimed by the present invention is defined by the appended claims and their equivalents.
Claims
1. A blockchain verification query method based on an improved Merkle tree and middleware, characterized in that: The following steps are involved: Step S1, the service node and the supervisory node synchronize the latest data of the blockchain to their respective local databases; Step S2, the service node and the supervisory node each construct / update a local hash list based on an improved Merkle tree, which includes a root hash value with timing information, and the supervisory node obtains the root hash value from the service node through a message queue middleware; Step S3: When real-time consistency verification of on-chain and off-chain data is required, the supervisory node compares the root hash value of the service node with the root hash value of the supervisory node to determine their consistency. The improved Merkle tree includes a root node, a non-leaf node and a leaf node. The leaf node represents a data fragment and stores pointers to adjacent leaf nodes; the non-leaf node stores a hash value, which is calculated from the hash values of the child nodes of the non-leaf node, and the non-leaf node also stores pointers to each of the child nodes; the root node stores the root hash value, which represents the integrity of the data set composed of the data fragments.
2. According to the blockchain verification query method based on the improved Merkle tree and middleware according to claim 1, Features: Wherein, step S1 includes the following sub-steps: Step S1-1, the blockchain event listener listens to the block message, and sends the block message to the synchronization service of the service node and the synchronization service of the supervisory node; Step S1-2, after receiving the block message, the synchronization service of the service node and the synchronization service of the supervisory node write the latest data of the corresponding block into their local databases, and perform on-chain verification on the data in their local databases during the writing process; Step S1-3: The synchronization service of the service node and the synchronization service of the supervisory node complete data writing, and push the database change information to the consistency verification service through their data processing middleware.
3. The blockchain verification query method based on the improved Merkle tree and middleware according to claim 2 is characterized in that: in, The data processing middleware is Canal, The message queue middleware is RocketMQ.
4. According to claim 2, the blockchain verification query method based on the improved Merkle tree and middleware, Features: Wherein, step S2 includes the following sub-steps: Step S2-1, the improved Merkle tree generation service of the service node and the improved Merkle tree generation service of the supervisory node traverse the data set in their local databases, calculate the hash value of the key of each record in the data set as the Merkle hash value of the leaf node of the corresponding improved Merkle tree; Step S2-2, starting from each leaf node, constructing / updating the non-leaf node layer by layer according to the structure of the B+ tree, calculating the Merkle hash value of the non-leaf node based on the hash values of all child nodes of the non-leaf node, and recursively constructing / updating to the root node, the Merkle hash value of the root node is the root hash value of the improved Merkle tree; Step S2-3: The service node and the supervisory node each add the constructed / updated root hash value to their local hash lists for version recording or consistency verification.
5. The blockchain verification query method based on the improved Merkle tree and middleware according to claim 4 is characterized in that: in, In step S2-2, the combination of hash values of all child nodes of the non-leaf node is calculated by the FNV-1a hash algorithm as the Merkle hash value of the non-leaf node.
6. The blockchain verification query method based on the improved Merkle tree and middleware according to claim 4 is characterized in that: in, Step S2 also includes the following sub-steps: Step S2-4, the service node sends the root hash value with timing information to the message queue middleware; Step S2-5, the supervisory node pulls the root hash value with timing information of the service node through the message queue middleware, and stores the pulled root hash value in the remote hash list corresponding to the supervisory node locally in time sequence, In step S3, the supervisory node compares the root hash value in the remote hash list with the root hash value in the local hash list of the supervisory node to determine their consistency.
7. The blockchain verification query method based on the improved Merkle tree and middleware according to claim 6, Features: Wherein, step S3 includes the following sub-steps: Step S3-1, the query direction requests the supervision node for the consistency check result of a data table of the corresponding service node; Step S3-2, the supervisory node compares the root hash values in the remote hash list and the local hash list of the supervisory node one by one in descending time order to detect whether there are consistent matching items; Step S3-3, when the matching item is detected, the supervisory node sets the check value of the data table corresponding to the timestamp to true, and temporarily stores the check value in its cache; Step S3-4, the supervisory node deletes the root hash value before the timestamp of the paired item in the remote hash list; Step S3-5: the supervision node sends the consistency check result to the querying party.
8. According to claim 7, the blockchain verification query method based on the improved Merkle tree and middleware, Features: Wherein, step S3 also includes the following sub-steps: Step S3-6, when the consistency check result is passed, the querying party applies to query the data of the service node; Step S3-7, the service node receives the query request and requests the corresponding public key from the supervision node; Step S3-8, the supervisory node receives the public key request, and the private key signature service of the supervisory node constructs a digital signature including the public key and the private key; Step S3-9, the private key signature service of the supervisory node sends the digital signature to the local database of the service node to update the signature field in the local database of the service node; Step S3-10, the service node performs public key verification signature on each piece of data; Step S3-11, when the public key verification result is passed, the service node provides the service to the querying party.
9. The blockchain verification query method based on the improved Merkle tree and middleware according to claim 8 is characterized in that: in, In step S3-8, the private key signature service of the regulatory node determines whether the corresponding public and private keys exist locally. If not, PKCS8EncodedKey is used to generate public and private keys for the service node and store them locally; if they exist, the public and private keys are read into the memory.
10. A blockchain verification query system based on an improved Merkle tree and middleware, characterized in that: include: One or more service nodes, supervisor nodes, and message queue middleware, The service node and the supervisory node each have a local database. The service node and the supervisory node synchronize the latest data of the blockchain to their respective local databases, and each construct / update a local hash list based on the improved Merkle tree, which contains a root hash value with timing information. The supervisory node obtains the root hash value from the service node through the message queue middleware. When real-time consistency verification of on-chain and off-chain data is required, the supervisory node compares the root hash value of the service node with the root hash value of the supervisory node to determine their consistency. The improved Merkle tree includes a root node, a non-leaf node and a leaf node. The leaf node represents a data fragment and stores pointers to adjacent leaf nodes; the non-leaf node stores a hash value, which is calculated from the hash values of the child nodes of the non-leaf node, and the non-leaf node also stores pointers to each of the child nodes; the root node stores the root hash value, which represents the integrity of the data set composed of the data fragments.
Citation Information
Cited By
Interconnection and intercommunication document editing system and method
CN120930606A