CN112433885A - Block chain consensus processing method and device, electronic equipment and storage medium - Google Patents
Block chain consensus processing method and device, electronic equipment and storage medium Download PDFInfo
- Publication number
- CN112433885A CN112433885A CN202011306346.6A CN202011306346A CN112433885A CN 112433885 A CN112433885 A CN 112433885A CN 202011306346 A CN202011306346 A CN 202011306346A CN 112433885 A CN112433885 A CN 112433885A
- Authority
- CN
- China
- Prior art keywords
- consensus
- log
- block
- information
- file
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Data Mining & Analysis (AREA)
- Quality & Reliability (AREA)
- Retry When Errors Occur (AREA)
Abstract
The embodiment of the application discloses a block chain consensus processing method and a device, wherein the method comprises the following steps: recording a consensus message acquired by a consensus node into a consensus log so that the consensus log stores the consensus message according to a local time sequence; in the consensus process of the consensus node according to the obtained consensus information, if the consensus node is detected to have a fault, calling the consensus log after the fault is recovered to obtain the consensus information stored by the consensus log according to a local time sequence in the consensus process; and according to the consensus information obtained from the consensus log, re-executing the consensus process in the consensus node according to the local time sequence corresponding to the consensus information. According to the technical scheme of the embodiment of the application, after the fault of the consensus node is recovered, the consensus state of the consensus node before the fault occurs can be rapidly recovered.
Description
Technical Field
The present application relates to the field of blockchain technologies, and in particular, to a blockchain consensus method and apparatus, an electronic device, and a computer-readable storage medium.
Background
At present, the consensus algorithm of the blockchain system is a memory operation, and after the downtime of the consensus node is restarted, the consensus node loses the consensus information, so that the consensus node cannot recover the consensus process, and the whole blockchain system is unavailable. Therefore, how to improve the consensus availability of the blockchain system is still a problem to be solved in the prior art.
Disclosure of Invention
In order to solve the foregoing technical problem, embodiments of the present application provide a block chain consensus processing method and apparatus, an electronic device, and a computer-readable storage medium.
According to an aspect of an embodiment of the present application, there is provided a block chain consensus processing method, including: recording a consensus message acquired by a consensus node into a consensus log so that the consensus log stores the consensus message according to a local time sequence; in the consensus process of the consensus node according to the obtained consensus information, if the consensus node is detected to have a fault, calling the consensus log after the fault is recovered to obtain the consensus information stored by the consensus log according to a local time sequence in the consensus process; and according to the consensus information obtained from the consensus log, re-executing the consensus process in the consensus node according to the local time sequence corresponding to the consensus information.
According to an aspect of the embodiments of the present application, there is provided a block chain consensus processing apparatus, including: the consensus information recording module is configured to record the consensus information acquired by the consensus node into a consensus log so that the consensus log stores the consensus information according to a local time sequence; a consensus message playback module, configured to, in a consensus process performed by the consensus node according to the obtained consensus message, if it is detected that the consensus node has a fault, call the consensus log after the fault is recovered to obtain the consensus message stored in the consensus log according to a local time sequence in the consensus process; and the consensus recovery execution module is configured to re-execute the consensus process in the consensus node according to the local time sequence corresponding to the consensus message according to the consensus message acquired from the consensus log.
According to an aspect of the embodiments of the present application, there is provided an electronic device, including a processor and a memory, where the memory stores computer-readable instructions, and the computer-readable instructions, when executed by the processor, implement the block chain consensus processing method as described above.
According to an aspect of embodiments of the present application, there is provided a computer-readable storage medium having stored thereon computer-readable instructions, which, when executed by a processor of a computer, cause the computer to execute the block chain consensus processing method as described above.
According to an aspect of embodiments herein, there is provided a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and executes the computer instructions, so that the computer device executes the block chain consensus processing method provided in the above-described various alternative embodiments.
In the technical solution provided in the embodiment of the present application, the consensus messages in the consensus process are persistently stored through the consensus log, and the consensus log stores the consensus messages according to the local time sequence, if the consensus node fails in the consensus process, the consensus messages stored according to the local time sequence in the consensus process through the consensus log are acquired after the failure is recovered, and the consensus process is re-executed in the consensus node based on the consensus messages and the local time sequence corresponding to the consensus messages, so that the consensus node can quickly recover the consensus state of the consensus node before the failure occurs after the failure is recovered, and therefore, the consensus availability of the blockchain system can be improved to a greater extent.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application. It is obvious that the drawings in the following description are only some embodiments of the application, and that for a person skilled in the art, other drawings can be derived from them without inventive effort. In the drawings:
FIG. 1 is a schematic illustration of an implementation environment to which the present application relates;
fig. 2 is a flowchart illustrating a block chain consensus processing method according to an exemplary embodiment of the present application;
FIG. 3 is a flowchart of step S130 in the embodiment shown in FIG. 2 in an exemplary embodiment;
fig. 4 is a block diagram illustrating a block chain consensus processing apparatus according to an exemplary embodiment of the present application;
FIG. 5 illustrates a schematic structural diagram of a computer system suitable for use in implementing the electronic device of an embodiment of the present application.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.
The block diagrams shown in the figures are functional entities only and do not necessarily correspond to physically separate entities. I.e. these functional entities may be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor means and/or microcontroller means.
The flow charts shown in the drawings are merely illustrative and do not necessarily include all of the contents and operations/steps, nor do they necessarily have to be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the actual execution sequence may be changed according to the actual situation.
It should also be noted that: reference to "a plurality" in this application means two or more. "and/or" describe the association relationship of the associated objects, meaning that there may be three relationships, e.g., A and/or B may mean: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship.
Referring to fig. 1, fig. 1 is a schematic diagram of an implementation environment, which is a block chain system according to the present application.
The blockchain system 100 shown in fig. 1 refers to a system for sharing data between the node devices 10 and the node devices 10, and in order to ensure information intercommunication in the blockchain system 100, there may be an information connection between the node devices 10 in the blockchain system 100, and information transmission between the node devices 10 may be performed through this information connection.
As shown in fig. 1, a node device 10 in a block chain system 100 stores a block chain 20, where the block chain 20 is composed of a plurality of blocks, each block includes a block header and a block body, and information such as a block height and a time stamp is stored in the block header.
All or part of the node devices 10 included in the blockchain system 100 participate in the consensus process of the consensus message as the consensus nodes, where the consensus message includes all the messages participating in the consensus process, for example, in the byzantine consensus algorithm, the consensus message includes a proposal message, a pre-vote message, and a pre-submit message, which need to be identified in three stages, namely, a proposal stage, a pre-vote stage, and a pre-submit stage, which are involved in the byzantine consensus algorithm. Only the consensus blocky data passing through all or some of the consensus nodes can be de-centered and reliably stored on the blockchain 20.
In the process of common identification performed on the common identification messages, the node device 10 may have a failure such as a downtime, a network disconnection, and the like, which may easily cause the common identification state of the blockchain system 100 to be stuck and the common identification of the common identification messages to be unsuccessfully completed, thereby causing the common identification of the blockchain system 100 to be unavailable.
In order to avoid the above problem, the node device 10 shown in fig. 1 records the acquired consensus messages into the consensus log, so that the consensus log stores the consensus messages according to the local time sequence, in the consensus process performed by the node device 10 according to the acquired consensus messages, if the node device 10 has a fault, the consensus log is called after the fault is recovered, so as to acquire the consensus messages stored according to the local time sequence in the consensus process performed on the consensus messages by the consensus log before the fault occurs, and then the consensus process is re-executed according to the local time sequence corresponding to the consensus messages according to the consensus messages acquired from the consensus log.
By executing the above procedure, the consensus state of the node device 10 can be quickly restored to the consensus state before the failure occurs, and the node device 10 can be efficiently added to the blockchain system 100 after the failure is restored, so that the blockchain system 100 has extremely high consensus survival performance.
It should be noted that the node device 10 in the block chain system 100 shown in fig. 1 may be an independent physical server, may also be a server cluster or a distributed system formed by a plurality of physical servers, and may also be a cloud server providing basic cloud computing services such as a cloud service, a cloud database, cloud computing, a cloud function, cloud storage, a Network service, cloud communication, a middleware service, a domain name service, a security service, a CDN (Content Delivery Network) and a big data and artificial intelligence platform, which is not limited herein.
Fig. 2 is a flowchart illustrating a block chain consensus processing method according to an exemplary embodiment of the present application.
The method may be applied to the implementation environment shown in fig. 1 and is specifically performed by the node device 20 in the embodiment environment shown in fig. 1. The method may also be applied to other blockchain systems and executed by node devices included in the blockchain systems, which is not limited in this embodiment.
As shown in fig. 2, the block chain consensus method at least includes steps S110 to S150, which are described in detail as follows:
step S110, the consensus information obtained by the consensus node is recorded in a consensus log, so that the consensus log stores the consensus information according to a local time sequence.
It should be noted that the consensus message mentioned in this embodiment includes all messages participating in the consensus process, specifically includes the consensus message generated by the consensus node itself, and also includes the consensus message sent by other consensus nodes and received by the consensus node.
For example, taking the byzantine consensus algorithm as an example for explanation, a general byzantine consensus algorithm includes three consensus phases: the first stage is a proposal stage, the second stage is a pre-vote stage, the third stage is a pre-submission stage, when the consensus information in the proposal stage is a proposal information, the consensus node can choose to accept or not accept the proposal information after acquiring the proposal information, and if the consensus node chooses to accept, the consensus process enters the pre-vote stage. In the pre-voting stage, the consensus node sends a pre-voting message to other consensus nodes, and the consensus nodes can also receive the pre-voting message sent by other consensus nodes, so that the consensus messages also comprise the pre-voting message in the pre-voting stage. In the pre-commit stage, the consensus node broadcasts the pre-commit message to other consensus nodes, the consensus node may also receive the pre-commit message broadcast by other consensus nodes, and when the consensus receives a target number of pre-commit messages, it indicates that most of the consensus nodes have agreed to the data to be written into the block chain, and therefore the consensus messages also include the pre-commit message in the pre-commit stage.
It should be understood that in an actual blockchain application scenario, since the consensus mechanism actually adopted by the blockchain system may be various, the consensus message actually acquired by the consensus node may be different from the consensus message contained in the above-mentioned byzantine consensus algorithm.
Because the consensus algorithm of the current blockchain system is a memory operation, if a certain consensus node has faults such as downtime, network disconnection and the like, data of the consensus node executing the consensus process is partially or completely lost, and the consensus node cannot recover the consensus state before the fault occurs after the fault is recovered, so that the consensus function of the whole blockchain system is unavailable. In order to solve the problem, the embodiment sets the consensus log for persistently storing the consensus messages, and specifically, the consensus node records the consensus messages into the consensus log for persistent storage before performing consensus according to the obtained consensus messages or while performing consensus according to the obtained consensus messages, so that even if the consensus node fails in the process of performing consensus, the persistently stored consensus messages can be obtained from the consensus log after the failure is recovered, and the consensus state before the failure is rapidly recovered according to the consensus messages.
In this embodiment, the consensus log stores the consensus messages acquired by the consensus node in a local time order. As described above, the consensus process performed by the consensus node is usually staged, the different stages of the consensus process have a time sequence, and the process of recording the obtained consensus message to the consensus log by the consensus node also has a time sequence, so that the consensus log is configured to store the consensus message according to the local time sequence, so that the local time sequence recorded by the consensus log of the consensus message can accurately reflect the execution time sequence of the consensus message in the consensus process, and further, after the fault is recovered, the consensus process performed based on the consensus message before the fault can be accurately played back according to the local time sequence recorded by the consensus log of the consensus message, so that the consensus state of the consensus node before the fault is quickly recovered.
It should be noted that the consensus log may be in any log form capable of storing the consensus messages according to the local time sequence, for example, a binary (also referred to as binlog) log, which is not limited in this embodiment.
Step S130, in the consensus process performed by the consensus node according to the obtained consensus message, if it is detected that the consensus node has a fault, the consensus log is called after the fault is recovered, so as to obtain the consensus message stored in the consensus log according to the local time sequence in the consensus process.
As described above, in the common byzantine consensus algorithm, the consensus process performed by the consensus node according to the obtained consensus message generally includes a proposal phase, a pre-vote phase and a pre-submission phase. In an actual block chain application scenario, the consensus process performed according to the obtained consensus message may be different from the three stages included in the byzantine consensus algorithm, and the specific consensus process is not limited in this embodiment.
In the consensus process performed according to the acquired consensus message, the detected fault of the consensus node may include a breakdown of the consensus node, a network disconnection of the consensus node, and the like, and if the restart of the consensus node is continuously detected or the network connection of the consensus node is recovered, it indicates that the fault recovery of the consensus node is completed.
After the fault is recovered, the consensus node calls the consensus log to obtain the consensus messages stored in the consensus log in the consensus process performed before the fault occurs in the consensus node, and can correspondingly obtain the local time sequence of the consensus messages recorded in the consensus log. That is, the consensus node can obtain not only the consensus messages related to processing in the consensus process executed by the consensus node before the fault occurs, but also the processing sequence of each consensus message in the consensus process by calling the consensus log. After the consensus node is recovered from the fault, the consensus process executed before the fault occurs is re-executed in the consensus node according to the processing sequence of each consensus message in the consensus process, so that the consensus mechanism of the consensus node can be quickly recovered, and the consensus state of the consensus node can be quickly recovered to the consensus state before the fault occurs.
Step S150, according to the consensus information obtained from the consensus log, re-executing the consensus process in the consensus node according to the local time sequence corresponding to the consensus information.
As described above, the consensus log stores the consensus messages acquired by the consensus nodes according to the local time sequence, which can reflect the sequence in which the consensus nodes perform the consensus process according to the consensus messages before the fault occurs, and therefore, in this embodiment, after acquiring the consensus messages from the consensus log, the consensus nodes re-perform the consensus process according to the processing sequence of each consensus message in the consensus process, and logically perform the replay process accurately on the consensus process before the fault occurs, so that the consensus nodes can quickly recover to the consensus state before the fault occurs, and the consensus nodes completing the fault recovery can be early added to the consensus process of the block chain system, and the consensus performance of the block chain system is improved to a greater extent.
In another embodiment, considering that a consensus node may generate a timeout event in a consensus process performed according to an acquired consensus message, for example, in the above-mentioned universal byzantine consensus algorithm, an arbitrary consensus phase may generate a timeout due to a low network bandwidth, and the like, in order to achieve accurate recovery of the consensus state before the consensus node fails, it is necessary to replay the corresponding timeout state in the consensus process of performing the consensus on the consensus message by the consensus node.
Therefore, in the consensus process performed by the consensus node according to the acquired consensus message, if the timeout event is detected, the timeout information corresponding to the detected timeout event is recorded in the consensus log, so that after the consensus node completes fault recovery, the timeout information recorded in the consensus process is further acquired by calling the consensus log, and then the consensus process is re-executed in the consensus node according to the consensus message and the timeout information acquired from the consensus log.
It should be noted that the timeout information corresponding to the timeout event may include parameters such as a timeout type and a timeout time value, and after the fault is recovered, the consensus node may correspondingly execute the timeout information in the re-executed consensus process, so as to implement playback processing of the timeout event in the consensus process, thereby enabling the consensus node to more accurately recover to the consensus state before the fault.
After the common node completely performs a round of common process, a block to be linked is obtained, wherein the block contains data to be stored on the blockchain and passes common knowledge of all or most common nodes contained in the blockchain system. In some embodiments, after the consensus node stores the block obtained by consensus on the block chain, the block height of the newest block on the block chain may be recorded in the consensus log.
Since the consensus logs store data according to the local time sequence, and the block height of each block in the block chain is different, the embodiment records the block height of the newest block in the block chain into the consensus log, so as to locate the data recorded in the consensus process of each round of blocks in the consensus log. For example, suppose that after the consensus node completes the last round of block consensus process, the latest block with a block height of 10001 is newly added to the block chain, so that the block height is recorded in the consensus log 10001, the consensus node immediately performs the consensus process of the block of the current round, and records the consensus message obtained in the consensus process of the block of the current round and the timeout information corresponding to the timeout event generated in the consensus process of the block of the current round into the consensus log, so that the consensus message and the timeout information stored in the consensus log after the block height of 10001 are the data recorded in the consensus process of the block of the current round.
Based on this, after the fault is recovered, the process of acquiring the consensus message stored in the consensus log according to the local time sequence in the consensus process by the consensus node may specifically include step S131 to step S135 shown in fig. 3, which is described in detail as follows:
step S131, call the consensus log to obtain the latest block height stored in the consensus log.
It should be noted that, in this embodiment, the common identification log is called, specifically, a data reading interface provided externally by the common identification log is called, and data stored in the common identification log can be read by calling the data reading interface externally, for example, the latest block height stored in the common identification log can be read to obtain the common identification information.
The consensus log can also provide a data writing interface for the external, and the external can transmit the consensus message, the timeout information corresponding to the timeout event, the block height of the latest block on the block chain, and other data to the consensus log through the data writing interface, so that the data can be persistently stored in the consensus log. In some embodiments, the data reading interface and the data writing interface provided by the above-mentioned consensus log to the outside may be the same interface, and this interface supports the call of data reading and data writing at the same time, thereby supporting the storage and reading operation of the consensus log on data.
It should be noted that the latest block height mentioned in this embodiment refers to the block height of the last block stored in the common knowledge log, for example, in the process of common knowledge of the current block, the latest block height stored in the common knowledge log is the block height of the latest block on the current block chain, and the latest block height stored in the common knowledge log is the block height of the latest block on the current block chain.
In step S133, if it is determined that the latest block height is the block height of the latest block on the block chain, the consensus information recorded according to the local time sequence in the consensus process is obtained from the consensus log.
If the latest block height stored in the consensus log is the block height of the latest block on the block chain, the consensus node is a fault in the consensus process of the block in the current round, so that the consensus process of the block in the current round is determined to be executed again in the fault recovery consensus node, and the consensus messages recorded according to the local time sequence in the consensus process are obtained from the consensus log. It should be further noted that, if the consensus log stores the timeout information generated during the consensus node executing the consensus process of the current round of blocks before the failure, the consensus messages and the timeout information recorded in the consensus process according to the local time sequence are obtained from the consensus log.
Illustratively, the common identification information and the timeout information recorded by the common identification log according to the local time sequence in the common identification process can be obtained by searching a target log file containing the block height of the latest block on the block chain and a file offset bit in the common identification log, and then reading data recorded in the target log file by taking the file offset bit as the start.
It should be understood that a plurality of log files are usually stored in the consensus log, and in the present embodiment, a log file storing the block height of the latest block in the block chain is used as the target log file, and the file offset bit refers to the location information where the block height of the latest block in the block chain is stored in the target log file. Therefore, in this embodiment, the data recorded in the target log file is read starting from the file offset corresponding to the block height of the latest block in the block chain, that is, the consensus information processed based on the time sequence in the consensus process performed by the consensus node before the failure and the time information corresponding to the timeout event occurring in the consensus process can be correspondingly obtained, so that the consensus state of the consensus node before the failure is quickly and accurately recovered based on the obtained information.
In step S135, if it is determined that the latest block height is smaller than the block height of the latest block on the block chain, the consensus process of the next round of blocks is performed.
If the height of the latest block stored in the consensus log is smaller than the height of the latest block on the block chain, the consensus node is indicated to finish the consensus process of the block in the current round, but the consensus node fails before the height of the latest block on the block chain is recorded into the consensus log, which obviously does not affect the consensus performance of the block chain system, so the consensus node can directly jump to execute the consensus process of the block in the next round, does not need to execute the consensus process of the block in the current round again, and does not need to call the data stored in the consensus log.
In other embodiments, before the consensus node performs the consensus process of the next round of blocks, the consensus node may further record the block height of the latest block on the block chain into the consensus log, so as to identify that the consensus process of the round of blocks has been completed based on the latest block height recorded in the consensus log, thereby ensuring the data integrity of the consensus process performed by the consensus log for the consensus node.
Therefore, in the method provided in the above embodiment, the data stored in the consensus log is obtained according to the size relationship between the latest block height stored in the consensus log and the block height of the latest block on the current block chain, so that the handling processing of the fault occurring in the consensus node can be flexibly performed, for example, if it is determined that the fault occurs before the block height of the latest block on the block chain is recorded in the consensus log, the consensus node does not need to re-execute the consensus process of the block in the current round, thereby further improving the consensus performance of the block chain system.
In another exemplary embodiment, the consensus log is a binary log, and the binary log manages log files in a group (commonly called group), and each log file has a limit on the size of data volume, and the total data volume size of all log files in the binary log is also limited.
When the binary log records data at the beginning, only one log file is contained, when the data volume recorded in the log file reaches a preset threshold value, the binary log generates the next log file in a polling mode, and all the log files have common prefix information, but suffix information of all the log files is different, so that different log files are distinguished through the suffix information. Therefore, the suffix information of each log file can also be used as the file index number of the corresponding log file, so that the corresponding log file can be searched in the binary log according to the file index number.
It is easy to understand that if the log files contained in the binary log are assumed to be datalog.000, datalog.001, … …, datalog ###, "000" is an initial file index number used for indexing an initial log file in the binary log, and "####" is a latest file index number used for indexing a latest log file in the binary log. With the writing of more data in the binary log, the file index number increases progressively and becomes larger, so that when a specific log file in the binary log is searched, index searching can be performed according to the corresponding relationship between the file index number corresponding to the log file and the initial file index number or the latest file index number.
Therefore, when searching the target log file and the file offset position with the block height of the latest block on the block chain as the starting point in the consensus log, the target file index number in which the block height of the latest block on the block chain is recorded can be determined, then the target log file identified by the target file index number is searched in the consensus log according to the corresponding relationship between the target file index number and the initial file index number or the latest file index number corresponding to the consensus log, and finally the file offset position of the block height of the latest block on the block chain on the target log file is obtained. If the difference between the index number of the target file and the index number of the initial file is larger than the difference between the index number of the target file and the index number of the latest file, the target log file to be searched is closer to the initial log file, so that the target log file is traversed forwards in the binary log from the initial log file, and the target log file is traversed backwards in the binary log from the latest log file.
The binary log realizes data storage in a binary mode, namely, the binary log stores binary data, so that the binary log is also provided with a data coding interface and a data decoding interface, wherein the data coding interface is used for realizing the coding of the binary data, and the data decoding interface is used for realizing the corresponding decoding of the binary data.
Therefore, when data are stored in the binary log, the data coding interface provided by the binary log is called to code the data to obtain corresponding binary data, and then the obtained binary data can be recorded in the binary log. It should be noted that the data stored in the binary log may include the consensus message, the timeout information corresponding to the timeout event, and the block height of the latest block in the current blockchain. Recording the obtained binary data into a binary log, specifically, storing the binary data into the latest log file in the binary log, and if the data volume of the latest log file is detected to reach a threshold value in the storage process of the binary data, storing the non-saved binary data into the next log file in a polling manner.
When data is read from the log file, decoded data output through the data decoding interface processing is acquired by calling a data decoding interface provided by the binary log. Specifically, the binary data recorded in the target log file are sequentially read from the file offset bit of the block height of the latest block on the block chain in the target log file as the start, and the binary data are processed and output as decoded data through the data decoding interface, so that the decoded data are acquired as data recorded in the local time sequence in the consensus process.
It should be further noted that the above-described processes of data storage and data reading performed by the binary journal can also be extended to other types of common logs, and are not limited to the above-described binary journal. The processes of data storage and data reading based on the binary logs are very convenient for storing data in the consensus process of the consensus node before the fault and re-executing the consensus process of the consensus node after the fault is recovered.
Fig. 4 is a block diagram illustrating a block chain consensus processing apparatus according to an exemplary embodiment of the present application. As shown in fig. 4, the exemplary block chain consensus processing device includes:
the consensus message recording module 210 is configured to record the consensus messages acquired by the consensus nodes into a consensus log, so that the consensus log stores the consensus messages according to a local time sequence; the consensus message playback module 230 is configured to, in a consensus process performed by the consensus node according to the obtained consensus message, if the consensus node is detected to have a fault, call the consensus log after the fault is recovered to obtain the consensus message stored in the consensus log according to a local time sequence in the consensus process; and the consensus recovery execution module 250 is configured to re-execute the consensus process in the consensus node according to the local time sequence corresponding to the consensus message according to the consensus message acquired from the consensus log.
In another exemplary embodiment, the apparatus further includes a timeout event time module, where the timeout event time module is configured to, in a consensus process performed by the consensus node according to the obtained consensus message, record timeout information corresponding to the timeout event into a consensus log if the timeout event is detected;
the consensus information playback module 230 is further configured to, after the fault recovery of the consensus node is completed, further obtain the timeout information recorded in the consensus process by calling the consensus log, so as to re-execute the consensus process in the consensus node according to the consensus information and the timeout information obtained from the consensus log.
In another exemplary embodiment, the apparatus further includes a block height recording module configured to record the block height of the newest block on the block chain into the consensus log after the consensus node stores the consensus block onto the block chain.
In another exemplary embodiment, the consensus message playback module 230 comprises:
the consensus log calling module is configured to call the consensus log to obtain the latest block height stored in the consensus log; and the consensus information acquisition module is configured to acquire consensus information recorded according to a local time sequence in a consensus process from the consensus log when the latest block height is determined to be the block height of the latest block on the block chain.
In another exemplary embodiment, the consensus message acquisition module includes:
the file searching unit is configured to search a target log file containing the block height of the latest block on the block chain and a file offset in the consensus log; and the data reading unit is configured to read the data recorded in the target log file by taking the file offset bit as a start so as to obtain the consensus information recorded by the consensus log according to the local time sequence in the consensus process.
In another exemplary embodiment, the common recognition log includes a binary log provided with a data decoding interface, and the data reading unit includes:
a binary data reading subunit configured to read binary data recorded in the target log file starting from the file offset bit; and the decoding data acquisition unit is configured to acquire the binary data, process the output decoding data through the data decoding interface, and take the decoding data as the consensus information recorded according to the local time sequence in the consensus process.
In another exemplary embodiment, the file lookup unit includes:
a target file index number obtaining subunit configured to determine a target file index number in which the block height of the latest block on the block chain is recorded; the target log file searching subunit is configured to search the target log file identified by the target file index number in the consensus log according to the corresponding relation between the target file index number and the initial file index number or the latest file index number corresponding to the consensus log; and the file offset bit acquiring subunit is configured to acquire a file offset bit of the block height of the latest block on the block chain on the target log file.
In another exemplary embodiment, the consensus message playback module 230 further includes a consensus jump execution unit configured to execute a consensus process for a next round of blocks when it is determined that the latest block height is less than the block height of the latest block on the block chain.
In another exemplary embodiment, the consensus jump execution unit further records the block height of the newest block on the block chain into the consensus log before performing the consensus process for the next round of blocks.
In another exemplary embodiment, the consensus log comprises a binary log, the binary log provided with a data encoding interface; the consensus message recording module 210 includes:
the data coding interface calling unit is configured to call a data coding interface provided by the binary log so as to code the consensus information acquired by the consensus node and obtain binary data corresponding to the consensus information; and the binary data recording unit is configured to record the binary data corresponding to the consensus information in the consensus log.
In another exemplary embodiment, the binary data recording unit includes:
the common storage subunit is configured to store the binary data corresponding to the consensus information into the latest log file in the consensus log; and the polling storage subunit is configured to poll and store the unsaved binary data into the next log file of the common log if the data amount of the latest log file is detected to reach the threshold value.
It should be noted that the apparatus provided in the foregoing embodiment and the method provided in the foregoing embodiment belong to the same concept, and the specific manner in which each module and unit execute operations has been described in detail in the method embodiment, and is not described again here.
Embodiments of the present application further provide an electronic device, which includes a processor and a memory, where the memory has stored thereon computer readable instructions, and the computer readable instructions, when executed by the processor, implement the method for processing blockchain consensus as described above.
FIG. 5 illustrates a schematic structural diagram of a computer system suitable for use in implementing the electronic device of an embodiment of the present application.
It should be noted that the computer system 1600 of the electronic device shown in fig. 5 is only an example, and should not bring any limitation to the functions and the scope of the application of the embodiments.
As shown in fig. 5, computer system 1600 includes a Central Processing Unit (CPU)1601, which can perform various appropriate actions and processes, such as executing the methods described in the above embodiments, according to a program stored in a Read-Only Memory (ROM) 1602 or a program loaded from a storage portion 1608 into a Random Access Memory (RAM) 1603. In the RAM 1603, various programs and data necessary for system operation are also stored. The CPU 1601, ROM 1602, and RAM 1603 are connected to each other via a bus 1604. An Input/Output (I/O) interface 1605 is also connected to the bus 1604.
The following components are connected to the I/O interface 1605: an input portion 1606 including a keyboard, a mouse, and the like; an output section 1607 including a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, a speaker, and the like; a storage portion 1608 including a hard disk and the like; and a communication section 1609 including a Network interface card such as a LAN (Local Area Network) card, a modem, or the like. The communication section 1609 performs communication processing via a network such as the internet. The driver 1610 is also connected to the I/O interface 1605 as needed. A removable medium 1611 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 1610 as necessary, so that a computer program read out therefrom is mounted in the storage portion 1608 as necessary.
In particular, according to embodiments of the application, the processes described above with reference to the flow diagrams may be implemented as computer software programs. For example, embodiments of the present application include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising a computer program for performing the method illustrated by the flow chart. In such embodiments, the computer program may be downloaded and installed from a network via the communication portion 1609, and/or installed from the removable media 1611. When the computer program is executed by a Central Processing Unit (CPU)1601, various functions defined in the system of the present application are executed.
It should be noted that the computer readable medium shown in the embodiments of the present application may be a computer readable signal medium or a computer readable storage medium or any combination of the two. The computer readable storage medium may be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a Read-Only Memory (ROM), an Erasable Programmable Read-Only Memory (EPROM), a flash Memory, an optical fiber, a portable Compact Disc Read-Only Memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present application, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In this application, however, a computer readable signal medium may include a propagated data signal with a computer program embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program embodied on the computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. Each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The units described in the embodiments of the present application may be implemented by software, or may be implemented by hardware, and the described units may also be disposed in a processor. Wherein the names of the elements do not in some way constitute a limitation on the elements themselves.
Another aspect of the present application also provides a computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, implements the blockchain consensus processing method as described above. The computer-readable storage medium may be included in the electronic device described in the above embodiment, or may exist separately without being incorporated in the electronic device.
Another aspect of the application also provides a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and executes the computer instructions, so that the computer device executes the block chain consensus processing method provided in the above embodiments.
The above description is only a preferred exemplary embodiment of the present application, and is not intended to limit the embodiments of the present application, and those skilled in the art can easily make various changes and modifications according to the main concept and spirit of the present application, so that the protection scope of the present application shall be subject to the protection scope of the claims.
Claims (14)
1. A block chain consensus processing method, the method comprising:
recording a consensus message acquired by a consensus node into a consensus log so that the consensus log stores the consensus message according to a local time sequence;
in the consensus process of the consensus node according to the obtained consensus information, if the consensus node is detected to have a fault, calling the consensus log after the fault is recovered to obtain the consensus information stored by the consensus log according to a local time sequence in the consensus process;
and according to the consensus information obtained from the consensus log, re-executing the consensus process in the consensus node according to the local time sequence corresponding to the consensus information.
2. The method of claim 1, further comprising:
in the consensus process of the consensus node according to the obtained consensus information, if an overtime event is detected, recording overtime information corresponding to the overtime event into the consensus log;
after the fault recovery of the consensus node is finished, the consensus log is called to further obtain the overtime information recorded in the consensus process, so that the consensus process is executed again in the consensus node according to the consensus information and the overtime information obtained from the consensus log.
3. The method of claim 1, further comprising:
after the consensus node stores the block obtained by consensus on the block chain, recording the block height of the latest block on the block chain into the consensus log.
4. The method of claim 1, wherein invoking the consensus log after failure recovery to obtain consensus messages that the consensus log stores in a local temporal order during the consensus process comprises:
calling the consensus log to obtain the latest block height stored in the consensus log;
and if the latest block height is determined to be the block height of the latest block on the block chain, acquiring the consensus information recorded according to the local time sequence in the consensus process from the consensus log.
5. The method of claim 4, wherein obtaining consensus messages recorded in a local chronological order in the consensus process from the consensus log comprises:
searching a target log file containing the block height of the latest block on the block chain and a file offset in the consensus log;
and reading the data recorded in the target log file by taking the file offset as a start so as to obtain the consensus information recorded by the consensus log according to the local time sequence in the consensus process.
6. The method of claim 5, wherein the consensus log comprises a binary log, the binary log provided with a data decoding interface; reading the data recorded in the target log file from the file offset as a start to obtain the consensus information recorded according to the local time sequence in the consensus process, wherein the consensus information comprises:
reading binary data recorded in the target log file from the file offset as a start;
and acquiring decoded data output by the binary data through the data decoding interface, and taking the decoded data as the consensus information recorded according to the local time sequence in the consensus process.
7. The method of claim 5, wherein searching the consensus log for a target log file and a file offset bit starting from a block height of a newest block in the block chain comprises:
determining a target file index number recorded with the block height of the latest block on the block chain;
searching a target log file identified by the target file index number in the consensus file according to the corresponding relation between the target file index number and the initial file index number or the latest file index number corresponding to the consensus log;
and acquiring the file offset of the block height of the latest block on the block chain on the target log file.
8. The method of claim 4, further comprising:
and if the latest block height is determined to be smaller than the block height of the latest block on the block chain, executing the consensus process of the blocks in the next round.
9. The method of claim 8, wherein before performing the consensus process for the next block, the method further comprises:
recording the block height of the newest block on the block chain into the consensus log.
10. The method of claim 1, wherein the consensus log comprises a binary log, the binary log provided with a data encoding interface; recording the consensus information acquired by the consensus node into a consensus log, wherein the recording comprises the following steps:
calling a data coding interface provided by the binary log to code the consensus information acquired by the consensus node to obtain binary data corresponding to the consensus information;
and recording binary data corresponding to the consensus information in the consensus log.
11. The method of claim 10, wherein recording binary data corresponding to the consensus message in the consensus log comprises:
storing the binary data corresponding to the consensus information into the latest log file in the consensus log;
and if the data volume of the latest log file is detected to reach a threshold value, polling and storing the unsaved binary data into the next log file of the common log.
12. An apparatus for processing block chain consensus, the apparatus comprising:
the consensus information recording module is configured to record the consensus information acquired by the consensus node into a consensus log so that the consensus log stores the consensus information according to a local time sequence;
a consensus message playback module, configured to, in a consensus process performed by the consensus node according to the obtained consensus message, if it is detected that the consensus node has a fault, call the consensus log after the fault is recovered to obtain the consensus message stored in the consensus log according to a local time sequence in the consensus process;
and the consensus recovery execution module is configured to re-execute the consensus process in the consensus node according to the local time sequence corresponding to the consensus message according to the consensus message acquired from the consensus log.
13. An electronic device, comprising:
a memory storing computer readable instructions;
a processor to read computer readable instructions stored by the memory to perform the method of any of claims 1-11.
14. A computer-readable storage medium having computer-readable instructions stored thereon, which, when executed by a processor of a computer, cause the computer to perform the method of any one of claims 1-11.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011306346.6A CN112433885B (en) | 2020-11-19 | 2020-11-19 | Block chain consensus processing method and device, electronic equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011306346.6A CN112433885B (en) | 2020-11-19 | 2020-11-19 | Block chain consensus processing method and device, electronic equipment and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112433885A true CN112433885A (en) | 2021-03-02 |
| CN112433885B CN112433885B (en) | 2021-09-10 |
Family
ID=74692772
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011306346.6A Active CN112433885B (en) | 2020-11-19 | 2020-11-19 | Block chain consensus processing method and device, electronic equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112433885B (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115378803A (en) * | 2022-04-13 | 2022-11-22 | 网易（杭州）网络有限公司 | Log management method and device, block chain node and storage medium |
| CN115811526A (en) * | 2023-02-09 | 2023-03-17 | 北京奥星贝斯科技有限公司 | Consensus method, computing node and system in distributed storage system |
| CN116938951A (en) * | 2023-09-18 | 2023-10-24 | 哈尔滨工业大学(深圳)(哈尔滨工业大学深圳科技创新研究院) | Block chain consensus method and system, electronic equipment and storage medium |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20140101484A1 (en) * | 2010-08-14 | 2014-04-10 | Teradata Corporation | Management of a distributed computing system through replication of write ahead logs |
| CN109246194A (en) * | 2018-08-13 | 2019-01-18 | 佛山市顺德区中山大学研究院 | Practical Byzantine failure tolerance block chain common recognition method and system based on more leader nodes |
| CN110473100A (en) * | 2019-08-15 | 2019-11-19 | 深圳前海微众银行股份有限公司 | A kind of transaction processing method and device based on block catenary system |
| CN110572281A (en) * | 2019-08-23 | 2019-12-13 | 华南理工大学 | Credible log recording method and system based on block chain |
| CN111291110A (en) * | 2018-12-06 | 2020-06-16 | 中国电信股份有限公司 | Consensus method and system based on block chain network |
| CN111461887A (en) * | 2020-04-01 | 2020-07-28 | 杭州溪塔科技有限公司 | Block chain consensus processing method and device and electronic equipment |
| CN111522697A (en) * | 2020-07-03 | 2020-08-11 | 支付宝(杭州)信息技术有限公司 | Restarting processing method of block chain consensus node, consensus node and block chain system |
| CN111522696A (en) * | 2020-07-03 | 2020-08-11 | 支付宝(杭州)信息技术有限公司 | Downtime processing method, data persistence method and hardware of block chain common identification node |
-
2020
- 2020-11-19 CN CN202011306346.6A patent/CN112433885B/en active Active
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20140101484A1 (en) * | 2010-08-14 | 2014-04-10 | Teradata Corporation | Management of a distributed computing system through replication of write ahead logs |
| CN109246194A (en) * | 2018-08-13 | 2019-01-18 | 佛山市顺德区中山大学研究院 | Practical Byzantine failure tolerance block chain common recognition method and system based on more leader nodes |
| CN111291110A (en) * | 2018-12-06 | 2020-06-16 | 中国电信股份有限公司 | Consensus method and system based on block chain network |
| CN110473100A (en) * | 2019-08-15 | 2019-11-19 | 深圳前海微众银行股份有限公司 | A kind of transaction processing method and device based on block catenary system |
| CN110572281A (en) * | 2019-08-23 | 2019-12-13 | 华南理工大学 | Credible log recording method and system based on block chain |
| CN111461887A (en) * | 2020-04-01 | 2020-07-28 | 杭州溪塔科技有限公司 | Block chain consensus processing method and device and electronic equipment |
| CN111522697A (en) * | 2020-07-03 | 2020-08-11 | 支付宝(杭州)信息技术有限公司 | Restarting processing method of block chain consensus node, consensus node and block chain system |
| CN111522696A (en) * | 2020-07-03 | 2020-08-11 | 支付宝(杭州)信息技术有限公司 | Downtime processing method, data persistence method and hardware of block chain common identification node |
Non-Patent Citations (1)
| Title |
|---|
| 包振山等: "基于树形拓扑网络的实用拜占庭容错共识算法", 《应用科学学报》 * |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115378803A (en) * | 2022-04-13 | 2022-11-22 | 网易（杭州）网络有限公司 | Log management method and device, block chain node and storage medium |
| CN115378803B (en) * | 2022-04-13 | 2023-12-12 | 网易（杭州）网络有限公司 | Log management method, device, blockchain node and storage medium |
| CN115811526A (en) * | 2023-02-09 | 2023-03-17 | 北京奥星贝斯科技有限公司 | Consensus method, computing node and system in distributed storage system |
| CN116938951A (en) * | 2023-09-18 | 2023-10-24 | 哈尔滨工业大学(深圳)(哈尔滨工业大学深圳科技创新研究院) | Block chain consensus method and system, electronic equipment and storage medium |
| CN116938951B (en) * | 2023-09-18 | 2024-02-13 | 哈尔滨工业大学(深圳)(哈尔滨工业大学深圳科技创新研究院) | Block chain consensus method and system, electronic equipment and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112433885B (en) | 2021-09-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112433885B (en) | Block chain consensus processing method and device, electronic equipment and storage medium | |
| US11614867B2 (en) | Distributed storage system-based data processing method and storage device | |
| US9778998B2 (en) | Data restoration method and system | |
| CN110300151B (en) | Data file uploading method and system | |
| CN109614439B (en) | Data synchronization method, device, electronic equipment and storage medium | |
| CN112437001B (en) | Method and device for guaranteeing reliable delivery and consumption of messages | |
| CN114710224A (en) | Frame synchronization method and device, computer readable medium and electronic device | |
| CN112202663A (en) | Message pushing method, device, terminal and medium | |
| CN111431952B (en) | Message pushing method, device and system, computer storage medium and electronic equipment | |
| CN110737543B (en) | Method, device and storage medium for recovering distributed file system data | |
| CN111198853B (en) | Data processing method, device, electronic equipment and computer readable storage medium | |
| CN111679892A (en) | Distributed transaction processing method, device, equipment and medium | |
| CN110597794A (en) | Data processing method and device and electronic equipment | |
| CN110119400B (en) | Unique identifier generation method and device suitable for logic operation | |
| CN107704557B (en) | Processing method and device for operating mutually exclusive data, computer equipment and storage medium | |
| CN107332679B (en) | Centerless information synchronization method and device | |
| CN113098978B (en) | Data transmission method, device and medium | |
| CN113051085B (en) | Service calling method, device, server and storage medium | |
| CN112988469B (en) | State backup method and device in alliance chain and electronic equipment | |
| CN115981828B (en) | Service message processing method and device | |
| CN109901970B (en) | Method and device for monitoring video network terminal | |
| CN115460271B (en) | Network control method and device based on edge calculation and storage medium | |
| CN111490885B (en) | Method for processing equipment error information, electronic equipment and storage medium | |
| CN109257404B (en) | Data backup method, device and system | |
| CN117493298A (en) | Database management method and device, electronic equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 40040996 Country of ref document: HK |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |