A consensus method and a consensus node in a blockchain system, and a blockchain system

Abstract

This application provides one or more embodiments of a consensus method and consensus node in a blockchain system, and a blockchain system. The method is applied to any target consensus node participating in the consensus in the blockchain system, and includes: collecting a block certificate corresponding to the h-th block in the blockchain, which is included in the consensus message broadcast by each consensus node during the consensus process for any block number corresponding to any block number in the block number range [h+1, h+L]. The block certificate is used to indicate that the transaction contained in the h-th block has been successfully executed; L represents a preset offset value corresponding to the block number range; in response to collecting N block certificates corresponding to the h-th block sent by different consensus nodes, after the consensus for the h+L-th block in the blockchain is completed, continuing to initiate consensus for the h+L+1-th block in the blockchain; N is a preset threshold.

Description

Technical Field

[0001] One or more embodiments of this application relate to the field of blockchain technology, and more particularly to a consensus method and consensus node in a blockchain system, and a blockchain system. Background Technology

[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus protocols, and cryptographic algorithms. In a blockchain system, data blocks are sequentially linked together to form a chain-like data structure, and a distributed ledger is cryptographically guaranteed to be immutable and unforgeable. Due to its decentralized, immutable, and autonomous characteristics, blockchain is becoming increasingly widely used. Summary of the Invention

[0003] This application provides one or more embodiments of a consensus method and consensus node in a blockchain system, and the blockchain system includes:

[0004] A consensus method in a blockchain system, applied to any target consensus node participating in the consensus process within the blockchain system, includes:

[0005] During the consensus process of each consensus node, when reaching a consensus on any block number within the block number range [h+1, h+L], the consensus message broadcast by the nodes contains the block certificate corresponding to the h-th block in the blockchain; wherein, the block certificate is used to indicate that the transaction contained in the h-th block has been successfully executed; and L represents a preset offset value corresponding to the block number range.

[0006] In response to the collection of N identical block credentials corresponding to the h-th block sent by different consensus nodes, after the consensus for the (h+L)-th block in the blockchain is completed, a consensus for the (h+L+1)-th block in the blockchain is initiated; where N is a preset threshold.

[0007] A consensus node in a blockchain system includes:

[0008] The message collection unit collects the block credentials corresponding to block h in the blockchain, which are broadcast by each consensus node during the consensus process for any block number within the block number range [h+1, h+L]. The block credentials indicate that the transaction contained in block h has been successfully executed; L represents a preset offset value corresponding to the block number range.

[0009] The consensus initiating unit, in response to collecting N identical block credentials corresponding to the h-th block sent by different consensus nodes, after the consensus for the (h+L)-th block in the blockchain is completed, continues to initiate consensus for the (h+L+1)-th block in the blockchain; where N is a preset threshold.

[0010] A blockchain system comprising consensus nodes, wherein any target consensus node:

[0011] During the consensus process of each consensus node, when reaching a consensus on any block number within the block number range [h+1, h+L], the consensus message broadcast by the nodes contains the block certificate corresponding to the h-th block in the blockchain; wherein, the block certificate is used to indicate that the transaction contained in the h-th block has been successfully executed; and L represents a preset offset value corresponding to the block number range.

[0012] In response to the collection of N identical block credentials corresponding to the h-th block sent by different consensus nodes, after the consensus for the (h+L)-th block in the blockchain is completed, a consensus for the (h+L+1)-th block in the blockchain is initiated; where N is a preset threshold.

[0013] In the above embodiments, the target consensus node in the blockchain system can collect the block credentials included in the consensus messages broadcast by various consensus nodes during the consensus process for any block number in the block number range [h+1, h+L], which indicate that the transactions contained in block h have been successfully executed. In response to collecting enough identical block credentials sent by different consensus nodes corresponding to block h, after the consensus for block h+L is completed, the target consensus node can continue to initiate the consensus for block h+L+1.

[0014] Using the above method, since the existence of block credentials does not affect the normal execution of consensus messages, during the consensus process for any block number within the block number range [h+1, h+L] based on the consensus message itself, the finalization of block h can also be completed based on the block credentials contained in the consensus message, which indicate that the transactions contained in block h have been successfully executed. Therefore, for each block, there is no longer a need for an additional round of communication independent of the communication in the consensus process to complete the finalization of that block; instead, the finalization of that block can be completed using the communication in the consensus process. Firstly, this reduces the types of messages transmitted between consensus nodes in the blockchain system, making the system simpler and reducing the possibility of errors. Secondly, it avoids the instability of communication that could lead to a decrease in system efficiency. Thirdly, when consensus for block h+L is completed, there is no longer a need to wait for the finalization of block h to be completed; instead, consensus for block h+L+1 can begin seamlessly, thus ensuring a smooth progress of consensus. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a schematic diagram illustrating a blockchain system according to an exemplary embodiment of this application;

[0017] Figure 2 This is a schematic diagram of the regular phases of the PBFT protocol in related technologies;

[0018] Figure 3 This is a flowchart illustrating a consensus method in a blockchain system according to an exemplary embodiment of this application;

[0019] Figure 4 This is a schematic diagram illustrating a conventional phase of a PBFT protocol according to an exemplary embodiment of this application;

[0020] Figure 5 This is a schematic diagram of the structure of a device shown in an exemplary embodiment of this application;

[0021] Figure 6 This is a schematic diagram of the architecture of a consensus node in a blockchain system, as illustrated in an exemplary embodiment of this application. Detailed Implementation

[0022] 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 with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0023] Blockchain is generally classified into three types: public blockchain, private blockchain, and consortium blockchain. Furthermore, combinations of these types are possible, such as a combination of private and consortium blockchains, or a combination of consortium and public blockchains.

[0024] Of the three types of blockchains mentioned above, public blockchains offer the highest degree of decentralization. Participants in a public blockchain (also known as nodes in the blockchain) can read data records on the chain, participate in transactions, and compete for the right to record new blocks. Moreover, nodes can freely join or leave the network and perform related operations.

[0025] In contrast, private blockchains have write permissions controlled by a specific organization or institution, and data read permissions are governed by the organization's regulations. That is, a private blockchain can be viewed as a weakly centralized system, with strict restrictions on the number of nodes and a relatively small number of nodes. This type of blockchain is more suitable for use within specific organizations.

[0026] Consortium blockchains fall between public and private blockchains, enabling "partial decentralization." Each node in a consortium blockchain typically has a corresponding entity or organization; nodes join the network through authorization and form a consortium of stakeholders to jointly maintain the operation of the blockchain.

[0027] Please refer to Figure 1 , Figure 1 This is a schematic diagram illustrating a blockchain system according to an exemplary embodiment of this application.

[0028] like Figure 1 As shown, a blockchain system can maintain one or more blockchains (e.g., public blockchain, private blockchain, consortium blockchain, etc.) and can contain multiple blockchain nodes to host the aforementioned one or more blockchains; for example, such as Figure 1 The blockchain nodes 1, 2, 3, 4, and i shown can collectively support one or more blockchains. Cross-chain data access is also possible between the blockchains contained within each blockchain system, and between different blockchain systems themselves.

[0029] 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 shown, 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 based on virtualization technology. Each blockchain node can be coupled together to form a network through various types of communication methods (e.g., TCP / IP) to carry one or more blockchains.

[0030] Based on the fundamental characteristics of blockchain, a blockchain is typically composed of several blocks. Each of these blocks records a timestamp corresponding to the time of its creation. All blocks strictly follow the timestamps recorded in the blocks, forming a time-ordered data chain.

[0031] 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 this transaction, and execute the transaction after the consensus is completed. In this way, the transaction and the execution result can be persistently stored in the blockchain.

[0032] In a blockchain system, different participants can establish a distributed blockchain network through their deployed nodes. The decentralized (or multi-centralized) distributed ledger, constructed using a chain-like block structure, is stored on each node (or a majority of nodes, such as consensus nodes) in the distributed blockchain network. This type of blockchain system needs to address the consistency and correctness of the ledger data across multiple decentralized (or multi-centralized) nodes. Each node in the blockchain system runs a blockchain program. With certain fault tolerance requirements, a consensus protocol ensures that all loyal nodes have the same transactions, thereby guaranteeing consistent execution results for the same transactions across all loyal nodes. The transactions and execution results are then packaged into blocks.

[0033] Current mainstream consensus protocols include Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPoS), Practical Byzantine Fault Tolerance (PBFT), and Honey Badger Byzantine Fault Tolerance (HoneyBadgerBFT). These consensus protocols can generally be divided into asynchronous and non-asynchronous consensus protocols. For example, the PBFT algorithm is a semi-synchronous protocol, while the HoneyBadgerBFT algorithm is an asynchronous protocol.

[0034] Taking the PBFT algorithm as an example, proposed by Miguel Castro and Barbara Liskov in 1999, it solved the problem of low efficiency in the original Byzantine fault-tolerant algorithm, reducing the algorithm complexity from exponential to polynomial, making the Byzantine fault-tolerant algorithm feasible in practical system applications. This paper was published at the 1999 International Conference on Operating System Design and Implementation (OSDI99). In the PBFT algorithm, all replicas operate in a succession of configuration process called a view. In a view, one replica acts as the primary node, and the other replicas act as backup nodes. Views are consecutively numbered integers. The primary node 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. This algorithm assumes that when at most f replicas (i.e., nodes) fail, a total of at least 3f+1 replicas can guarantee safety and liveness in an asynchronous system. The set of replicas required to ensure data consistency and fault tolerance for all replicas is generally the set of the majority of nodes in the distributed system, forming a majority (Quorum). For example, when 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.

[0035] The PBFT protocol includes two phases: the Normal Case Phase and the View Change Phase. Figure 2This is a flowchart of the Normal Case Phase process. The Normal Case Phase mainly includes three stages: PRE-PREPARE, PREPARE, and COMMIT. Node 3 could, for example, represent a node that crashes. Figure 2 (Represented by ×). When the master node fails, a view change process needs to be initiated to adjust the state and replace the master node in the event of a system failure. If the master node goes offline or acts maliciously without broadcasting client requests, the client can set a timeout mechanism. If the timeout occurs, the client can broadcast a request message to all replica nodes. A replica node can also initiate a View Change Phase to replace the master node (often simply called "master replacement") after detecting that the master node is malicious or offline. Furthermore, the three-phase consensus process of PRE-PREPARE, PREPARE, and COMMIT may fail due to the master node making an incorrect proposal, or the PREPARE and COMMIT phases may fail to reach a consensus on the required number of quorum members (e.g., 2f+1 out of 3f+1 nodes, also known as the quorum). In these cases, a View Change Phase may also be initiated to replace the master node.

[0036] The PBFT algorithm is a semi-synchronous protocol, characterized by the assumption that the network is initially asynchronous but can synchronize at a certain point. The simplest way to achieve consensus among different nodes on the same proposal is to set a master node to unify the opinions of all nodes. A timer can be used to prevent the master node from malfunctioning. In the PBFT protocol, if the Normal Case Phase is not completed within a finite time, backups will initiate a View Change Phase to replace the master node. The PBFT protocol keeps the master node in one location; all requests can be sent to the master node first, and then broadcast to other consensus nodes.

[0037] In single-master-node protocols like PBFT, only the master node can initiate consensus proposals within a single consensus process; other nodes lack the ability to do so. Alternatively, if other nodes also have proposals, they must be forwarded to the master node, which then initiates the proposal on their behalf. The former approach is unfair to the consensus nodes' power in constructing blocks, while the latter, although allowing backup nodes to propose, increases the pressure on the master node's outgoing bandwidth. Neither approach is particularly suitable for scenarios where most consensus nodes need to initiate consensus proposals.

[0038] Specifically, all consensus nodes in a blockchain system can reach a consensus on the transactions contained in a new block to be connected to the chained block structure, based on a consensus protocol. This ensures that all consensus nodes agree on the content and order of the transactions contained in the block. After consensus is reached, each consensus node can execute the transactions contained in the block in sequence, and the block is finalized when the execution results of all consensus nodes are confirmed to be consistent. Finalization means that the transactions contained in the block have been executed and the execution results are accepted by all consensus nodes (or a certain number of consensus nodes, such as two-thirds of the consensus nodes).

[0039] In a blockchain system, each consensus node, upon completing the execution of transactions within a block that has reached consensus, can broadcast a message confirming that the block has achieved consensus and that all its transactions have been executed. Therefore, this message confirms the consistency of transaction execution results across consensus nodes for that block, allowing for the finalization of the block. In other words, for each block that has reached consensus, an additional round of communication, independent of the initial consensus process, is required to confirm the consistency of transaction execution results across consensus nodes, thus finalizing the block.

[0040] The aforementioned message has different names in different consensus protocols. Taking the PBFT algorithm as an example, this message is usually called a checkpoint message. Checkpointing is a garbage collection mechanism in the PBFT algorithm. The checkpoint message is used to confirm that a block has reached consensus and that the transactions it contains have been executed. The checkpoint message carries the block identifier and the execution results of the transactions contained in the block (also known as the proof of block execution, such as transaction receipts, world state, etc.). When a consensus node receives a Quorum number of checkpoint messages carrying the same block identifier, it can confirm whether the transaction execution results of each consensus node for the block corresponding to that block identifier are consistent, thus completing the finalization of the block. It will also clean up the consensus data (including cached consensus messages exchanged during the consensus process) related to the blocks that have reached consensus before this block that are stored locally.

[0041] In a blockchain, block height refers to the number of blocks linked together in a chain-like block structure. However, for any given block in the blockchain, its block height serves as its identifier. A block is typically considered to have two identifiers: the hash value of its block header and its block height. The hash value of the block header is obtained by performing a secondary hash calculation on the block header using algorithms such as SHA256. This hash value uniquely identifies a block, and any node in the blockchain system can independently obtain the hash value of the block header by performing a hash calculation on the block header. Block height refers to the block's position within the blockchain. While a block always has a defined and fixed height, a single block height does not always identify a unique block; two or more blocks may have the same block height, meaning they are vying for the same position in the blockchain.

[0042] In a blockchain, blocks are typically linked chronologically on a chain-like block structure; that is, the chain-like block structure is actually a time-ordered chain. In this case, the block height is usually set to an increasing value. For example, assuming the block height of the previous finalized block is h, then the block height of the next block to be reached for consensus is h+1; and so on.

[0043] Typically, consensus protocols in blockchain systems can be implemented using a sliding window approach. For example, a consensus window of length L can be set; assuming the block height of the block currently undergoing finalization is h, consensus can be reached on blocks with heights within the range [h+1, h+L]. However, when consensus is reached on the block with height h+L, if the finalization of the block with height h has not yet been completed, the progress of the consensus window will be blocked, preventing further block production and thus impacting the overall efficiency of the blockchain system.

[0044] In summary, in the relevant technologies, each block requires an additional round of communication independent of the communication during the consensus process to complete the finalization of that block. Furthermore, since consensus on new blocks only begins after the finalization of the current block is completed, this additional round of communication may block the progress of consensus. Continuing with the example above, consensus on blocks with height h+L+1 and beyond cannot begin until the finalization of the block at height h is completed; that is, the progress of consensus depends on the completion of the finalization of previous blocks.

[0045] This application provides a consensus method and consensus node in a blockchain system, and an embodiment of the blockchain system. In this embodiment, the target consensus node in the blockchain system can collect the block credentials included in the consensus messages broadcast by various consensus nodes during the consensus process for any block number in the block number range [h+1, h+L]. These credentials indicate that the transactions contained in block h have been successfully executed. Therefore, in response to collecting a sufficient number of identical block credentials corresponding to block h sent by different consensus nodes, after the consensus for block h+L is completed, the node can continue to initiate consensus for block h+L+1.

[0046] In practical implementation, after executing the transactions contained in block h of the blockchain, any consensus node in the aforementioned blockchain system can, during the consensus process for block k, broadcast a consensus message corresponding to block k but carrying a block credential corresponding to block h. This block credential can be used to indicate that the transactions contained in block h have been successfully executed. Block k can be any block number within the block number range [h+1, h+L]. L can represent a preset offset value corresponding to the block number range.

[0047] In the above scenario, the target consensus node can collect the block credentials corresponding to block h in the blockchain, which are broadcast and sent by various consensus nodes in the blockchain system during the consensus process for block k in the blockchain.

[0048] When the target consensus node completes consensus on block h+L in the aforementioned blockchain, it has already collected the block credential corresponding to block h in the blockchain. Therefore, in response to collecting N identical block credentials corresponding to block h in the blockchain sent by different consensus nodes, the target consensus node can, after completing consensus on block h+L in the blockchain, continue to initiate consensus on block h+L+1 in the blockchain. Here, N can be a preset threshold, specifically depending on how many consensus nodes acknowledge the transaction execution result of the block when its finality is considered complete.

[0049] Using the above method, since the existence of block credentials does not affect the normal execution of consensus messages, during the consensus process for any block number within the block number range [h+1, h+L] based on the consensus message itself, the finalization of block h can also be completed based on the block credentials contained in the consensus message, which indicate that the transactions contained in block h have been successfully executed. Therefore, for each block, there is no longer a need for an additional round of communication independent of the communication in the consensus process to complete the finalization of that block; instead, the finalization of that block can be completed using the communication in the consensus process. Firstly, this reduces the types of messages transmitted between consensus nodes in the blockchain system, making the system simpler and reducing the possibility of errors. Secondly, it avoids the instability of communication that could lead to a decrease in system efficiency. Thirdly, when consensus for block h+L is completed, there is no longer a need to wait for the finalization of block h to be completed; instead, consensus for block h+L+1 can begin seamlessly, thus ensuring a smooth progress of consensus.

[0050] Please refer to Figure 3 , Figure 3 This is a flowchart illustrating a consensus method in a blockchain system according to an exemplary embodiment of this application.

[0051] In this embodiment, the consensus method in the blockchain system described above can be applied to any consensus node (which may be referred to as the target consensus node) participating in the consensus in the blockchain system.

[0052] It should be noted that all consensus nodes in the aforementioned blockchain system can reach a consensus on a block based on the consensus message corresponding to the new block to be connected to the chain block structure.

[0053] This application provides an embodiment of a consensus method in a blockchain system, such as... Figure 3 As shown, it specifically includes:

[0054] Step 302: Collect the block credentials corresponding to block h in the blockchain that are broadcast in the consensus messages sent by each consensus node during the consensus process for any block number in the block number range [h+1, h+L]. The block credentials are used to indicate that the transaction contained in block h has been successfully executed. L represents a preset offset value corresponding to the block number range.

[0055] In this embodiment, a block number can be assigned to each block in the blockchain to identify the block; that is, one block number can identify one block. In practical applications, the block number can be the block height or a unique number corresponding to the hash value of the block header; this application does not impose any special restrictions on this.

[0056] In the aforementioned blockchain system, after executing the transactions contained in block h of the blockchain, any consensus node can broadcast a consensus message corresponding to block k, but carrying a block credential corresponding to block h, during the consensus process for block k. This block credential can indicate that the transactions contained in block h have been successfully executed; for example, the block credential can be the execution result of the transactions contained in block h. Block k can be any block number within the block number range [h+1, h+L]. L can represent a preset offset value corresponding to the block number range; for example, L can be the length of the consensus window set in a sliding window approach.

[0057] It should be noted that when consensus is reached for block h+L, most consensus nodes have usually completed the execution of the transactions contained in block h. Therefore, during the consensus process for block k in the blockchain, it is feasible to broadcast a consensus message that corresponds to block k but carries the block certificate corresponding to block h.

[0058] In practical applications, for any consensus node in the aforementioned blockchain system, the transaction execution service on that consensus node (which can be a thread responsible for executing the transactions contained in a block that has already reached consensus) can generate the aforementioned consensus message after executing the transactions contained in block h of the blockchain, and push the consensus message to the consensus service on that consensus node (which can be a thread responsible for reaching consensus on blocks). Thus, the consensus service on that consensus node can broadcast and send the consensus message during the consensus process for block k of the blockchain.

[0059] In the above scenario, the target consensus node can collect the block credentials corresponding to block h in the blockchain, which are broadcast and sent by various consensus nodes in the blockchain system during the consensus process for block k in the blockchain.

[0060] Since the consensus message mentioned above corresponds to block k, where k belongs to the interval [h+1, h+L], and this consensus message contains the block credential corresponding to block h, it can be guaranteed that when the consensus for block h+L is completed, the block credential corresponding to block h has already been collected, thus completing the finalization of block h. This means that when the consensus for block h+L is completed, there is no longer a need to wait for the finalization of block h to be completed; instead, consensus for block h+L+1 can begin seamlessly.

[0061] In one embodiment, after executing the transactions contained in block h of the blockchain system, any consensus node in the blockchain system can, during the consensus process for block h+L of the blockchain, broadcast a consensus message corresponding to block h+L, but carrying the block credential corresponding to block h. At this time, the target consensus node can collect the block credential corresponding to block h contained in the consensus message broadcast by each consensus node in the blockchain system during the consensus process for block h+L of the blockchain.

[0062] In other words, for each block, the block certificate corresponding to that block can be collected during the consensus process for the Lth block after that block. Therefore, it is possible to avoid collecting the block certificate too early, thus ensuring the smooth progress of consensus.

[0063] In one embodiment, when the target consensus node collects the block certificate corresponding to block h in the blockchain, which is broadcast in the consensus message sent by various consensus nodes in the blockchain system during the consensus process for block h+L within the block number range [h+1, h+L], it can specifically receive the consensus message broadcast by various consensus nodes in the blockchain system during the consensus process for block h+L within the block number range [h+1, h+L], and verify the block certificate corresponding to block h in the blockchain contained in the received consensus message; if the verification of the block certificate is successful, the block certificate contained in the consensus message can be saved, thereby completing the collection of the block certificate.

[0064] By verifying the block credentials contained in the consensus message, the correctness and reliability of the collected block credentials can be guaranteed, and abnormal block credentials can be avoided, thereby ensuring the normal and reliable progress of the consensus.

[0065] In one embodiment shown, the block certificate may include a digest value of block h in the blockchain. The digest value may be a hash value obtained by hashing block h. Furthermore, the block certificate may be signed (e.g., digitally signed) by the consensus node that sent the block certificate.

[0066] Since the target consensus node, as one of the participating consensus nodes, can also broadcast a consensus message carrying a block certificate corresponding to block h in the aforementioned blockchain, it can locally store the digest value of block h. In this case, when verifying the block certificate corresponding to block h contained in the received consensus message, the target consensus node can specifically perform signature verification on the block certificate and verify whether the locally stored digest value of block h is the same as the digest value in the block certificate. If the signature verification of the block certificate passes, and the locally stored digest value of block h is the same as the digest value in the block certificate, then the verification of the block certificate is confirmed to be successful. If the signature verification of the block certificate fails, or the locally stored digest value of block h is different from the digest value in the block certificate, then the verification of the block certificate is confirmed to be unsuccessful.

[0067] By including the digest value of the corresponding block in the block certificate and signing the block certificate, verification of the block certificate can be achieved through signature verification and digest value verification. Signature verification of the block certificate ensures that the collected block certificates were sent by trusted consensus nodes; verification of the digest value ensures the consistency of the blocks corresponding to the collected block certificates. Therefore, block certificates that fail verification can be considered as being sent by malicious nodes and ignored, avoiding the collection of abnormal block certificates and ensuring the normal and reliable progress of consensus.

[0068] Step 304: In response to the collection of N identical block credentials corresponding to the h-th block sent by different consensus nodes, after the consensus for the (h+L)-th block in the blockchain is completed, continue to initiate the consensus for the (h+L+1)-th block in the blockchain; where N is a preset threshold.

[0069] In this embodiment, when the target consensus node completes consensus for block h+L in the blockchain, it has already collected the block credentials corresponding to block h in the blockchain. Therefore, in response to collecting N identical block credentials sent by different consensus nodes corresponding to block h in the blockchain, the target consensus node can, after completing consensus for block h+L in the blockchain, continue to initiate consensus for block h+L+1 in the blockchain. Here, N can be a preset threshold, specifically depending on how many consensus nodes acknowledge the transaction execution result of a block to consider it finalized. For example, assuming the finalization rule set for the blockchain system is that the transactions contained in the block are completed and the transaction execution result is acknowledged by two-thirds of the consensus nodes, then the value of N can be two-thirds of the total number of consensus nodes in the blockchain system.

[0070] As mentioned earlier, finality refers to the completion of the execution of transactions contained in a block, and the acceptance of the transaction execution results by all consensus nodes (or a certain number of consensus nodes, such as two-thirds of the consensus nodes). That is, it needs to be confirmed that the transaction execution results of each consensus node for the transactions contained in the block are consistent. Therefore, when the target consensus node collects the block credentials corresponding to block h in the aforementioned blockchain, it can not only confirm whether it has collected N block credentials corresponding to block h in the blockchain sent by different consensus nodes in the blockchain system, but also confirm whether these N block credentials are identical. If it is confirmed that N identical block credentials corresponding to block h in the blockchain have been collected from different consensus nodes in the blockchain system, then the finality of block h in the blockchain can be considered complete.

[0071] In one embodiment shown, the block certificate may include the digest value of block h in the blockchain. Furthermore, the block certificate may be signed (e.g., digitally signed) by the consensus node that sent it.

[0072] In the above scenario, on the one hand, the target consensus node can verify whether these block credentials are identical by checking whether the digest value in the collected block credentials corresponding to block h in the blockchain is the same; on the other hand, the target consensus node can verify whether these block credentials were sent by different consensus nodes in the blockchain system by checking the signatures of the collected block credentials corresponding to block h in the blockchain. For example, it can use the keys corresponding to each consensus node in the blockchain system to perform signature verification on the collected block credentials, thereby confirming which consensus node sent the block credentials whose signatures have been verified.

[0073] In one embodiment shown, the consensus protocol supported by the aforementioned blockchain system may include multiple consensus phases. Accordingly, the block credential can be carried in the consensus messages exchanged between the consensus nodes in the blockchain system during any consensus phase of the consensus protocol. For example, assuming the blockchain system supports the PBFT protocol, as mentioned earlier, the PBFT protocol mainly includes three phases: pre-prepare, prepare, and commit. Therefore, the block credential can be carried in any of the pre-prepare, prepare, or commit messages exchanged during these three phases.

[0074] Specifically, for any consensus node in the aforementioned blockchain system, the consensus message in which consensus phase the node includes the block credential depends on when the node completes the execution of all transactions contained in the corresponding block. Taking the PBFT protocol as an example, if the consensus node completes the execution of all transactions in the block only after sending the prepare message exchanged during the prepare phase, then the node can include the block credential in the commit message exchanged during the commit phase.

[0075] It should be noted that the existence of block credentials does not affect the normal execution of consensus messages; that is, the consensus messages merely serve as carriers of block credentials. Taking the pre-prepare message in the PBFT protocol as an example, when a consensus node in the aforementioned blockchain system receives a pre-prepare message carrying a block credential, it can, on the one hand, verify the block credential to complete the collection of such block credentials and count the number of collected block credentials; on the other hand, it can continue to send prepare messages. These two operations are independent of each other and do not affect each other.

[0076] In one embodiment shown, L can be a configurable offset value. In this case, the user can configure the value of L according to actual needs, that is, the user can configure the length of the consensus window according to actual needs.

[0077] In one embodiment shown, the number of consensus nodes required to approve the transaction execution result of a block in the finalization rules set for the aforementioned blockchain system can depend on the fault tolerance threshold supported by the consensus protocol adopted by the blockchain system. Therefore, the value of N can range from [f+1, nf]. Here, f can represent the number of fault-tolerant nodes supported by the consensus protocol adopted by the aforementioned blockchain system, and n can represent the total number of consensus nodes in the blockchain system.

[0078] In one embodiment shown, the consensus protocol used by the blockchain system can be a Byzantine Fault Tolerance (BFT) protocol; the total number of consensus nodes in the blockchain system can be represented by 3f+1. In this case, the value of N can be in the range of [f+1, 2f+1]. Here, f can represent the number of Byzantine nodes tolerated by the consensus protocol used by the blockchain system.

[0079] In one embodiment shown, the consensus protocol used by the aforementioned blockchain system can be the PBFT protocol. As mentioned earlier, the PBFT protocol mainly includes three phases: pre-prepare, prepare, and commit. Therefore, the block certificate can be carried in any of the pre-prepare, prepare, or commit messages exchanged between these three phases. Further, as... Figure 2 As shown, in the PBFT protocol, the pre-prepare messages exchanged during the pre-prepare phase are sent by the master node in the blockchain system, the prepare messages exchanged during the prepare phase are sent by the backup nodes in the blockchain system, and the commit messages exchanged during the commit phase are sent by both the master node and the backup nodes in the blockchain system. Therefore, the master node can carry the block certificate in either the pre-prepare message or the commit message, while the backup node can carry the block certificate in either the prepare message or the commit message.

[0080] As mentioned earlier, the consensus message in which the master node and backup node in the aforementioned blockchain system carry the block certificate depends on when the master node and backup node have completed executing all the transactions contained in the corresponding block.

[0081] In practical applications, if the consensus protocol used by the aforementioned blockchain system is the PBFT protocol, then the target consensus node can be the master node in the PBFT protocol. Since any consensus node in the blockchain system can be called a master node in the PBFT protocol, the target consensus node can be any consensus node in the blockchain system.

[0082] Please combine Figure 2 ,refer to Figure 4 , Figure 4 This is a schematic diagram illustrating a conventional phase in a PBFT protocol according to an exemplary embodiment of this application.

[0083] like Figure 4As shown, the consensus protocol used in the above blockchain system can be the PBFT protocol. This blockchain system can include replicas 0, 1, 2, and 3. Replica 0 serves as the master node, and replicas 1, 2, and 3 serve as backup nodes; replica 3 can represent a failed node (…). Figure 4 (represented by ×).

[0084] Assuming the above-mentioned regular phase is the regular phase in which all consensus nodes in the blockchain system reach consensus on block k in the blockchain, where k belongs to the interval [h+1, h+L], and replica 0 has already executed the transactions contained in block h in the blockchain before the start of this regular phase, then replica 0 can carry the block certificate corresponding to block h in the pre-prepare message exchanged during the pre-prepare phase. Figure 4 (Represented by dashed lines with arrows). If Replica 2 has already executed the transactions contained in Block h before sending the prepare message during the prepare phase, it can include the block certificate corresponding to Block h in the prepare message during the prepare phase. Replica 1 executes the transactions contained in Block h only after sending the prepare message during the prepare phase and before sending the commit message during the commit phase. Therefore, it can include the block certificate corresponding to Block h in the commit message during the commit phase. This ensures that any consensus node in the blockchain system has collected the block certificate corresponding to Block h when consensus on Block h+L is completed, thus finalizing Block h.

[0085] In the above embodiments, the target consensus node in the blockchain system can collect the block credentials included in the consensus messages broadcast by various consensus nodes during the consensus process for any block number in the block number range [h+1, h+L], which indicate that the transactions contained in block h have been successfully executed. In response to collecting enough block credentials sent by different consensus nodes corresponding to block h, after the consensus for block h+L is completed, the target consensus node can continue to initiate the consensus for block h+L+1.

[0086] Using the above method, since the existence of block credentials does not affect the normal execution of consensus messages, during the consensus process for any block number within the block number range [h+1, h+L] based on the consensus message itself, the finalization of block h can also be completed based on the block credentials contained in the consensus message, which indicate that the transactions contained in block h have been successfully executed. Therefore, for each block, there is no longer a need for an additional round of communication independent of the communication in the consensus process to complete the finalization of that block; instead, the finalization of that block can be completed using the communication in the consensus process. Firstly, this reduces the types of messages transmitted between consensus nodes in the blockchain system, making the system simpler and reducing the possibility of errors. Secondly, it avoids the instability of communication that could lead to a decrease in system efficiency. Thirdly, when consensus for block h+L is completed, there is no longer a need to wait for the finalization of block h to be completed; instead, consensus for block h+L+1 can begin seamlessly, thus ensuring a smooth progress of consensus.

[0087] Please refer to Figure 5 , Figure 5 This is a schematic diagram illustrating the structure of a device according to an exemplary embodiment of this application. At the hardware level, the device includes a processor 502, an internal bus 504, a network interface 506, memory 508, and non-volatile memory 510, and may also include other necessary hardware. One or more embodiments of this application can be implemented in software, for example, the processor 502 reads the corresponding computer program from the non-volatile memory 510 into memory 508 and then runs it. Of course, besides software implementation, one or more embodiments of this application do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution entity of the following processing flow is not limited to individual logic modules, but can also be hardware or logic devices.

[0088] Please refer to Figure 6 , Figure 6 This is a schematic diagram of the architecture of a consensus node in a blockchain system, as illustrated in an exemplary embodiment of this application.

[0089] In this embodiment, the consensus node in the above-mentioned blockchain system can be as follows: Figure 5 The device shown is used to implement the technical solution of this application.

[0090] This application also provides an embodiment of a consensus node in a blockchain system, which can, as Figure 6 As shown, it includes:

[0091] The message collection unit 602 collects the block credentials corresponding to the h-th block in the blockchain, which are included in the consensus messages broadcast by each consensus node during the consensus process for any block number within the block number range [h+1, h+L]. The block credentials indicate that the transaction contained in the h-th block has been successfully executed; L represents a preset offset value corresponding to the block number range.

[0092] The consensus initiation unit 604, in response to collecting N block credentials corresponding to the h-th block sent by different consensus nodes, continues to initiate consensus for the h+L+1-th block in the blockchain after the consensus for the (h+L)-th block in the blockchain is completed; wherein, N is a preset threshold.

[0093] Optionally, the message collection unit 602:

[0094] During the consensus process of each consensus node in the block number range [h+1, h+L] for the h+Lth block, the block certificate corresponding to the hth block in the blockchain is included in the consensus message broadcast and sent by each consensus node.

[0095] Optionally, the message collection unit 602:

[0096] Receive consensus messages broadcast by various consensus nodes during the consensus process for the h+Lth block in the block number range [h+1, h+L].

[0097] The block credential contained in the consensus message is verified; if the verification of the block credential passes, the block credential contained in the consensus message is saved.

[0098] Optionally, the block certificate includes a digest value of the h-th block; and a signature for the digest value;

[0099] The message collection unit 602:

[0100] Verify the signature in the block certificate; and verify whether the digest value of the locally stored block h is the same as the digest value in the block certificate.

[0101] If the signature verification in the block certificate passes and the digest value of the locally stored block h is the same as the digest value in the block certificate, then the verification of the block certificate is confirmed to be successful.

[0102] If the signature verification for the block certificate fails, or if the digest value of the locally stored block h is different from the digest value in the block certificate, then the verification for the block certificate is confirmed to have failed.

[0103] Optionally, the consensus protocol supported by the blockchain system includes multiple consensus phases; the block certificate is contained in the consensus messages exchanged by each consensus node in any consensus phase of the consensus protocol.

[0104] Optionally, L is a configurable offset value.

[0105] Optionally, the value of N is in the range of [f+1, nf]; where f represents the number of fault-tolerant nodes supported by the consensus protocol adopted by the blockchain system; and n represents the total number of consensus nodes in the blockchain system.

[0106] Optionally, the consensus protocol adopted by the blockchain system is a Byzantine fault-tolerant protocol; the total number of consensus nodes in the blockchain system is represented by 3f+1; the value range of N is [f+1, 2f+1]; where f represents the number of Byzantine nodes tolerated by the consensus protocol adopted by the blockchain system.

[0107] Optionally, the consensus protocol adopted by the blockchain system is the PBFT protocol; the block certificate is contained in any one of the pre-prepare message, prepare message and commit message exchanged in the three phases of the PBFT protocol.

[0108] This application also provides an embodiment of a blockchain system, including consensus nodes, wherein any target consensus node:

[0109] During the consensus process of each consensus node, when reaching a consensus on any block number within the block number range [h+1, h+L], the consensus message broadcast by the nodes contains the block certificate corresponding to the h-th block in the blockchain; wherein, the block certificate is used to indicate that the transaction contained in the h-th block has been successfully executed; and L represents a preset offset value corresponding to the block number range.

[0110] In response to the collection of N block credentials corresponding to the h-th block sent by different consensus nodes, after the consensus for the (h+L)-th block in the blockchain is completed, the consensus for the (h+L+1)-th block in the blockchain is initiated; where N is a preset threshold.

[0111] Optionally, the target consensus node:

[0112] During the consensus process of each consensus node in the block number range [h+1, h+L] for the h+Lth block, the block certificate corresponding to the hth block in the blockchain is included in the consensus message broadcast and sent by each consensus node.

[0113] Optionally, the target consensus node:

[0114] Receive consensus messages broadcast by various consensus nodes during the consensus process for the h+Lth block in the block number range [h+1, h+L].

[0115] The block credential contained in the consensus message is verified; if the verification of the block credential passes, the block credential contained in the consensus message is saved.

[0116] Optionally, the block certificate includes a digest value of the h-th block; and a signature for the digest value;

[0117] The target consensus node:

[0118] Verify the signature in the block certificate; and verify whether the digest value of the locally stored block h is the same as the digest value in the block certificate.

[0119] If the signature verification in the block certificate passes and the digest value of the locally stored block h is the same as the digest value in the block certificate, then the verification of the block certificate is confirmed to be successful.

[0120] If the signature verification for the block certificate fails, or if the digest value of the locally stored block h is different from the digest value in the block certificate, then the verification for the block certificate is confirmed to have failed.

[0121] Optionally, the consensus protocol supported by the blockchain system includes multiple consensus phases; the block certificate is contained in the consensus messages exchanged by each consensus node in any consensus phase of the consensus protocol.

[0122] Optionally, L is a configurable offset value.

[0123] Optionally, the value of N is in the range of [f+1, nf]; where f represents the number of fault-tolerant nodes supported by the consensus protocol adopted by the blockchain system; and n represents the total number of consensus nodes in the blockchain system.

[0124] Optionally, the consensus protocol adopted by the blockchain system is a Byzantine fault-tolerant protocol; the total number of consensus nodes in the blockchain system is represented by 3f+1; the value range of N is [f+1, 2f+1]; where f represents the number of Byzantine nodes tolerated by the consensus protocol adopted by the blockchain system.

[0125] Optionally, the consensus protocol adopted by the blockchain system is the PBFT protocol; the block certificate is contained in any one of the pre-prepare message, prepare message and commit message exchanged in the three phases of the PBFT protocol.

[0126] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using a hardware physical module. For example, a Programmable Logic Device (PLD) (e.g., a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program a digital system themselves to "integrate" it onto a PLD, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, 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, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0127] The controller can be implemented in any suitable manner. For example, it 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: ARC625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, ASICs, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

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

[0129] While one or more embodiments of this application provide the method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded. For example, the use of terms such as "first," "second," etc., is used to denote names and does not indicate any particular order.

[0130] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of this application, the functions of each module can be implemented in the same or more software and / or hardware, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be indirect couplings or communication connections between devices or units through some interfaces, and may be electrical, mechanical, or other forms.

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

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

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

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

[0135] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0136] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. 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 technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0137] Those skilled in the art will understand that one or more embodiments of this application can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this application can take the form of a computer program product implemented 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.

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

[0139] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for system embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this application, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this application, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in a suitable manner in any one or more embodiments or examples. In addition, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this application and the features of different embodiments or examples.

[0140] The above description is merely an embodiment of one or more embodiments of this application and is not intended to limit the scope of the one or more embodiments of this application. For those skilled in the art, various modifications and variations can be made to the one or more embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of this application should be included within the scope of the claims.

Claims

1. A consensus method in a blockchain system, applied to any target consensus node participating in the consensus process within the blockchain system, comprising: During the consensus process of each consensus node, when reaching a consensus on any block number within the block number range [h+1, h+L], the consensus message broadcast by the nodes contains the block certificate corresponding to the h-th block in the blockchain; wherein, the block certificate is used to indicate that the transaction contained in the h-th block has been successfully executed; and L represents a preset offset value corresponding to the block number range. In response to the collection of N identical block credentials corresponding to the h-th block sent by different consensus nodes, after the consensus for the (h+L)-th block in the blockchain is completed, a consensus for the (h+L+1)-th block in the blockchain is initiated; where N is a preset threshold.

2. The method as described in claim 1, wherein collecting the block certificate corresponding to block h in the blockchain, which is included in the consensus message broadcast by each consensus node during the consensus process for any block number within the block number range [h+1, h+L], comprises: During the consensus process of each consensus node in the block number range [h+1, h+L] for the h+Lth block, the block certificate corresponding to the hth block in the blockchain is included in the consensus message broadcast and sent by each consensus node.

3. The method as described in claim 2, wherein collecting the block certificate corresponding to the h-th block in the blockchain, contained in the consensus message broadcast by each consensus node during the consensus process for the (h+L)-th block within the block number range [h+1, h+L], includes: Receive consensus messages broadcast by various consensus nodes during the consensus process for the h+Lth block in the block number range [h+1, h+L]. The block credential contained in the consensus message is verified; if the verification of the block credential passes, the block credential contained in the consensus message is saved.

4. The method of claim 3, wherein the block certificate includes the digest value of the h-th block; the block certificate is signed by the consensus node that sent the block certificate; Verification of the block credentials contained in the consensus message includes: The signature verification is performed on the block certificate; and the digest value of the locally stored block h is verified to be the same as the digest value in the block certificate. If the signature verification for the block credential passes, and the digest value of the locally stored block h is the same as the digest value in the block credential, then the verification for the block credential is confirmed to have passed. If the signature verification for the block certificate fails, or if the digest value of the locally stored block h is different from the digest value in the block certificate, then the verification for the block certificate is confirmed to have failed.

5. The method as described in any one of claims 1-4, wherein the consensus protocol supported by the blockchain system includes multiple consensus phases; and the block certificate is contained in the consensus messages exchanged by the various consensus nodes in any consensus phase of the consensus protocol.

6. The method of claim 1, wherein L is a configurable offset value.

7. The method as described in claim 1, wherein the value range of N is [f+1, nf]; wherein, f represents the number of fault-tolerant nodes supported by the consensus protocol adopted by the blockchain system; n represents the total number of consensus nodes in the blockchain system.

8. The method as described in claim 7, wherein the consensus protocol used in the blockchain system is a Byzantine fault-tolerant protocol; the total number of consensus nodes in the blockchain system is represented by 3f+1; and the value range of N is [f+1, 2f+1]; wherein, The number of Byzantine nodes is represented by f, which is the number of consensus protocols used by the blockchain system.

9. The method as described in claim 8, wherein the consensus protocol adopted by the blockchain system is the PBFT protocol; the block certificate is contained in any one of the pre-prepare message, prepare message, and commit message exchanged in the three phases of the PBFT protocol.

10. A consensus node in a blockchain system, comprising: The message collection unit collects the block credentials corresponding to block h in the blockchain, which are broadcast by each consensus node during the consensus process for any block number within the block number range [h+1, h+L]. The block credentials indicate that the transaction contained in block h has been successfully executed; L represents a preset offset value corresponding to the block number range. The consensus initiating unit, in response to collecting N identical block credentials corresponding to the h-th block sent by different consensus nodes, after the consensus for the (h+L)-th block in the blockchain is completed, continues to initiate consensus for the (h+L+1)-th block in the blockchain; where N is a preset threshold.

11. A blockchain system comprising consensus nodes, wherein any target consensus node: During the consensus process among consensus nodes for any block number within the block number range [h+1, h+L], the block certificate corresponding to block number h in the blockchain is included in the consensus message broadcast and sent by each node; whereby... The block certificate is used to indicate that the transaction contained in the h-th block has been successfully executed; L represents a preset offset value corresponding to the block number range; In response to the collection of N identical block credentials corresponding to the h-th block sent by different consensus nodes, after the consensus for the (h+L)-th block in the blockchain is completed, a consensus for the (h+L+1)-th block in the blockchain is initiated; where N is a preset threshold.

Images