WO2023045574A1

WO2023045574A1 - Consensus in consortium blockchain

Info

Publication number: WO2023045574A1
Application number: PCT/CN2022/109829
Authority: WO
Inventors: 陈盛龙
Original assignee: 蚂蚁区块链科技(上海)有限公司; 支付宝(杭州)信息技术有限公司
Priority date: 2021-09-24
Filing date: 2022-08-03
Publication date: 2023-03-30
Also published as: CN113836232A

Abstract

A consensus method in a consortium blockchain, and a system. The method comprises: a first consensus node in a consortium blockchain broadcasting a checkpoint message in the consortium blockchain when generating a specified number of blocks, wherein the checkpoint message is used for indicating that the first consensus node has generated the specified number of blocks (110); a second consensus node in the consortium blockchain receiving the checkpoint message sent by the first consensus node (120); if the second consensus node does not receive checkpoint messages sent by the other 2f consensus nodes in the consortium blockchain within a preset time period, the second consensus node determining that the stable checkpoint state of the second consensus node times out (130); and the second consensus node initiating a view switching operation in the consortium blockchain on the basis of the fact that the stable checkpoint state of the second consensus node times out, wherein f is the maximum number of abnormal consensus nodes that is allowed in the consortium blockchain (140).

Description

Consensus in Consortium Chain

technical field

This document relates to the field of computer technology, especially to a consensus method and system in an alliance chain.

Background technique

At present, Practical Byzantine Fault Tolerance (PBFT) mainly includes two parts, including Normal Case Phase and View Change Phase. Among them, the Normal Case Phase part includes request (request phase), pre-prepare (pre-preparation phase), prepare (preparation phase), commit (submission phase) and reply (response phase) to complete the consensus. Among them, request and reply respectively correspond to the transaction request initiated by the client (client) and the transaction execution result returned to the client.

In the existing technology, the consensus node usually starts the timer after receiving the request sent by the client. If the client does not receive f+1 replies to the request sent by it within the preset time period, the view switch can be triggered operate. However, since the request is sent by the client, it is a behavior of the client. If the client sends a large number of requests to the consensus node in a short period of time, the consensus node will not be able to complete the consensus on the request within the preset time period. The action in turn triggers a view switch action.

Contents of the invention

The embodiment of this specification provides a consensus method and system in the alliance chain to solve the problem that if the client sends a large number of requests to the consensus node in a short period of time in the existing alliance chain, it will also cause the consensus node to fail at the preset time. The problem of completing the consensus operation on the request within the segment and then triggering the view switching operation.

In order to solve the above technical problems, the embodiments of this specification are implemented in the following way. In the first aspect, a consensus method in the alliance chain is proposed, including: when the first consensus node in the alliance chain generates a specified number of blocks, it broadcasts a checkpoint message in the alliance chain, and the checkpoint message is used for Indicate that the first consensus node has generated the specified number of blocks; the second consensus node in the consortium chain receives the checkpoint message sent by the first consensus node; if the second consensus node is within the preset time If the checkpoint message sent by other 2f consensus nodes in the alliance chain is not received within the segment, then the second consensus node determines that the stable checkpoint state of the second consensus node has timed out; the second consensus node is based on the The stable checkpoint state of the second consensus node times out, and a view switching operation is initiated in the alliance chain, and f is the maximum number of abnormal consensus nodes allowed in the alliance chain.

In the second aspect, a consortium chain system is proposed, including: a first consensus node, when generating a specified number of blocks, broadcasts a checkpoint message in the consortium chain, and the checkpoint message is used to indicate that the first consensus The node has generated the specified number of blocks; the second consensus node receives the checkpoint message sent by the first consensus node, if it does not receive the checkpoint message sent by other 2f consensus nodes in the alliance chain within the preset time checkpoint message, it is determined that the stable checkpoint state of the second consensus node has timed out; and based on the timeout of the stable checkpoint state of the second consensus node, a view switching operation is initiated in the alliance chain, and f is in the alliance chain The maximum number of abnormal consensus nodes allowed.

In the third aspect, a consensus node in the consortium chain is proposed, including: a broadcast module, when a specified number of blocks is generated, a checkpoint message is broadcast in the consortium chain, and the checkpoint message is used to indicate that the specified number has been generated block; the receiving module receives checkpoint messages sent by other consensus nodes in the consortium chain; the status determination module, if the checkpoint message sent by other 2f consensus nodes in the consortium chain is not received within the preset time period message, then determine that the stable checkpoint state is overtime; the view switching module, based on the timeout of the stable checkpoint state, initiates a view switching operation in the alliance chain, and f is the maximum number of abnormal consensus nodes allowed in the alliance chain.

In a fourth aspect, an electronic device is provided, comprising a processor and a memory arranged to store computer-executable instructions that, when executed, cause the processor to perform the following operations: block, broadcast a checkpoint message in the consortium chain, the checkpoint message is used to indicate that the specified number of blocks have been generated; receive checkpoint messages sent by other consensus nodes in the consortium chain; if within a preset time period If the checkpoint message sent by the other 2f consensus nodes in the alliance chain is not received, it is determined that the stable checkpoint state has timed out; based on the timeout of the stable checkpoint state, a view switching operation is initiated in the alliance chain, and f is the alliance The maximum number of abnormal consensus nodes allowed in the chain.

In the fifth aspect, a computer-readable storage medium is proposed, the computer-readable storage medium stores one or more programs, and when the one or more programs are executed by an electronic device including multiple application programs, the The electronic device performs the following operations: when a specified number of blocks is generated, a checkpoint message is broadcast in the consortium chain, and the checkpoint message is used to indicate that the specified number of blocks has been generated; receiving other consensus in the consortium chain The checkpoint message sent by the node; if the checkpoint message sent by the other 2f consensus nodes in the alliance chain is not received within the preset time period, it is determined that the stable checkpoint state has timed out; based on the timeout of the stable checkpoint state, in the A view switching operation is initiated in the consortium chain, and f is the maximum number of abnormal consensus nodes allowed in the consortium chain.

The embodiment of this specification uses the above technical solution to at least achieve the following technical effects: using the consensus method provided by the embodiment of this specification, the first consensus node in the consortium chain broadcasts a checkpoint message in the consortium chain when generating a specified number of blocks , the checkpoint message is used to indicate that the first consensus node has generated a specified number of blocks; the second consensus node in the consortium chain receives the checkpoint message sent by the first consensus node; if the second consensus node does not receive the checkpoint message within the preset time period To the checkpoint message sent by other 2f consensus nodes in the alliance chain, the second consensus node determines that the stable checkpoint state of the second consensus node has timed out; and the second consensus node is based on the stable checkpoint state of the second consensus node. Initiate a view switching operation in , and f is the maximum number of abnormal consensus nodes allowed in the alliance chain. Since the consensus node counts the checkpoint messages received from other consensus nodes in the consortium chain, one thread can be used alone, which can avoid causing great pressure on the consensus node at a certain moment, and thus enable the consensus node to be more accurate in the consortium chain. Trigger a view switch operation.

Description of drawings

The drawings described here are used to provide a further understanding of this specification and constitute a part of this specification. The schematic embodiments and descriptions of this specification are used to explain this specification and do not constitute an improper limitation of this specification. In the attached picture:

Fig. 1 is a schematic diagram of the implementation flow of a consensus method in a consortium chain provided by an embodiment of this specification.

Fig. 2 is a schematic diagram of the implementation flow of an application of the consensus method in the consortium chain provided by an embodiment of this specification.

Fig. 3 is a schematic structural diagram of an alliance chain system provided by an embodiment of this specification.

Fig. 4 is a schematic structural diagram of a consensus node in a consortium chain provided by an embodiment of this specification.

Fig. 5 is a schematic structural diagram of an electronic device provided by an embodiment of this specification.

Detailed ways

In order to make the purpose, technical solution and advantages of this document clearer, the technical solution of this specification will be clearly and completely described below in conjunction with specific embodiments of this specification and corresponding drawings. Apparently, the described embodiments are only some of the embodiments in this document, not all of them. Based on the embodiments in this specification, all other embodiments obtained by persons of ordinary skill in the art without creative efforts fall within the protection scope of this document.

The technical solutions provided by each embodiment of this specification will be described in detail below in conjunction with the accompanying drawings.

In the process of using the PBFT algorithm for consensus in the alliance chain, each Replica (copy, that is, all consensus nodes participating in the consensus in the alliance chain) sends a message or receives messages from other consensus nodes (including pre-prepare, prepare, commit messages) will be recorded in the message log (Message Log) of the memory of the consensus node. With the continuous progress of consensus operations in the alliance chain, the Message Log of each consensus node in the alliance chain will take up more and more memory space. Therefore, in order to save the memory space of each consensus node in the alliance chain, garbage collection is required, that is, When each consensus node executes the proposal, the Message Log of each consensus node is cleared, and the memory space of each consensus node is released.

One way of garbage collection is that every time a consensus node in the consortium chain executes a proposal (that is, every time a block is generated), it can send a broadcast to other consensus nodes in the consortium chain, aiming at whether the consensus node can be cleared The message log of the consensus node is reached in the whole network. After receiving such broadcasts, each consensus node in the alliance chain can also send broadcasts to other consensus nodes in the alliance chain. unanimous. If the consensus nodes in the consortium chain receive confirmations from consensus nodes with different numbers of Quorum (2f+1), these consensus nodes can delete the proposal corresponding to one proposal (that is, the latest generated block) in the consensus node Message Log. message log.

Another way to deal with garbage is that every time a certain consensus node in the alliance chain executes k proposals (that is, each new k blocks are generated), it can send a broadcast to other consensus nodes in the alliance chain. Clearing the Message Log of this consensus node reaches a consensus in the entire network. After receiving such broadcasts, each consensus node in the alliance chain can also broadcast to other consensus nodes in the alliance chain. It is also aimed at whether the Message Log of this consensus node can be cleared. consensus across the network. If the consensus nodes in the consortium chain receive confirmations from consensus nodes with different numbers of Quorum (2f+1), these consensus nodes can delete the k proposals (that is, the latest generated k blocks) in the consensus node Message Log. message log.

Among them, k is the message record corresponding to the k proposals (that is, the newly generated k blocks) indicated by the checkpoint message in the embodiment of this specification, and the Message Log that clears the consensus node above is the checkpoint message in the embodiment of this specification , the format is <CHECKPOINT, n, d, i>, where n is the sequence number of the smallest block that the consensus node currently expects to keep, d is the message digest that is expected to be kept, and i is the number of the consensus node that sent the checkpoint message .

The checkpoint message broadcast by the consensus node in the alliance chain and the summary of the checkpoint message received in the alliance chain are recorded in the Message Log of the consensus node. If the consensus node i in the consortium chain receives Quorum-1 legitimate checkpoint messages sent by other different consensus nodes, plus the checkpoint message sent by consensus node i itself, then the checkpoint message of consensus node i for <n, d> will be When the number of Quorum(2f+1) is reached, the consensus node i can clear the message records corresponding to all blocks before the block number n in the consensus node Message Log (including the corresponding pre-prepare, prepare, commit messages, and checkpoint messages).

The above block number n is the current stable checkpoint of the consensus node i, which means that the consensus node i has reached a consensus on the execution result of the block before the block number n, and the message record corresponding to the block with the block number n is still Retained in the Message Log of consensus node i. Since the processing of each consensus node in the consortium chain system is asynchronous, the consensus node with fast consensus message processing may gradually distance itself from the consensus node with slow consensus message processing. The speed of message processing can be limited by setting high and low water levels: H=h+L, where H is the high water level, L is the low water level, h is the set value, h generally takes the n value of the stable checkpoint. This can control the processing speed of the fast-processing consensus node. When the n value of the consensus message it processes reaches the high water mark H, it will wait until the stable checkpoint changes before continuing to process.

Therefore, if the stable checkpoint has not changed, each consensus node in the consortium chain cannot process the next proposal, and the high and low water levels that limit the speed of message processing will not change, which in turn will cause all parties in the consortium chain to Consensus nodes have stagnated.

In order to solve this problem, the first consensus node in the alliance chain broadcasts a checkpoint message in the alliance chain when generating a specified number of blocks. The checkpoint message is used to indicate that the first consensus node has generated a specified number of blocks. block; the second consensus node in the alliance chain receives the checkpoint message sent by the first consensus node; if the second consensus node does not receive the checkpoint message sent by other 2f consensus nodes in the alliance chain within the preset time period, Then the second consensus node determines that the stable checkpoint state of the second consensus node has timed out; and the second consensus node initiates a view switching operation in the alliance chain based on the timeout of the stable checkpoint state of the second consensus node, and f is the maximum exception allowed in the alliance chain The number of consensus nodes. Since the consensus node in the alliance chain can trigger the view switching operation in time after the stable checkpoint state times out, to replace the consensus master node in the alliance chain and restart the consensus operation, thereby avoiding stagnation of each consensus node in the alliance chain status.

In addition, if any request sent by the client to the consensus node in the consortium chain can successfully reach a consensus, it will eventually reach a consensus in the consortium chain and broadcast a commit message throughout the network, while the consensus node in the consortium chain targets a certain After the request reaches a consensus, it will send a checkpoint message to other nodes, so that 2f+1 nodes in the consortium chain can perform garbage collection operations after reaching a consensus on the same request, and change the state of the consensus node to a stable checkpoint state, so , if the stable checkpoint state of a certain consensus node in the alliance chain has timed out, it can also reflect that the request sent by the client to the consensus node has timed out.

The embodiment of this specification is based on this, and considering that each consensus node in the consortium chain can process the checkpoint message as a separate thread, it is proposed to trigger the view switching operation in the consortium chain based on the timeout of the stable checkpoint state of the consensus node.

Specifically, a schematic diagram of the implementation flow of a consensus method in a consortium chain provided by one or more embodiments of this specification is shown in Figure 1 , including the following steps.

Step 110, when the first consensus node in the consortium chain generates a specified number of blocks, it broadcasts a checkpoint message in the consortium chain, and the checkpoint message is used to indicate that the first consensus node has generated a specified number of blocks.

Among them, when the first consensus node generates a specified number of blocks, the purpose of broadcasting the checkpoint message in the alliance chain is to reach a consensus on whether the Message Log can be cleared in the entire network.

Optionally, in order to facilitate the determination of clearing the message records corresponding to which blocks in the Message Log, the first consensus node broadcasts a checkpoint message in the consortium chain, including: The block number n broadcasts the checkpoint message in the consortium chain, and the checkpoint message carries the block number n of the block with the largest sequence number among the specified number of blocks.

Among them, the purpose of carrying the block number n of the block with the largest sequence number among the specified number of blocks in the checkpoint message is to check whether the message corresponding to the block before the block number n in the Message Log can be cleared and recorded in the entire network agree.

It should be understood that if the consensus node receives Quorum-1 legal checkpoint messages sent by different nodes, plus the checkpoint message sent by itself, it means that the consensus node has collected checkpoint messages of Quorum quantity, and a stable checkpoint can be achieved, and then It is possible to clean up the message records corresponding to the blocks before the block number n in the Message Log. Specifically, after the first consensus node broadcasts the checkpoint message in the alliance chain, the method provided by the embodiment of this specification further includes: when the second consensus node generates a specified number of blocks, the second consensus node broadcasts the checkpoint message in the alliance chain to carry There is a checkpoint message of the block number n of the block with the largest serial number among the specified number of blocks, and the checkpoint message broadcast by the second consensus node is used to indicate that the second consensus node has generated the specified number of blocks; the first consensus node receives the The checkpoint message sent by the second consensus node; when the first consensus node receives the checkpoint message of 2f consensus nodes in the alliance chain within the preset time period, the first consensus node clears the specified number of blocks in the first consensus node The message record corresponding to the block before the block with the largest sequence number; the first consensus node modifies the state of the first consensus node to stable checkpoint based on the block number n of the block with the largest sequence number among the specified number of blocks.

Optionally, the above specified number is a positive integer greater than or equal to 1.

Optionally, a way of triggering the view switching operation provided by the embodiment of this specification is that when the specified number is 1, after the first consensus node modifies the state of the first consensus node to stable checkpoint, the method provided by the embodiment of this specification The method also includes: the first consensus node starts the timer; if the first consensus node does not receive the block numbers of n+ 1 checkpoint message, the first consensus node determines that the stable checkpoint state of the first consensus node has timed out; the first consensus node triggers a view switching operation in the alliance chain based on the timeout of the stable checkpoint state of the first consensus node.

Every time the first consensus node in the consortium chain executes a proposal (that is, every time a block is generated), it can broadcast checkpoint messages to other consensus nodes in the consortium chain to reach an agreement on whether the message log of this consensus node can be cleared in the entire network. Consistent, other consensus nodes in the consortium chain can also broadcast checkpoint messages to other consensus nodes in the consortium chain after receiving the checkpoint message, and also reach a consensus on whether the Message Log of this consensus node can be cleared in the entire network. If the first consensus node in the consortium chain receives confirmations from consensus nodes with different numbers of Quorum (2f+1) within the set preset time period, the first consensus node can modify the status of the consensus node to stable checkpoint. At this time, the first consensus node in the consortium chain can restart the timer. If the first consensus node does not receive the zone data of other 2f consensus nodes in the consortium chain within the preset time period after starting the timer For the checkpoint message with block number n+1, the first consensus node determines that its stable checkpoint status has timed out, and can trigger a view switching operation in the consortium chain based on the stable checkpoint status timeout.

Optionally, another way of triggering the view switching operation provided by the embodiment of this specification is that when the specified number is a positive integer k greater than 1, after the first consensus node modifies the state of the first consensus node to stable checkpoint, The method also includes: the first consensus node starts the timer; if the first consensus node does not receive the other 2f consensus nodes in the consortium chain within the preset time period after starting the timer, the block number is n+k checkpoint messages, the first consensus node determines that the stable checkpoint state of the first consensus node has timed out; the first consensus node triggers a view switching operation in the alliance chain based on the timeout of the stable checkpoint state of the first consensus node.

Every time the first consensus node in the alliance chain executes k proposals (that is, every time k blocks are generated), it can broadcast checkpoint messages to other consensus nodes in the alliance chain. After reaching a consensus on the network, other consensus nodes in the consortium chain can also broadcast checkpoint messages to other consensus nodes in the consortium chain after receiving the checkpoint message. It is also a consensus on whether the Message Log of this consensus node can be cleared in the entire network. If the first consensus node in the consortium chain receives confirmations from consensus nodes with different numbers of Quorum (2f+1) within the set preset time period, the first consensus node can modify the status of the consensus node to stable checkpoint. At this time, the first consensus node in the consortium chain can restart the timer. If the first consensus node does not receive the zone data of other 2f consensus nodes in the consortium chain within the preset time period after starting the timer For a checkpoint message with block number n+k, the first consensus node determines that its stable checkpoint status has timed out, and can trigger a view switching operation in the consortium chain based on the stable checkpoint status timeout.

Step 120, the second consensus node in the consortium chain receives the checkpoint message sent by the first consensus node.

When the second consensus node in the consortium chain generates a specified number of blocks, it can also broadcast a checkpoint message in the consortium chain. The checkpoint message is used to indicate that the second consensus node has generated a specified number of blocks. While the second consensus node broadcasts the checkpoint message in the alliance chain, it will also receive the checkpoint message sent by other consensus nodes in the alliance chain such as the first consensus node.

Step 130, if the second consensus node does not receive checkpoint messages sent by other 2f consensus nodes in the consortium chain within the preset time period, the second consensus node determines that the stable checkpoint state of the second consensus node has timed out.

Wherein, the duration of the preset time period is the duration of the timer set locally by the second consensus node to trigger timeout. If the second consensus node does not receive the checkpoint messages sent by other 2f consensus nodes in the consortium chain within the preset time period, the second consensus node cannot collect the checkpoint messages of Quorum quantity, and cannot achieve stable checkpoint, and thus cannot Perform garbage cleaning operations on the Message Log in this consensus node. In the embodiment of this specification, the state that the consensus node cannot reach the stable checkpoint is simply referred to as the stable checkpoint state timeout.

Step 140, the second consensus node initiates a view switching operation in the consortium chain based on the timeout of the stable checkpoint state of the second consensus node, and f is the maximum number of abnormal consensus nodes allowed in the consortium chain.

When the stable checkpoint status of the second consensus node times out, it means that the stable checkpoint of the second consensus node cannot be updated, which means that the second consensus node cannot continue the consensus operation on propose. At this time, in order to change this situation, The second consensus node can initiate a view switching operation in the consortium chain based on the timeout of its local stable checkpoint state, in an attempt to replace the consensus master node in the consortium chain.

It should be noted that, in addition to the PBFT algorithm, the consensus algorithm in the embodiment of this specification can also be applied to the RAFT algorithm, and other consensus algorithms that can distinguish between consensus master nodes and consensus backup nodes. The embodiment of this specification does not impose specific restrictions on the adopted consensus algorithm, as long as there is a consensus master node in the adopted consensus algorithm.

The consensus method provided by the embodiment of this specification will be described in detail below with the schematic diagram of the consensus operation process using the PBFT algorithm shown in FIG. 2 . In Figure 2, C is the client, consensus node 0 is the consensus master node during this consensus operation, and consensus nodes 1 to 3 are consensus backup nodes during this consensus operation. The schematic diagram shown in Figure 2 includes the following situations: In the first case, the consensus node 0 is a malicious node, and the consensus node 0 deceives the consensus node 1 and the consensus node 2 to perform the consensus operation on the message m requesting consensus from the client (Figure 2 shown in the solid line), while the consensus node 0 itself and the consensus node 3 do not perform the consensus operation on the message m requesting consensus from the client (the dotted line shown in Figure 2). Even if the consensus node 0 continues to do evil, but, as the message m is continuously processed, on the one hand, since the consensus node 3 does not perform any consensus operations, its local timer will time out after the set period of time, thus in the consortium chain Trigger the view switching operation; on the other hand, although the consensus node 1 and the consensus node 2 have executed the consensus operation on m, the consensus node 1 and the consensus node 2 will reach the checkpoint after executing the consensus operation of m, so that in the alliance chain Broadcast the checkpoint message, but because the consensus node 0 and the consensus node 3 did not perform the consensus operation on m, the checkpoint will not be reached, and the checkpoint message will not be broadcast in the alliance chain, which makes the consensus node 1 and the consensus node 2 Unable to collect checkpoint messages of the number of Quorum, unable to achieve stable checkpoint, further, consensus node 1 and consensus node 2 will not continue to execute after reaching the high water level, consensus node 1 and consensus node 2 will set the local timer after the set time period It will also time out, which will trigger the view switching operation.

In the second case, if the consensus node 0 continues to do evil like in the first case, the local timer of the consensus node 3 will also time out, thereby initiating a view switching operation in the alliance chain; at the same time, due to the fact that in the first case , Consensus Node 1 and Consensus Node 2 have been unable to reach a stable checkpoint, that is, the stable checkpoint state has timed out. In this way, Consensus Node 1 and Consensus Node 2 will also trigger a view switching operation in the alliance chain, and then can achieve a Quorum number of view switching operations. Complete the master change.

In the third case, in the alliance chain network, every time a consensus node generates a block, it can broadcast a block message to other consensus nodes through the P2P protocol, and receive the consensus node that broadcasts the block message, as shown in Figure 2 If the consensus node 3 finds that the block height in the block message is higher than its local maximum block height, it will synchronize the latest block from consensus node 1 or consensus node 2 (there are already 2f+1 signatures in the block , can be pushed or pulled from consensus node 1 or consensus node 2, regardless of the height of the block of consensus node 0), so as to maintain synchronization with consensus node 1 or consensus node 2.

Using the consensus method provided by the embodiment of this specification, when the first consensus node in the consortium chain generates a specified number of blocks, it broadcasts a checkpoint message in the consortium chain. The checkpoint message is used to indicate that the first consensus node has generated a specified number of blocks. block; the second consensus node in the alliance chain receives the checkpoint message sent by the first consensus node; if the second consensus node does not receive the checkpoint message sent by other 2f consensus nodes in the alliance chain within the preset time period, then The second consensus node determines that the stable checkpoint state of the second consensus node has timed out; and the second consensus node initiates a view switching operation in the alliance chain based on the timeout of the stable checkpoint state of the second consensus node, f is the maximum abnormal consensus allowed in the alliance chain number of nodes. Since the consensus node counts the checkpoint messages received from other consensus nodes in the consortium chain, one thread can be used alone, which can avoid causing great pressure on the consensus node at a certain moment, and thus enable the consensus node to be more accurate in the consortium chain. Trigger a view switch operation.

Fig. 3 is a schematic structural diagram of the consortium chain system 300 provided by the embodiment of this specification. Please refer to FIG. 3 , in a software implementation, the consortium chain system 300 may include a first consensus node 310 and a second consensus node 320, wherein: the first consensus node 310, when generating a specified number of blocks, A checkpoint message is broadcast in the consortium chain, and the checkpoint message is used to indicate that the first consensus node has generated the specified number of blocks; the second consensus node 320 receives the checkpoint message sent by the first consensus node, if If the checkpoint message sent by other 2f consensus nodes in the alliance chain is not received within the preset time period, it is determined that the stable checkpoint state of the second consensus node has timed out; and based on the stable checkpoint of the second consensus node When the state is timed out, a view switch operation is initiated in the alliance chain, and f is the maximum number of abnormal consensus nodes allowed in the alliance chain.

Optionally, in an implementation manner, the first consensus node 310 is configured to: broadcast a checkpoint in the consortium chain based on the block number n of the block with the largest sequence number among the specified number of blocks message, the checkpoint message carries the block number n of the block with the largest sequence number among the specified number of blocks.

Optionally, in an implementation manner, after the first consensus node broadcasts a checkpoint message in the consortium chain, when the second consensus node generates the specified number of blocks, the second The consensus node broadcasts in the consortium chain a checkpoint message carrying the block number n of the block with the largest sequence number among the specified number of blocks, and the checkpoint message broadcast by the second consensus node is used to indicate that the second The consensus node has generated the specified number of blocks; the first consensus node receives the checkpoint message sent by the second consensus node; when the first consensus node receives the alliance within the preset time period When there are checkpoint messages from 2f consensus nodes in the chain, the first consensus node clears the message record corresponding to the block before the block with the largest sequence number in the specified number of blocks in the first consensus node; The first consensus node modifies the state of the first consensus node to stable checkpoint based on the block number n of the block with the largest sequence number among the specified number of blocks.

In one embodiment, the specified number is a positive integer greater than or equal to 1.

In one embodiment, when the specified number is 1, after the first consensus node modifies the state of the first consensus node to stable checkpoint, the method further includes: the first consensus node starts timer; if the first consensus node does not receive the block number n+1 carried by the other 2f consensus nodes in the consortium chain within the preset time period after starting the timer checkpoint message, the first consensus node determines that the stable checkpoint state of the first consensus node has timed out; View switching operation.

In one embodiment, when the specified number is a positive integer k greater than 1, after the first consensus node modifies the state of the first consensus node to stable checkpoint, the method further includes: the The first consensus node starts the timer; if the first consensus node does not receive the blocks carried by other 2f consensus nodes in the consortium chain within the preset time period after starting the timer n+k checkpoint message, the first consensus node determines that the stable checkpoint status of the first consensus node has timed out; the first consensus node is based on the stable checkpoint status of the first consensus node. Trigger the view switching operation in the alliance chain mentioned above.

In one embodiment, the first consensus node is any consensus node in the consortium chain; the second consensus node is any consensus node in the consortium chain.

The consortium chain system 300 can implement the methods in the method embodiments in FIGS. 1-2 . For details, please refer to the consensus method in the consortium chain in the embodiment shown in FIGS. 1-2 , and details will not be repeated here.

Fig. 4 is a schematic structural diagram of a consensus node 400 in a consortium chain provided by an embodiment of this specification, including: a broadcast module 410, which broadcasts a checkpoint message in the consortium chain when a specified number of blocks are generated, the checkpoint message It is used to indicate that the specified number of blocks has been generated; the receiving module 420 receives checkpoint messages sent by other consensus nodes in the alliance chain; the state determination module 430, if the alliance chain is not received within a preset time period The checkpoint message sent by other 2f consensus nodes in the chain determines that the stable checkpoint state is overtime; the view switching module 440 initiates a view switching operation in the alliance chain based on the timeout of the stable checkpoint state, and f is the alliance chain The maximum number of abnormal consensus nodes allowed in .

In one embodiment, the broadcast module 410 is configured to: broadcast a checkpoint message in the consortium chain based on the block number n of the block with the largest sequence number among the specified number of blocks, the checkpoint message carries the block number n of the block with the largest sequence number among the specified number of blocks.

In one embodiment, the status determination module 430 is further configured to: clear the designated node in this consensus node when receiving checkpoint messages from 2f consensus nodes in the consortium chain within the preset time period. The message record corresponding to the block before the block with the largest serial number among the number of blocks; based on the block number n of the block with the largest serial number among the specified number of blocks, modify the status of the consensus node to stable checkpoint.

In one embodiment, when the specified number is 1, after the state determination module 430 modifies the state of this consensus node to stable checkpoint, the view switching module 440 is also used to: start the timer; if Within the preset time period after starting the timer, if no checkpoint message carrying block number n+1 from other 2f consensus nodes in the consortium chain is received, then the consensus node’s The stable checkpoint state timed out; based on the timeout of the stable checkpoint state of the consensus node, the view switching operation is triggered in the alliance chain.

In one embodiment, when the specified number is a positive integer k greater than 1, after the state determination module 430 modifies the state of the consensus node to stable checkpoint, the view switching module 440 is further configured to: Start the timer; if within the preset time period after starting the timer, the checkpoint message carrying the block number n+k of the other 2f consensus nodes in the consortium chain is not received, then Determine the timeout of the stable checkpoint state of the consensus node; based on the timeout of the stable checkpoint state of the consensus node, trigger the view switching operation in the alliance chain.

In one embodiment, the consensus node 400 in the consortium chain is any consensus node in the consortium chain.

The consensus node 400 in the consortium chain can implement the method in the method embodiment in FIG. 1 . For details, please refer to the consensus method in the consortium chain in the embodiment shown in FIG. 1 , which will not be repeated here.

Fig. 5 is a schematic structural diagram of an electronic device provided by an embodiment of this specification. Please refer to FIG. 5 , at the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and a memory. Wherein, the memory may include a memory, such as a high-speed random-access memory (Random-Access Memory, RAM), and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory. Of course, the electronic device may also include hardware required by other services.

The processor, the network interface and the memory can be connected to each other through an internal bus, which can be an ISA (Industry Standard Architecture, industry standard architecture) bus, a PCI (Peripheral Component Interconnect, peripheral component interconnection standard) bus or an EISA (Extended Industry Standard Architecture, extended industry standard architecture) bus, etc. The bus can be divided into address bus, data bus, control bus and so on. For ease of representation, only one double-headed arrow is used in FIG. 5 , but it does not mean that there is only one bus or one type of bus.

Memory for storing programs. Specifically, the program may include program code, and the program code includes computer operation instructions. Storage, which can include internal memory and nonvolatile storage, provides instructions and data to the processor.

The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it, forming a blockchain system deployed by consensus nodes in the consortium chain on a logical level. The processor executes the program stored in the memory, and is specifically used to perform the following operations: when a specified number of blocks is generated, a checkpoint message is broadcast in the consortium chain, and the checkpoint message is used to indicate that the specified number of blocks has been generated block; receive checkpoint messages sent by other consensus nodes in the alliance chain; if the checkpoint messages sent by other 2f consensus nodes in the alliance chain are not received within the preset time period, then determine that the stable checkpoint state is overtime; Based on the timeout of the stable checkpoint state, a view switching operation is initiated in the alliance chain, and f is the maximum number of abnormal consensus nodes allowed in the alliance chain.

The above-mentioned consensus method in the consortium chain disclosed in the embodiment shown in FIG. 1 of this specification can be applied to the processor, or implemented by the processor. A processor may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in a processor or an instruction in the form of software. The above-mentioned processor can be a general-purpose processor, including a central processing unit (Central Processing Unit, CPU), a network processor (Network Processor, NP), etc.; it can also be a digital signal processor (Digital Signal Processor, DSP), a dedicated integrated Circuit (Application Specific Integrated Circuit, ASIC), Field-Programmable Gate Array (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. The various methods, steps and logic block diagrams disclosed in one or more embodiments of this specification can be realized or executed. A general-purpose processor may be a microprocessor, or the processor may be any conventional processor, or the like. The steps of the method disclosed in conjunction with one or more embodiments of this specification may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software module can be located in a mature storage medium in the field such as random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, register. The storage medium is located in the memory, and the processor reads the information in the memory, and completes the steps of the above method in combination with its hardware.

The electronic device can also execute the consensus method in the consortium chain shown in FIG. 1 , which will not be repeated here in this specification.

Of course, in addition to the software implementation, the electronic equipment in this specification does not exclude other implementations, such as logic devices or the combination of software and hardware, etc., that is to say, the execution subject of the following processing flow is not limited to each logic unit, It can also be a hardware or logic device.

The embodiment of this specification also proposes a computer-readable storage medium, the computer-readable storage medium stores one or more programs, and the one or more programs include instructions, and the instructions are used when a portable electronic device including multiple application programs During execution, the portable electronic device can be made to execute the method of the embodiment shown in FIG. 5, and is specifically used to perform the following operations: when a specified number of blocks is generated, a checkpoint message is broadcast in the consortium chain, and the checkpoint message is used for Indicate that the specified number of blocks has been generated; receive the checkpoint message sent by other consensus nodes in the alliance chain; if the checkpoint message sent by other 2f consensus nodes in the alliance chain is not received within the preset time period message, it is determined that the stable checkpoint state has timed out; based on the timeout of the stable checkpoint state, a view switching operation is initiated in the alliance chain, and f is the maximum number of abnormal consensus nodes allowed in the alliance chain.

In a word, the above descriptions are only preferred embodiments of this specification, and are not intended to limit the scope of protection of this specification. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of one or more embodiments of this specification shall be included in the protection scope of one or more embodiments of this specification.

The systems, devices, modules, or units described in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementing device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or Combinations of any of these devices.

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can be implemented by any method or technology for storage of information. Information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Flash memory or other memory technology, Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical storage, Magnetic tape cartridge, tape magnetic disk storage or other magnetic storage device or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.

It should also be noted that the term "comprises", "comprises" or any other variation thereof is intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus comprising a set of elements includes not only those elements, but also includes Other elements not expressly listed, or elements inherent in the process, method, commodity, or apparatus are also included. Without further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article or apparatus comprising said element.

Each embodiment in this specification is described in a progressive manner, the same and similar parts of each embodiment can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for relevant parts, refer to part of the description of the method embodiment.

Claims

A consensus method in the alliance chain, including:

When the first consensus node in the consortium chain generates a specified number of blocks, it broadcasts a checkpoint message in the consortium chain, and the checkpoint message is used to indicate that the first consensus node has generated the specified number of blocks;

The second consensus node in the consortium chain receives the checkpoint message sent by the first consensus node;

If the second consensus node does not receive the checkpoint message sent by other 2f consensus nodes in the alliance chain within the preset time period, the second consensus node determines the stable checkpoint status of the second consensus node time out;

The second consensus node initiates a view switching operation in the alliance chain based on the timeout of the stable checkpoint state of the second consensus node, and f is the maximum number of abnormal consensus nodes allowed in the alliance chain.
The method according to claim 1, wherein the first consensus node broadcasts a checkpoint message in the alliance chain, comprising:

The first consensus node broadcasts a checkpoint message in the consortium chain based on the block number n of the block with the largest sequence number among the specified number of blocks, and the checkpoint message carries the specified number of blocks The block number n of the block with the largest sequence number.
The method according to claim 2, after the first consensus node broadcasts a checkpoint message in the consortium chain, the method further comprises:

When the second consensus node generates the specified number of blocks, the second consensus node broadcasts the block number n of the block with the largest sequence number among the specified number of blocks in the alliance chain checkpoint message, the checkpoint message broadcast by the second consensus node is used to indicate that the second consensus node has generated the specified number of blocks;

The first consensus node receives the checkpoint message sent by the second consensus node;

When the first consensus node receives checkpoint messages from 2f consensus nodes in the alliance chain within the preset time period, the first consensus node clears the specified number of The message record corresponding to the block before the block with the largest sequence number in the block;

The first consensus node modifies the state of the first consensus node to stable checkpoint based on the block number n of the block with the largest sequence number among the specified number of blocks.
The method according to claim 3, wherein the specified number is a positive integer greater than or equal to 1.
The method according to claim 4, when the specified number is 1, after the first consensus node modifies the state of the first consensus node to stable checkpoint, the method further includes:

The first consensus node starts a timer;

If the first consensus node does not receive checkpoint messages carrying block number n+1 from other 2f consensus nodes in the consortium chain within the preset time period after starting the timer , then the first consensus node determines that the stable checkpoint state of the first consensus node times out;

The first consensus node triggers a view switching operation in the consortium chain based on the timeout of the stable checkpoint state of the first consensus node.
The method according to claim 4, when the specified number is a positive integer k greater than 1, after the first consensus node modifies the state of the first consensus node to stable checkpoint, the method further includes:

The first consensus node starts a timer;

If the first consensus node does not receive checkpoint messages with block number n+k from other 2f consensus nodes in the consortium chain within the preset time period after starting the timer , then the first consensus node determines that the stable checkpoint state of the first consensus node times out;

The first consensus node triggers a view switching operation in the consortium chain based on the timeout of the stable checkpoint state of the first consensus node.
The method according to any one of claims 1 to 6,

The first consensus node is any consensus node in the alliance chain;

The second consensus node is any consensus node in the alliance chain.
An alliance chain system, including:

The first consensus node, when generating a specified number of blocks, broadcasts a checkpoint message in the alliance chain, and the checkpoint message is used to indicate that the first consensus node has generated the specified number of blocks;

The second consensus node receives the checkpoint message sent by the first consensus node, and if it does not receive the checkpoint message sent by other 2f consensus nodes in the alliance chain within the preset time period, then determine the second consensus node The stable checkpoint state of the node is timed out; and based on the stable checkpoint state timeout of the second consensus node, a view switching operation is initiated in the alliance chain, and f is the maximum number of abnormal consensus nodes allowed in the alliance chain.
A consensus node in the alliance chain, including:

The broadcast module broadcasts a checkpoint message in the consortium chain when generating a specified number of blocks, and the checkpoint message is used to indicate that the specified number of blocks has been generated;

The receiving module receives checkpoint messages sent by other consensus nodes in the alliance chain;

The state determination module, if the checkpoint message sent by other 2f consensus nodes in the alliance chain is not received within the preset time period, then determine that the stable checkpoint state is overtime;

The view switching module, based on the timeout of the stable checkpoint state, initiates a view switching operation in the alliance chain, where f is the maximum number of abnormal consensus nodes allowed in the alliance chain.
An electronic device comprising:

processor; and

a memory arranged to store computer-executable instructions that, when executed, cause the processor to:

When a specified number of blocks is generated, a checkpoint message is broadcast in the consortium chain, and the checkpoint message is used to indicate that the specified number of blocks has been generated;

Receive checkpoint messages sent by other consensus nodes in the alliance chain;

If the checkpoint message sent by the other 2f consensus nodes in the alliance chain is not received within the preset time period, the stable checkpoint state is determined to be timed out;

Based on the timeout of the stable checkpoint state, a view switching operation is initiated in the alliance chain, and f is the maximum number of abnormal consensus nodes allowed in the alliance chain.
A computer-readable storage medium that stores one or more programs that, when executed by an electronic device including a plurality of application programs, cause the electronic device to perform the following operations :

When a specified number of blocks is generated, a checkpoint message is broadcast in the consortium chain, and the checkpoint message is used to indicate that the specified number of blocks has been generated;

Receive checkpoint messages sent by other consensus nodes in the alliance chain;

If the checkpoint message sent by the other 2f consensus nodes in the alliance chain is not received within the preset time period, the stable checkpoint state is determined to be timed out;

Based on the timeout of the stable checkpoint state, a view switching operation is initiated in the alliance chain, and f is the maximum number of abnormal consensus nodes allowed in the alliance chain.