Method, device and equipment for alliance chain consensus process and storage medium

Abstract

The invention relates to the technical field of block chain consensus algorithms, and discloses a method, a device, equipment and a storage medium for an alliance chain consensus process, the method comprises the following steps: dividing nodes in an alliance chain into a plurality of clusters, the number of the clusters in the alliance chain is at least four, the number of the nodes in the alliance chain is at least twelve, and the nodes comprise at least four clusters and at least twelve nodes; at least one of a fault node and a disable node is connected with a common node; nodes in each cluster are subjected to inter-node consensus by adopting a distributed consistency algorithm, and the nodes in the cluster comprise following nodes, candidate nodes and leading nodes; and a practical Byzantine fault-tolerant algorithm is adopted among leader nodes of the clusters to carry out consensus among the clusters. According to the method, the higher time complexity and space complexity caused by the PBFT algorithm adopted by the whole network are reduced, the consensus efficiency and throughput are improved, and an alliance chain scene of large-scale nodes can be supported.

Description

Technical Field

[0001] The present invention relates to the technical field of blockchain consensus algorithms, and in particular to methods, devices, equipment and storage media for alliance chain consensus processes. Background Art

[0002] With the rapid development of science and technology, people are gradually entering the digital age. Payment transactions in daily life can be transferred through bank cards or third-party electronic payment platforms such as WeChat, Alipay, and Taobao. The dominance of paper money is gradually replaced by electronic money. However, electronic content itself has zero cost to copy, and the value transfer cannot be completed by directly sending electronic content. This is where the "double-spending problem" comes from.

[0003] Electronic money is based on a safe and reliable third-party bookkeeping institution, which completes transactions by mortgaging credit. However, third-party bookkeeping institutions are also unreliable. For example, the system of third-party bookkeeping institutions may fail, or anonymous parties in the network may directly trade, which has given rise to a decentralized digital currency system, namely the blockchain technology of a distributed system. Blockchain includes private chains, consortium chains and public chains.

[0004] In the consensus process of the alliance chain, the right to record accounts is only participated by the alliance members, the read and write permissions of the blocks are stipulated by the alliance rules, the entire network is jointly maintained by consensus nodes and non-consensus nodes, and alliance members generally access through the gateway nodes of member institutions. The representative consensus algorithms of the alliance chain are Byzantine Fault Tolerance (BET), Practical Byzantine Fault Tolerance (PBFT) and its variants.

[0005] Since PBFT includes malicious nodes, its preparation and submission phases adopt a broadcasting method. Only when each node has received most of the correct messages in the network can it generate the next message and enter the next phase. This also increases the communication volume and communication time of the algorithm. Therefore, the influence of the number of nodes on the consensus efficiency is absolutely dominant. When the network scale is large, the consensus efficiency of PBFT will be sacrificed. Summary of the invention

[0006] In view of this, the present invention provides a method, apparatus, device and storage medium for a consortium chain consensus process to solve the problem of low PBFT consensus efficiency when the network scale is large.

[0007] In a first aspect, the present invention provides a method for a consortium chain consensus process, the method comprising: dividing the nodes in the consortium chain into multiple clusters, the number of clusters in the consortium chain is at least four, the number of nodes in the consortium chain is at least twelve, the nodes include at least one of a faulty node and a malicious node and an ordinary node; the nodes in each cluster use a distributed consistency algorithm to perform inter-node consensus, the nodes in the cluster include follower nodes, candidate nodes and leader nodes; the leader nodes of each cluster use a practical Byzantine fault-tolerant algorithm to perform inter-cluster consensus.

[0008] In an optional embodiment, each node in the cluster uses a distributed consistency algorithm to achieve inter-node consensus, including: the initial state of each node in the target cluster is a follower node, and the target follower node that receives the message starts a timer. If the duration recorded by the timer exceeds a preset duration, the state of the target follower node is switched to a candidate node; based on the candidate node, a voting request is sent to each node in the target cluster. If the candidate node obtains a preset number of votes, the state of the candidate node is switched to a leader node; if the leader node obtains a transaction request submitted by a client node, a log entry is created based on the transaction request, and the log entry is broadcast to the follower nodes in the target cluster. Each follower node in the target cluster replies to the leader node based on its own log record. If the leader node obtains a preset number of replies, the log entry is added to the log through the leader node, and the inter-node consensus is completed.

[0009] In an optional implementation, a voting request is sent to each node in the target cluster based on the candidate node, including: if the term of the candidate node contained in the voting request is greater than the term in the log of the target follower node in the target cluster, the target follower node votes for the candidate node, and the number of votes for the candidate node is increased by one.

[0010] In an optional embodiment, sending a voting request to each node in the target cluster based on the candidate node also includes: when the term of the candidate node contained in the voting request is equal to the term in the log of the target follower node, if the first value of the log index of the candidate node contained in the voting request is greater than the second value of the log index of the target follower node, the target follower node votes for the candidate node, and the number of votes for the candidate node is increased by one.

[0011] In an optional implementation, the aforementioned method for alliance chain consensus further includes: if the leader node is selected in the target cluster, the leader node sends periodic heartbeat information to other nodes in the target cluster.

[0012] In an optional embodiment, the leader nodes of each cluster use a practical Byzantine fault-tolerant algorithm to achieve inter-cluster consensus, including: based on the leader node sending a prepare message to other leader nodes; the target leader node enters the submission phase when the number of prepare messages obtained reaches a preset number, and the target leader node sends a submission message to other leader nodes and the client node; if the number of submission messages obtained by the client node reaches a preset number, the inter-cluster consensus is completed.

[0013] In a second aspect, the present invention provides a device for a consortium chain consensus process, the device comprising: a building module, used to divide the nodes in the consortium chain into multiple clusters, the number of clusters in the consortium chain is at least four, the number of nodes in the consortium chain is at least twelve, and the nodes include at least one of a faulty node and a malicious node and an ordinary node; a first consensus module, used for the nodes in each cluster to use a distributed consistency algorithm to perform inter-node consensus, the nodes in the cluster include follower nodes, candidate nodes and leader nodes; a second consensus module, used for the leader nodes of each cluster to use a practical Byzantine fault-tolerant algorithm to perform inter-cluster consensus.

[0014] In a third aspect, the present invention provides a computer device, comprising: a memory and a processor, the memory and the processor are communicatively connected to each other, computer instructions are stored in the memory, and the processor executes the method for the alliance chain consensus process of the above-mentioned first aspect or any corresponding embodiment thereof by executing the computer instructions.

[0015] In a fourth aspect, the present invention provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute the method for a consortium chain consensus process of the above-mentioned first aspect or any corresponding embodiment thereof.

[0016] In a fifth aspect, the present invention provides a computer program product, comprising computer instructions, which are used to enable a computer to execute the method for a consortium chain consensus process of the above-mentioned first aspect or any corresponding embodiment thereof.

[0017] The network is divided into clusters that meet the requirements of the number of nodes in a single cluster and the number of clusters. The distributed consensus algorithm (Raft) is used within the cluster to reach a consensus within the cluster, and the PBFT algorithm is implemented between clusters to reach a consensus between clusters, thereby reaching a consensus on the entire network. The use of the PBFT algorithm between clusters avoids the strong master nature of the Raft algorithm, and allows malicious nodes and faulty nodes, so that most nodes can participate in the consensus process. The use of the Raft algorithm between clusters reduces the high time complexity and space complexity brought about by the use of the PBFT algorithm in the entire network, improves consensus efficiency and throughput, and can support alliance chain scenarios with large-scale nodes. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the related technologies, the drawings required for use in the specific embodiments or the related technical descriptions will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0019] Figure 1 A schematic diagram of a process for a consortium chain consensus process provided by an embodiment of the present invention is shown;

[0020] Figure 2 A flowchart of another method for a consortium chain consensus process provided by an embodiment of the present invention is shown;

[0021] Figure 3 A schematic diagram of a process for consensus among nodes in a cluster provided by an embodiment of the present invention is shown;

[0022] Figure 4 A flowchart of another method for a consortium chain consensus process provided by an embodiment of the present invention is shown;

[0023] Figure 5 A schematic flow chart of another method for alliance chain consensus provided by an embodiment of the present invention is shown;

[0024] Figure 6 It shows a schematic diagram of the process of executing the Raft algorithm in the cluster;

[0025] Figure 7 A schematic diagram of the process of executing the PBFT algorithm between clusters is shown;

[0026] Figure 8 A schematic diagram of the structure of a device for a consortium chain consensus process provided by an embodiment of the present invention is shown;

[0027] Fig. 9 A schematic diagram of the hardware structure of a computer device provided in an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0028] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0029] Byzantine fault tolerance is a fault-tolerant technology in the field of distributed computing. Byzantine fault tolerance originates from the Byzantine Generals Problem. The blockchain consensus algorithm is essentially a distributed consistency algorithm, which refers to how nodes in the system reach a consensus on a proposal, including success or failure. With the development of blockchain technology, the application scenarios of consensus algorithms are gradually improved. Blockchains in related technologies include private chains, consortium chains, and public chains. In practical applications, the type of blockchain can be selected based on the trust environment, such as read and write permissions, and the required degree of decentralization.

[0030] A consortium chain is a blockchain that requires registration permission, also known as a permissioned chain. It can be considered a network structure between a public chain and a private chain. The consensus process of the consortium chain has a partially decentralized feature, and its main application scenario is transactions between institutions, such as banking systems for payment or settlement.

[0031] The PBFT algorithm is generally used in consortium chain scenarios. It is a BFT solution when there are fewer consensus nodes. Since PBFT includes malicious nodes, its preparation and submission stages are broadcast. Only when each node receives most of the correct messages in the network can it generate the next message and enter the next stage. This also increases the communication volume and communication time of the algorithm. Therefore, the impact of the number of nodes on consensus efficiency is absolutely dominant. When the network scale is large, the consensus efficiency of PBFT will be sacrificed.

[0032] According to an embodiment of the present invention, a method embodiment for a consortium chain consensus process 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 a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in an order different from that shown here.

[0033] In this embodiment, a method for the alliance chain consensus process is provided, which can be used in terminals such as mobile phones, tablet computers or servers. Figure 1 A flow chart of a method for a consortium chain consensus process provided by an embodiment of the present invention is shown. Figure 1 As shown, the process includes the following steps:

[0034] Step S101, divide the nodes in the alliance chain into multiple clusters, the number of clusters in the alliance chain is at least four, the number of nodes in the alliance chain is at least twelve, and the nodes include at least one of a faulty node and a malicious node and an ordinary node.

[0035] In this step, the n nodes in the alliance chain can be divided into m clusters. Assuming that there are f leading nodes in the m clusters that are malicious nodes or faulty nodes, based on the PBFT algorithm content, the necessary condition for reaching consensus among the m clusters is m≥3f+1. Since f≥1, m≥4, so the number of clusters in the alliance chain is at least four.

[0036] Assume that there are f faulty or malicious nodes in each cluster ′ Based on the Raft algorithm, the necessary conditions for reaching consensus within the cluster are: And ′ ≥1, so That is, n≥3m, which means that the number of nodes in the alliance chain is at least 12;

[0037] Step S102: Each node in the cluster uses a distributed consistency algorithm to reach consensus among nodes. The nodes in the cluster include follower nodes, candidate nodes, and leader nodes.

[0038] In this step, the follower node is the initial state of the node, responsible for responding to the leader node's request. The candidate node is a follower node that becomes a candidate node when there is no leader node, and initiates an election. The leader node is elected and is responsible for decision-making and log replication within the cluster.

[0039] Distributed consensus algorithms can use Raft to achieve consensus among nodes. Distributed consensus algorithms can elect a leader node through voting. The leader node is responsible for processing all changes and copying the changes to the follower nodes. Once the leader node commits the change, it notifies the follower nodes to synchronize and ensure that the entire cluster reaches a consensus. This can ensure data consistency and collaborative work among multiple nodes, improving the reliability and availability of the system.

[0040] Step S103: The leader nodes of each cluster use a practical Byzantine fault-tolerant algorithm to reach a consensus among the clusters.

[0041] In this step, the leader node of each cluster is equivalent to a node in the PBFT algorithm. These leader nodes communicate and negotiate through the PBFT algorithm to ensure data consistency and collaborative work among clusters.

[0042] The PBFT algorithm enables the leadership nodes between clusters to reach a consensus on a proposal through a series of message exchanges and voting processes. Even if some leadership nodes fail or act maliciously, the PBFT algorithm can ensure the overall security and reliability of the system. The inter-cluster consensus mechanism that uses the Practical Byzantine Fault Tolerance algorithm can effectively improve the fault tolerance and security of the system, and ensure that multiple clusters can maintain consistency and coordination when working together.

[0043] The method for the alliance chain consensus process provided in this embodiment divides the network into clusters that meet the requirements of the number of nodes in a single cluster and the number of clusters. A distributed consensus algorithm (Raft) is used within the cluster to reach a consensus within the cluster, and a PBFT algorithm is implemented between clusters to reach a consensus between clusters, thereby reaching a consensus on the entire network. The PBFT algorithm is used between clusters to avoid the strong master nature of the Raft algorithm, and malicious nodes and faulty nodes are allowed, so that most nodes can participate in the consensus process. The Raft algorithm is used between clusters to reduce the high time complexity and space complexity brought about by the use of the PBFT algorithm in the entire network, improve the consensus efficiency and throughput, and can support alliance chain scenarios with large-scale nodes.

[0044] In this embodiment, a method for the alliance chain consensus process is provided, which can be used in the above-mentioned terminals, such as mobile phones, tablet computers or servers, etc. Figure 2 A flow chart of another method for a consortium chain consensus process provided by an embodiment of the present invention is shown. Figure 2 As shown, the process includes the following steps:

[0045] Step S201: divide the nodes in the alliance chain into multiple clusters. The number of clusters in the alliance chain is at least four, and the number of nodes in the alliance chain is at least twelve. The nodes include at least one of a faulty node and a malicious node and a normal node. For details, please refer to Figure 1 Step S101 of the illustrated embodiment will not be described in detail here.

[0046] Step S202: Each node in the cluster uses a distributed consistency algorithm to reach consensus among nodes. The nodes in the cluster include follower nodes, candidate nodes, and leader nodes.

[0047] Specifically, the above step S202 includes:

[0048] Step S2021, the initial state of each node in the target cluster is a follower node. The target follower node that receives the message starts a timer. If the duration recorded by the timer exceeds a preset duration, the state of the target follower node is switched to a candidate node.

[0049] In this step, any cluster in the alliance chain can be used as the target cluster. The initial state of each node in the target cluster is a follower node. Each follower node automatically starts the timer. Each time the follower node receives a message, the timer is reset and the timer is restarted. If the follower node receives a message indicating that there is a candidate node or a leader node in the network, the follower node's timer needs to be reset. The preset duration can be selected in the range of [150ms, 300ms]. The state of the follower node whose first timer records a duration exceeding the preset duration is switched to a candidate node, and the term of the candidate node is increased by one.

[0050] Step S2022: Send a voting request to each node in the target cluster based on the candidate node. If the candidate node obtains a preset number of votes, the state of the candidate node is switched to a leader node.

[0051] In this step, the candidate node sends a voting request to the nodes in the target cluster. If the candidate node receives votes from the majority of nodes in the target cluster, the candidate node's status is switched to the leader node. A follower node can only vote for one candidate node in one round of elections. If a follower node believes that the candidate node has the latest log, and the follower node has not voted yet, the follower node can vote for the candidate node. Only the candidate node with the latest log can be elected as the leader node. Therefore, the elected leader node has absolute leadership.

[0052] Step S2023: If the leader node obtains the transaction request submitted by the client node, it creates a log entry based on the transaction request and broadcasts the log entry to the follower nodes in the target cluster. The follower nodes in the target cluster reply to the leader node based on their own log records. If the leader node obtains replies from a preset number of nodes, the log entry is added to the log through the leader node, and consensus between nodes is completed.

[0053] In this step, the client node sends the transaction request to any node of any cluster. If the cluster where the node receiving the transaction request is located has not elected a leader node, the node receiving the transaction request will temporarily store the transaction request and wait for the leader node to appear before forwarding it to the leader node.

[0054] After the leader node obtains the transaction request, it calculates the hash summary based on the transaction request, creates a block, creates a log entry, and broadcasts the log entry to the follower nodes in the target cluster through the Append Entries heartbeat. After the follower nodes in the target cluster receive the Append Entries heartbeat, if their own log records are also the latest, they submit the log entry to the log. If their own log records are not the latest, they return their current log hash value in the log. When the leader node receives the replies submitted by most nodes, it will block the block to the log.

[0055] Step S203: The leader nodes of each cluster use a practical Byzantine fault-tolerant algorithm to reach a consensus among the clusters. Figure 1 Step S103 of the illustrated embodiment will not be described in detail here.

[0056] In this way, through the distributed consistency algorithm, the nodes in the cluster can achieve coordinated and consistent operations, avoiding data inconsistencies caused by node failures or communication problems, thereby improving the reliability of the system. At the same time, it can ensure that the data copies on all nodes remain consistent between multiple nodes, meeting the business requirements for data consistency.

[0057] In some optional implementations, the above step S2022 includes:

[0058] Step a1: If the term of the candidate node included in the voting request is greater than the term in the log of the target follower node in the target cluster, the target follower node votes for the candidate node, and the number of votes for the candidate node increases by one.

[0059] In this step, you can first determine whether the term of the candidate node log included in the voting request is the latest. You can compare whether the term of the candidate node log is larger than the term in the target follower node log. If the term of the candidate node log is larger, the target follower node votes for the candidate node.

[0060] Step a2, when the term of the candidate node contained in the voting request is equal to the term in the log of the target follower node, if the first value of the log index of the candidate node contained in the voting request is greater than the second value of the log index of the target follower node, the target follower node votes for the candidate node, and the number of votes for the candidate node increases by one.

[0061] In this step, if the first value of the log index of the candidate node included in the voting request is less than or equal to the second value of the log index of the target follower node, the target follower node does not vote for the candidate node.

[0062] In this way, each follower node can only vote once in the same round of elections, which can ensure that only the candidate node that obtains the majority of votes can become the leader node, avoiding the emergence of the dual leader problem and ensuring the consistency and stability of the system. By limiting the number of votes and voting conditions for each follower node, unnecessary communication and computing overheads are reduced, and the efficiency of the election is improved.

[0063] In some optional implementations, the aforementioned method for the alliance chain consensus process further includes: if a leader node is selected in the target cluster, the leader node sends periodic heartbeat information to other nodes in the target cluster.

[0064] In this embodiment, the leader node declares its own leader node status and sovereignty through periodic heartbeat information (heart beat), which can prevent the duration recorded by the follower node timer from exceeding the preset duration and avoid initiating the next round of elections.

[0065] In this way, if the leader node stops sending heartbeat information, other follower nodes will not receive heartbeat information within the specified time and will determine that the leader node may have failed, thereby triggering a new election process to ensure the continuous operation of the system; the leader node failure can be discovered and handled in a timely manner, thereby reducing service interruptions and data loss caused by leader node failures, and improving system stability and availability.

[0066] Figure 3 FIG. 1 is a flow chart showing a consensus process among nodes in a cluster provided by an embodiment of the present invention. Figure 3 As shown, after the follower node 31 receives the message, the timer is started. When the duration recorded by the timer is greater than the preset duration, the state of the follower node 31 is switched to the candidate node 32. The candidate node 32 initiates a new round of elections. The candidate node 32 sends voting requests to other nodes. The candidate node 32 receives the majority of votes. The state of the candidate node 32 is switched to the leader node 33. The leader node 33 fails in the election or finds a leader node. The state of the leader node 33 is switched to the follower node 31.

[0067] In this embodiment, a method for the alliance chain consensus process is provided, which can be used in the above-mentioned terminals, such as mobile phones, tablet computers or servers, etc. Figure 4 A flowchart of another method for a consortium chain consensus process provided by an embodiment of the present invention is shown. Figure 4 As shown, the process includes the following steps:

[0068] Step S401: divide the nodes in the alliance chain into multiple clusters. The number of clusters in the alliance chain is at least four, and the number of nodes in the alliance chain is at least twelve. The nodes include at least one of a faulty node and a malicious node and a normal node. For details, please refer to Figure 1 Step S101 of the illustrated embodiment will not be described in detail here.

[0069] Step S402: Each node in the cluster uses a distributed consensus algorithm to reach consensus among nodes. The nodes in the cluster include follower nodes, candidate nodes, and leader nodes. Figure 1 Step S102 of the illustrated embodiment will not be described in detail here.

[0070] Step S403: The leader nodes of each cluster use a practical Byzantine fault-tolerant algorithm to reach a consensus among the clusters.

[0071] Specifically, the above step S403 includes:

[0072] Step S4031, based on the leader node, sending a preparation message to other leader nodes.

[0073] In this step, the leader node of each cluster sends a prepare message to all other leader nodes, so that other clusters can be informed that the cluster is ready to complete the submission phase.

[0074] Step S4032, the target leader node whose number of prepared messages has reached a preset number enters the submission phase, and the target leader node sends a submission message to other leader nodes and client nodes.

[0075] In this step, the preset number can be the number of leader nodes in the alliance chain that are faulty nodes or malicious nodes plus one. The target leader node sends a submission message to other leader nodes and client nodes (client). At the same time, the target leader node sends a submission message to all nodes in the cluster. The purpose is to inform other clusters that a sufficient number of messages ready to be submitted have been received and that the cluster has submitted the client node.

[0076] Step S4033: If the number of submission messages obtained by the client node reaches the preset number, the inter-cluster consensus is completed.

[0077] In this step, the preset number can be the number of faulty or malicious nodes in the alliance chain plus one. After the inter-cluster consensus is completed, the business can be successfully executed, for example, movie tickets can be sold.

[0078] In this way, the use of PBFT between clusters can provide strong consistency, ensuring that all nodes in the cluster maintain a consistent understanding of the data. Through the fault-tolerant mechanism, it can handle situations where nodes behave maliciously or fail, thereby improving the overall stability of the system.

[0079] This embodiment assumes that there are 12 nodes, 4 clusters, 1 malicious node in each cluster, and 1 malicious leader node in all clusters, and a consensus can be reached in the end. Figure 5 FIG. 2 is a flow chart of another method for alliance chain consensus provided by an embodiment of the present invention. Figure 5 As shown, the alliance chain network includes the first cluster 51, the second cluster 52, the third cluster 53 and the fourth cluster 54. The first cluster 51, the second cluster 52, the third cluster 53 and the fourth cluster 54 use the PBFT algorithm to reach a consensus among the clusters. The first cluster 51 uses the Raft algorithm to reach a consensus among the nodes within the cluster. Similarly, the second cluster 52, the third cluster 53 and the fourth cluster 54 also use the Raft algorithm to reach a consensus among the nodes within the cluster. After the consensus among the nodes within the cluster is reached, the consensus among the clusters is reached. After the consensus among the clusters is reached, the reply is sent to the client node 55.

[0080] Figure 6 Figure 1 shows a schematic diagram of the process of executing the Raft algorithm in a cluster. Figure 6 As shown:

[0081] Step S601: Use random numbers to simulate real client transactions. Each transaction includes a serial number that uniquely identifies the transaction and the transaction itself. The transaction itself can be simulated by random numbers.

[0082] Step S602: The client node sends a transaction request to any server node in each cluster. If the server node is not a leader node, the transaction request is forwarded to the leader node. If a leader node has not been selected in the entire network, the server node caches the transaction request until a leader node appears.

[0083] Step S603: leader node election.

[0084] Each server node has a random timer. When the timer times out, the server node status switches from a follower node to a candidate node, the term increases by one, and a voting request is initiated to other nodes. Other nodes will determine whether to vote based on their own status and respond. At the same time, the candidate node will collect votes in the network and count the votes. When the candidate node receives votes from most nodes in the cluster network, the status of the candidate node switches to a leader node.

[0085] Step S604: After the cluster selects a leader node, the leader node will start to send periodic heart beats to declare its own leader node status and sovereignty.

[0086] The purpose is to prevent the timer of the follower node from timing out and initiating the next round of election. Every time the follower node receives a message from the leader node or candidate node, it resets its own random timer. At this time, the follower node forwards the received transaction request to the leader node.

[0087] Step S605: After receiving the transaction request, the leader node can start the consensus process within the cluster. The leader node will initiate an AppendEntries request, which is a special heart beat containing log entries. If the follower node accepts the request, it will prepare to complete the log replication and enter the pre-commit state and reply. If the leader node receives more than a majority of replies, it is ready to submit the block.

[0088] Figure 7 Figure 1 shows a schematic diagram of the process of executing the PBFT algorithm between clusters. Figure 7 As shown,

[0089] Step S701: Each leader node in the alliance chain network enters the preparation phase of the PBFT algorithm and sends preparation messages to each other. The leader nodes in the alliance chain network include: the first leader node 71, the second leader node 72, the third leader node 73 and the fourth leader node 74. The node collects the preparation message (prepare Msg), verifies the legitimacy of the message and stores the legal message in the State. When more than 2f messages are received, the preparation phase 75 is completed and a submission message is created. Among them, there are f leader nodes in the alliance chain network that are malicious nodes or faulty nodes. The preparation message allows each cluster to know that more than 2f clusters are ready to submit messages, and the message can be submitted.

[0090] Step S702: Start submitting messages within the cluster, submit the block and add it to the log. Send commit messages between clusters, nodes collect commit messages, verify the legitimacy of the messages and store the legitimate messages in the State. When more than 2f messages ([Commit-Vote]) are received, the commit stage 76 is completed ([STAGE-DONE]Commit), and the state machine execution status is the submitted request. After that, the node replies to the client node 77 with the reply result 78 of the execution operation.

[0091] In the method for the alliance chain consensus process provided by the embodiment of the present invention, it is assumed that the total number of nodes in the alliance chain is n, which is divided into m clusters, and each cluster has n / m nodes; it is assumed that there are f cluster leaders who are malicious or faulty, then the total number of clusters is m≥3f+1, and f≥1, then m≥4; in the consensus algorithm process between nodes in the cluster, it is assumed that each cluster has f ′ malicious or faulty nodes, then the number of nodes in the cluster is related to n / m≥2f ′ +1, again f ′ ≥1, therefore n / m≥3, that is, n≥3m.

[0092] The maximum communication volume of each cluster is: (n / m-1)×2; the minimum communication volume of each cluster is: n / m-1+(n / m-1) / 2=3 / 2(n / m-1).

[0093] The maximum communication volume between the cluster and the client node is 2×(m-1)+(m-1)(m-1)×2; the minimum communication volume is m-1+(m-1)(2f+1)×2+(m-1)(f+1), and m≥3f+1, that is, (m-1) / 3≥f. When f=f_max, the minimum communication volume required to reach a consensus is the largest, so (m-1) / 3=f, so the minimum communication volume is

[0094] From the above, we can see that the maximum communication volume is (n / m-1)×2+2×(m-1)+(m-1)(m-1)×2, and n / m≥3, so it is Therefore, the maximum space complexity is o(m 2 ).

[0095] The space complexity of the original PBFT algorithm is (n-1)+(n-1)*(n-1)*2=2n 2 -3n+1, that is, o(n 2 ). And n≥3m, the total number of nodes n must be much larger than the number of clusters m. Therefore, the space complexity of the method for alliance chain consensus provided by the embodiment of the present invention is reduced.

[0096] Assuming the unit communication time is t, the total time required to reach consensus is reduced, and the number of fault-tolerant nodes is not much different, so the overall consensus efficiency is improved and the throughput is improved.

[0097] In this embodiment, a device for the alliance chain consensus process is also provided, which is used to implement the above embodiments and preferred implementations, and will not be repeated here. As used below, the term "module" can implement a combination of software and / or hardware for a predetermined function. Although the device described in the following embodiments is preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0098] This embodiment provides a device for the alliance chain consensus process. Figure 8 FIG. 1 shows a schematic diagram of the structure of a device for a consortium chain consensus process provided by an embodiment of the present invention. Figure 8 As shown, including:

[0099] Building module 801 is used to divide the nodes in the alliance chain into multiple clusters, the number of clusters in the alliance chain is at least four, the number of nodes in the alliance chain is at least twelve, and the nodes include at least one of a faulty node and a malicious node and ordinary nodes.

[0100] The first consensus module 802 is used for nodes in each cluster to use a distributed consistency algorithm to reach consensus among nodes. The nodes in the cluster include follower nodes, candidate nodes and leader nodes.

[0101] The second consensus module 803 is used for the leader nodes of each cluster to use a practical Byzantine fault-tolerant algorithm to reach consensus among clusters.

[0102] In some optional implementations, the first consensus module 802 includes:

[0103] The first unit of the first consensus module is used for the initial state of each node in the target cluster to be a follower node. The target follower node that receives the message starts a timer. If the timer records a duration that exceeds a preset duration, the state of the target follower node is switched to a candidate node.

[0104] The second unit of the first consensus module is used to send a voting request to each node in the target cluster based on the candidate node. If the candidate node obtains a preset number of votes, the state of the candidate node is switched to a leading node.

[0105] The third unit of the first consensus module is used to create a log entry based on the transaction request submitted by the client node if the leader node obtains the transaction request, broadcast the log entry to the follower nodes in the target cluster, and the follower nodes in each target cluster reply to the leader node based on their own log records. If the leader node obtains replies from a preset number of nodes, the log entry is added to the log through the leader node, and the consensus between nodes is completed.

[0106] In some optional implementations, the second unit of the first consensus module includes:

[0107] The first subunit of the second unit is used to, if the term of the candidate node included in the voting request is greater than the term in the log of the target follower node in the target cluster, the target follower node votes for the candidate node, and the number of votes for the candidate node increases by one.

[0108] In some optional implementations, the second unit of the first consensus module further includes:

[0109] The second sub-unit of the second unit is used for the case where, when the term of the candidate node included in the voting request is equal to the term in the log of the target follower node, if the first value of the log index of the candidate node included in the voting request is greater than the second value of the log index of the target follower node, the target follower node votes for the candidate node, and the number of votes for the candidate node is increased by one.

[0110] In some optional implementations, the aforementioned device for the alliance chain consensus process further includes:

[0111] The information sending module is used to select a leader node in the target cluster, and the leader node sends periodic heartbeat information to other nodes in the target cluster.

[0112] In some optional implementations, the second consensus module 803 includes,

[0113] The first unit of the second consensus module is used to send a preparation message to other leader nodes based on the leader node.

[0114] The second unit of the second consensus module is used for the target leader node whose number of prepared messages reaches a preset number to enter the submission phase, and the target leader node sends a submission message to other leader nodes and client nodes.

[0115] The third unit of the second consensus module is used to complete the inter-cluster consensus if the number of submission messages obtained by the client node reaches a preset number.

[0116] The further functional description of each of the above modules and units is the same as that of the above corresponding embodiments and will not be repeated here.

[0117] The device for the alliance chain consensus process in this embodiment is presented in the form of a functional unit, where the unit refers to an application specific integrated circuit (ASIC) circuit, a processor and memory that executes one or more software or fixed programs, and / or other devices that can provide the above functions.

[0118] The embodiment of the present invention also provides a computer device having the above Figure 8 The apparatus shown is used for the consortium chain consensus process.

[0119] See also Fig. 9 , Fig. 9 is a schematic diagram of the structure of a computer device provided by an optional embodiment of the present invention, such as Fig. 9 As shown, the computer device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. Various components are connected to each other using different buses for communication, and can be installed on a common mainboard or installed in other ways as needed. The processor can process instructions executed in the computer device, including instructions stored in or on the memory to display graphical information of a graphical user interface on an external input / output device (such as a display device coupled to an interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple computer devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Fig. 9 A processor 10 is taken as an example.

[0120] The processor 10 may be a central processing unit, a network processor or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be a dedicated integrated circuit, a programmable logic device or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic or any combination thereof.

[0121] The aforementioned memory 20 stores instructions executable by at least one processor 10, so that the aforementioned at least one processor 10 executes the method shown in the above embodiment.

[0122] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created according to the use of the computer device, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely arranged relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0123] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid state drive; the memory 20 may also include a combination of the above types of memory.

[0124] The computer device also includes an input device 30 and an output device 40. The processor 10, the memory 20, the input device 30 and the output device 40 may be connected via a bus or other means. Fig. 9 The example of connecting through bus is taken in the following.

[0125] The input device 30 can receive input digital or character information, and generate key signal input related to the user settings and function control of the computer device, such as a touch screen, a keypad, a mouse, a track pad, a touch pad, an indicator rod, one or more mouse buttons, a trackball, a joystick, etc. The output device 40 may include a display device, an auxiliary lighting device (such as a light emitting diode) and a tactile feedback device (such as a vibration motor), etc. The above-mentioned display device includes but is not limited to a liquid crystal display, a light emitting diode, a display and a plasma display. In some optional embodiments, the display device can be a touch screen.

[0126] The embodiment of the present invention also provides a computer-readable storage medium. The method according to the embodiment of the present invention can be implemented in hardware, firmware, or can be implemented as a computer code that can be recorded in a storage medium, or can be implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and will be stored in a local storage medium through a network download, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state hard disk, etc.; further, the storage medium can also include a combination of the above types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor, or hardware, the method shown in the above embodiment is implemented.

[0127] A part of the present invention may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present invention through the operation of the computer. Those skilled in the art should understand that the existence of the computer program instruction in a computer-readable medium includes, but is not limited to, a source file, an executable file, an installation package file, etc., and accordingly, the way in which the computer program instruction is executed by the computer includes, but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium may be any available computer-readable storage medium or communication medium accessible to the computer.

[0128] Although the embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations are all within the scope defined by the appended claims.

Claims

1. A method for a consortium chain consensus process, characterized in that: The method comprises: Divide the nodes in the alliance chain into multiple clusters, the number of clusters in the alliance chain is at least four, the number of nodes in the alliance chain is at least twelve, and the nodes include at least one of a faulty node and a malicious node and a normal node; Each node in the cluster uses a distributed consensus algorithm to reach consensus among nodes, and the nodes in the cluster include follower nodes, candidate nodes and leader nodes; The leader nodes of each cluster use a practical Byzantine fault-tolerant algorithm to reach consensus among the clusters.

2. The method according to claim 1, characterized in that Each node in the cluster uses a distributed consensus algorithm to reach consensus among nodes, including: The initial state of each node in the target cluster is a follower node. The target follower node that receives the message starts a timer. If the duration recorded by the timer exceeds a preset duration, the state of the target follower node is switched to a candidate node. Sending a voting request based on the candidate node to each node in the target cluster, if the candidate node obtains a preset number of votes, switching the state of the candidate node to a leader node; If the leader node obtains a transaction request submitted by a client node, it creates a log entry based on the transaction request and broadcasts the log entry to the follower nodes in the target cluster. Each follower node in the target cluster replies to the leader node based on its own log record. If the leader node obtains replies from a preset number of nodes, the log entry is added to the log by the leader node, and the consensus between the nodes is completed.

3. The method according to claim 2, characterized in that Sending a voting request to each node in the target cluster based on the candidate node includes: If the term of the candidate node included in the voting request is greater than the term in the log of the target follower node in the target cluster, the target follower node votes for the candidate node, and the number of votes for the candidate node increases by one.

4. The method according to claim 2, characterized in that: Sending a voting request to each node in the target cluster based on the candidate node also includes: In the case where the term of the candidate node contained in the voting request is equal to the term in the log of the target follower node, if the first value of the log index of the candidate node contained in the voting request is greater than the second value of the log index of the target follower node, the target follower node votes for the candidate node, and the number of votes for the candidate node is increased by one.

5. The method according to claim 2, characterized in that: The method further comprises: If the leader node is selected in the target cluster, the leader node sends periodic heartbeat information to other nodes in the target cluster.

6. The method according to claim 1 or 2, characterized in that: The leader nodes of each cluster use a practical Byzantine fault-tolerant algorithm to reach consensus among the clusters, including: Sending a prepare message to other leader nodes based on the leader node; The target leader node whose number of the prepared messages reaches a preset number enters a submission phase, and the target leader node sends a submission message to other leader nodes and the client node; If the number of submission messages obtained by the client node reaches a preset number, the inter-cluster consensus is completed.

7. A device for a consortium chain consensus process, characterized in that: The device comprises: A construction module is used to divide the nodes in the alliance chain into multiple clusters, the number of the clusters in the alliance chain is at least four, the number of the nodes in the alliance chain is at least twelve, and the nodes include at least one of a faulty node and a malicious node and a common node; A first consensus module, used for each node in the cluster to use a distributed consensus algorithm to reach a consensus among nodes, wherein the nodes in the cluster include follower nodes, candidate nodes and leader nodes; The second consensus module is used for the leadership nodes of each cluster to use a practical Byzantine fault-tolerant algorithm to reach consensus among clusters.

8. A computer device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the method for the alliance chain consensus process according to any one of claims 1 to 6 by executing the computer instructions.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the method for the alliance chain consensus process described in any one of claims 1 to 6.

10. A computer program product, characterized in that It includes computer instructions, which are used to cause a computer to execute the method for the alliance chain consensus process described in any one of claims 1 to 6.

Images