Block chain transaction verification method and device, storage medium and electronic equipment

Abstract

The invention discloses a block chain transaction verification method and device, a storage medium and electronic equipment. The method comprises the following steps: under the condition that a verification request triggered for transaction data associated with a light node is obtained, sending the verification request to a consensus node; obtaining a verification information set returned by the consensus node; and verifying the existence of the verification data on the Merkel tree by using the verification data, the Merkel root and the adjacent Hash path to obtain a verification result so as to determine that the transaction data effectively exists in the block chain, and the method can be applied to a block chain scene. According to the invention, the technical problem of low verification efficiency of block chain transaction is solved.

Description

Technical Field

[0001] This application relates to the field of computers, and more particularly, to a method, apparatus, storage medium, and electronic device for verifying blockchain transactions. Background Art

[0002] In the process of verifying blockchain transactions, the Merkle tree, as a common data structure, is widely used to verify the existence of transaction data. However, a significant drawback of this verification method is that it requires a Merkle tree-style verification of all underlying transaction data on the blockchain one by one. This one-by-one verification method is not only cumbersome but also very time-consuming when dealing with a large amount of data, resulting in a low efficiency of blockchain transaction verification. Therefore, there is a problem of low efficiency in verifying blockchain transactions.

[0003] For the above problems, no effective solution has been proposed yet. Summary of the Invention

[0004] Embodiments of this application provide a method, apparatus, storage medium, and electronic device for verifying blockchain transactions to at least solve the technical problem of low efficiency in verifying blockchain transactions.

[0005] According to one aspect of the embodiments of this application, a method for verifying blockchain transactions is provided, including: when a verification request for transaction data associated with a light node is obtained, sending the verification request to a consensus node, where the verification request is used to request verification of the existence of the transaction data in the blockchain, and the light node and the consensus node are associated with each other; obtaining a verification information set returned by the consensus node, where the verification information set includes verification data in the transaction data, a hash path adjacent to the verification data on the Merkle tree, and a Merkle root of the Merkle tree, the Merkle tree is composed of hash paths matched by each data in the transaction data, and the Merkle root is a hash value result obtained by combining operations of each data on the Merkle tree according to the matched hash path; using the verification data, the Merkle root, and the adjacent hash path to verify the existence of the verification data on the Merkle tree to obtain a verification result, so as to determine that the transaction data effectively exists in the blockchain.

[0006] According to another aspect of the embodiments of the present application, another method for verifying blockchain transactions is provided, including: a verification request sent by a node, where the verification request is a request triggered by transaction data associated with the light node and used to request verification of the existence of the transaction data in the blockchain, and the light node and the consensus node are associated with each other; in response to the verification request, obtaining a verification information set, where the verification information set includes verification data in the transaction data, a hash path adjacent to the verification data on the Merkle tree, and the Merkle root of the Merkle tree, the Merkle tree is composed of hash paths matched by each data in the transaction data, and the Merkle root is the hash value result obtained by operating on each data on the Merkle tree according to the matched hash path; sending the verification data to the light node, and the light node uses the verification data, the Merkle root, and the adjacent hash path to verify the existence of the verification data on the Merkle tree, obtaining a verification result, and the light node determines that the transaction data exists effectively in the blockchain.

[0007] According to another aspect of the embodiments of the present application, a verification device for blockchain transactions is further provided, including: a first sending unit, configured to send the verification request to a consensus node when a verification request triggered by transaction data associated with a light node is obtained, where the verification request is used to request verification of the existence of the transaction data in the blockchain, and the light node and the consensus node are associated with each other; a first obtaining unit, configured to obtain a verification information set returned by the consensus node, where the verification information set includes verification data in the transaction data, a hash path adjacent to the verification data on the Merkle tree, and the Merkle root of the Merkle tree, the Merkle tree is composed of hash paths matched by each data in the transaction data, and the Merkle root is the hash value result obtained by performing a combined operation on each data on the Merkle tree according to the matched hash path; a verification unit, configured to use the verification data, the Merkle root, and the adjacent hash path to verify the existence of the verification data on the Merkle tree, obtaining a verification result to determine that the transaction data exists effectively in the blockchain.

[0008] As an alternative solution, the above-mentioned first acquisition unit includes: a first acquisition module, configured to acquire the above-mentioned verification data, the above-mentioned Merkle root, and the above-mentioned hash path returned by the above-mentioned consensus node; wherein, when the hash path where the above-mentioned verification data matches on the above-mentioned Merkle tree includes a first hash value, the above-mentioned adjacent hash path includes a second hash value adjacent to the above-mentioned first hash value on the above-mentioned Merkle tree; when the hash path where the above-mentioned verification data matches on the above-mentioned Merkle tree includes the above-mentioned first hash value and a first combined hash value, the above-mentioned adjacent hash path includes the above-mentioned second hash value and a second combined hash value, the above-mentioned first combined hash value is a hash value obtained by performing a combined operation on the above-mentioned first hash value and the above-mentioned second hash value, and the above-mentioned second combined hash value is a hash value adjacent to the above-mentioned first combined hash value on the above-mentioned Merkle tree; when the hash path where the above-mentioned verification data matches on the above-mentioned Merkle tree includes the above-mentioned first hash value, the above-mentioned first combined hash value, and a first target hash value, the above-mentioned adjacent hash path includes the above-mentioned second hash value, the second combined hash value, and a second target hash value, the above-mentioned first target hash value is a hash value obtained by performing a combined operation on the above-mentioned first combined hash value and the above-mentioned second combined hash value, and the above-mentioned second target hash value is a hash value adjacent to the above-mentioned first target hash value on the above-mentioned Merkle tree.

[0009] As an alternative solution, the above-mentioned verification unit includes: a first operation module, configured to perform a combined operation on the above-mentioned first hash value and the above-mentioned second hash value to obtain a first operation result when the above-mentioned adjacent hash path includes the above-mentioned second hash value, wherein when the first operation result is consistent with the above-mentioned Merkle root, the above-mentioned verification result indicates that the above-mentioned verification data exists effectively on the above-mentioned Merkle tree; a second operation module, configured to perform a combined operation on the above-mentioned first combined hash value and the above-mentioned second combined hash value to obtain a second operation result when the above-mentioned adjacent hash path includes the above-mentioned second hash value and the above-mentioned second combined hash value, wherein when the second operation result is consistent with the above-mentioned Merkle root, the above-mentioned verification result indicates that the above-mentioned verification data exists effectively on the above-mentioned Merkle tree; a third operation module, configured to perform a combined operation on the above-mentioned first target hash value and the above-mentioned second target hash value to obtain a third operation result when the above-mentioned adjacent hash path includes the above-mentioned second hash value, the above-mentioned second combined hash value, and the second target hash value, wherein when the third operation result is consistent with the above-mentioned Merkle root, the above-mentioned verification result indicates that the above-mentioned verification data exists effectively on the above-mentioned Merkle tree.

[0010] As an alternative solution, the above-mentioned device further includes: a second acquisition unit, configured to acquire a first block height of the consensus node before sending the verification request to the consensus node, where the first block height is used to indicate the position number of the block currently held by the consensus node in the blockchain; a third acquisition unit, configured to acquire the verification request before sending the verification request to the consensus node when the first block height is greater than a second block height of the light node, where the second block height is used to indicate the position number of the block currently held by the light node in the blockchain.

[0011] As an alternative solution, the above-mentioned device further includes: a fourth acquisition unit, configured to acquire a first hash value set including N random values before sending the verification request to the consensus node, where the verification request carries the first hash value set, and N is a natural number; a fifth acquisition unit, configured to acquire a requested block height according to the second block height and the first block height before sending the verification request to the consensus node; where the verification request carries the requested block height, the verification data is the data in the transaction data that matches the first hash value set, the transaction data is the blockchain data corresponding to the target block, and the target block is the block determined by the consensus node from the blocks currently held by the consensus node and matching the requested block height.

[0012] As an alternative solution, the above-mentioned device further includes: a sixth acquisition unit, configured to acquire a second hash value set including K random values returned by the consensus node before acquiring the verification data returned by the consensus node, when the verification request is a subscription verification request and the consensus node currently holds a new block, where the subscription verification request is used to request verification when the consensus node currently holds the new block, the second hash value set is a hash value set obtained by the consensus node using the block hash value corresponding to the new block as a random number seed, and K is a natural number; a seventh acquisition unit, configured to acquire a third hash value set including P random values before acquiring the verification data returned by the consensus node, where P is a natural number; an operation unit, configured to perform an addition modulo operation on the second hash value set and the third hash value set to obtain a target hash value set before acquiring the verification data returned by the consensus node; where the verification request carries the target hash value set, and the verification data is the data in the transaction data that matches the target hash value set, and the transaction data is the blockchain data corresponding to the new block.

[0013] As an alternative solution, the above-mentioned first acquisition unit includes: a second acquisition module, configured to acquire the verification data of the first data volume, the Merkle root, and the hash path returned by the consensus node, where the ratio between the first data volume and the second data volume of the transaction data is greater than or equal to a preset ratio.

[0014] According to another aspect of the embodiments of the present application, there is also provided another verification device for blockchain transactions, including: an eighth acquisition unit, configured to acquire a verification request sent by a light node, where the verification request is a request triggered by the transaction data associated with the light node and used to request verification of the existence of the transaction data in the blockchain, and the light node and the consensus node are associated with each other; a ninth acquisition unit, configured to respond to the verification request and acquire a verification information set, where the verification information set includes the verification data in the transaction data, the hash path adjacent to the verification data on the Merkle tree, and the Merkle root of the Merkle tree, the Merkle tree is composed of the hash paths matched by each data in the transaction data, and the Merkle root is the hash value result obtained by operating the above-mentioned each data on the Merkle tree according to the above-mentioned matched hash path; a second sending unit, configured to send the verification data to the light node, and the light node uses the verification data, the Merkle root, and the adjacent hash path to verify the existence of the verification data on the Merkle tree, obtain a verification result, and the light node determines that the transaction data effectively exists in the blockchain.

[0015] As an alternative solution, the above-mentioned ninth acquisition unit includes: a third acquisition module, configured to use the block hash value corresponding to the new block as a random number seed and acquire a fourth hash value set including M random numerical values by using the random number seed when the verification request is a subscription verification request and the consensus node currently holds a new block, where the subscription verification request is used to request verification when the consensus node currently holds the new block, and M is a natural number; a fourth acquisition module, configured to determine the verification data matching the fourth hash value set from the transaction data.

[0016] According to yet another aspect of the embodiments of the present application, there is provided a computer program product or a computer program, where the computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the electronic device executes the verification method for blockchain transactions as described above.

[0017] According to another aspect of the embodiments of the present application, an electronic device is further provided, including a memory, a processor, and a computer program stored on the memory and executable on the processor. Among them, the above-mentioned processor executes the above-mentioned method for verifying blockchain transactions through the computer program.

[0018] In the embodiments of the present application, the different responsibilities of lightweight nodes (light nodes) and full-scale nodes (consensus nodes) in the blockchain are first utilized. Among them, lightweight nodes focus on storing incomplete blockchain data, while consensus nodes maintain complete blockchain data.

[0019] However, when a lightweight node needs to verify specific transaction data, the consensus node often returns the entire blockchain data, which undoubtedly increases the processing pressure on the lightweight node. And due to the need to process a large amount of data, the data processing process of the blockchain becomes slow and cumbersome, instead reducing the verification efficiency of the lightweight node, and there are certain technical defects.

[0020] Furthermore, in order to overcome the above technical defects in this embodiment, when the lightweight node sends a verification request to the consensus node, the consensus node no longer returns the entire blockchain data, but only returns the part of the data related to the verification, and these data include key information such as specific verification information, the hash path on the Merkle tree, and the Merkle root.

[0021] In this way, the lightweight node can use these streamlined data for efficient verification, avoiding the transmission and redundant checks of the entire blockchain, reducing the computational amount and time required for verifying blockchain transactions, and thus solving the technical problem of low verification efficiency of blockchain transactions. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The drawings described herein are used to provide a further understanding of the present application, and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application, and do not constitute an improper limitation of the present application. In the drawings:

[0023] Figure 1 is a schematic diagram of an application environment of an optional method for verifying blockchain transactions according to an embodiment of the present application;

[0024] Figure 2 is a schematic diagram of the flow of an optional method for verifying blockchain transactions according to an embodiment of the present application;

[0025] Figure 3 is a schematic diagram of an optional method for verifying blockchain transactions according to an embodiment of the present application;

[0026] Figure 4 is a schematic diagram of the flow of another optional method for verifying blockchain transactions according to an embodiment of the present application;

[0027] Figure 5 It is a schematic diagram of another alternative blockchain transaction verification method according to an embodiment of the present application;

[0028] Figure 6 It is a schematic diagram of another alternative blockchain transaction verification method according to an embodiment of the present application;

[0029] Figure 7 It is a schematic diagram of another alternative blockchain transaction verification method according to an embodiment of the present application;

[0030] Figure 8 It is a schematic diagram of another alternative blockchain transaction verification method according to an embodiment of the present application;

[0031] Figure 9 It is a schematic diagram of another alternative blockchain transaction verification method according to an embodiment of the present application;

[0032] Figure 10 It is a schematic diagram of another alternative blockchain transaction verification method according to an embodiment of the present application;

[0033] Figure 11 It is a schematic diagram of an alternative blockchain transaction verification device according to an embodiment of the present application;

[0034] Figure 12 It is a schematic diagram of an alternative blockchain transaction verification device according to an embodiment of the present application;

[0035] Figure 13 It is a schematic diagram of the structure of an alternative electronic device according to an embodiment of the present application. Detailed implementation manners

[0036] In order to enable those skilled in the art to better understand the solution of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0037] It should be noted that in the description, claims and the above-mentioned drawings of this application, the terms "first", "second", etc. are used to distinguish similar objects, and do not necessarily describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments of the present application described here can be implemented in an order other than those illustrated or described here. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or are inherent to these processes, methods, products or devices.

[0038] For ease of understanding, the following terms are explained:

[0039] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithms. Blockchain, in essence, is a decentralized database, a series of data blocks generated by using cryptographic methods. Each data block contains information about a batch of network transactions, which is used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include a blockchain underlying platform, a platform product service layer, and an application service layer.

[0040] The blockchain underlying platform can include processing modules such as user management, basic services, smart contracts, and operation detection. Among them, the user management module is responsible for the identity information management of all blockchain participants, including maintaining the generation of public and private keys (account management), key management, and the maintenance of the correspondence between the real identity of the user and the blockchain address (permission management). And under authorization, it supervises and audits the transaction situations of certain real identities, and provides the rule configuration for risk control (risk control audit); the basic service module is deployed on all blockchain node devices, used to verify the validity of business requests, and records the valid requests on the storage after consensus. For a new business request, the basic service first performs interface adaptation parsing and authentication processing (interface adaptation), then encrypts the business information through the consensus algorithm (consensus management), transmits it to the shared ledger intact and consistently after encryption (network communication), and performs record storage; the smart contract module is responsible for the registration and issuance of contracts, as well as contract triggering and contract execution. Developers can define contract logic through a certain programming language, publish it to the blockchain (contract registration), and trigger the execution by calling keys or other events according to the logic of the contract terms to complete the contract logic. At the same time, it also provides functions for contract upgrade and cancellation; the operation detection module is mainly responsible for the deployment, configuration modification, contract setting, cloud adaptation during the product release process, and the visual output of the real-time state during product operation, such as: alarming, detecting network conditions, detecting the health status of node devices, etc.

[0041] The platform product service layer provides the basic capabilities and implementation frameworks of typical applications. Developers can build on these basic capabilities and overlay the characteristics of the business to complete the blockchain implementation of the business logic. The application service layer provides application services based on the blockchain solution for business participants to use.

[0042] According to one aspect of the embodiments of the present application, a method for verifying blockchain transactions is provided. Optionally, as an alternative implementation, the above method for verifying blockchain transactions can be applied, but is not limited to, an environment such as Figure 1 shown. It may include, but is not limited to, a user device 102 and a server 112. The user device 102 may include, but is not limited to, a display 104, a processor 106, and a memory 108. The server 112 includes a database 114 and a processing engine 116.

[0043] The specific process may be as follows:

[0044] Step S102, the user device 102 obtains a verification request;

[0045] Step S104, the verification request is sent to the server 112 through the network 110;

[0046] Step S106, the server 112 responds to the verification request through the processing engine 116, and obtains a verification information set from the database 114. The verification information set includes the verification data in the transaction data, the adjacent hash path of the verification data on the Merkle tree, and the Merkle root of the Merkle tree;

[0047] Steps S108 - S112, the verification information set is sent to the user device 102 through the network 110. The user device 102 uses the processor 106 to verify the existence of the verification data on the Merkle tree by using the verification data, the Merkle root, and the adjacent hash path, obtains a verification result, and displays the verification result on the display 104. Further, the verification result is used to determine the effective existence of the transaction data in the blockchain, and the information indicating the effective existence of the above transaction data in the blockchain is stored in the memory 108.

[0048] Except Figure 1In addition to the examples shown, the above terminal device may be a terminal device configured with a target client, and may include, but is not limited to, at least one of the following: mobile phone (such as Android mobile phone, iOS mobile phone, etc.), laptop computer, tablet computer, palmtop computer, MID (Mobile Internet Devices), PAD, desktop computer, smart TV, etc. The target client may be a video client, instant messaging client, browser client, education client, etc. The above network may include, but is not limited to: wired network, wireless network, where the wired network includes: local area network, metropolitan area network and wide area network, and the wireless network includes: Bluetooth, WIFI and other networks that implement wireless communication. The above server may be a single server, or a server cluster composed of multiple servers, or a cloud server. The above is only an example, and this embodiment does not make any limitation thereto.

[0049] Optionally, as an alternative implementation, as Figure 2 shown, the verification method of blockchain transactions can be executed by an electronic device, and the electronic device may be, for example, a Figure 1 user device or server as shown, and the specific steps include:

[0050] S202, when a verification request is triggered for the transaction data associated with the light node, send the verification request to the consensus node, where the verification request is used to request verification of the existence of the transaction data in the blockchain. The light node is a lightweight node in the blockchain that is used to store non-complete blockchain data, and the consensus node is a full-weight node in the blockchain that is used to store complete blockchain data. The complete blockchain data includes transaction data, and the light node and the consensus node are mutually associated;

[0051] S204, obtain the verification information set returned by the consensus node, where the verification information set includes the verification data in the transaction data, the hash path adjacent to the verification data on the Merkle tree, and the Merkle root of the Merkle tree. The Merkle tree is composed of the hash paths matched by each data in the transaction data, and the Merkle root is the hash value result obtained by combining operations on each data on the Merkle tree according to the matched hash path;

[0052] S206, use the verification data, Merkle root, and adjacent hash path to verify the existence of the verification data on the Merkle tree, and obtain a verification result to determine the effective existence of the transaction data in the blockchain.

[0053] Optionally, in this embodiment, the above blockchain transaction verification method can be but is not limited to being applied in the blockchain scenario of a lightweight node (client) and a consensus node (server). The lightweight node (client) does not need to store the complete blockchain data, thus reducing its hardware and storage requirements. When the client needs to verify the associated transaction data, it sends a verification request to the server. The consensus node (server) stores the complete blockchain data and can quickly respond after receiving the request.

[0054] When the server responds to the request, it does not return the entire blockchain data. Instead, according to the verification requirements of the client, it precisely provides the relevant verification data. This data includes specific verification data in the transaction data, the hash path of this verification data on the Merkle tree, and the Merkle root of the Merkle tree. This way of returning data greatly reduces the data transmission volume and improves the verification speed.

[0055] After the client receives the verification data returned by the server, it uses this data, the Merkle root, and the hash path for verification. Since the verification process only involves specific data and paths, rather than all the data of the entire blockchain, the amount of computation and time required for verification are greatly reduced.

[0056] If the verification result shows that the verification data exists validly on the Merkle tree, the client can determine that the associated transaction data also exists validly in the blockchain. This deterministic verification result not only enhances the client's confidence in the authenticity of the transaction data but also avoids unnecessary repeated verification, further improving the verification efficiency.

[0057] Therefore, in this interaction scenario between the lightweight node (client) and the consensus node (server), the blockchain transaction verification method provided by the embodiment of the present application realizes a significant improvement in the blockchain transaction verification efficiency by optimizing data return, reducing the amount of computation, and providing a deterministic verification result.

[0058] Optionally, in this embodiment, a lightweight node can be a type of node in the blockchain (network). It does not store the complete blockchain data but only stores part of the blockchain data or only stores the block header information. The design of the lightweight node enables users with limited device resources (such as mobile phones, Internet of Things devices, etc.) to also participate in the blockchain network because the lightweight node does not need to download and store a large amount of blockchain data.

[0059] Optionally, in this embodiment, a consensus node can be a core component of the blockchain network, maintaining the security and consistency of the blockchain. The consensus node stores the complete blockchain data and can actively participate in the consensus mechanism of the blockchain network, responsible for verifying transactions, generating new blocks, and other tasks.

[0060] Optionally, in this embodiment, the light node and the consensus node are associated with each other. It can be understood that the light node and the consensus node are connected to each other in the blockchain network. The light node can request data or verification services from the consensus node, and the consensus node provides these services.

[0061] Optionally, in this embodiment, the transaction data associated with the light node can be the transaction data that the light node is concerned about or related to. For example, the light node may represent a user who wants to verify whether a certain transaction of his has been confirmed by the blockchain network.

[0062] Optionally, in this embodiment, the verification request is used to request verification of the existence of the transaction data in the blockchain. By sending the verification request, the light node can confirm whether the transaction data has been accepted and recorded by the blockchain network.

[0063] Optionally, in this embodiment, the Merkle Tree is a data structure composed of the hash paths matching each data in the transaction data and combined according to a specific structure (usually a binary tree), and is used to efficiently verify the integrity and content of a large amount of data.

[0064] Optionally, in this embodiment, the Merkle root is the hash value result obtained by combining the operations of each data on the Merkle tree according to the matching hash path, and can also be understood as the root node hash value of the Merkle tree, which is obtained by recursively combining and hashing the hash values in the tree.

[0065] Optionally, in this embodiment, in the Merkle tree, each node is obtained by hashing the hash values of its child nodes. The hash path can refer to the set of all intermediate hash values on the path from a certain leaf node (i.e., the hash value of the transaction data) to the Merkle Root along the tree structure. These intermediate hash values are generated by successive hashing operations when constructing the Merkle tree.

[0066] Since the complete data in the blockchain may be very large, light nodes usually do not store all the data, but rely on consensus nodes to provide necessary data verification services. When a light node needs to verify whether a certain transaction data exists in the blockchain, it can request the verification information set of the transaction data from the consensus node, which includes the hash path of this transaction data on the Merkle tree.

[0067] Using this hash path, a lightweight node can perform quick verification locally without having to download the entire blockchain data. The lightweight node will start from the hash value of the transaction data according to the hash path and calculate the intermediate hash values step by step upward until the Merkle root is calculated. If the calculated Merkle root is the same as the Merkle root provided by the consensus node, then the lightweight node can confirm that the transaction data indeed exists in the blockchain.

[0068] The generation of the hash path is completed when constructing the Merkle tree. A Merkle tree is a full binary tree. The leaf nodes of the Merkle tree are the hash values of the transaction data, and the non-leaf nodes are obtained by performing a hash operation on their child nodes. When constructing the Merkle tree, each node will save its hash value, and these hash values will be used to generate the hash values of the upper-level nodes. The hash path is composed of these intermediate hash values.

[0069] Optionally, in this embodiment, the hash paths adjacent to the verification data on the Merkle tree can refer to the hash values directly connected to the verification data on the path from the root node of the Merkle tree to the leaf node where the verification data is located. These hash values are used to verify the position of the verification data in the Merkle tree.

[0070] Optionally, in this embodiment, the existence of the verification data on the Merkle tree is verified using the verification data, the Merkle root, and the adjacent hash paths to obtain a verification result. For example, the lightweight node uses the verification information set received from the consensus node (including the verification data in the transaction data, the adjacent hash paths, and the Merkle root) to locally reconstruct a partial Merkle tree and verify whether the verification data exists in the Merkle tree according to the expected hash path. If the verification data can be found in the reconstructed partial Merkle tree and all the hash values match the received data, then the lightweight node can confirm the existence of the verification data in the blockchain.

[0071] Optionally, in this embodiment, if the verification result shows that the verification data effectively exists on the Merkle tree, then the lightweight node can determine that the associated transaction data also effectively exists in the blockchain, that is, the verification of validity. This certainty is based on the mathematical properties of the Merkle tree and the irreversibility of the hash function.

[0072] It should be noted that this embodiment first utilizes the different characteristics of lightweight nodes (light nodes) and full-scale nodes (consensus nodes) in the blockchain. Lightweight nodes save incomplete blockchain data, while consensus nodes save complete blockchain data. When a lightweight node needs to verify associated transaction data, it sends a verification request to the consensus node. This way of division of labor and cooperation avoids the cumbersome processing of complete blockchain data by lightweight nodes, thereby improving the verification efficiency.

[0073] Secondly, after receiving a verification request, the consensus node in this embodiment does not return the complete blockchain data, but only returns the verification information related to the verification request, including specific verification data in the transaction data, the hash path adjacent to the specific verification data on the Merkle tree, and the Merkle root of the Merkle tree. This way of returning streamlined data reduces the data transmission volume, thereby improving the verification speed.

[0074] After receiving the verification information, the lightweight node uses the specific verification data, the Merkle root, and the adjacent hash path to verify the existence of the data on the Merkle tree. Since only specific data and paths need to be verified instead of all the data in the entire blockchain, the amount of computation and time required for verification is reduced.

[0075] And if the verification result indicates that the verification data exists effectively on the Merkle tree, the lightweight node can determine that the associated transaction data exists effectively in the blockchain. This deterministic verification result avoids unnecessary repeated verification, thereby achieving the purpose of reducing the amount of computation and time required for verifying blockchain transactions, and thus realizing the technical effect of improving the verification efficiency of blockchain transactions.

[0076] For further illustration by way of example, optionally Figure 3 As shown, in the case of obtaining a verification request triggered by the transaction data associated with the lightweight node 302, the verification request is sent to the consensus node 304, where the verification request is used to request verification of the existence of the transaction data in the blockchain. The lightweight node 302 is a lightweight node in the blockchain for storing non-complete blockchain data, and the consensus node 304 is a full-scale node in the blockchain for storing complete blockchain data. The complete blockchain data includes transaction data, and the lightweight node 302 and the consensus node 304 are mutually associated;

[0077] Obtain the verification information set returned by the consensus node 304, where the verification information set includes verification data (such as data 1) in the transaction data, the hash path adjacent to the verification data on the Merkle tree (such as the hash path adjacent to data 1 in all the hash paths), and the Merkle root of the Merkle tree. The Merkle tree is composed of the hash paths matched by each data in the transaction data, and the Merkle root is the hash value result obtained by combining and operating each data on the Merkle tree according to the matched hash path;

[0078] Further use the verification data, the Merkle root, and the adjacent hash path to verify the existence of the verification data on the Merkle tree to obtain a verification result; in the case where the verification result indicates that the verification data exists effectively on the Merkle tree, determine that the transaction data exists effectively in the blockchain.

[0079] Through the embodiments provided in this application, the different responsibilities of lightweight nodes (light nodes) and full-scale nodes (consensus nodes) in the blockchain are first utilized. Among them, light nodes focus on storing incomplete blockchain data, while consensus nodes maintain complete blockchain data. However, when a light node needs to verify specific transaction data, the consensus node often returns the entire blockchain data, which undoubtedly increases the processing pressure on the light node. And due to the need to process a large amount of data, the data processing process of the blockchain becomes slow and cumbersome, which instead reduces the verification efficiency of the lightweight node, and there are certain technical defects. Further, to overcome the above technical defects in this embodiment, when the light node sends a verification request to the consensus node, the consensus node no longer returns the entire blockchain data, but only returns the partial data related to the verification, and these data include key information such as specific verification information, the hash path on the Merkle tree, and the Merkle root. In this way, the light node can use these streamlined data for efficient verification, avoiding the transmission and redundant checks of the entire blockchain, and thus achieving the purpose of reducing the computational amount and time required for verifying blockchain transactions, thereby realizing the technical effect of improving the verification efficiency of blockchain transactions.

[0080] As an optional solution, obtaining the verification data returned by the consensus node includes:

[0081] Obtaining the verification data, the Merkle root, and the hash path returned by the consensus node; where

[0082] In the case where the hash path where the verification data matches on the Merkle tree includes the first hash value, the adjacent hash path includes the second hash value adjacent to the first hash value on the Merkle tree;

[0083] In the case where the hash path where the verification data matches on the Merkle tree includes the first hash value and the first combined hash value, the adjacent hash path includes the second hash value and the second combined hash value, the first combined hash value is the hash value obtained by the combined operation of the first hash value and the second hash value, and the second combined hash value is the hash value adjacent to the first combined hash value on the Merkle tree;

[0084] In the case where the hash path where the verification data matches on the Merkle tree includes the first hash value, the first combined hash value, and the first target hash value, the adjacent hash path includes the second hash value, the second combined hash value, and the second target hash value, the first target hash value is the hash value obtained by the combined operation of the first combined hash value and the second combined hash value, and the second target hash value is the hash value adjacent to the first target hash value on the Merkle tree.

[0085] It should be noted that during the verification process of blockchain transactions, in order to improve verification efficiency, lightweight nodes will obtain the verification data, Merkle root, and hash path returned by consensus nodes. These returned data allow lightweight nodes to verify the existence of transaction data without downloading the entire blockchain. Among them, the hash path refers to the sequence of hash values passed from the root of the Merkle tree (Merkle root) to a specific leaf node (verification data).

[0086] For further illustration, optionally assume there is a blockchain containing multiple transactions, and each transaction is represented as a hash value and stored in the leaf nodes of the Merkle tree. Now, a lightweight node wants to verify the existence of a specific transaction (verification data).

[0087] The first case: If the verification data is located in a shallower level of the Merkle tree, its hash path may only include a first hash value. At this time, the adjacent hash path will include the second hash value adjacent to this first hash value on the Merkle tree. The lightweight node only needs to obtain these two hash values to reconstruct part of the Merkle tree and conduct verification.

[0088] The second case: If the verification data is located in a deeper level of the Merkle tree, its hash path may include the first hash value and the first combined hash value formed by the combination of the first hash value and the second hash value. At this time, the adjacent hash path will include the second hash value and the second combined hash value adjacent to the first combined hash value on the Merkle tree. The lightweight node needs to obtain these four hash values for verification.

[0089] The third case: For deeper levels, the hash path of the verification data may be longer, including the first hash value, the first combined hash value, and the first target hash value formed by the combination of the first combined hash value and the second combined hash value. In this case, the adjacent hash path will be correspondingly longer, but the lightweight node still only needs to obtain a limited number of hash values for verification.

[0090] Through the embodiments provided in this application, verification data, a Merkle root, and a hash path returned by a consensus node are obtained. Wherein, when the hash path where the verification data matches on the Merkle tree includes a first hash value, the adjacent hash path includes a second hash value adjacent to the first hash value on the Merkle tree; when the hash path where the verification data matches on the Merkle tree includes a first hash value and a first combined hash value, the adjacent hash path includes a second hash value and a second combined hash value, the first combined hash value is a hash value obtained by a combined operation of the first hash value and the second hash value, and the second combined hash value is a hash value adjacent to the first combined hash value on the Merkle tree; when the hash path where the verification data matches on the Merkle tree includes a first hash value, a first combined hash value, and a first target hash value, the adjacent hash path includes a second hash value, a second combined hash value, and a second target hash value, the first target hash value is a hash value obtained by a combined operation of the first combined hash value and the second combined hash value, and the second target hash value is a hash value adjacent to the first target hash value on the Merkle tree. By obtaining the verification data returned by the consensus node and its adjacent hash path on the Merkle tree, the purpose of efficiently verifying the existence of transaction data is achieved, thereby realizing the technical effect of improving the verification efficiency of blockchain transactions.

[0091] As an optional solution, the existence of the verification data on the Merkle tree is verified by using the verification data, the Merkle root, and the adjacent hash path to obtain a verification result, including:

[0092] S1-1, when the adjacent hash path includes a second hash value, a combined operation is performed on the first hash value and the second hash value to obtain a first operation result. Wherein, when the first operation result is consistent with the Merkle root, the verification result indicates that the verification data exists effectively on the Merkle tree;

[0093] S1-2, when the adjacent hash path includes a second hash value and a second combined hash value, a combined operation is performed on the first combined hash value and the second combined hash value to obtain a second operation result. Wherein, when the second operation result is consistent with the Merkle root, the verification result indicates that the verification data exists effectively on the Merkle tree;

[0094] S1-3, when the adjacent hash path includes a second hash value, a second combined hash value, and a second target hash value, a combined operation is performed on the first target hash value and the second target hash value to obtain a third operation result. Wherein, when the third operation result is consistent with the Merkle root, the verification result indicates that the verification data exists effectively on the Merkle tree.

[0095] Optionally, in this embodiment, the Merkle tree is a binary tree structure, where each leaf node is the hash value of a data block, and each non-leaf node is a combination of the hash values of its child nodes (such as re-hashing). Due to the one-way property and avalanche effect of the hash function, any minor data change will result in a significant change in the final hash value (the Merkle root). Therefore, by verifying a series of hash values on the hash path from the verification data to the Merkle root, lightweight nodes can efficiently confirm the existence and integrity of the verification data without verifying the entire blockchain.

[0096] It should be noted that in the blockchain, to improve the verification efficiency of transactions, lightweight nodes will use the verification data, Merkle root, and adjacent hash paths obtained from consensus nodes to verify the existence of transaction data on the Merkle tree. This verification method is based on the structural characteristics of the Merkle tree and verifies level by level upward through the combined operation of adjacent hash values until reaching the root node of the Merkle tree (the Merkle root).

[0097] To further illustrate with an example, optionally, if the adjacent hash path only includes the second hash value, the lightweight node will perform a combined operation (usually a hash operation) on the first hash value and the second hash value to obtain a first operation result. If this first operation result is consistent with the Merkle root, it indicates that the verification data exists effectively on the Merkle tree.

[0098] If the adjacent hash path includes the second hash value and the second combined hash value, the lightweight node will skip the hash values of the first layer (since they are assumed to be correct) and directly perform a combined operation on the first combined hash value and the second combined hash value to obtain a second operation result. Similarly, if the second operation result is consistent with the Merkle root, the verification data is considered to exist effectively.

[0099] If the adjacent hash path is longer and includes the second hash value, the second combined hash value, and the second target hash value, the lightweight node will perform a similar combined operation, but this time on the first target hash value and the second target hash value to obtain a third operation result. The comparison of this result with the Merkle root will determine the validity of the verification data.

[0100] Through the embodiments provided in this application, when adjacent hash paths include a second hash value, a combined operation is performed on the first hash value and the second hash value to obtain a first operation result. Among them, when the first operation result is consistent with the Merkle root, the verification result indicates that the verification data exists effectively on the Merkle tree; when adjacent hash paths include a second hash value and a second combined hash value, a combined operation is performed on the first combined hash value and the second combined hash value to obtain a second operation result. Among them, when the second operation result is consistent with the Merkle root, the verification result indicates that the verification data exists effectively on the Merkle tree; when adjacent hash paths include a second hash value, a second combined hash value, and a second target hash value, a combined operation is performed on the first target hash value and the second target hash value to obtain a third operation result. Among them, when the third operation result is consistent with the Merkle root, the verification result indicates that the verification data exists effectively on the Merkle tree. This allows lightweight nodes to confirm the existence of transaction data in the blockchain by only acquiring and verifying a small amount of data (verification data, Merkle root, and adjacent hash paths), rather than downloading the entire blockchain or performing a full-scale data verification. Furthermore, it achieves the purpose of reducing the data transmission volume, lowering the computational complexity, and using the mathematical properties of the Merkle tree to ensure the accuracy and security of verification, thereby realizing the technical effect of improving the verification efficiency of blockchain transactions.

[0101] As an optional solution, before sending the verification request to the consensus node, the method further includes:

[0102] S2-1, obtaining the first block height of the consensus node, where the first block height is used to indicate the position number of the block currently held by the consensus node in the blockchain;

[0103] S2-2, when the first block height is greater than the second block height of the lightweight node, obtaining the verification request, where the second block height is used to indicate the position number of the block currently held by the lightweight node in the blockchain.

[0104] Optionally, in this embodiment, the block height can represent the position or order of a specific block in the blockchain. Each newly generated block is added to the end of the blockchain, and each block has a unique block height, which is determined according to the position of the block in the blockchain.

[0105] For further illustration, the calculation of the optional block height starts from the genesis block (i.e., the first block) of the blockchain. The block height of the genesis block is defined as 0, and subsequently, the block height of each newly generated block increases by 1. Therefore, the block height can be understood as an integer representing how many blocks have passed from the genesis block to the current block.

[0106] It should be noted that in a blockchain network, each node (whether it is a light node or a consensus node) maintains the data of one or more blocks. The block height is a number used to identify the position of a specific block in the blockchain, representing the number of blocks from the genesis block (the first block) to that block. Light nodes and consensus nodes play different roles in the blockchain network: light nodes only store incomplete blockchain data, while consensus nodes store complete blockchain data.

[0107] When a light node needs to verify the transaction data associated with it, it will consider the block height of the consensus node. This is because the consensus node usually has the latest block height due to storing the complete blockchain data, while the light node may have a lower block height because it only stores partial data.

[0108] To further illustrate with an example, optionally, for example, the light node first queries the block height of the block currently held by the consensus node (i.e., the first block height), which is usually achieved by sending a request to the consensus node. The light node compares the first block height of the consensus node with its own second block height. The second block height indicates the position of the latest block currently held by the light node in the blockchain. If the first block height of the consensus node is greater than the second block height of the light node, this means that the consensus node has updated data that the light node has not yet obtained. In this case, the light node will obtain the verification request related to the transaction data to be verified and send it to the consensus node.

[0109] Through the embodiments provided in this application, by comparing the block heights, the light node can avoid sending unnecessary requests before sending a verification request to the consensus node because it already holds the latest data. This reduces redundant communication in the network. Only when the consensus node has data newer than the light node will the light node send a verification request. This ensures that the light node always bases its verification of transaction data on the latest blockchain state. By reducing unnecessary network communication and computing, the light node and the consensus node can more effectively utilize their resources, such as processor time, bandwidth, and storage space. By comparing the block heights and sending verification requests when necessary, the purpose of ensuring that the light node always verifies transactions based on the latest blockchain state is achieved, thereby realizing the technical effect of improving the transaction verification efficiency of the entire blockchain network.

[0110] As an optional solution, before sending the verification request to the consensus node, the method further includes:

[0111] S3-1, obtaining a first hash value set containing N random numerical values, where the verification request carries the first hash value set, and N is a natural number;

[0112] S3-2. Obtain the requested block height according to the second block height and the first block height.

[0113] Among them, the verification request carries the requested block height, the verification data is the data in the transaction data that matches the first hash value set, the transaction data is the blockchain data corresponding to the target block, and the target block is the block determined by the consensus node from the blocks currently held by the consensus node and matching the requested block height.

[0114] It should be noted that in this embodiment, by sending a verification request that includes a hash value set instead of the complete transaction data, the light node significantly reduces the amount of data that needs to be transmitted. Hash values are usually much smaller than the original data, so bandwidth and transmission time can be saved.

[0115] By specifying the requested block height, the light node can more precisely tell the consensus node which data needs to be verified. This avoids the consensus node unnecessarily processing a large amount of irrelevant data, thereby improving the efficiency of the verification process.

[0116] In addition, since the communication and data processing between the light node and the consensus node are more efficient, this reduces the redundant operations and computational overhead in the network. This is particularly important for resource-constrained environments because it allows for more efficient use of limited computing, storage, and communication resources.

[0117] For further illustration by way of example, optionally, for example, the light node first generates or obtains a first hash value set containing N hash values. The light node calculates the requested block height according to its own second block height and the first block height of the consensus node, such as comparing these two heights and selecting a suitable, lower block height as the basis for the request. The light node sends a verification request containing the first hash value set and the requested block height to the consensus node.

[0118] Through the embodiment provided by this application, obtain a first hash value set containing N random numerical values, where the verification request carries the first hash value set, N is a natural number; obtain the requested block height according to the second block height and the first block height; among them, the verification request carries the requested block height, the verification data is the data in the transaction data that matches the first hash value set, the transaction data is the blockchain data corresponding to the target block, and the target block is the block determined by the consensus node from the blocks currently held by the consensus node and matching the requested block height. By combining the use of the first hash value set and the requested block height, the purpose of enabling the light node to obtain the data required for transaction verification from the consensus node more quickly and accurately is achieved, thereby realizing the technical effect of improving the verification efficiency of blockchain transactions.

[0119] As an optional solution, before obtaining the verification data returned by the consensus node, the method further includes:

[0120] S4-1. When the verification request is a subscription verification request and the consensus node currently holds a new block, obtain a second hash value set containing K random values returned by the consensus node. Here, the subscription verification request is used to request verification when the consensus node currently holds a new block. The second hash value set is a hash value set obtained by the consensus node using the block hash value corresponding to the new block as a random number seed, and K is a natural number.

[0121] S4-2. Obtain a third hash value set containing P random values, where P is a natural number.

[0122] S4-3. Perform an addition modulo operation on the second hash value set and the third hash value set to obtain a target hash value set.

[0123] Among them, the verification request carries the target hash value set, and the verification data is the data in the transaction data that matches the target hash value set. The transaction data is the blockchain data corresponding to the new block.

[0124] Optionally, in this embodiment, the subscription verification request can be understood as a special type of verification request sent by a lightweight node, used to inform the consensus node that when the consensus node holds a new block, the lightweight node hopes to verify it.

[0125] It should be noted that in the blockchain, in order to improve the verification efficiency of transactions, especially when a lightweight node hopes to subscribe to the new block of the consensus node for verification, a screening and verification method based on a hash value set can be adopted. This method involves the interaction between the lightweight node and the consensus node, as well as the use of hash functions and random number seeds to generate and match hash value sets.

[0126] For further illustration by example, optionally, for example, a lightweight node sends a subscription verification request to the consensus node, indicating that it hopes to verify the new block of the consensus node. When the consensus node holds a new block, it uses the block hash value of the new block as a random number seed to generate a second hash value set containing K hash values and returns it to the lightweight node. The lightweight node generates a third hash value set containing P hash values. The lightweight node performs an addition modulo operation on the received second hash value set and the third hash value set it generates to obtain a target hash value set. The lightweight node sends a verification request carrying the target hash value set to the consensus node, requesting the consensus node to return verification data in the new block that matches the target hash value set.

[0127] Through the embodiments provided in this application, by using the hash value set as the screening condition, the lightweight node only needs to obtain the transaction data that matches the target hash value set from the consensus node, rather than all the transaction data of the entire new block. This greatly reduces the amount of data that needs to be transmitted, thereby improving the verification efficiency. Since the second hash value set is generated based on the block hash value of the new block, it has high randomness and unpredictability. This increases the security of the system because it is difficult for malicious nodes to predict or manipulate the hash value set. Both the lightweight node and the consensus node can independently generate their own hash value sets (the third hash value set and the second hash value set), and then obtain the target hash value set through the modulo addition operation, which provides great flexibility and allows the lightweight node and the consensus node to cooperate without the need for complete synchronization or sharing of the same information. By combining the use of subscription verification requests, generation of hash value sets based on the hash value of the new block, and modulo addition operation of hash value sets, the purpose of enabling the lightweight node to obtain the data required for transaction verification in the new block from the consensus node more quickly and accurately is achieved, thereby realizing the technical effect of improving the verification efficiency of blockchain transactions.

[0128] As an optional solution, obtaining the verification data returned by the consensus node includes:

[0129] Obtaining the verification data of the first data volume, the Merkle root, and the hash path returned by the consensus node, where the ratio between the first data volume and the second data volume of the transaction data is greater than or equal to a preset ratio.

[0130] It should be noted that in the blockchain, verification data usually involves a large amount of computation and data transmission. To improve the verification efficiency, a verification method based on data digest (such as Merkle tree) can be adopted. In this method, instead of obtaining the complete transaction data for verification, the lightweight node obtains a verification data with a smaller data volume and combines the Merkle root and the hash path for verification.

[0131] For further illustration, optionally, for example, the lightweight node sends a verification request to the consensus node, and the request contains information such as the target hash value set. The consensus node filters out the transaction data that matches the target hash value set according to the verification request, and calculates the Merkle root and the hash path of this part of the transaction data. The consensus node returns the verification data of the first data volume, the Merkle root, and the hash path to the lightweight node.

[0132] Through the embodiments provided in this application, a light node only needs to obtain verification data of the first data volume instead of the complete transaction data. This greatly reduces the data transmission volume, thereby improving the verification efficiency. By combining the Merkle root and the hash path, the light node can quickly verify whether the received verification data is authentic and valid locally. This is because if the verification data is tampered with, the recalculated Merkle root will not match the original Merkle root. Furthermore, by adjusting the ratio between the first data volume and the second data volume (i.e., the preset ratio) in this embodiment, the accuracy and efficiency of verification can be balanced. The higher the ratio, the higher the verification accuracy, but the efficiency may decrease; the lower the ratio, the higher the efficiency, but the accuracy may decrease. By combining the verification data of the first data volume, the Merkle root, and the hash path, the purpose of enabling the light node to verify the transaction data more quickly and accurately is achieved, thereby realizing the technical effect of improving the verification efficiency of blockchain transactions.

[0133] Optionally, as another alternative embodiment, as Figure 4 shown, the verification method of blockchain transactions can be executed by an electronic device, and the electronic device can be, for example, a user device or a server as Figure 1 shown, and the specific steps include:

[0134] S402. Obtain a verification request sent by a light node, where the verification request is a request triggered by transaction data associated with the light node and used to request verification of the existence of the transaction data in the blockchain. The light node is a lightweight node in the blockchain used to store non-complete blockchain data, and the consensus nodes in the blockchain are full-weight nodes used to store complete blockchain data. The complete blockchain data includes transaction data, and the light node and the consensus nodes are mutually associated;

[0135] S404. Respond to the verification request and obtain verification data. The complete blockchain data includes verification data. The verification data includes verification data in the transaction data, the hash path adjacent to the verification data on the Merkle tree, and the Merkle root of the Merkle tree. The Merkle tree is composed of hash paths matched by each data in the transaction data, and the Merkle root is the hash value result obtained by operating on each data on the Merkle tree according to the matched hash path;

[0136] S406. Send the verification data to the light node, and the light node uses the verification data, the Merkle root, and the adjacent hash path to verify the existence of the verification data on the Merkle tree, obtain a verification result, and determine that the transaction data exists effectively in the blockchain.

[0137] Optionally, in this embodiment, the above blockchain transaction verification method can be, but is not limited to, applied in the blockchain scenario of a light node (client) and a consensus node (server). The light node (client) does not need to store the complete blockchain data, thus reducing its hardware and storage requirements. When the client needs to verify the associated transaction data, it sends a verification request to the server. The consensus node (server) stores the complete blockchain data and can quickly respond after receiving the request.

[0138] When responding to the request, the server does not return the entire blockchain data. Instead, according to the verification requirements of the client, it precisely provides the relevant verification data. These data include specific verification data in the transaction data, the hash path of this verification data on the Merkle tree, and the Merkle root of the Merkle tree. This way of returning data greatly reduces the data transmission volume and improves the verification speed.

[0139] After receiving the verification data returned by the server, the client uses this data, the Merkle root, and the hash path for verification. Since the verification process only involves specific data and paths, rather than all the data of the entire blockchain, the computational amount and time required for verification are greatly reduced.

[0140] If the verification result shows that the verification data effectively exists on the Merkle tree, the client can determine that the associated transaction data also effectively exists in the blockchain. This deterministic verification result not only enhances the client's confidence in the authenticity of the transaction data but also avoids unnecessary repeated verification, further improving the verification efficiency.

[0141] Therefore, in this interaction scenario between the light node (client) and the consensus node (server), the blockchain transaction verification method provided by the embodiment of the present application realizes a substantial improvement in the blockchain transaction verification efficiency by optimizing data return, reducing the computational amount, and providing a deterministic verification result.

[0142] It should be noted that this embodiment first utilizes the different characteristics of lightweight nodes (light nodes) and full-scale nodes (consensus nodes) in the blockchain. The light node stores incomplete blockchain data, while the consensus node stores complete blockchain data. When the light node needs to verify the associated transaction data, it sends a verification request to the consensus node. This way of division of labor and cooperation avoids the cumbersome processing of the complete blockchain data by the light node, thus improving the verification efficiency.

[0143] Secondly, after receiving the verification request, the consensus node in this embodiment does not return the complete blockchain data, but only returns the verification information related to the verification request, including specific verification data in the transaction data, the adjacent hash path of the specific verification data on the Merkle tree, and the Merkle root of the Merkle tree. This way of returning streamlined data reduces the data transmission volume, thereby improving the verification speed.

[0144] After receiving the verification information, the lightweight node uses the specific verification data, Merkle root, and adjacent hash path to verify the existence of the data on the Merkle tree. Since only specific data and paths need to be verified instead of all the data in the entire blockchain, the computational effort and time required for verification are reduced.

[0145] And if the verification result indicates that the verification data exists effectively on the Merkle tree, the lightweight node can determine that the associated transaction data exists effectively in the blockchain. This deterministic verification result avoids unnecessary repeated verification, and thus achieves the purpose of reducing the computational effort and time required for verifying blockchain transactions, thereby realizing the technical effect of improving the verification efficiency of blockchain transactions.

[0146] For specific embodiments, reference can be made to the examples shown in the above verification method for blockchain transactions, and details are not elaborated herein for this example.

[0147] Through the embodiments provided in this application, the different responsibilities of lightweight nodes (light nodes) and full-scale nodes (consensus nodes) in the blockchain are first utilized. Among them, lightweight nodes focus on storing incomplete blockchain data, while consensus nodes maintain complete blockchain data. However, when a lightweight node needs to verify specific transaction data, the consensus node often returns the entire blockchain data, which undoubtedly increases the processing pressure on the lightweight node. Moreover, due to the need to process a large amount of data, the data processing process of the blockchain becomes slow and cumbersome, instead reducing the verification efficiency of the lightweight node, presenting certain technical drawbacks. Further, to overcome the above technical drawbacks in this embodiment, when the lightweight node sends a verification request to the consensus node, the consensus node no longer returns the entire blockchain data, but only returns partial data related to the verification, including key information such as specific verification information, the hash path on the Merkle tree, and the Merkle root. In this way, the lightweight node can use this streamlined data for efficient verification, avoiding the transmission and redundant checks of the entire blockchain, and thus achieving the purpose of reducing the computational effort and time required for verifying blockchain transactions, thereby realizing the technical effect of improving the verification efficiency of blockchain transactions.

[0148] As an alternative solution, obtaining the verification data includes:

[0149] S5-1. When the verification request is a subscription verification request and the consensus node currently holds a new block, use the block hash value corresponding to the new block as a random number seed, and obtain a fourth hash value set containing M random values by using the random number seed, where the subscription verification request is used to request verification when the consensus node currently holds a new block, and M is a natural number;

[0150] S5-2. Determine the verification data that matches the fourth hash value set from the transaction data.

[0151] Optionally, in this embodiment, the subscription verification request may be a special verification request sent by a lightweight node, aiming to verify the new block when the consensus node holds it.

[0152] Optionally, in this embodiment, each block is assigned a unique hash value when generated, and this hash value is a digest of the block content.

[0153] Optionally, in this embodiment, in encryption and hashing operations, the random number seed is an initial value used to start or control a certain random or pseudo-random process.

[0154] It should be noted that in a blockchain environment, to improve the verification efficiency of transactions, especially when a lightweight node subscribes to a new block of a consensus node for verification, a screening method based on a hash value set can be adopted. In this method, instead of obtaining all the transaction data of the entire new block for verification, the lightweight node filters out some transaction data for verification according to a specific hash value set.

[0155] For further illustration, optionally, for example, when a lightweight node sends a subscription verification request and the consensus node currently holds a new block, the consensus node will use the block hash value of this new block as a random number seed. Using this random number seed, the consensus node generates a fourth hash value set containing M random values. Next, the consensus node filters out the verification data that matches the fourth hash value set from the transaction data corresponding to the new block. Finally, the consensus node returns the filtered verification data to the lightweight node.

[0156] Through the embodiments provided by this application, the light node does not obtain all the transaction data of the entire new block, but only obtains the verification data that matches the fourth hash value set. This greatly reduces the amount of data that needs to be transmitted and processed. Since the fourth hash value set is generated based on the block hash value of the new block, it has a high degree of randomness. This increases the security of the system because it is difficult for malicious nodes to predict or manipulate this hash value set. By adjusting the value of M, the accuracy and efficiency of verification can be balanced. A larger value of M will increase the amount of verification data, thereby improving the accuracy, but may reduce the efficiency; a smaller value of M will improve the efficiency, but may reduce the accuracy. By combining the use of subscription verification requests, the fourth hash value set generated based on the block hash value of the new block, and the matching and screening of the hash value set, the purpose is achieved that the light node can obtain the data required for transaction verification in the new block from the consensus node more quickly and accurately, thereby achieving the technical effect of improving the verification efficiency of blockchain transactions.

[0157] As an alternative solution, for ease of understanding, the above verification method for blockchain transactions is applied to the blockchain technology scenario. With the development of blockchain technology, more and more business systems are starting to use blockchain. Blockchain is essentially a distributed storage system, and all consensus nodes need to store complete data so that transactions can be executed in order to participate in and reach consensus.

[0158] However, in reality, as the number of blockchain nodes increases, the performance of blockchain node consensus will decline, which is foreseeable. The most intuitive understanding is that the message communication volume has increased. And in many business systems, there is a need to verify whether a transaction exists. The consensus nodes already have a very large number of functions, so they are not suitable for this.

[0159] Then there are light nodes. Such nodes do not store all the block data, but only retain the block header information. When a transaction is verified, its existence can be verified through the Merkle path of this transaction. However, for light nodes, their data source is the consensus node. Although they only store the block header, they also need to verify the block header.

[0160] The block header consists of information such as the block hash value (Hash), block height, and transaction Merkle root. The block Hash is calculated through a hash function using information such as the previous block Hash, block height, and transaction Merkle root, and it is very easy to verify. However, the verification of the transaction Merkle root is not easy to achieve.

[0161] The current solution used in the industry is to send all transaction data to the light node. The light node regenerates it through the same Merkle root calculation method and then verifies it. Such calculation is rigorous. Some blockchain systems will only send the Hash values of all transaction data, which is more efficient. However, since the transactions themselves also need to be verified, this is prone to the risk of malicious behavior.

[0162] To solve this problem, this embodiment combines the idea of commitment in cryptography and combines Merkle commitment to propose a Merkle root verification method for light node transactions that can reduce the message communication volume. Through this method, the message communication volume can be greatly reduced, the performance can be improved, and the security is sufficient.

[0163] The core of this embodiment can be understood as adopting a technology called Merkle commitment. The core point is to replace all by a probabilistic method, that is, not to send all the data, but only a very small part of the data. However, this embodiment can still determine that these data are normal with a high probability.

[0164] Optionally, in this embodiment, for example Figure 5 As shown in the Merkle tree (D is the underlying data, H is the hash value, and Root is the Merkle tree root), assuming the Merkle tree has n layers, then the number of transactions is 2^n. If n is 10, it means there are 1024 transactions. If the size of one transaction is 1MB, then the total data volume to be transmitted is 1G. And assuming only N data Ds are selected from 2^n for verification, and considering that the data D is not just one bit in size and the forgery difficulty is relatively high, so N can be set to 1, that is, only 1 data D is selected for verification. Because for a collision-resistant hash function, it is impossible to construct a transaction with different content and a signature that can pass within polynomial time.

[0165] For further illustration by example, optionally for example Figure 6 As shown in the Merkle tree, assuming data D3 is the data D to be verified, then this embodiment only needs to transmit data D3, hash value H4 (the hash value corresponding to data D4), hash value H12 (the combination of hash value H1 and hash value H2), and hash value H5678 (the combination of hash value H56 and hash value H78). This data volume is relatively small compared to all the data.

[0166] Specifically, the verification data D3 can be understood as the path of data D3 in the verified Merkle tree (a path from a certain data to the Merkle root is understood as a path. For example, D3, H3, H34, H1234, Root is such a path, assumed to be path A). To verify path A, the known H4, H12, H5678, and Root are used for verification (this is because at the initial stage of creating the Merkle tree, Root is obtained through the combination of hash values. Therefore, it is known that Root = H1234 + H5678, H1234 = H12 + H34, and H34 = H3 + H4), and then by verifying path A with the above-known proofs, it is finally determined whether the obtained hash value combination is Root.

[0167] Assume again that the selected data D is data D6. Then the data obtained by the light node at least includes D6, H5, H78, H123456, and Root, and the verified path is path B: D6, H5, H56, H5678, Root.

[0168] Optionally, in this embodiment, for the selection of data D, if there is a consensus node to select this D (this transaction), there is a certain space for malicious behavior, and it can be forged through transactions constructed in a non-polynomial manner. Then the most reasonable and easy-to-understand way is naturally for the light node to select, or a way that the server cannot know.

[0169] Optionally, in the blockchain system of this embodiment, there are multiple interaction relationships between the light node and the consensus node. One interaction relationship is the request-response type. The consensus node broadcasts its current block height (or the light node periodically obtains the block height of the corresponding consensus node); if the light node determines that the block height is higher than its local one, it will send a request to the corresponding consensus node to obtain block information; the consensus node sends the result to the light node.

[0170] For further illustration by example, optionally, for example Figure 7 As shown, the specific steps are as follows:

[0171] The verifier (light node) randomly generates N numbers (strings) as a random value set. The random value set and the requested height H are sent to the prover in the form of a network message. Calculate the Hash value set [H1, H2,..., Hn] corresponding to the content in the random value set and its corresponding processed value set [H'1, H'2,..., H'n].

[0172] The proving party (consensus node) parses the network message from the verifying party to obtain the block height H and the set of random values [X1, X2, …, Xn]. It retrieves the block header (BlockHeader) with height H from the local ledger. Initializes an empty set of response transactions (TxList). Traverses the set of random numbers [X1, X2, …, Xn] and performs the following operations on each value X in the set: Performs a Hash operation on X to generate the corresponding Hash value H. Processes H according to specific rules to obtain H' and calculates the index M: H' mod len(Txs) = M. Looks up the transaction in Txs[M] and calculates the corresponding Merkle path Path. Constructs the transaction in Txs[M] and its Path as a transaction with a Merkle path and adds it to TxList. Constructs a response message containing BlockHeader, TxList (the set of transactions with Merkle paths), and the total number of transactions (TransactionCount). Sends the response message back to the verifying party in the form of a network message.

[0173] The verifying party (light node) continues the operation, parses the network message from the proving party to obtain BlockHeader, TxList, and TransactionCount. Calculates the results of taking the modulo of the values in the set [H'1, H'2, …, H'n] by TransactionCount: [M1, M2, …, Mn]. Traverses the set [M1, M2, …, Mn] and verifies the corresponding transactions with Merkle paths in the order of TxList. If any transaction verification fails, discards the entire block header information; if all transaction verifications succeed, proceeds to the next step. Verifies whether the received block hash (BlockHash) is consistent with the locally calculated or expected Hash value. If not, discards it; if consistent, proceeds to the next step. Writes the verified block header into the local ledger.

[0174] For this interaction model, this embodiment proposes a scheme for random selection by the client. The core of this scheme is to fill in the position where the corresponding data D required by the consensus node is located when sending a request, and the consensus node returns the data according to the requirements.

[0175] In blockchain technology, a block is the basic unit that makes up the blockchain. Each block contains a series of transaction information and other metadata. For the corresponding server (consensus node), the response data is optionally based on Figure 7 the scenario shown, and continues as Figure 8 shown, the block header (Block Header) is the metadata part of the block, containing some key information of the block but not the actual transaction content. The block header usually includes information such as the hash value of the previous block, timestamp, difficulty target (for proof-of-work blockchains), etc.

[0176] Transaction Count: Refers to the number of transactions contained in a block. This number helps network nodes understand how many transactions they need to parse next.

[0177] Transaction content refers to the content of a specific transaction. Each transaction typically includes a sender, a recipient, the transaction amount, and other possible fields (such as transaction fees, timestamps, etc.).

[0178] BlockHash (block hash) is the hash value of the block header, which is calculated through a specific hash algorithm. The hash of each block is unique and closely related to the content of the block. Any minor change to the block content will cause a huge change in the hash value.

[0179] BlockHeight (block height) refers to the position of the block in the blockchain. The height of the first block (also known as the genesis block) is 0, and the height of each subsequent block increases in sequence.

[0180] In some blockchain implementations, TransactionSetRoot is the root hash of the Merkle Tree formed by all transactions in the block. This allows lightweight nodes to verify the existence and integrity of specific transactions by only downloading and verifying the block header.

[0181] TransactionCount refers to the number of transactions in the block. TransactionX and TxPathX(Y) are specific transactions and their Merkle paths. The Merkle path is a list of hash values that allows tracing from TransactionSetRoot in the block header to a specific transaction. This is very useful for lightweight nodes because they can verify specific transactions without having to download the entire block or all transactions.

[0182] For example, Transaction1 is a specific transaction in the block, and TxPath1(1), TxPath1(2), TxPath1(... ) are the list of hash values that form the Merkle path from TransactionSetRoot to Transaction1.

[0183] For further illustration, optionally, a light node subscribes to a synchronous request. For the consensus node, as long as a new block is generated, it will be pushed to the light node. In this mode, there is no interaction. To prevent the server from acting maliciously, the server can use the block Hash as a random number seed for processing. Because in the blockchain, BlockHash is a very random value, which involves a lot of data such as transactions and heights and is difficult to predict in advance.

[0184] The corresponding server processing model is optionally based on Figure 7 the scenario shown, and continue as Figure 9 shown. The specific content is as follows:

[0185] Taking BlockHash as the random source, it is the hash value of the block. Usually, each block is unique, so its hash value is also unique. A series of hash values are generated from N random sets to form a hash chain. Each hash value is calculated based on the previous hash value. For example, H1 = Hash(BlockHash), H2 = Hash(H1), H3 = Hash(H2),..., HN = Hash(HN-1), where each Hi is the result of hashing the previous hash value Hi-1.

[0186] For the N calculation sets, apply the X() function to each Hi. This function performs operations such as taking the first few or last few digits. For example, H'1 = X(H1), H'2 = X(H2), H'3 = X(H3),..., H'N = X(HN). The specific implementation and parameters of the X() function (such as taking the first few digits) may affect the randomness and security of the final transaction selection.

[0187] For the N transaction value sets, take the modulo C of each hashed value H'i processed by the X() function. C is the number of transactions in the block. For example, M1 = H'1 mod C, M2 = H'2 mod C, M3 = H'3 mod C,..., MN = H'N mod C. These Mi values are used as indices to select specific transactions from the transaction set of the block.

[0188] Further return to the corresponding transactions of the verifier. According to the calculated indices Mi, select the corresponding transactions from the transaction set Txs of the block and return these transactions and their Merkle paths Pathi, such as Txs[M1] and Path1, Txs[M2] and Path2, Txs[M3] and Path3,..., Txs[MN] and PathN, etc. The verifier can use these transactions and their Merkle paths to verify the validity of the block without downloading the entire block.

[0189] After the client receives the BlockHash, it can calculate the hash chain in the same way as the server, select transactions, and verify the validity of these transactions. Due to the determinism of the hash function, as long as the client and the server use the same BlockHash and N value, they will select the same transactions for verification.

[0190] The security of this mechanism depends on the collision resistance and randomness of the hash function. If there are weaknesses in the hash function, an attacker may be able to predict or manipulate the selected transactions. Also, the specific implementation of the X() function may affect security. If it only takes a small part of the hash value, there may be a risk of collision.

[0191] In addition, the value of N also needs to be carefully selected. A too small N may reduce randomness, while a too large N may increase the computational and communication overhead. Since the client can receive the BlockHash, it can fully verify in the same way as the server. In Figure 9 the example shown, N can be a pre-determined value.

[0192] To further illustrate with an example, optionally for the server, it also expects to play a certain role in the random number selection. Similar to many communication models, these random numbers are often the result of interaction between both parties. The corresponding processing flow is as Figure 10 shown, and the specific process is as follows:

[0193] The prover (consensus node) generates a new block and packages a certain number of transactions into the new block.

[0194] The prover obtains the block header and the number of transactions, and extracts the block header (BlockHeader) and the number of transactions (TransactionCount) of the new block.

[0195] The prover generates a set of random numbers A, and generates a set of random numbers A [A1, A2,... An] according to the TransactionCount.

[0196] The prover sends a message to the verifier, and sends the block header, TransactionCount, and set A to the verifier.

[0197] The verifier (light node) receives and parses the prover's message, receives the block header, TransactionCount, and set A sent by the prover, and parses them.

[0198] The verifier verifies the block header and checks whether the content of the block header is correct. If it is incorrect, the message is discarded.

[0199] The verifier generates a set of random numbers B. If the block header passes the verification, a set of random numbers B[B1, B2, …Bn] is generated according to TransactionCount.

[0200] The verifier sends the set B to the prover, and sends the set of random numbers B to the prover.

[0201] The prover receives and parses the message from the verifier, waits to receive the set of random numbers B sent by the verifier, and parses it.

[0202] The prover generates a new set M, performs a modulo operation by adding set A and set B, and generates a set M[M1, M2, …Mn].

[0203] The prover calculates the Merkle path corresponding to the transaction, traverses set M, and calculates the Merkle path Path for each Mi of the transaction Txs[Mi].

[0204] The prover sends the transaction and the path to the verifier, and sends the transaction set TxList and its corresponding Path to the verifier.

[0205] The verifier receives and parses the message from the prover, waits to receive the transaction set TxList sent by the prover and its corresponding Path, and parses it.

[0206] The verifier verifies the transaction and the path, traverses TxList, verifies the correctness of each transaction and its Path, and discards the message if it is incorrect.

[0207] The verifier writes to the local ledger. If all verifications pass, the block header is written to the local ledger.

[0208] Through the embodiments provided in this application, combining the commitment mechanism in cryptography and the Merkle commitment theory, an optimized verification method for the Merkle root of light node transactions is innovatively proposed. This method significantly reduces the message communication volume required during the verification process, thereby significantly improving the overall performance of the system without sacrificing security.

[0209] In terms of specific implementation, this example designs three specific interaction schemes according to the actual application scenarios and requirements. These schemes not only have high flexibility and adaptability, can be optimized for different interaction models, but also can all achieve complete and efficient block header synchronization operations. Through actual application and testing, these schemes have shown significant advantages in reducing data transmission volume and improving verification efficiency.

[0210] Compared with the prior art, the technical solution provided in this embodiment has achieved remarkable results in reducing the data transmission volume, while ensuring the security and accuracy of the verification process. This improvement is of great significance for enhancing the overall performance and scalability of the blockchain system.

[0211] It can be understood that in the specific implementation of this application, when it comes to data related to user information, etc., when the above embodiments of this application are applied to specific products or technologies, user permission or consent needs to be obtained, and the collection, use, and processing of relevant data need to comply with relevant laws, regulations, and standards in relevant countries and regions.

[0212] It should be noted that for the foregoing method embodiments, for the sake of simple description, they are all expressed as a series of action combinations. However, those skilled in the art should know that this application is not limited by the described action sequence, because according to this application, certain steps can be in other sequences or performed simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0213] According to another aspect of the embodiments of this application, there is also provided a verification device for blockchain transactions for implementing the above verification method for blockchain transactions. As Figure 11 shown, the device includes:

[0214] A first sending unit 1102, configured to send a verification request to a consensus node when a verification request triggered by transaction data associated with a light node is obtained, where the verification request is used to request verification of the existence of the transaction data in the blockchain. The light node is a lightweight node in the blockchain that is used to store non-complete blockchain data, and the consensus node is a full-scale node in the blockchain that is used to store complete blockchain data. The complete blockchain data includes transaction data, and the light node and the consensus node are mutually associated;

[0215] A first obtaining unit 1104, configured to obtain a verification information set returned by the consensus node, where the verification information set includes verification data in the transaction data, a hash path adjacent to the verification data on the Merkle tree, and the Merkle root of the Merkle tree. The Merkle tree is composed of hash paths matched by each data in the transaction data, and the Merkle root is the hash value result obtained by combining operations of each data on the Merkle tree according to the matched hash paths;

[0216] A verification unit 1106, configured to verify the existence of the verification data on the Merkle tree by using the verification data, the Merkle root, and the adjacent hash path, and obtain a verification result;

[0217] A determination unit 1108, configured to determine that the transaction data is effectively present in the blockchain when the verification result indicates that the verification data is effectively present on the Merkle tree.

[0218] For specific embodiments, reference may be made to the examples shown in the above-mentioned verification method for blockchain transactions, and details are not elaborated herein.

[0219] As an alternative solution, the first acquisition unit 1104 includes:

[0220] A first acquisition module, configured to acquire verification data, a Merkle root, and a hash path returned by a consensus node; wherein,

[0221] When the hash path matching the verification data on the Merkle tree includes a first hash value, the adjacent hash path includes a second hash value adjacent to the first hash value on the Merkle tree;

[0222] When the hash path matching the verification data on the Merkle tree includes a first hash value and a first combined hash value, the adjacent hash path includes a second hash value and a second combined hash value, the first combined hash value is a hash value obtained by a combined operation of the first hash value and the second hash value, and the second combined hash value is a hash value adjacent to the first combined hash value on the Merkle tree;

[0223] When the hash path matching the verification data on the Merkle tree includes a first hash value, a first combined hash value, and a first target hash value, the adjacent hash path includes a second hash value, a second combined hash value, and a second target hash value, the first target hash value is a hash value obtained by a combined operation of the first combined hash value and the second combined hash value, and the second target hash value is a hash value adjacent to the first target hash value on the Merkle tree.

[0224] For specific embodiments, reference may be made to the examples shown in the above-mentioned verification method for blockchain transactions, and details are not elaborated herein.

[0225] As an alternative solution, the verification unit 1106 includes:

[0226] A first operation module, configured to perform a combined operation on the first hash value and the second hash value when the adjacent hash path includes the second hash value, to obtain a first operation result, wherein when the first operation result is consistent with the Merkle root, the verification result indicates that the verification data is effectively present on the Merkle tree;

[0227] A second operation module, configured to perform a combined operation on the first combined hash value and the second combined hash value when adjacent hash paths include a second hash value and a second combined hash value, to obtain a second operation result, where when the second operation result is consistent with the Merkle root, the verification result indicates that the verification data exists effectively on the Merkle tree;

[0228] A third operation module, configured to perform a combined operation on the first target hash value and the second target hash value when adjacent hash paths include a second hash value, a second combined hash value, and a second target hash value, to obtain a third operation result, where when the third operation result is consistent with the Merkle root, the verification result indicates that the verification data exists effectively on the Merkle tree.

[0229] For specific embodiments, reference may be made to the examples shown in the above verification method for blockchain transactions, and details are not described herein again.

[0230] As an optional solution, the apparatus further includes:

[0231] A second acquisition unit, configured to acquire a first block height of a consensus node before sending a verification request to the consensus node, where the first block height is used to indicate the position number of the block currently held by the consensus node in the blockchain;

[0232] A third acquisition unit, configured to acquire a verification request before sending the verification request to the consensus node when the first block height is greater than a second block height of a lightweight node, where the second block height is used to indicate the position number of the block currently held by the lightweight node in the blockchain.

[0233] For specific embodiments, reference may be made to the examples shown in the above verification method for blockchain transactions, and details are not described herein again.

[0234] As an optional solution, the apparatus further includes:

[0235] A fourth acquisition unit, configured to acquire a first hash value set including N random values before sending a verification request to the consensus node, where the verification request carries the first hash value set, and N is a natural number;

[0236] A fifth acquisition unit, configured to acquire a requested block height according to the second block height and the first block height before sending the verification request to the consensus node;

[0237] Wherein, the verification request carries the requested block height, the verification data is the data in the transaction data that matches the first hash value set, the transaction data is the blockchain data corresponding to the target block, and the target block is the block determined by the consensus node from the block currently held by the consensus node and matching the requested block height.

[0238] Specific embodiments may refer to the examples shown in the above blockchain transaction verification method, and will not be elaborated herein in this example.

[0239] As an alternative solution, the apparatus further includes:

[0240] A sixth acquisition unit, configured to, before acquiring the verification data returned by the consensus node, when the verification request is a subscription verification request and the consensus node currently holds a new block, acquire a second hash value set returned by the consensus node and including K random values, where the subscription verification request is used to request verification when the consensus node currently holds a new block, the second hash value set is a hash value set obtained by the consensus node using the block hash value corresponding to the new block as a random number seed, and K is a natural number;

[0241] A seventh acquisition unit, configured to, before acquiring the verification data returned by the consensus node, acquire a third hash value set including P random values, where P is a natural number;

[0242] An operation unit, configured to, before acquiring the verification data returned by the consensus node, perform an addition modulo operation on the second hash value set and the third hash value set to obtain a target hash value set;

[0243] Wherein, the verification request carries the target hash value set, the verification data is the data in the transaction data that matches the target hash value set, and the transaction data is the blockchain data corresponding to the new block.

[0244] Specific embodiments may refer to the examples shown in the above blockchain transaction verification method, and will not be elaborated herein in this example.

[0245] As an alternative solution, the first acquisition unit 1104 includes:

[0246] A second acquisition module, configured to acquire the verification data, Merkle root, and hash path of the first data volume returned by the consensus node, where the ratio between the first data volume and the second data volume of the transaction data is greater than or equal to a preset ratio.

[0247] Specific embodiments may refer to the examples shown in the above blockchain transaction verification method, and will not be elaborated herein in this example.

[0248] According to another aspect of the embodiments of the present application, there is also provided another blockchain transaction verification apparatus for implementing the above blockchain transaction verification method. As Figure 12 shown, the apparatus includes:

[0249] An eighth acquisition unit 1202, configured to acquire a verification request sent by a lightweight node, where the verification request is a request triggered by transaction data associated with the lightweight node and used to request verification of the existence of the transaction data in the blockchain. The lightweight node is a lightweight node in the blockchain that is used to store non-complete blockchain data. The consensus node in the blockchain is a full-weight node that is used to store complete blockchain data. The complete blockchain data includes transaction data. The lightweight node and the consensus node are mutually associated;

[0250] A ninth acquisition unit 1204, configured to acquire a verification information set in response to the verification request, where the complete blockchain data includes the verification information set. The verification information set includes verification data in the transaction data, a hash path adjacent to the verification data on the Merkle tree, and the Merkle root of the Merkle tree. The Merkle tree is composed of hash paths matched by each data in the transaction data. The Merkle root is a hash value result obtained by performing operations on each data on the Merkle tree according to the matched hash path;

[0251] A second sending unit 1206, configured to send the verification data to the lightweight node, and the lightweight node uses the verification data, the Merkle root, and the adjacent hash path to verify the existence of the verification data on the Merkle tree to obtain a verification result. When the verification result indicates that the verification data effectively exists on the Merkle tree, the lightweight node determines that the transaction data effectively exists in the blockchain.

[0252] For specific embodiments, reference may be made to the examples shown in the above blockchain transaction verification method, and the examples are not elaborated herein.

[0253] As an optional solution, the ninth acquisition unit 1204 includes:

[0254] A third acquisition module, configured to, when the verification request is a subscription verification request and the consensus node currently holds a new block, use the block hash value corresponding to the new block as a random number seed, and use the random number seed to acquire a fourth hash value set including M random numerical values, where the subscription verification request is used to request verification when the consensus node currently holds a new block, and M is a natural number;

[0255] A fourth acquisition module, configured to determine verification data matching the fourth hash value set from the transaction data.

[0256] For specific embodiments, reference may be made to the examples shown in the above blockchain transaction verification method, and the examples are not elaborated herein.

[0257] According to another aspect of the embodiments of the present application, an electronic device for implementing the above blockchain transaction verification method is further provided. The electronic device may but is not limited to be Figure 1The user equipment 102 or the server 112 shown in the figure. In this embodiment, the electronic device is taken as an example of the user equipment 102 for illustration. Further, as Figure 13 shown, the electronic device includes a memory 1302 and a processor 1304. A computer program is stored in the memory 1302, and the processor 1304 is configured to execute the steps in any of the above method embodiments through the computer program.

[0258] Optionally, in this embodiment, the above electronic device may be at least one network device among multiple network devices in a computer network.

[0259] Optionally, in this embodiment, the above processor may be configured to execute the following steps through a computer program:

[0260] S6-1, when a verification request triggered by transaction data associated with a light node is obtained, send the verification request to a consensus node, where the verification request is used to request verification of the existence of the transaction data in the blockchain. The light node is a lightweight node in the blockchain that is used to store non-complete blockchain data, and the consensus node is a full-weight node in the blockchain that is used to store complete blockchain data. The complete blockchain data includes transaction data, and the light node and the consensus node are associated with each other;

[0261] S6-2, obtain a verification information set returned by the consensus node, where the verification information set includes verification data in the transaction data, a hash path adjacent to the verification data on the Merkle tree, and the Merkle root of the Merkle tree. The Merkle tree is composed of hash paths matched by each data in the transaction data, and the Merkle root is the hash value result obtained by combining operations on each data on the Merkle tree according to the matched hash paths;

[0262] S6-3, use the verification data, the Merkle root, and the adjacent hash path to verify the existence of the verification data on the Merkle tree to obtain a verification result;

[0263] S6-4, when the verification result indicates that the verification data exists effectively on the Merkle tree, determine that the transaction data exists effectively in the blockchain. Or,

[0264] S7-1, obtain a verification request sent by the light node, where the verification request is a request triggered by transaction data associated with the light node and is used to request verification of the existence of the transaction data in the blockchain. The light node is a lightweight node in the blockchain that is used to store non-complete blockchain data, and the consensus node in the blockchain is a full-weight node that is used to store complete blockchain data. The complete blockchain data includes transaction data, and the light node and the consensus node are associated with each other;

[0265] S7-2. In response to a verification request, obtain a verification information set. Among them, the complete blockchain data includes the verification information set. The verification information set includes verification data in the transaction data, the adjacent hash path of the verification data on the Merkle tree, and the Merkle root of the Merkle tree. The Merkle tree is composed of hash paths matching each data in the transaction data. The Merkle root is the hash value result obtained by operating on each data on the Merkle tree according to the matching hash path.

[0266] S7-3. Send the verification data to the light node, and the light node uses the verification data, the Merkle root, and the adjacent hash path to verify the existence of the verification data on the Merkle tree to obtain a verification result. When the verification result indicates that the verification data exists effectively on the Merkle tree, the light node determines that the transaction data exists effectively in the blockchain.

[0267] Optionally, those of ordinary skill in the art can understand that Figure 13 the structure shown is only schematic Figure 13 and does not limit the structure of the above-mentioned electronic device. For example, the electronic device may further include more or fewer components (such as a network interface, etc.) than those shown Figure 13 in the figure, or have a different configuration from that shown Figure 13 in the figure.

[0268] Among them, the memory 1302 can be used to store software programs and modules, such as the program instructions / modules corresponding to the verification method and device of blockchain transactions in the embodiments of the present application. The processor 1304 executes various functional applications and data processing by running the software programs and modules stored in the memory 1302, that is, implements the above-mentioned verification method of blockchain transactions. The memory 1302 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memories, or other non-volatile solid-state memories. In some instances, the memory 1302 may further include a memory remotely set relative to the processor 1304, and these remote memories can be connected to the electronic device through a network. Examples of the above network include but are not limited to the Internet, enterprise intranets, local area networks, mobile communication networks, and their combinations. Among them, the memory 1302 can specifically but not limitedly be used to store information such as transaction data, verification information sets, and verification results. As an example, as Figure 13 shown, the above-mentioned memory 1302 may include but are not limited to the first sending unit 1102, the first obtaining unit 1104, the verification unit 1106, and the determination unit 1108 in the verification device of the above-mentioned blockchain transaction; or, the eighth obtaining unit 1202, the ninth obtaining unit 1204, and the second sending unit 1206. In addition, it may further include but are not limited to other module units in the verification device of the above-mentioned blockchain transaction, which will not be elaborated in this example.

[0269] Optionally, the above-mentioned transmission device 1306 is used to receive or send data via a network. Specific examples of the above-mentioned network may include a wired network and a wireless network. In one example, the transmission device 1306 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices and routers through a network cable, so as to communicate with the Internet or a local area network. In one example, the transmission device 1306 is a Radio Frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0270] In addition, the above-mentioned electronic device further includes: a display 1308, which is used to display information such as the above-mentioned transaction data, verification information set, and verification result; and a connection bus 1310, which is used to connect each module component in the above-mentioned electronic device.

[0271] In other embodiments, the above-mentioned user equipment or server can be a node in a distributed system. Among them, the distributed system can be a blockchain system, and the blockchain system can be a distributed system formed by connecting the multiple nodes in the form of network communication. Among them, the nodes can form a peer-to-peer network, and any form of computing device, such as an electronic device such as a server or a user equipment, can become a node in the blockchain system by joining the peer-to-peer network.

[0272] According to one aspect of the present application, there is provided a computer program product, which includes a computer program / instructions, and the computer program / instructions include program codes for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part, and / or installed from a removable medium. When the computer program is executed by the central processing unit, it executes various functions provided by the embodiments of the present application.

[0273] The serial numbers of the above-mentioned embodiments of the present application are only for description and do not represent the advantages or disadvantages of the embodiments.

[0274] It should be noted that the computer system of the electronic device is only an example and should not bring any limitations to the functions and usage scopes of the embodiments of the present application.

[0275] The computer system includes a Central Processing Unit (CPU) which can perform various appropriate actions and processes according to the program stored in a Read-Only Memory (ROM) or the program loaded from a storage section into a Random Access Memory (RAM). In the random access memory, various programs and data required for system operation are also stored. The central processing unit, the read-only memory, and the random access memory are connected to each other via a bus. An Input / Output interface (I / O interface) is also connected to the bus.

[0276] The following components are connected to the input / output interface: an input section including a keyboard, a mouse, etc.; an output section including a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), etc. and a speaker, etc.; a storage section including a hard disk, etc.; and a communication section including a network interface card such as a local area network card, a modem, etc. The communication section performs communication processing via a network such as the Internet. A drive is also connected to the input / output interface as required. A removable medium such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc. is installed on the drive as required so that a computer program read from it can be installed into the storage section as required.

[0277] In particular, according to an embodiment of the present application, the processes described in each method flow chart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product which includes a computer program carried on a computer-readable medium, and the computer program contains program codes for executing the method shown in the flow chart. In such an embodiment, the computer program can be downloaded and installed from a network through the communication section, and / or installed from a removable medium. When the computer program is executed by the central processing unit, various functions defined in the system of the present application are executed.

[0278] According to one aspect of the present application, there is provided a computer-readable storage medium, and a processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions so that the computer device executes the methods provided in the above various optional implementation manners.

[0279] Optionally, in this embodiment, the above computer-readable storage medium may be configured to store a computer program for executing the following steps:

[0280] S6-1. When a verification request is triggered for the transaction data associated with a lightweight node, send the verification request to a consensus node, where the verification request is used to request verification of the existence of the transaction data in the blockchain. The lightweight node is a lightweight node in the blockchain that stores non-complete blockchain data, and the consensus node is a full-scale node in the blockchain that stores complete blockchain data. The complete blockchain data includes transaction data, and the lightweight node and the consensus node are interconnected;

[0281] S6-2. Obtain the verification information set returned by the consensus node, where the verification information set includes the verification data in the transaction data, the adjacent hash path of the verification data on the Merkle tree, and the Merkle root of the Merkle tree. The Merkle tree is composed of the hash paths matched by each data in the transaction data, and the Merkle root is the hash value result obtained by combining operations on each data on the Merkle tree according to the matched hash path;

[0282] S6-3. Use the verification data, the Merkle root, and the adjacent hash path to verify the existence of the verification data on the Merkle tree to obtain a verification result;

[0283] S6-4. When the verification result indicates that the verification data exists effectively on the Merkle tree, determine that the transaction data exists effectively in the blockchain. Or,

[0284] S7-1. Obtain the verification request sent by the lightweight node, where the verification request is a request triggered for the transaction data associated with the lightweight node and is used to request verification of the existence of the transaction data in the blockchain. The lightweight node is a lightweight node in the blockchain that stores non-complete blockchain data, and the consensus node in the blockchain is a full-scale node that stores complete blockchain data. The complete blockchain data includes transaction data, and the lightweight node and the consensus node are interconnected;

[0285] S7-2. In response to the verification request, obtain the verification information set, where the complete blockchain data includes the verification information set. The verification information set includes the verification data in the transaction data, the adjacent hash path of the verification data on the Merkle tree, and the Merkle root of the Merkle tree. The Merkle tree is composed of the hash paths matched by each data in the transaction data, and the Merkle root is the hash value result obtained by performing operations on each data on the Merkle tree according to the matched hash path;

[0286] S7-3. Send the verification data to the lightweight node, and let the lightweight node use the verification data, the Merkle root, and the adjacent hash path to verify the existence of the verification data on the Merkle tree to obtain a verification result. When the verification result indicates that the verification data exists effectively on the Merkle tree, let the lightweight node determine that the transaction data exists effectively in the blockchain.

[0287] Optionally, in the embodiments of the present application, the term "module" or "unit" refers to a computer program with a predetermined function or a part of a computer program, which works with other related parts to achieve a predetermined goal, and can be fully or partially implemented by using software, hardware (such as a processing circuit or a memory), or a combination thereof. Similarly, one processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be a part of an overall module or unit that includes the function of that module or unit.

[0288] Optionally, in this embodiment, those of ordinary skill in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing the relevant hardware of an electronic device through a program, and this program can be stored in a computer-readable storage medium. The storage medium can include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disc, etc.

[0289] The serial numbers of the above embodiments of the present application are only for description and do not represent the advantages or disadvantages of the embodiments.

[0290] If the integrated unit in the above embodiments is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in the above computer-readable storage medium. Based on this understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing one or more computer devices (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods of the various embodiments of the present application.

[0291] In the above embodiments of the present application, the descriptions of the various embodiments have their own emphases. For the parts not detailed in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0292] In the several embodiments provided by the present application, it should be understood that the disclosed user equipment can be implemented in other ways. Among them, the device embodiments described above are only illustrative. For example, the division of units is only a logical function division. In actual implementation, there can be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces. The indirect couplings or communication connections of units or modules can be in an electrical or other form.

[0293] The unit described as a separation component may or may not be physically separated, and the component displayed as a unit may or may not be a physical unit, that is, it may be located in one place or may be distributed across multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0294] In addition, each functional unit in various embodiments of the present application may be integrated in a processing unit, may exist separately as individual physical units, or two or more units may be integrated in one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

[0295] The above are only the preferred embodiments of the present application. It should be noted that for those of ordinary skill in the art, without departing from the principle of the present application, several improvements and refinements can be made, and these improvements and refinements should also be regarded as the protection scope of the present application.

Claims

1. A method for verifying blockchain transactions, characterized in that, Including: When a verification request is triggered for transaction data associated with a light node, sending the verification request to a consensus node, where the verification request is used to request verification of the existence of the transaction data in the blockchain, and the light node and the consensus node are associated with each other; Obtaining a verification information set returned by the consensus node, where the verification information set includes verification data in the transaction data, a hash path adjacent to the verification data on a Merkle tree, and a Merkle root of the Merkle tree; Using the verification data, the Merkle root, and the adjacent hash path to verify the existence of the verification data on the Merkle tree to determine that the transaction data effectively exists in the blockchain.

2. The method according to claim 1, wherein The obtaining the verification data returned by the consensus node includes: Obtaining the verification data, the Merkle root, and the hash path returned by the consensus node; where When the hash path matching the verification data on the Merkle tree includes a first hash value, the adjacent hash path includes a second hash value adjacent to the first hash value on the Merkle tree; When the hash path matching the verification data on the Merkle tree includes the first hash value and a first combined hash value, the adjacent hash path includes the second hash value and a second combined hash value, the first combined hash value is a hash value obtained by a combined operation of the first hash value and the second hash value, and the second combined hash value is a hash value adjacent to the first combined hash value on the Merkle tree; When the hash path matching the verification data on the Merkle tree includes the first hash value, the first combined hash value, and a first target hash value, the adjacent hash path includes the second hash value, the second combined hash value, and a second target hash value, the first target hash value is a hash value obtained by a combined operation of the first combined hash value and the second combined hash value, and the second target hash value is a hash value adjacent to the first target hash value on the Merkle tree.

3. The method according to claim 2, characterized in that, The using the verification data, the Merkle root, and the adjacent hash path to verify the existence of the verification data on the Merkle tree to obtain a verification result includes: When the adjacent hash path includes the second hash value, performing a combined operation on the first hash value and the second hash value to obtain a first operation result, where when the first operation result is consistent with the Merkle root, the verification result indicates that the verification data effectively exists on the Merkle tree; When the adjacent hash path includes the second hash value and the second combined hash value, performing a combined operation on the first combined hash value and the second combined hash value to obtain a second operation result, where when the second operation result is consistent with the Merkle root, the verification result indicates that the verification data effectively exists on the Merkle tree; In a case where the adjacent hash paths include the second hash value, the second combined hash value, and the second target hash value, a combined operation is performed on the first target hash value and the second target hash value to obtain a third operation result. Wherein, in a case where the third operation result is consistent with the Merkle root, the verification result indicates that the verification data validly exists on the Merkle tree.

4. The method according to claim 1, wherein Before sending the verification request to the consensus node, the method further includes: Obtaining a first block height of the consensus node, where the first block height is used to indicate a position number of the block currently held by the consensus node in the blockchain; In a case where the first block height is greater than a second block height of the light node, obtaining the verification request, where the second block height is used to indicate a position number of the block currently held by the light node in the blockchain.

5. The method according to claim 4, characterized in that, Before sending the verification request to the consensus node, the method further includes: Obtaining a first hash value set including N random values, where the verification request carries the first hash value set, and N is a natural number; Obtaining a requested block height according to the second block height and the first block height; Wherein, the verification request carries the requested block height, the verification data is data in the transaction data that matches the first hash value set, the transaction data is blockchain data corresponding to a target block, and the target block is a block determined by the consensus node from the block currently held by the consensus node and matching the requested block height.

6. The method according to claim 1, wherein Before obtaining the verification data returned by the consensus node, the method further includes: In a case where the verification request is a subscription verification request and the consensus node currently holds a new block, obtaining a second hash value set including K random values returned by the consensus node, where the subscription verification request is used to request verification when the consensus node currently holds the new block, and the second hash value set is a hash value set obtained by the consensus node using the block hash value corresponding to the new block as a random number seed, and K is a natural number; Obtaining a third hash value set including P random values, where P is a natural number; Performing an addition modulo operation on the second hash value set and the third hash value set to obtain a target hash value set; Wherein, the verification request carries the target hash value set, and the verification data is data in the transaction data that matches the target hash value set, and the transaction data is blockchain data corresponding to the new block.

7. The method according to any one of claims 1 to 6, characterized in that The obtaining the verification data returned by the consensus node includes: Obtaining verification data with a first data volume, the Merkle root, and the hash path returned by the consensus node, where a ratio between the first data volume and a second data volume of the transaction data is greater than or equal to a preset ratio.

8. A verification method for blockchain transactions, characterized in that, Including: Obtain a verification request sent by a light node, where the verification request is a request triggered by transaction data associated with the light node and used to request verification of the existence of the transaction data in the blockchain, and the light node and the consensus node are associated with each other; Respond to the verification request to obtain a verification information set, where the verification information set includes verification data in the transaction data, a hash path adjacent to the verification data on the Merkle tree, and the Merkle root of the Merkle tree; Send the verification data to the light node, and the light node uses the verification data, the Merkle root, and the adjacent hash path to verify the existence of the verification data on the Merkle tree, and the light node determines the effective existence of the transaction data in the blockchain.

9. The method according to claim 8, wherein The obtaining of the verification data includes: When the verification request is a subscription verification request and the consensus node currently holds a new block, use the block hash value corresponding to the new block as a random number seed, and use the random number seed to obtain a fourth hash value set including M random numerical values, where the subscription verification request is used to request verification when the consensus node currently holds the new block, and M is a natural number; Determine the verification data matching the fourth hash value set from the transaction data.

10. A verification device for blockchain transactions, characterized in that, Includes: A first sending unit, configured to send the verification request to a consensus node when a verification request triggered by transaction data associated with a light node is obtained, where the verification request is used to request verification of the existence of the transaction data in the blockchain, and the light node and the consensus node are associated with each other; A first obtaining unit, configured to obtain a verification information set returned by the consensus node, where the verification information set includes verification data in the transaction data, a hash path adjacent to the verification data on the Merkle tree, and the Merkle root of the Merkle tree; A verification unit, configured to use the verification data, the Merkle root, and the adjacent hash path to verify the existence of the verification data on the Merkle tree to determine the effective existence of the transaction data in the blockchain.

11. A verification device for blockchain transactions, characterized in that, Includes: An eighth obtaining unit, configured to obtain a verification request sent by a light node, where the verification request is a request triggered by transaction data associated with the light node and used to request verification of the existence of the transaction data in the blockchain, and the light node and the consensus node are associated with each other; A ninth obtaining unit, configured to respond to the verification request to obtain a verification information set, where the verification information set includes verification data in the transaction data, a hash path adjacent to the verification data on the Merkle tree, and the Merkle root of the Merkle tree; A second sending unit, configured to send the verification data to the light node, and the light node uses the verification data, the Merkle root, and the adjacent hash path to verify the existence of the verification data on the Merkle tree, and the light node determines the effective existence of the transaction data in the blockchain.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein the program, when run by an electronic device, executes the method described in any one of claims 1 to 7, or 8 to 9.

13. A computer program product, comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by a processor, the steps of the method described in any one of claims 1 to 7, or 8 to 9 are implemented.

14. An electronic device, comprising a memory and a processor, characterized in that, A computer program is stored in the memory, and the processor is configured to execute the method described in any one of claims 1 to 7, or 8 to 9 through the computer program.

Images