CN116846912A

CN116846912A - View switching method, consensus node and block chain system in PBFT algorithm

Info

Publication number: CN116846912A
Application number: CN202310800523.3A
Authority: CN
Inventors: 荣康; 徐文博
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2023-06-30
Filing date: 2023-06-30
Publication date: 2023-10-03

Abstract

One or more embodiments of the present application provide a view switching method, a consensus node and a blockchain system in a PBFT algorithm, where the method is applied to any target consensus node in the blockchain system, and includes: receiving ViewChange messages sent by other consensus nodes in response to the fact that the current round of consensus meets the ViewChange condition; the ViewChange message comprises a first block number of the latest block which is already commonly recognized by other commonly recognized nodes and a commonly recognized passing evidence of the latest block; responding to the received ViewChange message sent by other consensus nodes, determining whether the second block number of the latest block which is already commonly recognized by the node is smaller than the first block number contained in the ViewChange message; if the second block number is smaller than the first block number, synchronizing the consensus passing certification of the first target block to other consensus nodes, and locally storing the consensus passing certification of the first target block; the first target block is a block with a block number larger than the second block number and not larger than the first block number.

Description

View switching method, consensus node and block chain system in PBFT algorithm

Technical Field

One or more embodiments of the present application relate to the field of blockchain technologies, and in particular, to a view switching method, a consensus node, and a blockchain system in a PBFT algorithm.

Background

Blockchain (Blockchain) is a new application model of computer technology such as distributed data storage, point-to-point transmission, consensus protocols, encryption algorithms, and the like. In the block chain system, the data blocks are combined into a chain data structure in a sequential connection mode according to the time sequence, and the distributed account book which is not tamperable and counterfeit and is ensured in a cryptographic mode is formed. The blockchain has the characteristics of decentralization, non-tamperability of information, autonomy and the like, so that the blockchain is more and more widely applied.

Disclosure of Invention

One or more embodiments of the present application provide a view switching method, a consensus node and a blockchain system in a PBFT algorithm, including:

the application provides a view switching method in a PBFT algorithm, which is applied to any target consensus node in a block chain system and comprises the following steps:

receiving ViewChange messages sent by other consensus nodes in response to the fact that the current round of consensus meets the ViewChange condition; the ViewChange message comprises a first block number of a latest block which is already commonly recognized by the other commonly recognized nodes and a commonly recognized passing evidence of the latest block;

Responding to the received ViewChange message sent by the other consensus nodes, and determining whether the second block number of the latest block which is already commonly recognized by the node is smaller than the first block number contained in the ViewChange message;

if the second block number is smaller than the first block number, synchronizing the consensus passing certification of the first target block to other consensus nodes, and locally storing the consensus passing certification of the first target block; the first target block is a block with a block number larger than the second block number and not larger than the first block number.

The application also provides a consensus node, which is any target consensus node in a block chain system, comprising:

the first receiving unit is used for receiving ViewChange messages sent by other consensus nodes in response to the fact that the current round of consensus meets the ViewChange condition; the ViewChange message comprises a first block number of a latest block which is already commonly recognized by the other commonly recognized nodes and a commonly recognized passing evidence of the latest block;

a first determining unit, configured to determine, in response to a received ViewChange message sent by the other consensus node, whether a second block number of a latest block that has been commonly recognized to pass by the node is smaller than the first block number included in the ViewChange message;

The first synchronization unit is used for synchronizing the consensus passing evidence of the first target block to other consensus nodes if the second block number is smaller than the first block number, and locally storing the consensus passing evidence of the first target block; the first target block is a block with a block number larger than the second block number and not larger than the first block number.

The application also provides a blockchain system comprising a plurality of consensus nodes, wherein:

any target consensus node responds to the fact that the round of consensus meets the ViewChange condition, and receives ViewChange messages sent by other consensus nodes; the ViewChange message comprises a first block number of a latest block which is already commonly recognized by the other commonly recognized nodes and a commonly recognized passing evidence of the latest block;

the target consensus node responds to the received ViewChange message sent by the other consensus nodes, and determines whether the second block number of the latest block which is already commonly recognized by the target consensus node is smaller than the first block number contained in the ViewChange message;

if the second block number is smaller than the first block number, the target consensus node synchronizes the consensus passing evidence of the first target block to other consensus nodes, and locally stores the consensus passing evidence of the first target block; the first target block is a block with a block number larger than the second block number and not larger than the first block number.

In the above embodiment, in the process of consensus for a transaction included in a block, if a consensus node has completed consensus for the block (i.e. 2f+1 common messages corresponding to the block have been collected) before View switching because the progress of consensus is faster, the node may carry, in the View Change stage, locally stored consensus passing credentials of the block (including collected 2f+1 common messages corresponding to the block) in the View Change message to broadcast to other consensus nodes, so that when receiving the View Change message, the other consensus nodes may store the consensus passing credentials of the block included in the View Change message locally. Through the synchronization mechanism, the consensus nodes with slower consensus progress can keep pace with the consensus nodes with faster consensus progress in the View Change stage, so that synchronization of the consensus progress among the consensus nodes is ensured. After the view is switched, the new master node will rebroadcast the Pre-preparation message corresponding to the block to reinitiate the consensus for the transaction contained in the block, at this time, because each consensus node has synchronized to the latest consensus passing evidence, if the consensus passing evidence of the block is stored locally, the preparation message corresponding to the Pre-preparation message may not be returned any more, so that repeated voting is aborted. Thus, even if the configuration of the consensus node is updated, the abnormal situation can not occur when the consensus is re-known because the voting is not repeated.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for the description of the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments described in the present application, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic diagram of a blockchain system in accordance with an exemplary embodiment of the present application;

FIG. 2 is a schematic diagram illustrating a conventional phase in a PBFT algorithm according to an exemplary embodiment of the present application;

FIG. 3 is a schematic diagram of a view switching stage in a PBFT algorithm according to an exemplary embodiment of the present application;

FIG. 4 is a flow chart of a method of view switching in a PBFT algorithm according to an exemplary embodiment of the present application;

FIG. 5 is a schematic diagram of an apparatus according to an exemplary embodiment of the present application;

fig. 6 is a schematic diagram illustrating an architecture of a consensus node in a blockchain network in accordance with an exemplary embodiment of the present application.

Detailed Description

In order to make the technical solution of the present application better understood by those skilled in the art, the technical solution of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application, and it is apparent that the described embodiments are only some embodiments of the present application, not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, shall fall within the scope of the application.

Blockchains are generally divided into three types: public (Public Blockchain), private (Private Blockchain) and federated (Consortium Blockchain) chains. In addition, there may be various types of combinations as described above, such as a combination of a private chain and a federation chain, a combination of a federation chain and a public chain, and so on.

Among the three types of blockchains described above, the most decentralized is the public chain. Participants joining the public chain (which may also be referred to as nodes in the blockchain) may read data records on the chain, participate in transactions, compete for billing rights for new blocks, and so forth. Moreover, each node can freely join or leave the network and perform relevant operations.

The private chain is the opposite, the write rights of the network are controlled by some organization or organization, and the data read rights are specified by the organization. That is, the private chain may be considered as a weakly centralized system with strict restrictions on nodes and a small number of nodes. This type of blockchain is more suitable for use within a particular organization.

The alliance chain is between the public chain and the private chain, so that the 'partial decentralization' can be realized. Each node in the federation chain typically has an entity authority or organization corresponding thereto; nodes join the network by authorization and form a benefit-related federation, which collectively maintains the operation of the blockchain.

Referring to fig. 1, fig. 1 is a schematic diagram of a blockchain system according to an exemplary embodiment of the application.

As shown in FIG. 1, a blockchain system may maintain one or more blockchains (e.g., public blockchains, private blockchains, federated blockchains, etc.), and may contain a plurality of blockchain nodes for carrying the one or more blockchains; for example, blockchain node 1, blockchain node 2, blockchain node 3, blockchain node 4, blockchain node i, and the like, as shown in fig. 1, may collectively carry one or more blockchains. Inter-chain data access may also be performed between blockchains included in each blockchain system, as well as between blockchain systems.

The blockchain node is a logical communication entity; multiple blockchain nodes of different types may run on the same physical server or on different physical servers. In one embodiment shown, the blockchain node may be a physical device or a virtual device implemented in a server or server cluster; for example, the blockchain node may be a physical host in the server cluster, or may be a virtual machine created by virtualizing a hardware resource mounted on the server or the server cluster based on a virtualization technology. Each blockchain node may be coupled together to form a network by various types of communication methods (e.g., TCP/IP, etc.) to carry one or more blockchains.

Based on the basic characteristics of a blockchain, a blockchain is typically made up of several blocks. The time stamps corresponding to the creation time of the block are recorded in the blocks respectively, and all the blocks form a time-ordered data chain strictly according to the time stamps recorded in the blocks.

For data generated outside the blockchain, the data can be constructed into a standard transaction (transaction) format supported by the blockchain, then issued to the blockchain, the nodes participating in the consensus in the blockchain system make the consensus on the transaction, and the transaction is executed after the consensus is completed, so that the transaction and the execution result can be subjected to persistence in the blockchain.

In a blockchain system, different participants may establish a distributed blockchain network through deployed nodes. Wherein a decentralized (or multicentric) distributed ledger constructed using a chain block structure is stored on each node (or large multi-node, such as a consensus node) in the distributed blockchain network. Such blockchain systems need to address the problem of consistency and correctness of the respective ledger data across the plurality of nodes that are de-centralized (or multicentric). Each node in the blockchain system runs a blockchain program, and under the design of certain fault tolerance requirements, all the loyalty nodes are guaranteed to have the same transaction through a consensus (consensus) protocol, so that the consistency of the execution results of all the loyalty nodes on the same transaction is guaranteed, and the transaction and the execution results are packed to generate a block.

Specifically, the consensus nodes in the blockchain system can agree on the transactions contained in the new blocks to be connected to the chain block structure based on the consensus protocol, so as to ensure that each consensus node agrees on the contents and the sequence of the transactions contained in the block, thereby realizing the construction of the block. After the consensus is completed, the consensus node may send the constructed block to other nodes to sequentially execute the transactions included in the block by each node, and complete the finalization of the block if it is confirmed that the transaction execution results of each node are consistent. Where finalize refers to the completion of execution of a transaction contained in a block, and the result of execution of the transaction is accepted by all nodes (or a certain number of nodes, such as two-thirds of nodes).

The consensus protocol of the current mainstream includes: and algorithms such as Proof of Work (POW), proof of equity (POS), proof of commission (Delegated Proof of Stake, DPOS), practical bayer fault tolerance (Practical Byzantine Fault Tolerance, PBFT), meles bayer fault tolerance (honeybadger bft), and the like. These consensus protocols can generally be divided into two classes, asynchronous and non-asynchronous. For example, the PBFT algorithm belongs to a semi-synchronous (partial synchronous) protocol, while the honeybadger bft algorithm belongs to an asynchronous (asynchroous) protocol.

Taking the PBFT algorithm as an example, the algorithm is proposed by Miguel Castro and barbarba Liskov in 1999, which solves the problem that the original bayer fault-tolerant algorithm is not efficient, reduces the algorithm complexity from exponential level to polynomial level, and makes the bayer fault-tolerant algorithm feasible in practical system application. The paper was published in 1999 on the operating system design and implementation international conference (OSDI 99). In the PBFT algorithm, all copies (replicas) run in a rotation process (succession of configuration), called view. In a certain view, one copy acts as a primary node (primary) and the other copies act as backup nodes (backup). Views are integers numbered consecutively. The master node is calculated from the formula p=v mod|r|, where v is the view number, p is the copy number, and |r| is the number of copy sets. It is assumed in this algorithm that when there are at most f copies (i.e., nodes) to fail, if there are at least 3f+1 copies in total, it is guaranteed that security and activity are provided in an asynchronous system. The set of a certain number of copies needed to be able to ensure data consistency requirements and fault tolerance requirements of all copies is typically the set of most nodes in the distributed system, constituting the majority (Quorum). For example, in the case where the total node number n is 3f+1 (the case where n=3f+2 or n=3f does not generally contribute to improvement in the fault tolerance effect), quum is 2f+1. Thus, for a distributed system comprising four nodes, any three nodes may constitute a Quorum.

The PBFT algorithm includes two processes, normal Case Phase and View Change Phase. Fig. 2 is a schematic diagram of Normal Case Phase (conventional phase). Normal Case Phase mainly comprises three stages of PRE-preparation, preparation and COMMIT, wherein node No. 3 may represent a down node (indicated by x in fig. 2), for example. When the master node fails, a View Change process needs to be started, so that state adjustment is performed when the system fails, and a new master node is updated. Fig. 3 is a schematic diagram of View Change Phase (view switching stage). The client may set a timeout mechanism if the master node drops or does not broadcast the client's request, etc. If timed out, the client may broadcast a request message to all duplicate nodes. After the duplicate node detects that the master node is either dead or down, view Change Phase may also be initiated to replace the master node (often referred to simply as "swap master"). In addition, the PRE-PREPARE, PREPARE and COMMIT three-phase consensus process may fail due to the main node initiating the wrong proposal, or the PREPARE, COMMIT phase may not be consistent with the number of Quorum (such as 2f+1 of 3f+1 nodes, also called Quorum), and the consensus cannot be completed. View Change Phase may also be initiated in these cases to replace the master node. For example, the master node of the v-th view is copy 0, and copy 1 is a new master node after the view is changed, i.e., the master node of the v+1th view is copy 1.

The PBFT algorithm belongs to a semi-synchronous protocol, and is characterized in that it is assumed that the network is initially asynchronous, but can start to synchronize from a certain moment. To let different nodes agree on the same proposal in the network, the simplest way is to set up a master node, which unifies the ideas of the various nodes. By setting the timer, master node errors can be prevented. In the PBFT algorithm, if Normal Case Phase is not completed within a limited time, backups initiation View Change Phase is triggered to replace the master node. The PBFT algorithm fixes the master node in one place, and all requests can be sent to the master node first and then broadcast to other consensus nodes by the master node.

A single master node type protocol such as PBFT has only the master node capable of initiating a consensus proposal in the same consensus, and other nodes have no capability of initiating a consensus proposal. Alternatively, if other nodes also have a proposal, the proposal needs to be forwarded to the master node, which initiates the proposal instead.

Specifically, in a blockchain system using the PBFT algorithm as a consensus protocol, if a new master node needs to be replaced, a view switching phase is entered. In the blockchain system, each consensus node may send a ViewChange message to other consensus nodes, proposing to switch views. The new master node can be calculated from the formula p=v+1 mod|r|, v+1 representing the next view after the view switch. The new master node may send a NewView message to the other consensus nodes after collecting 2f+1 view change messages, and after the other consensus nodes accept the NewView message, the view switch is completed.

In the related art, in the process of consensus for a transaction included in a block, there are cases where some or some consensus nodes have completed consensus for the block (i.e. 2f+1 common messages corresponding to the block have been collected) before view switching because the progress of consensus is faster, but other consensus nodes have not completed consensus for the block (i.e. 2f+1 common messages corresponding to the block have not been collected), and at this time, the block is considered to have not yet reached consensus, i.e. the block has not yet succeeded in outputting the block. In this case, after the view is switched, the new master node will reinitiate the consensus of the transaction contained in the block, and vote for the block by each consensus node, if the configuration of part of the consensus nodes is updated (e.g. node change, key update, etc.) in the process of the re-consensus, the abnormal situation occurs in the re-consensus, and the block consensus fails.

Referring to fig. 4, fig. 4 is a flowchart illustrating a view switching method in a PBFT algorithm according to an exemplary embodiment of the present application.

The application provides an embodiment of a view switching method in a PBFT algorithm, in the embodiment, the PBFT algorithm can be used as a consensus protocol of a block chain system, and the view switching method in the PBFT algorithm can be applied to any consensus node (which can be called a target consensus node) in the block chain system.

As shown in fig. 4, the view switching method in the PBFT algorithm may specifically include:

step 402: receiving ViewChange messages sent by other consensus nodes in response to the fact that the current round of consensus meets the ViewChange condition; the ViewChange message includes a first block number of a latest block through which the other consensus nodes have commonly passed, and a consensus passing proof of the latest block.

In this embodiment, as described above, when the master node fails, a view exchange process needs to be started, and in the view exchange stage, each node in the blockchain system may send a ViewChange message to other nodes. Therefore, when the master node fails, the current round of consensus can be considered to meet the ViewChange condition. For any of the consensus nodes in the blockchain system, the consensus node may send a ViewChange message to other consensus nodes in the blockchain system in response to the current round of consensus satisfying the ViewChange condition. That is, the target consensus node may receive a ViewChange message sent by other consensus nodes in the blockchain system in response to the current round of consensus satisfying the ViewChange condition.

For any of the above-described consensus nodes in the blockchain system, the view change message sent by the 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 to pass, and the consensus proof of passing (proof) of the latest block. That is, the ViewChange message received by the target consensus node and sent by some other consensus node in the blockchain system may include the block number (may be referred to as the first block number) of the latest block that the other consensus node has already agreed to pass, and the consensus passing proof of the latest block.

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 round of consensus satisfying a ViewChange condition. The ViewChange message may include the block number (which may be referred to as the second block number) of the latest block that the node (i.e., the target consensus node) has commonly passed, and the consensus passing certificate of the latest block.

In practical applications, on the one hand, the common passing proof of a block may contain 2f+1 Commit messages and their signatures corresponding to the block. Wherein f represents a fault tolerance threshold of the PBFT algorithm for a consensus node in the blockchain system. If a consensus node locally stores a consensus passing proof for a block, it is stated that the consensus node has received 2f+1 Commit messages corresponding to the block and validated to pass, i.e., the block is the block that the consensus node has agreed to pass.

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

For a blockchain, the blockheight is the number of blocks connected to the chain block structure. However, for any block in the blockchain, the block height of that block may be used as an identifier of that block. A chunk is generally considered to have two identifiers, one being the hash value of the chunk header and the other being the chunk height. The hash value of the block head is obtained by performing secondary hash calculation on the block head through an SHA256 algorithm and the like; the hash value of a block header can uniquely identify a block, and any node in the blockchain system can independently obtain the hash value of the block header by hashing the block header. Block height refers to the position of a block in a blockchain; the block height is not an identifier that uniquely identifies a block, although a block will always have a definite and fixed block height, a block height does not always identify a unique block, and two or more blocks may have the same block height, i.e., contend for the same position in the blockchain.

The individual blocks in a blockchain are typically connected to a chain block structure in time sequence, i.e. the chain block structure is in fact a chain that is ordered in time. In this case, the block height is typically set to an increasing value. For example, assuming that the block height of the last block after finalizing is h, the block height of the next block to be commonly recognized is h+1; and so on.

Note that, the block number of the latest block that has been commonly passed by a common node may also be referred to as a checkpoint of the common node.

In some embodiments, the ViewChange message sent by a consensus node may be expressed as < VIEWCHANGE, v+1, h, pset, qset, nodeid, sig, proof >. Where v denotes the current view, v+1 denotes the next view after switching, h denotes the checkpoint of the consensus node, pset is the block with a block number greater than h and having completed the preparation phase (i.e. having received 2f+1 preparation messages and their signatures corresponding to the block), qset is the block with a block number greater than h and having completed the PRE-preparation phase (i.e. having received 2f+1 preparation messages and their signatures corresponding to the block), sig is the signature of all preceding fields, and proof is the consensus passing of the block with block number h.

Step 404: and responding to the received ViewChange message sent by the other consensus nodes, determining whether the second block number of the latest block which is already commonly recognized by the node is smaller than the first block number contained in the ViewChange message.

In this embodiment, when receiving the ViewChange message sent by any one of the other consensus nodes in the blockchain system, the target consensus node may determine, in response to the ViewChange message, whether the block number (which may be referred to as a second block number) of the latest block through which the target consensus node has agreed is smaller than the first block number included in the ViewChange message. At this time, the first block number is the block number of the latest block that the other consensus node has commonly recognized to pass.

For example, assuming that the target consensus node is a consensus node a, the block number of the latest block that the consensus node a has already agreed to pass through (i.e., the second block number) is a block number a, and the block number of the latest block that a certain consensus node X in the blockchain system has already agreed to pass through (i.e., the first block number) is a block number X, if the consensus node a receives the ViewChange message sent by the consensus node X, it may determine whether the block number a is smaller than the block number X in response to the ViewChange message.

Step 406: if the second block number is smaller than the first block number, synchronizing the consensus passing certification of the first target block to other consensus nodes, and locally storing the consensus passing certification of the first target block; the first target block is a block with a block number larger than the second block number and not larger than the first block number.

In this embodiment, if the second block number is smaller than the first block number, it is indicated that the maximum block number corresponding to the local existing common identification passing certificate of the target common identification node is the second block number, that is, the local target common identification node has no block number greater than the second block number and not greater than the first block number, but the maximum block number corresponding to the local existing common identification passing certificate of the other common identification node is the first block number, that is, the local existing block number of the other common identification node is greater than the second block number and not greater than the first block number. Thus, the target consensus node may synchronize the consensus passing credentials of certain blocks (which may be referred to as first target blocks) to the other consensus nodes and store the consensus passing credentials 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 is less than the block number and less than or equal to the first block number). It should be noted that all blocks with block numbers greater than the second block number and not greater than the first block number can be used as the first target block.

Continuing with the above example, if block number a is less than block number X, consensus node a may synchronize the consensus passing evidence of the first target block with consensus node a and store the consensus passing evidence of the first target block locally. At this time, the first target block may be all blocks whose block number is greater than the block number a and not greater than the block number X (i.e., block number a < block number +.block number X).

In some embodiments, the target consensus node may determine whether a Pre-preparation message of the first target block exists locally after synchronizing to the consensus of the first target block is verified, for example: and judging whether to locally store the PrePrePrepaper message corresponding to the block number of the first target block according to the block number of the first target block. If there is no Pre-preparation message of the first target block locally, the target consensus node may synchronize the Pre-preparation message of the first target block to the other consensus nodes in the blockchain system, i.e., synchronize the original content of the transaction contained in the first target block to the other consensus nodes. If the Pre-preparation message of the first target block is not synchronized, the target consensus node locally only has the consensus passing certification of the first target block, but only can certify that the target consensus node passes aiming at the first target block, but the related information of the transaction contained in the first target block is locally missing, so that the transaction contained in the first target block cannot be normally executed.

In some embodiments, as described above, the ViewChange message received by the target consensus node and sent by some other consensus node in the blockchain system may include a consensus passing proof of the latest block that the other consensus node has already agreed to pass. Therefore, when receiving the ViewChange message sent by any other consensus node in the blockchain system, the target consensus node can also respond to the ViewChange message to locally store the consensus passing evidence contained in the ViewChange message. At this time, the consensus passing evidence is the consensus passing evidence of the latest block which the other consensus node has passed in consensus.

That is, the target consensus node may directly store the consensus passing certificate of the latest block that the other consensus node has passed through, which is included in the ViewChange message sent by the other consensus node. In this case, the target consensus node may not synchronize the consensus passing proof of the latest block to the other consensus node any more, but only synchronize the consensus passing proof of the block whose block number is greater than the second block number and smaller than the block number of the latest block (i.e., the first block number) through which the other consensus node has already passed to the other consensus node, so that the data transmission amount between the target consensus node and the other consensus node may be reduced, and the synchronization efficiency of the consensus progress for the block may be improved.

In some embodiments, the target consensus node may receive a ViewChange message sent by some other consensus node in the blockchain system before sending the ViewChange message to the other consensus node in the blockchain system, and store the consensus passing certificate of the latest block that the other consensus node included in the ViewChange message has already agreed to pass locally. In this case, the target consensus node may determine, before sending the ViewChange message to other consensus nodes in the blockchain system, whether there is a set of consensus passing proofs in which corresponding block numbers remain continuously incremented with respect to the second block number in the locally stored consensus passing proofs, and if there is a set of consensus passing proofs, may further determine a maximum block number in the block numbers corresponding to each consensus passing proof in the set of consensus passing proofs, and update the second block number based on the maximum block number. Therefore, a checking mechanism before the consensus node sends the ViewChange message is realized, the checkpoint contained in the ViewChange message sent by one consensus node can be ensured, and the real consensus progress of the consensus node can be embodied.

For example, assuming that the block number of the latest block through which the target consensus node has already agreed (i.e., the second block number) is 10, the target consensus node typically stores locally the consensus passing evidence of 10 blocks having block numbers 1 to 10. If the target consensus node receives the ViewChange message sent by 3 other consensus nodes in the blockchain system, the 3 ViewChange messages include the consensus passing evidence of the block with the block number of 11, the consensus passing evidence of the block with the block number of 12 and the consensus passing evidence of the block with the block number of 14 respectively, the target consensus node can store the 3 consensus passing evidence locally. That is, the target consensus node locally stores the consensus certification of 13 blocks of block numbers 1 to 12 and block number 14 at this time. Since there is a set of common-knowledge passing certificates (i.e., a set consisting of common-knowledge passing certificates of blocks with block numbers 11 and common-knowledge passing certificates of blocks with block numbers 12) in which the corresponding block numbers remain continuously incremented with respect to the second block number in the common-knowledge node locally stored, it is possible to further determine that the largest block number among the block numbers corresponding to the respective common-knowledge passing certificates in the set of common-knowledge passing certificates is 12, and update the second block number from 10 to 12. Thus, it can be explained that the block number of the latest block that the target consensus node has already agreed to pass is updated to the maximum block number, and the consensus passing evidence of the latest block that the target consensus node has already agreed to pass is updated to the consensus passing evidence that the corresponding block number is the maximum block number.

It should be noted that, after the second block number is updated, the subsequent view change message sent by the target consensus node to other consensus nodes in the blockchain system may include a new second block number, and a consensus passing proof corresponding to the new second block number. In addition, the target consensus node may synchronize the consensus passing proof of the block number greater than the new second block number and not greater than the block number of the latest block (i.e., the first block number) that the other consensus node has already agreed to pass when synchronizing the consensus passing proof of the block to some other consensus node in the blockchain system.

For any consensus node in the block chain system, by updating the block number of the latest block which is passed by the consensus node, when the consensus passing certification of the blocks is synchronized among all nodes in the block chain system, the data transmission quantity between the consensus node and other consensus nodes in the block chain system is reduced, and the synchronization efficiency of the consensus progress of the blocks is improved.

In some embodiments, taking any other consensus node except the target consensus node in the blockchain system as an example, the target consensus node may firstly construct a synchronization request message when implementing synchronization of the consensus passing certification of the first target block to the other consensus node, and when locally storing the consensus passing certification of the first target block, and send the synchronization request message to the other consensus node, where the synchronization request message may include the second block number (i.e., the block number of the latest block that the target consensus node has already commonly passed) and the first block number (i.e., the block number of the latest block that the other consensus node has already commonly passed). The other consensus node may respond to the synchronization request message, construct a synchronization response message corresponding to the synchronization request message, and return the synchronization response message to the target consensus node, where the synchronization response message may include a consensus proof of the first target block (i.e., a block having a block number greater than the second block number and not greater than the first block number). Accordingly, the target consensus node may obtain the synchronization response message returned by the other consensus nodes, and store the consensus passing certification of the first target block included in the synchronization response message locally in response to the synchronization response message.

In some embodiments, the synchronization request message sent by one consensus node to some other consensus node may be a FetchCheckPointPropof message, denoted < FETCHCHECKPOINPROOF, begin, end >. Wherein begin indicates that the add of 1 to the checkpoint of the consensus node is h (i.e., the checkpoint of the other consensus node) in the view change message sent by the other consensus node and received by the consensus node. Accordingly, the synchronization response message returned by the other consensus node to the consensus node may be a CheckPointProof message, denoted < checkpointpro, pro-vector >. Wherein the pro-vector stores the consensus proof of all blocks of block numbers from begin to end.

And 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, so that the target consensus node can synchronize the consensus of the block which is not in itself from the other consensus nodes according to the requirement of the target consensus node, and the synchronization of the target consensus node and the other consensus nodes on the consensus progress of the block is ensured.

In some embodiments, for any of the above-mentioned consensus nodes in the blockchain system, when receiving the ViewChange message sent by other consensus nodes in the blockchain system, the consensus node may not only synchronize the consensus passing proof of the block to the other consensus nodes, but also start to perform view switching when receiving at least 2f+1 ViewChange messages (including the ViewChange message generated by itself). First, the consensus node may determine whether the node is elected as a new master node after the view switch, for example: a calculation may be performed according to the formula p=v+1 mod|r| to determine if the present node is the new master node after the view switch.

If the target consensus node determines that the target consensus node is elected as a new master node after view switching, the target consensus node may determine the starting block number h from the block numbers contained in at least 2f+1 view change messages received by the target consensus node.

It should be noted that, for all the consensus nodes in the blockchain system, the block number included in the ViewChange message sent by at least one honest node of the consensus nodes is not less than the starting block number h. That is, there is at least one honest node in the blockchain system, and the honest node has commonly recognized the block number of the latest block passing through the honest node is not less than the starting block number h. If one honest node in the blockchain system passes through for a block consensus, then other consensus nodes in the blockchain system are considered to pass through for that block as well. Thus, for any block whose block number is less than the starting block number h, all consensus nodes in the blockchain system can be considered to pass through in common for that block. In this case, the starting block number h can be considered as an honest, reliable checkpoint, and thus can be used as the basis for the decision.

The target consensus node can also synchronize the consensus passing evidence of the block to other consensus nodes in the process of collecting the ViewChange message, so that the target consensus node can determine the final checkpoint based on the synchronized consensus passing evidence of the block. Specifically, in the case where the above-mentioned start block number H is determined, the target consensus node may determine whether there is a set of consensus passing proofs in which the corresponding block number is kept continuously increasing with respect to the start block number H in the locally stored consensus passing proofs, and if there is, may further determine a maximum block number among the block numbers corresponding to the respective consensus passing proofs in the set of consensus passing proofs, and determine the maximum block number as the end block number H corresponding to the start block number H.

In the case where the start block number H and the end block number H are determined, 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 located in the interval H, H and the common-knowledge passing credentials of the corresponding block (i.e. one block number corresponds to one common-knowledge passing credential).

In some embodiments, the NewView message sent by the new master node after the view switch may be expressed as < NewView, v+1, h, proofmap, vset, xset >. Where h represents the final checkpoint determined by the new master node, proofmap is the mapping from each block number in the range from the base 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 received 2f+1 ViewChange messages, xset is the block number within the interval (h, h+l) but the consensus is not reached yet, where L is the maximum number of parallelism of the consensus instance (also referred to as the length of the consensus window).

For a block with a block number k (h < k.ltoreq.h+L), a block may be put into xset as described above if the block meets any one of three conditions:

1. the received 2f+1 ViewChange messages contain checkpoints less than k, and each ViewChange message contains pset with block k; or, the received 2f+1 view change messages all contain checkpoints smaller than k, and the view numbers of all tiles in the pset contained in each view change message are smaller than the view number of the tile k.

2. At least f+1 ViewChange messages in the received 2f+1 ViewChange messages contain qset with block k.

3. Block k is a block that the new master node has not agreed to pass (i.e., 2f+1 Commit messages corresponding to block k have not been received).

For block k that does not meet the above three conditions, the new master node may consider that the transaction contained in that block is constructed by a disqualified node, so that the transaction contained in that block may be emptied and then put into xset.

That is, the above three conditions can be regarded as validity verification rules for the block for which the consensus has not been reached.

In some embodiments, for a blockchain system with a PBFT algorithm as the consensus protocol, the number of consensus nodes in the blockchain system may be denoted as 3f+1, where there are at least 2f+1 honest nodes and at most f disqualified nodes, where f represents the fault tolerance threshold of the PBFT algorithm for the consensus nodes. In this case, when the target consensus node determines the starting block number h from the block numbers included in the received at least 2f+1 view change messages, the block numbers included in the at least 2f+1 view change messages received by the target consensus node may be specifically sorted according to the order from large to small, and the f+1st block number in the sorted block numbers may be obtained as the starting block number h.

In some embodiments, before determining whether there is a set of locally stored common passing certificates for which the corresponding block number remains continuously incremented relative to the starting block number h, the target common node may determine whether the block number of the latest block that the node has already passed through in common (i.e., the second block number) is smaller than the starting block number h, and if so, may synchronize the block data and the common passing certificates of some blocks (which may be referred to as second target blocks) to other common nodes. The second target block is a block with a block number greater than the second block number and not greater than the starting block number h (i.e., the second block number is less than or equal to the block number h). It should be noted that all blocks with a block number greater than the second block number and not greater than the starting block number h can be used as the second target block.

By synchronizing the block data and the common passing evidence of all blocks with the block number larger than the second block number and not larger than the starting block number h to other common nodes in the blockchain system by the target common node serving as a new master node after view switching, all nodes in the blockchain system can be ensured to have the block data and the common passing evidence of the blocks, so that the blocks are ensured to have common passing and successfully come out of the blocks in the blockchain system.

Accordingly, in some embodiments, if the target consensus node determines that the target consensus node is not elected as a new master node after the view switch, the target consensus node may receive NewView messages sent by other consensus nodes in the blockchain system that are new master nodes after the view switch. The NewView message may include an ending block number H 'determined by the new master node, and a mapping relationship between each block number located in the interval [ H', H '] and the common passing evidence of the corresponding block, where H' is a starting block number determined by the new master node.

The target consensus node may determine whether the target consensus node receives at least 2f+1 view change messages in response to the received NewView messages, and if so, may determine a valid block number from the block numbers included in the at least 2f+1 view change messages received by the target consensus node. For all the consensus nodes in the blockchain system, the block number contained in the ViewChange message sent by at least one honest node in the consensus nodes is not smaller than the valid block number.

When the valid block number is determined, the target consensus node may determine whether the valid block number is lower than the ending block number H' included in the NewView message, and if so, may search for a consensus passing proof of some blocks (these blocks may be referred to as a third target block) from the mapping relationship included in the NewView message. The third target block is a block whose block number is greater than the effective block number and is not greater than the ending block number H '(i.e., the effective block number < block number +.h') included in the NewView message. It should be noted that, all blocks with block numbers greater than the effective block number and not greater than the ending block number H' can be used as the third target block.

If the consensus passing evidence of the third target block is found from the mapping relation contained in the NewView message, the target consensus node may locally store the found consensus passing evidence of the third target block, and accept the NewView message to complete view switching. Further, the target consensus node may verify the found consensus passing proof of the third target block, store the consensus passing proof of the third target block after the verification passes, and accept the NewView message to complete the view switching.

In some embodiments, similar to the foregoing, the target consensus node may determine whether the Pre-preparation message of the third target block exists locally after the found consensus of the third target block is stored locally through proof. If there is no Pre-preparation message of the third target block locally, the target consensus node may synchronize the Pre-preparation message of the third target block to other consensus nodes in the blockchain system, that is, synchronize the original content of the transaction contained in the third target block to other consensus nodes in the blockchain system.

In some embodiments, similar to the foregoing, when the target consensus node determines the valid block number from the block numbers included in the received at least 2f+1 view change messages, the block numbers included in the at least 2f+1 view change messages received by the target consensus node may be specifically sorted in the order from the big to the small, and the f+1st block number in the sorted block numbers is obtained as the valid block number.

In some embodiments, after the view switch is completed, the new master node reinitiates the consensus for the transactions contained in the block for which the consensus has not been reached in the previous view.

Specifically, since the checkpoint represents the block number of the latest block that has already been agreed to pass, if the target consensus node determines that the target consensus node is elected as a new master node after the view switch, the target consensus node may send a Pre-preparation message for a block whose block number is greater than the checkpoint or the second block number to other consensus nodes in the blockchain system according to the determined final checkpoint or the second block number, so as to initiate the consensus of the transaction included in the block whose block number is greater than the checkpoint or the second block number.

If the target consensus node determines that the node is not elected as a new master node after view switching, the target consensus node may respond to a received Pre-preparation message sent by the new master node, determine whether a locally stored consensus passing evidence of the block exists according to the block contained in the Pre-preparation message, and if so, may not broadcast the preparation message corresponding to the Pre-preparation message to other consensus nodes in the blockchain system, that is, the target consensus node may not vote on the block any more, thereby aborting repeated voting.

In some embodiments, similar to the foregoing, for any locally stored consensus passing certificate, the target consensus node may synchronize the Pre-preparation message including the block with other consensus nodes in the blockchain system and store the synchronized Pre-preparation message locally according to the block corresponding to the consensus passing certificate and determining whether the Pre-preparation message including the block is stored locally. That is, 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 the same locally to avoid a subsequent failure to normally execute the transaction contained in the block.

Referring to fig. 5, fig. 5 is a schematic view illustrating a structure of an apparatus according to 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 storage 510, although other hardware may be included as desired. One or more embodiments of the application may be implemented in a software-based manner, such as by the processor 502 reading a corresponding computer program from the non-volatile storage 510 into the memory 508 and then running. Of course, in addition to software implementation, one or more embodiments of the present application do not exclude other implementation, such as a logic device or a combination of software and hardware, etc., that is, the execution subject of the following process flows is not limited to each logic module, but may also be hardware or a logic device.

Referring to fig. 6, fig. 6 is a schematic diagram illustrating an architecture of a consensus node in a blockchain system according to an exemplary embodiment of the present application.

The application also provides an embodiment of the common node in the blockchain system, in this embodiment, the common node in the blockchain system may be a device as shown in fig. 5, so as to implement the technical scheme of the application. Wherein the blockchain system includes a plurality of consensus nodes.

The consensus node is any target consensus node in the blockchain system, as shown in fig. 6, specifically may include:

the first receiving unit 602 receives the ViewChange message sent by other consensus nodes in response to the fact that the current round of consensus meets the ViewChange condition; the ViewChange message comprises a first block number of a latest block which is already commonly recognized by the other commonly recognized nodes and a commonly recognized passing evidence of the latest block;

a first determining unit 604, configured to determine, in response to a received ViewChange message sent by the other consensus node, whether a second block number of a latest block that has been commonly recognized by the node is smaller than the first block number included in the ViewChange message;

a first synchronization unit 606, if the second block number is smaller than the first block number, synchronizing the consensus passing evidence of the first target block to other consensus nodes, and storing the consensus passing evidence of the first target block locally; the first target block is a block with a block number larger than the second block number and not larger than the first block number.

Optionally, the synchronization unit 606:

sending a synchronization request message to other consensus nodes; the synchronization request message is used for synchronizing the consensus passing certification of the first target block to the other consensus nodes;

Acquiring synchronous response messages corresponding to the synchronous request messages returned by the other consensus nodes; wherein the synchronization response message includes a consensus passing attestation of the first target block;

and responding to the synchronous response message, and storing the consensus passing evidence of the first target block contained in the synchronous response message locally.

Optionally, the consensus node further comprises:

and the first storage unit responds to the received ViewChange message sent by the other consensus nodes, and stores the consensus passing certification contained in the ViewChange message locally.

Optionally, the consensus node further comprises:

the first sending unit is used for sending a ViewChange message to other consensus nodes in response to the fact that the current round of consensus meets the ViewChange condition; wherein the ViewChange message includes the second block number and the consensus of the latest block is verified.

Optionally, the consensus node further comprises:

a second determining unit, configured to determine whether a locally stored consensus passing evidence set in which a corresponding block number is continuously incremented relative to the second block number exists before sending a ViewChange message to other consensus nodes;

And the updating unit is used for determining the maximum block number in the block numbers corresponding to the consensus passing certification in the consensus passing certification set if the block numbers exist, and updating the second block number based on the maximum block number.

Optionally, the consensus node further comprises:

a third determining unit, configured to determine a start block number h from the block numbers contained in the received at least 2f+1 view change messages, if the node is selected as a new master node after view switching; wherein, the block number contained in the ViewChange message sent by at least one honest node in the consensus nodes is not less than the initial block number;

a fourth determining unit that determines whether there is a common-knowledge passing evidence set in which the corresponding block number is kept continuously increasing with respect to the start block number in the locally stored common-knowledge passing evidence; if so, determining the maximum block number in the block numbers corresponding to the consensus passing evidence in the consensus passing evidence set, and determining the maximum block number as an ending block number H corresponding to the starting block number;

the second sending unit sends a NewView message to other consensus nodes; the NewView message includes the ending block number, and a mapping relationship between each block number located in the interval [ H, H ] and the common passing evidence of the corresponding block.

Optionally, the third determining unit:

sequencing the block numbers contained in the received at least 2f+1 ViewChange messages according to the sequence from large to small, and acquiring the f+1th block number in the sequenced block numbers as a starting block number h; where f represents the fault tolerance threshold of the PBFT algorithm for the consensus node.

Optionally, the consensus node further comprises:

a fifth determining unit configured to determine whether the second block number is smaller than the start block number before determining whether there is a set of common-knowledge passing proofs in which the corresponding block number is kept continuously incremented with respect to the start block number in the locally stored common-knowledge passing proofs; if so, synchronizing the block data of the second target block and the consensus passing certification to other consensus nodes; the second target block is a block with a block number greater than the second block number and not greater than the starting block number.

Optionally, the consensus node further comprises:

the second receiving unit is used for receiving a NewView message sent by a new master node after view switching if the node is not elected as the new master node;

a sixth determining unit, configured to determine, in response to the received NewView message, whether the node receives at least 2f+1 view change messages; if yes, determining an effective block number from the block numbers contained in the received at least 2f+1 ViewChange messages; wherein, the block number contained in the ViewChange message sent by at least one honest node in the consensus nodes is not less than the effective block number;

A second storage unit for determining whether the effective block number is lower than the ending block number contained in the NewView message; if so, searching the consensus passing evidence of a third target block from the mapping relation contained in the NewView message; if the consensus passing evidence of the third target block is found from the mapping relation, the consensus passing evidence of the third target block is stored locally, and the NewView message is accepted to complete view switching; wherein the third target block is the ending block number contained in the NewView message and has a block number greater than the valid block number.

Optionally, the sixth determining unit:

and sequencing the block numbers contained in the received at least 2f+1 ViewChange messages according to the sequence from big to small, and acquiring the f+1st block number in the sequenced block numbers as the effective block number.

Optionally, the consensus node further comprises:

a seventh determining unit, configured to determine, in response to a received Pre-preparation message sent by the new master node, whether there is a common-knowledge passing certificate corresponding to a block included in the Pre-preparation message in a locally stored common-knowledge passing certificate; if so, the Prepaper message corresponding to the Prepaper message is not broadcasted and sent to other consensus nodes.

Optionally, the consensus node further comprises:

a second synchronization unit for determining whether a Pre-preparation message including a block corresponding to the locally stored consensus passing certificate is locally stored; if not, synchronizing the PrePrePrecure message containing the block corresponding to the consensus passing certification with other consensus nodes, and storing the PrePrePrecure message locally.

The present application also provides an embodiment of a blockchain system, comprising a plurality of consensus nodes, wherein:

In the 90 s of the 20 th century, improvements to one technology could clearly be distinguished as improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software (improvements to the process flow). However, with the development of technology, many improvements of the current method flows can be regarded as direct improvements of hardware circuit structures. Designers almost always obtain corresponding hardware circuit structures by programming improved method flows into hardware circuits. Therefore, an improvement of a method flow cannot be said to be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (e.g., field programmable gate array (Field Programmable Gate Array, FPGA)) is an integrated circuit whose logic function is determined by the programming of the device by a user. A designer programs to "integrate" a digital system onto a PLD without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, such programming is mostly implemented with "logic compiler" software, which is similar to the software compiler used in program development and writing, and the original code before the compiling is also written in a specific programming language, which is called hardware description language (Hardware Description Language, HDL), but not just one, but a plurality of kinds, 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., VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog are most commonly used at present. It will also be apparent to those skilled in the art that a hardware circuit implementing the logic method flow can be readily obtained by merely slightly programming the method flow into an integrated circuit using several of the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, 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 (Application Specific Integrated Circuit, ASIC), programmable logic controllers, and embedded microcontrollers, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic of the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller in a pure computer readable program code, it is well possible to implement the same functionality by logically programming the method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Such a controller may thus be regarded as a kind of hardware component, and means for performing various functions included therein may also be regarded as structures within the hardware component. Or even means for achieving the various functions may be regarded as either software modules implementing the methods or structures within hardware components.

The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation device is a server system. Of course, the application does not exclude that as future computer technology advances, the computer implementing the functions of the above-described embodiments may be, for example, a personal computer, a laptop computer, a car-mounted human-computer interaction device, a cellular telephone, 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.

Although one or more embodiments of the application provide method operational steps as described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps recited in the embodiments is merely one way of performing the order of steps and does not represent a unique order of execution. When implemented in an actual device or end product, the instructions may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even in a distributed data processing environment) as illustrated by the embodiments or by the figures. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, it is not excluded that additional identical or equivalent elements may be present in a process, method, article, or apparatus that comprises a described element. For example, if first, second, etc. words are used to indicate a name, but not any particular order.

For convenience of description, the above devices are described as being functionally divided into various modules, respectively. Of course, when implementing one or more of the present application, the functions of each module may be implemented in the same piece or pieces of software and/or hardware, or a module that implements the same function may be implemented by a plurality of sub-modules or a combination of sub-units, or the like. The above-described apparatus embodiments are merely illustrative, for example, the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other forms.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may 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, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

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

The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer 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, read only compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

One skilled in the relevant art will recognize that one or more embodiments of the application may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of the application may take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

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

The embodiments of the present application are described in a progressive manner, and the same and similar parts of the embodiments are all referred to each other, and each embodiment is mainly described in the differences from the other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, as relevant to see a section of the description of method embodiments. In the description of the present application, a description of the terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present application. In the present application, the schematic representations of the above terms are not necessarily for the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, the various embodiments or examples described herein, as well as the features of the various embodiments or examples, may be combined and combined by those skilled in the art without contradiction.

The foregoing description is only illustrative of one or more embodiments of the application and is not to be construed as limiting the application. Various modifications and alterations to one or more embodiments of the application will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, etc. which come within the spirit and principles of the application are desired to be covered by 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:

2. The method of claim 1, synchronizing the consensus passing evidence of the first target block to other consensus nodes and storing the consensus passing evidence of the first target block locally, comprising:

3. The method of claim 1, the method further comprising:

and responding to the received ViewChange message sent by the other consensus nodes, and storing the consensus contained in the ViewChange message locally through proving.

4. The method of claim 1, the method further comprising:

responding to the fact that the round of consensus meets the ViewChange condition, and sending ViewChange information to other consensus nodes; wherein the ViewChange message includes the second block number and the consensus of the latest block is verified.

5. The method of claim 4, further comprising, prior to sending the ViewChange message to the other consensus node:

determining whether a corresponding block number maintains a continuously increasing set of consensus passing proofs relative to the second block number in the locally stored consensus passing proofs;

and if the block numbers exist, determining the maximum block number in the block numbers corresponding to the consensus passing certification in the consensus passing certification set, and updating the second block number based on the maximum block number.

6. The method of claim 1, the method further comprising:

if the node is selected as a new master node after view switching, determining a starting block number h from 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 in the consensus nodes is not less than the initial block number;

determining whether a corresponding block number maintains a continuously increasing consensus passing evidence set relative to the initial block number in a locally stored consensus passing evidence; if so, determining the maximum block number in the block numbers corresponding to the consensus passing evidence in the consensus passing evidence set, and determining the maximum block number as an ending block number H corresponding to the starting block number;

Transmitting a NewView message to other consensus nodes; the NewView message includes the ending block number, and a mapping relationship between each block number located in the interval [ H, H ] and the common passing evidence of the corresponding block.

7. The method of claim 6, wherein determining a starting block number h from the block numbers contained in the received at least 2f+1 ViewChange messages comprises:

8. The method of claim 6, prior to determining whether there is a set of locally stored common-knowledge-passing certificates for which the corresponding block number remains continuously incremented relative to the starting block number, further comprising:

determining whether the second block number is less than the starting block number; if so, synchronizing the block data of the second target block and the consensus passing certification to other consensus nodes; the second target block is a block with a block number greater than the second block number and not greater than the starting block number.

9. The method of claim 6, the method further comprising:

if the node is not elected as a new master node after view switching, receiving a NewView message sent by the new master node;

determining whether the node receives at least 2f+1 ViewChange messages or not in response to the received NewView messages; if yes, determining an effective block number from the block numbers contained in the received at least 2f+1 ViewChange messages; wherein, the block number contained in the ViewChange message sent by at least one honest node in the consensus nodes is not less than the effective block number;

determining whether the effective block number is lower than the ending block number contained in the NewView message; if so, searching the consensus passing evidence of a third target block from the mapping relation contained in the NewView message; if the consensus passing evidence of the third target block is found from the mapping relation, the consensus passing evidence of the third target block is stored locally, and the NewView message is accepted to complete view switching; wherein the third target block is the ending block number contained in the NewView message and has a block number greater than the valid block number.

10. The method of claim 9, determining a valid block number from block numbers contained in the received at least 2f+1 ViewChange messages, comprising:

11. The method of claim 6, the method further comprising:

responding to the received Pre-preparation message sent by the new master node, and determining whether a locally stored consensus passing evidence exists in the consensus passing evidence corresponding to a block contained in the Pre-preparation message; if so, the Prepaper message corresponding to the Prepaper message is not broadcasted and sent to other consensus nodes.

12. The method of any one of claims 1-11, the method further comprising:

determining whether a Pre-preparation message containing a block corresponding to the locally stored consensus passing certificate is stored locally; if not, synchronizing the PrePrePrecure message containing the block corresponding to the consensus passing certification with other consensus nodes, and storing the PrePrePrecure message locally.

13. A consensus node, the consensus node being any target consensus node in a blockchain system, comprising:

14. A blockchain system comprising a plurality of consensus nodes, wherein: