Block chain consensus method and device, nonvolatile storage medium and electronic equipment

Abstract

The invention discloses a block chain consensus method and device, a nonvolatile storage medium and electronic equipment. The method comprises the steps that a first consensus request initiating node in a first slave chain of the block chain sends a first consensus request to a first representative node in the first slave chain; the first consensus request initiating node receives first consensus responses sent by the non-consensus request initiating node, and performs quantity and data consistency judgment on the first consensus responses; and when the judgment result is that the first consensus request initiating node receives N identical first consensus responses, the first consensus request initiating node sends consensus result data in the first consensus responses to a first node in a main chain of the block chain corresponding to the first slave chain, and the first node is used as a second consensus request initiating node to send consensus result data to other nodes in the main chain. The technical problem of low consensus efficiency of the block chain in the related technology is solved.

Description

Technical Field

[0001] The present application relates to the field of block fault tolerance algorithms, and more specifically, to a blockchain consensus method and apparatus, a non-volatile storage medium, and an electronic device. Background Art

[0002] In the fields of distributed computing and network communication, the Byzantine Fault Tolerance (BFT) algorithm is widely used to solve the problem of how to ensure that all honest nodes in the system can reach an agreement in the case of possible node failures or malicious behaviors. With the rise of blockchain technology, the application of the BFT algorithm in the blockchain consensus mechanism has become particularly important, because it can ensure that nodes in the network can reach an agreement on the validity of transaction data without centralized trust, thus ensuring the correctness and immutability of the blockchain ledger.

[0003] However, traditional BFT algorithms, such as PBFT (Practical Byzantine Fault Tolerance), have efficiency bottlenecks when dealing with large-scale networks and high-concurrency transactions. This is because as the number of nodes participating in the consensus in the network increases, the communication overhead and processing time between nodes will also increase significantly, especially in the cross-chain communication scenario, that is, the interoperability between different blockchains, this problem is particularly prominent. Cross-chain communication requires transmitting and verifying transaction information between different blockchains, and different chains may adopt different consensus algorithms and data structures, which leads to communication complexity and latency problems, affecting the overall performance and user experience of the system.

[0004] In addition, existing cross-chain BFT consensus mechanisms often lack sufficient flexibility and robustness when dealing with node dynamic changes and network partitions. For example, in the case of nodes joining or leaving the system, or the network experiencing a partition (i.e., communication interruption between some nodes), existing algorithms may need to be reconfigured or go through a long recovery process, which not only increases the operating cost of the system, but also reduces the response speed and availability of the system.

[0005] In view of the above problems, no effective solution has been proposed yet. Summary of the Invention

[0006] The present application provides a blockchain consensus method and apparatus, a non-volatile storage medium, and an electronic device, so as to at least solve the technical problem of low consensus efficiency of the blockchain in related technologies.

[0007] According to an aspect of the present application, a blockchain consensus method is provided, including: a first consensus request initiating node in a first slave chain of a blockchain sends a first consensus request to a first representative node in the first slave chain, where the blockchain includes a main chain and multiple slave chains, the main chain includes multiple different nodes having an associated relationship with different slave chains, and the first representative node is configured to send the first consensus request to N non-consensus request initiating nodes in the first slave chain, and the N non-consensus request initiating nodes include: the first representative node and first replica nodes other than the first representative node, and N is a positive integer greater than 1; the first consensus request initiating node receives a first consensus response sent by the non-consensus request initiating node, and determines the quantity and data consistency of the first consensus response; in the case where the determination result is that the first consensus request initiating node receives N identical first consensus responses, the first consensus request initiating node sends the consensus result data in the first consensus response to a first node in the main chain of the blockchain corresponding to the first slave chain, where the first node is configured to act as a second consensus request initiating node to send the consensus result data to the remaining nodes in the main chain.

[0008] Optionally, a first consensus request initiating node in a first slave chain of a blockchain sending a first consensus request to a first representative node in the first slave chain includes: the first consensus request initiating node sending a first consensus request to the first representative node, where the first consensus request includes: a first consensus request identifier, a first request signature, and a first timestamp, and the first representative node is configured to determine whether the first consensus request identifier is correct, and in the case where it is determined that the first consensus request identifier is correct, verify the first request signature and the first timestamp; in the case where the verification of the first request signature and the first timestamp is passed, send the first consensus request to N non-consensus request initiating nodes, where each node in the N non-consensus request initiating nodes is configured to perform local calculation after receiving the first consensus request, digitally sign the calculated digest data, add the signed data to the first consensus response, and send the first consensus response to the first consensus request initiating node.

[0009] Optionally, the method further includes: in the case that the first consensus request initiating node does not receive N identical first consensus responses, the first consensus request initiating node resends the first consensus request to the first representative node; in the case that the number of times of resending the first consensus request to the first representative node reaches a preset number and the first consensus request initiating node still does not receive N identical first consensus responses, the first consensus request initiating node sends a second consensus request different from the first consensus request to the first representative node; the first representative node determines the identification information of the second consensus request in the first view and sends a node broadcast prepare message to N non-consensus request initiating nodes, where the node broadcast prepare message includes: the identification information of the first view and the identification information of the second consensus request; after receiving the node broadcast prepare message, the first replica node sends a node broadcast message to N non-consensus request initiating nodes, where the node broadcast message includes: the identification information of the first view and the identification information of the second consensus request; the N non-consensus request initiating nodes determine whether the identification information in the node broadcast prepare message is consistent with the identification information in the node broadcast message, and in the case of determining that the identification information in the node broadcast prepare message is consistent with the identification information in the node broadcast message, send a second consensus response with a digital signature added to the first consensus request initiating node; the first consensus request initiating node receives the second consensus responses sent by the N non-consensus request initiating nodes, packs the received second consensus responses, and sends the packing result to the N non-consensus request initiating nodes.

[0010] Optionally, the method further includes: after determining that the identification information in the node broadcast prepare message is consistent with the identification information in the node broadcast message, determining whether the number of messages received by each of the N non-consensus request initiating nodes is greater than or equal to 2f + 1, where f is the number of faulty nodes in the first sub-chain; in the case that the number of messages received by each of the N non-consensus request initiating nodes is greater than or equal to 2f + 1, sending a second consensus response with a digital signature added to the first consensus request initiating node.

[0011] Optionally, the method further includes: the second consensus request initiating node sends a third consensus request to the second representative node in the main chain, where the second representative node is used to send the third consensus request to M non-consensus request initiating nodes in the main chain, and the M non-consensus request initiating nodes include: the second representative node and the second replica node, and M is a positive integer greater than 1; if the second consensus request initiating node does not receive M identical third consensus responses, search for the faulty node among the M non-consensus request initiating nodes, replace the faulty node with the corresponding sub-chain of the faulty node, and send a fourth consensus request to the second representative node; the second representative node determines the identification information of the fourth consensus request in the second view, and sends a node broadcast preparation message to the M non-consensus request initiating nodes, where the node broadcast preparation message includes: the identification information of the second view and the identification information of the fourth consensus request; after receiving the node broadcast preparation message, the second replica node sends a node broadcast message to the M non-consensus request initiating nodes, where the node broadcast message includes: the identification information of the second view and the identification information of the fourth consensus request; the M non-consensus request initiating nodes determine whether the identification information in the node broadcast preparation message is consistent with the identification information in the node broadcast message, and when it is determined that the identification information in the node broadcast preparation message is consistent with the identification information in the node broadcast message, send the fourth consensus response with a digital signature added to the second consensus request initiating node; the second consensus request initiating node receives the fourth consensus responses sent by the M non-consensus request initiating nodes, packs the received fourth consensus responses, and sends the packing result to the M non-consensus request initiating nodes.

[0012] Optionally, the method further includes: after sending the consensus result data to the remaining nodes in the main chain, sending the consensus result data to other nodes in their respective corresponding sub-chains through their respective corresponding representative nodes.

[0013] Optionally, the method further includes: after sending the consensus result data to the remaining nodes in the main chain, if there is a target sub-chain newly accessing the blockchain, taking the consensus result data as the consensus message of the target sub-chain for in-sub-chain consensus, and performing in-chain and / or inter-chain communication after completing the in-sub-chain consensus.

[0014] According to another aspect of the present application, there is also provided a blockchain consensus device, including: a first processing module, configured to instruct a first consensus request initiating node in a first slave chain of the blockchain to send a first consensus request to a first representative node in the first slave chain, wherein the blockchain includes a main chain and multiple slave chains, the main chain includes multiple different nodes associated with different slave chains, and the first representative node is configured to send the first consensus request to N non-consensus request initiating nodes in the first slave chain, the N non-consensus request initiating nodes include: the first representative node and first replica nodes other than the first representative node, and N is a positive integer greater than 1; a judgment module, configured to instruct the first consensus request initiating node to receive a first consensus response sent by the non-consensus request initiating node, and perform quantity and data consistency judgment on the first consensus response; a second processing module, configured to instruct that in the case where the judgment result is that the first consensus request initiating node receives N identical first consensus responses, the first consensus request initiating node sends the consensus result data in the first consensus response to a first node in the main chain of the blockchain corresponding to the first slave chain, wherein the first node is configured to act as a second consensus request initiating node to send the consensus result data to the remaining nodes in the main chain.

[0015] According to another aspect of the present application, there is also provided a non-volatile storage medium, the storage medium includes a stored program, wherein when the program runs, it controls the device where the storage medium is located to execute the above blockchain consensus method.

[0016] According to another aspect of the present application, there is also provided an electronic device, including: a memory and a processor, the processor is configured to run a program stored in the memory, wherein when the program runs, it executes the above blockchain consensus method.

[0017] According to another aspect of the present application, there is also provided a computer program, wherein when the computer program is executed by a processor, it implements the above blockchain consensus method.

[0018] According to another aspect of the present application, there is also provided a computer program product, the computer program product includes a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it implements the above blockchain consensus method.

[0019] In this application, the first consensus request initiating node in the first slave chain of the blockchain sends a first consensus request to the first representative node in the first slave chain. Herein, the blockchain includes a main chain and multiple slave chains, and the main chain includes multiple different nodes that have an associated relationship with different slave chains. The first representative node is used to send the first consensus request to N non-consensus request initiating nodes in the first slave chain. The N non-consensus request initiating nodes include: the first representative node and the first replica nodes other than the first representative node, where N is a positive integer greater than 1. The first consensus request initiating node receives the first consensus response sent by the non-consensus request initiating nodes, and judges the quantity and data consistency of the first consensus response. In the case where the judgment result is that the first consensus request initiating node receives N identical first consensus responses, the first consensus request initiating node sends the consensus result data in the first consensus response to the first node in the main chain of the blockchain corresponding to the first slave chain. Herein, the first node is used as the second consensus request initiating node to send the consensus result data to the remaining nodes in the main chain, achieving the purpose of improving the consensus efficiency of the blockchain, thus realizing the technical effect of reducing network latency, and further solving the technical problem of relatively low consensus efficiency of the blockchain in the related art. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0021] Figure 1 is a flowchart of a blockchain consensus method according to an embodiment of the present application;

[0022] Figure 2 is a schematic diagram of a communication model of a consensus algorithm according to an embodiment of the present application;

[0023] Figure 3 is a schematic flowchart of a consensus algorithm according to an embodiment of the present application;

[0024] Figure 4 is a structural diagram of a blockchain consensus device according to an embodiment of the present application;

[0025] Figure 5 is a hardware structure block diagram of a computer terminal of a blockchain consensus method according to an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

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

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

[0028] For the related technology 1 (patent number CN115941680A), this method faces problems of low efficiency caused by high communication complexity and long latency in cross-shard transaction processing, increasing the confirmation latency of transactions. Cross-shard security problems caused by incomplete cross-shard message passing. Since the leader is mainly responsible for forwarding cross-shard transaction messages, nodes within a shard cannot know whether the key information is forwarded by the leader. Therefore, a malicious leader may modify cross-shard transactions. The aggregate signature used in the solution requires high processing power. The signature is jointly generated by multiple entities, and it will be impossible to trace the specific signature entity. The private keys of all entities need to participate together. If one is leaked, it will pose a threat to the security of the entire system. The parallelism of this solution is relatively low, and the overall performance is limited by the bandwidth and computing power of the leader.

[0029] For related technology 2 (CN110677485A), both "read" and "write" type operations in this method require reaching a consensus. In a blockchain, a "read" operation does not change the data state in the ledger, so consensus is not required. Mixing "read" and "write" operations together will reduce the consensus efficiency of the system. At the same time, the serial operation verification process of the primary node and the replica nodes occupies most of the consensus process time, which also increases the latency. Secondly, all consensus nodes are equal and have the same chance to become the primary node, which does not encourage the enthusiasm of honest consensus nodes. The primary node is generated in rotation, which makes the primary node more vulnerable to attacks. In this solution, the consensus nodes are fixed. The system can only "punish" the primary node through the view conversion protocol, cannot detect whether the replica nodes are reliable, and cannot remove incorrect consensus nodes. This reduces the security and stability of the system.

[0030] To solve the above problems, relevant solutions are provided in the embodiments of the present application, which are described in detail below.

[0031] According to an embodiment of the present application, a method embodiment of a blockchain consensus method is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. And although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.

[0032] Figure 1 is a flowchart of a blockchain consensus method according to an embodiment of the present application, as Figure 1 shown, the method includes the following steps:

[0033] Step S102, a first consensus request initiating node in the first slave chain of the blockchain sends a first consensus request to a first representative node in the first slave chain. Among them, the blockchain includes a main chain and multiple slave chains, and the main chain includes multiple different nodes associated with different slave chains. The first representative node is used to send the first consensus request to N non-consensus request initiating nodes in the first slave chain. The N non-consensus request initiating nodes include: the first representative node and the first replica nodes other than the first representative node. N is a positive integer greater than 1.

[0034] Among them, the consensus request initiating node is the node that first initiates the consensus process in the blockchain network. It is responsible for generating transactions or data and submitting them to other nodes in the network for verification and confirmation. In the master-slave chain structure, each slave chain has its own consensus request initiating node.

[0035] The representative node is responsible for communicating between the slave chain and the main chain, forwarding the consensus result of the slave chain to the main chain, and at the same time, it can also forward the decisions or data of the main chain back to the slave chain, so as to achieve the transfer of cross-chain data and trust. The representative node receives requests from the consensus request initiating node and then forwards these requests to other nodes in the slave chain to initiate or continue the local consensus process of the slave chain.

[0036] For example, the consensus request initiating node in the slave chain can be determined by the following methods: 1. Polling mechanism: All possible initiating nodes take turns serving as the consensus request initiating node in sequence. This can ensure that all nodes have the opportunity to participate in the initiation of consensus, avoiding single-point failures and centralization risks. 2. Random selection: At the beginning of each consensus cycle, a node is randomly selected from the nodes participating in the consensus as the consensus request initiating node through a random algorithm. This method increases the difficulty for attackers to predict the consensus initiating node and improves the security of the system. 3. Reputation / credit: The consensus request initiating node is selected based on the reputation or credit of the node in the system. The reputation of the node can be evaluated by factors such as historical behavior, accuracy of verifying transactions, and response speed. Nodes with higher reputation will have a higher probability of being selected, which can encourage nodes to maintain good behavior and optimize the efficiency of the consensus process at the same time. 4. Hashing algorithm: The hashing algorithm is used to determine the consensus request initiating node. For example, the public key or other identifiers of the node are used for hashing calculation to determine the initiating node. This method can ensure the randomness and unpredictability of node selection.

[0037] The representative node in the slave chain can be determined by the following methods: 1. Resource-based allocation: The representative node is selected based on the hardware resources of the node, such as computing power, bandwidth, and storage resources. Selecting representative nodes from nodes with rich resources can improve the efficiency of the consensus process because they can process and forward data faster. 2. Nodes can obtain the opportunity to become representative nodes through a competition mechanism (such as solving complex mathematical problems). The node that solves the problem first will be selected as the representative node.

[0038] Step S104, the first consensus request initiating node receives the first consensus response sent by the non-consensus request initiating node and judges the quantity and data consistency of the first consensus response.

[0039] Step S106, in the case where the judgment result is that the first consensus request initiating node receives N identical first consensus responses, the first consensus request initiating node sends the consensus result data in the first consensus response to the first node in the main chain of the blockchain corresponding to the first slave chain, where the first node is used as the second consensus request initiating node to send the consensus result data to the remaining nodes in the main chain.

[0040] Suppose a financial transaction network based on blockchain, which includes a main chain and two slave chains: Slave Chain A and Slave Chain B. Slave Chain A is responsible for processing small payment transactions worldwide, while Slave Chain B focuses on processing large transactions. The main chain is responsible for coordinating and confirming cross-chain transactions between the two slave chains to ensure the accuracy and trust transfer of transactions.

[0041] In slave chain A, node U A (The first consensus request initiator) plans to make a large cross-chain payment transaction to chain B. In order to reach a consensus, node U A To SC A (First Representative Node) sent a first consensus request containing transaction details. A After receiving the request, forward the request to the SC A N non-consensus request initiating nodes (from other nodes in chain A, including SC A and several first replica nodes A i ).

[0042] Node U A Start waiting for response messages from N non-consensus request initiating nodes. These response messages contain the verification results of the request, including signatures and summaries. A The consensus responses are checked for consistency in number, that is, whether N first consensus responses with the same result have been received. At the same time, the UA also checks the data consistency to ensure that the data in all responses are consistent and correct.

[0043] If U A After confirming that the N responses received are consistent and the data is correct, it will encapsulate the consensus result data and send it to M in the main chain. A Node (first node).

[0044] M A The node is the main chain node representing slave chain A, responsible for forwarding the consensus result data of slave chain A to the other nodes on the main chain for the next step of main chain consensus. A Its responsibilities are not limited to data forwarding, it also participates in the consensus process of the main chain to ensure the integrity and accuracy of the data.

[0045] Furthermore, in M A After receiving the first consensus result data, it will serve as the second consensus request initiator and forward the data to all nodes in the main chain, including the main chain node M related to the slave chain B. B , start the main chain consensus process. Main chain node M B Upon receiving M A After the node forwards the consensus result data, it will serve as the consensus initiator node to conduct consensus in slave chain B.B (Representative Node) Auxiliary M B Perform the consensus process to ensure that transactions are also agreed upon among the nodes in Sub-chain B. Once the nodes in Sub-chain B reach a consensus, the transaction data is confirmed and synchronously updated in both sub-chains and the main chain, completing the processing of the entire cross-chain transaction.

[0046] According to the above steps, the first consensus request initiating node in the first sub-chain of the blockchain sends a first consensus request to the first representative node in the first sub-chain. Among them, the blockchain includes a main chain and multiple sub-chains, and the main chain includes multiple different nodes associated with different sub-chains. The first representative node is used to send the first consensus request to N non-consensus request initiating nodes in the first sub-chain. The N non-consensus request initiating nodes include: the first representative node and the first replica nodes other than the first representative node. N is a positive integer greater than 1. The first consensus request initiating node receives the first consensus response sent by the non-consensus request initiating nodes and judges the quantity and data consistency of the first consensus response. In the case where the judgment result is that the first consensus request initiating node receives N identical first consensus responses, the first consensus request initiating node sends the consensus result data in the first consensus response to the first node in the main chain of the blockchain corresponding to the first sub-chain. Among them, the first node is used to send the consensus result data to the remaining nodes in the main chain as the second consensus request initiating node, achieving the purpose of improving the consensus efficiency of the blockchain, thereby realizing the technical effect of reducing network latency.

[0047] Next, Figure 1 The steps shown will be described and explained by way of example.

[0048] According to some optional embodiments of the present application, the first consensus request initiating node in the first sub-chain of the blockchain sending a first consensus request to the first representative node in the first sub-chain can be implemented by the following method: The first consensus request initiating node sends a first consensus request to the first representative node. Among them, the first consensus request includes: a first consensus request identifier, a first request signature, and a first timestamp. The first representative node is used to judge whether the first consensus request identifier is correct, and in the case where the first consensus request identifier is judged to be correct, verify the first request signature and the first timestamp. In the case where the verification of the first request signature and the first timestamp passes, send the first consensus request to N non-consensus request initiating nodes. Each of the N non-consensus request initiating nodes is used to perform local calculation after receiving the first consensus request, digitally sign the calculated digest data, add the signed data to the first consensus response, and send the first consensus response to the first consensus request initiating node.

[0049] Specifically, the process of initiating a consensus request begins with a specific node U in the chain A , which acts as the initiator of the consensus request. When U A needs to verify and confirm consensus for a transaction or data, it constructs a consensus request message containing the timestamp t, the consensus request identifier Request, and the signature SigU A of node U A . U A then sends this message to the representative node SC A in the slave chain. Among them, t is used to record the moment when the request is sent, helping to prevent message replay or timing attacks; the consensus request identifier Request ensures the uniqueness of the request; the signature SigU A of node U A is used to verify the source of the message and prevent message tampering during transmission.

[0050] After receiving the consensus request, the representative node SC A first needs to verify whether the request is valid. Specifically, it includes checking whether the timestamp t is within the valid time window, ensuring the correctness of the consensus request identifier Request, and verifying the signature SigUA of node U A to confirm the true source of the request. Once SC A confirms the legality of the request, it numbers the consensus request and then forwards the request to N non-consensus request initiating nodes in the slave chain including itself. This number is the approval of the consensus request by SC A , which helps to ensure that all nodes are processing the same request, avoiding confusion and duplication.

[0051] SC A and each non-consensus initiating node, including each replica node A i , independently processes the consensus request, including verifying the validity of the transaction or data, calculating the digest data, and digitally signing the digest data to generate the first consensus response. Then, these consensus responses are sent by SC A and each A i node to U A . U A After receiving these consensus responses, it checks the validity of the signatures and the consistency of the digest data. If U A receives a sufficient number (N) of responses with the same digest information and all signatures pass the verification, then UA can conclude that there are no faulty nodes in the system and the consensus process is successfully completed in the slave chain

[0052] When U AAfter verifying the consensus responses of N nodes, these signed responses will be packaged into a data packet and sent to N non-consensus request initiating nodes again, including SC A and all replica nodes A i . After receiving the data packet of U A , all nodes will verify the signature of U A and the digest data in the aggregated consensus response again. Once all nodes confirm the integrity of the data packet and the validity of the consensus response, they will save the consensus result locally, indicating that SC A the consensus process has been completed, and the data or transaction has reached a consensus within the scope of the chain. At this time, the consensus request process between SC A and U A and between U A and all other non-consensus request initiating nodes ends.

[0053] According to some other optional embodiments of the present application, the blockchain consensus method further includes: in the case that the first consensus request initiating node does not receive N identical first consensus responses, the first consensus request initiating node resends the first consensus request to the first representative node. When the number of times of resending the first consensus request to the first representative node reaches a preset number, and the first consensus request initiating node still does not receive N identical first consensus responses, the first consensus request initiating node sends a second consensus request different from the first consensus request to the first representative node; the first representative node determines the identification information of the second consensus request in the first view and sends a node broadcast preparation message to N non-consensus request initiating nodes, where the node broadcast preparation message includes: the identification information of the first view and the identification information of the second consensus request; after receiving the node broadcast preparation message, the first replica node sends a node broadcast message to N non-consensus request initiating nodes, where the node broadcast message includes: the identification information of the first view and the identification information of the second consensus request; N non-consensus request initiating nodes determine whether the identification information in the node broadcast preparation message is consistent with the identification information in the node broadcast message, and in the case of determining that the identification information in the node broadcast preparation message is consistent with the identification information in the node broadcast message, send the second consensus response with a digital signature added to the first consensus request initiating node; the first consensus request initiating node receives the second consensus responses sent by N non-consensus request initiating nodes and packages the received second consensus responses, and sends the packaging result to N non-consensus request initiating nodes.

[0054] In the above embodiment, when the consensus request initiating node U A fails to collect signed responses with N identical digest information from N participating nodes, UA resends to the first representative node SC ASend the first consensus request. This time interval can be regarded as a timeout waiting mechanism for handling network latency or minor node failures. If, after a preset number of re-requests (e.g., 3 times), U A still fails to collect a sufficient number of identical first consensus responses, indicating that the current SC A consensus mechanism may fail due to a complex network environment or the presence of malicious nodes.

[0055] Therefore, U A sends a second consensus request different from the first consensus request to SC A . The second consensus request can contain different or additional information to ensure that the PBFT algorithm can correctly initialize the consensus process. For example, it can contain the urgency level of the request or additional verification information.

[0056] After SC A receives U A 's second consensus request, it assigns a unique number n to the request in the current first view v it is in. SC A Then constructs a node broadcast prepare message that contains not only the identification information of the first view v but also the number n of the second consensus request. SC A Broadcasts this message to N non-consensus request initiating nodes, and each node will start local verification and processing based on this information.

[0057] When the non-consensus initiating nodes (including SC A and all replica nodes A i ) receive the node broadcast prepare message from SC A , they first verify the identification information of the first view v and the number n of the second consensus request in the message to ensure the legality and timeliness of the message. Once the message is verified successfully, the node broadcasts a node broadcast message to all N non-consensus request initiating nodes. This message also contains the identification information of the first view v and the number n of the second consensus request.

[0058] Each non-consensus request initiating node generates a second consensus response based on the received broadcast prepare message and the identification information of the first view v and the number n of the second consensus request in the broadcast message, which contains the signature of the digest data. The node will send the second consensus response to U A only when it determines that the identification information in the node broadcast prepare message and the broadcast message is consistent. U A After receiving the second consensus responses from N nodes, packs these responses and sends them to N nodes again to confirm the consensus result.

[0059] Through the above steps, even when encountering complex network or node failures in the chain, the system can restore the consensus process and data confirmation through the dynamic switching of the consensus mechanism and the interaction between nodes. This process not only ensures the consistency and integrity of data, but also improves the stability and security of the system. Even if some nodes fail or there is malicious behavior, it can ensure the normal operation of the entire consensus process and the reliable confirmation of data, thus providing a solid technical foundation for cross-chain communication and data sharing.

[0060] In some optional embodiments of the present application, the blockchain consensus method further includes: after determining that the identification information in the node broadcast preparation message is consistent with the identification information in the node broadcast message, determining whether the number of messages received by each of the N non-consensus request initiating nodes is greater than or equal to 2f + 1, where f is the number of faulty nodes in the first sub-chain; in the case where the number of messages received by each of the N non-consensus request initiating nodes is greater than or equal to 2f + 1, sending the second consensus response with a digital signature to the first consensus request initiating node.

[0061] It should be noted that the message m in the algorithm of this implementation is encapsulated in a digital signature and a message authentication code for transmission. The digital signature is generated by the private key of the sending node, and the receiving node uses the public key of the node to verify the digital signature to ensure the source and integrity of the message m. The message authentication code is a mechanism for verifying message integrity and protecting data from tampering. It is usually generated by the sender using a shared key k and the message m, and the receiver uses the same key k to verify the MAC to ensure that the message has not been changed during transmission.

[0062] In the algorithm, m represents the specific transmission message, and k represents the unique serial number of the node, which is used to identify a specific node in the blockchain network. The form of the transmitted message is σ(k, m), which is actually a signature function that combines the private key of node k and the message m to generate a digital signature σ for verifying the authenticity and integrity of the message.

[0063] The total number N of non-consensus initiating nodes in the consensus process refers to the number of nodes participating in the consensus decision except for the consensus request initiating node. The setting of N needs to consider the number of faulty nodes and non-responsive nodes that may appear in the network to ensure the reliability of the consensus process.

[0064] The minimum number of response messages Q required to reach a correct decision by consensus is defined as Q = 2f + 1, where f represents the number of potentially faulty nodes. This means that at least twice the number of faulty nodes plus one additional correct node's response is needed to ensure the correct establishment of consensus. This design is to withstand Byzantine faults, so that even in the case of some nodes being faulty or engaging in malicious behavior, the system can still reach a consensus through the responses of the remaining correct nodes. R represents the number of non-responsive nodes, which may fail to respond in a timely manner due to network failures, delays, or other reasons, but are not necessarily malicious nodes.

[0065] Considering the possible malicious nodes and non-responsive nodes, there are at most f faulty nodes in the blockchain system, where f can be distributed among the non-responsive correct nodes (R) and the responsive malicious nodes. To ensure the correctness of the consensus, assume that all R non-responsive nodes are potentially correct nodes that just fail to participate in the consensus due to communication failures. Then, among the responsive nodes, at least f + 1 correct nodes are needed to overcome the influence of the faulty nodes, thus ensuring the correct decision-making in the consensus process. Therefore, the requirement that N must be greater than or equal to 3f + 1 is proposed in the algorithm to ensure that there are still enough correct nodes in the system to reach a consensus when any f nodes may be faulty.

[0066] At the same time, the requirement that Q (the minimum number of responses required for consensus decision) must be greater than or equal to 2f + 1 ensures that even in the worst-case scenario, that is, f nodes are faulty and f nodes are non-responsive, there is still at least one additional correct node's response, thus meeting the conditions for reaching a consensus.

[0067] As some alternative embodiments of the present application, the blockchain consensus method further includes: the second consensus request initiating node sends a third consensus request to the second representative node in the main chain, where the second representative node is used to send the third consensus request to M non-consensus request initiating nodes in the main chain, and the M non-consensus request initiating nodes include: the second representative node and the second replica node, and M is a positive integer greater than 1; if the second consensus request initiating node does not receive M identical third consensus responses, search for the faulty node among the M non-consensus request initiating nodes, replace the faulty node with the corresponding sub-chain of the faulty node, and send a fourth consensus request to the second representative node; the second representative node determines the identification information of the fourth consensus request in the second view, and sends a node broadcast prepare message to the M non-consensus request initiating nodes, where the node broadcast prepare message includes: the identification information of the second view and the identification information of the fourth consensus request; after receiving the node broadcast prepare message, the second replica node sends a node broadcast message to the M non-consensus request initiating nodes, where the node broadcast message includes: the identification information of the second view and the identification information of the fourth consensus request; the M non-consensus request initiating nodes determine whether the identification information in the node broadcast prepare message is consistent with the identification information in the node broadcast message, and if it is determined that the identification information in the node broadcast prepare message is consistent with the identification information in the node broadcast message, send the fourth consensus response with a digital signature added to the second consensus request initiating node; the second consensus request initiating node receives the fourth consensus responses sent by the M non-consensus request initiating nodes, packs the received fourth consensus responses, and sends the packing result to the M non-consensus request initiating nodes.

[0068] It should be noted that if the second consensus request initiating node does not receive M identical consensus responses, search for the faulty node among the M non-consensus request initiating nodes, replace the faulty node with the corresponding sub-chain of the faulty node, and send a new consensus request to the second representative node. When a faulty node is detected during the main chain consensus process, the consensus request initiating node can ensure the stability and security of the main chain consensus by searching for and replacing the faulty node. This replacement process involves the internal node rotation of the sub-chain, thus ensuring the correctness of the sub-chain representative node.

[0069] In some alternative embodiments of the present application, the blockchain consensus method further includes: after sending the consensus result data to the remaining nodes in the main chain, through their respective representative nodes, sending the consensus result data to other nodes in their respective sub-chains.

[0070] In the above embodiments, after the consensus initiating node on the main chain completes the consensus process, it aggregates the consensus result data of all participating nodes. This data includes, but is not limited to, transaction details, data summaries, digital signatures, etc., as well as all key response and confirmation messages during the consensus process. The main chain node encapsulates the collected consensus result data into a format suitable for transmission, which requires encryption processing of the data and addition of necessary metadata, such as timestamps, view numbers, request numbers, etc., to ensure the integrity and traceability of the data during cross-chain transmission. The main chain node sends the encapsulated consensus result data to all nodes participating in the consensus through the communication mechanism on the main chain. These nodes include not only the main chain nodes themselves, but also all replica nodes and representative nodes of all sub-chains.

[0071] After each representative node of the sub-chain receives the consensus result data sent by the main chain node, it will perform a legality check on the data. Once the representative node of the sub-chain verifies the legality of the consensus result data, it will take on the responsibility of data broadcasting and send the consensus result data to all other nodes in the sub-chain. After each node in the sub-chain receives the consensus result data forwarded by the representative node, it will perform a re-verification of the data. If the verification is correct, the node will update its local blockchain ledger to reflect the latest consensus result.

[0072] After the consensus result data is successfully broadcast to all nodes in the sub-chain, the representative node will update its status information, including the update of the view number, the record of the consensus result data, and the possible maintenance of a list of faulty nodes. This update process ensures that the representative node can accurately track the consensus status between the sub-chain and the main chain, preparing for possible subsequent view conversions or error handling. After each sub-chain node receives the consensus result data and verifies it correctly, it will also update its local status, including writing the consensus result data into the local blockchain ledger, updating the view number, and recording relevant consensus information.

[0073] To ensure the security and availability of the data, the consensus result data is not only stored in the local ledgers of all nodes, but may also be backed up on designated nodes. These backup nodes may be specific nodes in the sub-chain or high-reputation nodes on the main chain to prevent data loss or damage. Once the consensus result data is received, verified, and stored by all relevant nodes, each sub-chain node will perform corresponding data confirmation and application according to the consensus result. For example, for transaction data, the node will confirm the validity of the transaction and execute the corresponding fund transfer; for identity authentication data, the node will confirm the legality of the identity and update the permission information.

[0074] As some other alternative embodiments of the present application, the blockchain consensus method further includes: after sending the consensus result data to the remaining nodes in the main chain, if there is a target slave chain newly accessing the blockchain, taking the consensus result data as the consensus message of the target slave chain for in-slave-chain consensus, and performing in-chain and / or inter-chain communication after completing the in-slave-chain consensus.

[0075] In the above embodiments, after the collection and broadcast of the consensus result data complete the main chain consensus, the main chain nodes (i.e., the consensus initiating nodes) summarize the consensus result data and broadcast it to all participating nodes in the main chain, including but not limited to all second replica nodes and the representative nodes of all slave chains. The main chain network continuously detects whether a new target slave chain appears in the blockchain network. The newly accessed target slave chain may carry new trust domains and node functions and needs to be integrated into the existing consensus mechanism.

[0076] Once a newly accessed target slave chain (e.g., the fourth slave chain D) is detected, the nodes on the main chain convert the consensus result data into a consensus message format suitable for the fourth slave chain. Subsequently, the consensus initiating node sends the consensus message to the representative node SC of the fourth slave chain. D 。SC D As the representative node of the fourth slave chain, after receiving the consensus message, it broadcasts the message to all other nodes in the fourth slave chain, including replica nodes and ordinary nodes participating in the consensus. Before broadcasting, SC D needs to verify the source and legality of the consensus message, ensure that the message has not been tampered with, and confirm that the data carried by the message is consistent with the main chain consensus result.

[0077] After the nodes of the fourth slave chain receive the consensus message, they start the local consensus mechanism for verification. All nodes need to vote according to the consensus algorithm of the fourth slave chain to confirm the authenticity of the consensus message. If the nodes of the fourth slave chain reach an agreement during the consensus process and confirm the correctness of the consensus message, SC D will represent the fourth slave chain and broadcast the consensus confirmation of the fourth slave chain to the main chain, indicating that the fourth slave chain has accepted the main chain consensus result and is ready to perform corresponding in-chain and / or inter-chain communication operations. After the consensus result data is confirmed, the nodes of the fourth slave chain will start in-chain communication, such as transaction confirmation, data update, smart contract execution, etc. In-chain communication ensures that all nodes in the fourth slave chain process the consensus result data in the same way as the main chain, thus achieving cross-chain data synchronization and consistency.

[0078] On the basis of completing the in-chain communication, the nodes of the fourth slave chain may also need to perform inter-chain communication with other slave chains to complete cross-chain data sharing or transactions. Inter-chain communication may involve forwarding the consensus result data to the representative nodes of other slave chains, triggering further consensus and data processing processes.

[0079] Further, after completing in-chain and / or inter-chain communication, the nodes of the fourth slave chain will feedback the communication results to the SC D , SC D Then, these results are aggregated and broadcast to the entire blockchain network through the main chain to confirm that the fourth slave chain has completed all communication and processing operations related to the consensus result data.

[0080] As can be seen from the above embodiments, in the present application, the master-slave chain structure has stronger scalability. The addition of any new trust domain has no impact on other slave chain trust domains. It only needs to match the functions of the nodes within the trust domain with those of the slave chain nodes, and add the main chain nodes of this trust domain to the main chain. The newly added trust domain will reach a consensus through the main chain, and the original trust credentials of the main chain will be consensus to the local of the new main chain nodes. Thus, all the data and trust credentials of the previous consensus are obtained.

[0081] In addition, in order to adapt to distributed heterogeneous trust domains of various different systems, the present application constructs a corresponding distributed slave chain model without interfering with the internal organizational structure and node functions of the original trust domain. This measure not only ensures the stability and reliability of the system, but also significantly improves the compatibility and matching degree of the application.

[0082] The present application also provides another blockchain consensus method, where Figure 2 is a schematic diagram of the communication model of a consensus algorithm according to an embodiment of the present application, Figure 3 is a schematic diagram of the process of a consensus algorithm according to an embodiment of the present application. The following will explain and illustrate the above blockchain consensus method in conjunction with Figure 2 and Figure 3

[0083] Step 1, initiate the slave chain consensus phase.

[0084] Step 1.1, Request0 phase: The consensus initiating node U A sends a consensus request to the representative point SC A where t is the timestamp and Request is the consensus request identifier.

[0085] Step 1.2, Commit0 phase: SC A judges the correctness of the Request, verifies the request signature, checks the timestamp t, numbers the request message, and forwards the consensus request to N non-consensus request initiating nodes including itself.

[0086] Step 1.3, Reply0 phase: After receiving the request message, SC A and the replica node Ai perform local processing, sign the calculated digest, feedback to U A and perform algorithm conversion judgment. ​​

[0087] If UA receives N response messages with the same results from nodes, it indicates that there are no faulty nodes in the system, the consensus is successful, and it enters the Response0 phase. If the number of received responses is less than N, or there are inconsistent results in the responses, it indicates that there are faulty nodes in the system, and it jumps to the Panic0 phase to continue the consensus process.

[0088] Step 1.4, Response0 phase: U A Pack all the signed responses and send them to N non-consensus initiating nodes. After receiving the messages, the nodes verify and save the consensus results. Thus, SC A The consensus phase is completed and the consensus is successful.

[0089] Step 1.5, Panic0 phase: Enter the node timeout waiting mechanism, U A Make a failure judgment on the request and attempt to resend the consensus request.

[0090] Step 1.6, Abort1 phase: If the repeated request still fails, the node performs a rollback operation, switches the consensus algorithm, and enters the PBFT consensus algorithm.

[0091] Step 1.7, Request1 phase: U A Send a new consensus request to SC A

[0092] Step 1.8, Pre-prepare1 phase: SC A Number the request message as n and broadcast a pre-prepare message to N non-consensus initiating nodes The pre-prepare message, as a means of proof, clarifies that the request has been numbered n in view v, which is convenient for searching when the view is switched due to the change of the representative node.

[0093] Step 1.9, Prepare1 phase: Ai broadcasts a message to non-consensus initiating nodes After receiving the broadcast message, the node checks the correctness of the signature and view number v.

[0094] Since N ≥ 3f + 1, excluding at most f unresponsive nodes and 1 representative node, the remaining 2f nodes receive at least 2f messages in step 9, and the node receives 1 message in step 8. Therefore, a total of at least 2f + 1 messages are saved locally in the two phases.

[0095] Step 1.10, Commit1 phase: The non-consensus initiating nodes broadcast confirmation messages SigSCAorAi(Commit, v, n, h(m)) to each other. After verifying the correctness of the signature and view number, the nodes write the messages to the local. If the node receives Q messages, the consensus is reached. ​

[0096] Because Q≥f+(f+1), the number of error nodes is less than f, that is, the number of non-error nodes is at least f+1, so the correct consensus can be achieved.

[0097] Step 1.11, Reply 1 phase: N non-consensus initiating nodes send the signed response to the consensus initiating node UA.

[0098] Step 1.12, Response 1 stage: U A All received responses are packaged and sent to N non-consensus initiating nodes, and the HBFT process is now completed.

[0099] In the above steps, representative nodes are selected in a fair and just manner. These nodes initiate consensus requests and share data and transaction information. All nodes participating in the consensus need to verify the received data and vote. If more than the preset threshold of nodes accept, consensus is reached, and a new block is created to record the results, which are finally broadcast to the entire network to ensure data consistency. This process improves the efficiency and security of large-scale blockchain networks.

[0100] Step 2: Main chain consensus phase.

[0101] Step 2.1: Consensus initiated from chain representative node SC A Send the consensus result to the corresponding main chain node M A back.

[0102] Step 2.2, by M A As the main chain consensus initiator node, it sends the message to the main chain nodes corresponding to the other slave chain representative nodes within the main chain for consensus. The process is roughly the same as the slave chain consensus.

[0103] The difference from step 1 is that when any node error is found in the main chain consensus, the system will specify the corresponding slave chain to enter the representative node timeout rotation mechanism and the delay step-by-step increase mechanism, and replace the correct representative node until the HBFT consensus is completed. This mechanism ensures the correctness of the representative nodes of other slave chains, and thus ensures the correctness of the consensus content transmitted subsequently.

[0104] In the above steps, when any node error is found in the main chain consensus during the main chain consensus phase, the system will specify the corresponding slave chain to enter the representative node timeout rotation mechanism and the delay step-by-step increase mechanism, and replace the correct representative node until the HBFT consensus is completed. This ensures the correctness of the representative nodes of other slave chains, and then ensures the correctness of the consensus content transmitted subsequently.

[0105] Step 3, the goal is to reach the chain consensus stage.

[0106] Step 3.1, taking the consensus target from chain B as an example, M BOnce the consensus data has been obtained during the main-chain consensus process, it can be used as the consensus initiating node to issue a correct consensus request.

[0107] Step 3.2, complete the in-chain HBFT consensus with the assistance of the corresponding sub-chain representative node SC B to complete the entire consensus process, and the data is correctly shared through consensus.

[0108] This stage has strong scalability. After the main chain reaches a consensus, any sub-chain can join the network, query the existing consensus data on the main chain as the target sub-chain consensus message, and perform in-sub-chain consensus to enable cross-domain communication.

[0109] In the above steps, the target sub-chain consensus stage has strong scalability. After the main chain reaches a consensus, any sub-chain can join the network, query the existing consensus data on the main chain as the target sub-chain consensus message, and perform in-sub-chain consensus to enable cross-domain communication.

[0110] In summary, in this embodiment, the entire blockchain is split into a main chain and multiple sub-chains, and the nodes within the trust domains of different systems are functionally matched among these chains, making full use of the decentralized characteristics of the blockchain, thereby effectively reducing the centralized risk. By adopting a local consensus mechanism, data consensus sharing can be completed only by performing authentication on the relevant sub-chains and the main chain, significantly reducing the number of consensus participating nodes, and thus improving the authentication efficiency.

[0111] When the main chain and sub-chains perform partial data transmission, a method different from traditional centralized trust publishing and peer-to-peer data transmission is adopted. A phased and hierarchical consensus mechanism is adopted, which can handle the dynamic changes of representative nodes and perform data sharing and trust transfer. This mechanism not only simplifies the authentication interaction process but also makes full use of the immutable and traceable characteristics of the blockchain. Combining the method of storing the original data off-chain and the data hash value on-chain, all nodes participating in the consensus jointly record the data and operations. Once a problem occurs, it can be effectively traced, thereby realizing the effective protection of trust credentials and improving the credibility of the credentials.

[0112] Figure 4 is a structural diagram of a blockchain consensus device according to an embodiment of the present application. As Figure 4 shown, the device includes:

[0113] The first processing module 41 is used to instruct the first consensus request initiating node in the first slave chain of the blockchain to send a first consensus request to the first representative node in the first slave chain. The blockchain includes a main chain and multiple slave chains. The main chain includes multiple different nodes associated with different slave chains. The first representative node is used to send the first consensus request to N non-consensus request initiating nodes in the first slave chain. The N non-consensus request initiating nodes include: the first representative node and the first replica nodes other than the first representative node. N is a positive integer greater than 1.

[0114] The judgment module 42 is used to instruct the first consensus request initiating node to receive the first consensus response sent by the non-consensus request initiating node and judge the quantity and data consistency of the first consensus response.

[0115] The second processing module 43 is used to instruct that, when the judgment result is that the first consensus request initiating node receives N identical first consensus responses, the first consensus request initiating node sends the consensus result data in the first consensus response to the first node in the main chain of the blockchain corresponding to the first slave chain. The first node is used to act as the second consensus request initiating node and send the consensus result data to the remaining nodes in the main chain.

[0116] Optionally, the first processing module 41 is further used to perform the following steps: The first consensus request initiating node sends a first consensus request to the first representative node. The first consensus request includes: a first consensus request identifier, a first request signature, and a first timestamp. The first representative node is used to judge whether the first consensus request identifier is correct, and when judging that the first consensus request identifier is correct, verify the first request signature and the first timestamp; when the verification of the first request signature and the first timestamp passes, send the first consensus request to N non-consensus request initiating nodes. Each node in the N non-consensus request initiating nodes is used to perform local calculation after receiving the first consensus request, digitally sign the calculated digest data, add the signed data to the first consensus response, and send the first consensus response to the first consensus request initiating node.

[0117] Optionally, the blockchain consensus device is further configured to perform the following steps: in the case where the first consensus request initiating node does not receive N identical first consensus responses, the first consensus request initiating node resends the first consensus request to the first representative node; in the case where the number of times of resending the first consensus request to the first representative node reaches a preset number and the first consensus request initiating node still does not receive N identical first consensus responses, the first consensus request initiating node sends a second consensus request different from the first consensus request to the first representative node; the first representative node determines the identification information of the second consensus request in the first view and sends a node broadcast preparation message to N non-consensus request initiating nodes, where the node broadcast preparation message includes: the identification information of the first view and the identification information of the second consensus request; after receiving the node broadcast preparation message, the first replica node sends a node broadcast message to N non-consensus request initiating nodes, where the node broadcast message includes: the identification information of the first view and the identification information of the second consensus request; the N non-consensus request initiating nodes determine whether the identification information in the node broadcast preparation message is consistent with the identification information in the node broadcast message, and in the case where it is determined that the identification information in the node broadcast preparation message is consistent with the identification information in the node broadcast message, send the second consensus response with a digital signature added thereto to the first consensus request initiating node; the first consensus request initiating node receives the second consensus responses sent by the N non-consensus request initiating nodes, packs the received second consensus responses, and sends the packing result to the N non-consensus request initiating nodes.

[0118] Optionally, the blockchain consensus device is further configured to perform the following steps: after determining that the identification information in the node broadcast preparation message is consistent with the identification information in the node broadcast message, determine whether the number of messages received by each of the N non-consensus request initiating nodes is greater than or equal to 2f + 1, where f is the number of faulty nodes in the first sub-chain; in the case where the number of messages received by each of the N non-consensus request initiating nodes is greater than or equal to 2f + 1, send the second consensus response with a digital signature added thereto to the first consensus request initiating node.

[0119] Optionally, the blockchain consensus device is further configured to perform the following steps: The second consensus request initiating node sends a third consensus request to the second representative node in the main chain, where the second representative node is used to send the third consensus request to M non-consensus request initiating nodes in the main chain. The M non-consensus request initiating nodes include: the second representative node and the second replica node, and M is a positive integer greater than 1; if the second consensus request initiating node does not receive M identical third consensus responses, search for the faulty node among the M non-consensus request initiating nodes, replace the faulty node with its corresponding sub-chain, and send a fourth consensus request to the second representative node; the second representative node determines the identification information of the fourth consensus request in the second view and sends a node broadcast preparation message to the M non-consensus request initiating nodes, where the node broadcast preparation message includes: the identification information of the second view and the identification information of the fourth consensus request; after receiving the node broadcast preparation message, the second replica node sends a node broadcast message to the M non-consensus request initiating nodes, where the node broadcast message includes: the identification information of the second view and the identification information of the fourth consensus request; the M non-consensus request initiating nodes determine whether the identification information in the node broadcast preparation message is consistent with the identification information in the node broadcast message, and if it is determined that the identification information in the node broadcast preparation message is consistent with the identification information in the node broadcast message, send the fourth consensus response with a digital signature added to the second consensus request initiating node; the second consensus request initiating node receives the fourth consensus responses sent by the M non-consensus request initiating nodes, packs the received fourth consensus responses, and sends the packing result to the M non-consensus request initiating nodes.

[0120] Optionally, the blockchain consensus device is further configured to perform the following steps: After sending the consensus result data to the remaining nodes in the main chain, through their respective representative nodes, send the consensus result data to other nodes in their respective sub-chains.

[0121] Optionally, the blockchain consensus device is further configured to perform the following steps: After sending the consensus result data to the remaining nodes in the main chain, if there is a target sub-chain newly connected to the blockchain, perform in-sub-chain consensus on the consensus result data as the consensus message of the target sub-chain, and perform intra-chain and / or inter-chain communication after completing the in-sub-chain consensus.

[0122] It should be noted that the above Figure 4 each module can be a program module (for example, a set of program instructions that implement a specific function), or a hardware module. For the latter, it can be presented in the following forms, but not limited to: The manifestation form of each of the above modules is a processor, or the functions of each of the above modules are implemented by a processor.

[0123] It should be noted that Figure 4For the preferred implementation of the illustrated embodiment, reference may be made to Figure 1 the relevant description of the illustrated embodiment, which will not be elaborated herein.

[0124] Figure 5 The hardware block diagram of a computer terminal for implementing a blockchain consensus method is shown. As Figure 5 shown, the computer terminal 50 may include one or more processors 502 (illustrated as 502a, 502b, ……, 502n in the figure) (the processor 502 may include, but is not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 504 for storing data, and a transmission module 506 for communication functions. In addition, it may further include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the BUS bus), a network interface, a power supply, and / or a camera. Those of ordinary skill in the art can understand that Figure 5 the structure shown is only schematic and does not limit the structure of the above-mentioned electronic device. For example, the computer terminal 50 may further include more or fewer components than Figure 5 shown therein, or have a different configuration from Figure 5 shown.

[0125] It should be noted that the above one or more processors 502 and / or other data processing circuits are generally referred to as "data processing circuits" herein. The data processing circuit may be embodied in whole or in part as software, hardware, firmware, or any combination thereof. In addition, the data processing circuit may be a single independent processing module, or be incorporated in whole or in part into any one of the other elements in the computer terminal 50. As involved in the embodiments of the present application, the data processing circuit is a processor control (such as the selection of a variable resistance terminal path connected to an interface).

[0126] The memory 504 may be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the blockchain consensus method in the embodiments of the present application. The processor 502 executes various functional applications and data processing by running the software programs and modules stored in the memory 504, that is, implements the above-mentioned blockchain consensus method. The memory 504 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memories, or other non-volatile solid-state memories. In some instances, the memory 504 may further include a memory remotely disposed relative to the processor 502, and these remote memories may be connected to the computer terminal 50 through a network. Examples of the above network include, but are not limited to, the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.

[0127] The transmission module 506 is used to receive or send data via a network. Specific examples of the above-mentioned network may include a wireless network provided by the communication provider of the computer terminal 50. In one example, the transmission module 506 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission module 506 can be a Radio Frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0128] The display can be, for example, a touch-screen liquid crystal display (LCD), which enables the user to interact with the user interface of the computer terminal 50.

[0129] It should be noted here that in some alternative embodiments, the above Figure 5 shown computer terminal may include hardware elements (including circuits), software elements (including computer code stored on a computer-readable medium), or a combination of both hardware elements and software elements. It should be pointed out that Figure 5 is only an example of a specific specific instance and is intended to show the types of components that may exist in the above computer terminal.

[0130] It should be noted that Figure 5 the shown computer terminal is used to execute Figure 1 the shown blockchain consensus method. Therefore, the relevant explanations in the execution method of the above commands also apply to this electronic device, which will not be elaborated here.

[0131] The embodiment of the present application also provides a non-volatile storage medium. The non-volatile storage medium includes a stored program, wherein when the program runs, it controls the device where the storage medium is located to execute the above blockchain consensus method.

[0132] A program for a non-volatile storage medium to perform the following functions: A first consensus request initiating node in a first slave chain of a blockchain sends a first consensus request to a first representative node in the first slave chain. Among them, the blockchain includes a main chain and multiple slave chains, and the main chain includes multiple different nodes associated with different slave chains. The first representative node is used to send the first consensus request to N non-consensus request initiating nodes in the first slave chain. The N non-consensus request initiating nodes include: the first representative node and the first replica nodes other than the first representative node. N is a positive integer greater than 1. The first consensus request initiating node receives the first consensus response sent by the non-consensus request initiating nodes and judges the quantity and data consistency of the first consensus response. When the judgment result is that the first consensus request initiating node receives N identical first consensus responses, the first consensus request initiating node sends the consensus result data in the first consensus response to a first node in the main chain of the blockchain corresponding to the first slave chain. Among them, the first node is used as a second consensus request initiating node to send the consensus result data to the remaining nodes in the main chain.

[0133] An embodiment of the present application also provides an electronic device, including: a memory and a processor. The processor is used to run a program stored in the memory. Among them, when the program runs, it executes the above blockchain consensus method.

[0134] The processor is used to run a program that performs the following functions: A first consensus request initiating node in a first slave chain of a blockchain sends a first consensus request to a first representative node in the first slave chain. Among them, the blockchain includes a main chain and multiple slave chains, and the main chain includes multiple different nodes associated with different slave chains. The first representative node is used to send the first consensus request to N non-consensus request initiating nodes in the first slave chain. The N non-consensus request initiating nodes include: the first representative node and the first replica nodes other than the first representative node. N is a positive integer greater than 1. The first consensus request initiating node receives the first consensus response sent by the non-consensus request initiating nodes and judges the quantity and data consistency of the first consensus response. When the judgment result is that the first consensus request initiating node receives N identical first consensus responses, the first consensus request initiating node sends the consensus result data in the first consensus response to a first node in the main chain of the blockchain corresponding to the first slave chain. Among them, the first node is used as a second consensus request initiating node to send the consensus result data to the remaining nodes in the main chain.

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

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

[0137] In the above embodiments of the present application, the collected information is information and data authorized by the user or fully authorized by all parties. Moreover, for the processing of relevant data such as collection, storage, use, processing, transmission, provision, disclosure, and application, all comply with relevant laws, regulations, and standards, necessary protection measures are taken, it does not violate public order and good customs, and corresponding operation entrances are provided for users to choose to authorize or reject.

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

[0139] The units described as separate components may or may not be physically separated. The components displayed as units may or may not be physical units, that is, they can be located in one place or distributed to multiple units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0140] In addition, in each embodiment of the present application, the functional units can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

[0141] If the above-mentioned integrated units are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present application, in essence, or the part that contributes to the relevant technology, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in each embodiment of the present application. The foregoing storage medium includes: USB flash drives, read-only memories (ROM, Read-Only Memory), random access memories (RAM, Random Access Memory), mobile hard disks, magnetic disks, or optical discs and other various media that can store program codes.

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

Claims

1. A blockchain consensus method, characterized in that: include: The first consensus request initiating node in the first slave chain of the blockchain sends a first consensus request to the first representative node in the first slave chain, wherein the blockchain includes a main chain and multiple slave chains, the main chain includes multiple different nodes associated with different slave chains, and the first representative node is used to send the first consensus request to N non-consensus request initiating nodes in the first slave chain, the N non-consensus request initiating nodes include: the first representative node and a first replica node other than the first representative node, and N is a positive integer greater than 1; The first consensus request initiating node receives the first consensus response sent by the non-consensus request initiating node, and determines the quantity and data consistency of the first consensus response; When the judgment result is that the first consensus request initiating node receives N identical first consensus responses, the first consensus request initiating node sends the consensus result data in the first consensus response to the first node in the main chain of the blockchain corresponding to the first slave chain, wherein the first node is used as the second consensus request initiating node to send the consensus result data to the remaining nodes in the main chain.

2. The method according to claim 1, characterized in that: The first consensus request initiating node in the first slave chain of the blockchain sends a first consensus request to the first representative node in the first slave chain, including: The first consensus request initiating node sends a first consensus request to the first representative node, wherein the first consensus request includes: a first consensus request identifier, a first request signature, and a first timestamp, and the first representative node is used to determine whether the first consensus request identifier is correct, and if the first consensus request identifier is determined to be correct, verify the first request signature and the first timestamp; After verifying the first request signature and the first timestamp, the first consensus request is sent to the N non-consensus request initiating nodes, wherein each of the N non-consensus request initiating nodes is used to perform local calculations after receiving the first consensus request, digitally sign the calculated summary data, add the signed data to the first consensus response, and send the first consensus response to the first consensus request initiating node.

3. The method according to claim 1, characterized in that The method further comprises: In the case that the first consensus request initiating node has not received N identical first consensus responses, the first consensus request initiating node re-sends the first consensus request to the first representative node. When the number of times the first consensus request is re-sent to the first representative node reaches a preset number and the first consensus request initiating node still has not received N identical first consensus responses, the first consensus request initiating node sends a second consensus request different from the first consensus request to the first representative node; The first representative node determines the identification information of the second consensus request in the first view, and sends a node broadcast preparation message to the N non-consensus request initiating nodes, wherein the node broadcast preparation message includes: the identification information of the first view and the identification information of the second consensus request; After receiving the node broadcast preparation message, the first replica node sends a node broadcast message to the N non-consensus request initiating nodes, wherein the node broadcast message includes: identification information of the first view and identification information of the second consensus request; The N non-consensus request initiating nodes determine whether the identification information in the node broadcast preparation message is consistent with the identification information in the node broadcast message, and if it is determined that the identification information in the node broadcast preparation message is consistent with the identification information in the node broadcast message, send a second consensus response with a digital signature to the first consensus request initiating node; The first consensus request initiating node receives the second consensus responses sent by the N non-consensus request initiating nodes, packages the received second consensus responses, and sends the packaged results to the N non-consensus request initiating nodes.

4. The method according to claim 3, characterized in that The method further comprises: After determining that the identification information in the node broadcast preparation message is consistent with the identification information in the node broadcast message, determining whether the number of messages received by each of the N non-consensus request initiating nodes is greater than or equal to 2f+1, where f is the number of erroneous nodes in the first slave chain; When the number of messages received by each of the N non-consensus request initiating nodes is greater than or equal to 2f+1, a second consensus response with a digital signature is sent to the first consensus request initiating node.

5. The method according to claim 1, characterized in that The method further comprises: The second consensus request initiating node sends a third consensus request to the second representative node in the main chain, wherein the second representative node is used to send the third consensus request to M non-consensus request initiating nodes in the main chain, and the M non-consensus request initiating nodes include: the second representative node and the second replica node, and M is a positive integer greater than 1; If the second consensus request initiating node does not receive M identical third consensus responses, find the wrong node among the M non-consensus request initiating nodes, replace the wrong node with the slave chain corresponding to the wrong node, and send a fourth consensus request to the second representative node; The second representative node determines the identification information of the fourth consensus request in the second view, and sends a node broadcast preparation message to the M non-consensus request initiating nodes, wherein the node broadcast preparation message includes: the identification information of the second view and the identification information of the fourth consensus request; After receiving the node broadcast preparation message, the second replica node sends a node broadcast message to the M non-consensus request initiating nodes, wherein the node broadcast message includes: identification information of the second view and identification information of the fourth consensus request; The M non-consensus request initiating nodes determine whether the identification information in the node broadcast preparation message is consistent with the identification information in the node broadcast message, and if it is determined that the identification information in the node broadcast preparation message is consistent with the identification information in the node broadcast message, send a fourth consensus response with a digital signature added to the second consensus request initiating node; The second consensus request initiating node receives the fourth consensus responses sent by the M non-consensus request initiating nodes, packages the received fourth consensus responses, and sends the packaged results to the M non-consensus request initiating nodes.

6. The method according to claim 1, characterized in that The method further comprises: After sending the consensus result data to the remaining nodes in the main chain, the consensus result data is sent to the other nodes in the corresponding slave chains through the corresponding representative nodes.

7. The method according to claim 1 or 6, characterized in that: The method further comprises: After sending the consensus result data to the remaining nodes in the main chain, if there is a target slave chain newly connected to the blockchain, the consensus result data will be used as the consensus message of the target slave chain for intra-slave chain consensus, and intra-chain and / or inter-chain communication will be performed after completing the intra-slave chain consensus.

8. A blockchain consensus device, characterized in that: include: A first processing module is used to instruct a first consensus request initiating node in a first slave chain of a blockchain to send a first consensus request to a first representative node in the first slave chain, wherein the blockchain includes a main chain and multiple slave chains, the main chain includes multiple different nodes associated with different slave chains, and the first representative node is used to send the first consensus request to N non-consensus request initiating nodes in the first slave chain, the N non-consensus request initiating nodes include: the first representative node and a first replica node other than the first representative node, and N is a positive integer greater than 1; a judgment module, configured to instruct the first consensus request initiating node to receive a first consensus response sent by a non-consensus request initiating node, and to perform quantity and data consistency judgment on the first consensus response; The second processing module is used to instruct that when the judgment result is that the first consensus request initiating node receives N identical first consensus responses, the first consensus request initiating node sends the consensus result data in the first consensus response to the first node in the main chain of the blockchain corresponding to the first slave chain, wherein the first node is used to send the consensus result data to the remaining nodes in the main chain as the second consensus request initiating node.

9. A non-volatile storage medium, characterized in that: The non-volatile storage medium includes a stored program, wherein when the program is running, the device where the non-volatile storage medium is located is controlled to execute the blockchain consensus method described in any one of claims 1 to 7.

10. An electronic device, characterized in that: include: A memory and a processor, wherein the processor is used to run a program stored in the memory, wherein the program executes the blockchain consensus method described in any one of claims 1 to 7 when running.

11. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the blockchain consensus method described in any one of claims 1 to 7 is implemented.

Images