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

Abstract

This invention provides a consensus method, communication device, and computer-readable storage medium. The method includes: each member in a blockchain participating in executing the consensus protocol forms a network through peer-to-peer communication; the members include a leader and followers, and each member corresponds to a replica node; the consensus protocol includes a rolling view protocol, which selects a leader from the replica nodes in turn, so that each follower becomes the leader in turn. This invention utilizes the chain structure of blockchain to optimize the traditional practical Byzantine fault-tolerant consensus algorithm. It eliminates one full node broadcast for each consensus process, reducing communication resource consumption and increasing transaction throughput. Simultaneously, it eliminates the separate view transformation protocol, integrating view transformation into the regular consensus process, reducing the communication and computational workload of leader replacement, and lowering the cost of the consensus protocol handling malicious nodes.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a consensus method, communication device, and computer-readable storage medium in blockchain technology. Background Technology

[0002] Blockchain employs a cryptographically based chain structure, allowing consensus on blockchain content within a dynamically changing distributed network. Nodes can freely join and leave the network, yet both new and old nodes maintain consistency regarding historical events. Blockchain supports consensus in dynamic networks by using the longest chain principle and block-making competition among nodes to select a unique longest chain as the consensus outcome. The trade-off is that this longest chain has a certain probability of being replaced by other forks, and a sufficient number of subsequent blocks must be confirmed before consensus can be recognized with a high probability.

[0003] The concept of consortium blockchains partially resolves this dilemma by reintroducing the network model of distributed systems into the blockchain environment and using consensus protocols that support Byzantine fault tolerance to handle block generation and submission.

[0004] Existing consortium blockchain consensus schemes presuppose a stable set of nodes, applying the Byzantine Fault Tolerance (BFT) algorithm to the network composed of this set. Blocks are considered input to the algorithm. A designated leader node initiates a block proposal, which is broadcast to other nodes to collect a quorum of votes. Once two or more rounds of votes are collected, the block proposal is securely written to the local storage of each node, completing one round of deterministic consensus. Each block must wait for the previous round of consensus protocol to complete before processing, and a timeout is triggered when the leader node fails to output a consistent result, initiating a view transition to replace the current leader node. To reduce the communication complexity caused by broadcasting, some schemes use gossip protocols or rely on the leader node to propagate block proposals and signature votes. In a valid view, nodes need to witness two rounds of valid votes for the same block to confirm successful consensus.

[0005] However, most existing solutions directly apply the consensus algorithm to a single block. New blocks must wait for the previous consensus round to complete before they can be processed, thus the performance bottlenecks encountered in traditional distributed systems persist. Furthermore, traditional Byzantine fault-tolerant algorithms process independent request messages, which are then packaged into batches by the leader node and drive consensus execution. When the leader node acts maliciously, causing the protocol to fail to stop outputting results, other nodes need to use an additional view-transfer protocol to replace the current leader node and transfer the context. While this view-transfer method does optimize the protocol's execution flow under normal conditions, it makes the entire protocol more complex in design and implementation, requiring consideration of numerous context states outside the consensus protocol itself. Summary of the Invention

[0006] The purpose of this invention is to provide a consensus method, communication device, and computer-readable storage medium. This consensus protocol supports Byzantine fault-tolerant rolling views, optimizes the traditional practical Byzantine fault-tolerant consensus algorithm by utilizing the chain structure of blockchain, improves the throughput of transaction processing, and designs and implements automatic view switching to reduce the cost of dealing with malicious nodes and improve the consensus efficiency of the blockchain system.

[0007] To address the above problems, embodiments of the present invention provide a consensus method, the method comprising:

[0008] Each member in the blockchain that participates in executing the consensus protocol forms a network through peer-to-peer communication. The members include leaders and followers, and each member corresponds to a replica node.

[0009] The consensus protocol includes a rolling view protocol, which selects a leader from the replica nodes in turn, so that each follower becomes a leader in turn.

[0010] The rolling view protocol includes: all replica nodes generating voting messages for blocks, sending the voting messages to the leader of the view, and starting a timer;

[0011] The leader of the view collects the voting messages of the block. If enough voting messages are collected within a certain period of time, a proposal message is generated based on the packaged transaction data and the voting messages, and the proposal message is broadcast.

[0012] After receiving the proposal message broadcast by the leader, the replica node adds the proposal message as a new block to the blockchain and securely commits the second block preceding the proposed block.

[0013] Furthermore, the method also includes:

[0014] If the leader fails to collect enough votes within a certain period of time, it generates a re-vote message based on the current block and broadcasts the re-vote message to all replica nodes.

[0015] If the block corresponding to the re-vote message has a higher hash value than the block corresponding to the previous voting message under the same block height and the same view, or has a higher view or a higher block height under the same block height, then the re-vote message is valid.

[0016] The replica node resends the vote message to the leader based on the resend message.

[0017] If the replica node does not receive a proposal message broadcast by the leader of the view before the timer expires, it will perform a view transition, send the corresponding voting message to the leader of the next view, and start a new round of the rolling view protocol.

[0018] Specifically, the proposal message is Where `propose` is the message type of the proposal message, `d` is the packaged transaction data, `v` is the current view number, and `h` is the message type of the proposal message. k-1 It is the hash value of the previous block. It is the collection of voting messages for the previous block gathered by the leader under view v. L It is the signature of the message publisher for the proposed message, where L refers to the leader;

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

[0020] The re-cast message is<recall,v,m> L This is represented as RECALL, where recall is the message type of the recast message, v is the current view number, m is the proposal message to be voted on, and <> L It is the signature of the message publisher for the resend message.

[0021] The blockchain uses the following block structure: Among them B k It is a block of height k, where propose is the message type of the proposal message, d is the packaged transaction data, v is the current view number, and h is the block height k. k-1 It is the hash value of the previous block. It is the collection of voting messages for the previous block gathered by the leader under view v. L It is the signature of the message publisher for the proposed message, and L refers to the leader.

[0022] The block structure includes a block header and a block body. The block body includes message type, transaction data, current view number, previous block hash value, and previous block voting message.

[0023] Furthermore, the method also includes:

[0024] When the consensus protocol is running, each replica node acts as a follower or leader, processing messages in the first and second states respectively, executing the rolling view protocol to reach consensus, and the leader's identity is transferred between replica nodes as the view is viewed.

[0025] If an honest replica node does not receive a valid proposal message before the timer expires, it enters the next round of the rolling view protocol, where the current leader is replaced and consensus is reached under the organization of the new leader.

[0026] After the new leader consensus protocol is completed, the replica node performs a view transition and enters the new view.

[0027] This invention also provides a communication device, including a memory, a processor, and a program stored in the memory and executable on the processor, wherein the processor executes the program to implement the consensus method described above.

[0028] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps in the consensus method described above.

[0029] The above-described technical solution of the present invention has at least the following beneficial effects:

[0030] The consensus method, communication device, and computer-readable storage medium provided in this invention provide a rolling view protocol for reaching consensus and performing view transitions. Consensus is achieved through proposals and voting, with a re-voting phase modifying the voting content, making the consensus process more flexible and efficient. After one round of consensus is completed, the view automatically transitions, and with a change of leader, a new leader executes a new round of the rolling view protocol. When the chain height is k, blocks at height k-2 can be safely committed.

[0031] The embodiments of the present invention simplify the consensus process and view transformation process while ensuring the original security. For each consensus process, a full node broadcast is removed, which reduces the consumption of communication resources and increases the transaction throughput. At the same time, the separate view transformation protocol is removed and the view transformation is integrated into the regular consensus process, which reduces the communication and computation of changing leaders and lowers the cost of the consensus protocol in dealing with malicious nodes. Attached Figure Description

[0032] Figure 1 This is a schematic diagram illustrating the consensus method flow provided in an embodiment of the present invention;

[0033] Figure 2 This diagram illustrates the execution flow of the conventional state protocol in the consensus method provided by this embodiment of the invention.

[0034] Figure 3 This diagram illustrates the block structure in the consensus method provided in this embodiment of the invention.

[0035] Figure 4 This diagram illustrates the node state transition in the consensus method provided in this embodiment of the invention. Detailed Implementation

[0036] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0037] The consensus system provided in this invention adopts a consortium blockchain architecture. This system has a relatively fixed number of members participating in the execution of the consensus protocol, and can tolerate no more than one-third of the members experiencing Byzantine faults. Members are connected via peer-to-peer communication, and each member controls a replica node. Replica nodes are divided into leaders and followers based on their roles. During the consensus process, this invention employs a rolling view model, selecting a leader from among the replica nodes in a cyclical manner. Each follower then becomes a leader in turn. The leader generates blocks by collecting votes and initiating proposals, controlling the consensus content. Other followers are responsible for verification, ultimately completing the consensus process.

[0038] The present invention includes a scrolling view protocol and three message types used in the execution of the consensus protocol, as well as the corresponding block structure.

[0039] The rolling view protocol is used to reach consensus and perform view transitions. Consensus is achieved through proposals and voting, and the voting content can be changed through a re-vote phase, making the consensus-reaching process more flexible and efficient. After a round of consensus is completed, the view automatically transitions, and with a change of leader, the new leader executes a new round of the rolling view protocol. When the chain height is k, a block at height k-2 can be safely committed.

[0040] Three types of messages are used for communication between nodes during protocol execution: proposal messages, voting messages, and re-vote messages. Proposal messages are essentially the block structure used in the blockchain. B k This is a block of height k, which organically combines the Byzantine fault-tolerant consensus algorithm with blockchain. The specific descriptions of the three message types are as follows:

[0041] Proposal message: The structure of the proposal message is as follows This is represented 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, and h... k-1It is the hash value of the previous block, specifically the hash value of the block at height k-1, used for block linking. It is the set of voting messages collected by the leader under view v regarding the previous block, used to prove that the proposal at height k-1 is valid after verification by more than two-thirds of the nodes. L This is the message publisher's signature for the message; L indicates the leader.

[0042] Voting message: in the shape of <vote,v+1,h k > r , represented as VOTE, where vote is the message type of the voting message, v+1 is the view number of the next view, used to identify the next view, h k It is the hash value of the current block, that is, the hash value of the block at height k, used to identify the block to which the vote points. r This is the message publisher's signature for the message, and 'r' refers to the replica node;

[0043] Resubmitted message: in the form of <recall,v,m> L This is represented as RECALL, where recall is the message type of the re-vote 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 that a re-vote is required. L It is the message publisher's signature for the message.

[0044] Specifically, such as Figure 1 , 2 As shown, an embodiment of the present invention provides a consensus method, the method comprising:

[0045] Step 101: Each member in the blockchain participating in the execution of the consensus protocol forms a network through peer-to-peer communication. The members include leaders and followers, and each member corresponds to a replica node.

[0046] Step 102: The consensus protocol includes a rolling view protocol, which selects a leader from the replica nodes in turn, so that each follower becomes the leader in turn;

[0047] The rolling view protocol includes: all replica nodes generating voting messages for blocks, sending the voting messages to the leader of the view, and starting a timer at the same time;

[0048] The leader of the view collects the voting messages of the block. If enough voting messages are collected within a certain period of time, a proposal message is generated based on the packaged transaction data and the voting messages, and the proposal message is broadcast.

[0049] After receiving the proposal message broadcast by the leader, the replica node adds the proposal message as a new block to the blockchain and securely commits the second block preceding the proposed block.

[0050] The scrolling view protocol executes immediately after the previous consensus protocol is completed, and its process is as follows: Figure 2 As shown, assuming that at the start of the protocol, all nodes are in view v-1 and the current block height is k-1,

[0051] 1) All replica nodes for block B k-1 Generate voting message VOTE= <vote,v,h k-1 > r The message is then sent to the leader L of view v, and a timer is started with a duration of t. If a proposal message PROPOSE is not received from the leader L of view v before the timer expires, a view transition begins, and a corresponding vote message VOTE′ is sent to the leader L′ of view v+1. <vote,v+1,h k > r A new round of scroll view protocols begins;

[0052] 2) The leader L of view v begins collecting data on block B. k-1 The voting message VOTE attempts to generate a proposal message. And broadcast, among which It includes the collected votes as proof of the legitimacy of the proposed message;

[0053] If not enough votes are collected within a certain time t′ (t′ should be less than the follower timer duration t), then the leader L generates a re-vote message RECALL based on the current block.<recall,v,m> L The re-vote message is broadcast to all replica nodes. If, compared to the block corresponding to the previous vote message, the block to be re-voted has (i) a higher hash value with the same block height and the same view, or (ii) a higher view with the same block height, or (iii) a higher block height, then the re-vote message is valid, and the replica nodes will resend the vote message VOTE″= to the leader based on the re-vote message.<vote,v,H(m)> r , where H(m) is the hash value of the block pointed to by m;

[0054] If enough voting messages are collected, the leader will then determine the order 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;

[0055] In other words, the leader of the above view collects the voting messages of the block. If the leader does not collect enough voting messages within a certain period of time, it generates a re-vote message based on the current block and broadcasts the re-vote message to all replica nodes.

[0056] If the block corresponding to the recast message has a higher hash value than the block corresponding to the previous voting message, under the same block height and the same view, or has a higher view or a higher block height under the same block height, then the recast message is valid.

[0057] The replica node resends the vote message to the leader based on the resend message.

[0058] 3) After receiving the PROPOSE message from the leader, the replica node will use the PROPOSE message as the new block B. k =PROPOSE is added to the blockchain, and the second block B preceding this block is also added. k-2 Submit securely.

[0059] Furthermore, if a replica node does not receive a proposal message broadcast by the leader of the view before the timer expires, it will perform a view transition, send the corresponding voting message to the leader of the next view, and start a new round of the rolling view protocol.

[0060] The block structure used in the blockchain of this embodiment is as follows: Among them B k It is a block of height k, where propose is the message type of the proposal message, d is the packaged transaction data, v is the current view number, and h is the block height k. k-1 It is the hash value of the previous block. It is the collection of voting messages for the previous block gathered by the leader under view v. L It is the signature of the message publisher for the proposed message, and L refers to the leader.

[0061] The block structure used in this invention is as follows: Figure 3 As shown, the block structure includes a block header and a block body. The block body includes message type, transaction data, current view number, previous block hash value, and previous block voting message.

[0062] During the actual operation of the protocol, the state transitions of nodes are as follows: Figure 4As shown in the diagram, when the system is running normally, each node acts as either a follower or a leader, processing messages in two states: the first node (labeled 1 in the diagram) and the second node (labeled 2 in the diagram). They execute the rolling view protocol, reach consensus, and switch views. The leader's role shifts among the replica nodes along with the view. However, if the leader acts maliciously, honest replica nodes, having not received a valid proposal message before the timer expires, will enter the next round of the rolling view protocol, move to the next view, and replace the current leader. Consensus is then achieved under the new leader's organization. Regardless of whether consensus is reached in this round of the protocol, the replica nodes will switch views after the round ends, entering the new view.

[0063] Regarding the potential for malicious node behavior during protocol execution, if a follower acts maliciously in the rolling view protocol by sending an incorrect voting message to the leader, the leader simply discards the message. Once at least 2f+1 valid voting messages have been collected, a proposal message can be broadcast to complete the rolling view protocol. If a leader acts maliciously by not broadcasting a proposal message or broadcasting an incorrect one, honest followers will re-enter the rolling view protocol and send a new voting message to the leader of the next view, who will then organize the consensus process. If there are consecutive malicious leaders, honest followers will continuously perform view switching, changing views and leaders until the leader completes the consensus protocol.

[0064] When the consensus protocol of this embodiment is running, each replica node acts as a follower or leader, processes messages in the first state and the second state respectively, executes the rolling view protocol to reach consensus, and the leader's identity is transferred between replica nodes as the view is viewed.

[0065] If an honest replica node does not receive a valid proposal message before the timer expires, it enters the next round of the rolling view protocol, where the current leader is replaced and consensus is reached under the organization of the new leader.

[0066] In addition, after the consensus protocol of the new leader is completed, the replica nodes will perform a view transition and enter the new view.

[0067] The embodiments of the present invention simplify the consensus process and view transformation process while ensuring the original security. For each consensus process, a full node broadcast is removed, which reduces the consumption of communication resources and increases the transaction throughput. At the same time, the separate view transformation protocol is removed and the view transformation is integrated into the regular consensus process, which reduces the communication and computation of changing leaders and lowers the cost of the consensus protocol in dealing with malicious nodes.

[0068] The following is an example of a normal consensus process in a rolling view protocol, where the number of nodes participating in consensus is 4, the number of fault-tolerant nodes is 1, node 0 is the previous leader, the current blockchain height is k-1, the view is v-1, the network condition is good, and the process is as follows:

[0069] 1) All replica nodes numbered 0 to 3 generate a voting message VOTE0 = regarding the next view v for the block at height k-1. <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. Send the message to the current leader 1, enter view v, and start the timer, setting the timer duration to t;

[0070] 2) Leader 1 collects and verifies the legitimacy of voting messages. After collecting three legitimate votes (VOTE0, VOTE1, VOTE2) from copies 0 to 2, with view v, the leader 1 sets the collected votes into a collection. Add the proposal message in the form of And broadcast the proposal message to all replica nodes;

[0071] 3) Upon receiving the PROPOSE message from leader 1, all replica nodes numbered 0 to 3 verify the validity of the message and set it as block B of height k. k =The PROPOSE is added to the blockchain, and block B at height k-2 is also added. k-2 As a secure commit of an already determined block.

[0072] At this point, all legitimate nodes have reached a consensus on the block at height k-2.

[0073] The following is an example of a view transition in a rolling view protocol due to leader failure or malicious behavior. The number of nodes participating in consensus is 4, and the number of fault-tolerant nodes is 1. Node 0 is the previous leader, and node 1 is a malicious node that refuses to send any messages. The current view number is v-1, and the current blockchain height is k-1. The process is as follows:

[0074] 1) Replica nodes numbered 0, 2, and 3 generate a voting message VOTE0 = for block at height k-1, with view v. <vote,v,h k-1 >0, VOTE2 = <vote,v,h k-1 >2,VOTE3= <vote,v,h k-1>3. Send the message to the current leader 1, enter view v, and start the timer, setting the timer duration to t;

[0075] 2) Replica nodes numbered 0, 2, and 3 did not receive a proposal message from leader 1 under view v before the timer expired. Therefore, the three replica nodes generated a vote message VOTE′0= about the block at height k-1 and view v+1. <vote,v+1,h k-1 >0, VOTE′2= <vote,v+1,h k-1 >2,VOTE'3= <vote,v+1,h k-1 >3. Send the message to the current leader 2, enter view v+1, and start a timer, setting the timer duration to t;

[0076] 3) Leader 2 collects and verifies the legitimacy of voting messages. After collecting three legitimate votes (VOTE′0, VOTE′2, and VOTE′3) from replicas 0, 2, and 3, with view v+1, the collected votes are set into a collection. Add the proposal message in the form of And broadcast the proposal message to all replica nodes;

[0077] 4) After receiving the PROPOSE message from leader 2, replica nodes numbered 0, 2, and 3 verify the validity of the message and set it as block B of height k. k =The PROPOSE is added to the blockchain, and block B at height k-2 is also added. k-2 As a secure commit of an already determined block.

[0078] As can be seen, this embodiment of the invention integrates the view transition protocol into routine operations. Each node takes turns initiating at most one valid block proposal, simplifying the view transition process in the Byzantine algorithm when a leader node fails or acts maliciously. By combining the Byzantine fault tolerance capability with the chain structure of blocks, the consensus protocol processes newly generated block proposals in a pipeline manner. Moreover, the proposed new block structure includes the view in which the block was proposed and a set of valid signatures for the previous block, used to self-verify its legitimacy. A voting message type is designed, allowing nodes to change their votes when they receive block proposals with larger views, higher heights, or larger hash values.

[0079] This invention also provides a communication device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the various processes in the consensus method embodiments described above and achieves the same technical effect. To avoid repetition, it will not be described again here.

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

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

[0082] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 A device for one or more processes and / or the functions specified in one or more boxes.

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

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

[0085] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A consensus method, characterized in that, The method includes: Each member in the blockchain that participates in executing the consensus protocol forms a network through peer-to-peer communication. The members include leaders and followers, and each member corresponds to a replica node. The consensus protocol includes a rolling view protocol, which selects a leader from the replica nodes in turn, so that each follower becomes a leader in turn. The rolling view protocol includes: all replica nodes generating voting messages for blocks. Send the voting message to the leader of the view and start a timer; The leader of the view collects the voting messages of the block. If enough voting messages are collected within a certain period of time, a proposal message is generated based on the packaged transaction data and the voting messages, and the proposal message is broadcast. After receiving the proposal message broadcast by the leader, the replica node adds the proposal message as a new block to the blockchain and securely commits the second block preceding the proposed block.

2. The method according to claim 1, characterized in that, The method further includes: If the leader fails to collect enough votes within a certain period of time, it generates a re-vote message based on the current block and broadcasts the re-vote message to all replica nodes. If the block corresponding to the re-vote message has a higher hash value than the block corresponding to the previous voting message under the same block height and the same view, or has a higher view or a higher block height under the same block height, then the re-vote message is valid. The replica node resends the vote message to the leader based on the resend message.

3. The method according to claim 1, characterized in that, If the replica node does not receive a proposal message broadcast by the leader of the view before the timer expires, it will perform a view transition, send the corresponding voting message to the leader of the next view, and start a new round of the rolling view protocol.

4. The method according to claim 2, characterized in that, The proposal message is ,in It is a message type for a proposal message. It is packaged transaction data. It is the current view number. It is the hash value of the previous block. It is a view collected by the leader. The next set of voting messages for the previous block, It is the message publisher's signature on the proposed message. Refers to a leader; The voting message is ,in It is the message type for voting messages. It is the view number of the next view. It is the hash value of the current block. It is the signature of the message publisher for the voting message. Refers to replica nodes; The re-cast message is , represented as ,in It is a message type for resending messages. It is the current view number. It is a proposal message awaiting a vote. It is the signature of the message publisher for the resend message.

5. The method according to claim 1, characterized in that, The blockchain uses a block structure of... ,in Is the height as The block, It is the message type of the proposed message. It is packaged transaction data. It is the current view number. It is the hash value of the previous block. Is the leader in the view The collection of voting messages for the previous block. It is the message publisher's signature on the proposed message. Refers to a leader.

6. The method according to claim 5, characterized in that, The block structure includes a block header and a block body. The block body includes message type, transaction data, current view number, previous block hash value, and previous block voting message.

7. The method according to claim 1, characterized in that, The method further includes: When the consensus protocol is running, each replica node acts as a follower or leader, processing messages in the first and second states respectively, executing the rolling view protocol to reach consensus, and the leader's identity is transferred between replica nodes as the view is viewed. If an honest replica node does not receive a valid proposal message before the timer expires, it enters the next round of the rolling view protocol, where the current leader is replaced and consensus is reached under the organization of the new leader.

8. The method according to claim 7, characterized in that, After the consensus protocol for the new leader is completed, the replica node performs a view transition and enters the new view.

9. A communication device, comprising a memory, a processor, and a program stored in the memory and executable on the processor; characterized in that, When the processor executes the program, it implements the consensus method as described in any one of claims 1 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps in the consensus method as described in any one of claims 1 to 8.

Images