View switching method in PBFT algorithm, consensus node and blockchain system

Abstract

One or more embodiments of the present application provide a view switching method in a PBFT algorithm, a consensus node, and a blockchain system. The method is applied to any target consensus node in a blockchain system, and comprises: in response to a current round of consensus meeting a ViewChange condition, receiving a ViewChange message sent by another consensus node, the ViewChange message comprising a first block number of a latest block having passed consensus of the other consensus node, and a consensus proof of the latest block; in response to the received ViewChange message sent by the other consensus node, determining whether a second block number of the latest block having passed consensus of a current node is lower than the first block number comprised by the ViewChange message; and if the second block number is lower than the first block number, synchronizing a consensus proof of a first target block to the other consensus node, and storing the consensus proof of the first target block locally, the first target block being a block having a block number higher than the second block number and not higher than the first block number.

Description

View switching method, consensus node and blockchain system in PBFT algorithm Technical Field

[0001] One or more embodiments of the present application relate to the field of blockchain technology, and in particular to a view switching method, consensus node, and blockchain system in a PBFT algorithm. Background Art

[0002] Blockchain is a novel application model for computer technologies such as distributed data storage, peer-to-peer transmission, consensus protocols, and encryption algorithms. In a blockchain system, data blocks are linked sequentially in chronological order to form a chain-like data structure, cryptographically guaranteeing an unalterable and unforgeable distributed ledger. Due to its decentralized, tamper-proof, and autonomous nature, blockchain applications are becoming increasingly widespread.

[0003] Summary of the Invention

[0004] One or more embodiments of the present application provide a view switching method, consensus node, and blockchain system in a PBFT algorithm, including: The present application provides a view switching method in a PBFT algorithm, the method being applied to any target consensus node in a blockchain system, including: in response to a ViewChange condition being satisfied in a current round of consensus, receiving a ViewChange message sent by another consensus node; wherein the ViewChange message includes the first block number of the latest block that has been consensus-approved by the other consensus nodes, and a consensus-passing certificate for the latest block; in response to the received ViewChange message sent by the other consensus node, determining whether the second block number of the latest block that has been consensus-approved by the current node is less than the first block number included in the ViewChange message; if the second block number is less than the first block number, synchronizing the consensus-approving certificate of the first target block with the other consensus nodes, and locally storing the consensus-approving certificate of the first target block; wherein the first target block is a block having a block number greater than the second block number and not greater than the first block number.

[0005] The present application also provides a consensus node, which is any target consensus node in a blockchain system, comprising: a first receiving unit, which receives a ViewChange message sent by other consensus nodes in response to the current round of consensus satisfying a ViewChange condition; wherein the ViewChange message includes the first block number of the latest block that has been consensus-approved by the other consensus nodes, and a consensus pass certificate of the latest block; a first determining unit, which determines, in response to the received ViewChange message sent by the other consensus nodes, whether the second block number of the latest block that has been consensus-approved by the current node is less than the first block number included in the ViewChange message; a first synchronization unit, which synchronizes the consensus pass certificate of the first target block to other consensus nodes if the second block number is less than the first block number, and stores the consensus pass certificate of the first target block locally; wherein the first target block is a block number greater than the second block number and not greater than the first block number.

[0006] The present application also provides a blockchain system, comprising multiple consensus nodes, wherein: any target consensus node receives a ViewChange message sent by other consensus nodes in response to the ViewChange condition being satisfied in the current round of consensus; wherein the ViewChange message includes the first block number of the latest block that has been consensus-approved by the other consensus nodes, and a consensus-approved certificate of the latest block; the target consensus node determines, in response to the received ViewChange message sent by the other consensus nodes, whether the second block number of the latest block that has been consensus-approved by the node itself is less than the first block number included in the ViewChange message; if the second block number is less than the first block number, the target consensus node synchronizes the consensus-approved certificate of the first target block with the other consensus nodes, and stores the consensus-approved certificate of the first target block locally; wherein the first target block is a block whose block number is greater than the second block number and not greater than the first block number.

[0007] In the above embodiment, during the consensus process for transactions included in a block, if a consensus node has completed consensus for the block before the view switch due to a faster consensus progress (i.e., it has collected 2f+1 Commit messages corresponding to the block), then during the View Change phase, the node can carry the locally stored consensus proof for the block (including the collected 2f+1 Commit messages corresponding to the block) in the ViewChange message and broadcast it to other consensus nodes. Upon receiving the ViewChange message, the other consensus nodes can store the consensus proof for the block contained in the ViewChange message locally. Through this synchronization mechanism, consensus nodes with slower consensus progress can catch up with consensus nodes with faster consensus progress during the View Change phase, thereby ensuring the synchronization of consensus progress among the various consensus nodes. After the view is switched, the new master node will rebroadcast the Pre-Prepare message corresponding to the block to re-initiate consensus on the transactions contained in the block. At this time, because each consensus node has synchronized with the latest consensus proof, if the consensus proof of the block is stored locally, the Prepare message corresponding to the Pre-Prepare message will no longer be returned, thus terminating repeated voting. In this way, even if the consensus node configuration is updated, since repeated voting will no longer occur, there will be no anomalies during the re-consensus. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments recorded in this application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0009] FIG1 is a schematic diagram of a blockchain system according to an exemplary embodiment of the present application;

[0010] FIG2 is a schematic diagram of a conventional phase in a PBFT algorithm shown in an exemplary embodiment of the present application;

[0011] FIG3 is a schematic diagram of a view switching phase in a PBFT algorithm shown in an exemplary embodiment of the present application;

[0012] FIG4 is a flowchart of a view switching method in a PBFT algorithm shown in an exemplary embodiment of the present application;

[0013] FIG5 is a schematic structural diagram of a device shown in an exemplary embodiment of the present application;

[0014] FIG6 is a schematic diagram of the architecture of a consensus node in a blockchain network shown in an exemplary embodiment of the present application. DETAILED DESCRIPTION

[0015] In order to enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0016] Blockchains are generally categorized into three types: public, private, and consortium. Furthermore, combinations of these types are possible, such as combining private and consortium blockchains, or combining consortium and public blockchains.

[0017] Of the three types of blockchains mentioned above, public chains are the most decentralized. Participants in a public chain (also known as nodes in the blockchain) can access data records on the chain, participate in transactions, and compete for the right to record new blocks. Furthermore, each node can freely join and leave the network and perform related operations.

[0018] In contrast, private blockchains control write permissions to the network by a specific organization or institution, while data read permissions are regulated by that organization. In other words, private blockchains can be considered weakly centralized systems, with strict node restrictions and a small number of nodes. This type of blockchain is more suitable for internal use within a specific organization.

[0019] Consortium blockchains lie somewhere between public and private blockchains, enabling partial decentralization. Each node in a consortium blockchain typically has a corresponding entity or organization; nodes are authorized to join the network and form a coalition of stakeholders to jointly maintain the blockchain's operations.

[0020] Please refer to Figure 1, which is a schematic diagram of a blockchain system shown in an exemplary embodiment of the present application.

[0021] As shown in Figure 1, a blockchain system can maintain one or more blockchains (e.g., public blockchains, private blockchains, consortium blockchains, etc.) and can include multiple blockchain nodes for hosting these one or more blockchains. For example, blockchain nodes 1, 2, 3, 4, and i, as shown in Figure 1, can collectively host one or more blockchains. Cross-chain data access is also possible between the blockchains within each blockchain system, and between blockchain systems.

[0022] A blockchain node is a logical communication entity; multiple blockchain nodes of different types can run on the same physical server or on different physical servers. In one embodiment, a blockchain node can be a physical device or a virtual device implemented in a server or server cluster. For example, a blockchain node can be a physical host in a server cluster, or a virtual machine created by virtualizing the hardware resources of a server or server cluster using virtualization technology. Each blockchain node can be coupled together through various communication methods (e.g., TCP / IP) to form a network that can host one or more blockchains.

[0023] Based on the basic characteristics of blockchain, a blockchain is typically composed of several blocks. Each of these blocks is timestamped to indicate the moment of its creation. All blocks strictly follow the timestamps recorded in the blocks, forming a temporally ordered data chain.

[0024] For data generated outside the blockchain, this data can be constructed into a standard transaction format supported by the blockchain and then published to the blockchain. The nodes participating in the consensus in the blockchain system will reach a consensus on the transaction and execute the transaction after the consensus is reached, so that the transaction and the execution results can be persistently stored in the blockchain.

[0025] In a blockchain system, different participants can establish a distributed blockchain network through deployed nodes. A decentralized (or multi-centralized) distributed ledger, constructed using a chained block structure, is stored on each node (or a majority of nodes, such as consensus nodes) within the distributed blockchain network. This type of blockchain system must address the consistency and correctness of ledger data across multiple nodes within the decentralized (or multi-centralized) network. Each node in the blockchain system runs a blockchain program. Under certain fault-tolerance requirements, a consensus protocol ensures that all loyal nodes have the same transactions, ensuring consistent execution results for the same transactions. Transactions and execution results are then packaged and generated into blocks.

[0026] Specifically, consensus nodes in a blockchain system can reach consensus on the transactions contained in a new block to be connected to the chained block structure based on a consensus protocol, ensuring that all consensus nodes agree on the content and order of the transactions contained in the block, thereby achieving the construction of the block. After reaching consensus, the consensus node can send the constructed block to other nodes, so that each node can execute the transactions contained in the block in order. After confirming that the transaction execution results of each node are consistent, the block is finalized. Among them, finalization refers to the completion of the execution of the transactions contained in the block and the acceptance of the transaction execution results by all nodes (or a certain number of nodes, such as two-thirds of the nodes).

[0027] Current mainstream consensus protocols include Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), Practical Byzantine Fault Tolerance (PBFT), and HoneyBadgerBFT. These consensus protocols can generally be categorized as asynchronous and non-asynchronous. For example, PBFT is a semi-synchronous protocol, while HoneyBadgerBFT is an asynchronous protocol.

[0028] Take the PBFT algorithm, for example. Proposed by Miguel Castro and Barbara Liskov in 1999, it addresses the inefficiency of the original Byzantine fault-tolerance algorithm, reducing its complexity from exponential to polynomial, making it feasible for practical system applications. The paper was presented at the 1999 International Conference on Operating Systems Design and Implementation (OSDI99). In the PBFT algorithm, all replicas operate within a succession of configurations called views. Within a view, one replica serves as the primary, while the others serve as backups. Views are consecutively numbered integers. The primary is calculated using the formula p = v mod |R|, where v is the view number, p is the replica number, and |R| is the number of replicas. The algorithm assumes that, when at most f replicas (i.e., nodes) fail, safety and liveness are guaranteed in an asynchronous system if a total of at least 3f + 1 replicas remain. The set of replicas required to ensure data consistency and fault tolerance across all replicas is typically a majority of the nodes in the distributed system, forming a quorum. For example, if the total number of nodes n is 3f+1 (n=3f+2 or n=3f generally does not improve fault tolerance), the quorum is 2f+1. Thus, for a distributed system with four nodes, any three nodes can form a quorum.

[0029] The PBFT algorithm consists of two processes: the Normal Case Phase and the View Change Phase. Figure 2 illustrates the Normal Case Phase. The Normal Case Phase primarily includes three phases: PRE-PREPARE, PREPARE, and COMMIT. Node 3, for example, represents a downed node (indicated by an "X" in Figure 2). When the primary node fails, a View Change process must be initiated to adjust the system state and replace the primary node with a new one. Figure 3 illustrates the View Change Phase. If the primary node goes offline or acts maliciously and does not broadcast client requests, the client can set a timeout mechanism. If the timeout expires, the client can broadcast a request message to all replica nodes. If a replica node detects that the primary node is acting maliciously or is offline, it can also initiate a View Change Phase to replace the primary node (often referred to as "master replacement"). Furthermore, the three-phase consensus process of PRE-PREPARE, PREPARE, and COMMIT may fail due to an erroneous proposal from the master node. Alternatively, the quorum (e.g., 2f+1 out of 3f+1 nodes, also known as the legal number) may not be reached during the PREPARE and COMMIT phases, preventing consensus. In these cases, the View Change Phase may be initiated to replace the master node. For example, if the master node for view v is replica 0, after the view change, replica 1 becomes the new master node, meaning that the master node for view v+1 is replica 1.

[0030] The PBFT algorithm is a semi-synchronous protocol, assuming the network is initially asynchronous but capable of synchronization from a certain point in time. The simplest way to ensure consensus on the same proposal among different nodes in the network is to establish a master node, which unifies the opinions of all nodes. Setting a timer prevents master node errors. In the PBFT algorithm, if the Normal Case Phase fails to complete within a limited time, the Backups initiate the View Change Phase to replace the master node. The PBFT algorithm fixes the master node in one location, allowing all requests to be sent to the master node first, which then broadcasts them to other consensus nodes.

[0031] In single-master protocols like PBFT, only the master can initiate consensus proposals during a consensus process; other nodes are unable to do so. Alternatively, if other nodes have proposals, they must forward them to the master, who will initiate the proposal on their behalf.

[0032] Specifically, in a blockchain system using the PBFT algorithm as its consensus protocol, if a new master node needs to be replaced, the view switch phase begins. In this blockchain system, each consensus node can send a ViewChange message to other consensus nodes, proposing a view switch. The new master node can be calculated using the formula p = v + 1 mod |R|, where v + 1 represents the next view after the view switch. After collecting 2f + 1 ViewChange messages, the new master node sends a NewView message to the other consensus nodes. Once the other consensus nodes accept the NewView message, the view switch is complete.

[0033] In the related art, during the consensus process for the transactions included in a certain block, there is a situation where one or more consensus nodes have completed the consensus for the block before the view is switched because of the fast consensus progress (i.e., 2f+1 Commit messages corresponding to the block have been collected), but other consensus nodes have not yet completed the consensus for the block (i.e., 2f+1 Commit messages corresponding to the block have not yet been collected). At this time, it is considered that the block has not yet reached a consensus, that is, the block has not yet been successfully produced. In this case, after the view is switched, the new master node will re-initiate the consensus for the transactions included in the block, and each consensus node will vote on the block. If the configuration of some consensus nodes is updated during the re-consensus process (for example: node changes, key updates, etc.), it will cause anomalies during the re-consensus, resulting in the failure of the consensus on the block.

[0034] Please refer to FIG4 , which is a flowchart of a view switching method in a PBFT algorithm shown in an exemplary embodiment of the present application.

[0035] The present application provides an embodiment of a view switching method in a PBFT algorithm. In this embodiment, the PBFT algorithm can be used as a consensus protocol for a blockchain system, and the view switching method in the PBFT algorithm can be applied to any consensus node (referred to as a target consensus node) in the blockchain system.

[0036] As shown in FIG4 , the view switching method in the PBFT algorithm may specifically include steps 402 to 406 .

[0037] Step 402: In response to the current round of consensus satisfying the ViewChange condition, receiving a ViewChange message sent by other consensus nodes; wherein the ViewChange message includes the first block number of the latest block that has been agreed upon by the other consensus nodes, and a consensus certificate for the latest block.

[0038] In this embodiment, as previously described, when the master node fails, the view change process must be initiated. During this view change phase, each node in the blockchain system can send a ViewChange message to other nodes. Therefore, when the master node fails, the current round of consensus is deemed to have met the ViewChange condition. Any consensus node in the aforementioned blockchain system can, in response to the ViewChange condition being met in the current round of consensus, send a ViewChange message to other consensus nodes in the blockchain system. In other words, the target consensus node can receive ViewChange messages from other consensus nodes in the blockchain system in response to the ViewChange condition being met in the current round of consensus.

[0039] For any consensus node in the aforementioned blockchain system, the ViewChange message sent by that consensus node to other consensus nodes in the blockchain system may include the block number of the latest block that the consensus node has agreed upon, as well as proof of consensus on the latest block. In other words, the ViewChange message received by the target consensus node from another consensus node in the blockchain system may include the block number of the latest block that the other consensus node has agreed upon (referred to as the first block number) and proof of consensus on the latest block.

[0040] In some embodiments, the target consensus node may send a ViewChange message to other consensus nodes in the blockchain system in response to the current consensus round satisfying the ViewChange condition. The ViewChange message may include the block number (referred to as the second block number) of the latest block on which the current node (i.e., the target consensus node) has reached consensus, as well as a proof of consensus on the latest block.

[0041] In practical applications, a block's consensus proof can include 2f+1 commit messages corresponding to the block and their signatures. Here, f represents the fault tolerance threshold of the PBFT algorithm for consensus nodes in the blockchain system. If a consensus node locally stores a block's consensus proof, it means that the consensus node has received and verified 2f+1 commit messages corresponding to the block, meaning that the block has been agreed upon by the consensus node.

[0042] On the other hand, the block number of a block may be the block height of the block.

[0043] In a blockchain, the block height refers to the number of blocks connected in the chained block structure. However, for any block in a blockchain, its block height can be used as an identifier. Blocks are generally considered to have two identifiers: a hash value of the block header and a block height. The block header hash value is obtained by performing a secondary hash calculation on the block header using algorithms such as the SHA256 algorithm. The block header hash value uniquely identifies a block, and any node in the blockchain system can independently obtain the block header hash value by hashing the block header. The block height refers to the position of a block in the blockchain; it is not a unique identifier for a block. Although a block always has a clear and fixed block height, it does not always identify a single block. Two or more blocks may have the same block height, competing for the same position in the blockchain.

[0044] Blocks in a blockchain are typically linked chronologically in a chained block structure, effectively creating a temporally ordered chain. In this case, block heights are typically set to ascending values. For example, if the block height of the previous finalized block is h, the next block to be agreed upon will have a block height of h+1, and so on.

[0045] It should be noted that the block number of the latest block that a consensus node has agreed upon can also be called the checkpoint of the consensus node.

[0046] In some embodiments, a ViewChange message sent by a consensus node can be represented as<VIEWCHANGE,v+1,h,pset,qset,nodeid,sig,proof> Where v represents the current view, v+1 represents the next view after switching, h represents the checkpoint of the consensus node, pset is the block with a block number greater than h and has completed the PREPARE phase (i.e., 2f+1 Prepare messages corresponding to the block and their signatures have been received), qset is the block with a block number greater than h and has completed the PRE-PREPARE phase (i.e., 2f+1 Pre-Prepare messages corresponding to the block and their signatures have been received), sig is the signature of all the previous fields, and proof is the consensus proof of the block with block number h.

[0047] Step 404: In response to the received ViewChange message sent by the other consensus node, determine whether the second block number of the latest block that has been agreed upon by the current node is smaller than the first block number included in the ViewChange message.

[0048] In this embodiment, upon receiving a ViewChange message from any other consensus node in the blockchain system, the target consensus node may determine, in response to the ViewChange message, whether the block number (referred to as the second block number) of the latest block on which the target consensus node (i.e., the target consensus node) has agreed is smaller than the first block number included in the ViewChange message. In this case, the first block number is the block number of the latest block on which the other consensus node has agreed.

[0049] For example, assuming that the target consensus node is consensus node A, the block number of the latest block that consensus node A has agreed upon (i.e., the second block number) is block number A, and the block number of the latest block that consensus node X in the blockchain system has agreed upon (i.e., the first block number) is block number X, then when consensus node A receives a ViewChange message sent by consensus node X, it can determine whether block number A is less than block number X in response to the ViewChange message.

[0050] Step 406: If the second block number is smaller than the first block number, synchronize the consensus proof of the first target block to other consensus nodes, and store the consensus proof of the first target block locally; wherein the first target block is a block with a block number greater than the second block number and not greater than the first block number.

[0051] In this embodiment, if the second block number is smaller than the first block number, then the target consensus node's local consensus proof corresponds to the second block number, meaning the target consensus node does not have a local consensus proof for a block with a block number greater than the second block number and not greater than the first block number. However, the other consensus nodes have local consensus proofs corresponding to the first block number, meaning the other consensus nodes have local consensus proofs for blocks with a block number greater than the second block number and not greater than the first block number. Therefore, the target consensus node can synchronize the consensus proofs of certain blocks (referred to as first target blocks) with the other consensus nodes and store the consensus proofs of the first target blocks locally. The first target block is a block with a block number greater than the second block number and not greater than the first block number (i.e., the second block number < block number ≤ the first block number). It should be noted that all blocks whose block numbers are greater than the second block number and not greater than the first block number can be used as the first target block.

[0052] Continuing with the above example, if block number A is less than block number X, consensus node A can synchronize the consensus proof of the first target block to consensus node A and store the consensus proof of the first target block locally. In this case, the first target block can be any block whose block number is greater than block number A and not greater than block number X (i.e., block number A < block number ≤ block number X).

[0053] In some embodiments, after synchronizing to the consensus proof of the first target block, the target consensus node may determine whether a Pre-Prepare message for the first target block exists locally. For example, based on the block number of the first target block, the target consensus node may determine whether a Pre-Prepare message corresponding to the block number of the first target block is stored locally. If the Pre-Prepare message for the first target block does not exist locally, the target consensus node may synchronize the Pre-Prepare message for the first target block with the other consensus nodes in the blockchain system, i.e., synchronize the original content of the transactions contained in the first target block with the other consensus nodes. If the Pre-Prepare message for the first target block is not synchronized, the target consensus node only has the consensus proof of the first target block locally, which only proves that the target consensus node has reached consensus on the first target block. However, the target consensus node lacks the relevant information of the transactions contained in the first target block locally, resulting in the inability to execute the transactions contained in the first target block normally.

[0054] In some embodiments, as previously described, the ViewChange message received by the target consensus node from another consensus node in the blockchain system may include a consensus certificate for the latest block agreed upon by the other consensus node. Therefore, upon receiving a ViewChange message from any other consensus node in the blockchain system, the target consensus node may also, in response to the ViewChange message, locally store the consensus certificate included in the ViewChange message. In this case, the consensus certificate is the consensus certificate for the latest block agreed upon by the other consensus node.

[0055] That is, the target consensus node can directly store locally the consensus proof of the latest block that has been agreed upon by the other consensus node, which is included in the ViewChange message sent by the other consensus node. In this case, the target consensus node will no longer synchronize the consensus proof of the latest block with the other consensus node. Instead, it will only synchronize the consensus proof of blocks with block numbers greater than the second block number and less than the block number of the latest block that has been agreed upon by the other consensus node (i.e., the first block number). This can reduce the amount of data transmission between the target consensus node and the other consensus node, and improve the synchronization efficiency of the consensus progress of the block.

[0056] In some embodiments, before sending a ViewChange message to other consensus nodes in the blockchain system, the target consensus node may first receive a ViewChange message from another consensus node in the blockchain system and locally store the consensus proof of the latest block that the other consensus node has agreed upon, as contained in the ViewChange message. In this case, before sending the ViewChange message to other consensus nodes in the blockchain system, the target consensus node may first determine whether there exists a set of locally stored consensus proofs with corresponding block numbers that continuously increase relative to the second block number. If so, the target consensus node may further determine the maximum block number among the block numbers corresponding to the consensus proofs in the set of consensus proofs and update the second block number based on the maximum block number. This implements a check mechanism before a consensus node sends a ViewChange message, ensuring that the checkpoint contained in a ViewChange message sent by a consensus node reflects the consensus node's true consensus progress.

[0057] For example, assuming that the block number of the latest block that the target consensus node has agreed upon (i.e., the second block number) is 10, then under normal circumstances, the target consensus node locally stores the consensus certificates for the 10 blocks with block numbers 1 to 10. If the target consensus node also receives ViewChange messages from three other consensus nodes in the blockchain system, and the consensus certificates contained in these three ViewChange messages are respectively the consensus certificate for the block with block number 11, the consensus certificate for the block with block number 12, and the consensus certificate for the block with block number 14, then the target consensus node can also store these three consensus certificates locally. That is, at this time, the target consensus node locally stores the consensus certificates for 13 blocks with block numbers 1 to 12 and block number 14. Since the consensus proofs stored locally on the target consensus node include a set of consensus proofs whose corresponding block numbers continuously increase relative to the second block number (i.e., a set consisting of the consensus proofs for the block with block number 11 and the consensus proofs for the block with block number 12), it can be further determined that the maximum block number among the block numbers corresponding to the consensus proofs in the consensus proof set is 12, and the second block number is updated from 10 to 12. This indicates that the block number of the latest block that has been consensus-approved by the target consensus node has been updated to the maximum block number, and the consensus proof of the latest block that has been consensus-approved by the target consensus node has been updated to the consensus proof corresponding to the block number of the maximum block number.

[0058] It should be noted that after the target consensus node updates the second block number, any subsequent ViewChange messages sent by the target consensus node to other consensus nodes in the blockchain system may include the new second block number and the consensus certificate corresponding to the new second block number. Furthermore, when synchronizing the consensus certificate of a block with another consensus node in the blockchain system, the target consensus node may only synchronize the consensus certificate for blocks whose block numbers are greater than the new second block number and no greater than the block number of the most recent block that has been consensus-approved by the other consensus node (i.e., the first block number).

[0059] For any consensus node in the above blockchain system, by updating the block number of the latest block that has been agreed upon by the consensus node, when synchronizing the consensus proof of the block between the various nodes in the blockchain system, the data transmission volume between the consensus node and other consensus nodes in the blockchain system can be reduced, thereby improving the synchronization efficiency of the consensus progress of the block.

[0060] In the above embodiment, during the consensus process for transactions included in a block, if a consensus node has completed consensus for the block before the view switch due to a faster consensus progress (i.e., it has collected 2f+1 Commit messages corresponding to the block), then during the View Change phase, the node can carry the locally stored consensus proof for the block (including the collected 2f+1 Commit messages corresponding to the block) in the ViewChange message and broadcast it to other consensus nodes. Upon receiving the ViewChange message, the other consensus nodes can store the consensus proof for the block contained in the ViewChange message locally. Through this synchronization mechanism, consensus nodes with slower consensus progress can catch up with consensus nodes with faster consensus progress during the View Change phase, thereby ensuring the synchronization of consensus progress among the various consensus nodes. After the view is switched, the new master node will rebroadcast the Pre-Prepare message corresponding to the block to re-initiate consensus on the transactions contained in the block. At this time, because each consensus node has synchronized with the latest consensus proof, if the consensus proof of the block is stored locally, the Prepare message corresponding to the Pre-Prepare message will no longer be returned, thus terminating repeated voting. In this way, even if the consensus node configuration is updated, since repeated voting will no longer occur, there will be no anomalies during the re-consensus.

[0061] In some embodiments, taking any other consensus node other than the target consensus node in the blockchain system as an example, when the target consensus node synchronizes the consensus proof of the first target block to the other consensus node and locally stores the consensus proof of the first target block, it can first construct a synchronization request message and send the synchronization request message to the other consensus node. The synchronization request message can include the second block number (i.e., the block number of the latest block that the target consensus node has already agreed upon) and the first block number (i.e., the block number of the latest block that the other consensus node has already agreed upon). Upon receiving the synchronization request message, the other consensus node can respond to the synchronization request message by constructing a synchronization response message corresponding to the synchronization request message and return the synchronization response message to the target consensus node. The synchronization response message can include the consensus proof of the first target block (i.e., the block whose block number is greater than the second block number and not greater than the first block number). Accordingly, the target consensus node can obtain the synchronization response message returned by the other consensus node, and in response to the synchronization response message, store the consensus proof of the first target block contained in the synchronization response message locally.

[0062] In some embodiments, the synchronization request message sent by a consensus node to another consensus node may be a FetchCheckPointProof message, represented as<FETCHCHECKPOINTPROOF,begin,end> Wherein, begin indicates the checkpoint of the consensus node plus 1, and end is h in the ViewChange message sent by the other consensus node received by the consensus node (i.e., the checkpoint of the other consensus node). Accordingly, the synchronous response message returned by the other consensus node to the consensus node can be a CheckPointProof message, which is expressed as<CHECKPOINTPROOF,proofvector> Among them, proofvector stores the consensus proof of all blocks from block number begin to end.

[0063] The target consensus node sends a synchronization request message to other consensus nodes, and the other consensus nodes return a synchronization response message corresponding to the synchronization request message to the target consensus node. This allows the target consensus node to synchronize the consensus proof of blocks that it does not have from other consensus nodes according to its own needs, thereby ensuring that the target consensus node is synchronized with other consensus nodes on the consensus progress of the blocks.

[0064] In some embodiments, any consensus node in the aforementioned blockchain system, upon receiving a ViewChange message from another consensus node in the blockchain system, can not only synchronize the consensus proof of the block with the other consensus nodes, but can also initiate a view switch upon receiving at least 2f+1 ViewChange messages (including ViewChange messages generated by itself). First, the consensus node can determine whether it has been elected as the new master node after the view switch. For example, this can be calculated using the formula p=v+1mod|R| to determine whether the node is the new master node after the view switch.

[0065] If the target consensus node determines that the current node is elected as the new master node after the view switch, the target consensus node can determine the starting block number h from the block numbers contained in at least 2f+1 ViewChange messages received by the current node.

[0066] It should be noted that for all consensus nodes in the aforementioned blockchain system, the block number contained in the ViewChange message sent by at least one honest node among these consensus nodes is no less than the aforementioned starting block number h. In other words, the blockchain system must contain at least one honest node whose most recent consensus-agreed block number is no less than the starting block number h. If an honest node in the blockchain system reaches consensus on a block, it is assumed that all other consensus nodes in the blockchain system will also reach consensus on that block. Therefore, for any block with a block number less than the starting block number h, it can be assumed that all consensus nodes in the blockchain system will reach consensus on that block. In this case, the starting block number h can be considered an honest and reliable checkpoint, and can therefore be used as the basis for decision-making.

[0067] Because the target consensus node can also synchronize consensus proofs of blocks with other consensus nodes while collecting ViewChange messages, it can determine the final checkpoint based on the consensus proofs of the synchronized blocks. Specifically, once the starting block number h is determined, the target consensus node can determine whether there exists a set of consensus proofs in its locally stored consensus proofs whose block numbers continuously increase relative to the starting block number h. If so, it can further determine the maximum block number among the block numbers corresponding to the consensus proofs in the set, and determine this maximum block number as the ending block number H corresponding to the starting block number h.

[0068] After determining the starting block number h and the ending block number H, the target consensus node may send a NewView message to other consensus nodes in the blockchain system. The NewView message may include the ending block number H and a mapping relationship between each block number in the interval [h, H] and the consensus proof of the corresponding block (i.e., one block number corresponds to one consensus proof).

[0069] In some embodiments, the NewView message sent by the new master node after the view switch can be expressed as<NEWVIEW,v+1,h,proofmap,vset,xset> Where h represents the final checkpoint determined by the new master node, proofmap is a mapping of each block number in the range from the basic checkpoint determined by the new master node to h (i.e., the final checkpoint determined by the new master node) to the proof of the corresponding block, vset is the 2f+1 ViewChange messages received, and xset is the block number in the interval (h, h+L] for which consensus has not yet been reached; L is the maximum number of parallel consensus instances (also known as the length of the consensus window).

[0070] For a block with block number k (h < k ≤ h + L), the block can be placed in the aforementioned xset if it meets any of the following three conditions: 1. The checkpoints contained in the received 2f + 1 ViewChange messages are all smaller than k, and the pset contained in each ViewChange message contains block k; or, the checkpoints contained in the received 2f + 1 ViewChange messages are all smaller than k, and the view numbers of all blocks in the pset contained in each ViewChange message are smaller than the view number of block k.

[0071] 2. At least f+1 of the 2f+1 ViewChange messages received contain block k in their qset.

[0072] 3. Block k is a block that has not yet been agreed upon by the new master node (i.e., it has not received 2f+1 Commit messages corresponding to block k).

[0073] For block k that does not meet the above three conditions, the new master node can assume that the transactions contained in the block are constructed by a malicious node, so the transactions contained in the block can be cleared and then put into the above xset.

[0074] In other words, the above three conditions can also be regarded as the legitimacy verification rules for blocks that have not yet reached consensus.

[0075] In some embodiments, for a blockchain system using the PBFT algorithm as its consensus protocol, the number of consensus nodes in the blockchain system can be expressed as 3f+1, where there are at least 2f+1 honest nodes and at most f malicious nodes, where f represents the PBFT algorithm's fault tolerance threshold for consensus nodes. In this case, when determining the starting block number h from the block numbers contained in at least 2f+1 received ViewChange messages, the target consensus node may specifically sort the block numbers contained in the at least 2f+1 ViewChange messages received by the node in descending order and obtain the f+1th block number from the sorted block numbers as the starting block number h.

[0076] In some embodiments, before determining whether there is a corresponding set of consensus certificates in the locally stored consensus certificates whose block numbers continuously increase relative to the starting block number h, the target consensus node may first determine whether the block number of the latest block on which the node has reached consensus (i.e., the second block number) is less than the starting block number h. If so, the target consensus node may synchronize the block data and consensus certificates of certain blocks (which may be referred to as second target blocks) to other consensus nodes. The second target block is a block whose block number is greater than the second block number and not greater than the starting block number h (i.e., the second block number < block number ≤ h). It should be noted that all blocks whose block numbers are greater than the second block number and not greater than the starting block number h can serve as the second target block.

[0077] The target consensus node, which serves as the new master node after the view switch, synchronizes the block data and consensus certificates of all blocks with block numbers greater than the second block number and not greater than the starting block number h to other consensus nodes in the blockchain system, ensuring that all nodes in the blockchain system have the block data and consensus certificates of these blocks, thereby ensuring that these blocks have been consensus-passed and successfully produced in the blockchain system.

[0078] Accordingly, in some embodiments, if the target consensus node determines that it has not been elected as the new master node after the view switch, the target consensus node may receive a NewView message sent by another consensus node in the blockchain system that is the new master node after the view switch. The NewView message may include the end block number H' determined by the new master node, and a mapping relationship between each block number in the interval [h', H'] and the consensus pass certificate of the corresponding block, where h' is the start block number determined by the new master node.

[0079] In response to the received NewView message, the target consensus node can determine whether it has received at least 2f+1 ViewChange messages. If so, it can determine the valid block number from the block numbers contained in the at least 2f+1 ViewChange messages received by the target consensus node. For all consensus nodes in the blockchain system, the block number contained in the ViewChange message sent by at least one honest node among these consensus nodes must be no less than the valid block number.

[0080] After determining the valid block number, the target consensus node can determine whether the valid block number is lower than the end block number H' included in the NewView message. If so, it can search the mapping relationship included in the NewView message to find consensus proofs for certain blocks (these blocks may be referred to as third target blocks). The third target block is a block with a block number greater than the valid block number and no greater than the end block number H' included in the NewView message (i.e., the valid block number < block number ≤ H'). It should be noted that all blocks with a block number greater than the valid block number and no greater than the end block number H' can serve as the third target block.

[0081] If the consensus proof of the third target block is found in the mapping relationship contained in the NewView message, the target consensus node may locally store the consensus proof of the third target block and accept the NewView message to complete the view switch. Furthermore, the target consensus node may verify the consensus proof of the third target block. Once the verification is successful, the target consensus node may store the consensus proof of the third target block and accept the NewView message to complete the view switch.

[0082] In some embodiments, similar to the above, after the target consensus node stores the consensus proof of the third target block found locally, it can determine whether a Pre-Prepare message for the third target block exists locally. If the Pre-Prepare message for the third target block does not exist locally, the target consensus node can synchronize the Pre-Prepare message for the third target block with other consensus nodes in the blockchain system, that is, synchronize the original content of the transaction contained in the third target block with other consensus nodes in the blockchain system.

[0083] In some embodiments, similar to the foregoing, when the target consensus node determines the valid block number from the block numbers contained in the at least 2f+1 ViewChange messages received, it may specifically sort the block numbers contained in the at least 2f+1 ViewChange messages received by the node in descending order, and obtain the f+1th block number among the sorted block numbers as the valid block number.

[0084] In some embodiments, after completing the view switch, the new master node will re-initiate consensus on the transactions included in the blocks that have not yet reached consensus in the previous view.

[0085] Specifically, since the checkpoint represents the block number of the latest block that has been agreed upon, if the target consensus node determines that the current node is elected as the new master node after the view switch, the target consensus node can send a Pre-Prepare message for a block with a block number greater than the checkpoint or the second block number to other consensus nodes in the blockchain system based on the final checkpoint or the second block number determined, so as to initiate consensus on the transactions contained in the block with a block number greater than the checkpoint or the second block number.

[0086] If the target consensus node determines that it has not been elected as the new master node after the view switch, the target consensus node may respond to the Pre-Prepare message received from the new master node, and determine, based on the block contained in the Pre-Prepare message, whether the consensus proof of the block exists in the locally stored consensus proof. If so, the Prepare message corresponding to the Pre-Prepare message may no longer be broadcast to other consensus nodes in the blockchain system, that is, the target consensus node may no longer vote on the block, thereby terminating repeated voting.

[0087] In some embodiments, similar to the foregoing, for any locally stored consensus proof, the target consensus node may determine whether a Pre-Prepare message containing the block is stored locally based on the block corresponding to the consensus proof. If the Pre-Prepare message containing the block is not stored locally, the target consensus node may synchronize the Pre-Prepare message containing the block with other consensus nodes in the blockchain system and store the synchronized Pre-Prepare message locally. In other words, the target consensus node may synchronize the original content of the transaction contained in the block with other consensus nodes in the blockchain system and store it locally to avoid subsequent failure to properly execute the transaction contained in the block.

[0088] Please refer to Figure 5, which is a structural diagram of a device shown in an exemplary embodiment of the present application. At the hardware level, the device includes a processor 502, an internal bus 504, a network interface 506, a memory 508, and a non-volatile memory 510, and of course may also include other required hardware. One or more embodiments of the present application can be implemented based on software, such as the processor 502 reading the corresponding computer program from the non-volatile memory 510 into the memory 508 and then running it. Of course, in addition to software implementation, one or more embodiments of the present application do not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic module, but can also be hardware or logic devices.

[0089] Please refer to Figure 6, which is a schematic diagram of the architecture of a consensus node in a blockchain system shown in an exemplary embodiment of the present application.

[0090] The present application also provides an embodiment of a consensus node in a blockchain system. In this embodiment, the consensus node in the blockchain system can be a device as shown in Figure 5 to implement the technical solution of the present application. The blockchain system includes multiple consensus nodes.

[0091] The consensus node is any target consensus node in the blockchain system, as shown in FIG6 , and specifically may include: a first receiving unit 602, which receives a ViewChange message sent by another consensus node in response to the current round of consensus satisfying the ViewChange condition; wherein the ViewChange message includes the first block number of the latest block that has been agreed upon by the other consensus nodes, and a consensus approval certificate for the latest block;

[0092] The first determination unit 604 determines, in response to the ViewChange message received from the other consensus nodes, whether the second block number of the latest block on which the current node has reached consensus is smaller than the first block number contained in the ViewChange message; the first synchronization unit 606 synchronizes the consensus certificate of the first target block to the other consensus nodes if the second block number is smaller than the first block number, and stores the consensus certificate of the first target block locally; wherein the first target block is a block having a block number greater than the second block number and not greater than the first block number.

[0093] Optionally, the first synchronization unit 606: sends a synchronization request message to other consensus nodes; wherein the synchronization request message is used to synchronize the consensus proof of the first target block to the other consensus nodes; obtains a synchronization response message corresponding to the synchronization request message returned by the other consensus nodes; wherein the synchronization response message includes the consensus proof of the first target block; in response to the synchronization response message, stores the consensus proof of the first target block included in the synchronization response message locally.

[0094] Optionally, the consensus node further includes: a first storage unit, which, in response to receiving a ViewChange message sent by the other consensus nodes, stores the consensus pass proof contained in the ViewChange message locally.

[0095] Optionally, the consensus node further includes: a first sending unit, which sends a ViewChange message to other consensus nodes in response to the current round of consensus satisfying the ViewChange condition; wherein the ViewChange message includes the second block number and the consensus pass certificate of the latest block.

[0096] Optionally, the consensus node further includes: a second determination unit, which, before sending a ViewChange message to other consensus nodes, determines whether there exists a set of consensus certificates in the locally stored consensus certificates, whose corresponding block numbers continuously increase relative to the second block number; and an updating unit, which, if exists, determines the maximum block number among the block numbers corresponding to the individual consensus certificates in the consensus certificate set, and updates the second block number based on the maximum block number.

[0097] Optionally, the consensus node further includes: a third determination unit, which, if the current node is elected as the new master node after the view switch, determines a starting block number h from the block numbers contained in at least 2f+1 ViewChange messages received; wherein the block number contained in the ViewChange message sent by at least one honest node among the consensus nodes is not less than the starting block number; a fourth determination unit, which determines whether there is a set of consensus certificates in the locally stored consensus certificates whose corresponding block numbers keep continuously increasing relative to the starting block number; if so, determines the maximum block number among the block numbers corresponding to the respective consensus certificates in the consensus certificate set, and determines the maximum block number as the ending block number H corresponding to the starting block number; a second sending unit, which sends a NewView message to other consensus nodes; wherein the NewView message includes the ending block number, and a mapping relationship between each block number in the interval [h, H] and the consensus certificate of the corresponding block.

[0098] Optionally, the third determination unit: sorts the block numbers contained in the at least 2f+1 ViewChange messages received in descending order, and obtains the f+1th block number among the sorted block numbers as the starting block number h; where f represents the fault tolerance threshold of the PBFT algorithm for the consensus node.

[0099] Optionally, the consensus node further includes: a fifth determination unit, which determines whether the second block number is less than the starting block number before determining whether there is a corresponding set of consensus proofs in the locally stored consensus proofs whose block numbers continuously increase relative to the starting block number; if so, synchronizes the block data and consensus proof of a second target block to other consensus nodes; wherein the second target block is a block whose block number is greater than the second block number and not greater than the starting block number.

[0100] Optionally, the consensus node further includes: a second receiving unit, which, if the current node is not elected as the new master node after the view switch, receives a NewView message sent by the new master node; a sixth determining unit, which, in response to the received NewView message, determines whether the current node has received at least 2f+1 ViewChange messages; if so, determines a valid block number from the block numbers contained in the at least 2f+1 ViewChange messages received; wherein the block number contained in the ViewChange message sent by at least one honest node among the consensus nodes is not less than the valid block number; a second storage unit, which determines whether the valid block number is lower than the end block number contained in the NewView message; if so, searches for a consensus proof of a third target block from the mapping relationship contained in the NewView message; if the consensus proof of the third target block is found from the mapping relationship, locally stores the consensus proof of the third target block, and accepts the NewView message to complete the view switch; wherein the block number of the third target block is greater than the valid block number and not greater than the end block number contained in the NewView message.

[0101] Optionally, the sixth determining unit: sorts the block numbers contained in the at least 2f+1 received ViewChange messages in descending order, and obtains the f+1th block number from the sorted block numbers as the valid block number.

[0102] Optionally, the consensus node further includes: a seventh determination unit, which, in response to the received Pre-Prepare message sent by the new master node, determines whether there is a consensus certificate corresponding to the block included in the Pre-Prepare message in the locally stored consensus certificate; if so, no longer broadcasts the Prepare message corresponding to the Pre-Prepare message to other consensus nodes.

[0103] Optionally, the consensus node further includes: a second synchronization unit, which determines whether a Pre-Prepare message containing a block corresponding to the locally stored consensus proof is stored locally; if not, synchronizes the Pre-Prepare message containing a block corresponding to the consensus proof to other consensus nodes, and stores the Pre-Prepare message locally.

[0104] The present application also provides an embodiment of a blockchain system, comprising multiple consensus nodes, wherein: any target consensus node receives a ViewChange message sent by other consensus nodes in response to the ViewChange condition being satisfied in the current round of consensus; wherein the ViewChange message includes the first block number of the latest block that has been consensus-approved by the other consensus nodes, and a consensus-approved certificate of the latest block; the target consensus node determines, in response to the received ViewChange message sent by the other consensus nodes, whether the second block number of the latest block that has been consensus-approved by the node itself is less than the first block number included in the ViewChange message; if the second block number is less than the first block number, the target consensus node synchronizes the consensus-approved certificate of the first target block with the other consensus nodes, and stores the consensus-approved certificate of the first target block locally; wherein the first target block is a block whose block number is greater than the second block number and not greater than the first block number.

[0105] In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures such as diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using hardware modules. For example, a programmable logic device (PLD), such as a field programmable gate array (FPGA), is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to hire a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly done using "logic compiler" software. This is similar to the software compiler used when developing programs. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There is not just one HDL, but many, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages ​​and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.

[0106] The controller can be implemented in any suitable manner. For example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that in addition to implementing the controller in a purely computer-readable program code format, the controller can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules that implement the method and structures within the hardware component.

[0107] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude that with the future development of computer technology, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, an in-vehicle human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0108] Although one or more embodiments of the present application provide method operation steps as described in the embodiments or flow charts, more or fewer operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps and does not represent a unique execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "include", "comprising" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not clearly listed, or also includes elements inherent to such process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any particular order.

[0109] For the convenience of description, the above devices are described as being divided into various modules according to their functions. Of course, when implementing one or more of the present applications, the functions of each module can be implemented in the same or multiple software and / or hardware, or the module that implements the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0110] The present application is described with reference to the flowchart and / or block diagram of the method, device (system), and computer program product according to the embodiment of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, and the combination of the process and / or box in the flowchart and / or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the function specified in one process or multiple processes in the flowchart and / or one box or multiple boxes in the block diagram.

[0111] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0112] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0113] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0114] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

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

[0116] It will be understood by those skilled in the art that one or more embodiments of the present application may be provided as a method, system, or computer program product. Therefore, one or more embodiments of the present application may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, one or more embodiments of the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0117] One or more embodiments of the present application may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. One or more embodiments of the present application may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communications network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0118] The various embodiments in this application are described in a progressive manner. Similar or identical parts between the various embodiments can be referenced to each other. Each embodiment focuses on the differences from other embodiments. In particular, since the system embodiments are generally similar to the method embodiments, the description is relatively simple. For relevant parts, reference can be made to the partial description of the method embodiments. In the description of this application, reference to the terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of this application. In this application, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in any appropriate manner in any one or more embodiments or examples. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this application, as well as the features of different embodiments or examples, without conflict.

[0119] The foregoing is merely an example of one or more embodiments of the present application and is not intended to limit the one or more embodiments of the present application. It will be apparent to those skilled in the art that various modifications and variations may be made to one or more embodiments of the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application should be included within the scope of the claims.

Claims

1. A view switching method in a PBFT algorithm, the method being applied to any target consensus node in a blockchain system, comprising: In response to the current round of consensus satisfying the ViewChange condition, receiving a ViewChange message sent by other consensus nodes; wherein the ViewChange message includes the first block number of the latest block that has been agreed upon by the other consensus nodes, and a consensus approval certificate for the latest block; In response to the received ViewChange message sent by the other consensus node, determine whether the second block number of the latest block that has been consensus-approved by the node is smaller than the first block number included in the ViewChange message; If the second block number is smaller than the first block number, synchronize the consensus proof of the first target block to other consensus nodes, and store the consensus proof of the first target block locally; wherein the first target block is a block whose block number is greater than the second block number and not greater than the first block number.

2. The method according to claim 1, synchronizing the consensus proof of the first target block to other consensus nodes, and storing the consensus proof of the first target block locally, comprises: Sending a synchronization request message to other consensus nodes; wherein the synchronization request message is used to synchronize the consensus proof of the first target block to the other consensus nodes; Obtaining a synchronization response message corresponding to the synchronization request message returned by the other consensus nodes; wherein the synchronization response message includes a consensus pass certificate of the first target block; In response to the synchronization response message, the consensus of the first target block contained in the synchronization response message is stored locally through proof.

3. The method of claim 1, further comprising: In response to receiving the ViewChange message sent by the other consensus node, the consensus contained in the ViewChange message is locally stored through proof.

4. The method of claim 1, further comprising: In response to the current round of consensus satisfying the ViewChange condition, a ViewChange message is sent to other consensus nodes; wherein the ViewChange message includes the second block number and the consensus pass certificate of the latest block.

5. The method according to claim 4, before sending the ViewChange message to other consensus nodes, further comprises: Determining whether there is a set of consensus proofs in the locally stored consensus proofs whose corresponding block numbers are continuously increasing relative to the second block number; If so, determine the maximum block number among the block numbers corresponding to the consensus proofs in the consensus proof set, and update the second block number based on the maximum block number.

6. The method of claim 1, further comprising: If this node is elected as the new master node after the view switch, the starting block number h is determined from the block numbers contained in at least 2f+1 ViewChange messages received; wherein the block number contained in the ViewChange message sent by at least one honest node among the consensus nodes is not less than the starting block number; Determine whether there is a consensus proof set whose corresponding block numbers are continuously increasing relative to the starting block number in the locally stored consensus proofs; if so, determine the maximum block number among the block numbers corresponding to the consensus proofs in the consensus proof set, and determine the maximum block number as the ending block number H corresponding to the starting block number; Send a NewView message to other consensus nodes; wherein the NewView message includes the end block number, and a mapping relationship between each block number in the interval [h, H] and the consensus pass certificate of the corresponding block.

7. The method of claim 6, determining the starting block number h from the block numbers included in the at least 2f+1 ViewChange messages received, comprising: Sort the block numbers contained in at least 2f+1 ViewChange messages received from large to small, and obtain the f+1th block number among the sorted block numbers as the starting block number h; where f represents the fault tolerance threshold of the PBFT algorithm for consensus nodes.

8. The method of claim 6, before determining whether there is a set of consensus proofs with corresponding block numbers that continuously increase relative to the starting block number in the locally stored consensus proofs, further comprises: Determining whether the second block number is less than the starting block number; If yes, synchronize the block data and consensus pass proof of the second target block to other consensus nodes; wherein the second target block is a block whose block number is greater than the second block number and not greater than the starting block number.

9. The method of claim 6, further comprising: If the current node is not elected as the new master node after the view switch, receive the NewView message sent by the new master node; In response to the received NewView message, determining whether the node has received at least 2f+1 ViewChange messages; If yes, determine the valid block number from the block numbers included in the at least 2f+1 ViewChange messages received; wherein the block number included in the ViewChange message sent by at least one honest node among the consensus nodes is not less than the valid block number; Determine whether the valid block number is lower than the end block number included in the NewView message; if so, search for a consensus proof of a third target block from the mapping relationship included in the NewView message; if the consensus proof of the third target block is found from the mapping relationship, store the consensus proof of the third target block locally, and accept the NewView message to complete the view switch; wherein the third target block has a block number greater than the valid block number and not greater than the end block number included in the NewView message.

10. The method according to claim 9, determining a valid block number from the block numbers included in at least 2f+1 ViewChange messages received, comprising: The block numbers contained in at least 2f+1 ViewChange messages received are sorted in descending order, and the f+1th block number among the sorted block numbers is obtained as the valid block number.

11. The method of claim 6, further comprising: In response to receiving the Pre-Prepare message sent by the new master node, determine whether there is a consensus certificate corresponding to the block included in the Pre-Prepare message in the locally stored consensus certificate; if so, no longer broadcast the Prepare message corresponding to the Pre-Prepare message to other consensus nodes.

12. The method according to any one of claims 1 to 11, further comprising: Determine whether a Pre-Prepare message containing a block corresponding to the locally stored consensus proof is stored locally; If not, synchronize the Pre-Prepare message containing the block corresponding to the consensus pass proof to other consensus nodes and store the Pre-Prepare message locally.

13. A consensus node, the consensus node being any target consensus node in a blockchain system, comprising: A first receiving unit, in response to the current round of consensus satisfying the ViewChange condition, receives a ViewChange message sent by other consensus nodes; wherein the ViewChange message includes the first block number of the latest block that has been consensus-approved by the other consensus nodes, and a consensus-approved certificate of the latest block; A first determining unit, in response to a received ViewChange message sent by the other consensus node, determines whether a second block number of the latest block that has been consensus-passed by the node is smaller than the first block number included in the ViewChange message; The first synchronization unit synchronizes the consensus proof of the first target block to other consensus nodes if the second block number is smaller than the first block number, and stores the consensus proof of the first target block locally; wherein the first target block is a block having a block number greater than the second block number and not greater than the first block number.

14. A blockchain system, comprising a plurality of consensus nodes, wherein: In response to the current round of consensus satisfying the ViewChange condition, any target consensus node receives a ViewChange message sent by other consensus nodes; wherein the ViewChange message includes the first block number of the latest block that has been agreed upon by the other consensus nodes, and a consensus approval certificate for the latest block; The target consensus node confirms the received ViewChange message sent by the other consensus nodes. Determine whether the second block number of the latest block that has been agreed upon by the node is smaller than the first block number included in the ViewChange message; If the second block number is smaller than the first block number, the target consensus node synchronizes the consensus proof of the first target block to other consensus nodes, and stores the consensus proof of the first target block locally; wherein the first target block is a block whose block number is greater than the second block number and not greater than the first block number.

Images