Blockchain consensus node restart processing method, consensus node and blockchain system

Abstract

The embodiments of this specification provide a restart processing method for blockchain consensus nodes, consensus nodes and blockchain systems. The method includes: after the target consensus node is restarted in the process of target consensus, the consensus persistence data of the target consensus recorded in batches by the target consensus node before the restart is retrieved, and the consensus persistence data includes the consensus messages sent and received by the target consensus node in at least one protocol stage of the Honey Badger Byzantine consensus mechanism and the confirmation response messages received by the target consensus node from other consensus nodes based on the consensus messages sent by the target consensus node. The target consensus node determines the completion status of the target consensus node for the target consensus based on the consensus messages sent and received by the target consensus node in the consensus persistence data and the confirmation response messages received from other consensus nodes based on the consensus messages sent by the target consensus node, thereby restoring to the completion status before the restart based on the logic of the Honey Badger Byzantine consensus mechanism.

Description

[0001] This document is a divisional application of "Restart processing method of blockchain consensus node, consensus node and blockchain system". The application number of the parent case is "202010630197.2" and the application date is "July 3, 2020". Technical Field

[0002] This document relates to the field of blockchain technology, and in particular to a restart processing method for a blockchain consensus node, a consensus node, and a blockchain system. Background Art

[0003] At present, many blockchain systems use the Byzantine Fault-Tolerant (BFT) algorithm to achieve consensus. As a new asynchronous BFT consensus mechanism, HoneyBadgerBFT has the advantage of being independent of the time conditions of the network environment and has extremely high processing efficiency. It will develop into a mainstream consensus mechanism in the future.

[0004] At this stage, the HoneyBadgerBFT consensus mechanism has not yet been designed to deal with the crash of consensus nodes during the consensus process. Summary of the invention

[0005] The purpose of the embodiments of this specification is to provide a blockchain consensus node restart processing method, a consensus node and a blockchain system, which can enable the consensus node to recover to the corresponding consensus state after restarting during the consensus process.

[0006] In order to achieve the above purpose, the embodiments of this specification are implemented as follows:

[0007] In a first aspect, a method for restarting a blockchain consensus node is provided, comprising:

[0008] After the target consensus node of the blockchain is restarted during the target consensus process, the consensus persistence data of the target consensus recorded in batches by the target consensus node before the restart is retrieved, wherein the consensus persistence data includes the consensus messages sent and received by the target consensus node in at least one protocol phase of the Honey Badger Byzantine consensus mechanism and the confirmation response messages received by the target consensus node from other consensus nodes based on the consensus messages sent by the target consensus node;

[0009] The target consensus node determines the completion status of the target consensus node for the target consensus based on the consensus message sent and received by the target consensus node in the at least one protocol stage in the consensus persistence data and the confirmation response message fed back by other consensus nodes based on the consensus message sent by the target consensus node;

[0010] The target consensus node is restored to the completion state of the target consensus before restarting based on the logic of the Honey Badger Byzantine consensus mechanism.

[0011] Second, a consensus node of a blockchain is provided, including:

[0012] A calling module, after restarting in the process of target consensus, calls the consensus persistence data of the target consensus recorded before restarting, wherein the consensus persistence data includes the consensus messages sent and received in at least one protocol phase of the Honey Badger Byzantine consensus mechanism and the confirmation response messages received by the target consensus node and fed back by other consensus nodes based on the consensus messages sent by the target consensus node;

[0013] A determination module determines the completion status of the target consensus based on the consensus messages sent and received in at least one protocol stage of the Honey Badger Byzantine consensus mechanism in the consensus persistence data and the confirmation response messages fed back by other consensus nodes based on the consensus messages sent by the target consensus node;

[0014] The recovery module, based on the logic of the Honey Badger Byzantine consensus mechanism, recovers to the completion state of the target consensus before the restart. In a third aspect, a blockchain system is provided, including multiple consensus nodes, wherein:

[0015] After any target consensus node among the multiple consensus nodes is restarted during the target consensus process, the consensus persistence data of the target consensus recorded by the target consensus node before the restart is retrieved, wherein the consensus persistence data includes the consensus message sent and received by the target consensus node in at least one protocol phase of the Honey Badger Byzantine consensus mechanism and the confirmation response message received by the target consensus node and fed back by other consensus nodes based on the consensus message sent by the target consensus node;

[0016] The target consensus node determines the completion status of the target consensus node for the target consensus based on the consensus message sent and received by the target consensus node in the at least one protocol stage in the consensus persistence data and the confirmation response message fed back by other consensus nodes based on the consensus message sent by the target consensus node;

[0017] The target consensus node is restored to the completion state of the target consensus before the restart based on the logic of the Honey Badger Byzantine consensus mechanism. Based on the scheme of the embodiment of this specification, during the process of the target consensus, the consensus node records the consensus persistence data of the consensus messages sent and received in each protocol stage under the HoneyBadgerBFT consensus mechanism in batches, so that after the shutdown and restart, based on the consensus persistence data, it can be restored to the completion state of the target consensus before the restart, and then the target consensus can be executed according to the correct logic, which can avoid the phenomenon of block forks in the blockchain. Since the scheme adopts the method of batch recording to store consensus persistence data, for a consensus mechanism with complex message interaction processes such as HoneyBadgerBFT, the number of write operations and storage overhead can be greatly reduced. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the embodiments of this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0019] Figure 1 A flowchart of a method for restarting a blockchain consensus node provided in an embodiment of this specification.

[0020] Figure 2 A schematic diagram of the structure of a consensus node provided in an embodiment of this specification.

[0021] Figure 3 A schematic diagram of the structure of the blockchain system provided in the embodiments of this specification.

[0022] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this specification. DETAILED DESCRIPTION

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

[0024] As mentioned above, the HoneyBadgerBFT consensus mechanism has not yet been designed to deal with the downtime of consensus nodes during the consensus process. Once the consensus node is restarted during the consensus process, it may cause the consensus to fail to execute, or even cause inconsistent consensus results and block forks. In this context, this document proposes a restart processing solution for blockchain consensus nodes based on the HoneyBadgerBFT consensus mechanism. To this end, this specification provides a technical solution to the above problem.

[0025] To facilitate understanding of the downtime handling solution provided in the embodiments of this specification, the HoneyBadgerBFT consensus mechanism is briefly introduced below.

[0026] At present, the process of HoneyBadgerBFT consensus mechanism mainly includes: reliable broadcast transmission RBC protocol stage and binary agreement BA protocol stage.

[0027] The consensus node will first enter the RBC protocol stage, and based on the RBC protocol, broadcast the consensus proposal initiated by itself in this consensus view to other consensus nodes. Similarly, the consensus node will also receive the consensus proposal sent by other nodes in the RBC protocol stage in the RBC protocol stage. After the Merkle tree verification of the consensus proposal is performed, the BA protocol stage is entered. Among them, the Merkle tree verification result of the consensus proposal will affect the initial BA value of the consensus proposal in the BA protocol stage.

[0028] The BA protocol is a random uncertainty algorithm, which includes three stages: consensus nodes reach consensus through the initial exchange of consensus opinions (BA values), the second exchange of consensus opinions is conducive to convergence, and the final coin toss decision. The consensus nodes finally determine the consensus results of each consensus proposal in the BA protocol stage.

[0029] Based on the above, the embodiments of this specification provide a method for restarting a blockchain consensus node. Figure 1 It is a flowchart of the restart processing method of the embodiment of this specification. Figure 1 The method shown can be performed by the corresponding device below, including the following steps:

[0030] S102, after the target consensus node of the blockchain is restarted during the target consensus process, the consensus persistence data of the target consensus recorded in batches by the target consensus node before the restart is retrieved, wherein the consensus persistence data includes the consensus messages sent and received by the target consensus node in at least one protocol stage of the Honey Badger Byzantine consensus mechanism.

[0031] In an embodiment of the present specification, the target consensus node may be provided with a persistent cache queue, which stores the consensus persistent data generated by the target consensus node for the target consensus. In the process of executing the target consensus, the target consensus node may locally write the consensus persistent data in the persistent cache queue and clear the persistent cache queue based on a preset period, or the target consensus node may also locally write the consensus persistent data in the persistent cache queue and clear the persistent cache queue when the consensus persistent data in the persistent cache queue accumulates to a preset data volume threshold.

[0032] Specifically, the information sent and received during the RBC protocol phase of consensus persistent data records may include, but is not limited to: epoch messages, where the consensus nodes of the blockchain broadcast their own proposal data based on epoch messages during the RBC protocol phase; ready messages, where the consensus nodes of the blockchain send Ready messages corresponding to the consensus proposal to other consensus nodes to indicate successful verification of the Merkle tree of the consensus proposal.

[0033] The information sent and received during the RBC protocol phase of consensus persistent data records may include, but is not limited to: BVAL messages, used to determine the initial BA value of the proposed data of the target consensus; AUX messages, used to determine the intermediate BA value of the proposed data of the target consensus; Term messages, used to determine the final BA value of the proposed data of the target consensus.

[0034] It should be noted here that for the RBC protocol stage, the initial value, intermediate value and final value of BA are non-deterministic results. In order to ensure that the correct consensus state is restored after restart, the consensus persistence data also records the decision results of at least one of the BVAL message, AUX message and Term message in the RBC protocol stage, that is, the initial BA value of the proposed data determined based on the BVAL message, the intermediate BA value of the proposed data determined based on the AUX message and the final value of the proposed data determined based on the Term message.

[0035] S104, the target consensus node determines the completion status of the target consensus node for the target consensus based on the consensus messages sent and received by the target consensus node in at least one protocol stage in the consensus persistence data.

[0036] It should be understood that after the target consensus node obtains the consensus message sent and received for the target consensus before the restart, it can virtually execute the target consensus according to the consensus message sent and received, so as to determine the completion status of the target consensus before the restart.

[0037] S106, the target consensus node is restored to the completion state of the target consensus before the restart based on the logic of the Honey Badger Byzantine consensus mechanism.

[0038] It should be understood that after recovery, the target consensus node can continue the target consensus process with other consensus nodes to ensure that the target consensus can be executed smoothly.

[0039] based on Figure 1 It can be known from the restart processing method shown that in the scheme of the embodiment of this specification, the consensus node records the consensus persistent data of the consensus messages sent and received in each protocol stage under the HoneyBadgerBFT consensus mechanism in batches during the target consensus process, so that after the shutdown and restart, based on the consensus persistent data, it can be restored to the completion state of the target consensus before the restart, and then the target consensus can be executed according to the correct logic, which can avoid the block fork phenomenon of the blockchain. Because the scheme uses batch recording to store consensus persistent data, for a consensus mechanism with a complex message interaction process such as HoneyBadgerBFT, the number of write operations and storage overhead can be greatly reduced.

[0040] The main process of the restart processing method of the blockchain consensus node in the embodiment of this specification is introduced in detail below.

[0041] The solution of the embodiment of this specification introduces consensus persistence data that records the sending and receiving of consensus messages in each protocol stage for each consensus proposal in the HoneyBadgerBFT consensus mechanism.

[0042] In the HoneyBadgerBFT consensus mechanism, the consensus nodes are not synchronized in the process of executing the target consensus. Some consensus nodes have not yet completed the RBC protocol phase, while other consensus nodes may have already entered the BA protocol phase. For any consensus node, it is unknown what the completion status of other consensus nodes is during the process. Therefore, when the target consensus node is restarted during the target consensus process, it must first ensure that it is restored to the completion status of the target consensus before the restart, and secondly, it must ensure that the restart of the target consensus does not affect the execution of the target consensus by other consensus nodes.

[0043] To this end, the embodiment of this specification sets the following memory queues in the target consensus node:

[0044] The persistent cache queue persistent_queue stores the consensus persistence data generated by the target consensus node for the target consensus.

[0045] The sending queue send_queue stores the consensus messages of the RBC and BA protocol stages that the target consensus node is waiting to send and has not yet sent in the target consensus.

[0046] The resend queue resend_queue stores the consensus messages that the target consensus node needs to resend in the target consensus.

[0047] The response queue receipt_queue stores the confirmation response message to be sent by the target consensus node in the target consensus.

[0048] In the process of executing target consensus:

[0049] For persistent_queue, after the target consensus node sends any first target consensus message in persistent_queue, the first target consensus message is migrated from persistent_queue to resend_queue.

[0050] For resend_queue, the target consensus node periodically resends the consensus message in the resend_queue, and after receiving the confirmation response message sent by other consensus nodes based on any second target consensus message in the resend queue, removes the second target consensus message from the resend queue.

[0051] For receipt_queue, after receiving the consensus message sent by other consensus nodes, the target consensus node generates a corresponding confirmation response message and puts it into receipt_queue, waiting to be sent to other consensus nodes.

[0052] For persistent_queue, the target consensus node will store the consensus messages removed from resend_queue, the consensus messages received from other consensus nodes, and the BA value decision results determined in the BA protocol phase as consensus persistent data in persistent_queue. At the same time, the target consensus node will write the consensus persistent data in the persistent cache queue locally and clear the persistent cache queue according to the preset period, or, when the consensus persistent data in the persistent cache queue accumulates to the preset data volume threshold, the consensus persistent data in the persistent cache queue will be written locally and the persistent cache queue will be cleared.

[0053] Based on the above design, the consensus persistence data recorded by persistent_queue includes consensus messages that have been sent by the target consensus node and successfully received by other consensus nodes. After the target consensus node is restarted, it can reversely infer the consensus messages that it has not yet sent and the consensus messages that the target consensus node has sent but other consensus nodes have not fed back whether they have been received through the consensus persistence data, and tentatively resend the reversed consensus messages to ensure that other consensus nodes can execute the target consensus according to the correct logic.

[0054] As for the target consensus node, it can also successfully restore to the completion state of the target consensus before the restart, based on the consensus messages that it has successfully sent to other consensus nodes, the consensus messages received from other consensus nodes, and the BA value decision results determined in the BA protocol phase, recorded through persistent_queue, so as to continue to participate in the execution of the target consensus.

[0055] For ease of understanding, assume that the target consensus node has just entered the BA protocol phase before restarting, and sends its initial BA value for each proposed data to other consensus nodes through the Bval message, and has not received the Bval message sent by other consensus nodes that carries the initial BA value of each proposed data. After restarting, the target consensus node determines from the consensus persistence data of this record that only it has sent the Bval message before restarting. At this time, it can determine the link of exchanging Bval messages in the BA protocol phase before restarting, and restore to the corresponding link to wait for receiving Bval messages from other consensus nodes, so that the intermediate BA value of the proposed data can be determined according to the determined BA protocol logic and the initial BA value proposed by each consensus node in the Bval message.

[0056] The above is an introduction to the method of the embodiment of this specification. It should be understood that appropriate changes can be made without departing from the above principles of this article, and these changes should also be regarded as the protection scope of the embodiment of this specification. For example, since the target consensus node does not know the completion status of other consensus nodes for the target consensus, it is impossible to determine whether its own proposed data in this round of target consensus is successfully received by other consensus nodes after restart and recovery. In order to avoid this problem, in the embodiment of this specification, after the target consensus node is restarted, as long as it is determined that the completion status of the target consensus before the restart indicates that the proposed data initiated by itself in the target consensus has not reached a consensus, it will resend its own proposed data in this round of target consensus to other consensus nodes.

[0057] Corresponding to the above-mentioned restart processing method, the embodiment of this specification also provides a consensus node in a blockchain. Figure 2 Schematic diagram of the structure of the consensus node 200 of the embodiment of this specification, including:

[0058] The calling module 210, after restarting in the process of the target consensus, calls the consensus persistence data of the target consensus recorded before the restart, wherein the consensus persistence data includes the consensus messages sent and received in at least one protocol phase of the Honey Badger Byzantine consensus mechanism;

[0059] A determination module 220 determines a completion status for the target consensus based on consensus messages sent and received in at least one protocol phase of the Honey Badger Byzantine consensus mechanism in the consensus persistence data;

[0060] The recovery module 230, based on the logic of the Honey Badger Byzantine consensus mechanism, recovers to the completion state for the target consensus before restarting.

[0061] In the process of target consensus, the consensus nodes of the embodiments of this specification batch record the consensus persistent data of the consensus messages sent and received in each protocol stage under the HoneyBadgerBFT consensus mechanism, so that after the shutdown and restart, based on the consensus persistent data, the target consensus can be restored to the completion state before the restart, and then the target consensus can be executed according to the correct logic, which can avoid the block fork phenomenon of the blockchain. Because the scheme uses batch recording to store consensus persistent data, for a consensus mechanism with a complex message interaction process such as HoneyBadgerBFT, the number of write operations and storage overhead can be greatly reduced.

[0062] Optionally, the consensus node is provided with:

[0063] The persistent cache queue stores the consensus persistence data generated by the target consensus node for the target consensus. The consensus node also includes:

[0064] The persistence execution module, in the process of executing the target consensus, locally writes the consensus persistent data in the persistent cache queue and clears the persistent cache queue based on a preset period, or, when the consensus persistent data in the persistent cache queue of the target consensus node accumulates to a preset data volume threshold, locally writes the consensus persistent data in the persistent cache queue and clears the persistent cache queue.

[0065] Optionally, the consensus persistence data also includes: a confirmation response message received by the target consensus node and fed back by other consensus nodes based on the consensus message sent by the target consensus node. Correspondingly, the determination module 220 also determines the completion status of the target consensus for the target consensus based on the confirmation response message sent by other consensus nodes.

[0066] Optionally, the target consensus node is further provided with:

[0067] The sending queue stores consensus messages that the target consensus node is waiting to send and has not yet sent in the target consensus.

[0068] The resend queue stores consensus messages that the target consensus node needs to resend in the target consensus.

[0069] The response queue stores the confirmation response messages to be sent by the target consensus node in the target consensus.

[0070] Correspondingly, the persistent execution module is also used to: after sending any first target consensus message in the to-be-sent queue, migrate the first target consensus message from the to-be-sent queue to the resending queue; after receiving a confirmation response message sent by other consensus nodes based on any second target consensus message in the resending queue, remove the second target consensus message from the resending queue.

[0071] Among them, the consensus persistence data includes the consensus message sent by the target consensus node in at least one protocol stage of the Honey Badger Byzantine consensus mechanism, which is the consensus message removed from the resending queue by the target consensus node.

[0072] Optionally, at least one protocol phase of the Honey Badger Byzantine consensus mechanism includes: at least one of a reliable broadcast transmission RBC protocol phase and a binary agreement BA protocol phase.

[0073] If at least one protocol phase of the Honey Badger Byzantine consensus mechanism includes the BA protocol phase, the consensus persistence data also includes: the decision result of the target consensus in the BA protocol phase based on at least one of the BVAL message, the AUX message and the Term message, wherein the Bval message is used to determine the initial BA value of the proposed data of the target consensus, the AUX message is used to determine the intermediate BA value of the proposed data of the target consensus, and the Term message is used to determine the final BA value of the proposed data of the target consensus.

[0074] Optionally, the persistent execution module is also used to resend the proposal data initiated by the target consensus in the target consensus to other consensus nodes if the completion status of the determined target consensus for the target consensus indicates that the proposal data initiated by the target consensus node in the target consensus has not reached consensus.

[0075] Obviously, the consensus node in the embodiment of this specification can be used as the above Figure 1 The execution subject of the restart processing method shown in FIG. Figure 1 Since the principle is the same, this article will not repeat it.

[0076] Corresponding to the above-mentioned restart processing method, the embodiment of this specification also provides a blockchain system. Figure 3 3 is a schematic diagram of the structure of the blockchain system 300, including: a plurality of consensus nodes 310, wherein:

[0077] After any target consensus node 311 among the multiple consensus nodes 310 is restarted during the target consensus process, the consensus persistence data of the target consensus recorded by the target consensus node 311 before the restart is retrieved, wherein the consensus persistence data includes the consensus messages sent and received by the target consensus node 311 in at least one protocol stage of the Honey Badger Byzantine consensus mechanism.

[0078] The target consensus node 311 determines the completion status of the target consensus node 311 for the target consensus based on the consensus message sent and received by the target consensus node 311 in the at least one protocol stage in the consensus persistence data.

[0079] The target consensus node 311 is restored to the completion state for the target consensus before restarting based on the logic of the Honey Badger Byzantine consensus mechanism.

[0080] In the blockchain system based on the embodiment of this specification, the consensus node records the consensus persistent data of the consensus messages sent and received in each protocol stage under the HoneyBadgerBFT consensus mechanism in batches during the target consensus process, so that after the shutdown and restart, based on the consensus persistent data, it can be restored to the completion state of the target consensus before the restart, and then the target consensus can be executed according to the correct logic, which can avoid the block fork phenomenon of the blockchain. Because the solution uses batch recording to store consensus persistent data, for a consensus mechanism with a complex message interaction process such as HoneyBadgerBFT, it can achieve higher robustness with fewer write operations.

[0081] Obviously, the blockchain system of the embodiment of this specification can be used as the above Figure 1 The execution subject of the restart processing method shown in FIG. Figure 1 Since the principle is the same, this article will not repeat it.

[0082] Figure 4 This is a schematic diagram of the structure of an electronic device according to an embodiment of this specification. Figure 4 At the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and a memory. The memory may include a memory, such as a high-speed random access memory (RAM), and may also include a non-volatile memory (non-volatile memory), such as at least one disk storage. Of course, the electronic device may also include hardware required for other services.

[0083] The processor, network interface and memory can be interconnected through an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 4 Only one bidirectional arrow is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0084] The memory is used to store the program. Specifically, the program may include a program code, and the program code includes a computer operation instruction. The memory may include a memory and a non-volatile memory, and provides instructions and data to the processor.

[0085] The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it, forming the consensus master node in the above alliance chain at the logical level. The processor executes the program stored in the memory and is specifically used to perform the following operations:

[0086] After restarting during the target consensus process, the consensus persistence data of the target consensus recorded before the restart is retrieved, wherein the consensus persistence data includes consensus messages sent and received in at least one protocol phase of the Honey Badger Byzantine consensus mechanism.

[0087] Based on the consensus messages sent and received in at least one protocol phase of the Honey Badger Byzantine consensus mechanism in the consensus persistence data, a completion status for the target consensus is determined.

[0088] Based on the logic of the Honey Badger Byzantine consensus mechanism, restore to the completion state of the target consensus before restart.

[0089] In the electronic device based on the embodiment of this specification, the consensus node records the consensus persistent data of the consensus messages sent and received in each protocol stage under the HoneyBadgerBFT consensus mechanism in batches during the target consensus process, so that after the shutdown and restart, based on the consensus persistent data, it can be restored to the completion state of the target consensus before the restart, and then the target consensus can be executed according to the correct logic, which can avoid the block fork phenomenon of the blockchain. Because the solution uses batch recording to store consensus persistent data, for a consensus mechanism with a complex message interaction process such as HoneyBadgerBFT, the number of write operations and storage overhead can be greatly reduced.

[0090] The above is as in this manual Figure 1 The restart processing method disclosed in the illustrated embodiment can be applied to a processor or implemented by a processor. The 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 the processor or an instruction in the form of software. The above processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in the embodiments of this specification can be implemented or executed. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in the embodiments of this specification can be directly embodied as a hardware decoding processor for execution, or a combination of hardware and software modules in the decoding processor for execution. The software module can be located in a storage medium mature in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. 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.

[0091] It should be understood that the electronic device of the embodiment of this specification can implement the above restart processing method in Figure 1 The functions of the illustrated embodiments will not be described in detail herein.

[0092] Of course, in addition to software implementation, the electronic device of this specification does not exclude other implementation methods, such as logic devices or a 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, but can also be hardware or logic devices.

[0093] In addition, the embodiments of the present specification also provide a computer-readable storage medium, which stores one or more programs, wherein the one or more programs include instructions, which, when executed by a portable electronic device including a plurality of application programs, enable the portable electronic device to execute Figure 1 The method of the embodiment shown is specifically used to perform the following method:

[0094] After restarting during the target consensus process, the consensus persistence data of the target consensus recorded before the restart is retrieved, wherein the consensus persistence data includes consensus messages sent and received in at least one protocol phase of the Honey Badger Byzantine consensus mechanism.

[0095] Based on the consensus messages sent and received in at least one protocol phase of the Honey Badger Byzantine consensus mechanism in the consensus persistence data, a completion status for the target consensus is determined.

[0096] Based on the logic of the Honey Badger Byzantine consensus mechanism, restore to the completion state of the target consensus before restart.

[0097] Those skilled in the art will appreciate that the embodiments of this specification may be provided as methods, systems or computer program products. Therefore, this specification may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, this specification may 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.

[0098] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0099] The above are only embodiments of this specification and are not intended to limit this specification. For those skilled in the art, this specification may be subject to various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included in the scope of the claims of this specification. In addition, all other embodiments obtained by ordinary technicians in this field without creative work shall fall within the scope of protection of this document.

Claims

1. A method for restarting a blockchain consensus node, comprising: After the target consensus node of the blockchain is restarted during the target consensus process, the consensus persistence data of the target consensus recorded in batches by the target consensus node before the restart is retrieved, wherein the consensus persistence data includes the consensus message sent and received by the target consensus node in at least one protocol stage of the Honey Badger Byzantine consensus mechanism and the confirmation response message received by the target consensus node and fed back by other consensus nodes based on the consensus message sent by the target consensus node; the target consensus node determines the completion status of the target consensus node for the target consensus based on the consensus message sent and received by the target consensus node in the consensus persistence data at least one protocol stage and the confirmation response message fed back by other consensus nodes based on the consensus message sent by the target consensus node; the target consensus node is provided with: a queue to be sent, storing consensus messages to be sent and not yet sent by the target consensus node in the target consensus; a resend queue, storing consensus messages that the target consensus node needs to resend in the target consensus; a response queue, storing confirmation response messages to be sent by the target consensus node in the target consensus; The target consensus node is restored to the completion state of the target consensus before restarting based on the logic of the Honey Badger Byzantine consensus mechanism.

2. According to the method of claim 1, the target consensus node is provided with: A persistent cache queue stores the consensus persistence data generated by the target consensus node for the target consensus; in, In the process of the target consensus node executing the target consensus, the method further includes: The target consensus node locally writes the consensus persistent data in the persistent cache queue and clears the persistent cache queue based on a preset period, or, when the consensus persistent data in the persistent cache queue accumulates to a preset data volume threshold, the target consensus node locally writes the consensus persistent data in the persistent cache queue and clears the persistent cache queue.

3. The method according to claim 1, In the process of the target consensus node executing the target consensus, the method further includes: After sending any first target consensus message in the to-be-sent queue, the target consensus node migrates the first target consensus message from the to-be-sent queue to the resending queue; After receiving a confirmation response message sent by other consensus nodes based on any second target consensus message in the resending queue, the target consensus node removes the second target consensus message from the resending queue.

4. The method according to claim 1, The target consensus node determines the completion status of the target consensus node for the target consensus based on the consensus message sent and received by the target consensus node in the at least one protocol phase in the consensus persistence data, including: The target consensus node virtually executes the target consensus based on the consensus messages sent and received by the target consensus node in the at least one protocol stage in the consensus persistence data and the confirmation response messages fed back by other consensus nodes based on the consensus messages sent by the target consensus node, so as to determine the completion status of the target consensus node for the target consensus.

5. The method according to claim 1, The consensus persistence data includes a consensus message sent by the target consensus node in at least one protocol phase of the Honey Badger Byzantine consensus mechanism, which is a consensus message removed from the resending queue by the target consensus node.

6. The method according to any one of claims 1 to 5, At least one protocol phase of the Honey Badger Byzantine consensus mechanism includes: At least one of the reliable broadcast transport RBC protocol phase and the binary agreement BA protocol phase.

7. According to the method of claim 6, if at least one protocol phase of the Honey Badger Byzantine consensus mechanism includes the BA protocol phase, the consensus persistence data also includes: The target consensus is a decision result determined in the BA protocol stage based on at least one of a Bval message, an AUX message and a Term message, wherein the Bval message is used to determine an initial BA value of the proposed data of the target consensus, the AUX message is used to determine an intermediate BA value of the proposed data of the target consensus, and the Term message is used to determine a final BA value of the proposed data of the target consensus.

8. The method according to any one of claims 1 to 5, further comprising: If the determined completion status of the target consensus node for the target consensus indicates that the proposal data initiated by the target consensus node in the target consensus has not reached consensus, the target consensus node resends the proposal data initiated by the target consensus node in the target consensus to other consensus nodes.

9. A consensus node of a blockchain, comprising: The calling module, after restarting in the process of the target consensus, calls the consensus persistence data of the target consensus recorded before the restart, wherein the consensus persistence data includes the consensus messages sent and received in at least one protocol stage of the Honey Badger Byzantine consensus mechanism and the confirmation response messages received by the target consensus node from other consensus nodes based on the consensus messages sent by the target consensus node; the target consensus node is provided with: a queue to be sent, storing the consensus messages to be sent and not yet sent by the target consensus node in the target consensus; a resend queue, storing the consensus messages that the target consensus node needs to resend in the target consensus; a response queue, storing the confirmation response messages to be sent by the target consensus node in the target consensus; A determination module determines the completion status of the target consensus based on the consensus messages sent and received in at least one protocol stage of the Honey Badger Byzantine consensus mechanism in the consensus persistence data and the confirmation response messages fed back by other consensus nodes based on the consensus messages sent by the target consensus node; The recovery module, based on the logic of the Honey Badger Byzantine consensus mechanism, recovers to the completion state of the target consensus before the restart.

10. A blockchain system, comprising a plurality of consensus nodes, wherein: After any target consensus node among the multiple consensus nodes is restarted during the target consensus process, the consensus persistence data of the target consensus recorded by the target consensus node before the restart is retrieved, wherein the consensus persistence data includes the consensus message sent and received by the target consensus node in at least one protocol stage of the Honey Badger Byzantine consensus mechanism and the confirmation response message received by the target consensus node and fed back by other consensus nodes based on the consensus message sent by the target consensus node; the target consensus node determines the completion status of the target consensus node for the target consensus based on the consensus message sent and received by the target consensus node in the consensus persistence data at least one protocol stage and the confirmation response message received and fed back by other consensus nodes based on the consensus message sent by the target consensus node; the target consensus node is provided with: a queue to be sent, storing consensus messages to be sent and not yet sent by the target consensus node in the target consensus; a resend queue, storing consensus messages that the target consensus node needs to resend in the target consensus; a response queue, storing confirmation response messages to be sent by the target consensus node in the target consensus; The target consensus node is restored to the completion state for the target consensus before restart based on the logic of the Honey Badger Byzantine consensus mechanism.

Images