Verification method, device, equipment and readable storage medium

Abstract

The application discloses a kind of verification method, device, equipment and readable storage medium, belong to computer technical field, the method includes: in response to the first target node receives payment transaction request, based on the generation condition of knowledge argumentation, the knowledge argumentation generated by node in first network is obtained;Knowledge argumentation is used to prove the authenticity of payment transaction request;First network includes first target node;Based on the node in second network, the knowledge argumentation is verified, and the first verification result generated by node in second network is obtained;In the case where first verification result does not satisfy verification pass condition, the transaction information carried by payment transaction request and first verification result are verified, and the second verification result generated by node in second network is obtained;Second verification result is used to represent whether first verification result is correct and whether to execute payment transaction request.The method can improve the accuracy of verification.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and specifically relates to a verification method, apparatus, device, and readable storage medium. Background Technology

[0002] In a blockchain network, nodes must verify received payment transaction requests and generate corresponding blocks upon successful verification. However, in related technologies, consensus verification is primarily achieved through nodes across the entire blockchain network. If some nodes malfunction, it can easily lead to verification errors in the blockchain network, reducing the accuracy of the verification. Summary of the Invention

[0003] This application provides a verification method, apparatus, device, and readable storage medium to solve the problem of low verification accuracy.

[0004] In a first aspect, embodiments of this application provide a verification method applied in a blockchain network, the blockchain network comprising: a first network and a second network, wherein nodes in the first network are used to perform knowledge argument generation, transaction preprocessing and knowledge argument distribution operations, and nodes in the second network are used to verify knowledge arguments;

[0005] The method includes:

[0006] In response to the first target node receiving a payment transaction request, a knowledge argument generated by a node in the first network is obtained based on preset generation conditions for knowledge argumentation; the knowledge argumentation is used to prove the authenticity of the payment transaction request; the first network includes the first target node;

[0007] The knowledge argument is verified based on the nodes in the second network to obtain the first verification result generated by the nodes in the second network;

[0008] If the first verification result does not meet the verification pass condition, the transaction information carried by the payment transaction request and the first verification result are verified to obtain the second verification result generated by the node in the second network;

[0009] The second verification result is used to characterize whether the first verification result is correct and whether the payment transaction request is executed.

[0010] Optionally, the knowledge proof includes: zero-knowledge scalable transparent knowledge proof and zero-knowledge concise non-interactive knowledge proof. The response before the first target node receives the payment transaction request further includes:

[0011] Determine a first vector corresponding to each node in the blockchain network; the first vector is determined based on at least one of the performance parameters, network performance parameters, and load parameters when the node performs a first operation, wherein the first operation includes generating a knowledge proof or verifying a knowledge proof.

[0012] Based on the first vector corresponding to each node in the first network, a first clustering process is performed on each node in the first network to obtain a first type of node, a second type of node, and a third type of node after clustering; the first type of node is used to generate the scalable and transparent knowledge argument of the zero knowledge, the second type of node is used to generate the concise non-interactive knowledge argument of the zero knowledge, and the third type of node is used to perform the transaction preprocessing and the distribution operation.

[0013] Based on the first vector corresponding to each node in the second network, a second clustering process is performed on each node in the second network to obtain a verification subgroup, wherein the verification subgroup includes at least one node in the second network; wherein the verification subgroup is used to verify the knowledge argument and obtain the first verification result.

[0014] Optionally, if the first verification result does not meet the verification pass condition, verifying the transaction information carried in the payment transaction request and the first verification result to obtain a second verification result generated by a node in the second network includes:

[0015] If the first verification result does not meet the verification pass conditions, an arbitration group shall be determined;

[0016] The arbitration panel verifies the transaction information and the first verification result to obtain the second verification result generated by the arbitration panel.

[0017] The nodes in the arbitration group are some of the nodes in the verification subgroup, and the second verification result is determined based on the voting results of the nodes in the arbitration group and the voting weights of each node in the arbitration group.

[0018] Optionally, the preset generation conditions for knowledge argumentation include at least one of the following: whether the proportion of the first type of nodes in the blockchain network is greater than or equal to a preset proportion threshold; or whether the inter-node link delay parameter included in the network performance parameters is greater than or equal to a preset delay threshold.

[0019] The process of obtaining knowledge arguments generated by nodes in the first network based on preset generation conditions for knowledge arguments includes:

[0020] When the preset generation conditions for knowledge argumentation satisfy the fact that the proportion is greater than the preset proportion threshold, scalable transparent knowledge argumentation of the zero knowledge generated by the first type of node in the first network is obtained.

[0021] When the preset generation conditions for knowledge argument satisfy the condition that the inter-node link delay parameter is greater than the preset delay threshold, the zero-knowledge concise non-interactive knowledge argument generated by the second type of node in the first network is obtained.

[0022] Optionally, the first vector includes: CPU score, bandwidth stability coefficient, local load factor, historical verification efficiency weight, and reputation value; the CPU score represents the computing performance of the node, the bandwidth stability coefficient represents the network stability and bandwidth of the node, the local load factor represents the load of the node, the historical verification efficiency weight represents the weight of the node in historical verification, and the reputation value represents the accuracy and response time of the node in historical verification.

[0023] Determining the first vector corresponding to each node in the blockchain network includes:

[0024] Based on the performance parameters of the second target node when performing the first operation, and the corresponding preset weights, the CPU score value corresponding to the second target node is determined; the blockchain network includes the second target node;

[0025] The bandwidth stability coefficient value is determined by detecting the latency parameter when sending a UDP packet to the second target node and receiving the UDP packet through the second target node; the network performance parameter includes the latency parameter.

[0026] The local load factor value of the second target node is determined based on the load parameters;

[0027] The reputation value is determined based on the accuracy, error rate, and response rate of the second target node during historical verification.

[0028] Optionally, the method further includes:

[0029] The third target node in the verification subgroup whose arbitration weight is greater than a preset weight threshold is designated as a node of the arbitration group.

[0030] The arbitration weight is determined based on the CPU score of the third target node, the number of data transfer hops between the third target node and the first target node, and the reputation value of the third target node.

[0031] Optionally, the first vector includes: a bandwidth stability coefficient value; based on the first vector corresponding to each node in the second network, a second clustering process is performed on each node in the second network to obtain a verification subgroup, including:

[0032] The first matrix is ​​determined based on the bandwidth stability coefficient values ​​corresponding to each node in the second network.

[0033] The second matrix is ​​obtained based on the preset degree matrix and the first matrix;

[0034] The distance between each node in the second network is determined by calculating the second matrix using the Euclidean distance algorithm.

[0035] Clustering is performed on nodes in the second network whose distance values ​​are less than a preset distance threshold to obtain the verification subgroup.

[0036] Optionally, the verification pass condition includes at least one of the following:

[0037] The nodes in the verification subgroup that exceed the first preset value are determined to have passed the knowledge argument verification.

[0038] Alternatively, the predetermined number of fourth target nodes determine that the knowledge argument verification has passed;

[0039] Wherein, if the verification time of the fifth target node exceeds the preset verification time, the verification of the fifth target node fails. The verification subgroup includes: the fifth target node; the fourth target node is a node in the verification subgroup whose node location distance exceeds a preset location distance, and the node location distance is the distance of the device where the node is located.

[0040] Secondly, this application provides a verification device, characterized in that the device is applied in a blockchain network, the blockchain network including: a first network and a second network, wherein nodes in the first network are used to perform knowledge argument generation, transaction preprocessing and knowledge argument distribution operations, and nodes in the second network are used to verify knowledge arguments;

[0041] The verification device includes:

[0042] A generation module is used to respond to a first target node receiving a payment transaction request, and to obtain a knowledge argument generated by a node in the first network based on preset generation conditions for knowledge argumentation; the knowledge argument is used to prove the authenticity of the payment transaction request; the first network includes the first target node;

[0043] The first verification module is used to verify the knowledge argument based on the nodes in the second network, and obtain the first verification result generated by the nodes in the second network;

[0044] The second verification module is used to verify the transaction information carried in the payment transaction request and the first verification result when the first verification result does not meet the verification pass conditions, so as to obtain the second verification result generated by the node in the second network.

[0045] The second verification result is used to characterize whether the first verification result is correct and whether the payment transaction request is executed.

[0046] Thirdly, embodiments of this application provide an electronic device, including: a processor, a memory, and a program stored in the memory and executable on the processor, wherein when the program is executed by the processor, it implements the steps of the verification method as described in the first aspect.

[0047] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the verification method as described in the first aspect.

[0048] Fifthly, embodiments of this application provide a computer program product, including computer instructions that, when executed by a processor, implement the steps of the verification method as described in the first aspect.

[0049] As can be seen from the embodiments of this application, after receiving a payment transaction request, the first target node can obtain a knowledge proof generated by nodes in the first network based on preset generation conditions of the knowledge proof. Then, the knowledge proof is verified by nodes in the second network to obtain a first verification result generated by nodes in the second network. If the first verification result does not meet the verification pass conditions, the transaction information carried in the payment transaction request and the first verification result are verified to obtain a second verification result generated by nodes in the second network. It is understood that even if a node in the second network malfunctions, causing an error in the first verification result, the transaction information carried in the payment transaction request and the first verification result can be verified again to improve the accuracy of verification and the security of the blockchain network. Attached Figure Description

[0050] Figure 1 This is one of the flowcharts illustrating a verification method provided in an embodiment of this application;

[0051] Figure 2 This is a schematic diagram of a process for obtaining the first type of nodes, the second type of nodes, and the third type of nodes after clustering, as well as the verification subgroup, provided in an embodiment of this application.

[0052] Figure 3This is a schematic diagram of a process for generating knowledge arguments provided in an embodiment of this application;

[0053] Figure 4 This is a schematic diagram of a process for verifying knowledge argumentation provided in an embodiment of this application;

[0054] Figure 5 This is a second schematic flowchart of a verification method provided in an embodiment of this application;

[0055] Figure 6 This is a schematic diagram of the structure of a price calculation device provided in an embodiment of this application;

[0056] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0057] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0058] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and are not used to describe a specified order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first" and "second" are generally of the same class, not limited in number; for example, a first object can be one or more. Furthermore, in the specification and claims, "and" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0059] It is worth noting that the technologies described in this application are not limited to Long Term Evolution (LTE) / LTE-Advanced (LTE-A) systems, but can also be used in other wireless communication systems, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Single-carrier Frequency-Division Multiple Access (SC-FDMA), and other systems. The terms "system" and "network" in this application are often used interchangeably, and the described technologies can be used with the systems and radio technologies mentioned above, as well as with other systems and radio technologies. However, the following description describes New Radio (NR) systems for illustrative purposes, and NR terminology is used in most of the following description. These technologies can also be applied to applications beyond NR systems, such as 6th generation (6G) radio systems. th Generation 6G communication system.

[0060] The embodiments of this application can be applied to a blockchain network, which includes a first network and a second network. Nodes in the first network are used to perform knowledge argument generation, transaction preprocessing and knowledge argument distribution operations, and nodes in the second network are used to verify knowledge arguments.

[0061] The following is through Figure 1 The verification method of this application is described in detail below. The specific steps are as follows:

[0062] Step 101: In response to the first target node receiving a payment transaction request, a knowledge argument generated by a node in the first network is obtained based on the preset generation conditions of the knowledge argument; the knowledge argument is used to prove the authenticity of the payment transaction request; the first network includes the first target node.

[0063] In this embodiment, nodes in the first network can receive payment transaction requests, and at least one node in the first network can obtain the knowledge proof corresponding to the payment transaction request based on preset generation conditions of the knowledge proof, so as to prove the authenticity of the payment transaction request. If a node in the second network subsequently determines that the knowledge proof has passed verification, the blockchain network generates the block corresponding to the payment transaction request and executes the payment transaction request.

[0064] In some embodiments, the knowledge argumentation includes: scalable and transparent zero-knowledge knowledge argumentation and concise non-interactive zero-knowledge knowledge argumentation. The response prior to the first target node receiving the payment transaction request further includes:

[0065] Determine a first vector corresponding to each node in the blockchain network; the first vector is determined based on at least one of the performance parameters, network performance parameters, and load parameters when the node performs a first operation, wherein the first operation includes generating a knowledge proof or verifying a knowledge proof.

[0066] Based on the first vector corresponding to each node in the first network, a first clustering process is performed on each node in the first network to obtain a first type of node, a second type of node, and a third type of node after clustering; the first type of node is used to generate the scalable and transparent knowledge argument of the zero knowledge, the second type of node is used to generate the concise non-interactive knowledge argument of the zero knowledge, and the third type of node is used to perform the transaction preprocessing and the distribution operation.

[0067] Based on the first vector corresponding to each node in the second network, a second clustering process is performed on each node in the second network to obtain a verification subgroup, wherein the verification subgroup includes at least one node in the second network; wherein the verification subgroup is used to verify the knowledge argument and obtain the first verification result.

[0068] In this embodiment, the first clustering process can be K-means++ clustering, and the second clustering process can be a fusion of topological embedding and spectral clustering.

[0069] The following section will explain in detail the process of performing the first clustering process on each node in the first network to obtain the first, second, and third clustered nodes.

[0070] After determining the first vector corresponding to each node in the blockchain network, feature extraction can be performed on the first vector corresponding to each node to obtain the feature value corresponding to each node. This feature value can characterize the node capability of each node. Then, K-means++ clustering is performed on the feature values ​​corresponding to each node. Nodes with feature values ​​greater than or equal to a first preset threshold are classified as first-class nodes, nodes with feature values ​​greater than or equal to a second preset threshold but less than the first preset threshold are classified as second-class nodes, and nodes with feature values ​​less than the second preset threshold are classified as third-class nodes. The first preset threshold can be 0.8, and the second preset threshold can be 0.5.

[0071] In some embodiments, the first type of node can generate not only zero-knowledge scalable and transparent knowledge arguments, but also other computationally intensive knowledge arguments. The second type of node can generate not only zero-knowledge concise non-interactive knowledge arguments, but also other memory-optimized knowledge arguments. No limitations are imposed here.

[0072] The process of performing a second clustering on each node in the second network to obtain the verification subgroup will be explained in detail below.

[0073] In some embodiments, the first vector includes: a bandwidth stability coefficient value; based on the first vector corresponding to each node in the second network, a second clustering process is performed on each node in the second network to obtain a verification subgroup, including:

[0074] The first matrix is ​​determined based on the bandwidth stability coefficient values ​​corresponding to each node in the second network.

[0075] The second matrix is ​​obtained based on the preset degree matrix and the first matrix;

[0076] The distance between each node in the second network is determined by calculating the second matrix using the Euclidean distance algorithm.

[0077] Clustering is performed on nodes in the second network whose distance values ​​are less than a preset distance threshold to obtain the verification subgroup.

[0078] In this embodiment, the inter-node link delay parameters for each node are first determined based on the bandwidth stability coefficient values ​​corresponding to each node in the second network, and a multi-dimensional first matrix is ​​obtained based on these parameters. Then, the first matrix is ​​subjected to dimensionality reduction processing; for example, the multi-dimensional first matrix can be reduced to a 3-dimensional space using a multi-dimensional scaling algorithm.

[0079] Then, based on the preset degree matrix and the first matrix, the second matrix is ​​determined. The calculation formula can be: ,in, This is the second matrix, which can also be called the Laplace matrix. For the preset degree matrix, This is the first matrix.

[0080] Then obtain the first k eigencomponents from the second matrix, where, k can represent the node coordinates. This represents the total number of nodes in the entire blockchain network, which can be obtained by collecting node information across the entire blockchain network in real time using a lightweight probe.

[0081] Then, the Euclidean distance algorithm is used to calculate the first k feature components in the second matrix to determine the distance between each node in the second network. Nodes in the second network whose distance values ​​are less than a preset distance threshold are clustered to obtain the verification subgroup.

[0082] Understandably, in this embodiment, by performing Euclidean distance calculation and clustering on the second matrix, the nodes in the final verification subgroup can be made to be dually adjacent in terms of physical topology and performance space, which facilitates the subsequent verification of knowledge arguments through the verification subgroup.

[0083] Understandably, in the above embodiments, the first clustering process and the second clustering process respectively obtain the first type of nodes, the second type of nodes and the third type of nodes after clustering, as well as the verification subgroup. This facilitates the subsequent generation of knowledge arguments through the first type of nodes and the second type of nodes, and facilitates the distribution of transaction preprocessing and knowledge arguments through the third type of nodes. It also facilitates the subsequent verification of knowledge arguments through the verification subgroup.

[0084] The following is through Figure 2 The process of clustering is explained.

[0085] Step 201: Determine the first vector corresponding to each node in the blockchain network.

[0086] Step 202: Perform the first clustering process on the first vector corresponding to each node in the first network to obtain the first, second and third clustered nodes.

[0087] Step 203: Determine the first matrix based on the bandwidth stability coefficient values ​​in the first vector corresponding to each node in the second network.

[0088] Step 204: Perform dimensionality reduction on the first matrix to obtain the dimensionality-reduced first matrix.

[0089] Step 205: Obtain the second matrix based on the preset degree matrix and the first matrix after dimensionality reduction.

[0090] Step 206: Obtain the first k eigencomponents in the second matrix.

[0091] Step 207: Calculate the distance between the first k feature components in the second matrix using the Euclidean distance algorithm.

[0092] Step 208: Cluster the nodes in the second network whose distance values ​​are less than the preset distance threshold to obtain the verification subgroup.

[0093] Through steps 201-208 above, we can obtain the first, second, and third clustered nodes, as well as the validation subgroup.

[0094] The following section explains the process of generating the first vector corresponding to each node in the blockchain network before clustering.

[0095] In some embodiments, the first vector includes: a CPU score, a bandwidth stability coefficient, a local load factor, a historical verification efficiency weight, and a reputation value; the CPU score represents the computing performance of the node, the bandwidth stability coefficient represents the network stability and bandwidth of the node, the local load factor represents the load of the node, the historical verification efficiency weight represents the weight of the node in historical verification, and the reputation value represents the accuracy and response time of the node in historical verification.

[0096] Determining the first vector corresponding to each node in the blockchain network includes:

[0097] Based on the performance parameters of the second target node when performing the first operation, and the corresponding preset weights, the CPU score value corresponding to the second target node is determined; the blockchain network includes the second target node;

[0098] The bandwidth stability coefficient value is determined by detecting the latency parameter when sending a UDP packet to the second target node and receiving the UDP packet through the second target node; the network performance parameter includes the latency parameter.

[0099] The local load factor value of the second target node is determined based on the load parameters;

[0100] The reputation value is determined based on the accuracy, error rate, and response rate of the second target node during historical verification.

[0101] In this embodiment, the first vector includes: a Central Processing Unit (CPU) score, a bandwidth stability coefficient, a local load factor, a historical verification efficiency weight, and a reputation value. The second target node can be any node in the blockchain network, and all nodes in the blockchain network determine the first vector in the same way.

[0102] Optionally, the first vector can be characterized as ,in Let be the first vector. CPU score This is the bandwidth stability coefficient value. This is the local load factor value. For historical verification of efficiency weight values, This is the reputation score. Raw data parameters such as performance parameters, network performance parameters, and load parameters of a node during its first operation can be collected. Based on these raw data parameters, a CPU score, bandwidth stability coefficient, local load factor, historical verification efficiency weight, and reputation score can be obtained.

[0103] The performance parameter for a node executing its first operation can refer to the time it takes for the node to generate or verify at least one knowledge proof. For example, the first operation could be a zero-knowledge proof operation such as hashing based on a sponge structure, elliptic curve multiplication, or fast Fourier transform. Based on the time it takes for the node to generate or verify at least one knowledge proof, and the corresponding preset weights, a CPU score is determined for the node. For example, determining the time it takes for the node to execute a hashing operation based on a sponge structure. Determine the time required for a node to perform an elliptic curve dot product operation. Determine the time required for the node to perform the Fast Fourier Transform operation. And determine the weight of each operation using the formula: ,get One type of hash operation based on a sponge structure has a weight of... The weights corresponding to the dot product operation of elliptic curves are: The weights corresponding to the Fast Fourier Transform operation are .

[0104] Multipath active probing technology can also be employed to send User Datagram Protocol (UDP) packets, Internet Control Message Protocol (ICMP) packets, and Subscriber Identity Module (SIM) packets to nodes. This allows for the determination of latency parameters detected when nodes receive UDP packets, ICMP packets, and SIM data tables. These latency parameters can be characterized as follows: , , Electronic devices are then re-determined. , , The largest value in and minimum value Through the formula: Determine the current congestion state value of the node. .exist If the value is ≥2.0, the node is determined to be in a congested state, and the bandwidth stability coefficient value corresponding to the congested state is determined.

[0105] Load parameters may include: the length of the queue of transactions to be verified, the historical time statistics of zero-knowledge proof verification, etc., and the local load factor value of the node is determined based on the length of the queue of transactions to be verified and the historical time statistics of zero-knowledge proof verification.

[0106] Optionally, the matching rate (or accuracy) of a node can be determined based on its historical verification results and the final consensus result. The formula can be... The error rate can also be determined based on the proportion of nodes judged as errors in shard verification; the formula can be... The response timeliness (or response rate) can also be determined based on the probability that a node returns a verification result within a preset verification time during the verification process. The formula can be: It can also identify malicious behavior records of nodes. For example, if a node exhibits abnormal behavior such as forging verification results or frequent timeouts, a penalty mechanism will be triggered, and its reputation value will be lowered.

[0107] Then, using the formula: To determine the reputation value, among which... Weights are assigned to accuracy, error rate, response rate, and malicious behavior records, respectively. The penalty value corresponding to the recording of malicious behavior. The entropy weight method can be used to dynamically allocate the weights, and... Each time a node completes its first operation, it collects new data in real time and updates its reputation value.

[0108] Understandably, in this embodiment, determining the first vector of a node facilitates subsequent clustering operations to identify nodes of different classes, validation subgroups, arbitration groups, etc.

[0109] After identifying the different types of nodes in the first network and the verification subgroup in the second network, the knowledge proof corresponding to the payment transaction request can be generated based on the preset generation conditions of the knowledge proof.

[0110] Optionally, the preset generation conditions for knowledge argumentation include at least one of the following: whether the proportion of the first type of nodes in the blockchain network is greater than or equal to a preset proportion threshold; or whether the inter-node link delay parameter included in the network performance parameters is greater than or equal to a preset delay threshold.

[0111] The process of obtaining knowledge arguments generated by nodes in the first network based on preset generation conditions for knowledge arguments includes:

[0112] When the preset generation conditions for knowledge argumentation satisfy the fact that the proportion is greater than the preset proportion threshold, scalable transparent knowledge argumentation of the zero knowledge generated by the first type of node in the first network is obtained.

[0113] When the preset generation conditions for knowledge argument satisfy the condition that the inter-node link delay parameter is greater than the preset delay threshold, the zero-knowledge concise non-interactive knowledge argument generated by the second type of node in the first network is obtained.

[0114] In this embodiment, when the proportion of the first type of nodes in the blockchain network is greater than or equal to a preset proportion threshold, zero-knowledge scalable transparent knowledge proofs are generated through the first type of nodes. Furthermore, the proof can be broken down into... Parallel columns, , This represents the number of nodes in the first category. The preset percentage can be 30%.

[0115] Lightweight probes deployed at the edge of the blockchain network can be used to continuously collect inter-node link latency parameters, which reflect network latency fluctuations. When the inter-node link latency parameters are greater than or equal to a preset latency threshold, the second type of node generates concise, non-interactive knowledge arguments with zero knowledge to generate a tree-like dependency chain and reduce cross-group communication.

[0116] The network latency variance can also be determined by the latency parameter. When the network latency variance is greater than or equal to a preset variance threshold, the second type of node generates concise, non-interactive knowledge arguments with zero knowledge to generate tree-like dependency chains and reduce cross-group communication. The preset variance threshold can be 15%.

[0117] In the process of generating knowledge proofs, nodes in the first network can also perform homomorphic encryption and compression on the transaction data to reduce the amount of input data, thereby achieving adaptive matching and efficient generation of proof strategies and network states. For example, the amount of input data can be reduced to its original size. λ is a security parameter, λ≥128, and the specific value of λ can be set according to the security requirements of the actual payment scenario.

[0118] Understandably, in this embodiment, the state of the blockchain network can be determined by the proportion of the first type of nodes in the blockchain network and the inter-node link delay parameters, and knowledge arguments matching the state can be generated.

[0119] pass Figure 3 The process of generating knowledge argumentation is explained.

[0120] Step 301: Whether the proportion of the first type of nodes in the blockchain network is greater than or equal to the preset proportion threshold.

[0121] Step 302: When the proportion of the first type of nodes in the blockchain network is greater than or equal to the preset proportion threshold, generate zero-knowledge scalable transparent knowledge arguments through the first type of nodes.

[0122] Step 303: Whether the inter-node link delay parameter is greater than or equal to the preset delay threshold.

[0123] Step 304: When the proportion of the first type of nodes in the blockchain network is less than the preset proportion threshold, and the link delay parameter between nodes is greater than or equal to the preset delay threshold, the second type of nodes generates a concise, non-interactive knowledge argument with zero knowledge.

[0124] Step 305: If the proportion of the first type of nodes in the blockchain network is less than the preset proportion threshold and the inter-node link delay parameter is less than the preset delay threshold, generate a default knowledge argument.

[0125] Understandably, in steps 301-305, knowledge arguments that match the current state of the blockchain network can be generated.

[0126] Step 102: Verify the knowledge argument based on the nodes in the second network to obtain the first verification result generated by the nodes in the second network.

[0127] In some embodiments, nodes in the verification subgroup can receive knowledge arguments sent by nodes in the first network and verify the generated knowledge arguments through nodes in the verification subgroup.

[0128] The verification pass conditions include at least one of the following:

[0129] The nodes in the verification subgroup that exceed the first preset value are determined to have passed the knowledge argument verification.

[0130] Alternatively, the predetermined number of fourth target nodes determine that the knowledge argument verification has passed;

[0131] Wherein, if the verification time of the fifth target node exceeds the preset verification time, the verification of the fifth target node fails. The verification subgroup includes: the fifth target node; the fourth target node is a node in the verification subgroup whose node location distance exceeds a preset location distance, and the node location distance is the distance of the device where the node is located.

[0132] In this embodiment, the master node in the verification subgroup can send the knowledge argument fragments to other nodes in the group and start a timer. If a node's verification time exceeds a preset verification time, the node's verification fails; or if the node determines that the knowledge argument fragments are incorrect, the node's verification fails.

[0133] The preset verification duration can be determined by a formula, which is: .in, To preset the verification duration, This represents the average inter-node link delay. This represents the standard deviation of the delay.

[0134] If a node in the verification subgroup that is greater than or equal to a first preset value is considered to have passed the knowledge argument verification, then the knowledge argument verification is deemed successful. The first preset value can be... , To verify the number of valid nodes within the subgroup.

[0135] A topology-based redundancy verification mechanism can also be used to determine the verification pass conditions. For example, for each knowledge argument fragment, a preset number of nodes can be selected within the verification subgroup for simultaneous verification. If the verification results of the nodes are inconsistent, the verification fails; if the verification results of the nodes are consistent, the verification passes. The preset number can be three nodes, and these three nodes must be physically farthest apart, meaning the distance between their locations exceeds a preset distance.

[0136] Understandably, in this embodiment, two verification conditions are used to determine whether the verification is successful, so as to ensure the accuracy of the verification results and the security of the blockchain network.

[0137] Step 103: If the first verification result does not meet the verification pass conditions, verify the transaction information carried by the payment transaction request and the first verification result to obtain a second verification result generated by the node in the second network; wherein, the second verification result is used to characterize whether the first verification result is correct and whether the payment transaction request is executed.

[0138] If the initial verification result fails to meet the verification pass conditions, a partial Byzantine fault-tolerant consensus can be adopted to re-verify the transaction information carried in the payment transaction request and the initial verification result. For example, some nodes in the verification subgroup can be selected as an arbitration group, and the nodes in the arbitration group can re-verify the transaction information carried in the payment transaction request and the initial verification result.

[0139] The process of determining the arbitration panel will be explained below.

[0140] In some embodiments, the method further includes:

[0141] The third target node in the verification subgroup whose arbitration weight is greater than a preset weight threshold is designated as a node of the arbitration group.

[0142] The arbitration weight is determined based on the CPU score of the third target node, the number of data transfer hops between the third target node and the first target node, and the reputation value of the third target node.

[0143] In this embodiment, the arbitration weight corresponding to each node in the verification subgroup can be determined first. The formula for calculating the arbitration weight can be: .

[0144] in, As for the weight of arbitration, This is a CPU score, representing data transfer hops or physical hops. This is a reputation score. These are the weight values ​​corresponding to the CPU score, physical jump count, and reputation score, respectively.

[0145] Specifically, the physical hop count is less than or equal to 3 to ensure the physical proximity and high credibility between the arbitration node and the node receiving the payment transaction request. This allows for fair handling of disputes between nodes based on dynamically updated first vectors and other information. Furthermore, in the event of a sudden change in node capability, the weights are recalculated to replace the failed node, ensuring the accuracy of verification and network stability. For example, if a sudden change in node capability is detected in the arbitration group, such as a 30% bandwidth decrease, the arbitration group weights are automatically recalculated, and the failed node is replaced. Through the dual constraints of physical proximity (hop count) and transmission capacity, the optimal solution is selected from candidate paths, ensuring that task distribution latency is strictly controlled within theoretical boundaries.

[0146] Simultaneously, security isolation and anti-collusion design take effect. Based on the topology map and historical interaction records between nodes, the arbitration group is forced to meet physical dispersion and high-frequency interaction nodes are automatically excluded, cutting off the collusion link from a spatial dimension. If an abnormal drop in the reputation value of an arbitration node is detected during re-verification, a dynamic replacement mechanism will be triggered, switching from weighted to... New nodes are added in real time to the sorted standby pool to serve as nodes in the new arbitration group, forming a double closed loop of topology security and capability reliability.

[0147] Then, nodes in the verification subgroup whose arbitration weight is greater than the preset weight threshold are selected as nodes in the arbitration group.

[0148] Understandably, in this embodiment, by determining the arbitration weight of each node in the verification subgroup, the appropriate nodes for the arbitration group are determined, ensuring the accuracy and security of the subsequent second verification.

[0149] The following section will explain the verification process of the arbitration panel.

[0150] In some embodiments, the step of verifying the transaction information carried in the payment transaction request and the first verification result when the first verification result does not meet the verification pass conditions, to obtain a second verification result generated by a node in the second network, includes:

[0151] If the first verification result does not meet the verification pass conditions, an arbitration group shall be determined;

[0152] The arbitration panel verifies the transaction information and the first verification result to obtain the second verification result generated by the arbitration panel.

[0153] The nodes in the arbitration group are some of the nodes in the verification subgroup, and the second verification result is determined based on the voting results of the nodes in the arbitration group and the voting weights of each node in the arbitration group.

[0154] The transaction information, the first verification result, and the local resource monitoring log of the first target node carried in the payment transaction request can be broadcast within the arbitration group. The first target node is the node that receives the payment transaction request, and the local resource monitoring log can include information such as CPU utilization curves and memory snapshots.

[0155] The nodes within the arbitration group verify the transaction information carried in the payment transaction request, the first verification result, and the local resource monitoring logs of the first target node, and obtain the voting results corresponding to each node in the arbitration group. Then, combining the voting weights and voting results of each node in the arbitration group, the second verification result is determined for the second verification.

[0156] The voting weights can be determined by a formula, which is: .

[0157] Understandably, in this embodiment, conducting a second verification through an arbitration panel and obtaining a second verification result can ensure that the final verification error rate is suppressed to 10%. −6 The following approach enables efficient knowledge verification and dynamic fault-tolerant aggregation, ensuring the accuracy and reliability of the verification process.

[0158] Understandably, in the above embodiments, the first vector and position matrix corresponding to each node in the blockchain network can provide basic data for the weight calculation and physical proximity judgment of the subsequent dynamic arbitration group election. The division of verification subgroups and node classification as the composition of the arbitration group in the hierarchical re-verification can also provide a basis. The first verification result is the direct source of global aggregation and contradiction detection. That is, the first verification result determines whether to conduct a second verification through the arbitration group. Then, the network state perception and node management system constructed in the previous steps is used to achieve efficient global verification and state update.

[0159] Next, we will proceed through... Figure 4 This section explains the two-step verification process in a blockchain network.

[0160] Step 401: The verification subgroup receives the knowledge argument, performs sharding on the knowledge argument, and then sends the shards of the knowledge argument to other nodes in the group through the master node in the verification subgroup.

[0161] Step 402: Set the preset verification duration.

[0162] Step 403: Determine the verification results of each node in the verification subgroup for the knowledge argument segment.

[0163] Step 404: Count the number of passes corresponding to the verification results of each node in the verification subgroup, and determine whether the number of passes is greater than or equal to the first preset value.

[0164] Step 405: If the number of verifications is greater than or equal to the first preset value, aggregate the verification results corresponding to each node to obtain the signature of the verification subgroup (or the first verification result), which indicates that the knowledge argument verification has passed.

[0165] Step 406: If the number of successful verifications is less than the first preset value, aggregate the verification results of each node to obtain the signature of the verification subgroup (or the first verification result), which indicates that the knowledge argument verification failed.

[0166] Step 407: Select a preset number of nodes within the verification subgroup for simultaneous verification, and determine whether the verification results of the selected preset number of nodes are consistent.

[0167] Step 408: In the event of inconsistent verification results, the transaction information and the first verification result are verified by the arbitration panel to obtain the second verification result generated by the arbitration panel.

[0168] Step 409: If the verification results are consistent, the knowledge argument verification is successful.

[0169] If the knowledge proof is verified, the corresponding payment transaction request can be executed, the corresponding block can be generated, and the block operation can be performed in the blockchain network.

[0170] As can be understood from steps 101-103 above, after receiving a payment transaction request, the first target node can obtain a knowledge proof generated by nodes in the first network based on preset generation conditions for the knowledge proof. Then, the knowledge proof is verified by nodes in the second network to obtain a first verification result generated by nodes in the second network. If the first verification result does not meet the verification pass conditions, the transaction information carried in the payment transaction request and the first verification result are verified to obtain a second verification result generated by nodes in the second network. It is understandable that even if a node in the second network malfunctions, causing an error in the first verification result, the transaction information carried in the payment transaction request and the first verification result can be re-verified to improve the accuracy of verification and the security of the blockchain network.

[0171] In some embodiments, the arbitration group can be determined based on the number of failed piecewise verifications of knowledge-based arguments.

[0172] For example, if only a single knowledge argument fragment fails verification, it is identified as the lightest verification contradiction. Nodes in the verification subgroup whose feature values ​​are greater than a first preset feature threshold are designated as nodes in the arbitration group, with the feature value being the feature value corresponding to the first vector of the node.

[0173] If multiple knowledge argument fragments fail verification, they are identified as verification contradictions of moderate complexity. One or two nodes corresponding to each failed knowledge argument fragment, along with the root node in the second network, are selected as nodes for the arbitration group.

[0174] When multiple knowledge proof shards fail verification and threaten the fundamental consensus security of the entire blockchain network, they are identified as the most serious verification contradictions. Nodes whose feature value scores reach a second preset feature threshold are selected from the root chain of the blockchain network to serve as nodes in the arbitration group, where nodes in this arbitration group have high credibility.

[0175] Understandably, in this embodiment, redundant overhead of re-verification across the entire blockchain network is avoided by classifying verification contradictions. Furthermore, different hierarchical re-verification mechanisms are designed for different contradiction situations, combined with dynamic arbitration group election and anti-collusion isolation, significantly improving the reliability and security of verification results while reducing redundant overhead.

[0176] In some embodiments, a feedback-driven policy mechanism can also be set in the blockchain network to collect the latency of each verification. Energy consumption Throughput These metrics are input into the reinforcement learning model to select the update strategy weights, i.e., the calculations described above. Weight of time, voting weight of the arbitration panel, calculation The weights for calculating reputation are optimized and adjusted to ensure the blockchain network continuously approaches Pareto optimality. The formula can be: , .

[0177] in, To meet the minimum throughput requirements of the Network Service Level Agreement (NSLA), weights are selected through an update strategy to ensure the blockchain network achieves the minimum throughput required by the NSLA. Under the constraints, it continuously approaches the Pareto optimal state, thereby achieving dynamic optimization and iteration of the verification strategy and improving the long-term operating efficiency and resource utilization rationality of the entire payment verification system in dynamic heterogeneous network environments. Moreover, under this feedback-driven iteration, the blockchain network can autonomously learn network rules, adapt to the evolution of dynamic heterogeneous networks in the long term, and maintain continuously optimized verification performance.

[0178] Next, we will proceed through... Figure 5 The flowchart below illustrates the entire verification process of the blockchain network in this application.

[0179] Step 501: Collect the performance parameters, network performance parameters, and load parameters of each node in the blockchain network when performing the first operation.

[0180] Step 502: Determine the first vector corresponding to each node in the blockchain network.

[0181] Step 503: Determine the first, second, and third clustered nodes, as well as the validation subgroups.

[0182] Step 504: The first target node in the first network of the blockchain network receives the payment transaction request.

[0183] Step 505: Nodes in the first network generate knowledge arguments corresponding to the payment transaction request.

[0184] Step 506: Nodes in the second network verify the knowledge proof and determine the processing strategy for the payment transaction request based on the verification result. The processing strategy includes: if the verification passes, executing the payment transaction request, generating the corresponding block, and performing the block operation in the blockchain network; or, if the verification fails, not executing the payment transaction request.

[0185] Step 507: Collect the latency of each verification. Energy consumption Throughput These metrics are then input into the reinforcement learning model to update the policy selection weights, i.e., the above calculations are performed. Weight of time, voting weight of the arbitration panel, calculation The weights used in calculating reputation and the weights used in calculating reputation were optimized and adjusted.

[0186] The verification process of the blockchain network can be determined through the above steps 501-507.

[0187] In some embodiments, to address potential probe data acquisition delays, a multi-source data cross-validation mechanism can be added to ensure the real-time nature of node capability assessment. Alternatively, if the efficiency of clustering algorithms decreases with a surge in the number of nodes, incremental clustering optimization can be introduced to reduce redundant computation. Furthermore, to prevent malicious node collusion during re-verification, the dynamic replacement mechanism of the arbitration group can be strengthened, combining historical node reputation values ​​with real-time behavior monitoring to promptly remove abnormal nodes, ensuring the robustness of the embodiments of this application in complex network environments.

[0188] Please refer to Figure 6 , Figure 6 This is a schematic diagram of a verification device according to an embodiment of this application. The verification device includes: a first network and a second network. Nodes in the first network are used to perform knowledge argument generation, transaction preprocessing, and knowledge argument distribution operations. Nodes in the second network are used to verify the knowledge arguments. The verification device 600 includes:

[0189] The generation module 601 is used to respond to the first target node receiving a payment transaction request, and to obtain a knowledge argument generated by a node in the first network based on preset generation conditions of the knowledge argument; the knowledge argument is used to prove the authenticity of the payment transaction request; the first network includes the first target node.

[0190] The first verification module 602 is used to verify the knowledge argument based on the nodes in the second network, and obtain the first verification result generated by the nodes in the second network;

[0191] The second verification module 603 is used to verify the transaction information carried in the payment transaction request and the first verification result when the first verification result does not meet the verification pass conditions, so as to obtain the second verification result generated by the node in the second network.

[0192] The second verification result is used to characterize whether the first verification result is correct and whether the payment transaction request is executed.

[0193] Optionally, the knowledge proof includes: zero-knowledge scalable transparent knowledge proof and zero-knowledge concise non-interactive knowledge proof, and the verification device 600 further includes:

[0194] The first determining module is used to determine a first vector corresponding to each node in the blockchain network; the first vector is determined based on at least one of the performance parameters, network performance parameters and load parameters when the node performs a first operation, and the first operation includes generating a knowledge proof or verifying a knowledge proof.

[0195] The first clustering module is used to perform a first clustering process on each node in the first network based on the first vector corresponding to each node in the first network, to obtain a first type of node, a second type of node, and a third type of node after clustering; the first type of node is used to generate the scalable and transparent knowledge argument of the zero knowledge, the second type of node is used to generate the concise non-interactive knowledge argument of the zero knowledge, and the third type of node is used to perform the transaction preprocessing and the distribution operation.

[0196] The second clustering module is used to perform a second clustering process on each node in the second network based on the first vector corresponding to each node in the second network to obtain a verification subgroup, wherein the verification subgroup includes at least one node in the second network; wherein the verification subgroup is used to verify the knowledge argument and obtain the first verification result.

[0197] Optionally, the second verification module 603 may also include:

[0198] The first determining unit is used to determine the arbitration group when the first verification result does not meet the verification pass condition;

[0199] The first generation unit is used to verify the transaction information and the first verification result through the arbitration group, and obtain the second verification result generated by the arbitration group;

[0200] The nodes in the arbitration group are some of the nodes in the verification subgroup, and the second verification result is determined based on the voting results of the nodes in the arbitration group and the voting weights of each node in the arbitration group.

[0201] Optionally, the preset generation conditions for knowledge argumentation include at least one of the following: whether the proportion of the first type of nodes in the blockchain network is greater than or equal to a preset proportion threshold; or whether the inter-node link delay parameter included in the network performance parameters is greater than or equal to a preset delay threshold.

[0202] The generation module 601 may also include:

[0203] The second generation unit is used to obtain scalable and transparent knowledge arguments of the zero knowledge generated by the first type of nodes in the first network when the preset generation conditions of the knowledge argument satisfy the fact that the proportion is greater than the preset proportion threshold.

[0204] The third generation unit is used to obtain the zero-knowledge concise non-interactive knowledge argument generated by the second type of node in the first network when the preset generation conditions of the knowledge argument satisfy the condition that the inter-node link delay parameter is greater than the preset delay threshold.

[0205] Optionally, the first vector includes: CPU score, bandwidth stability coefficient, local load factor, historical verification efficiency weight, and reputation value; the CPU score represents the computing performance of the node, the bandwidth stability coefficient represents the network stability and bandwidth of the node, the local load factor represents the load of the node, the historical verification efficiency weight represents the weight of the node in historical verification, and the reputation value represents the accuracy and response time of the node in historical verification.

[0206] The first determining module may also include:

[0207] The second determining unit is used to determine the CPU score value corresponding to the second target node based on the performance parameters of the second target node when performing the first operation and the corresponding preset weight; the blockchain network includes the second target node;

[0208] The third determining unit is used to send UDP packets to the second target node and determine the bandwidth stability coefficient value by using the latency parameter detected when the second target node receives the UDP packets; the network performance parameters include the latency parameter.

[0209] The fourth determining unit is used to determine the local load factor value of the second target node based on the load parameters;

[0210] The fifth determining unit is used to determine the reputation value based on the accuracy, error rate and response rate of the second target node during historical verification.

[0211] Optionally, the verification device 600 may also include:

[0212] The second determining module is used to identify the third target node in the verification subgroup whose arbitration weight is greater than a preset weight threshold as a node of the arbitration group.

[0213] The arbitration weight is determined based on the CPU score of the third target node, the number of data transfer hops between the third target node and the first target node, and the reputation value of the third target node.

[0214] Optionally, the first vector includes: a bandwidth stability coefficient value; the second clustering module may further include:

[0215] The sixth determining unit is used to determine the first matrix based on the bandwidth stability coefficient value corresponding to each node in the second network;

[0216] The seventh determining unit is used to obtain the second matrix based on the preset degree matrix and the first matrix;

[0217] The eighth determining unit is used to calculate the distance between each node in the second network by using the Euclidean distance algorithm to calculate the second matrix.

[0218] The first clustering unit is used to cluster nodes in the second network whose distance values ​​are less than a preset distance threshold to obtain the verification subgroup.

[0219] Optionally, the verification pass condition includes at least one of the following:

[0220] The nodes in the verification subgroup that exceed the first preset value are determined to have passed the knowledge argument verification.

[0221] Alternatively, the predetermined number of fourth target nodes determine that the knowledge argument verification has passed;

[0222] Wherein, if the verification time of the fifth target node exceeds the preset verification time, the verification of the fifth target node fails. The verification subgroup includes: the fifth target node; the fourth target node is a node in the verification subgroup whose node location distance exceeds a preset location distance, and the node location distance is the distance of the device where the node is located.

[0223] The verification device 600 provided in this application embodiment can perform the above-described... Figure 1 The method embodiments shown are similar in principle and technical effect, and will not be described again here.

[0224] This application also provides an electronic device. Since the principle by which this electronic device solves the problem is similar to the verification method in this application, the implementation of this electronic device can be found elsewhere. Figure 1 The implementation of the method shown will not be repeated here. Figure 7 As shown, the electronic device according to an embodiment of this application includes: a processor 710, configured to read a program from a memory 720 and execute the following processes:

[0225] In response to the first target node receiving a payment transaction request, a knowledge argument generated by a node in the first network is obtained based on preset generation conditions for knowledge argumentation; the knowledge argumentation is used to prove the authenticity of the payment transaction request; the first network includes the first target node;

[0226] The knowledge argument is verified based on the nodes in the second network to obtain the first verification result generated by the nodes in the second network;

[0227] If the first verification result does not meet the verification pass condition, the transaction information carried by the payment transaction request and the first verification result are verified to obtain the second verification result generated by the node in the second network;

[0228] The second verification result is used to characterize whether the first verification result is correct and whether the payment transaction request is executed.

[0229] Optionally, the knowledge proof includes: zero-knowledge scalable transparent knowledge proof and zero-knowledge concise non-interactive knowledge proof. The processor 710 is also used to read the program from the memory 720 and perform the following steps: Before the first target node receives the payment transaction request, the process further includes:

[0230] Determine a first vector corresponding to each node in the blockchain network; the first vector is determined based on at least one of the performance parameters, network performance parameters, and load parameters when the node performs a first operation, wherein the first operation includes generating a knowledge proof or verifying a knowledge proof.

[0231] Based on the first vector corresponding to each node in the first network, a first clustering process is performed on each node in the first network to obtain a first type of node, a second type of node, and a third type of node after clustering; the first type of node is used to generate the scalable and transparent knowledge argument of the zero knowledge, the second type of node is used to generate the concise non-interactive knowledge argument of the zero knowledge, and the third type of node is used to perform the transaction preprocessing and the distribution operation.

[0232] Based on the first vector corresponding to each node in the second network, a second clustering process is performed on each node in the second network to obtain a verification subgroup, wherein the verification subgroup includes at least one node in the second network; wherein the verification subgroup is used to verify the knowledge argument and obtain the first verification result.

[0233] Optionally, the processor 710 is further configured to read the program in the memory 720 and perform the following steps: In the case that the first verification result does not meet the verification pass condition, verifying the transaction information carried in the payment transaction request and the first verification result to obtain a second verification result generated by the node in the second network, including:

[0234] If the first verification result does not meet the verification pass conditions, an arbitration group shall be determined;

[0235] The arbitration panel verifies the transaction information and the first verification result to obtain the second verification result generated by the arbitration panel.

[0236] The nodes in the arbitration group are some of the nodes in the verification subgroup, and the second verification result is determined based on the voting results of the nodes in the arbitration group and the voting weights of each node in the arbitration group.

[0237] Optionally, the preset generation conditions for knowledge argumentation include at least one of the following: whether the proportion of the first type of nodes in the blockchain network is greater than or equal to a preset proportion threshold; or whether the inter-node link delay parameter included in the network performance parameters is greater than or equal to a preset delay threshold.

[0238] The processor 710 is also used to read the program in the memory 720 and to perform the following steps: obtaining the knowledge arguments generated by the nodes in the first network based on the preset generation conditions of the knowledge arguments includes:

[0239] When the preset generation conditions for knowledge argumentation satisfy the fact that the proportion is greater than the preset proportion threshold, scalable transparent knowledge argumentation of the zero knowledge generated by the first type of node in the first network is obtained.

[0240] When the preset generation conditions for knowledge argument satisfy the condition that the inter-node link delay parameter is greater than the preset delay threshold, the zero-knowledge concise non-interactive knowledge argument generated by the second type of node in the first network is obtained.

[0241] Optionally, the first vector includes: CPU score, bandwidth stability coefficient, local load factor, historical verification efficiency weight, and reputation value; the CPU score represents the computing performance of the node, the bandwidth stability coefficient represents the network stability and bandwidth of the node, the local load factor represents the load of the node, the historical verification efficiency weight represents the weight of the node in historical verification, and the reputation value represents the accuracy and response time of the node in historical verification.

[0242] Processor 710 is also used to read the program in memory 720 and to perform the following steps: determining the first vector corresponding to each node in the blockchain network, including:

[0243] Based on the performance parameters of the second target node when performing the first operation, and the corresponding preset weights, the CPU score value corresponding to the second target node is determined; the blockchain network includes the second target node;

[0244] The bandwidth stability coefficient value is determined by detecting the latency parameter when sending a UDP packet to the second target node and receiving the UDP packet through the second target node; the network performance parameter includes the latency parameter.

[0245] The local load factor value of the second target node is determined based on the load parameters;

[0246] The reputation value is determined based on the accuracy, error rate, and response rate of the second target node during historical verification.

[0247] Optionally, the processor 710 is also used to read the program from the memory 720 and perform the following steps:

[0248] The third target node in the verification subgroup whose arbitration weight is greater than a preset weight threshold is designated as a node of the arbitration group.

[0249] The arbitration weight is determined based on the CPU score of the third target node, the number of data transfer hops between the third target node and the first target node, and the reputation value of the third target node.

[0250] Optionally, the first vector includes: a bandwidth stability coefficient value; the processor 710 is further configured to read the program in the memory 720 and perform the following steps: based on the first vector corresponding to each node in the second network, perform a second clustering process on each node in the second network to obtain a verification subgroup, including:

[0251] The first matrix is ​​determined based on the bandwidth stability coefficient values ​​corresponding to each node in the second network.

[0252] The second matrix is ​​obtained based on the preset degree matrix and the first matrix;

[0253] The distance between each node in the second network is determined by calculating the second matrix using the Euclidean distance algorithm.

[0254] Clustering is performed on nodes in the second network whose distance values ​​are less than a preset distance threshold to obtain the verification subgroup.

[0255] Optionally, the verification pass condition includes at least one of the following:

[0256] The nodes in the verification subgroup that exceed the first preset value are determined to have passed the knowledge argument verification.

[0257] Alternatively, the predetermined number of fourth target nodes determine that the knowledge argument verification has passed;

[0258] Wherein, if the verification time of the fifth target node exceeds the preset verification time, the verification of the fifth target node fails. The verification subgroup includes: the fifth target node; the fourth target node is a node in the verification subgroup whose node location distance exceeds a preset location distance, and the node location distance is the distance of the device where the node is located.

[0259] Among them, Figure 7 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits of one or more processors represented by processor 710 and memory represented by memory 720 together. The bus architecture can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides the interface.

[0260] The electronic device provided in this application embodiment can perform the above-described functions. Figure 1 The method embodiments shown are similar in principle and technical effect, and will not be described again here.

[0261] This application also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the various processes of the verification method embodiments described above and achieves the same technical effect. To avoid repetition, it will not be described again here. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0262] This application also provides a computer program product, including computer instructions. When these computer instructions are executed by a processor, they implement the various processes of the above-described verification method embodiments and achieve the same technical effects. To avoid repetition, they will not be described again here.

[0263] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0264] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0265] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A verification method, characterized in that, The application is in a blockchain network, which includes a first network and a second network. Nodes in the first network are used to perform knowledge argument generation, transaction preprocessing and knowledge argument distribution operations, and nodes in the second network are used to verify knowledge arguments. The method includes: In response to the first target node receiving a payment transaction request, a knowledge argument generated by a node in the first network is obtained based on preset generation conditions for knowledge argumentation; the knowledge argumentation is used to prove the authenticity of the payment transaction request; the first network includes the first target node; The knowledge argument is verified based on the nodes in the second network to obtain the first verification result generated by the nodes in the second network; If the first verification result does not meet the verification pass condition, the transaction information carried by the payment transaction request and the first verification result are verified to obtain the second verification result generated by the node in the second network; The second verification result is used to characterize whether the first verification result is correct and whether the payment transaction request is executed.

2. The method according to claim 1, characterized in that, The knowledge argumentation includes: scalable and transparent zero-knowledge knowledge argumentation and concise non-interactive zero-knowledge knowledge argumentation. The response, prior to the first target node receiving the payment transaction request, also includes: Determine a first vector corresponding to each node in the blockchain network; the first vector is determined based on at least one of the performance parameters, network performance parameters, and load parameters when the node performs a first operation, wherein the first operation includes generating a knowledge proof or verifying a knowledge proof. Based on the first vector corresponding to each node in the first network, a first clustering process is performed on each node in the first network to obtain a first type of node, a second type of node, and a third type of node after clustering; the first type of node is used to generate the scalable and transparent knowledge argument of the zero knowledge, the second type of node is used to generate the concise non-interactive knowledge argument of the zero knowledge, and the third type of node is used to perform the transaction preprocessing and the distribution operation. Based on the first vector corresponding to each node in the second network, a second clustering process is performed on each node in the second network to obtain a verification subgroup, wherein the verification subgroup includes at least one node in the second network; wherein the verification subgroup is used to verify the knowledge argument and obtain the first verification result.

3. The method according to claim 2, characterized in that, When the first verification result does not meet the verification pass conditions, the transaction information carried in the payment transaction request and the first verification result are verified to obtain a second verification result generated by a node in the second network, including: If the first verification result does not meet the verification pass conditions, an arbitration group shall be determined; The arbitration panel verifies the transaction information and the first verification result to obtain the second verification result generated by the arbitration panel. The nodes in the arbitration group are some of the nodes in the verification subgroup, and the second verification result is determined based on the voting results of the nodes in the arbitration group and the voting weights of each node in the arbitration group.

4. The method according to claim 2, characterized in that, The preset generation conditions for knowledge argumentation include at least one of the following: whether the proportion of the first type of nodes in the blockchain network is greater than or equal to a preset proportion threshold; or whether the inter-node link delay parameter included in the network performance parameters is greater than or equal to a preset delay threshold. The process of obtaining knowledge arguments generated by nodes in the first network based on preset generation conditions for knowledge arguments includes: When the preset generation conditions for knowledge argumentation satisfy the fact that the proportion is greater than the preset proportion threshold, scalable transparent knowledge argumentation of the zero knowledge generated by the first type of node in the first network is obtained. When the preset generation conditions for knowledge argument satisfy the condition that the inter-node link delay parameter is greater than the preset delay threshold, the zero-knowledge concise non-interactive knowledge argument generated by the second type of node in the first network is obtained.

5. The method according to claim 2, characterized in that, The first vector includes: CPU score, bandwidth stability coefficient, local load factor, historical verification efficiency weight, and reputation value; the CPU score represents the computing performance of the node, the bandwidth stability coefficient represents the network stability and bandwidth of the node, the local load factor represents the load of the node, the historical verification efficiency weight represents the weight of the node in historical verification, and the reputation value represents the accuracy and response time of the node in historical verification. Determining the first vector corresponding to each node in the blockchain network includes: Based on the performance parameters of the second target node when performing the first operation, and the corresponding preset weights, the CPU score value corresponding to the second target node is determined; the blockchain network includes the second target node; The bandwidth stability coefficient value is determined by detecting the latency parameter when sending a UDP packet to the second target node and receiving the UDP packet through the second target node; the network performance parameter includes the latency parameter. The local load factor value of the second target node is determined based on the load parameters; The reputation value is determined based on the accuracy, error rate, and response rate of the second target node during historical verification.

6. The method according to claim 5, characterized in that, The method further includes: The third target node in the verification subgroup whose arbitration weight is greater than a preset weight threshold is designated as a node of the arbitration group. The arbitration weight is determined based on the CPU score of the third target node, the number of data transfer hops between the third target node and the first target node, and the reputation value of the third target node.

7. The method according to claim 2, characterized in that, The first vector includes: a bandwidth stability coefficient value; the second clustering process, based on the first vector corresponding to each node in the second network, performs a second clustering process on each node in the second network to obtain a verification subgroup, including: The first matrix is ​​determined based on the bandwidth stability coefficient values ​​corresponding to each node in the second network. The second matrix is ​​obtained based on the preset degree matrix and the first matrix; The distance between each node in the second network is determined by calculating the second matrix using the Euclidean distance algorithm. Clustering is performed on nodes in the second network whose distance values ​​are less than a preset distance threshold to obtain the verification subgroup.

8. The method according to claim 2, characterized in that, The verification pass condition includes at least one of the following: The nodes in the verification subgroup that exceed the first preset value are determined to have passed the knowledge argument verification. Alternatively, a predetermined number of fourth target nodes determine that the knowledge argument verification has passed; Wherein, if the verification time of the fifth target node exceeds the preset verification time, the verification of the fifth target node fails. The verification subgroup includes: the fifth target node; the fourth target node is a node in the verification subgroup whose node location distance exceeds a preset location distance, and the node location distance is the distance of the device where the node is located.

9. A verification device, characterized in that, The device is applied in a blockchain network, which includes a first network and a second network. Nodes in the first network are used to perform knowledge argument generation, transaction preprocessing and knowledge argument distribution operations, and nodes in the second network are used to verify knowledge arguments. The verification device includes: A generation module is used to respond to a first target node receiving a payment transaction request, and to obtain a knowledge argument generated by a node in the first network based on preset generation conditions for knowledge argumentation; the knowledge argument is used to prove the authenticity of the payment transaction request; the first network includes the first target node; The first verification module is used to verify the knowledge argument based on the nodes in the second network, and obtain the first verification result generated by the nodes in the second network; The second verification module is used to verify the transaction information carried in the payment transaction request and the first verification result when the first verification result does not meet the verification pass conditions, so as to obtain the second verification result generated by the node in the second network. The second verification result is used to characterize whether the first verification result is correct and whether the payment transaction request is executed.

10. An electronic device, characterized in that, include: A processor, a memory, and a program stored in the memory and executable on the processor, wherein the program, when executed by the processor, implements the steps of the verification method as described in any one of claims 1 to 8.

11. A computer-readable storage medium for storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the verification method as described in any one of claims 1 to 8.

12. A computer program product, characterized in that, It includes computer instructions that, when executed by a processor, implement the steps of the verification method as described in any one of claims 1 to 8.

Images