A consensus method, a communication device and a computer readable storage medium

Abstract

The application provides a consensus method, a communication device and a computer readable storage medium, the method comprising: each member in a blockchain participating in performing a consensus protocol, corresponding to a copy node, the copy node comprising a leader and a follower; the consensus protocol comprising a normal state protocol, and consensus between the leader and one or more followers is reached according to the normal state protocol. The application optimizes a traditional practical Byzantine fault tolerance consensus algorithm by using a chain structure of the blockchain, simplifies a consensus process under the premise of ensuring original security, removes one full node broadcast for each consensus process, improves transaction throughput of a system, and reduces consumption of communication resources and communication cost.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of blockchain technology, in particular to a consensus method in the blockchain technology, a communication device and a computer readable storage medium. BACKGROUND

[0002] The blockchain is a distributed ledger technology, which has the characteristics of decentralization, trustlessness and tamper resistance, and the consensus algorithm is the core of the blockchain, so that all participants interact through network messages to locally maintain the consistent ledger content of the whole network.

[0003] The existing consensus protocol in the distributed system, such as the Byzantine fault-tolerant mechanism, can output a deterministic consensus result when the system contains no more than one-third of malicious nodes or faulty nodes. The blockchain relaxes the requirement for consistency by relying on the hash chain structure, and achieves probabilistic consistency through the longest chain principle. The deeper the block, the higher the probability of achieving consistency. However, this probabilistic consensus needs to wait for a long enough confirmation time, resulting in poor performance and low throughput of the blockchain.

[0004] Currently, there are Byzantine fault-tolerant consensus algorithms applied to the blockchain. In the consortium chain system, a node admission mechanism is introduced, usually specifying a certain node as a leader, the leader node initiates a block proposal and broadcasts it to other nodes in the network, and other nodes collect a quorum of messages and sign and broadcast again. According to the Byzantine fault-tolerant consensus protocol process, after multiple rounds of message broadcasting, all nodes can safely write the block proposal into the blockchain, thereby completing a round of consensus deterministically.

[0005] This scheme requires multiple rounds of message interaction to directly output the block to be written into the local blockchain, and does not utilize the chain structure to reduce communication costs. The throughput and delay of the system are still limited by the original consensus protocol, and the efficiency and ability of the blockchain system to store content and process transactions are limited, which is not conducive to the promotion and use of the blockchain system in practical application scenarios such as e-government and electronic evidence. SUMMARY

[0006] The purpose of the embodiments of the present application is to provide a consensus method, a communication device and a computer readable storage medium, which optimizes the traditional practical Byzantine fault-tolerant consensus algorithm by utilizing the chain structure of the blockchain, so that the consensus protocol can improve the throughput of the system to process transactions and reduce the communication cost while maintaining the Byzantine fault-tolerant capability.

[0007] To solve the above problems, the embodiments of the present application provide a consensus method, which comprises:

[0008] Each member in a blockchain participating in a consensus protocol, the members including one leader and one or more followers, each member corresponding to a replica node;

[0009] The consensus protocol includes a regular state protocol, according to which consensus between the leader and the followers is reached.

[0010] The regular state protocol includes:

[0011] All replica nodes vote on a block generation message, the message containing a corresponding block hash and a view number, and send the message to the leader while starting a timer;

[0012] The leader collects the voting messages for the block, collects enough voting messages within a certain time, generates a proposal message according to the packaged transaction data and the voting messages, and broadcasts the proposal message;

[0013] The replica node receives the proposal message broadcast by the leader before the timer ends, adds the proposal message as a new block to the blockchain, and safely commits the second block before the block.

[0014] Further, the method further includes:

[0015] When the leader does not collect enough voting messages within a certain time, the leader generates a re-vote message according to the current block, and broadcasts the re-vote message to all replica nodes;

[0016] The generated re-vote message has a higher hash value or a higher block height than the block corresponding to the last voting message, in the case of the same block height, then the re-vote message is valid;

[0017] The replica node re-sends a voting message to the leader according to the re-vote message.

[0018] Further, the consensus protocol further includes a view conversion protocol,

[0019] If the replica node does not receive the proposal message broadcast by the leader before the timer ends, the view conversion protocol is executed,

[0020] According to the view conversion protocol, the view is converted and the leader is changed, and the regular state protocol is continued to be executed by the changed new leader.

[0021] The view conversion protocol includes:

[0022] The follower locks the blockchain state, generates a view change message, sends the view change message to the leader of the next view, and starts a new timer at the same time;

[0023] The leader of the next view collects the view change messages of the view, generates a new view message after collecting enough view change messages, and broadcasts the new view message to all replica nodes;

[0024] When the leader of the next view does not collect enough view change messages within a certain time, the node that starts a new timer in the view change protocol executes the view change protocol again, starting a new round of view change, and the timer length in the new round of view change protocol is longer than that in the previous round of protocol.

[0025] After receiving the new view message from the leader of the next view, the replica node determines the blockchain fork position according to the new view message, unlocks the blockchain state, and executes the normal state protocol.

[0026] Further, the method further comprises:

[0027] Before the new timer expires, if the new view message generated by the leader of the next view is not received, the view change protocol is executed again until the new timer expires and the new view message generated by the leader of the next view is received.

[0028] The proposal message is Wherein propose is the message type of the proposal message, d is the packaged transaction data, v is the current view number, h k-1 is the hash value of the previous block, is the collection of voting messages for the previous block collected by the leader under view v, <> L is the signature of the message publisher for the proposal message, and L refers to the leader;

[0029] The voting message is <vote, v, h k > r Wherein vote is the message type of the voting message, v is the current view number, h k is the hash value of the current block, <> r is the signature of the message publisher for the voting message, and r refers to the replica node;

[0030] The recall message is <recall, v, m L Wherein recall is the message type of the recall message, v is the current view number, and m is the proposal message to be voted on, <> L is the signature of the message publisher for the recall message.

[0031] wherein the view-change message is <view-change, v+1, h k > r wherein view-change is the message type of the view-change message, v+1 is the new view number, h k is the current block hash, <> r is the message publisher's signature on the view-change message;

[0032] the new-view message is <new-view, v+1, π, m L wherein new-view is the message type of the new-view message, v+1 is the number of the new view, π is the set of view-change messages for the previous view collected by the new leader, m is the proposal message of the fork origin, <> L is the message publisher's signature on the new-view message.

[0033] wherein the block structure used by the blockchain is wherein B k is a block with height k, propose is the message type of the proposal message, d is the packed transaction data, v is the current view number, h k-1 is the hash of the previous block, is the set of vote messages for the previous block collected by the leader in view v, <> L is the message publisher's signature on the proposal message, and L denotes the leader.

[0034] wherein the block structure includes a block header and a block body, and the block body includes the message type, the transaction data, the current view number, the hash of the previous block, and the vote messages for the previous block.

[0035] wherein during the operation of the consensus protocol, each replica node acts as a follower or a leader, and processes messages in the first node and the third node respectively, executes the regular state protocol, and reaches consensus;

[0036] When the leader is malicious or fails, an honest follower will enter the second state and start the view-change protocol to replace the current leader and reach consensus under the organization of the new leader because it has not received a legal proposal message before the timer expires.

[0037] When consensus is performed under the organization of the new leader, the new leader still commits evil or fails, no view conversion is performed, and a new view message is published, then each replica node continues to remain in the second state after a timer timeout, starts a new round of view conversion protocol, and continues to replace the view and the leader until the normal state protocol is completely executed, and then enters the normal state protocol again, and the consensus is completed in the first state and the third state;

[0038] The first state and the third state are respectively processing messages by the follower and the leader, and the second state is processing messages by a replica node performing view conversion.

[0039] The embodiment of the application further provides a communication device, including a memory, a processor and a program stored in the memory and executable on the processor, and the processor implements the consensus method as described above when executing the program.

[0040] The embodiment of the application further provides a computer readable storage medium, which stores a computer program, and the program is executed by a processor to implement the steps in the consensus method as described above.

[0041] The above technical solutions of the application have at least the following beneficial effects:

[0042] The consensus method, the communication device and the computer readable storage medium provided by the embodiment of the application optimize the traditional practical Byzantine fault tolerance consensus algorithm by using the chain structure of the block chain, the new block does not have to wait for the end of the previous consensus instance, but can directly enter the consensus processing, thereby saving the time of block waiting for consensus, simplifying the consensus process under the premise of ensuring the original security, removing the full node broadcast for each consensus process, improving the transaction throughput of the system, and reducing the consumption of communication resources and the communication cost.

[0043] The embodiment of the application modifies the voting by sorting the received block proposal according to the block height and the block hash value within the view validity period, which can help the block chain quickly converge to the longest chain and improve the system response capability. BRIEF DESCRIPTION OF DRAWINGS

[0044] Figure 1 A consensus method flowchart provided by the embodiment of the application is shown;

[0045] Figure 2 A normal state protocol execution flowchart in the consensus method provided by the embodiment of the application is shown;

[0046] Figure 3 Another normal state protocol execution flowchart in the consensus method provided by the embodiment of the application is shown;

[0047] Figure 4 Figure 1 shows a schematic diagram of the view conversion protocol execution process in the consensus method provided by the embodiment of the present application;

[0048] Figure 5 Figure 2 shows another schematic diagram of the view conversion protocol execution process in the consensus method provided by the embodiment of the present application;

[0049] Figure 6 Figure 3 shows a schematic diagram of the block structure in the consensus method provided by the embodiment of the present application;

[0050] Figure 7 Figure 4 shows a schematic diagram of the node state transition in the consensus method provided by the embodiment of the present application. DETAILED DESCRIPTION

[0051] In order to make the technical problems, technical solutions and advantages of the present application clearer, specific embodiments will be described in detail below with reference to the accompanying drawings.

[0052] The embodiment of the present application adopts a system model similar to the practical Byzantine fault tolerance consensus protocol, in which the members participating in the execution of the consensus protocol are relatively fixed, each member corresponds to a replica node, the nodes are connected by point-to-point communication to complete networking, and no more than one-third of the nodes can be tolerated to fail or be malicious. The replica nodes can be divided into leaders and followers according to identity, and in each round of consensus, a leader drives the protocol to lead other followers to complete it.

[0053] The consensus protocol involved in the present application includes a regular state protocol and a view conversion protocol. The regular state protocol is mainly used to reach consensus, and uses the proposal and voting method to encapsulate a block. A re-vote stage is provided in the regular state protocol to allow nodes to change votes, so that the consensus is more flexible. In the block chain generated by the regular state protocol, when the chain height is k, the block B k-2 can be safely submitted. The view conversion protocol is mainly used to convert the view and change the leader. It is triggered by a block timeout, the node locks the current voted block and converts the view, and after completion, it re-votes for the leader of the new view, and then the leader of the new view continues to execute the regular state protocol.

[0054] In the process of executing the consensus protocol, five types of messages are provided for communication between nodes in the protocol execution process, including proposal messages, voting messages, re-vote messages, view conversion messages and new view messages. Among them, the proposal message is the block structure used in the block chain B k is a block with height k, which organically combines the Byzantine fault tolerance consensus algorithm with the block chain. The specific description of the five message types is as follows:

[0055] Proposal message: in the form of denoted as PROPOSE, where propose is the message type of the proposal message, d is the packaged transaction data, v is the current view number, used to identify the current view, h k-1 is the hash value of the previous block, i.e., the hash value of the block with height k-1, used to link the previous block, is the set of vote messages collected by the leader under view v for the previous block, used to prove that the proposal of the previous block is legal, <> L is the signature of the message publisher for the message, and L refers to the leader;

[0056] Vote message: in the form of k r denoted as VOTE, where vote is the message type of the vote message, v is the current view number, used to identify the current view, h k is the hash value of the current block, i.e., the hash value of the block with height k, used to indicate the block to which the vote points, <> r is the signature of the message publisher for the message, and r refers to the replica node;

[0057] Recall message: in the form of L denoted as RECALL, where recall is the message type of the recall message, v is the current view number, used to identify the current view, and m is the proposal message to be voted on, used to indicate the message that needs to be recalled, <> L is the signature of the message publisher for the message;

[0058] View change message: in the form of k r denoted as VIEWCHANGE, where view-change is the message type of the view change message, v+1 is the new view number, used to identify the new view, h k is the hash value of the current block, used to identify the current block information, <> r is the signature of the message publisher for the message;

[0059] New view message: in the form of L denoted as NEWVIEW, where new-view is the message type of the new view message, v+1 is the new view number, used to identify the current view, π is the set of view change messages collected by the new leader for the previous view, used to prove that the new view message is legal, and m is the proposal message of the fork starting point, used to synchronize the blockchain state of different replica nodes, <> L is the signature of the message publisher for the message.​​

[0060] Specifically, as shown in Figure 1 , the embodiment of the present application provides a consensus method, the method comprising:

[0061] Step 101: each member in a blockchain participating in the consensus protocol, the members including one leader and one or more followers, each member corresponding to a replica node;

[0062] Step 102: the consensus protocol includes a regular state protocol, and consensus between the leader and the follower is reached according to the regular state protocol.

[0063] The regular state protocol provided by the embodiment of the present application is executed immediately after the last consensus protocol is completed, assuming that all nodes are in view v and the current block height is k-1 when the protocol starts, as shown in Figure 2 , 3 , the regular state protocol includes:

[0064] Step 201: all replica nodes generate a voting message for the block B k-1 , the voting message containing a corresponding block hash and a view number, and send the voting message to the leader L while starting a timer;

[0065] Specifically, the voting message VOTE = <vote, v, h k-1 > r , the timer time is set to t, and if the proposal message from the leader is not received before the timer ends, the view conversion protocol is entered;

[0066] Step 202: the leader L collects the voting message VOTE of the block B k-1 , collects enough voting messages within a certain time, generates a proposal message according to the packaged transaction data and the voting message, and broadcasts the proposal message;

[0067] Wherein, the voting message contains the collected votes as a proof of the legitimacy of the proposal message;

[0068] This step includes: 1) when the leader L does not collect enough voting messages within a certain time t' (t' should be less than the timer duration t of the follower), the leader generates a recall message RECALL = <recall, v, m L according to the current block, and broadcasts the recall message to all replica nodes;

[0069] The generated recall message has a higher hash value or a higher block height than the block corresponding to the last voting message in the case of the same block height, and the recall message is valid.

[0070] The replica node resends the vote message VOTE′= to the leader based on the resend message.<vote,v,H(m)> r , where H(m) is the hash value of the block pointed to by m.

[0071] 2) If leader L has collected enough voting messages, then the leader will determine the outcome based on the packaged transaction data d and the set of voting messages. Generate a proposal message PROPOSE and broadcast the proposal message to all replica nodes.

[0072] Step 203: Before the timer expires, the replica node receives the PROPOSE message broadcast by the leader and uses the PROPOSE message as the new block B. k =The PROPOSE is added to the blockchain, making it the second block B preceding the aforementioned block. k-2 Submit securely.

[0073] Furthermore, if the replica node does not receive a proposal message broadcast by the leader before the timer expires, it executes the view transition protocol, changes the view and the leader according to the view transition protocol, and the new leader continues to execute the regular state protocol.

[0074] Specifically, such as Figure 4 , 5 As shown, the view transition protocol begins execution after the follower's timer times out. The view transition protocol includes:

[0075] Step 301: The follower locks the blockchain state, generates a view transition message, sends the view transition message to the leader L′ of the next view v+1, and starts a new timer;

[0076] Specifically, the view transition message VIEWCHANGE= <view-change,v+1,h k > r The timer is set to a timeout period of t. If a new view message NEWVIEW is not received from the leader L′ before the timeout ends, the view transition protocol is entered again.

[0077] Step 302: The leader L′ of the next view collects the view transition messages VIEWCHANGE of the view v+1, generates a new view message after collecting enough view transition messages, and broadcasts the new view message to all replica nodes;

[0078] NewView message NEWVIEW=<new-view,v+1,π,m> LWherein π contains the collected view transition message as the proof of the legitimacy of the new view message.

[0079] Step 303: When the leader L' of the next view does not collect enough view transition messages within a certain time, the node starting the new timer in the view transition protocol executes the view transition protocol again, starting a new round of view transition.

[0080] Wherein the length of the timing time in the new round of view transition protocol is longer than that in the last round of protocol, so as to avoid frequent view transition.

[0081] After receiving the new view message VIEWCHANGE of the leader L' of the next view, the replica node determines the blockchain fork position B according to m in the new view message m , releases the lock on the blockchain state, and executes the normal state protocol.

[0082] Wherein when the new timer ends without receiving the new view message generated by the leader of the next view, the view transition protocol is executed again until the new view message generated by the leader of the next view is received before the new timer ends.

[0083] The block structure used in the application is shown in Figure 6 The block structure includes a block header and a block body, and the block body includes a message type, transaction data, a current view number, a previous block hash value and a previous block voting message.

[0084] The block structure is the same as the proposal message structure, that is, Wherein B k is a block with a height of k, propose is the message type of the proposal message, d is the packaged transaction data, v is the current view number, h k-1 is the hash value of the previous block, is the collection of voting messages for the previous block collected by the leader in view v, <> L is the signature of the message publisher for the proposal message, and L refers to the leader.

[0085] In the actual operation process of the protocol, the state transition of the node is as follows Figure 7When the system is running normally, each replica node as a follower or a leader processes messages in the first state (labeled 1 in the figure) and the third state (labeled 3 in the figure) respectively, executes a normal state protocol, and reaches consensus; and when the leader is malicious or fails, the honest follower enters the second state (labeled 2 in the figure) before a timer expires without receiving a legitimate proposal message, starts a view change protocol, replaces the current leader, and finally enters a new view to reach consensus under the organization of the new leader.

[0086] If the new leader is still a malicious or failed node during the process and does not perform view change and issue a new view message, each replica node continues to remain in the second state (labeled 2 in the figure) after the timer expires, starts a new round of view change protocol, continues to replace the view and the leader, until the protocol is completely executed, and then enters the normal state protocol again to complete consensus in states 1 and 3.

[0087] The first state and the third state are respectively for processing messages as a follower and a leader, and the second state is for processing messages as a replica node performing view change.

[0088] Thus, the honest node can reach consensus according to the normal state protocol.

[0089] For the node malpractice that may be encountered during the execution of the protocol, if a replica node is malicious and sends an incorrect voting message to the leader during the normal state protocol, the leader only needs to discard the message, and when collecting legitimate voting messages of not less than 2f+1 nodes, the leader can broadcast a proposal message.

[0090] If the leader is malicious and does not broadcast a proposal message or broadcasts an incorrect proposal message during the normal state protocol, the honest follower enters the view change protocol, replaces the view and the leader in the second state, and reenters the normal state protocol.

[0091] If the new leader is malicious and does not broadcast a new view message or broadcasts an incorrect new view message during the view change protocol, the honest replica node remains in the second state, reenters the view change protocol, and finally enters the normal state protocol.

[0092] The embodiment of the application can make message processing pipelined by introducing a blockchain chain structure into a Byzantine fault-tolerant consensus algorithm, so that a new block does not have to wait for the end of the previous consensus instance, but can directly enter the consensus processing, which greatly improves the transaction throughput of the system and saves the time for block waiting for consensus. By modifying the voting, the received block proposal is sorted according to the block height and the size of the block hash value within the view validity period, which can help the blockchain quickly converge to the longest chain and improve the system response capability.

[0093] The embodiment of the application simplifies the consensus process under the premise of ensuring the original security, removes one full node broadcast for each consensus process, reduces the consumption of communication resources, and improves the transaction throughput.

[0094] An embodiment of a conventional process protocol is given below, in which the number of nodes participating in consensus is 4, the number of fault-tolerant nodes is 1, node 0 is the leader, the current blockchain height is k-1, the view is v, the network condition is good, and the process is as follows:

[0095] 1) All replica nodes numbered 0 to 3 generate voting messages VOTE0=<vote,v,h k-1 >0, VOTE1=<vote,v,h k-1 >1, VOTE2=<vote,v,h k-1 >2, VOTE3=<vote,v,h k-1 >3 about the block with height k-1, and send the message to the current leader 0 and start a timer with a set timer time t;

[0096] 2) The leader 0 collects and verifies the legality of the voting messages, and after collecting 3 legal voting messages VOTE0, VOTE1, VOTE2 from replicas 0 to 2, adds the collected voting messages to the proposal message in the form of a set and broadcasts the proposal message to all replica nodes;

[0097] 3) All replica nodes numbered 0 to 3 verify the legality of the proposal message PROPOSE received from the leader 0, and add the proposal message as the block B k with height k to the blockchain, and at the same time, add the block B k-2 with height k-2 as a block that has been determined to be safely submitted.

[0098] At this point, all legal nodes have reached consensus on the block B k-2 with height k-2.

[0099] The following is an example of a view transformation protocol. The number of nodes participating in consensus is 4, and the number of fault-tolerant nodes is 1. Node 0 is the currently timed-out leader. Node 0 has crashed due to a local failure and is unable to send, receive, or process any messages. The current view number is v, and the current blockchain height is k-1. The process is as follows:

[0100] 1) Replica nodes numbered 1 to 3 lock the blockchain state after the timer expires, stop receiving messages from node 0, and generate a view transition message VIEWCHANGE1= to transition to view v+1. <view-change,v+1,h k-1 >1,VIEWCHANGE2= <view-change,v+1,h k-1 >2,VIEWCHANGE3= <view-change,v+1,h k-1 >3, and send the message to the new leader, which is node number 1, and start a timer with the timeout period set to t;

[0101] 2) The new leader 1 collects and verifies the legitimacy of view transition messages. After collecting 3 legitimate view transition messages from replicas 1 to 3... Figure 1 After the view transition messages VIEWCHANGE1, VIEWCHANGE2, and VIEWCHANGE3 are generated, the view is... Figure 1 NewView message NEWVIEW=<new-view,v+1,π,m> 1, where π = {VIEWCHANGE1,VIEWCHANGE2,VIEWCHANGE3} contains the collected view transition messages and broadcasts these messages to all replica nodes;

[0102] 3) After receiving a new view message (v+1) from the new leader 1, replica nodes 1 to 3 unlock their blockchain state and determine the fork position B based on the block information m in the message. m Then, the normal process protocol is entered, and the vote is sent to leader 1.

[0103] As can be seen, this embodiment of the invention introduces the chain structure of blocks into the Byzantine fault-tolerant consensus algorithm, thereby enabling the consensus protocol to process newly generated block proposals in a pipeline manner. It also provides a new block structure, which includes a valid signature set field for the hash of the previous block, used to self-verify whether the legality of the block meets the protocol requirements. The scheme allows nodes to change their votes when they receive block proposals with higher block heights or larger hash values, and designs a view transition message type, accordingly modifying the view transition protocol, which can smoothly transfer the voting status of the block where the failed view is located to the next view.

[0104] The embodiment of the present application also provides a communication device, comprising a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to realize each process in the consensus method embodiment and achieve the same technical effects. To avoid repetition, details are not described herein.

[0105] The embodiment of the present application also provides a computer readable storage medium, which stores a computer program executable by a processor to realize each process in the consensus method embodiment and achieve the same technical effects. To avoid repetition, details are not described herein. The computer readable storage medium can be a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0106] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system or a computer program product. Therefore, the present application can be in the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Moreover, the present application can be in the form of a computer program product implemented on one or more computer readable storage media (including but not limited to disk storage and optical storage) containing computer usable program code.

[0107] The present application is described with reference to the flowcharts and / or block diagrams according to the method, device (system) and computer program product of the embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of the flows and / or blocks in the flowcharts and / or block diagrams can be implemented by computer program instructions. These computer program instructions can be provided to a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing devices to produce a machine, so that the instructions executed by the computer or other programmable data processing devices produce a device that implements the functions specified in the flowcharts and / or block diagrams. Figure 1 The device that implements the functions specified in one flow or multiple flows and / or one block or multiple blocks.

[0108] These computer program instructions can also be stored in a computer readable storage medium that can guide the computer or other programmable data processing devices to work in a specific way, so that the instructions stored in the computer readable storage medium produce a product including an instruction device that implements the functions specified in the flowcharts and / or block diagrams. Figure 1 The device that implements the functions specified in one flow or multiple flows and / or one block or multiple blocks. Figure 1 The device that implements the functions specified in one flow or multiple flows and / or one block or multiple blocks.

[0109] These computer program instructions can also be loaded into computer or other programmable data processing devices, so that a series of operational steps are performed on the computer or other programmable data processing devices to generate a computer-implemented process, so that the instructions executed on the computer or other programmable data processing devices provide steps for implementing the function specified in the flowchart Figure 1 one flow or a plurality of flows and / or the functions specified in the block ​ one flow or a plurality of flows and / or the functions specified in the block

[0110] The above is the preferred embodiment of the present application, it should be pointed out that, for those skilled in the art, without departing from the principles of the present application, can also make a number of improvements and refinements, these improvements and refinements should also be considered as the protection scope of the present application.

Claims

1. A consensus method, characterized by, The method comprises: Each member in a blockchain participating in a consensus protocol, the members including one leader and one or more followers, each member corresponding to a replica node; The consensus protocol includes a regular state protocol, according to which consensus is reached between the leader and the followers; The regular state protocol includes: All replica nodes vote on a block generation message, the message containing a corresponding block hash and a view number, and send the message to the leader while starting a timer; The leader collects the voting messages of the block, collects enough voting messages within a certain time, generates a proposal message according to the packaged transaction data and the voting messages, and broadcasts the proposal message; The replica node receives the proposal message broadcast by the leader before the timer ends, adds the proposal message as a new block to the blockchain, and safely commits the second block before the block.

2. The method of claim 1, wherein, The method further comprises: When the leader does not collect enough voting messages within a certain time, the leader generates a re-vote message according to the current block, and broadcasts the re-vote message to all replica nodes; The generated re-vote message has a higher hash value or a higher block height than the block corresponding to the last voting message, and the re-vote message is valid; The replica node re-sends a voting message to the leader according to the re-vote message.

3. The method of claim 1, wherein, The consensus protocol further includes a view conversion protocol, If the replica node does not receive the proposal message broadcast by the leader before the timer ends, the view conversion protocol is executed, According to the view conversion protocol, the view is converted and the leader is changed, and the regular state protocol is continued to be executed by the new leader after the change.

4. The method of claim 3, wherein, The view conversion protocol includes: The follower locks the blockchain state, generates a view conversion message, and sends the view conversion message to the leader of the next view while starting a new timer; The leader of the next view collects the view conversion messages of the view, generates a new view message after collecting enough view conversion messages, and broadcasts the new view message to all replica nodes; When the leader of the next view does not collect enough view conversion messages within a certain time, the node that starts a new timer in the view conversion protocol executes the view conversion protocol again, starts a new round of view conversion, and the timer time length in the new round of view conversion protocol is longer than that in the last round of protocol; After receiving the new view message of the leader of the next view, the replica node determines the blockchain fork position according to the new view message, unlocks the blockchain state, and executes the regular state protocol.

5. The method of claim 4, wherein, The method further comprises: Before the new timer ends, if the new view message generated by the leader of the next view is not received, the view conversion protocol is executed again until the new timer ends and the new view message generated by the leader of the next view is received.

6. The method of claim 1 or 2, wherein The propose message is where propose is the message type of the propose message, d is the packaged transaction data, v is the current view number, h k-1 is the hash value of the previous block, is the set of vote messages for the previous block collected by the leader under view v, L is the signature of the message publisher for the propose message, and L denotes the leader. The voting message is <vote, v, h k > r , where vote is the message type of the voting message, v is the current view number, h k is the hash value of the current block, <> r is the signature of the message publisher for the voting message, and r indicates a replica node. The recall message is <recall, v, m> L where recall is the message type of the recall message, v is the current view number, m is the proposal message to be voted on, and L is the message publisher's signature on the recall message.

7. The method of claim 4 or 5, wherein the block structure comprises a block header and a block body, and the block body comprises a message type, transaction data, a current view number, a previous block hash value, and a previous block voting message. The view-change message is <view-change, v+1, h k > r where view-change is the message type of the view-change message, v+1 is the new view number, h k is the current block hash, <> r is the message publisher's signature for the view-change message; The new view message is <new-view, v+1, π, m> L where new-view is the message type of the new view message, v+1 is the number of the new view, π is the set of view change messages collected by the new leader for the previous view, m is the proposal message of the split point, L is the signature of the message publisher to the new view message.

8. The method of claim 1, wherein, The blockchain uses a block structure of where B k is a block of height k, propose is the message type of the proposal message, d is the packaged transaction data, v is the current view number, h k-1 is the hash of the previous block, is the set of vote messages for the previous block collected by the leader under view v, <> L is the signature of the message publisher for the proposal message, and L refers to the leader.

9. The method of claim 8, wherein, In the consensus protocol, each replica node acts as a follower or a leader, and processes messages in the first state and the third state respectively, executes the regular state protocol, and reaches consensus.

10. The method of claim 1, wherein, When the leader is misbehaving or fails, the honest followers enter the second state and initiate the view change protocol to replace the current leader, and finally enter a new view to reach consensus under the new leader. When the new leader is misbehaving or fails without view change and issues a new view message, each replica node continues to remain in the second state after the timer expires, initiates a new round of view change protocol, and continues to replace the view and the leader until the regular state protocol is completely executed, and then enters the regular state protocol again to complete consensus in the first state and the third state. The first state and the third state are for the followers and the leaders to process messages respectively, and the second state is for the replica nodes to process messages during view change. The processor executes the program to implement the consensus method of any one of claims 1-10.

11. A communication device comprising a memory, a processor, and a program stored on the memory and executable on the processor; characterized in that, The program is executed by the processor to implement the steps in the consensus method of any one of claims 1-10.

12. A computer readable storage medium having stored thereon a computer program, characterized in that, ​

Images