Method, device and electronic equipment for generating signature of node of blockchain

Abstract

The application discloses a method and device for generating a node signature of a blockchain and electronic equipment, relates to the fields of blockchains, financial technology and other related technical fields, and comprises the following steps: dividing 3F+1 subnodes corresponding to the blockchain into a first subregion and a second subregion, obtaining F+1 first signatures and F+1 second signatures, controlling the first subregion and the second subregion to enter a blockchain consensus phase respectively, obtaining 2F+1 third signatures after communication between the first subregion and the second subregion is restored, regarding signatures inconsistent with the third signatures in the F+1 first signatures and the F+1 second signatures as abnormal signatures, repairing blocks in target subnodes corresponding to the abnormal signatures, and regenerating target signatures corresponding to the target subnodes through private keys of the target subnodes. The application solves the technical problem of low verification efficiency caused by a blockchain consensus verification method based on standard certificates in the prior art in the case of subregion failure of the blockchain.

Description

Technical Field

[0001] This application relates to the fields of blockchain, fintech, and other related technologies. Specifically, it relates to a method, apparatus, and electronic device for generating node signatures in a blockchain. Background Technology

[0002] Byzantine fault tolerance (BFT) systems are used to handle node and communication failures in distributed systems (such as blockchain systems). BFT systems ensure that business operations within a distributed system can continue to function normally even when some nodes fail. Current technologies typically employ standard certificate verification to ensure the reliability and security of the distributed system, addressing unreliable communication between nodes and occasional malicious behavior. However, this standard certificate-based verification method requires collecting at least 2F+1 voting signatures from secondary nodes in the blockchain before proceeding to the next consensus verification stage. Here, F represents the maximum number of faulty secondary nodes the distributed system can accommodate. In the event of a partition failure, the BFT system may fail to collect the required 2F+1 voting signatures in time due to communication failures, thus preventing it from entering the next consensus verification stage. Current solutions require waiting for the partition communication to recover and for the 2F+1 voting signatures to be collected before proceeding to the next consensus verification stage, resulting in low efficiency in blockchain consensus verification.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This application provides a method, apparatus, and electronic device for generating node signatures in a blockchain, to at least solve the technical problem of low verification efficiency caused by existing blockchain consensus verification methods based on standard certificates in the event of a partition failure in the blockchain.

[0005] According to one aspect of this application, a method for generating node signatures in a blockchain is provided, comprising: dividing 3F+1 secondary nodes corresponding to the blockchain into a first partition and a second partition, wherein F is a positive integer, each partition includes at least F+1 secondary nodes, and a communication failure exists between the first partition and the second partition; obtaining F+1 first signatures generated by F+1 secondary nodes in the first partition and F+1 second signatures generated by F+1 secondary nodes in the second partition, and controlling the first partition and the second partition to enter the blockchain consensus verification stage respectively; after the communication between the first partition and the second partition is restored, obtaining 2F+1 third signatures generated by 2F+1 secondary nodes in the blockchain; identifying signatures among the F+1 first signatures and F+1 second signatures that are inconsistent with the third signature as abnormal signatures, and repairing the blocks in the target secondary node corresponding to the abnormal signatures; after the blocks in the target secondary node are repaired, regenerating the target signature corresponding to the target secondary node using the private key of the target secondary node.

[0006] Optionally, the method for generating node signatures in the blockchain further includes: obtaining M endorsement nodes corresponding to the first partition and M endorsement nodes corresponding to the second partition, where M is a positive integer; the endorsement nodes corresponding to the first partition are used to securely communicate with each secondary node in the first partition, and the endorsement nodes corresponding to the second partition are used to securely communicate with each secondary node in the second partition; any one of the M endorsement nodes in the first partition is designated as the first master node, where the first master node is used to collect F+1 first signatures; any one of the M endorsement nodes in the second partition is designated as the second master node, where the second master node is used to collect F+1 second signatures.

[0007] Optionally, the method for generating node signatures in the blockchain further includes: generating a first broadcast message through a first master node, wherein the first broadcast message is used to represent the transaction request information initiated by the user; transmitting the first broadcast message to each secondary node in the first partition; and after the i-th secondary node in the first partition receives the first broadcast message, generating a first signature corresponding to the i-th secondary node through the private key corresponding to the i-th secondary node, wherein i is a positive integer less than or equal to F+1.

[0008] Optionally, the method for generating node signatures in the blockchain further includes: verifying the consistency among F+1 first signatures through the smart contract corresponding to the blockchain; and generating a weak certificate corresponding to the first partition when the F+1 first signatures are consistent, wherein the weak certificate is used to verify the identity information of each of the F+1 secondary nodes corresponding to the F+1 first signatures.

[0009] Optionally, the method for generating node signatures in the blockchain further includes: verifying the consistency among the 2F+1 third signatures through the smart contract corresponding to the blockchain; and generating a standard certificate corresponding to the blockchain if the 2F+1 third signatures are consistent, wherein the standard certificate is used to verify the identity information of each of the 2F+1 secondary nodes corresponding to the 2F+1 third signatures.

[0010] Optionally, the method for generating node signatures in the blockchain further includes: obtaining the block length corresponding to the target secondary node and the block length corresponding to each of the 2F+1 secondary nodes corresponding to the 2F+1 third signatures, wherein the block length corresponding to the secondary node is used to characterize the number of blocks stored in the secondary node; taking the secondary node with the largest block length among the 2F+1 secondary nodes corresponding to the 2F+1 third signatures as the first secondary node; taking the minimum value between the block length corresponding to the target secondary node and the block length corresponding to the first secondary node as the target value; and determining the j-th block in the target secondary node as a faulty block if the stored data in the j-th block in the target secondary node is inconsistent with that in the j-th block in the first secondary node, wherein j is a positive integer less than or equal to the target value.

[0011] Optionally, the method for generating the node signature of the blockchain further includes: obtaining X faulty blocks corresponding to the target secondary node, where X is a positive integer less than or equal to the target value; querying the X first blocks corresponding to the first secondary node based on the permutation number of each faulty block in the X faulty blocks among all blocks corresponding to the target secondary node, where the X first blocks correspond one-to-one with the X faulty blocks; and updating the storage data of the faulty block corresponding to the first block based on the storage data of each first block in the X first blocks.

[0012] According to one aspect of this application, a node signature generation apparatus for a blockchain is also provided, comprising: a partitioning unit, configured to divide 3F+1 secondary nodes corresponding to the blockchain into a first partition and a second partition, wherein F is a positive integer, each partition includes at least F+1 secondary nodes, and there is a communication failure between the first partition and the second partition; a first acquisition unit, configured to acquire F+1 first signatures generated by F+1 secondary nodes in the first partition and F+1 second signatures generated by F+1 secondary nodes in the second partition, and control the first partition and the second partition to enter the blockchain consensus phase respectively; a second acquisition unit, configured to acquire 2F+1 third signatures generated by 2F+1 secondary nodes in the blockchain after the communication between the first partition and the second partition is restored; a repair unit, configured to identify signatures in the F+1 first signatures and F+1 second signatures that are inconsistent with the third signature as abnormal signatures, and repair the blocks in the target secondary node corresponding to the abnormal signatures; and a first generation unit, configured to regenerate the target signature corresponding to the target secondary node using the private key of the target secondary node after the block repair in the target secondary node is completed.

[0013] According to another aspect of this application, a computer-readable storage medium is also provided, which stores a computer program, wherein the computer program controls the device where the computer-readable storage medium is located to execute the method for generating node signatures of the blockchain according to any of the above-mentioned methods when it is running.

[0014] According to another aspect of this application, an electronic device is also provided, wherein the electronic device includes one or more processors and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method for generating node signatures of the blockchain as described above.

[0015] In this application, the 3F+1 secondary nodes corresponding to the blockchain are first divided into a first partition and a second partition, where F is a positive integer. Each partition includes at least F+1 secondary nodes. There is a communication failure between the first partition and the second partition. Then, F+1 first signatures generated by F+1 secondary nodes in the first partition and F+1 second signatures generated by F+1 secondary nodes in the second partition are obtained. The first partition and the second partition are then controlled to enter the blockchain consensus verification stage respectively. After the communication between the first partition and the second partition is restored, 2F+1 third signatures generated by 2F+1 secondary nodes in the blockchain are obtained. The signatures that are inconsistent with the third signatures among the F+1 first signatures and F+1 second signatures are regarded as abnormal signatures. The blocks in the target secondary node corresponding to the abnormal signatures are repaired. After the blocks in the target secondary node are repaired, the target signature corresponding to the target secondary node is regenerated using the private key of the target secondary node.

[0016] As described above, in scenarios where some nodes in a blockchain cannot communicate (i.e., there is a partition failure), this application divides all the corresponding secondary nodes (i.e., 3F+1 secondary nodes) of the blockchain into two partitions (i.e., the first partition and the second partition). After obtaining F+1 first signatures and F+1 second signatures, the first partition and the second partition are controlled to enter the next blockchain consensus verification stage based on a weak certificate verification method. Compared with the standard certificate verification method in the prior art, which requires waiting for the partition communication to recover and at least 2F+1 signatures to be collected before entering the blockchain consensus verification stage, the number of secondary nodes in each partition in this application is no less than F+1. Therefore, this application can ensure that the system collects F+1 first signatures and F+1 second signatures in parallel at the current stage, thereby satisfying the conditions for the first partition and the second partition to enter the next round of blockchain consensus verification stage. At this time, the system can determine whether the first partition and the second partition in the blockchain have reached a local consensus, thereby improving the verification efficiency of blockchain consensus.

[0017] Furthermore, to mitigate the security risks associated with weak certificate-based verification, after resolving the blockchain partition failure, this application re-collected 2F+1 third signatures corresponding to the 2F+1 secondary nodes in the blockchain. It then verified the consistency between the F+1 first signatures and F+1 second signatures obtained during the asynchronous period before partition communication recovery and the 2F+1 third signatures obtained during the synchronous period after partition communication recovery. Subsequently, signatures inconsistent with the third signatures among the F+1 first and F+1 second signatures were designated as anomalous signatures, and the blocks in the target secondary nodes corresponding to the anomalous signatures were repaired. This combined delay checking and repair techniques with weak certificate-based verification, thereby achieving transaction rollback and vote replay, reducing the security risks associated with weak certificate-based verification, and improving the verification efficiency of blockchain consensus while ensuring the security of the blockchain system.

[0018] Therefore, the technical solution of this application, by combining delayed checking and repair technology with a weak certificate-based verification method, achieves the technical effect of improving the verification efficiency of blockchain consensus while ensuring the security of the blockchain system. This solves the technical problem of low verification efficiency caused by existing blockchain consensus verification methods based on standard certificates when there are partition faults in the blockchain. Attached Figure Description

[0019] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0020] Figure 1 This is a flowchart of an optional blockchain node signature generation method according to an embodiment of this application;

[0021] Figure 2 This is a schematic diagram showing the node distribution in an optional first partition and second partition according to an embodiment of this application;

[0022] Figure 3 This is a schematic diagram of an optional client node according to an embodiment of this application;

[0023] Figure 4 This is a schematic diagram of an optional blockchain consensus module according to an embodiment of this application;

[0024] Figure 5 This is a flowchart of an optional Byzantine fault-tolerant method based on weak certificate delay repair according to an embodiment of this application;

[0025] Figure 6 This is a flowchart of an optional master node operation method according to an embodiment of this application;

[0026] Figure 7 This is a flowchart of an optional working method for a secondary node according to an embodiment of this application;

[0027] Figure 8 This is a schematic diagram of an optional blockchain node signature generation apparatus according to an embodiment of this application;

[0028] Figure 9 This is a schematic diagram of an optional electronic device according to an embodiment of this application. Detailed Implementation

[0029] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0030] It should be noted that the terms "first," "second," etc., 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. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0031] It should also be noted that all information and data involved in this application (including transaction information of financial institution users stored in the blockchain) and data (including but not limited to data used for display and analysis) are information and data authorized by the users or fully authorized by all parties. For example, this system has an interface with the relevant users or institutions. Before obtaining relevant information, it needs to send an acquisition request to the aforementioned users or institutions through the interface, and obtain the relevant information after receiving consent from the aforementioned users or institutions.

[0032] Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of relevant information and data involved in this application all comply with the relevant laws, regulations, and standards of the relevant regions, and necessary confidentiality measures have been taken. This application does not violate public order and good morals. In addition, this application provides a corresponding operation entry point for users to choose to agree to or refuse authorization. If the user chooses to refuse authorization, the corresponding expert decision-making process will be initiated.

[0033] According to an embodiment of this application, an embodiment of a method for generating node signatures in a blockchain is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0034] This application provides a blockchain node signature generation system (hereinafter referred to as the generation system) for executing the blockchain node signature generation method of this application. The explanations of some technical terms involved in the technical solution of this application are as follows:

[0035] Byzantine fault-tolerant systems are used to maintain the normal operation of distributed system services even when some nodes fail. Byzantine fault-tolerant systems are typically used in distributed systems that require high reliability and stability.

[0036] Strong quorum certificates: In each phase of the Byzantine blockchain, after a master node or user broadcasts a transaction proposal to other slave nodes, at least 3f+1 votes from slave nodes must be collected to verify the proposal before the next round of blockchain consensus verification can proceed.

[0037] Regular quorum certificates: In each phase of the Byzantine blockchain, after a master node or user broadcasts a transaction proposal to other slave nodes, at least 2f+1 votes from slave nodes must be collected to verify the proposal before the next round of blockchain consensus verification can proceed.

[0038] Weak quorum certificates: In each phase of the Byzantine blockchain, after a master node or user broadcasts a transaction proposal to other replica nodes, at least f+1 votes from replica nodes must be collected to verify the proposal before the next round of blockchain consensus verification can proceed.

[0039] Partition failure: In blockchain, partition failure refers to the situation where nodes in the network are divided into different regions, and nodes in each region cannot communicate and exchange information with nodes in other regions. This communication failure is usually caused by changes in network topology, node failure, or malicious attacks.

[0040] In one alternative embodiment, Figure 1 This is a flowchart of an optional blockchain node signature generation method according to an embodiment of this application, such as... Figure 1 As shown, the method includes the following steps:

[0041] Step S101: Divide the 3F+1 secondary nodes corresponding to the blockchain into the first partition and the second partition.

[0042] In step S101, F is a positive integer, each partition includes at least F+1 secondary nodes, and there is a communication failure between the first partition and the second partition.

[0043] Optionally, blocks in the blockchain are used to store encrypted transaction information corresponding to users of financial institutions.

[0044] Optionally, the secondary nodes of the blockchain represent participants in the blockchain network. A user, an organization, or a computer can all act as a secondary node in the blockchain network. Each secondary node is used to store data in the blocks included in the blockchain, and each secondary node can communicate and interact with other nodes through the network. The consensus mechanism of the blockchain can ensure the consistency of the block data stored by each of the 3F+1 secondary nodes and the security of the entire blockchain.

[0045] Optionally, F is the maximum number of secondary nodes that can be accommodated in a distributed system (i.e., a blockchain) that have experienced communication failures.

[0046] Step S102: Obtain F+1 first signatures generated by F+1 secondary nodes in the first partition and F+1 second signatures generated by F+1 secondary nodes in the second partition, and control the first partition and the second partition to enter the blockchain consensus verification stage respectively.

[0047] Optionally, this application enables communication between the generating system (i.e., the Byzantine system) and the first partition, and between the generating system and the second partition, by setting client nodes for the first partition and the second partition respectively. The client nodes are used to send and receive transaction requests to access nodes in the first partition and the second partition.

[0048] Optionally, the technical solution of this application is based on the weak certificate verification method. After collecting f+1 node signatures from the sub-nodes in the same stage, the next blockchain consensus verification stage can be entered. Compared with the traditional standard certificate verification method in the prior art, the number of node signatures to be collected in each stage of the Byzantine system is less. Therefore, the technical solution of this application has higher execution efficiency in verifying whether the blockchain has reached a consensus.

[0049] Step S103: After communication between the first partition and the second partition is restored, obtain 2F+1 third signatures generated by 2F+1 secondary nodes in the blockchain.

[0050] Optionally, since weak certificates are detrimental to maintaining the security of blockchain operation, and since there is a possibility of malicious behavior by master nodes in the blockchain system, in order to further improve the security and stability of the blockchain system, this application, after introducing a verification method based on weak certificates in specific scenarios such as partition failures, also proposes a delayed-repair Byzantine fault-tolerant method. That is, during the asynchronous-to-synchronous processing (i.e., after the communication between the first and second partitions is restored), this application checks the transaction proposal signature corresponding to the weak certificate based on the 2F+1 third signatures re-collected after the communication is restored. If the transaction proposals collected during the synchronous period and the asynchronous period are found to be inconsistent, a transaction rollback and vote replay are initiated, thereby improving the security of the blockchain system.

[0051] Optionally, after communication between the first partition and the second partition is restored, the generation system switches from asynchronous processing to synchronous processing. At this time, the generation system selects one endorsement node as the target master node from all the endorsement nodes included in the blockchain, generates a target broadcast message through the target master node, and transmits the target broadcast message to each of the 3F+1 sub-nodes in the blockchain.

[0052] Optionally, after the j-th sub-node in the blockchain receives the target broadcast message, it generates a third signature corresponding to the j-th sub-node using the private key of the j-th sub-node, where j is a positive integer less than or equal to 3F+1.

[0053] Step S104: The signatures that are inconsistent with the third signature among the F+1 first signatures and F+1 second signatures are identified as abnormal signatures, and the blocks in the target sub-node corresponding to the abnormal signatures are repaired.

[0054] Optionally, the generation system verifies the consistency between F+1 first signatures, F+1 second signatures, and 2F+1 third signatures by calling the smart contract corresponding to the blockchain.

[0055] Step S105: After the block repair in the target sub-node is completed, the target signature corresponding to the target sub-node is regenerated using the private key of the target sub-node.

[0056] Optionally, after regenerating the target signature corresponding to the target sub-node using the private key of the target sub-node, the generation system re-collects 2F+1 target signatures generated by 2F+1 sub-nodes in the blockchain, and performs blockchain consensus verification operation based on the re-collected 2F+1 target signatures.

[0057] As described above, in scenarios where some nodes in a blockchain cannot communicate (i.e., there is a partition failure), this application divides all the corresponding secondary nodes (i.e., 3F+1 secondary nodes) of the blockchain into two partitions (i.e., the first partition and the second partition). After obtaining F+1 first signatures and F+1 second signatures, the first partition and the second partition are controlled to enter the next blockchain consensus verification stage based on a weak certificate verification method. Compared with the standard certificate verification method in the prior art, which requires waiting for the partition communication to recover and at least 2F+1 signatures to be collected before entering the blockchain consensus verification stage, the number of secondary nodes in each partition in this application is no less than F+1. Therefore, this application can ensure that the system collects F+1 first signatures and F+1 second signatures in parallel at the current stage, thereby satisfying the conditions for the first partition and the second partition to enter the next round of blockchain consensus verification stage. At this time, the system can determine whether the first partition and the second partition in the blockchain have reached a local consensus, thereby improving the verification efficiency of blockchain consensus.

[0058] Furthermore, to mitigate the security risks associated with weak certificate-based verification, after resolving the blockchain partition failure, this application re-collected 2F+1 third signatures corresponding to the 2F+1 secondary nodes in the blockchain. It then verified the consistency between the F+1 first signatures and F+1 second signatures obtained during the asynchronous period before partition communication recovery and the 2F+1 third signatures obtained during the synchronous period after partition communication recovery. Subsequently, signatures inconsistent with the third signatures among the F+1 first and F+1 second signatures were designated as anomalous signatures, and the blocks in the target secondary nodes corresponding to the anomalous signatures were repaired. This combined delay checking and repair techniques with weak certificate-based verification, thereby achieving transaction rollback and vote replay, reducing the security risks associated with weak certificate-based verification, and improving the verification efficiency of blockchain consensus while ensuring the security of the blockchain system.

[0059] Therefore, the technical solution of this application, by combining delayed checking and repair technology with a weak certificate-based verification method, achieves the technical effect of improving the verification efficiency of blockchain consensus while ensuring the security of the blockchain system. This solves the technical problem of low verification efficiency caused by existing blockchain consensus verification methods based on standard certificates when there are partition faults in the blockchain.

[0060] In one optional embodiment, the generation system first obtains M endorsement nodes corresponding to the first partition and M endorsement nodes corresponding to the second partition, where M is a positive integer. The endorsement nodes corresponding to the first partition are used to securely communicate with each secondary node in the first partition, and the endorsement nodes corresponding to the second partition are used to securely communicate with each secondary node in the second partition. Then, the generation system uses any one of the M endorsement nodes in the first partition as the first master node, where the first master node is used to collect F+1 first signatures. Then, the generation system uses any one of the M endorsement nodes in the second partition as the second master node, where the second master node is used to collect F+1 second signatures.

[0061] Optionally, Figure 2 This is a schematic diagram illustrating the node distribution in an optional first and second partition according to an embodiment of this application, as shown below. Figure 2As shown: Assuming F equals 3, the first partition includes 6 (i.e., 2F) secondary nodes, and the second partition includes 4 (i.e., F+1) secondary nodes. There is a partition fault between the first and second partitions, meaning that nodes in the first partition cannot communicate with nodes in the second partition. In addition, the first and second partitions each include a leader node, a certificate node, and client nodes. The leader node is used to securely communicate with each secondary node in the partition, the certificate node is used to generate different types of digital certificates based on the collected signatures of the secondary nodes, and the client nodes are used to send and receive transaction requests to access nodes in the first and second partitions.

[0062] Optionally, Figure 3 This is a schematic diagram of an optional client node according to an embodiment of this application, such as... Figure 3 As shown, the client node includes a communication module, a connection module, a secure computing module, a message processing module, and a routing management module.

[0063] Optionally, the communication module serves as the entry point for the client node, enabling the generation system to send and receive data packets. The connection module establishes a secure channel for the client node and implements the functions of establishing, terminating, and restarting communication. The secure computation module encrypts and decrypts data packets using cryptographic algorithms. The packet processing module parses and splits user data to form data vectors and assembles them into user data packets. The routing management module manages the routing information corresponding to the communication packets, enabling the saving, deleting, and adding of routing information. The routing management module includes two phases during execution: initialization and dynamic pheromone updating.

[0064] Optionally, the generation system also includes a blockchain consensus module. Figure 4 This is a schematic diagram of an optional blockchain consensus module according to an embodiment of this application, such as... Figure 4 As shown, the blockchain consensus module includes a communication module, a ciphertext processing module, a transaction processing module, and a transaction consensus module.

[0065] Optionally, the communication module is used to realize the communication and interaction functions between the nodes of the blockchain. The communication and interaction functions include transaction broadcast information, consensus information, block synchronization information, and network status determination information. The ciphertext processing module is responsible for encrypting and decrypting the data packets sent and received by the communication module. The transaction processing module is responsible for determining the unique identifier of the transaction and the unique identifier of the contract based on the transaction request provided by the ciphertext processing module, assembling the transaction message by calling parameters, and determining the consensus result by calling the smart contract. The transaction consensus module is responsible for executing the Byzantine fault-tolerant algorithm based on weak certificate delay repair, which is used to realize asynchronous state information synchronization in the partition failure environment, and query the inconsistent signature information between different partitions, thereby realizing transaction replay and delay repair.

[0066] In one optional embodiment, the generation system first generates a first broadcast message through a first master node, wherein the first broadcast message is used to characterize the transaction request information initiated by the user. Then, the generation system transmits the first broadcast message to each slave node in the first partition. After the i-th slave node in the first partition receives the first broadcast message, the generation system generates a first signature corresponding to the i-th slave node through the private key corresponding to the i-th slave node, wherein i is a positive integer less than or equal to F+1.

[0067] Optionally, the generation system first generates a second broadcast message through the second master node. Then, the generation system transmits the second broadcast message to each slave node in the second partition. After the kth slave node in the second partition receives the second broadcast message, the generation system generates a second signature corresponding to the kth slave node in the second partition using the private key corresponding to the kth slave node in the second partition, where k is a positive integer less than or equal to F+1.

[0068] In one optional embodiment, after collecting F+1 first signatures, the generation system first verifies the consistency among the F+1 first signatures through the smart contract corresponding to the blockchain. Then, if the F+1 first signatures are consistent, a weak certificate corresponding to the first partition is generated. The weak certificate corresponding to the first partition is used to verify the identity information of each of the F+1 secondary nodes corresponding to the F+1 first signatures.

[0069] Optionally, after collecting F+1 second signatures, the generation system first verifies the consistency between the F+1 second signatures through the smart contract corresponding to the blockchain. Then, if the F+1 second signatures are consistent, a weak certificate corresponding to the second partition is generated. The weak certificate corresponding to the second partition is used to verify the identity information of each of the F+1 secondary nodes corresponding to the F+1 second signatures.

[0070] In one optional embodiment, the generation system first verifies the consistency among the 2F+1 third signatures through the smart contract corresponding to the blockchain. Then, if the 2F+1 third signatures are consistent, a standard certificate corresponding to the blockchain is generated. The standard certificate is used to verify the identity information of each of the 2F+1 secondary nodes corresponding to the 2F+1 third signatures.

[0071] Optionally, the weak certificate corresponding to the first partition, the weak certificate corresponding to the second partition, and the standard certificate corresponding to the blockchain are all generated by the certificate nodes in the blockchain. The certificate nodes in the blockchain generate different types of digital certificates based on the collected voting signatures of the secondary nodes. The types of digital certificates include strong certificates, standard certificates, and weak certificates.

[0072] In one optional embodiment, the generation system first obtains the block length corresponding to the target secondary node and the block length corresponding to each of the 2F+1 secondary nodes corresponding to the 2F+1 third signatures, wherein the block length corresponding to the secondary node is used to characterize the number of blocks stored in the secondary node. Then, the generation system takes the secondary node with the largest block length among the 2F+1 secondary nodes corresponding to the 2F+1 third signatures as the first secondary node. Then, the generation system takes the minimum value between the block length corresponding to the target secondary node and the block length corresponding to the first secondary node as the target value. Furthermore, if the stored data in the j-th block in the target secondary node is inconsistent with the stored data in the j-th block in the first secondary node, the generation system determines the j-th block in the target secondary node as a faulty block, where j is a positive integer less than or equal to the target value.

[0073] Optionally, Figure 5 This is a flowchart of an optional Byzantine fault-tolerant method based on weak certificate delay repair according to an embodiment of this application, such as... Figure 5 As shown, this method includes three steps: partition fault tolerance, fault location, and delayed repair.

[0074] Optionally, during the partition fault tolerance phase, b_1 to b_k+1 are multiple blocks stored in the target secondary node, and *b_1 to *b_k+1 are multiple blocks stored in the first secondary node. Assuming that communication between the first and second partitions has been restored at time t2, the generation system compares the consistency between the signatures collected by the first and target secondary nodes during the asynchronous phase, such as... Figure 5As shown, wQC represents a weak certificate and rQC represents a standard certificate. During the fault location phase, the generation system uses a fault location tool to determine that the stored data of each block from b_2 to b_k+1 is different from the stored data of each block from *b_2 to *b_k+1. Therefore, b_2 to b_k+1 in the target secondary node are identified as faulty blocks. After that, the generation system enters the delayed repair phase, and repairs the X faulty blocks based on the block data stored in the secondary node corresponding to the standard certificate generated by the newly collected 2F+1 third signatures.

[0075] In one optional embodiment, the generation system first obtains X fault blocks corresponding to the target secondary node, where X is a positive integer less than or equal to the target value. Then, the generation system queries the X first blocks corresponding to the first secondary node based on the permutation number of each fault block in the X fault blocks among all blocks corresponding to the target secondary node. The X first blocks correspond one-to-one with the X fault blocks. Finally, the generation system updates the storage data of the fault block corresponding to the first block based on the storage data of each first block in the X first blocks.

[0076] For example, after obtaining X faulty blocks corresponding to the target secondary node, assuming X equals 3, and the sequence numbers of the three faulty blocks in the blockchain stored in the target secondary node are 2, 3, and 4 respectively, then the sequence numbers of the three first blocks obtained from the three faulty blocks in the blockchain stored in the first secondary node are 2, 3, and 4 respectively. At this time, the storage data of the second faulty block in the target secondary node is updated based on the second first block in the first secondary node, the storage data of the third faulty block in the target secondary node is updated based on the third first block in the first secondary node, and the storage data of the fourth faulty block in the target secondary node is updated based on the fourth first block in the first secondary node.

[0077] Optionally, Figure 6 This is a flowchart of an optional master node operation method according to an embodiment of this application, such as... Figure 6 As shown, the method includes the following steps:

[0078] Step S601: Initialization<req,pl,sl,view,height,qc> The parameters are as follows: req represents the transaction request information initiated by the user, pl represents the hash value of the parent block in the blockchain, view represents the current view, height represents the block height, qc represents the certificate, and sl represents the hash value of the stable block. The stable block refers to the block with the highest block length that has received the standard certificate vote. The hash value of the stable block is represented by b.stable.

[0079] Step S602: Start clock t1 and wait for the secondary node's vote signature.

[0080] Step S603: If the current node is the master node, then execute the following steps S604 to S610.

[0081] Step S604: The broadcast message is represented by M, where M =<Generic,b,qc> .

[0082] Step S605: Broadcast M= to the entire network<Generic,b,qc> And wait for the vote signature from the secondary node.

[0083] Step S606: Determine whether F+1 signatures have been collected.

[0084] Step S607: If F+1 signatures are collected, start clock t2, which means proceeding to the next blockchain consensus verification stage.

[0085] Step S608: Determine whether 2F+1 signatures have been collected;

[0086] Step S609: If 2F+1 signatures are collected, set qc = rQC; if F+1 signatures are collected, set qc = wQC and exit the loop.

[0087] Step S610: t2 timeout, exit the loop.

[0088] Optionally, Figure 7 This is a flowchart of an optional secondary node operation method according to an embodiment of this application, such as... Figure 7 As shown, the method includes the following steps:

[0089] Step S701: The replica node waits to receive broadcast message M from the master node.<Generic,b,qc> ;

[0090] Step S702: Initialize b, b ′ ,b″,b * b0, v, b high Parameters, where b ′ This indicates the parent block of b, and b″ indicates b. ′ The parent block, b high This indicates the height of the current block, and sets b0 = QcBlock(wQC), and sets b... high =QcBlock(rQC), sets b ′ =QcBlock(qc), where QcBlock is a block retrieval function that determines the block information with the highest height among the same type of certificates in the blockchain by taking the certificate type as input.

[0091] Step S703: Determine whether the type of qc is a standard certificate. If it is a standard certificate, execute Step 704; otherwise, execute Step 705.

[0092] Step S704: Discuss in the following three cases:

[0093] Case 1: If rank(b ′ ) > rank(b high ), then rQC = qc;

[0094] Case 2: If b ′ .stable = b″ and rank(b″) > rank(lb), then lb = b″;

[0095] Case 3: If b ′ .stable = b″ and the views of lb, b ′ , b″, b * are the same, then send the stored transaction data of b * .

[0096] Step S705: If the type of qc is a weak certificate, execute Step 706.

[0097] Step S706: Discuss in the following two cases:

[0098] Case 1: If rank(b ′ .stable) >= rank(b0.stable), then wQC = qc;

[0099] Case 2: If rank(b ′ .stable) < rank(b0.stable), locate the faulty block through the fault point location tool and perform delayed repair on the faulty block.

[0100] Step S707: Send a voting signature to the master node.

[0101] In this application, the 3F+1 secondary nodes corresponding to the blockchain are first divided into a first partition and a second partition, where F is a positive integer. Each partition includes at least F+1 secondary nodes. There is a communication failure between the first partition and the second partition. Then, F+1 first signatures generated by F+1 secondary nodes in the first partition and F+1 second signatures generated by F+1 secondary nodes in the second partition are obtained. The first partition and the second partition are then controlled to enter the blockchain consensus verification stage respectively. After the communication between the first partition and the second partition is restored, 2F+1 third signatures generated by 2F+1 secondary nodes in the blockchain are obtained. The signatures that are inconsistent with the third signatures among the F+1 first signatures and F+1 second signatures are regarded as abnormal signatures. The blocks in the target secondary node corresponding to the abnormal signatures are repaired. After the blocks in the target secondary node are repaired, the target signature corresponding to the target secondary node is regenerated using the private key of the target secondary node.

[0102] As described above, in scenarios where some nodes in a blockchain cannot communicate (i.e., there is a partition failure), this application divides all the corresponding secondary nodes (i.e., 3F+1 secondary nodes) of the blockchain into two partitions (i.e., the first partition and the second partition). After obtaining F+1 first signatures and F+1 second signatures, the first partition and the second partition are controlled to enter the next blockchain consensus verification stage based on a weak certificate verification method. Compared with the standard certificate verification method in the prior art, which requires waiting for the partition communication to recover and at least 2F+1 signatures to be collected before entering the blockchain consensus verification stage, the number of secondary nodes in each partition in this application is no less than F+1. Therefore, this application can ensure that the system collects F+1 first signatures and F+1 second signatures in parallel at the current stage, thereby satisfying the conditions for the first partition and the second partition to enter the next round of blockchain consensus verification stage. At this time, the system can determine whether the first partition and the second partition in the blockchain have reached a local consensus, thereby improving the verification efficiency of blockchain consensus.

[0103] Furthermore, to mitigate the security risks associated with weak certificate-based verification, after resolving the blockchain partition failure, this application re-collected 2F+1 third signatures corresponding to the 2F+1 secondary nodes in the blockchain. It then verified the consistency between the F+1 first signatures and F+1 second signatures obtained during the asynchronous period before partition communication recovery and the 2F+1 third signatures obtained during the synchronous period after partition communication recovery. Subsequently, signatures inconsistent with the third signatures among the F+1 first and F+1 second signatures were designated as anomalous signatures, and the blocks in the target secondary nodes corresponding to the anomalous signatures were repaired. This combined delay checking and repair techniques with weak certificate-based verification, thereby achieving transaction rollback and vote replay, reducing the security risks associated with weak certificate-based verification, and improving the verification efficiency of blockchain consensus while ensuring the security of the blockchain system.

[0104] Therefore, the technical solution of this application, by combining delayed checking and repair technology with a weak certificate-based verification method, achieves the technical effect of improving the verification efficiency of blockchain consensus while ensuring the security of the blockchain system. This solves the technical problem of low verification efficiency caused by existing blockchain consensus verification methods based on standard certificates when there are partition faults in the blockchain.

[0105] According to another aspect of the embodiments of this application, a device for generating node signatures in a blockchain is also provided. Figure 8 This is a schematic diagram of an optional blockchain node signature generation apparatus according to an embodiment of this application, as shown below. Figure 8 As shown, the blockchain node signature generation device includes: a partitioning unit 801, a first acquisition unit 802, a second acquisition unit 803, and a first generation unit 804.

[0106] Optionally, a partitioning unit is used to divide the 3F+1 secondary nodes corresponding to the blockchain into a first partition and a second partition, where F is a positive integer, each partition includes at least F+1 secondary nodes, and there is a communication failure between the first partition and the second partition; a first acquisition unit is used to acquire F+1 first signatures generated by F+1 secondary nodes in the first partition and F+1 second signatures generated by F+1 secondary nodes in the second partition, and control the first partition and the second partition to enter the blockchain consensus stage respectively; a second acquisition unit is used to acquire 2F+1 third signatures generated by 2F+1 secondary nodes in the blockchain after the communication between the first partition and the second partition is restored; a repair unit is used to treat the signatures in the F+1 first signatures and F+1 second signatures that are inconsistent with the third signature as abnormal signatures, and repair the blocks in the target secondary node corresponding to the abnormal signatures; a first generation unit is used to regenerate the target signature corresponding to the target secondary node using the private key of the target secondary node after the block repair in the target secondary node is completed.

[0107] In one optional embodiment, the blockchain node signature generation device further includes: a third acquisition unit, a first determination unit, and a second determination unit.

[0108] Optionally, the third acquisition unit is used to acquire M endorsement nodes corresponding to the first partition and M endorsement nodes corresponding to the second partition, where M is a positive integer. The endorsement nodes corresponding to the first partition are used to securely communicate with each sub-node in the first partition, and the endorsement nodes corresponding to the second partition are used to securely communicate with each sub-node in the second partition. The first determination unit is used to select any one of the M endorsement nodes in the first partition as the first master node, where the first master node is used to collect F+1 first signatures. The second determination unit is used to select any one of the M endorsement nodes in the second partition as the second master node, where the second master node is used to collect F+1 second signatures.

[0109] In one optional embodiment, the blockchain node signature generation device further includes: a second generation unit, a first transmission unit, and a third generation unit.

[0110] Optionally, the second generation unit is used to generate a first broadcast message through the first master node, wherein the first broadcast message is used to represent the transaction request information initiated by the user; the first transmission unit is used to transmit the first broadcast message to each secondary node in the first partition; the third generation unit is used to generate a first signature corresponding to the i-th secondary node through the private key corresponding to the i-th secondary node after the i-th secondary node in the first partition receives the first broadcast message, wherein i is a positive integer less than or equal to F+1.

[0111] In one optional embodiment, the blockchain node signature generation device further includes a first verification unit and a fourth generation unit.

[0112] Optionally, the first verification unit is used to verify the consistency among the F+1 first signatures through the smart contract corresponding to the blockchain; the fourth generation unit is used to generate a weak certificate corresponding to the first partition when the F+1 first signatures are consistent, wherein the weak certificate is used to verify the identity information of each of the F+1 secondary nodes corresponding to the F+1 first signatures.

[0113] In one optional embodiment, the blockchain node signature generation device further includes a second verification unit and a fifth generation unit.

[0114] Optionally, the second verification unit is used to verify the consistency among the 2F+1 third signatures through the smart contract corresponding to the blockchain; the fifth generation unit is used to generate a standard certificate corresponding to the blockchain when the 2F+1 third signatures are consistent, wherein the standard certificate is used to verify the identity information of each of the 2F+1 secondary nodes corresponding to the 2F+1 third signatures.

[0115] In one optional embodiment, the blockchain node signature generation device further includes: a fourth acquisition unit, a third determination unit, a fourth determination unit, and a fifth determination unit.

[0116] Optionally, the fourth acquisition unit is used to acquire the block length corresponding to the target secondary node and the block length corresponding to each of the 2F+1 secondary nodes corresponding to the 2F+1 third signatures, wherein the block length corresponding to the secondary node is used to characterize the number of blocks stored in the secondary node; the third determination unit is used to select the secondary node with the largest block length among the 2F+1 secondary nodes corresponding to the 2F+1 third signatures as the first secondary node; the fourth determination unit is used to select the minimum value between the block length corresponding to the target secondary node and the block length corresponding to the first secondary node as the target value; the fifth determination unit is used to determine the j-th block in the target secondary node as a faulty block when the stored data in the j-th block in the target secondary node is inconsistent with the j-th block in the first secondary node, wherein j is a positive integer less than or equal to the target value.

[0117] In one optional embodiment, the blockchain node signature generation device further includes: a fifth acquisition unit, a query unit, and an update unit.

[0118] Optionally, the fifth acquisition unit is used to acquire X fault blocks corresponding to the target secondary node, where X is a positive integer less than or equal to the target value; the query unit is used to query X first blocks corresponding to the first secondary node based on the permutation number of each fault block in the X fault blocks among all blocks corresponding to the target secondary node, where the X first blocks correspond one-to-one with the X fault blocks; the update unit is used to update the storage data of the fault block corresponding to the first block based on the storage data of each first block in the X first blocks.

[0119] In this application, the 3F+1 secondary nodes corresponding to the blockchain are first divided into a first partition and a second partition, where F is a positive integer. Each partition includes at least F+1 secondary nodes. There is a communication failure between the first partition and the second partition. Then, F+1 first signatures generated by F+1 secondary nodes in the first partition and F+1 second signatures generated by F+1 secondary nodes in the second partition are obtained. The first partition and the second partition are then controlled to enter the blockchain consensus verification stage respectively. After the communication between the first partition and the second partition is restored, 2F+1 third signatures generated by 2F+1 secondary nodes in the blockchain are obtained. The signatures that are inconsistent with the third signatures among the F+1 first signatures and F+1 second signatures are regarded as abnormal signatures. The blocks in the target secondary node corresponding to the abnormal signatures are repaired. After the blocks in the target secondary node are repaired, the target signature corresponding to the target secondary node is regenerated using the private key of the target secondary node.

[0120] As described above, in scenarios where some nodes in a blockchain cannot communicate (i.e., there is a partition failure), this application divides all the corresponding secondary nodes (i.e., 3F+1 secondary nodes) of the blockchain into two partitions (i.e., the first partition and the second partition). After obtaining F+1 first signatures and F+1 second signatures, the first partition and the second partition are controlled to enter the next blockchain consensus verification stage based on a weak certificate verification method. Compared with the standard certificate verification method in the prior art, which requires waiting for the partition communication to recover and at least 2F+1 signatures to be collected before entering the blockchain consensus verification stage, the number of secondary nodes in each partition in this application is no less than F+1. Therefore, this application can ensure that the system collects F+1 first signatures and F+1 second signatures in parallel at the current stage, thereby satisfying the conditions for the first partition and the second partition to enter the next round of blockchain consensus verification stage. At this time, the system can determine whether the first partition and the second partition in the blockchain have reached a local consensus, thereby improving the verification efficiency of blockchain consensus.

[0121] Furthermore, to mitigate the security risks associated with weak certificate-based verification, after resolving the blockchain partition failure, this application re-collected 2F+1 third signatures corresponding to the 2F+1 secondary nodes in the blockchain. It then verified the consistency between the F+1 first signatures and F+1 second signatures obtained during the asynchronous period before partition communication recovery and the 2F+1 third signatures obtained during the synchronous period after partition communication recovery. Subsequently, signatures inconsistent with the third signatures among the F+1 first and F+1 second signatures were designated as anomalous signatures, and the blocks in the target secondary nodes corresponding to the anomalous signatures were repaired. This combined delay checking and repair techniques with weak certificate-based verification, thereby achieving transaction rollback and vote replay, reducing the security risks associated with weak certificate-based verification, and improving the verification efficiency of blockchain consensus while ensuring the security of the blockchain system.

[0122] Therefore, the technical solution of this application, by combining delayed checking and repair technology with a weak certificate-based verification method, achieves the technical effect of improving the verification efficiency of blockchain consensus while ensuring the security of the blockchain system. This solves the technical problem of low verification efficiency caused by existing blockchain consensus verification methods based on standard certificates when there are partition faults in the blockchain.

[0123] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored computer program, wherein, when the computer program is running, it controls the device where the computer-readable storage medium is located to execute the method for generating node signatures of the blockchain according to any of the above.

[0124] According to another aspect of the embodiments of this application, an electronic device is also provided, including: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute a method for generating a node signature of a blockchain via executing the executable instructions.

[0125] Optionally, Figure 9 This is a schematic diagram of an optional electronic device according to an embodiment of this application, such as... Figure 9 As shown, this application provides an electronic device, which includes a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements the method for generating node signatures of a blockchain as described above.

[0126] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0127] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of 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, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0128] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0129] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0130] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory. Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0131] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0132] It should also be noted that 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 process, method, article, or apparatus. Unless otherwise specified, 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.

[0133] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0134] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for generating node signatures in a blockchain, characterized in that, include: The 3F+1 secondary nodes corresponding to the blockchain are divided into a first partition and a second partition, where F is a positive integer, each partition includes at least F+1 secondary nodes, and there is a communication failure between the first partition and the second partition; Obtain F+1 first signatures generated by F+1 secondary nodes in the first partition and F+1 second signatures generated by F+1 secondary nodes in the second partition, and control the first partition and the second partition to enter the blockchain consensus verification stage respectively; After communication between the first partition and the second partition is restored, obtain 2F+1 third signatures generated by 2F+1 secondary nodes in the blockchain; The signatures among the F+1 first signatures and F+1 second signatures that are inconsistent with the third signature are regarded as abnormal signatures, and the blocks in the target sub-nodes corresponding to the abnormal signatures are repaired. After the block repair in the target sub-node is completed, the target signature corresponding to the target sub-node is regenerated using the private key of the target sub-node.

2. The method for generating node signatures in a blockchain according to claim 1, characterized in that, After dividing the 3F+1 secondary nodes corresponding to the blockchain into a first partition and a second partition, the method for generating node signatures of the blockchain further includes: Obtain M endorsement nodes corresponding to the first partition and M endorsement nodes corresponding to the second partition, where M is a positive integer. The endorsement nodes corresponding to the first partition are used to communicate securely with each sub-node in the first partition, and the endorsement nodes corresponding to the second partition are used to communicate securely with each sub-node in the second partition. Take any one of the M endorsement nodes in the first partition as the first master node, wherein the first master node is used to collect the F+1 first signatures; Any one of the M endorsement nodes in the second partition is used as the second master node, wherein the second master node is used to collect the F+1 second signatures.

3. The method for generating node signatures in a blockchain according to claim 2, characterized in that, In the process of obtaining F+1 first signatures generated by F+1 secondary nodes in the first partition and F+1 second signatures generated by F+1 secondary nodes in the second partition, the method for generating node signatures in the blockchain further includes: The first master node generates a first broadcast message, wherein the first broadcast message is used to represent the transaction request information initiated by the user; The first broadcast message is transmitted to each secondary node in the first partition; After the i-th sub-node in the first partition receives the first broadcast message, it generates the first signature corresponding to the i-th sub-node using the private key corresponding to the i-th sub-node, where i is a positive integer less than or equal to F+1.

4. The method for generating node signatures in a blockchain according to claim 1, characterized in that, After obtaining F+1 first signatures generated by F+1 secondary nodes in the first partition and F+1 second signatures generated by F+1 secondary nodes in the second partition, the method for generating node signatures in the blockchain further includes: The consistency among the F+1 first signatures is verified through the smart contract corresponding to the blockchain; If the F+1 first signatures are consistent, a weak certificate is generated corresponding to the first partition. The weak certificate is used to verify the identity information of each of the F+1 secondary nodes corresponding to the F+1 first signatures.

5. The method for generating node signatures in a blockchain according to claim 1, characterized in that, After obtaining 2F+1 third signatures generated by 2F+1 secondary nodes in the blockchain, the method for generating node signatures in the blockchain further includes: The consistency among the 2F+1 third signatures is verified through the smart contract corresponding to the blockchain; If the 2F+1 third signatures are consistent, a standard certificate corresponding to the blockchain is generated. The standard certificate is used to verify the identity information of each of the 2F+1 secondary nodes corresponding to the 2F+1 third signatures.

6. The method for generating node signatures in a blockchain according to claim 1, characterized in that, Before repairing the block in the target secondary node corresponding to the abnormal signature, the method for generating the node signature of the blockchain further includes: Obtain the block length corresponding to the target secondary node and the block length corresponding to each of the 2F+1 secondary nodes corresponding to the 2F+1 third signatures, wherein the block length corresponding to the secondary node is used to characterize the number of blocks stored in the secondary node; The sub-node with the largest block length among the 2F+1 sub-nodes corresponding to the 2F+1 third signatures is taken as the first sub-node; The minimum value between the block length corresponding to the target sub-node and the block length corresponding to the first sub-node is taken as the target value; If the stored data in the j-th block of the target secondary node is inconsistent with that in the j-th block of the first secondary node, the j-th block of the target secondary node is identified as a faulty block, where j is a positive integer less than or equal to the target value.

7. The method for generating node signatures in a blockchain according to claim 6, characterized in that, After identifying the j-th block in the target secondary node as a faulty block, the method for generating the node signature of the blockchain includes: Obtain X fault blocks corresponding to the target secondary node, where X is a positive integer less than or equal to the target value; Based on the sequence number of each of the X fault blocks in the target sub-node among all blocks, X first blocks corresponding to the first sub-node are obtained, wherein the X first blocks correspond one-to-one with the X fault blocks; The storage data of the faulty block corresponding to the first block is updated based on the storage data of each of the X first blocks.

8. A device for generating node signatures in a blockchain, characterized in that, include: A partitioning unit is used to divide the 3F+1 secondary nodes corresponding to the blockchain into a first partition and a second partition, where F is a positive integer, each partition includes at least F+1 secondary nodes, and there is a communication failure between the first partition and the second partition. The first acquisition unit is used to acquire F+1 first signatures generated by F+1 secondary nodes in the first partition and F+1 second signatures generated by F+1 secondary nodes in the second partition, and to control the first partition and the second partition to enter the blockchain consensus stage respectively. The second acquisition unit is used to acquire 2F+1 third signatures generated by 2F+1 secondary nodes in the blockchain after the communication between the first partition and the second partition is restored. The repair unit is used to identify the signatures among the F+1 first signatures and the F+1 second signatures that are inconsistent with the third signature as abnormal signatures, and to repair the blocks in the target sub-nodes corresponding to the abnormal signatures. The first generation unit is used to regenerate the target signature corresponding to the target sub-node using the private key of the target sub-node after the block repair in the target sub-node is completed.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to perform the method for generating node signatures of the blockchain according to any one of claims 1 to 7.

10. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the method for generating node signatures of a blockchain according to any one of claims 1 to 7.

Images