HK1246891B - Consensus method and device based on block chain - Google Patents

Description

A consensus method and device based on blockchain

Technical Field

The present application relates to the field of computer technology, and in particular to a consensus method and device based on blockchain.

Background Art

At present, blockchain technology has been widely used. Its decentralized model ensures that data is not easily tampered with, thereby improving security.

In practical applications, blockchains can provide clients with relevant business services. Blockchain nodes process user business requests and generate corresponding results. However, the blockchain may contain malicious or faulty nodes, which will undoubtedly affect the business services provided to clients. To address this, blockchain nodes can use consensus processes such as the Practical Byzantine Fault Tolerance (PBFT) algorithm to ensure that all nodes agree on the correct processing results.

Taking the PBFT-based consensus process as an example, the PBFT consensus process consists of the pre-prepare, prepare, and commit phases, as shown in Figure 1. A node (node 0) that receives a service request from a client (represented by C in Figure 1) sends the service request to other nodes (nodes 1, 2, and 3) for consensus. During each phase, each node sends a consensus message to each other, enabling them to reach consensus. After these three phases, consensus is considered reached, and each node then processes the service request and reports the results to the client.

In some scenarios in the prior art, in order to be able to handle a large number of consensus processes, multiple servers are usually set up in each node of the above-mentioned blockchain. Different servers can participate in different consensus processes respectively to improve the processing capacity and processing efficiency of the blockchain.

However, in actual applications, nodes may experience abnormalities such as server downtime or reboots. For example, in the PBFT consensus process, if a server anomaly occurs, it will be unable to participate in the consensus process and the probability of reaching consensus will be affected. If consensus is not reached, the blockchain will be restarted from the pre-preparation phase regardless of the consensus phase. This will undoubtedly affect the efficiency of the blockchain consensus and, by extension, the efficiency of the blockchain's business processing.

Summary of the Invention

The embodiments of the present application provide a blockchain-based consensus method and device to solve the problem of low consensus efficiency caused by abnormalities in the server of the current node.

An embodiment of the present application provides a consensus method based on blockchain, wherein a blockchain node includes a first server, a second server, and at least one database. The method includes:

The database stores consensus data required for consensus execution, for the first server and the second server to call during the consensus execution process;

The first server encounters an exception before or during consensus execution;

The second server replaces the first server, obtains consensus data from the database, and performs consensus based on the consensus data to generate a consensus result;

The second server stores the consensus result in the database.

The embodiment of the present application provides a consensus device based on blockchain, wherein a blockchain node includes a first server, a second server, and at least one database, wherein:

The database stores consensus data required for consensus execution, for the first server and the second server to call during the consensus execution process;

The first server encounters an exception before or during consensus execution;

The device comprises:

An acquisition module, which acquires consensus data corresponding to the consensus message from the database according to the consensus message;

A consensus execution module, executing consensus based on the consensus data and generating a consensus result;

A storage module stores the consensus message and the consensus result in the database.

The embodiments of the present application provide a consensus method and device based on blockchain. For each server in a blockchain node, the server that participates in a consensus process will "publicly" save the consensus messages of different consensus stages or the consensus results of the current stage generated by itself, that is, store them in a database within the blockchain node, and the database is available to all servers within the blockchain node. In this way, if a server participating in a consensus experiences an abnormality such as going offline or restarting, the consensus data of the server can be used by other servers within the blockchain node, and the corresponding consensus process can be continued on behalf of the server that experienced the abnormality.

Obviously, compared with the existing technology, the way in which each server in the blockchain node stores the consensus data in the database within the blockchain node means that even if a server malfunctions, other normally operating servers can obtain the corresponding consensus data from the database and take over the abnormal server to complete the consensus, thus ensuring the normal progress of the consensus process. While reducing the number of times consensus is re-initiated, it can improve the success rate of the consensus process to a certain extent, thereby improving the business processing efficiency of the blockchain.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

Figure 1 shows the consensus process based on PBFT in the prior art;

FIG2a is a diagram illustrating the architecture of a blockchain-based consensus process according to an embodiment of the present application;

Figure 2b is the architecture of the blockchain node in the blockchain-based consensus process provided by an embodiment of the present application.

FIG2c is a blockchain-based consensus process on the server side provided in an embodiment of the present application;

FIG2 d is another blockchain node architecture provided in an embodiment of the present application;

Figures 3a and 3b are schematic diagrams of a server change process in the same consensus process provided by an embodiment of the present application;

FIG4 is a schematic diagram of the structure of a blockchain-based consensus device on the server side provided in an embodiment of the present application.

DETAILED DESCRIPTION

To make the purpose, technical solutions, and advantages of this application more clear, the technical solutions of this application will be clearly and completely described below in conjunction with the specific embodiments of this application and the corresponding drawings. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

As mentioned above, during any consensus process between nodes in a blockchain, a server participating in the consensus process may experience abnormalities such as going offline or restarting, causing the server to be unable to continue participating in the consensus, thereby potentially reducing the consensus success rate. Especially when using PBFT consensus, a certain number of consensus failures may trigger the garbage collection mechanism under PBFT, clearing the consensus data from each server. Obviously, this will undoubtedly affect the business processing of the blockchain.

Based on this, the embodiments of the present application provide a blockchain-based consensus method. By storing consensus data in a database in a blockchain node, when a server fails (goes offline or restarts), other normally operating servers in the blockchain node can also read the consensus data stored in the database and continue to execute consensus on behalf of the server that failed. Of course, the blockchain-based consensus method in the embodiments of the present application is not limited to the consensus process based on PBFT, but can also be used for the consensus process of consensus algorithms such as Paxos.

It should be noted that in the embodiment of the present application, the architecture adopted by the blockchain-based consensus method is shown in Figure 2a. As can be seen from Figure 2a, the blockchain contains multiple blockchain nodes. For the convenience of subsequent description, the blockchain nodes will be referred to as nodes below.

Multiple clients can interact with the blockchain for business purposes. The blockchain can be a consortium blockchain and/or a private blockchain, providing business services to users. The clients can include browsers, applications, and other applications. The clients can run on terminals, servers, and databases, without specific limitations.

Based on the architecture shown in Figure 2a, for any node, its architecture can be as shown in Figure 2b. As can be seen in Figure 2b, the node contains n servers and a database shared by all servers. Different servers can participate in different consensus processes, and each server can operate independently of each other. The database is used to provide data storage services for each server in the node. In other words, each server can store the corresponding consensus data in the database during the consensus process. Of course, the number of databases in the node shown in Figure 2b is only a general number. In actual applications, the number of databases in the node can be adjusted according to the needs of the actual application. In addition, in some scenarios, the server in the node can be replaced by a computer or other device with computing and processing capabilities.

It should also be noted that, for ease of description, in the following text, a server that may experience anomalies during operation is referred to as the "first server." A server that can operate normally is referred to as the "second server." Therefore, the architecture shown in Figure 2b can be considered to include two types of servers: the first server and the second server. The above content should not be construed as limiting the present application.

Based on the relational architecture shown in FIG2b , an embodiment of the present application provides a consensus process based on blockchain, as shown in FIG2c . The process specifically includes the following steps:

S201: The database stores consensus data required for executing consensus, for the first server and the second server to call during the consensus execution process.

Based on the architecture shown in Figure 2b, the database is set up in the node where the server is located and is shared by all servers in the node. After any server in the node receives a consensus message or generates a consensus result, it will be stored in the database. The server can then obtain the consensus data required to execute the consensus from the database. The consensus data may include consensus messages received by the server from servers in other nodes, consensus results generated by the server itself, and service requests sent by clients that can trigger the consensus process.

It's important to note that storing consensus data in a database ensures that it's available to all servers in the node. That is, if a server experiences an anomaly, while it can no longer participate in consensus, other servers in the node can execute consensus on behalf of the anomalous server based on the consensus data stored in the database.

S202: When an exception occurs on the first server before or during consensus execution, the second server replaces the first server, obtains consensus data from the database, executes consensus based on the consensus data, and generates a consensus result.

In actual operation, the first server participating in the consensus process may experience anomalies (such as downtime, reboot, etc.). The timing of the anomaly is usually random, but whether it occurs before or during the consensus process, it will affect the completion of the consensus process. In this case, to ensure that the consensus process is not affected, another normally operating second server within the blockchain node can replace the abnormal first server to execute the consensus.

Because the first server has an exception and cannot continue to execute consensus, the second server can receive consensus messages instead of the first server and participate in the consensus process originally participated by the first server.

As mentioned above, any server in the node will store the consensus data in the database, so the second server can search and obtain the consensus data required for the consensus process in the database to replace the abnormal first server to execute the consensus and further generate the corresponding consensus result.

Obviously, the consensus is executed by the normally operating server instead of the abnormal server, ensuring that the consensus process is not affected.

S203: The second server stores the consensus result in the database.

In an embodiment of the present application, the second server that executes consensus instead of the first server will also store the consensus result as a kind of consensus data in the database according to the data storage mechanism in the present application.

Through the above steps, for each server in the blockchain node, the server that participated in a consensus process will "publicly" save the consensus messages of different consensus stages or the consensus results of the current stage generated by itself, that is, store them in the database within the node, and the database is available to all servers in the node. In this way, if a server participating in a consensus encounters an abnormality such as going offline or restarting, the consensus data of the server can be used by other servers in the node, and can continue to execute the corresponding consensus process instead of the server with the abnormality.

Obviously, compared with the existing technology, the way in which each server in the node stores the consensus data in the database within the node means that even if a server malfunctions, other normally operating servers can obtain the corresponding consensus data from the database and take over the abnormal server to complete the consensus, thus ensuring the normal progress of the consensus process. While reducing the number of times consensus is re-initiated, it can improve the success rate of the consensus process to a certain extent, thereby improving the business processing efficiency of the blockchain.

It should be noted that during consensus, any server in a node will receive consensus messages from other devices participating in the same consensus process. These other devices include, but are not limited to, other nodes and/or clients participating in the consensus process. These consensus messages may include service requests sent by clients that trigger consensus, as well as consensus data sent by other nodes during the consensus process.

Obviously, for a certain consensus process, if an exception occurs in the first server, the second server will receive the consensus message instead of the first server in order to participate in the consensus process of the first server.

Therefore, when an exception occurs before the first server executes consensus, the second server replaces the first server to obtain consensus data from the database, which may include: when an exception occurs before the first server executes consensus, the second server replaces the first server to receive consensus messages sent by other devices participating in the consensus process, and obtains consensus data corresponding to the consensus message from the database based on the consensus message.

In addition, in the embodiments of the present application, there is a retry mechanism. Specifically, after sending a consensus message or service request, if the other devices participating in the consensus process do not receive a response from the other party within a set time, they will resend the same consensus message or service request. This shows that if an abnormality occurs during the consensus execution process, the first server will not be able to respond to the other devices within the set time.

Therefore, when an exception occurs in the consensus process of the first server, the second server replaces the first server, receives the consensus message retried by other devices participating in the consensus process, and obtains the consensus data corresponding to the consensus message from the database based on the consensus message.

When the second server obtains the consensus data from the database, it is usually based on the corresponding identifier in the consensus message. The following describes the process of obtaining the consensus data from the database:

In PBFT consensus, one service request corresponds to one consensus process, and the node that receives the client's service request (also called the master node) will number the service request. In other words, the service request number can uniquely correspond to one consensus process.

Specifically, the service request number (i.e., the service request identifier) of a consensus process participated in by any server in a node can uniquely identify a consensus process. The service request number can be used to distinguish it from consensus processes participated in by other servers in the node. Therefore, if a server receives a consensus message carrying a service request number, it can retrieve the consensus data with the same service request number from the database based on the service request number (the obtained consensus data belongs to the same consensus process as the consensus message).

For example, during the consensus process, the format of a consensus message might be: <consensus stage identifier, view number, service request number, service request summary>. Suppose the server receives a consensus message: <commit, v, n, D(m)>, where commit indicates that the node has entered the confirmation phase, v represents the view number, n represents the service request number, and D(m) represents the signature of the node issuing the notification message. Based on the number "n," the server can search the database for all consensus data corresponding to that number.

Based on this, the process of the second server obtaining the consensus data corresponding to the consensus message from the database is: the second server searches and obtains the consensus data corresponding to the identifier from the database according to the identifier of the business request contained in the consensus message.

In addition to the above, in actual applications, to avoid the situation where consensus messages are sent to the first server that has experienced an anomaly, in embodiments of the present application, consensus messages can be dispatched through a gateway on the node. That is, the blockchain node also includes a gateway. In this case, the node architecture can be as shown in Figure 2d. It can be seen that the gateway is responsible for dispatching consensus messages to the servers in the node. If the first server experiences an anomaly, the gateway will not send the consensus message to the anomaly first server, but will instead send the consensus message to the normally functioning second server.

Therefore, specifically, for the second server, the process of receiving the consensus message can be:

When the gateway determines that the first server has an abnormality before executing consensus, the gateway forwards the consensus messages received from other devices participating in the consensus process to the second server that is operating normally. The second server then receives the consensus messages forwarded by the gateway from other devices participating in the consensus process.

When the gateway determines that an exception has occurred during the consensus process on the first server, the gateway forwards the received consensus message from other devices participating in the consensus process to the second server that is operating normally. Correspondingly, the second server receives the consensus message from other devices participating in the consensus process forwarded by the gateway.

It can be understood that in an embodiment of the present application, the gateway will forward the consensus message to the second server in the node where no abnormality occurs. In other words, the gateway needs to know the server in the node where the abnormality occurs and the server that is still operating normally.

In an embodiment of the present application, each server in the node can communicate with the gateway through a heartbeat mechanism so that the gateway can learn the operating status of each server. That is, the gateway determines the operating status of the first server and the second server in the following manner:

The gateway receives operation status messages sent by the first server and the second server to the gateway according to a preset period, and the gateway determines the operation status of the first server and the second server according to the operation status messages.

That is to say, if the gateway can receive periodic operation status messages, the gateway can determine that the server sending the operation status message is working normally. If the gateway does not receive the operation status message of a server within a certain period of time, the gateway can determine that the server has an abnormality.

The following is an application example:

For example, as shown in Figure 3a, assume that in a certain consensus process, server 11 in node 1 and server 21 in node 2 both participate in the consensus process (gray in Figure 3a indicates that the two servers are in the same consensus process). Assume that server 21 is offline (i.e., in node 2, server 21 is the first server). At this time, server 11 sends a consensus message to server 21. Obviously, since server 21 is offline, server 21 will not provide any feedback. Then, after waiting for a certain period of time, server 11 will initiate a retry (this retry can also be regarded as a retry initiated by node 1), that is, resend the consensus message. When the gateway of node 2 receives the consensus message retried by node 1, it will select a normally working server within it to handle the retry of node 1. As shown in Figure 3b, in this example, server 22 in node 2 is selected (i.e., server 22 is the second server). That is, the gateway will forward the consensus message sent in the retry to server 22, and server 22 will take over the consensus execution from server 21.

In addition, with respect to the process in which the second server stores the consensus data in the server, as a method in an embodiment of the present application, the second server may store the received consensus message in the database immediately after receiving the consensus message (the consensus message may be considered as a kind of consensus data), and after executing the consensus to generate a consensus result corresponding to the consensus message (the consensus result may also be considered as a kind of consensus data), the consensus result may be stored in the database.

As another method in the embodiment of the present application, after receiving the consensus message, the second server will go through the aforementioned process, wait for the consensus result to be generated, and then store the consensus message and the consensus result in the database.

The above two storage methods do not constitute a limitation to this application.

The above is a consensus method based on blockchain provided in an embodiment of the present application. Based on the same idea, an embodiment of the present application also provides a consensus device based on blockchain, as shown in FIG4 , wherein a blockchain node includes multiple servers and at least one database, wherein the database stores the consensus data required for executing the consensus, for the first server and the second server to call during the consensus execution process;

The first server encounters an exception before or during consensus execution;

The blockchain-based consensus device at least includes: a receiving module 401, an acquisition module 402, a consensus execution module 403 and a storage module 404, wherein:

An acquisition module 402 acquires consensus data from the database;

The consensus execution module 403 executes consensus according to the consensus data and generates a consensus result;

The storage module 404 stores the consensus result in the database.

When an exception occurs before the first server executes consensus, the receiving module 401 receives a consensus message sent by other devices participating in the consensus process; the acquisition module obtains the consensus data corresponding to the consensus message from the database based on the consensus message.

When an exception occurs during the consensus process of the first server, the receiving module 401 receives the consensus message sent by other devices participating in the consensus process; the acquisition module obtains the consensus data corresponding to the consensus message from the database based on the consensus message.

When the other device sends a consensus message and does not receive a response after a set time, it retries to send the consensus message.

The consensus message includes an identifier of the business request; the acquisition module 402 searches for and acquires consensus data corresponding to the identifier in the database according to the identifier of the business request included in the consensus message.

In addition, a blockchain node may also include a gateway. In this case, the device further includes at least: a gateway receiving module 405, an operating status determination module 406, and a forwarding module 407.

When the operating status determination module 406 determines that the first server has an abnormality before executing the consensus, the forwarding module 407 forwards the consensus message received from other devices participating in the consensus process to the second server that is operating normally.

When the operation status determination module 406 determines that an exception occurs in the consensus process of the first server, the forwarding module 407 forwards the received consensus message retried by other devices participating in the consensus process to the second server that is operating normally.

The gateway receiving module 405 receives the operation status message sent by the first server and the second server to the gateway according to a preset period;

The operation status determination module 406 determines the operation status of the first server and the second server according to the operation status message.

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

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

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

For the convenience of description, the above devices are described as being divided into various units according to their functions. Of course, when implementing this application, the functions of each unit can be implemented in the same or multiple software and/or hardware.

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

The present invention is described with reference to the flowcharts and/or block diagrams of the methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and/or box in the flowchart and/or block diagram, as well as the combination of processes and/or boxes in the flowchart and/or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

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

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

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

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

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

It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

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

The various embodiments in this specification are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences between the other embodiments. In particular, the system embodiments are generally similar to the method embodiments, so the description is relatively simple. For relevant parts, refer to the description of the method embodiments.

The foregoing is merely an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all be included within the scope of the claims of the present application.

Claims (10)

1. A consensus method based on blockchain, characterized in that a blockchain node includes a first server, a second server, and at least one database, the method comprising: The database stores the consensus data required for consensus execution, which can be accessed by the first server and the second server during the consensus execution process. If the first server encounters an anomaly before or during consensus execution, the second server takes over, retrieves consensus data from the database, executes consensus based on the consensus data, and generates a consensus result, specifically including: When the first server encounters an error during the consensus process, the second server takes over from the first server, receives retry messages from other devices participating in the consensus process, and retrieves the consensus data corresponding to the consensus message from the database based on the consensus message. If the other device sends a consensus message and does not receive a response after a set time, it will retry sending the consensus message; the second server stores the consensus result in the database. 2. The method as described in claim 1, characterized in that, when the first server encounters an anomaly before executing consensus, the second server replaces the first server and retrieves consensus data from the database, specifically including: When the first server encounters an anomaly before executing consensus, the second server takes over from the first server, receives consensus messages sent by other devices participating in the consensus process, and retrieves the consensus data corresponding to the consensus messages from the database based on the consensus messages. 3. The method as described in claim 2, wherein the consensus message includes an identifier of the service request; Based on the consensus message, obtain the consensus data corresponding to the consensus message from the database, specifically including: The second server searches for and retrieves consensus data corresponding to the business request identifier contained in the consensus message from the database. 4. The method as described in claim 2, wherein the blockchain node further includes a gateway; Receive consensus messages sent by other devices participating in the consensus process, specifically including: When the gateway determines that the first server has encountered an anomaly before executing consensus, the gateway will forward the consensus messages received from other devices participating in the consensus process to the normally operating second server. The second server receives consensus messages forwarded by the gateway from other devices participating in the consensus process; Receive retry messages from other devices participating in the consensus process, specifically including: When the gateway determines that the first server has encountered an anomaly during the consensus process, the gateway will resend the consensus message received from other devices participating in the consensus process and forward it to the normally operating second server. The second server receives consensus messages forwarded by the gateway from other devices participating in the consensus process that are retrying to send consensus messages. 5. The method as described in claim 4, wherein the gateway determines the operating status of the first server and the second server in the following manner: The gateway receives operation status messages sent by the first server and the second server at a preset period. The gateway determines the operating status of the first server and the second server based on the operating status message. 6. A blockchain-based consensus device, characterized in that a blockchain node comprises a first server, a second server, and at least one database, wherein, The database stores the consensus data required for consensus execution, which can be accessed by the first server and the second server during the consensus execution process. The first server encountered an anomaly before or during consensus execution; The second server includes: The acquisition module retrieves consensus data from the database; The consensus execution module performs consensus based on the consensus data and generates a consensus result. The storage module stores the consensus result in the database; The receiving module receives retry messages from other devices participating in the consensus process when an exception occurs during the consensus process of the first server; the obtaining module obtains consensus data corresponding to the consensus message from the database based on the consensus message. If the other device does not receive a response after sending a consensus message within a set time, it will retry sending the consensus message. 7. The apparatus as claimed in claim 6, wherein the apparatus further comprises: a receiving module; When the first server encounters an anomaly before executing consensus, the receiving module receives consensus messages sent by other devices participating in the consensus process; the obtaining module retrieves consensus data corresponding to the consensus messages from the database based on the consensus messages. 8. The apparatus as described in claim 7, wherein the consensus message includes an identifier of the service request; The acquisition module searches for and retrieves consensus data corresponding to the identifier of the business request contained in the consensus message from the database. 9. The apparatus of claim 8, wherein the blockchain node further comprises a gateway; The device further includes: an operating status determination module and a forwarding module; When the operation status determination module determines that the first server has an anomaly before executing consensus, the forwarding module forwards the consensus message received from other devices participating in the consensus process to the normally operating second server. When the operation status determination module determines that the first server has encountered an anomaly during the consensus process, the forwarding module forwards the consensus message received from other devices participating in the consensus process to the normally operating second server. 10. The apparatus as described in claim 9, wherein the apparatus further comprises: a gateway receiving module, for receiving running status messages sent by the first server and the second server to the gateway according to a preset period; The operation status determination module determines the operation status of the first server and the second server based on the operation status message.