Blockchain-based transaction verification method, device, and blockchain system

Abstract

The present invention provides a blockchain-based transaction verification method, device, and blockchain system, relating to the financial and blockchain technology fields. The method comprises: sending a transaction verification request to a full node corresponding to a transaction to be verified; receiving transaction verification information returned by the full node in response to the transaction verification request, the transaction verification information including a Bloom filter bitmap, a Bloom filter hash method, a Merkle tree root, and a Merkle path result corresponding to the transaction to be verified; and obtaining a transaction verification result corresponding to the transaction to be verified based on the Bloom filter hash method, Bloom filter bitmap, Merkle path result, and Merkle tree root in the transaction verification information returned by the full node. This application expands Merkle proofs based on Bloom filters, overcomes the drawback of existing Merkle proofs that they can only verify affirmative propositions, and improves the accuracy of transaction verification.

Description

Technical Field

[0001] This application relates to the fields of finance and blockchain technology, and specifically to a blockchain-based transaction verification method, device, and blockchain system. Background Art

[0002] Currently, blockchains generally use Merkle proofs to verify transaction validity. Given a Merkle path, the hash of each transaction is calculated pairwise along this path to obtain a Merkle root. This Merkle root is recorded in the block header of each blockchain node. When a light node needs to prove that a transaction exists within a blockchain node, the full node only needs to provide the Merkle path in the Merkle tree. The light node then recalculates the hash of the given Merkle path to obtain the Merkle root. If the verified Merkle root matches the Merkle root stored in the block header, the transaction is confirmed to exist.

[0003] The advantage of Merkle proofs is that they reduce storage pressure and communication overhead on light nodes, speeding up payment verification. However, Merkle proofs also have a limitation: if a full node maliciously returns that a transaction does not exist, the full node will not provide a Merkle path, and the light node will be unable to determine whether the transaction actually exists. In other words, Merkle proofs can only verify affirmative statements, not negative ones. Summary of the Invention

[0004] In order to solve the problems in the existing technology, this application provides a blockchain-based transaction verification method, device and blockchain system, which relate to the financial field and blockchain technology field.

[0005] First, this application provides a blockchain-based transaction verification method from the perspective of a light node, including:

[0006] Send a transaction verification request to the full node corresponding to the transaction to be verified;

[0007] Receiving transaction verification information returned by the full node in response to the transaction verification request, the transaction verification information including a Bloom filter bitmap, a Bloom filter hash method, a Merkle tree root, and a Merkle path result corresponding to the transaction to be verified;

[0008] Obtaining a Bloom filter verification result corresponding to the transaction to be verified according to the Bloom filter hash method and the Bloom filter bitmap;

[0009] Obtaining a Merkle proof result corresponding to the transaction to be verified according to the Merkle path result and the Merkle tree root;

[0010] A transaction verification result corresponding to the transaction to be verified is obtained according to the Bloom filter verification result and the Merkle proof result.

[0011] In one embodiment, obtaining the Merkle proof result corresponding to the transaction to be verified based on the Merkle path result and the Merkle tree root includes:

[0012] Determine whether a Merkle path exists in the Merkle path result; if the Merkle path does not exist, the Merkle proof result is that the transaction does not exist;

[0013] If a Merkle path exists, the hash value corresponding to the transaction to be verified is calculated based on the Merkle path;

[0014] The Merkle proof result is obtained based on whether the hash value is consistent with the Merkle tree root; if they are consistent, the Merkle proof result is that the transaction exists; if they are inconsistent, the Merkle proof result is that the transaction does not exist.

[0015] In one embodiment, obtaining a Bloom filter verification result corresponding to the transaction to be verified according to the Bloom filter hash method and the Bloom filter bitmap includes:

[0016] Performing a hash operation on the transaction to be verified according to the Bloom filter hashing method to obtain a Bloom filter bitmap value corresponding to the transaction to be verified;

[0017] A Bloom filter verification result corresponding to the transaction to be verified is obtained according to the Bloom filter bitmap value and the Bloom filter bitmap.

[0018] In one embodiment, obtaining the Bloom filter verification result corresponding to the transaction to be verified according to the Bloom filter bitmap value and the Bloom filter bitmap includes:

[0019] Performing a bitwise AND calculation on the Bloom filter bitmap value and the Bloom filter bitmap to obtain a bitwise AND result;

[0020] Determine whether the bitwise AND result is consistent with the Bloom filter bitmap;

[0021] If they are consistent, the Bloom filter verification result is that the transaction exists;

[0022] If they are inconsistent, the Bloom filter verification result is that the transaction does not exist.

[0023] In one embodiment, obtaining the transaction verification result corresponding to the transaction to be verified according to the Bloom filter verification result and the Merkle proof result includes:

[0024] If both the Merkle proof result and the Bloom filter verification result indicate that the transaction exists, then the transaction verification result indicates that the transaction exists;

[0025] If the Bloom filter verification result is that the transaction does not exist, then the transaction verification result is that the transaction does not exist.

[0026] In one embodiment, obtaining the transaction verification result corresponding to the transaction to be verified according to the Bloom filter verification result and the Merkle proof result further includes:

[0027] If the Bloom filter verification result is that the transaction exists and if the Merkle proof result is that the transaction does not exist, determining an actual false positive rate of the Bloom filter based on the Bloom filter verification result and the Merkle proof result;

[0028] Whether the full node is trustworthy is determined based on the actual false positive rate and the theoretical false positive rate of the Bloom filter; if trustworthy, the transaction verification result is that the transaction does not exist; if not trustworthy, the transaction verification result is that the transaction exists.

[0029] In one embodiment, determining the actual false positive rate of the Bloom filter according to the Bloom filter verification result and the Merkle proof result includes:

[0030] Counting the number of successes and false positives of the Bloom filter, where the number of successes is the number of times both the Merkle proof result and the Bloom filter verification result indicate that the transaction exists, and the number of false positives is the number of times the Merkle proof result indicates that the transaction does not exist and the Bloom filter verification result indicates that the transaction exists;

[0031] The ratio of the number of false positives to the number of successful positives is calculated to obtain an actual false positive rate of the Bloom filter.

[0032] In one embodiment, determining whether the full node is trustworthy according to the actual false positive rate and the theoretical false positive rate of the Bloom filter includes:

[0033] When the actual false positive rate is greater than the theoretical false positive rate, the full node is untrustworthy; otherwise, the full node is trustworthy.

[0034] Secondly, this application provides another blockchain-based transaction verification method from the perspective of a full node, including:

[0035] Receive the transaction verification request corresponding to the transaction to be verified sent by the light node;

[0036] Generate transaction verification information according to the transaction verification request, and return the transaction verification information to the light node, so that the light node obtains the transaction verification result corresponding to the transaction to be verified according to the Bloom filter hash method, Bloom filter bitmap, Merkle path result and Merkle tree root in the transaction verification information.

[0037] In a third aspect, the present application provides a blockchain system, comprising:

[0038] Consensus nodes, used to package Bloom filter hashing methods;

[0039] a full node, configured to obtain, from the consensus node, the Bloom filter hash method and the Bloom filter bitmap corresponding to all transactions of the full node; and upon receiving a transaction verification request corresponding to a transaction to be verified from a light node, generate transaction verification information according to the transaction verification request, and return the transaction verification information to the light node;

[0040] The light node is used to send a transaction verification request to the full node, and obtain the transaction verification result corresponding to the transaction to be verified based on the Bloom filter hash method, Bloom filter bitmap, Merkle path result and Merkle tree root in the transaction verification information returned by the full node.

[0041] In one embodiment, the light node is specifically used for:

[0042] Obtaining a Bloom filter verification result corresponding to the transaction to be verified according to the Bloom filter hash method and the Bloom filter bitmap;

[0043] Obtaining a Merkle proof result corresponding to the transaction to be verified according to the Merkle path result and the Merkle tree root; and

[0044] A transaction verification result corresponding to the transaction to be verified is obtained according to the Bloom filter verification result and the Merkle proof result.

[0045] In one embodiment, the consensus node is further used to:

[0046] Traverse all transactions according to the Bloom filter hash method to obtain the Bloom filter bitmap value corresponding to each transaction;

[0047] The Bloom filter bitmap values ​​corresponding to each transaction are bitwise ANDed to obtain the Bloom filter bitmap.

[0048] In a fourth aspect, the present application provides a blockchain-based transaction verification method, which is applied to any blockchain system provided in the present application, and the method includes:

[0049] The light node sends a transaction verification request to the full node corresponding to the transaction to be verified;

[0050] The full node generates transaction verification information based on the transaction verification request and returns the transaction verification information to the light node, wherein the transaction verification information includes the Bloom filter bitmap, Bloom filter hash method, Merkle tree root, and Merkle path result corresponding to the transaction to be verified; the Bloom filter bitmap is calculated by the consensus node based on the Bloom filter hash method and each transaction in the full node;

[0051] The light node obtains a transaction verification result corresponding to the transaction to be verified according to the Bloom filter hash method, the Bloom filter bitmap, the Merkle path result, and the Merkle tree root.

[0052] In one embodiment, the light node obtains the transaction verification result corresponding to the transaction to be verified according to the Bloom filter hash method, the Bloom filter bitmap, the Merkle path result, and the Merkle tree root, including:

[0053] The light node obtains a Bloom filter verification result corresponding to the transaction to be verified according to the Bloom filter hash method and the Bloom filter bitmap;

[0054] The light node obtains the Merkle proof result corresponding to the transaction to be verified according to the Merkle path result and the Merkle tree root; and

[0055] The light node obtains a transaction verification result corresponding to the transaction to be verified according to the Bloom filter verification result and the Merkle proof result.

[0056] In a fifth aspect, the present application provides a blockchain-based transaction verification device, which corresponds to the blockchain-based transaction verification method provided in the present application from the perspective of a light node, and the device includes:

[0057] The transaction verification request sending module is used to send a transaction verification request to the full node corresponding to the transaction to be verified;

[0058] a transaction verification information receiving module, configured to receive transaction verification information returned by the full node in response to the transaction verification request, wherein the transaction verification information includes a Bloom filter bitmap, a Bloom filter hash method, a Merkle tree root, and a Merkle path result corresponding to the transaction to be verified;

[0059] a Bloom filter verification result generation module, configured to obtain a Bloom filter verification result corresponding to the transaction to be verified according to the Bloom filter hash method and the Bloom filter bitmap;

[0060] A Merkle proof result generation module, configured to obtain a Merkle proof result corresponding to the transaction to be verified based on the Merkle path result and the Merkle tree root;

[0061] The transaction verification result generating module is used to obtain the transaction verification result corresponding to the transaction to be verified according to the Bloom filter verification result and the Merkle proof result.

[0062] In one embodiment, the Merkle proof result generation module includes:

[0063] a Merkle path determination unit, configured to determine whether a Merkle path exists in the Merkle path result;

[0064] a hash value calculation unit, configured to calculate a hash value corresponding to the transaction to be verified according to the Merkle path when the Merkle path exists;

[0065] a hash value comparison unit, configured to determine whether the hash value is consistent with the Merkle tree root;

[0066] The Merkle proof result generating unit is configured to obtain the Merkle proof result based on whether a Merkle path exists or whether the hash value is consistent with the Merkle tree root; if the Merkle path does not exist, the Merkle proof result is that the transaction does not exist; if the hash value is consistent with the Merkle tree root, the Merkle proof result is that the transaction exists; if the hash value is inconsistent with the Merkle tree root, the Merkle proof result is that the transaction does not exist.

[0067] In one embodiment, the Bloom filter verification result generation module includes:

[0068] a Bloom filter bitmap value calculation unit, configured to perform a hash operation on the transaction to be verified according to the Bloom filter hash method to obtain a Bloom filter bitmap value corresponding to the transaction to be verified;

[0069] The Bloom filter verification result generating unit is configured to obtain a Bloom filter verification result corresponding to the transaction to be verified according to the Bloom filter bitmap value and the Bloom filter bitmap.

[0070] In one embodiment, the Bloom filter verification result generation unit is specifically configured to:

[0071] Performing a bitwise AND calculation on the Bloom filter bitmap value and the Bloom filter bitmap to obtain a bitwise AND result;

[0072] Determine whether the bitwise AND result is consistent with the Bloom filter bitmap;

[0073] If they are consistent, the Bloom filter verification result is that the transaction exists;

[0074] If they are inconsistent, the Bloom filter verification result is that the transaction does not exist.

[0075] In one embodiment, the transaction verification result generation module includes:

[0076] a false positive rate calculation unit, configured to determine an actual false positive rate of the Bloom filter based on the Bloom filter verification result and the Merkle proof result when the Bloom filter verification result indicates that the transaction exists and the Merkle proof result indicates that the transaction does not exist;

[0077] A full-node trust judgment unit, configured to determine whether the full-node is trustworthy based on the actual false positive rate and the theoretical false positive rate of the Bloom filter;

[0078] The transaction verification result generating unit is configured to, when both the Merkle proof result and the Bloom filter verification result indicate that the transaction exists, determine the transaction verification result as the existence of the transaction; when the Bloom filter verification result indicates that the transaction does not exist, determine the transaction verification result as the non-existence of the transaction; when the Bloom filter verification result indicates that the transaction exists and the Merkle proof result indicates that the transaction does not exist, if the full node is trustworthy, determine the transaction verification result as the non-existence of the transaction; if the full node is untrustworthy, determine the transaction verification result as the existence of the transaction.

[0079] In one embodiment, the error rate calculation unit is specifically used to:

[0080] Counting the number of successes and false positives of the Bloom filter, where the number of successes is the number of times both the Merkle proof result and the Bloom filter verification result indicate that the transaction exists, and the number of false positives is the number of times the Merkle proof result indicates that the transaction does not exist and the Bloom filter verification result indicates that the transaction exists;

[0081] The ratio of the number of false positives to the number of successful positives is calculated to obtain an actual false positive rate of the Bloom filter.

[0082] In a sixth aspect, the present application provides another blockchain-based transaction verification device, corresponding to the blockchain-based transaction verification method provided in the present application from the perspective of a full node, the device comprising:

[0083] The transaction verification request receiving module is used to receive the transaction verification request corresponding to the transaction to be verified sent by the light node;

[0084] A transaction verification information generation module is used to generate transaction verification information according to the transaction verification request and return the transaction verification information to the light node, so that the light node obtains the transaction verification result corresponding to the transaction to be verified according to the Bloom filter hash method, Bloom filter bitmap, Merkle path result and Merkle tree root in the transaction verification information.

[0085] The blockchain-based transaction verification method, device, and blockchain system described in this application utilize Bloom filters to extend Merkle proofs, overcoming the limitation of existing Merkle proofs, which can only verify affirmative propositions. The combination of the two can simultaneously verify both affirmative and negative propositions, improving the accuracy of transaction verification. Execution of this application only requires adding a small number of fields to the block header of blockchain nodes, without burdening the storage and network transmission of light nodes. BRIEF DESCRIPTION OF THE DRAWINGS

[0086] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0087] Figure 1 A schematic diagram of an application scenario applicable to this application.

[0088] Figure 2 A schematic diagram of the blockchain-based transaction verification method provided in this application.

[0089] Figure 3 Flowchart for obtaining the Merkle proof result provided for this application.

[0090] Figure 4 A structural diagram of the Merkle path provided in this application.

[0091] Figure 5 This is a schematic diagram of obtaining the Bloom filter verification result provided by this application.

[0092] Figures 6 to 9 A schematic diagram of the Bloom filter bitmap value of a transaction provided by this application.

[0093] Figure 10 A schematic diagram of the Bloom filter bitmap of a full node provided in this application.

[0094] Figure 11 Another schematic diagram of obtaining Bloom filter verification results provided by this application.

[0095] Figure 12 and Figure 13 A schematic diagram of the Bloom filter bitmap values ​​corresponding to the transactions to be verified provided in this application.

[0096] Figure 14 and Figure 15 Schematic diagram of the bitwise AND result corresponding to the transaction to be verified provided by this application.

[0097] Figure 16 A schematic diagram of obtaining transaction verification results provided for this application.

[0098] Figure 17 This is a schematic diagram of obtaining the actual misjudgment rate of the Bloom filter provided in this application.

[0099] Figure 18 Another schematic diagram of the blockchain-based transaction verification method provided in this application.

[0100] Figure 19 Another schematic diagram of the blockchain-based transaction verification method provided in this application.

[0101] Figure 20 Schematic diagram of the blockchain-based transaction verification device provided in this application.

[0102] Figure 21 Another schematic diagram of the blockchain-based transaction verification device provided in this application.

[0103] Figure 22 Another schematic diagram of the blockchain-based transaction verification device provided in this application.

[0104] Figure 23 Another schematic diagram of the blockchain-based transaction verification device provided in this application.

[0105] Figure 24 Another schematic diagram of the blockchain-based transaction verification device provided in this application. DETAILED DESCRIPTION

[0106] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0107] In order to facilitate the public to understand the blockchain-based transaction verification method of this application, this application first provides an application scenario of the blockchain-based transaction verification method. An example of an application scenario of this application is as follows: Figure 1As shown, the scenario is a blockchain system, which includes three types of nodes, namely light node 1, full node 2 and consensus node 3. Among them, light node 1 only contains the block header data of full node 2. Unlike existing blockchain nodes, the block header of the consensus node of this application adds four fields on the basis of existing fields: the name of the Bloom filter hash method set, the ratio of the Bloom filter bitmap length m to the number of transactions n BitPreKey (hereinafter directly represented as BitPreKey), the number of hash methods k, and the Bloom filter bitmap. Correspondingly, when the full node 2 synchronizes the block data of the consensus node, the four fields of the Bloom filter hash method set name, BitPreKey, the number of hash methods k, and the Bloom filter bitmap will also be added to the block header of the full node 2. Therefore, the block header of full node 2 contains the following 8 fields: block number, previous block hash, Merkle tree root, transaction number n, Bloom filter hash method set name, BitPreKey and hash method number k, and Bloom filter bitmap. Among them, the first four fields are the fields originally in the block header of full node 2, and the last four fields are newly added fields.

[0108] Figure 1 In the blockchain system shown, there is at least one light node, full node, and consensus node. For ease of representation, Figure 1 The example of a light node, a full node, and a consensus node is used for illustration only, and this application is not limited to this.

[0109] In the first aspect, this application first starts from Figure 1 The blockchain-based transaction verification method of this application is explained from the perspective of light node 1 in the given application scenario. Please also refer to Figure 1 and Figure 2 , the blockchain-based transaction verification method includes the following steps:

[0110] Step S101: Send a transaction verification request to the full node corresponding to the transaction to be verified.

[0111] Step S102: Receive transaction verification information returned by the full node according to the transaction verification request, wherein the transaction verification information includes a Bloom filter bitmap, a Bloom filter hash method, a Merkle tree root, and a Merkle path result corresponding to the transaction to be verified.

[0112] The transaction verification request includes a request to download the block header of full node 2 and a request for the data required to verify the transaction. The block header of full node 2 contains the block number corresponding to the full node, the hash of the previous block, the Merkle root, the name of the Bloom filter hash method set, the number of transactions n, the BitPreKey, the number of hash methods k, and the Bloom filter bitmap. The data required to verify the transaction includes at least the Bloom filter bitmap and the Merkle path result. The Bloom filter hash method in step S102 can be obtained based on the Bloom filter hash method set name in the block header.

[0113] Step S103: Obtain a Bloom filter verification result corresponding to the transaction to be verified according to the Bloom filter hash method and the Bloom filter bitmap.

[0114] In this step, the transaction to be verified is hashed using the Bloom filter hashing method to obtain a sequence of numbers equal to the length of the Bloom filter bitmap. The Bloom filter verification result is obtained based on this sequence and the Bloom filter bitmap. The detailed steps will be described in the subsequent examples.

[0115] Step S104: Obtain a Merkle proof result corresponding to the transaction to be verified according to the Merkle path result and the Merkle tree root.

[0116] In this step, the transaction to be verified is hashed according to the Merkle path to obtain a hash value. The Merkle proof result is obtained based on this hash value and the Merkle tree root. The detailed steps will be described in the subsequent embodiments.

[0117] Step S105: Obtain a transaction verification result corresponding to the transaction to be verified according to the Bloom filter verification result and the Merkle proof result.

[0118] In this step, the Bloom filter verification results and the Merkle proof results are combined to determine whether the transaction to be verified exists. The specific determination steps will be described in the subsequent embodiments.

[0119] In this embodiment, step S103 and step S104 are actually in a parallel relationship. The order of execution of these two steps can be reversed. Here, the case where step S103 is executed first and then step S104 is executed. In actual application, step S104 can also be executed first and then step S103. Changing the execution order alone will not affect this application, so this application does not limit this.

[0120] This blockchain-based transaction verification method utilizes a Bloom filter to extend the Merkle proof, overcoming the limitation of existing Merkle proofs, which can only verify affirmative propositions. The combination of the two can verify both affirmative and negative propositions, improving the accuracy of transaction verification. This method only requires adding a small number of fields to the block header of blockchain nodes, without burdening the storage and network transmission of light nodes.

[0121] In one embodiment, if Figure 3 As shown, step S104, obtaining the Merkle proof result corresponding to the transaction to be verified based on the Merkle path result and the Merkle tree root, includes:

[0122] Step S1041, determining whether a Merkle path exists in the Merkle path result; if the Merkle path exists, executing step S1042; if the Merkle path does not exist, executing step S1045;

[0123] Step S1042: Calculate the hash value corresponding to the transaction to be verified according to the Merkle path;

[0124] Step S1043, determining whether the hash value is consistent with the Merkle tree root; if they are consistent, executing step S1044; if they are inconsistent, executing step S1045;

[0125] Step S1044: Determine the Merkle proof result as the existence of the transaction; then execute step S1046;

[0126] Step S1045: Determine the Merkle proof result as the non-existence of the transaction; then proceed to step S1046;

[0127] Step S1046: Output the Merkle proof result.

[0128] Specifically, in step S1041, the Merkle path result is returned from the full node to the light node. There are two possible scenarios for the Merkle path result: the first is the Merkle path corresponding to the transaction to be verified, which corresponds to the case where the Merkle path in step S1041 exists; the second is empty, which corresponds to the case where the Merkle path in step S1041 does not exist. When the Merkle path result is empty, it means that the full node cannot find the Merkle path corresponding to the transaction to be verified, or the full node has found the Merkle path corresponding to the transaction to be verified but maliciously returns an empty result. Regardless of whether the full node returns an empty result maliciously, as long as the full node returns an empty result, the light node will obtain a Merkle proof result that the transaction does not exist. Therefore, the result of the non-existence of the transaction obtained through the Merkle proof may be inaccurate.

[0129] Steps S1042 to S1045 are steps executed when determining whether a Merkle path exists in the Merkle path result, and are described here using an example:

[0130] Figure 4 is a schematic diagram of the Merkle path. Assume Figure 4 Transaction 1 is the transaction to be verified in this application, and transactions 2, 3, and 4 are other transactions in the full node. Then, the transaction to be verified is brought into the position of transaction 1 in the Merkle path, and the hash values ​​are calculated in pairs along the Merkle path. Finally, a hash value can be obtained, that is, Figure 4 "Hash 1-4" in the transaction, step S1042 is now completed; then it is determined whether "Hash 1-4" is consistent with the Merkle tree root (i.e., step S1043); if they are consistent, the Merkle proof result is determined to be the existence of the transaction; if they are inconsistent, the Merkle proof result is determined to be the non-existence of the transaction.

[0131] This embodiment describes in detail the process of determining the Merkle proof result based on the principle of Merkle proof.

[0132] In one embodiment, if Figure 5 As shown, step S103, obtaining a Bloom filter verification result corresponding to the transaction to be verified according to the Bloom filter hash method and the Bloom filter bitmap, includes:

[0133] Step S1031: performing a hash operation on the transaction to be verified according to the Bloom filter hashing method to obtain a Bloom filter bitmap value corresponding to the transaction to be verified;

[0134] Step S1032: Obtain a Bloom filter verification result corresponding to the transaction to be verified according to the Bloom filter bitmap value and the Bloom filter bitmap.

[0135] The Bloom filter bitmap is obtained by performing a hash operation on all transactions in the full node using the Bloom filter hash method synchronized from the consensus node. The calculation process is illustrated by the following example:

[0136] Assuming that there is a transaction key in the full node, there are three Bloom filter hash methods synchronized by the full node from the consensus node. The transaction key is hashed using hash methods hash1, hash2, and hash3 to obtain the first Bloom filter bitmap value corresponding to the transaction key, such as Figure 6 As shown; Use hash method hash2 to perform hash operation on the transaction key to obtain the second Bloom filter bitmap value corresponding to the transaction key, as shown Figure 7 As shown; Use hash method hash3 to perform hash operation on the transaction key to obtain the third Bloom filter bitmap value corresponding to the transaction key, as shown Figure 8 shown; then Figures 6 to 8 The three Bloom filter bitmap values ​​shown are bitwise ANDed to obtain the Bloom filter bitmap value corresponding to the transaction key, as shown in Figure 9 shown. Figures 6 to 8 The hash value in Figure 9 The Bloom filter bitmap values ​​in have the same length, which is 16 bits in this example. When there are multiple transactions with key1, key2, ..., keyn, the Bloom filter bitmap is the result of bitwise AND calculation of the Bloom filter bitmap values ​​of all transactions, for example Figure 10 It is understandable that when there is only one transaction key in the full node, the Bloom filter bitmap value corresponding to the transaction key is the Bloom filter bitmap of the full node.

[0137] The length m of the Bloom filter bitmap is related to the number of transactions n and BitPreKey, and can be expressed as m = n * BitPreKey, where n is the number of transactions and BitPreKey is the ratio of the Bloom filter bitmap length m to the number of transactions n, which is synchronized by the full node from the consensus node.

[0138] After the full node calculates the Bloom filter bitmap, the light node can request the Bloom filter bitmap from the full node and obtain the Bloom filter verification result based on the Bloom filter bitmap and the Bloom filter hash method. The following example illustrates steps S1031 and S1032:

[0139] Assume that the light node receives three Bloom filter hash methods from the full node, namely hash1, hash2, and hash3. In step S1031, the light node performs hash operations on the transaction to be verified using the Bloom filter hash methods hash1, hash2, and hash3, respectively, to obtain the Bloom filter bitmap value corresponding to the transaction to be verified.

[0140] In step S1032, the light node obtains the Bloom filter verification result corresponding to the transaction to be verified according to the Bloom filter bitmap value and the Bloom filter bitmap. Figure 10 :

[0141] Step S10321: The Bloom filter bitmap value of the transaction to be verified and the Bloom filter bitmap (see Figure 10 ) performs bitwise AND calculation to obtain a bitwise AND result;

[0142] Step S10322, determining whether the bitwise AND result is consistent with the Bloom filter bitmap; if consistent, executing step S10323; if inconsistent, executing step S10324;

[0143] Step S10323: Determine the Bloom filter verification result as the existence of the transaction; then execute step S10325;

[0144] Step S10324: Determine the Bloom filter verification result as the transaction not existing; then execute step S10325;

[0145] Step S10325: output the Bloom filter verification result.

[0146] Figure 12 and Figure 13 These are two examples of Bloom filter bitmap values ​​corresponding to the transactions to be verified. Figure 12 The bloom filter bitmap values ​​shown are the same as Figure 10 The bitwise AND result of the Bloom filter bitmap shown is as follows Figure 14 As shown, Figure 14 The bitwise AND result is Figure 10 The Bloom filter bitmap shown is inconsistent, which corresponds to the inconsistency in step S10322, and the output Bloom filter verification result is that the transaction exists; Figure 13 The bloom filter bitmap values ​​shown are the same as Figure 10 The bitwise AND result of the Bloom filter bitmap shown is as follows Figure 15 As shown, Figure 15 The bitwise AND result is Figure 10 The bloom filter bits shown Figure 1 At this time, corresponding to the consistent situation in step S10322, the output Bloom filter verification result is that the transaction does not exist.

[0147] In one embodiment, if Figure 16 As shown, step S105, obtaining the transaction verification result corresponding to the transaction to be verified according to the Bloom filter verification result and the Merkle proof result, includes:

[0148] Step S1051: Determine whether the Merkle proof result indicates that the transaction exists; if so, proceed to step S1052; if not, proceed to step S1053;

[0149] Step S1052, determine whether the Bloom filter verification result indicates that the transaction exists; if so, execute step S1054; if not, execute step S1055;

[0150] Step S1053, determining whether the Bloom filter verification result indicates that the transaction exists; if so, executing step S1056; if not, executing step S1055;

[0151] Step S1054: Determine the transaction verification result as the existence of the transaction; then execute step S1058;

[0152] Step S1055: Determine the transaction verification result as non-existent transaction; then execute step S1058;

[0153] Step S1056, determining the actual false positive rate of the Bloom filter according to the Bloom filter verification result and the Merkle proof result;

[0154] Step S1057: Determine whether the full node is trustworthy based on the actual false positive rate and the theoretical false positive rate of the Bloom filter; if it is trustworthy, execute step S1055; if it is not trustworthy, execute step S1054;

[0155] Step S1058: output the transaction verification result.

[0156] Thus, in step S105, obtaining the transaction verification result corresponding to the transaction to be verified based on the Bloom filter verification result and the Merkle proof result needs to be performed according to the following principles:

[0157] 1) If the Merkle proof result shows that the transaction exists, and the Bloom filter verification result shows that the transaction exists, then the transaction verification result shows that the transaction exists;

[0158] 2) If the Merkle proof result shows that the transaction does not exist and the Bloom filter verification result shows that the transaction does not exist, then the transaction verification result shows that the transaction does not exist;

[0159] 3) If the Merkle proof result shows that the transaction does not exist, but the Bloom filter verification result shows that the transaction exists, further judgment is required.

[0160] Based on the above principles 1) to 2), it can be concluded that step S105 specifically includes:

[0161] If both the Merkle proof result and the Bloom filter verification result indicate that the transaction exists, then the transaction verification result is determined to be the existence of the transaction (corresponding to Principle 1);

[0162] If the Bloom filter verification result is that the transaction does not exist, then the transaction verification result is determined to be that the transaction does not exist (corresponding to principle 2).

[0163] Among them, in principle 1), the Merkle proof result is consistent with the Bloom filter verification result, and the Merkle proof result is the existence of the transaction. Since the Merkle proof can verify affirmative propositions, the Merkle proof result shall prevail. In principle 2), the Merkle proof result is consistent with the Bloom filter verification result, and the Bloom filter verification result is the non-existence of the transaction. Since the Merkle proof can verify negative propositions, the Bloom filter verification result shall prevail. In principle 3), the Merkle proof result is the existence of the transaction, while the Bloom filter verification result is the non-existence of the transaction. This situation is almost impossible to occur. Here, it is stipulated that the Bloom filter verification result shall prevail.

[0164] As can be seen from this, as long as the Merkle proof result indicates that the transaction exists, the Merkle proof result shall prevail. As long as the Bloom filter verification result indicates that the transaction does not exist, the Bloom filter verification result shall prevail. In fact, there is also a situation where the Merkle proof result indicates that the transaction exists, but the Bloom filter verification result indicates that the transaction does not exist. This situation is theoretically impossible, but for the sake of completeness, this application still assumes this situation. When the Merkle proof result indicates that the transaction exists, but the Bloom filter verification result indicates that the transaction does not exist, the Bloom filter verification result shall prevail.

[0165] In principle 3), the Merkle proof indicates that the transaction does not exist, while the Bloom filter verifies that the transaction does exist. Since Merkle proofs can only verify affirmative statements and Bloom filters can only verify negative statements, it is impossible to determine whether the two results are correct. In this case, further judgment is required to improve the accuracy of the transaction verification results.

[0166] When the Merkle proof result indicates that the transaction does not exist, we believe that either the corresponding Merkle path of the transaction to be verified does not exist, or the corresponding Merkle path of the transaction to be verified does exist but the full node maliciously returns that the corresponding Merkle path of the transaction to be verified does not exist. There are only two situations. Therefore, we only need to determine whether the full node is trustworthy to determine whether the Merkle proof result is accurate. Simply put, if the full node is trustworthy, the Merkle proof result is accurate, and the transaction verification result is that the transaction does not exist; if the full node is untrustworthy, the Merkle proof result is inaccurate, and the transaction verification result is that the transaction exists. For details, please refer to Figure 15 Steps S1056 to S1057 in the above example are executed only when the Merkle proof result shows that the transaction does not exist and the Bloom filter verification result shows that the transaction exists.

[0167] In this embodiment, the actual error rate of the Bloom filter is determined based on the Bloom filter verification result and the Merkle proof result, and then whether the full node is trustworthy is determined based on the actual error rate and the theoretical error rate of the Bloom filter. Figure 17As shown, step S1056, determining the actual false positive rate of the Bloom filter according to the Bloom filter verification result and the Merkle proof result, includes:

[0168] Step S10561, counting the number of successes and false positives of the Bloom filter, wherein the number of successes is the number of times the Merkle proof result and the Bloom filter verification result are both that the transaction exists, and the number of false positives is the number of times the Merkle proof result is that the transaction does not exist, and the Bloom filter verification result is that the transaction exists.

[0169] Step S10562: Calculate the ratio of the number of false positives to the number of successful positives to obtain the actual false positive rate of the Bloom filter, i.e., actual false positive rate = number of false positives / number of successful positives.

[0170] In one embodiment, step S1057, determining whether the full node is trustworthy based on the actual false positive rate and the theoretical false positive rate of the Bloom filter, specifically includes:

[0171] It is determined that the actual false positive rate is greater than the theoretical false positive rate. If so, it is determined that the full node is untrustworthy; if not, it is determined that the full node is trustworthy.

[0172] The actual false positive rate is obtained through steps S10561 and S10562, and the theoretical false positive rate is obtained by looking up a table. Specific theoretical false positive rates (hash collision probabilities) of Bloom filters are shown in Tables 1 to 3:

[0173] Table 1: Bloom filter theoretical misjudgment rate (hash collision probability) corresponding to Table 1

[0174]

[0175]

[0176] Table 2: Bloom filter theoretical misjudgment rate (hash collision probability) corresponding to Table 2

[0177]

[0178]

[0179] Table 3: Bloom filter theoretical misjudgment rate (hash collision probability) corresponding to Table 3

[0180] m / n k k＝17 k＝18 k＝19 k＝20 k＝21 k＝22 k＝23 k＝24 22 15.2 2.67E-05 23 15.9 1.61E-05 24 16.6 9.84E-06 1.00E-05 25 17.3 6.08E-06 6.11E-06 6.27E-06 26 18 3.81E-06 3.76E-06 3.80E-06 3.92E-06 27 18.7 2.41E-06 2.34E-06 2.33E-06 2.37E-06 28 19.4 1.54E-06 1.47E-06 1.44E-06 1.44E-06 1.48E-06 29 20.1 9.96E-07 9.35E-07 9.01E-07 8.89E-07 8.96E-07 9.21E-07 30 20.8 6.50E-07 6.00E-07 5.69E-07 5.54E-07 5.50E-07 5.58E-07 31 21.5 4.29E-07 3.89E-07 3.63E-07 3.48E-07 3.41E-07 3.41E-07 3.48E-07 32 22.2 2.85E-07 2.55E-07 2.34E-07 2.21E-07 2.13E-07 2.10E-07 2.12E-07 2.17E-07

[0181] In Tables 1 to 3 above, m / n is the BitPreKey value, and k is the number of hash methods. Academic research has shown that for n transactions, m Bloom filter bitmap length (in bits), and k hash methods, the hash collision probability is lowest when k = m / n*ln(2). As can be seen from Tables 1 to 3, when BitPreKey = m / n = 10 and k = 7, the hash collision probability is only 0.00819; when BitPreKey = m / n = 32 and k = 22, the hash collision probability is only 2.1e-07.

[0182] In this embodiment, assuming that all nodes are trustworthy, in the case where it is impossible to determine whether the Merkle proof result is that the transaction does not exist, and the Bloom filter verification result is that the transaction exists, the actual error rate of the Bloom filter in this case is calculated, assuming that the Merkle proof result is correct and the Bloom filter verification result is an error. Because the Bloom filter has a theoretical error rate, which is related to the ratio of the Bloom filter bitmap length m to the number of transactions n (BitPreKey) and the number of hash methods k, the actual error rate of the Bloom filter generally does not exceed this theoretical error rate. Therefore, if the calculated actual error rate of the Bloom filter is greater than the theoretical error rate, the conclusion that the Bloom filter misjudged is considered incorrect, that is, the Bloom filter did not misjudgment, the Bloom filter verification result is accurate, and therefore the Merkle proof result is inaccurate, and the full node is untrustworthy.

[0183] It can be seen from this that the method of using Bloom filter to assist Merkle proof to verify transactions, in addition to the original function of Merkle proof to verify affirmative propositions, also has the function of Bloom filter to verify negative propositions. It can further verify whether the full node is trustworthy, effectively improving the accuracy of transaction verification.

[0184] Second, this application Figure 1 The blockchain-based transaction verification method of this application is explained from the perspective of full node 2 in the given application scenario. Please also refer to Figure 1 and Figure 18 , the blockchain-based transaction verification method includes the following steps:

[0185] Step S201: receiving a transaction verification request corresponding to a transaction to be verified sent by a light node;

[0186] Step S202: Generate transaction verification information according to the transaction verification request, and return the transaction verification information to the light node, so that the light node obtains the transaction verification result corresponding to the transaction to be verified according to the Bloom filter hash method, Bloom filter bitmap, Merkle path result and Merkle tree root in the transaction verification information.

[0187] Among them, the steps for light nodes to obtain transaction verification results are as follows: Figures 2 to 17 And the contents of the corresponding instructions are sufficient, which will not be repeated here.

[0188] The Bloom filter bitmap in this application is calculated by the consensus node. The specific steps are:

[0189] Traverse all transactions using the Bloom filter hash method to obtain the Bloom filter bitmap value corresponding to each transaction; and

[0190] The Bloom filter bitmap values ​​corresponding to each transaction are bitwise ANDed to obtain the Bloom filter bitmap.

[0191] Specifically, see Figures 6 to 10 And the contents of the corresponding instructions are sufficient, which will not be repeated here.

[0192] Thirdly, this application provides a blockchain system, see Figure 1 , the system comprises:

[0193] Consensus node 3 is used to package the Bloom filter hash method. The block header of the consensus node adds the Bloom filter method set name, BitPreKey, number of hash methods, and Bloom filter bits. Figure 4 fields;

[0194] Full node 2 is configured to synchronously obtain the Bloom filter hash method and the Bloom filter bitmap corresponding to all transactions of the full node from the consensus node; and when receiving a transaction verification request corresponding to a transaction to be verified sent by a light node, generate transaction verification information according to the transaction verification request and return the transaction verification information to the light node;

[0195] Light node 2 is used to send a transaction verification request to the full node, and obtain the transaction verification result corresponding to the transaction to be verified based on the Bloom filter hash method, Bloom filter bitmap, Merkle path result and Merkle tree root in the transaction verification information returned by the full node.

[0196] In one embodiment, the light node is specifically used for:

[0197] Obtaining a Bloom filter verification result corresponding to the transaction to be verified according to the Bloom filter hash method and the Bloom filter bitmap;

[0198] Obtaining a Merkle proof result corresponding to the transaction to be verified according to the Merkle path result and the Merkle tree root; and

[0199] A transaction verification result corresponding to the transaction to be verified is obtained according to the Bloom filter verification result and the Merkle proof result.

[0200] Among them, the steps for light nodes to obtain transaction verification results are as follows: Figures 2 to 17 And the contents of the corresponding instructions are sufficient, which will not be repeated here.

[0201] In one embodiment, the consensus node is further used to:

[0202] Traverse all transactions according to the Bloom filter hash method to obtain the Bloom filter bitmap value corresponding to each transaction;

[0203] The Bloom filter bitmap values ​​corresponding to each transaction are bitwise ANDed to obtain the Bloom filter bitmap.

[0204] Specifically, see Figures 6 to 10 And the contents of the corresponding instructions are sufficient, which will not be repeated here.

[0205] Fourthly, this application provides a blockchain-based transaction verification method, which is applied to any blockchain system provided in this application, such as Figure 19 As shown, the method includes:

[0206] Step S301: The consensus node synchronizes the Bloom filter hash method set name, BitPreKey, number of hash methods, and Bloom filter bitmap to all nodes;

[0207] Step S302: The full node receives the Bloom filter hash method and the Bloom filter bitmap corresponding to all transactions in the full node sent by the consensus node;

[0208] Step S303: The light node sends a transaction verification request to the full node corresponding to the transaction to be verified;

[0209] Step S304: The full node generates transaction verification information based on the transaction verification request and returns the transaction verification information to the light node, wherein the transaction verification information includes the Bloom filter bitmap, Bloom filter hash method, Merkle tree root, and Merkle path result corresponding to the transaction to be verified;

[0210] Step S305: The light node obtains a transaction verification result corresponding to the transaction to be verified according to the Bloom filter hash method, the Bloom filter bitmap, the Merkle path result, and the Merkle tree root.

[0211] In one embodiment, the light node obtains the transaction verification result corresponding to the transaction to be verified according to the Bloom filter hash method, the Bloom filter bitmap, the Merkle path result, and the Merkle tree root, including:

[0212] The light node obtains a Bloom filter verification result corresponding to the transaction to be verified according to the Bloom filter hash method and the Bloom filter bitmap;

[0213] The light node obtains the Merkle proof result corresponding to the transaction to be verified according to the Merkle path result and the Merkle tree root; and

[0214] The light node obtains a transaction verification result corresponding to the transaction to be verified according to the Bloom filter verification result and the Merkle proof result.

[0215] Among them, the steps for light nodes to obtain transaction verification results are as follows: Figures 2 to 17 And the contents of the corresponding instructions are sufficient, which will not be repeated here.

[0216] Based on the same inventive concept, the embodiments of the present application also provide a transaction verification device based on blockchain, which can be used to implement the method described in the above embodiments, as described in the following embodiments. Since the principle of solving the problem by the transaction verification device based on blockchain is similar to that of the transaction verification method based on blockchain, the implementation of the transaction verification device based on blockchain can refer to the implementation of the transaction verification method based on blockchain, and the repetitions will not be repeated. As used below, the term "unit" or "module" can be a combination of software and / or hardware that implements a predetermined function. Although the system described in the following embodiments is preferably implemented in software, implementation in hardware, or a combination of software and hardware, is also possible and conceived.

[0217] In the fifth aspect, the present application provides a transaction verification device based on blockchain, which corresponds to the transaction verification method based on blockchain provided by the present application from the perspective of light node, such as Figure 20 As shown, the device includes:

[0218] Transaction verification request sending module 401, used to send a transaction verification request to the full node corresponding to the transaction to be verified;

[0219] Transaction verification information receiving module 402, configured to receive transaction verification information returned by the full node in response to the transaction verification request, wherein the transaction verification information includes a Bloom filter bitmap, a Bloom filter hash method, a Merkle tree root, and a Merkle path result corresponding to the transaction to be verified;

[0220] A Bloom filter verification result generating module 403 is configured to obtain a Bloom filter verification result corresponding to the transaction to be verified according to the Bloom filter hash method and the Bloom filter bitmap;

[0221] A Merkle proof result generating module 404 is configured to obtain a Merkle proof result corresponding to the transaction to be verified based on the Merkle path result and the Merkle tree root;

[0222] The transaction verification result generating module 405 is configured to obtain a transaction verification result corresponding to the transaction to be verified according to the Bloom filter verification result and the Merkle proof result.

[0223] In one embodiment, if Figure 21 As shown, the Merkle proof result generation module 404 includes:

[0224] A Merkle path determination unit 4041 is configured to determine whether a Merkle path exists in the Merkle path result;

[0225] A hash value calculation unit 4042 is configured to calculate a hash value corresponding to the transaction to be verified based on a Merkle path when the Merkle path exists;

[0226] A hash value comparison unit 4043, configured to determine whether the hash value is consistent with the Merkle tree root;

[0227] The Merkle proof result generating unit 4044 is configured to obtain the Merkle proof result based on whether a Merkle path exists or whether the hash value is consistent with the Merkle tree root; if the Merkle path does not exist, the Merkle proof result is that the transaction does not exist; if the hash value is consistent with the Merkle tree root, the Merkle proof result is that the transaction exists; if the hash value is inconsistent with the Merkle tree root, the Merkle proof result is that the transaction does not exist.

[0228] In one embodiment, if Figure 22 As shown, the Bloom filter verification result generation module 403 includes:

[0229] a Bloom filter bitmap value calculation unit 4031, configured to perform a hash operation on the transaction to be verified according to the Bloom filter hashing method to obtain a Bloom filter bitmap value corresponding to the transaction to be verified;

[0230] The Bloom filter verification result generating unit 4032 is configured to obtain a Bloom filter verification result corresponding to the transaction to be verified according to the Bloom filter bitmap value and the Bloom filter bitmap.

[0231] In one embodiment, the Bloom filter verification result generation unit 4032 is specifically configured to:

[0232] Performing a bitwise AND calculation on the Bloom filter bitmap value and the Bloom filter bitmap to obtain a bitwise AND result;

[0233] Determine whether the bitwise AND result is consistent with the Bloom filter bitmap;

[0234] If they are consistent, the Bloom filter verification result is that the transaction exists;

[0235] If they are inconsistent, the Bloom filter verification result is that the transaction does not exist.

[0236] In one embodiment, if Figure 23 As shown, the transaction verification result generation module 405 includes:

[0237] a false positive rate calculation unit 4051 for determining an actual false positive rate of the Bloom filter based on the Bloom filter verification result and the Merkle proof result when the Bloom filter verification result indicates that the transaction exists and the Merkle proof result indicates that the transaction does not exist;

[0238] A full-node trust judgment unit 4052 is configured to determine whether the full node is trustworthy based on the actual false positive rate and the theoretical false positive rate of the Bloom filter;

[0239] The transaction verification result generating unit 4053 is configured to, when both the Merkle proof result and the Bloom filter verification result indicate that the transaction exists, determine the transaction verification result as the existence of the transaction; when the Bloom filter verification result indicates that the transaction does not exist, determine the transaction verification result as the non-existence of the transaction; when the Bloom filter verification result indicates that the transaction exists and the Merkle proof result indicates that the transaction does not exist, if the full node is trustworthy, determine the transaction verification result as the non-existence of the transaction; if the full node is untrustworthy, determine the transaction verification result as the existence of the transaction.

[0240] In one embodiment, the error rate calculation unit 4051 is specifically used to:

[0241] Counting the number of successes and false positives of the Bloom filter, where the number of successes is the number of times both the Merkle proof result and the Bloom filter verification result indicate that the transaction exists, and the number of false positives is the number of times the Merkle proof result indicates that the transaction does not exist and the Bloom filter verification result indicates that the transaction exists;

[0242] The ratio of the number of false positives to the number of successful positives is calculated to obtain an actual false positive rate of the Bloom filter.

[0243] In a sixth aspect, the present application provides another blockchain-based transaction verification device, which corresponds to the blockchain-based transaction verification method provided by the present application from the perspective of a full node, such as Figure 24 As shown, the device includes:

[0244] The transaction verification request receiving module 501 is used to receive a transaction verification request corresponding to a transaction to be verified sent by a light node;

[0245] The transaction verification information generation module 502 is used to generate transaction verification information according to the transaction verification request and return the transaction verification information to the light node, so that the light node can obtain the transaction verification result corresponding to the transaction to be verified according to the Bloom filter hash method, Bloom filter bitmap, Merkle path result and Merkle tree root in the transaction verification information.

[0246] The blockchain-based transaction verification method, device, and blockchain system described in this application utilize Bloom filters to extend Merkle proofs, overcoming the limitation of existing Merkle proofs, which can only verify affirmative propositions. The combination of the two can simultaneously verify both affirmative and negative propositions, improving the accuracy of transaction verification. Execution of this application only requires adding a small number of fields to the block header of blockchain nodes, without burdening the storage and network transmission of light nodes.

[0247] Those skilled in the art will appreciate that the embodiments of this specification may be provided as methods, systems, or computer program products. Therefore, the embodiments of this specification may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, the embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. In the description of this specification, the reference terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" mean that the specific features, structures, materials, or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the embodiments of this specification.

[0248] In this specification, the schematic expressions of the above terms do not necessarily refer to the same embodiment or example. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples, unless they contradict each other. The above is only an embodiment of the embodiment of this specification and is not intended to limit the embodiment of this specification. For those skilled in the art, the embodiment of this specification may have various changes and variations. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the embodiment of this specification shall be included within the scope of the claims of the embodiment of this specification.

Claims

1. A transaction verification method based on blockchain, characterized in that: include: Send a transaction verification request to the full node corresponding to the transaction to be verified; Receiving transaction verification information returned by the full node in response to the transaction verification request, the transaction verification information including a Bloom filter bitmap, a Bloom filter hash method, a Merkle tree root, and a Merkle path result corresponding to the transaction to be verified; Obtaining a Bloom filter verification result corresponding to the transaction to be verified according to the Bloom filter hash method and the Bloom filter bitmap; Obtaining a Merkle proof result corresponding to the transaction to be verified according to the Merkle path result and the Merkle tree root; A transaction verification result corresponding to the transaction to be verified is obtained according to the Bloom filter verification result and the Merkle proof result, including: if the Merkle proof result and the Bloom filter verification result are both that the transaction exists, then the transaction verification result is that the transaction exists; if the Bloom filter verification result is that the transaction does not exist, then the transaction verification result is that the transaction does not exist; if the Bloom filter verification result is that the transaction exists and if the Merkle proof result is that the transaction does not exist, then the actual error rate of the Bloom filter is determined according to the Bloom filter verification result and the Merkle proof result; whether the full node is trustworthy is determined according to the actual error rate and the theoretical error rate of the Bloom filter; if it is trustworthy, the transaction verification result is that the transaction does not exist; if it is not trustworthy, the transaction verification result is that the transaction exists.

2. The blockchain-based transaction verification method according to claim 1, characterized in that: Obtaining the Merkle proof result corresponding to the transaction to be verified according to the Merkle path result and the Merkle tree root includes: Determine whether a Merkle path exists in the Merkle path result; if the Merkle path does not exist, the Merkle proof result is that the transaction does not exist; If a Merkle path exists, the hash value corresponding to the transaction to be verified is calculated based on the Merkle path; The Merkle proof result is obtained based on whether the hash value is consistent with the Merkle tree root; if they are consistent, the Merkle proof result is that the transaction exists; if they are inconsistent, the Merkle proof result is that the transaction does not exist.

3. The blockchain-based transaction verification method according to claim 2, characterized in that: Obtaining a Bloom filter verification result corresponding to the transaction to be verified according to the Bloom filter hash method and the Bloom filter bitmap includes: Performing a hash operation on the transaction to be verified according to the Bloom filter hashing method to obtain a Bloom filter bitmap value corresponding to the transaction to be verified; A Bloom filter verification result corresponding to the transaction to be verified is obtained according to the Bloom filter bitmap value and the Bloom filter bitmap.

4. The blockchain-based transaction verification method according to claim 3, characterized in that: Obtaining a Bloom filter verification result corresponding to the transaction to be verified according to the Bloom filter bitmap value and the Bloom filter bitmap includes: Performing a bitwise AND calculation on the Bloom filter bitmap value and the Bloom filter bitmap to obtain a bitwise AND result; Determine whether the bitwise AND result is consistent with the Bloom filter bitmap; If they are consistent, the Bloom filter verification result is that the transaction exists; If they are inconsistent, the Bloom filter verification result is that the transaction does not exist.

5. The transaction verification method based on blockchain according to claim 1, characterized in that: Determining the actual misjudgment rate of the Bloom filter according to the Bloom filter verification result and the Merkle proof result includes: Counting the number of successes and false positives of the Bloom filter, where the number of successes is the number of times both the Merkle proof result and the Bloom filter verification result indicate that the transaction exists, and the number of false positives is the number of times the Merkle proof result indicates that the transaction does not exist and the Bloom filter verification result indicates that the transaction exists; The ratio of the number of false positives to the number of successful positives is calculated to obtain an actual false positive rate of the Bloom filter.

6. The transaction verification method based on blockchain according to claim 1, characterized in that: The determining whether the full node is trustworthy according to the actual false positive rate and the theoretical false positive rate of the Bloom filter includes: When the actual false positive rate is greater than the theoretical false positive rate, the full node is untrustworthy; otherwise, the full node is trustworthy.

7. A transaction verification method based on blockchain, characterized in that: include: Receive the transaction verification request corresponding to the transaction to be verified sent by the light node; Generate transaction verification information according to the transaction verification request, and return the transaction verification information to the light node, so that the light node obtains the transaction verification result corresponding to the transaction to be verified according to the Bloom filter hash method, Bloom filter bitmap, Merkle path result and Merkle tree root in the transaction verification information, wherein the light node obtains the transaction verification result corresponding to the transaction to be verified according to the Bloom filter hash method, Bloom filter bitmap, Merkle path result and Merkle tree root in the transaction verification information, including: obtaining the Bloom filter verification result corresponding to the transaction to be verified according to the Bloom filter hash method and the Bloom filter bitmap; obtaining the Merkle proof result corresponding to the transaction to be verified according to the Merkle path result and the Merkle tree root; obtaining the transaction verification result corresponding to the transaction to be verified according to the Bloom filter verification result and the Merkle proof result.

8. A blockchain system, characterized in that: include: Consensus nodes, used to package Bloom filter hashing methods; A full node, configured to obtain from the consensus node the Bloom filter hash method and a Bloom filter bitmap corresponding to all transactions of the full node; and when receiving a transaction verification request corresponding to a transaction to be verified sent by a light node, generating transaction verification information according to the transaction verification request, and returning the transaction verification information to the light node; The light node is configured to send a transaction verification request to the full node, and obtain a transaction verification result corresponding to the transaction to be verified based on the Bloom filter hash method, the Bloom filter bitmap, the Merkle path result, and the Merkle tree root in the transaction verification information returned by the full node, including: obtaining the Bloom filter verification result corresponding to the transaction to be verified based on the Bloom filter hash method and the Bloom filter bitmap; A Merkle proof result corresponding to the transaction to be verified is obtained according to the Merkle path result and the Merkle tree root; and a transaction verification result corresponding to the transaction to be verified is obtained according to the Bloom filter verification result and the Merkle proof result.

9. The blockchain system according to claim 8, characterized in that: The consensus node is also used to: Traverse all transactions according to the Bloom filter hash method to obtain the Bloom filter bitmap value corresponding to each transaction; The Bloom filter bitmap values ​​corresponding to each transaction are bitwise ANDed to obtain the Bloom filter bitmap.

10. A transaction verification method based on blockchain, applied to the blockchain system according to any one of claims 8 to 9, characterized in that: include: The light node sends a transaction verification request to the full node corresponding to the transaction to be verified; The full node generates transaction verification information based on the transaction verification request and returns the transaction verification information to the light node, wherein the transaction verification information includes the Bloom filter bitmap, Bloom filter hash method, Merkle tree root, and Merkle path result corresponding to the transaction to be verified; the Bloom filter bitmap is calculated by the consensus node based on the Bloom filter hash method and each transaction in the full node; The light node obtains the transaction verification result corresponding to the transaction to be verified according to the Bloom filter hash method, the Bloom filter bitmap, the Merkle path result and the Merkle tree root, including: obtaining the Bloom filter verification result corresponding to the transaction to be verified according to the Bloom filter hash method and the Bloom filter bitmap; obtaining the Merkle proof result corresponding to the transaction to be verified according to the Merkle path result and the Merkle tree root; obtaining the transaction verification result corresponding to the transaction to be verified according to the Bloom filter verification result and the Merkle proof result.

11. A transaction verification device based on blockchain, characterized in that: include: The transaction verification request sending module is used to send a transaction verification request to the full node corresponding to the transaction to be verified; a transaction verification information receiving module, configured to receive transaction verification information returned by the full node in response to the transaction verification request, the transaction verification information including a Bloom filter bitmap, a Bloom filter hash method, a Merkle tree root, and a Merkle path result corresponding to the transaction to be verified; a Bloom filter verification result generation module, configured to obtain a Bloom filter verification result corresponding to the transaction to be verified according to the Bloom filter hash method and the Bloom filter bitmap; A Merkle proof result generation module, configured to obtain a Merkle proof result corresponding to the transaction to be verified based on the Merkle path result and the Merkle tree root; a transaction verification result generating module, configured to obtain a transaction verification result corresponding to the transaction to be verified based on the Bloom filter verification result and the Merkle proof result; The transaction verification result generation module includes: a transaction verification result generation unit, which is used to determine the transaction verification result as transaction existence when the Merkle proof result and the Bloom filter verification result are both transaction existence; when the Bloom filter verification result is transaction non-existence, determine the transaction verification result as transaction non-existence; when the Bloom filter verification result is transaction existence and the Merkle proof result is transaction non-existence, if the full node is trustworthy, determine the transaction verification result as transaction non-existence; if the full node is untrustworthy, determine the transaction verification result as transaction existence.

12. The blockchain-based transaction verification device according to claim 11, characterized in that: The transaction verification result generation module includes: a false positive rate calculation unit, configured to determine an actual false positive rate of the Bloom filter based on the Bloom filter verification result and the Merkle proof result when the Bloom filter verification result indicates that the transaction exists and the Merkle proof result indicates that the transaction does not exist; The full-node trust judgment unit is used to determine whether the full node is trustworthy based on the actual false positive rate and the theoretical false positive rate of the Bloom filter.

13. A transaction verification device based on blockchain, characterized in that: include: The transaction verification request receiving module is used to receive the transaction verification request corresponding to the transaction to be verified sent by the light node; A transaction verification information generation module is used to generate transaction verification information according to the transaction verification request and return the transaction verification information to the light node, so that the light node obtains the transaction verification result corresponding to the transaction to be verified according to the Bloom filter hash method, Bloom filter bitmap, Merkle path result and Merkle tree root in the transaction verification information, wherein the light node obtains the transaction verification result corresponding to the transaction to be verified according to the Bloom filter hash method, Bloom filter bitmap, Merkle path result and Merkle tree root in the transaction verification information, including: obtaining the Bloom filter verification result corresponding to the transaction to be verified according to the Bloom filter hash method and the Bloom filter bitmap; obtaining the Merkle proof result corresponding to the transaction to be verified according to the Merkle path result and the Merkle tree root; obtaining the transaction verification result corresponding to the transaction to be verified according to the Bloom filter verification result and the Merkle proof result.

Images