Information verification method and device, electronic equipment, medium and program product

Abstract

The application discloses an information verification method and device, electronic equipment, medium and program product. The information verification method comprises the following steps: receiving a transaction verification request; wherein the transaction verification request is used to indicate verification of transactions between transaction users in different partitions in a block chain; based on the transaction verification request, a consensus partition of a transaction user in a different partition corresponding to the transaction verification request is acquired from a binary consensus tree; wherein the binary consensus tree comprises N-level consensus partitions, each level of the consensus partitions has at least two partitions of the block chain, and at least one transaction user is stored in each partition; N is a positive integer greater than or equal to 2; based on a consensus node corresponding to the consensus partition, the transaction corresponding to the transaction verification request is verified to obtain a verification result. The effect of quickly verifying the transactions of the transaction users in the different partitions can be realized.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, specifically to an information verification method, device, electronic device, medium, and program product. Background Technology

[0002] Double-spending, also known as double-spending, refers to the use of the same money two or more times. How to verify double-spending is a pressing issue that needs to be addressed.

[0003] Currently, the verification of double-spending payments involves using all the corresponding consensus nodes in the blockchain to verify the double-spending payment, which results in low verification efficiency. Summary of the Invention

[0004] The purpose of this application is to provide an information verification method, apparatus, electronic device, medium, and program product to achieve the effect of quickly verifying the transactions of trading users in different partitions.

[0005] The technical solution of this application is as follows:

[0006] Firstly, an information verification method is provided, the method comprising:

[0007] Receive a transaction verification request; wherein the transaction verification request is used to instruct the verification of transactions between users in different partitions of the blockchain;

[0008] Based on the transaction verification request, the consensus partitions of the transaction users corresponding to different partitions of the transaction verification request are obtained from the binary consensus tree; wherein, the binary consensus tree includes N levels of consensus partitions, each level of consensus partition has partitions of at least two blockchains, and each partition stores at least one transaction user; N is a positive integer greater than or equal to 2;

[0009] Based on the consensus node corresponding to the consensus partition, the transaction corresponding to the transaction verification request is verified to obtain the verification result.

[0010] Secondly, an information verification device is provided, the device comprising:

[0011] A receiving module is used to receive transaction verification requests; wherein the transaction verification request is used to instruct the verification of transactions between users in different partitions of the blockchain;

[0012] The acquisition module is used to acquire the consensus partitions of the transaction users corresponding to different partitions of the transaction verification request from the binary consensus tree based on the transaction verification request; wherein, the binary consensus tree includes N levels of consensus partitions, each level of consensus partition has partitions of at least two blockchains, and each partition stores at least one transaction user; N is a positive integer greater than or equal to 2;

[0013] The verification module is used to verify the transaction corresponding to the transaction verification request based on the consensus node corresponding to the consensus partition, and obtain the verification result.

[0014] Thirdly, embodiments of this application provide an electronic device, which includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor. When the program or instructions are executed by the processor, they implement the steps of any of the information verification methods described in the embodiments of this application.

[0015] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, and when the program or instructions are executed by a processor, the steps of any of the information verification methods described in embodiments of this application are implemented.

[0016] Fifthly, embodiments of this application provide a computer program product, wherein instructions in the computer program product, when executed by a processor of an electronic device, enable the electronic device to perform the steps of any of the information verification methods described in embodiments of this application.

[0017] The technical solutions provided by the embodiments of this application bring at least the following beneficial effects:

[0018] The information verification method provided in this application receives a transaction verification request indicating that transactions between users in different partitions of a blockchain are to be verified. It then obtains the consensus partitions of the users in the different partitions corresponding to the transaction verification request from a binary consensus tree. Finally, based on the consensus nodes corresponding to the consensus partitions, it verifies the transactions corresponding to the transaction verification request to obtain a verification result. In this way, when it is necessary to verify transactions between users in different partitions of a blockchain, the consensus partitions of the users in the different partitions are obtained through a binary consensus tree, and then the transactions of the users in the different partitions are verified based on the consensus nodes corresponding to those consensus partitions. This reduces the amount of data required for consensus nodes to verify transactions, thus improving the efficiency of consensus verification.

[0019] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application, and do not constitute an undue limitation of this application.

[0021] Figure 1 This is one of the flowcharts illustrating an information verification method provided in the first aspect of this application;

[0022] Figure 2 This is a schematic diagram of the structure of a binary consensus tree according to the first aspect of the present application;

[0023] Figure 3 This is a schematic flowchart illustrating the implementation process of allocating target partitions to target transaction users according to the first aspect of this application.

[0024] Figure 4 This is a second schematic flowchart of the information verification method provided in the first aspect of this application;

[0025] Figure 5 This is a schematic diagram of the structure of an information verification device provided in the second aspect of this application;

[0026] Figure 6 This is a schematic diagram of the structure of an electronic device provided in the third aspect of this application. Detailed Implementation

[0027] To enable those skilled in the art to better understand the technical solutions of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0028] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples consistent with some aspects of this application as detailed in the appended claims.

[0029] As described in the background section, existing technologies suffer from low efficiency in double-spending verification. To address this issue, this application provides an information verification method, apparatus, electronic device, medium, and program product. The method involves receiving a transaction verification request indicating transactions between users in different partitions of a blockchain, obtaining the consensus partitions of the users in different partitions corresponding to the verification request from a binary consensus tree, and then verifying the transaction corresponding to the verification request based on the consensus nodes corresponding to those partitions to obtain the verification result. This approach reduces the amount of data required for consensus nodes in verifying transactions between users in different partitions of the blockchain, thus improving the efficiency of consensus verification.

[0030] The information verification method provided in this application will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.

[0031] Figure 1 This is a flowchart illustrating an information verification method provided in an embodiment of this application. The execution entity of this information verification method can be a server. It should be noted that the aforementioned execution entity does not constitute a limitation on this application.

[0032] like Figure 1 As shown, the information verification method provided in this application embodiment may include steps 110-130.

[0033] Step 110: Receive transaction verification request.

[0034] Transaction verification requests can be used to instruct the verification of transactions between users in different partitions of the blockchain.

[0035] Step 120: Based on the transaction verification request, obtain the consensus partitions of the transaction users corresponding to different partitions in the binary consensus tree.

[0036] The binary consensus tree consists of N levels of consensus partitions, each level having at least two blockchain partitions, and each partition storing at least one transaction user; N is a positive integer greater than or equal to 2.

[0037] Step 130: Based on the consensus node corresponding to the consensus partition, verify the transaction corresponding to the transaction verification request and obtain the verification result.

[0038] In the embodiments of this application, a transaction verification request is received, indicating that transactions between users in different partitions of the blockchain are to be verified. The consensus partitions of the users in different partitions corresponding to the transaction verification request are obtained from the binary consensus tree. Then, based on the consensus nodes corresponding to the consensus partitions, the transactions corresponding to the transaction verification request are verified to obtain the verification results. In this way, when it is necessary to verify transactions between users in different partitions of the blockchain, the consensus partitions of the users in different partitions are obtained through the binary consensus tree, and then the transactions of users in different partitions are verified based on the consensus nodes corresponding to those consensus partitions. This reduces the amount of data required for consensus nodes to verify transactions, thus improving the efficiency of consensus verification.

[0039] The information verification method provided in the embodiments of this application will be described in detail below.

[0040] First, let's introduce step 110, receiving the transaction verification request.

[0041] A transaction verification request can be a request to verify a specific transaction. Specifically, the transaction verification request can be used to instruct the verification of transactions between users in different partitions of the blockchain.

[0042] Different partitions in a blockchain can be different blocks within the blockchain. Each partition can store at least one transaction user.

[0043] In some embodiments of this application, the transaction user can trade with the object.

[0044] In one example, user A transfers money to user B, which is a transaction between user A and user B. Here, user A and user B are the users of the transaction.

[0045] Then, step 120 is introduced: based on the transaction verification request, obtain the consensus partition of the transaction user corresponding to the different partitions of the transaction verification request from the binary consensus tree.

[0046] The binary consensus tree can be a binary tree constructed from different partitions in the blockchain.

[0047] In some embodiments of this application, the binary consensus tree may include N levels of consensus partitions, each level having partitions of at least two blockchains; N is a positive integer greater than or equal to 2.

[0048] The consensus partitions for trading users in different partitions can be the consensus verification partitions corresponding to trading users in different partitions.

[0049] In one example, such as Figure 2 As shown, Figure 2 For a binary consensus tree, Figure 2The binary consensus tree in the model includes N levels of consensus partitions ( Figure 2 The consensus partitions are 12, 34, 56, MN, 1234 and 56MN, and each consensus partition has at least two blockchain partitions.

[0050] In some embodiments of this application, based on the transaction verification request, the consensus partitions of the transaction users corresponding to different partitions of the transaction verification request can be obtained from a pre-built binary consensus tree.

[0051] In some embodiments of this application, in order to further improve the transaction verification efficiency of transaction users in different partitions, the information verification method mentioned above may further include the following before step 110:

[0052] Construct a binary consensus tree based on transaction users in different partitions of the blockchain;

[0053] Calculate the accuracy of the consensus of each consensus node in the blockchain for the transaction consensus of users in each partition;

[0054] Consensus nodes are selected for each partition in the binary consensus tree based on accuracy.

[0055] Consensus nodes can be nodes that verify transactions between users in the blockchain.

[0056] Transaction consensus can be the consensus reached among various trading users.

[0057] In one example, user A transfers money to user B, which is a transaction between user A and user B. Whether user B allows user A to transfer money to him or not, that is, whether user A and user B can reach a consensus on this transfer, i.e., transaction consensus.

[0058] In some embodiments of this application, a blockchain can have multiple consensus nodes. These consensus nodes can verify transactions between users in the blockchain. In the prior art, if user A in one partition of the blockchain transfers funds to user B in another partition of the blockchain, the transaction is verified by all the consensus nodes corresponding to the blockchain. This results in a large amount of data for the consensus nodes of the transaction, leading to low verification efficiency.

[0059] To address the aforementioned issues, this embodiment constructs a binary consensus tree based on transaction users in different partitions of the blockchain. Then, it calculates the accuracy of the consensus among all consensus nodes in the blockchain for each partition's transaction users. Based on this accuracy, all consensus nodes in the blockchain can be assigned to each partition in the binary consensus tree. Thus, when a transaction exists in a partition, verification can be performed based on the consensus node corresponding to that partition, eliminating the need for all consensus nodes in the blockchain to verify it. This saves consensus verification time and improves its efficiency.

[0060] It should be noted that constructing a binary consensus tree based on the transaction users in different partitions of the blockchain, and then selecting consensus nodes for different partitions based on the accuracy of the consensus nodes in the blockchain for the transaction consensus of the transaction users in each partition, can also be performed before step 120. This process can be performed before the consensus nodes in the partition are used to verify the transactions within it.

[0061] In some embodiments of this application, to further improve the verification efficiency of transactions by users in different partitions, the step of constructing a binary consensus tree based on transaction users in different partitions of the blockchain may specifically include:

[0062] Each partition in the blockchain is identified as a leaf node of a binary consensus tree;

[0063] Two partitions with a predefined relationship are identified as consensus partitions, and the consensus partitions are used to form the parent nodes of the leaf nodes of the binary consensus tree.

[0064] Update each consensus partition to two partitions, return to the execution and determine the two partitions with the preset relationship as consensus partitions, form the parent node of the leaf node of the consensus partition, until the two partitions have no preset relationship, and form a binary consensus tree.

[0065] Leaf nodes can be the nodes corresponding to the leaves of a binary consensus tree. For example... Figure 2 The leaf is 1, leaf 2, leaf 3, ..., leaf N.

[0066] The preset relationship can be a pre-defined relationship between two partitions.

[0067] A parent node can be the node that is the parent node of a leaf node.

[0068] In some embodiments of this application, leaf nodes and parent nodes correspond to each other. For example... Figure 2 As shown, when leaf 1 and leaf 2 are leaf nodes, their parent node is leaf 9. When the parent node (leaf 9) is a leaf node, its parent node is leaf 13.

[0069] In one example, such as Figure 2 As shown, each partition in the blockchain (i.e., partition 1, partition 2, partition 3, ..., partition N) is identified as a leaf node of the binary consensus tree. Then, partitions 1 and 2 with a predefined relationship are identified as a consensus partition (i.e., consensus partition 12), and this consensus partition 12 becomes the parent node of the leaf nodes (partitions 1 and 2) of the binary consensus tree. Next, each consensus partition (e.g., consensus partition 12 and consensus partition 34) is updated to the partitions 1 and 2 as defined above. The process then returns to the previous step, identifying consensus partitions 12 and 34 with a predefined relationship as another consensus partition (i.e., consensus partition 1234), and this consensus partition 1234 becomes the parent node of the leaf nodes (consensus partitions 12 and 34) of the binary consensus tree. This process is repeated until two partitions no longer have a predefined relationship, thus forming a consensus tree. Figure 2 The binary consensus tree shown.

[0070] In the embodiments of this application, by determining each partition in the blockchain as the leaf node of a binary consensus tree, determining two partitions with a preset relationship as consensus partitions, forming the parent node of the leaf node of the binary consensus tree for the consensus partitions, updating each consensus partition to two partitions, returning to the process of determining two partitions with a preset relationship as consensus partitions, forming the parent node of the leaf node of the binary consensus tree for the consensus partitions, until the two partitions no longer have a preset relationship, a binary consensus tree can be formed. In this way, a binary consensus tree corresponding to each partition in the blockchain can be formed, so that the consensus partitions corresponding to different partitions can be found based on the binary consensus tree, so that when there are transactions in different partitions, the consensus nodes of the consensus partitions of different partitions can be used to verify them, further improving the verification efficiency.

[0071] In some embodiments of this application, the above-mentioned determination of two partitions with a preset relationship as consensus partitions can be achieved by determining the preset relationship between the two partitions in the following manner: before determining the two partitions with a preset relationship as consensus partitions and forming the parent node of the leaf node of the consensus partition in the binary consensus tree, the information verification method involved above may further include:

[0072] Get the number of transactions initiated by each user in each partition of the blockchain;

[0073] Based on the number of transactions, construct a transaction count matrix for each partition;

[0074] Calculate the similarity between the transaction frequency matrices of every two partitions;

[0075] The two partitions with the highest similarity are identified as having a predefined relationship.

[0076] The transaction count matrix can be a matrix corresponding to the number of transactions initiated by each user in each partition.

[0077] In one example, transaction data for each trading user is retrieved from each partition, as shown in Table 1 below:

[0078] Table 1

[0079] 1 User A User B 0.1 2021.6.24 10:00:00 2 User A User C 0.1 2021.6.24 10:00:00 3 User A User B 0.1 2021.6.24 10:00:00 4 User A User B 0.1 2021.6.24 10:00:00 5 ...... ...... ...... ......

[0080] Then, the number of times each transaction sender initiates a transaction in each partition over a period of time i is counted to form the transaction count matrix corresponding to that partition. If there are N partitions and a total of M users in the blockchain, the transaction count matrix corresponding to each partition is formed as shown in the following formula (1):

[0081]

[0082] Wherein, a in formula (1) nm This represents the number of transactions initiated by the Mth transaction user in the Nth partition.

[0083] Then, calculate the similarity between the transaction frequency matrices of any two partitions. Specifically, refer to the following formula (2) for calculation, and then obtain the similarity matrix between any two partitions, as shown in formula (3):

[0084]

[0085] Here, p and q are two different partitions, and k is the transaction user in partition p or partition q.

[0086]

[0087] Then, based on formula (4), the two partitions with the highest similarity are selected and these two partitions are determined as having a preset relationship.

[0088]

[0089] In one example, if the similarity between partition 1 and partition 2 is higher than that between partition 1 and partition 3, then partition 1 and partition 2 are placed under the same parent node (consensus node 12) of the binary consensus tree as the partitions with the highest similarity.

[0090] In the embodiments of this application, the number of transactions initiated by each user in each partition of the blockchain is obtained; based on the number of transactions, a transaction count matrix corresponding to each partition is constructed; the similarity between the transaction count matrices of every two partitions is calculated; and the two partitions with the highest similarity are identified as two partitions with a preset relationship. In this way, the two partitions with a preset relationship corresponding to the leaf nodes of the binary consensus tree can be accurately determined.

[0091] In some embodiments of this application, to further improve the transaction verification efficiency for users in different partitions, the accuracy of the consensus consensus of each consensus node corresponding to the blockchain for the transaction users in each partition may specifically include:

[0092] Obtain the first number of times that the consensus nodes of the blockchain correctly verified the transactions of the users in each partition, and the second number of times that the consensus nodes failed to verify the transactions of the users in each partition.

[0093] Based on the first and second counts, the accuracy of each consensus node's consensus on transactions of users in each partition is determined.

[0094] The first number can be the number of times that the consensus nodes of the blockchain have verified the correctness of the transaction consensus of the users in each partition.

[0095] The second number can be the number of times that the consensus nodes of the blockchain fail to verify the transaction consensus of the users in each partition.

[0096] In one example, there are 10 consensus nodes in the blockchain. User A wants to transfer money to User B. This transaction is initiated by User A. The 10 consensus nodes will verify the transaction. If User A's password is incorrect, the transaction between User A and User B cannot be executed. However, if 8 consensus nodes verify that the transaction is not executable and 2 consensus nodes verify that the transaction is executable, then the 10 consensus nodes in the blockchain will correctly verify the transaction initiated by User A 8 times (i.e., the first verification) and incorrectly verify it 2 times (i.e., the second verification).

[0097] Then, based on the first and second counts, the accuracy of the consensus among these 10 consensus nodes regarding the transaction initiator, User A, in this transaction between User A and User B can be determined according to the following formula (5):

[0098]

[0099] Where Y is the first number and N is the second number.

[0100] In the embodiments of this application, by obtaining the first number of times that the consensus nodes of the blockchain correctly verified the transactions of the users in each partition, and the second number of times that the consensus nodes failed to verify the transactions of the users in each partition; then, based on the first number and the second number, the accuracy rate of the consensus nodes in verifying the transactions of the users in each partition can be accurately determined. Thus, based on the accuracy rate, consensus nodes can be allocated to different partitions to improve the efficiency of transaction verification for users in different partitions.

[0101] In some embodiments of this application, to further improve the efficiency of transaction verification for users in different partitions, the selection of consensus nodes for each partition in the binary consensus tree based on accuracy may specifically include:

[0102] Arrange the accuracy rates in descending order, and select the consensus nodes corresponding to the top M accuracy rates as the consensus nodes corresponding to the root consensus partition.

[0103] Calculate the first accuracy rate of the consensus nodes that are not the consensus nodes corresponding to the root consensus partition for the transaction users of the leaf node partition of the root consensus partition, and select the top M consensus nodes with the first accuracy rate as the consensus nodes corresponding to the leaf node partition of the root consensus partition.

[0104] The consensus nodes corresponding to the leaf node partitions that are not the root consensus partitions are updated. The first accuracy rate of the transaction consensus of the transaction users in the leaf node partitions of the root consensus partition is calculated based on the consensus nodes corresponding to the leaf node partitions of the root consensus partition. The top M consensus nodes with the highest first accuracy rates are selected as the consensus nodes corresponding to the leaf node partitions of the root consensus partition, and so on, until consensus nodes are selected for each consensus partition in the binary consensus tree.

[0105] The root consensus partition can be the top-level consensus partition of the binary consensus tree, i.e. Figure 2 The root consensus partition in the process.

[0106] In the above steps, M can be a positive integer.

[0107] The leaf node partition of the root consensus partition can be the partition corresponding to the leaf node of the root consensus partition.

[0108] In one example, refer to Figure 2 , Figure 2 The leaf node partitions of the root consensus partition can be consensus partition 1234 and consensus partition 56MN.

[0109] The first accuracy rate can be the accuracy rate of the transaction consensus of transaction users in the leaf node partitions of the root consensus partition by the consensus node that is not the consensus node corresponding to the root consensus partition.

[0110] In some embodiments of this application, after calculating the accuracy of the consensus of each consensus node in the blockchain for the transaction consensus of the transaction users in each partition, the accuracy rates are arranged in descending order, and then the consensus nodes corresponding to the top M accuracy rates are selected as the consensus nodes corresponding to the root consensus partition.

[0111] Then, calculate the accuracy rate (i.e., the first accuracy rate) of the consensus nodes that are not the root consensus partitions for the transaction consensus of the transaction users in the leaf node partitions of the root consensus partition. Sort the first accuracy rates from largest to smallest and select the consensus nodes corresponding to the top M first accuracy rates as the consensus nodes corresponding to the leaf node partitions of the root consensus partition.

[0112] Update the consensus nodes of the leaf nodes that are not the root consensus partitions to the consensus nodes that are not the root consensus partitions. Repeatedly calculate the first accuracy rate of the transaction consensus of the consensus nodes that are not the root consensus partitions for the transaction users of the leaf nodes of the root consensus partitions. Select the top M consensus nodes with the first accuracy rate as the consensus nodes of the leaf nodes of the root consensus partitions, until consensus nodes are selected for all partitions.

[0113] In one example, such as Figure 2 As shown, there are 10 consensus nodes in the blockchain. After calculating the accuracy rate of these 10 consensus nodes for the transaction consensus of users in each partition, they are then sorted from highest to lowest accuracy. The top two (the specific top few can be selected according to user needs) consensus nodes (for example, consensus node 1 and consensus node 2) are selected as... Figure 2 The consensus nodes in the root consensus region are then used. Next, the accuracy rate (first accuracy rate) of the transaction consensus of the remaining 8 consensus nodes for the transaction users (i.e., transaction users in partitions 1, 2, 3, and 4) of the leaf node partitions (consensus partitions 1, 2, 3, and 4) of the root consensus partition is calculated. This first accuracy rate is then sorted from largest to smallest, and the consensus nodes corresponding to the top two first accuracy rates (e.g., consensus node 3 and consensus node 4) are selected as the consensus nodes corresponding to consensus partitions 1, 2, 3, and 4.

[0114] Then, calculate the accuracy of the consensus of the remaining 6 consensus nodes for the transaction users in consensus partition 56MN (i.e., transaction users in partitions 5, 6, M and N), sort the accuracy from largest to smallest, and select the consensus nodes corresponding to the top 2 accuracy rates (for example, consensus node 5 and consensus node 6) as the consensus nodes corresponding to consensus partition 56MN.

[0115] Then calculate the accuracy of the transaction consensus of the remaining 4 consensus nodes for the transaction users corresponding to consensus partition 12 (i.e., partition 1 and partition 2), sort the accuracy from largest to smallest, and select the consensus nodes corresponding to the top 2 accuracy rates (for example, consensus node 7 and consensus node 8) as the consensus nodes corresponding to consensus partition 12.

[0116] Repeat the above steps until all consensus partitions have been assigned corresponding consensus nodes.

[0117] In the embodiments of this application, by arranging the accuracy rates in descending order, the consensus nodes corresponding to the top M accuracy rates are selected as the consensus nodes corresponding to the root consensus partition; the first accuracy rate of the transaction consensus of the consensus nodes that are not corresponding to the root consensus partition for the transaction users of the leaf node partitions of the root consensus partition is calculated, and the first M consensus nodes corresponding to the first accuracy rates are selected as the consensus nodes corresponding to the leaf node partitions of the root consensus partition; the consensus nodes that are not corresponding to the root consensus partition are updated based on the consensus nodes corresponding to the leaf node partitions of the root consensus partition, and the process returns to execution. The first accuracy rate of the consensus consensus of users in the leaf nodes of the root consensus partition is calculated for the consensus nodes that are not the consensus nodes corresponding to the root consensus partition. The top M consensus nodes with the highest first accuracy rates are selected as the consensus nodes corresponding to the leaf nodes of the root consensus partition. This process continues until consensus nodes are selected for each consensus partition in the binary consensus tree. This way, a corresponding consensus node is assigned to each consensus partition, and subsequent verification of the transactions of users in different partitions of that consensus partition can be performed based on the consensus nodes corresponding to that consensus partition. Since the data volume of the consensus nodes corresponding to the consensus partition is small, verification time is saved and verification efficiency is improved. Furthermore, since the consensus nodes assigned to each consensus partition are those with high verification accuracy for that consensus partition, the accuracy of the verification is also ensured.

[0118] In some embodiments of this application, in the prior art, when placing a transaction user into a partition in the blockchain, the user is usually assigned to a unique partition by calculating the unique primary key ID of each user's account through consistent hashing. However, if a transaction user has a large amount of transaction data, it may cause a serious imbalance in transaction data between different partitions, which may severely degrade the performance of the blockchain system.

[0119] To address the issue of imbalanced transaction data across different partitions in a blockchain, before constructing a binary consensus tree based on transaction users in different partitions of the blockchain, the aforementioned information verification method may further include:

[0120] Determine the scores for each partition where the transaction data of the target transaction user is located;

[0121] Based on the rating, target trading users are assigned to target partitions;

[0122] Correspondingly, the construction of a binary consensus tree based on transaction users in different partitions may specifically include:

[0123] A binary consensus tree is constructed based on the target trading users in different target partitions.

[0124] The target transaction user can be any one of the transaction users in the blockchain.

[0125] The target partition can be any of the partitions in the blockchain.

[0126] In one example, taking user A as the target transaction user, if user A's transaction data is stored in partition 1 and partition 2 respectively, the score of the partition where user A's transaction data is located (i.e., partition 1 and partition 2) is first obtained, and then user A can be assigned to a certain partition in the blockchain (i.e., the target partition) based on the score.

[0127] In the embodiments of this application, the scores of each partition where the transaction data of the target transaction user is located are determined; based on the scores, the target partition assigned to the target transaction user can be determined, thus accurately determining the partition where the transaction user is located and avoiding imbalance of transaction data in each partition.

[0128] In some embodiments of this application, determining the scores of each partition where the transaction data corresponding to the target transaction user is located may specifically include:

[0129] Obtain at least one attribute information of the partition where the transaction data of the target transaction user is located;

[0130] Based on the attribute information and the weights corresponding to each attribute information, the score of the partition where the transaction data of the target transaction user is located is calculated.

[0131] The attribute information can be the attribute information of the partition where the transaction data of the target transaction user is located. This attribute information may include, but is not limited to, the average CPU utilization of the partition over a period of time, the average memory utilization of the partition over a period of time, the average disk utilization of the partition over a period of time, and the average bandwidth utilization of the partition over a period of time.

[0132] In one example, taking user A as the target transaction user, if user A's transaction data is stored in partition 1 and partition 2 respectively, the attribute information of the partitions (i.e., partition 1 and partition 2) where user A's transaction data is located is first obtained. Then, based on the weights corresponding to each attribute information, the score of the partitions (i.e., partition 1 and partition 2) where user A's transaction data is located can be calculated according to the following formula (6):

[0133] score=(α*f cpu +β*f men +γ*f disk +μ*f net )*100 (6)

[0134] Among them, f cpu Let f be the average CPU utilization of the partition over a certain period of time, α be the weight of the average CPU utilization of the partition over a certain period of time, and f be the weight of the average CPU utilization of the partition over a certain period of time. men β represents the average memory utilization of a partition over a period of time, and f is the weight of the average memory utilization of a partition over a period of time. disk Let f be the average disk usage of the partition over a certain period of time, λ be the weight of the average disk usage of the partition over a certain period of time, and f be the weight of the average disk usage of the partition over a certain period of time. net α represents the average bandwidth utilization of the partition over a period of time, and μ represents the weight of the average bandwidth utilization of the partition over a period of time; α + β + λ + μ = 1.

[0135] In the embodiments of this application, at least one attribute information of the partition where the transaction data of the target transaction user is located is obtained; based on each attribute information and the weight corresponding to each attribute information, the score of the partition where the transaction data of the target transaction user is located is calculated. In this way, the score of the partition where the transaction data of the target transaction user is located can be accurately determined, and the target partition where the target transaction user is located can be determined according to the score, thereby further avoiding the imbalance of transaction data in each partition of the blockchain.

[0136] In some embodiments of this application, to further avoid imbalances in transaction data across different partitions of the blockchain, the allocation of target transaction users to target partitions based on scoring may specifically include:

[0137] The lowest score among the ratings is selected as the first rating;

[0138] Obtain the lowest score from other partitions that do not have transaction data corresponding to the target transaction user, and use it as the second score;

[0139] Calculate the quotient of the first and second ratings;

[0140] If the quotient is greater than the preset quotient, the transaction data of the target transaction user will be placed in the partition corresponding to the second score;

[0141] If the quotient is less than or equal to the preset quotient, the transaction data of the target transaction user will be placed in the partition corresponding to the first score.

[0142] The first rating can be the lowest rating among the ratings of the partition where the target trading user's transaction data is located.

[0143] The second rating can be a rating from other partitions where there is no corresponding transaction data for the target trading user.

[0144] In one example, taking user A as the target transaction user, there are four partitions in the blockchain: partition 1, partition 2, partition 3, and partition 4. If user A's transaction data is stored in partition 1 and partition 2, but not in partition 3 and partition 4, then the scores of the partitions where user A's transaction data is located (i.e., partition 1 and partition 2) are obtained. If the score of partition 1 is 8 points and the score of partition 2 is 6 points, then 6 points (i.e., the score corresponding to partition 2) is taken as the first score. If the score of partition 3 is 7 points and the score of partition 4 is 9 points, since 7 points is less than 9 points, then the score of partition 3, 7 points, is taken as the second score.

[0145] The preset quotient can be a threshold value for the quotient of the first and second scores that has been set in advance.

[0146] In one example, continuing with the example above, calculate the quotient of the first and second ratings (6 / 7 = 0.857). If the preset quotient is 0.5, then the quotient is greater than the preset quotient, and user A is placed in the partition corresponding to the second rating, i.e., partition 3. If the preset quotient is 0.9, then user A is placed in the partition corresponding to the first rating, i.e., partition 2.

[0147] In the embodiments of this application, the lowest score among the scores is selected as the first score, and then the lowest score of the scores of other partitions that do not have transaction data corresponding to the target transaction user is obtained as the second score; the quotient of the first score and the second score is calculated, and based on the correspondence between the quotient and the preset quotient, the target partition where the transaction data of the target transaction user is stored can be accurately determined, without causing an imbalance of transaction data in each partition of the blockchain.

[0148] To gain a clearer understanding of the allocation of target partitions to target trading users, such as Figure 3 The flowchart illustrating the implementation of allocating target partitions to target transaction users provided in this application embodiment is as follows: Figure 3 As shown, the process of allocating target partitions to target trading users includes the following steps 31-38.

[0149] Step 31: Obtain at least one attribute information of the partition where the transaction data of the target transaction user is located.

[0150] Step 32: Based on each attribute information and the corresponding weight of each attribute information, calculate the score of the partition where the transaction data of the target transaction user is located.

[0151] Step 33: Select the lowest score from the ratings as the first score.

[0152] Step 34: Obtain the lowest score of other partitions that do not have transaction data corresponding to the target transaction user, and use it as the second score.

[0153] Step 35: Calculate the quotient of the first score and the second score.

[0154] Step 36: Determine if the quotient is greater than the preset quotient. If yes, proceed to step 36; otherwise, proceed to step 37.

[0155] Step 37: Place the target user's transaction data in the partition corresponding to the second rating.

[0156] Step 38: Place the target user's transaction data in the partition corresponding to the first rating.

[0157] It should be noted that steps 31-38 have been described in the above embodiments and will not be repeated here.

[0158] Finally, step 130 is introduced: based on the consensus node corresponding to the consensus partition, the transaction corresponding to the transaction verification request is verified to obtain the verification result.

[0159] In some embodiments of this application, after determining the consensus partitions of the transaction users corresponding to different partitions of the transaction verification request, the transaction corresponding to the transaction verification request can be verified based on the consensus node corresponding to the consensus partition to obtain the verification result.

[0160] In one example, the transaction verification request corresponds to a transaction between user A in partition 1 and user B in partition 2, and then according to... Figure 2 The binary consensus tree shown determines the consensus partition of user A and user B as consensus partition 12. Then, based on the consensus node assigned to consensus partition 12, the transaction between user A and user B is verified to obtain the verification result.

[0161] In some embodiments of this application, to more clearly understand the information verification method provided in this application, the embodiments of this application also provide another possible implementation of the information verification method, such as... Figure 4 This is a flowchart illustrating another information verification method. (For example...) Figure 4 As shown, the information verification method provided in this application embodiment may specifically include steps 41-46.

[0162] Step 41: Based on the transaction count matrix corresponding to each partition in the blockchain, determine the leaf nodes with the same parent node in the binary consensus tree.

[0163] In some embodiments of this application, the number of transactions can be determined based on the transaction count matrix corresponding to each partition in the blockchain. Figure 2 In a binary consensus tree, leaf nodes with the same parent node can be identified. Figure 2 Partition 1 and partition 2 have the same parent node, and partition 3 and partition 4 have the same parent node.

[0164] Step 42: Update the parent node to a leaf node with the same parent node, and repeat step 41 to build a binary consensus tree.

[0165] In some embodiments of this application, the parent node is updated to a leaf node with the same parent node, and then the steps of determining two leaf nodes with a preset relationship as consensus partitions and forming the parent node of the leaf node of the consensus partition into a binary consensus tree are repeated until the two leaf nodes no longer have a preset relationship, thus forming a binary consensus tree. The specific process has been described in the above embodiments and will not be repeated here.

[0166] Step 43: Select the consensus node corresponding to the root consensus node of the binary consensus tree.

[0167] In some embodiments of this application, the consensus node corresponding to the root consensus node of the binary consensus tree can be selected by calculating the accuracy rate of the consensus nodes of each consensus node in each partition, arranging the accuracy rates in descending order, and selecting the consensus nodes corresponding to the top M accuracy rates as the consensus nodes corresponding to the root consensus partition. This will not be elaborated further here. Step 44: Select the corresponding consensus node for all consensus partitions in the binary consensus tree in a top-down manner.

[0168] In some embodiments of this application, by performing the above-described calculation of the first accuracy rate of the transaction consensus of the consensus nodes not corresponding to the root consensus partition for the transaction users of the leaf node partition of the root consensus partition, and selecting the top M consensus nodes corresponding to the first accuracy rate as the consensus nodes corresponding to the leaf node partition of the root consensus partition; updating the consensus nodes not corresponding to the root consensus partition based on the consensus nodes corresponding to the leaf node partitions of the root consensus partition, returning to perform the calculation of the first accuracy rate of the transaction consensus of the consensus nodes not corresponding to the root consensus partition for the transaction users of the leaf node partition of the root consensus partition, and selecting the top M consensus nodes corresponding to the first accuracy rate as the consensus nodes corresponding to the leaf node partition of the root consensus partition, until a consensus node is selected for each consensus partition in the binary consensus tree, corresponding consensus nodes can be selected for all consensus partitions in the binary consensus tree. Further details are omitted here.

[0169] Step 44: Receive transaction verification requests for transactions between users in different partitions of the blockchain.

[0170] Step 45: Based on the transaction verification request, obtain the consensus partition of the transaction user corresponding to the different partitions of the transaction verification request from the binary consensus tree.

[0171] Step 46: Based on the consensus node corresponding to the consensus partition, verify the transaction corresponding to the transaction verification request and obtain the verification result.

[0172] In some embodiments of this application, steps 44-46 are consistent with steps 110-130 in the above embodiments, and will not be described again here.

[0173] It should be noted that the information verification method provided in this application embodiment can be executed by an information verification device or a control module in the information verification device for executing the information verification method.

[0174] Based on the same inventive concept as the information verification method described above, this application also provides an information verification device. The following is in conjunction with… Figure 5The information verification device provided in the embodiments of this application will be described in detail.

[0175] Figure 5 This is a schematic diagram of the structure of an information verification device according to an exemplary embodiment.

[0176] like Figure 5 As shown, the information verification device 500 may include:

[0177] The receiving module 510 is used to receive a transaction verification request; wherein the transaction verification request is used to instruct the verification of transactions between users in different partitions of the blockchain;

[0178] The acquisition module 520 is used to acquire, based on the transaction verification request, the consensus partitions of the transaction users corresponding to different partitions in the binary consensus tree; wherein, the binary consensus tree includes N levels of consensus partitions, each level of consensus partition has partitions of at least two blockchains, and each partition stores at least one transaction user; N is a positive integer greater than or equal to 2;

[0179] The verification module 530 is used to verify the transaction corresponding to the transaction verification request based on the consensus node corresponding to the consensus partition, and obtain the verification result.

[0180] In the embodiments of this application, a receiving module receives a transaction verification request indicating that transactions between users in different partitions of the blockchain are to be verified. An acquisition module retrieves the consensus partitions of the users in different partitions corresponding to the transaction verification request from a binary consensus tree. Then, a verification module verifies the transaction corresponding to the transaction verification request based on the consensus node corresponding to the consensus partition, obtaining the verification result. Thus, when it is necessary to verify transactions between users in different partitions of the blockchain, the consensus partitions of the users in different partitions are obtained through a binary consensus tree, and then the transactions of users in different partitions are verified based on the consensus node corresponding to that consensus partition. This reduces the amount of data required for consensus node verification, improving the efficiency of consensus verification.

[0181] In some embodiments of this application, in order to further improve the transaction verification efficiency of transaction users in different partitions, the information verification device mentioned above may further include:

[0182] The building module is used to construct a binary consensus tree based on transaction users in different partitions of the blockchain;

[0183] The calculation module is used to calculate the accuracy of the consensus of each consensus node in the blockchain for the transaction consensus of the transaction users in each partition;

[0184] The selection module is used to select consensus nodes for each partition in the binary consensus tree based on the accuracy rate.

[0185] In some embodiments of this application, to further improve the verification efficiency of transactions for users in different partitions, the construction module may specifically include:

[0186] The first determining unit is used to determine each partition in the blockchain as a leaf node of the binary consensus tree;

[0187] The second determining unit is used to determine two partitions with a preset relationship as consensus partitions, and to form the consensus partitions as the parent nodes of the leaf nodes of the binary consensus tree.

[0188] The first construction unit is used to update each consensus partition into two partitions, return to execute the determination of two partitions with a preset relationship as consensus partitions, and form the parent node of the leaf node of the consensus partition into the parent node of the leaf node of the binary consensus tree until the two partitions no longer have the preset relationship, thus forming the binary consensus tree.

[0189] In some embodiments of this application, the building module may further include:

[0190] The acquisition unit is used to acquire the number of transactions initiated by each user in each partition of the blockchain;

[0191] The second construction unit is used to construct a transaction count matrix corresponding to each partition based on the number of transactions.

[0192] A calculation unit is used to calculate the similarity between the transaction frequency matrices of every two partitions;

[0193] The third determining module is used to determine the two partitions with the highest similarity as two partitions with a preset relationship.

[0194] In some embodiments of this application, in order to further improve the transaction verification efficiency of trading users in different partitions, the calculation module may specifically be used for:

[0195] Obtain the first number of times that the consensus nodes of the blockchain correctly verified the transaction consensus of the transaction users in each partition, and the second number of times that the consensus nodes failed to verify the transaction consensus of the transaction users in each partition.

[0196] Based on the first and second counts, the accuracy of each consensus node's consensus on the transactions of users in each partition is determined.

[0197] In some embodiments of this application, in order to further improve the efficiency of transaction verification for trading users in different partitions, the selection module may specifically be used for:

[0198] Arrange the accuracy rates in descending order, and select the consensus nodes corresponding to the top M accuracy rates as the consensus nodes corresponding to the root consensus partition; wherein, the root consensus partition is the top-level consensus partition of the binary consensus tree; M is a positive integer;

[0199] Calculate the first accuracy rate of the consensus nodes that are not the consensus nodes corresponding to the root consensus partition for the transaction users of the leaf node partition of the root consensus partition, and select the top M consensus nodes with the first accuracy rate as the consensus nodes corresponding to the leaf node partition of the root consensus partition.

[0200] The consensus nodes corresponding to the leaf nodes of the root consensus partition are updated based on the consensus nodes of the leaf nodes of the root consensus partition. The first accuracy rate of the transaction consensus of the consensus nodes of the leaf nodes of the root consensus partition is calculated based on the consensus nodes of the leaf nodes of the root consensus partition. The top M consensus nodes with the highest first accuracy rates are selected as the consensus nodes corresponding to the leaf nodes of the root consensus partition, until consensus nodes are selected for each consensus partition in the binary consensus tree.

[0201] In some embodiments of this application, in order to maintain the balance of transaction data in different partitions of the blockchain, the aforementioned information verification device may further include:

[0202] The first determination module is used to determine the scores of each partition where the transaction data of the target transaction user is located;

[0203] The allocation module is used to allocate the target trading user to a target partition based on the score;

[0204] The building module can be specifically used for:

[0205] A binary consensus tree is constructed based on the target trading users in different target partitions.

[0206] In some embodiments of this application, the first determining module may specifically be used for:

[0207] Obtain at least one attribute information of the partition where the transaction data corresponding to the target transaction user is located;

[0208] Based on each attribute information and the weight corresponding to each attribute information, the score of the partition where the transaction data of the target transaction user is located is calculated.

[0209] In some embodiments of this application, in order to further maintain the balance of transaction data in different partitions of the blockchain, the allocation module may specifically be used for:

[0210] The lowest score among the scores is selected as the first score;

[0211] The lowest score among the scores of other partitions that do not have transaction data corresponding to the target transaction user is used as the second score;

[0212] Calculate the quotient between the first score and the second score;

[0213] If the quotient is greater than the preset quotient, the transaction data of the target transaction user will be placed in the partition corresponding to the second score;

[0214] If the quotient is less than or equal to a preset quotient, the transaction data of the target transaction user will be placed in the partition corresponding to the first rating.

[0215] The information verification device provided in this application embodiment can be used to execute the information verification methods provided in the above method embodiments. The implementation principle and technical effect are similar, and will not be described in detail here for the sake of brevity.

[0216] Based on the same inventive concept, embodiments of this application also provide an electronic device.

[0217] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example... Figure 6 As shown, the electronic device may include a processor 601 and a memory 602 storing computer programs or instructions.

[0218] Specifically, the processor 601 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of the present invention.

[0219] Memory 602 may include mass storage for data or instructions. For example, and not limitingly, memory 602 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 602 may include removable or non-removable (or fixed) media. Where appropriate, memory 602 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 602 is non-volatile solid-state memory. Memory may include read-only memory (ROM), random-access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, a memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described in the information verification method provided in the above embodiments.

[0220] The processor 601 implements any of the information verification methods described in the above embodiments by reading and executing computer program instructions stored in the memory 602.

[0221] In one example, the electronic device may also include a communication interface 603 and a bus 610. For example, Figure 6 As shown, the processor 601, memory 602, and communication interface 603 are connected through bus 610 and complete communication with each other.

[0222] The communication interface 603 is mainly used to realize communication between various modules, devices, units and / or devices in the embodiments of the present invention.

[0223] Bus 610 includes hardware, software, or both, that couples components of an electronic device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 610 may include one or more buses. Although specific buses are described and illustrated in embodiments of the invention, the invention contemplates any suitable bus or interconnect.

[0224] The electronic device can execute the information verification method in the embodiments of the present invention, thereby achieving... Figure 1 and Figure 4 The described information verification method.

[0225] Furthermore, in conjunction with the information verification methods in the above embodiments, this invention can be implemented using a readable storage medium. This readable storage medium stores program instructions; when these program instructions are executed by a processor, they implement any of the information verification methods described in the above embodiments.

[0226] It should be clarified that the present invention is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of the present invention.

[0227] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this invention are programs or code segments used to perform the required tasks. The programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried in a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0228] It should also be noted that the exemplary embodiments mentioned in this invention describe methods or systems based on a series of steps or apparatus. However, this invention is not limited to the order of the steps described above; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0229] The aspects of this application have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by dedicated hardware performing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0230] The above description is merely a specific embodiment of the present invention. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the protection scope of the present invention.

Claims

1. An information verification method, characterized in that, The method includes: Each partition in the blockchain is designated as a leaf node of a binary consensus tree; each partition stores at least one transaction user. Get the number of transactions initiated by each user in each partition of the blockchain; Based on the aforementioned number of transactions, construct a transaction count matrix for each partition; Calculate the similarity between the transaction frequency matrices of every two partitions; The two partitions with the highest similarity are identified as having a preset relationship. Two partitions with a preset relationship are identified as consensus partitions, and the consensus partitions are used as the parent nodes of the leaf nodes of the binary consensus tree. Update each consensus partition to two partitions, return to the execution and determine the two partitions with a preset relationship as consensus partitions, and form the parent node of the leaf node of the binary consensus tree with the consensus partitions until the two partitions no longer have the preset relationship, thus forming the binary consensus tree; Calculate the accuracy of the consensus of each consensus node in the blockchain for the transaction consensus of the transaction users in each partition; Based on the accuracy rate, consensus nodes are selected for each partition in the binary consensus tree; Receive a transaction verification request; wherein the transaction verification request is used to instruct the verification of transactions between users in different partitions of the blockchain; Based on the transaction verification request, the consensus partitions of the transaction users corresponding to different partitions of the transaction verification request are obtained from the binary consensus tree; wherein, the binary consensus tree includes N levels of consensus partitions, each level of consensus partition has partitions of at least two blockchains, and each partition stores at least one transaction user; N is a positive integer greater than or equal to 2; Based on the consensus node corresponding to the consensus partition, the transaction corresponding to the transaction verification request is verified to obtain the verification result.

2. The method according to claim 1, characterized in that, The calculation of the accuracy of the consensus consensus of each consensus node in the blockchain for the transaction consensus of transaction users in each partition includes: Obtain the first number of times that the consensus nodes of the blockchain correctly verified the transaction consensus of the transaction users in each partition, and the second number of times that the consensus nodes failed to verify the transaction consensus of the transaction users in each partition. Based on the first and second counts, the accuracy of each consensus node's consensus on the transactions of users in each partition is determined.

3. The method according to claim 1, characterized in that, Based on the accuracy rate, consensus nodes are selected for each partition in the binary consensus tree, including: Arrange the accuracy rates in descending order, and select the consensus nodes corresponding to the top M accuracy rates as the consensus nodes corresponding to the root consensus partition; wherein, the root consensus partition is the top-level consensus partition of the binary consensus tree; M is a positive integer; Calculate the first accuracy of the consensus nodes that are not the consensus nodes corresponding to the root consensus partition for the transaction users of the leaf node partition of the root consensus partition, and select the top M consensus nodes with the first accuracy as the consensus nodes corresponding to the leaf node partition of the root consensus partition. The consensus nodes corresponding to the leaf nodes of the root consensus partition are updated based on the consensus nodes of the leaf nodes of the root consensus partition. The first accuracy of the transaction consensus of the consensus nodes of the leaf nodes of the root consensus partition is calculated based on the consensus nodes of the leaf nodes of the root consensus partition. The top M consensus nodes with the highest first accuracy are selected as the consensus nodes corresponding to the leaf nodes of the root consensus partition, until consensus nodes are selected for each consensus partition in the binary consensus tree.

4. The method according to any one of claims 1-3, characterized in that, Before constructing the binary consensus tree among transaction users in different partitions of the blockchain, the method further includes: Determine the scores for each partition where the transaction data of the target transaction user is located; Based on the rating, the target trading user will be assigned to the target partition; The construction of a binary consensus tree based on transaction users in different partitions includes: A binary consensus tree is constructed based on the target trading users in different target partitions.

5. The method according to claim 4, characterized in that, The determination of the scores for each partition where the transaction data corresponding to the target transaction user is located includes: Obtain at least one attribute information of the partition where the transaction data corresponding to the target transaction user is located; Based on each attribute information and the weight corresponding to each attribute information, the score of the partition where the transaction data of the target transaction user is located is calculated.

6. The method according to claim 4, characterized in that, The process of assigning the target trading user to the target partition based on the score includes: The lowest score among the scores is selected as the first score; The lowest score among the scores of other partitions that do not have transaction data corresponding to the target transaction user is used as the second score; Calculate the quotient between the first score and the second score; If the quotient is greater than the preset quotient, the transaction data of the target transaction user will be placed in the partition corresponding to the second score; If the quotient is less than or equal to a preset quotient, the transaction data of the target transaction user will be placed in the partition corresponding to the first rating.

7. An information verification device for performing the method as described in claim 1, characterized in that, The device includes: A receiving module is used to receive transaction verification requests; wherein the transaction verification request is used to instruct the verification of transactions between users in different partitions of the blockchain; The acquisition module is used to acquire the consensus partitions of the transaction users corresponding to different partitions of the transaction verification request from the binary consensus tree based on the transaction verification request; wherein, the binary consensus tree includes N levels of consensus partitions, each level of consensus partition has partitions of at least two blockchains, and each partition stores at least one transaction user; N is a positive integer greater than or equal to 2; The verification module is used to verify the transaction corresponding to the transaction verification request based on the consensus node corresponding to the consensus partition, and obtain the verification result.

8. An electronic device, characterized in that, The electronic device includes: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, it implements the information verification method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the information verification method as described in any one of claims 1-6.

10. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device performs the information verification method as described in any one of claims 1-6.

Images