CN116991623B - Block chain node exception recovery method and device, electronic equipment and storage medium - Google Patents

Block chain node exception recovery method and device, electronic equipment and storage medium Download PDF

Info

Publication number
CN116991623B
CN116991623B CN202311100937.1A CN202311100937A CN116991623B CN 116991623 B CN116991623 B CN 116991623B CN 202311100937 A CN202311100937 A CN 202311100937A CN 116991623 B CN116991623 B CN 116991623B
Authority
CN
China
Prior art keywords
view
nodes
recovery
state information
node
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.)
Active
Application number
CN202311100937.1A
Other languages
Chinese (zh)
Other versions
CN116991623A (en
Inventor
邱炜伟
黄方蕾
端豪
张珂杰
胡麦芳
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hangzhou Qulian Technology Co Ltd
Original Assignee
Hangzhou Qulian Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hangzhou Qulian Technology Co Ltd filed Critical Hangzhou Qulian Technology Co Ltd
Priority to CN202311100937.1A priority Critical patent/CN116991623B/en
Publication of CN116991623A publication Critical patent/CN116991623A/en
Application granted granted Critical
Publication of CN116991623B publication Critical patent/CN116991623B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0793Remedial or corrective actions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor

Abstract

The present disclosure relates to the field of blockchain technologies, and in particular, to a method and an apparatus for recovering abnormal points of blockchain links, an electronic device, and a storage medium; the method comprises the following steps: a response of requesting view change in a common mode is not acquired within a first preset time period, and a first view change message in a recovery mode is broadcast to other nodes in the blockchain system; the first view change message includes a resume identification of a resume mode; acquiring response messages fed back by f+1 nodes in 2f+1 normal operation nodes based on the recovery identification in the first view change message; the response message comprises state information generated by the f+1 nodes based on a practical Bayesian-busy-tolerant algorithm; after the state information is checked, the target state corresponding to the state information is restored, and the abnormal restoration is completed; the problem that abnormal nodes in the block chain system cannot be recovered due to accidental network disconnection and the like can be solved, and the stability of single nodes in the block chain system is improved.

Description

Block chain node exception recovery method and device, electronic equipment and storage medium
Technical Field
The present disclosure relates to the field of blockchain technologies, and in particular, to a method and an apparatus for recovering abnormal points of blockchain links, an electronic device, and a storage medium.
Background
The practical Bayesian fault tolerance (Practical Byzantine Fault Tolerance, PBFT) algorithm supports a cluster view change (view change) sub-protocol of the blockchain system, and when a main node of the blockchain system fails, the cluster actively switches the main node, so that the problem that the cluster enters a chaotic state and cannot advance consensus is avoided.
However, when a single node (e.g., slave node) fails or enters an abnormal state (e.g., view change occurs), the abnormal node automatically exits the current view and enters a new view; the PBFT algorithm does not support autonomous recovery of single-node abnormality, abnormal nodes cannot recover to be normal due to sporadic network disconnection and the like, and stability of single nodes in a block chain system is reduced.
Disclosure of Invention
According to various embodiments of the application, a method, a device, electronic equipment and a storage medium for recovering abnormal nodes of a blockchain are provided, so that the problem that abnormal nodes in the blockchain system cannot be recovered due to sporadic network disconnection and the like can be solved, and the stability of single nodes in the blockchain system is improved.
In a first aspect, the present application provides a blockchain node exception recovery method applied to an exception node in a blockchain system, where the blockchain system includes 3f+1 nodes, and the blockchain system allows for a maximum of f nodes with a bayer error, where f is an integer greater than or equal to 1; the method comprises the following steps:
A response of requesting view change in a common mode is not acquired within a first preset time period, and a first view change message in a recovery mode is broadcast to other nodes in the blockchain system; the first view change message comprises a recovery identifier of the recovery mode; acquiring response messages fed back by f+1 nodes in 2f+1 normal operation nodes based on the recovery identification in the first view change message; the response message comprises state information generated by f+1 nodes based on a practical Bayesian fault-tolerant algorithm; after the state information is checked, the target state corresponding to the state information is restored, and the abnormal restoration is completed.
By the mode, when the view change request of the abnormal node in the blockchain system in the normal mode is not responded, the view change request in the recovery mode can be initiated again, namely a first view change message is sent, and the response message fed back by other nodes based on the recovery identifier is obtained by adding the recovery identifier in the first view change message, so that the abnormal recovery is completed based on the state information in the response message, the normal operation of the blockchain system is not influenced, the passive recovery is not required to be carried out by triggering the cluster view change of the blockchain system by depending on the main node in the blockchain system, the abnormal recovery can be independently completed by multiplexing the state information generated by other nodes based on the practical Bayesian fault tolerance algorithm, and the stability of a single node in the blockchain system is improved; has stronger usability and practicability.
In a second aspect, the present application provides a blockchain node exception recovery method applied to nodes that normally operate in a blockchain system, the blockchain system including 3f+1 nodes, the blockchain system allowing for nodes with up to f bayer errors, f being an integer greater than or equal to 1, the method comprising:
receiving a first view change message in a recovery mode broadcast by an abnormal node in the block chain system; the first view change message is sent when the abnormal node does not acquire a response for requesting view change in the common mode within a first preset time period; when the recovery mark of the recovery mode in the first view change message is identified, a response message is sent to the abnormal node; the response message comprises state information generated based on a practical Bayesian fault-tolerant algorithm, and the response message is used for indicating the abnormal node to restore to a target state corresponding to the state information after the state information is checked.
In a third aspect, the present application provides a block link point anomaly recovery apparatus, including:
the sending unit is used for broadcasting a first view changing message in a recovery mode to other nodes in the blockchain system when a response for requesting view changing in the normal mode is not acquired within a first preset time period; the first view change message includes a resume identification of the resume mode;
An obtaining unit, configured to obtain a response message fed back by f+1 nodes in 2f+1 normal operation nodes based on the recovery identifier in the first view change message; the response message comprises state information generated by the f+1 nodes based on a practical Bayesian-busy-tolerant algorithm;
the recovery unit is used for recovering to a target state corresponding to the state information after the state information is verified, and completing abnormal recovery;
wherein the blockchain system includes 3f+1 nodes, the blockchain system allows for nodes with up to f Byzantine errors, f being an integer greater than or equal to 1.
In a fourth aspect, the present application provides a block link point anomaly recovery apparatus, including:
a receiving unit, configured to receive a first view change message in a recovery mode broadcast by an abnormal node in a blockchain system; the first view change message is sent when the abnormal node does not acquire a response for requesting view change in the common mode within a first preset duration;
a processing unit, configured to send a response message to the abnormal node when a recovery identifier of the recovery mode in the first view change message is identified; the response message comprises state information generated based on a practical Bayesian-busy-tolerant algorithm, and is used for indicating the abnormal node to recover to a target state corresponding to the state information after the state information is checked;
Wherein the blockchain system includes 3f+1 nodes, the blockchain system allows for nodes with up to f Byzantine errors, f being an integer greater than or equal to 1.
In a fifth aspect, the present application provides an electronic device comprising a memory storing a computer program and a processor implementing the method of any one of the first or second aspects when the computer program is executed.
In a sixth aspect, the present application provides a computer readable storage medium having stored thereon a computer program which when executed by a processor implements the method of any one of the first or second aspects.
In a seventh aspect, the present application provides a computer program product for, when run on an electronic device, causing the electronic device to perform the method of any one of the first or second aspects above.
It will be appreciated that the advantages of the second to seventh aspects may be found in the relevant description of the first aspect, and are not described here again.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a block chain system architecture diagram according to an embodiment of the present disclosure;
FIG. 2 is a schematic flowchart of an implementation of a method for recovering from abnormal blockchain nodes according to an embodiment of the present disclosure;
FIG. 3 is a schematic flow architecture diagram of multiple node exception recovery provided in an embodiment of the present application;
FIG. 4 is a schematic flowchart of an implementation of a method for recovering from abnormal blockchain nodes according to an embodiment of the present disclosure;
FIG. 5 is a schematic diagram illustrating interactions between nodes of a blockchain system provided in an embodiment of the present application;
fig. 6 is a schematic structural diagram of a block link point abnormality recovery device according to an embodiment of the present disclosure;
fig. 7 is a schematic structural diagram of a block link point abnormality recovery device according to an embodiment of the present disclosure;
fig. 8 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
Detailed Description
Embodiments of the technical solutions of the present application will be described in detail below with reference to the accompanying drawings. The following examples are only for more clearly illustrating the technical solutions of the present application, and thus are only examples, and are not intended to limit the scope of protection of the present application.
Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the terms "comprising" and "having" and any variations thereof in the description and claims of the present application and in the description of the figures above are intended to cover non-exclusive inclusions.
In the description of the embodiments of the present application, the technical terms "first," "second," etc. are used merely to distinguish between different objects and are not to be construed as indicating or implying a relative importance or implicitly indicating the number of technical features indicated, a particular order or a primary or secondary relationship. In the description of the embodiments of the present application, the meaning of "plurality" is two or more unless explicitly defined otherwise.
Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the present application. The appearances of such phrases in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Those of skill in the art will explicitly and implicitly appreciate that the embodiments described herein may be combined with other embodiments.
In the description of the embodiments of the present application, the term "and/or" is merely an association relationship describing an association object, which means that three relationships may exist, for example, a and/or B may mean: a exists alone, A and B exist together, and B exists alone. In addition, the character "/" herein generally indicates that the front and rear associated objects are an "or" relationship.
The PBFT algorithm cannot support autonomous recovery after single node abnormality in the blockchain system, and abnormal nodes can only passively perform abnormality recovery. For example, when a single node enters an abnormal state (e.g., view change), the abnormal node alone exits the current view and enters a new view. And as long as at least 2f+1 nodes in the whole PBFT cluster can normally communicate, the cluster can continue to advance consensus in the current view and provide service to the outside, so that the PBFT algorithm cannot autonomously recover when aiming at single node faults. Abnormal nodes cannot be recovered to be normal due to accidental network disconnection and other reasons, and the stability of a single node in a block chain system is reduced.
At present, an abnormal node can only participate in view change together with other nodes in the cluster when the view change occurs in the whole cluster, and can passively recover to the correct view to participate in a normal consensus flow. The requirement of the cluster for triggering the view change is severe, namely the cluster is triggered when the main node of the current view is abnormal. The cluster view change can cause that the whole cluster cannot provide service for the outside in a period of time, so that the cluster view change can have a certain influence on the stability of the cluster, and the cost of triggering one cluster view change for abnormal recovery of a single node is high.
The traditional single-node exception active recovery based on the PBFT algorithm improvement is mainly based on the PBFT algorithm and introduces a set of sub-protocols at the same level as the cluster view change, and because the sub-protocols are logically close to the implementation of the cluster view change initiated by the main node exception, a certain code redundancy exists on the coding implementation; and the cooperation of 2f+1 normal working nodes is needed to be completed, and the recovery requirement is relatively high; meanwhile, the sub-protocol is strongly coupled with the PBFT algorithm, so that the sub-protocol is not convenient to expand to other BYBYBJT type algorithms.
Based on the defects, the embodiment of the application provides a block chain node exception recovery method, which only increases the sub-processes of pattern recognition and self-recovery, multiplexes the main process of original view change of the PBFT algorithm, and reduces code redundancy; the recovery is completed only under the cooperation of f+1 normal working nodes, so that the recovery requirement is reduced; the realization process of the method has low coupling degree with the PBFT algorithm, and is convenient to expand to other BPT algorithms; and the stability and the user experience of the PBFT algorithm in operation are improved.
To facilitate understanding of the principles of implementation of the solutions by those skilled in the art, related technical terms are first described.
1. View change (PBFT) algorithm performs a sub-protocol of the main node switching.
2. Checkpoints (checkpoints), a checkpoint sub-protocol for garbage collection in a PBFT algorithm; in the PBFT consensus process, a node executes K requests, and broadcasts to the whole network when the execution of the K requests is completed, namely, the whole network consensus is initiated every K requests, which is called a check point, and a stable check point records the number of the K requests.
3. Bayesian fault tolerance: meaning that the distributed system can tolerate the problem of a bayer general, i.e. allowing a small fraction of malicious nodes in the cluster.
4. And (3) a master node: and initiating a consensus node of the proposal in a consistency algorithm based on semi-synchronization.
5. Quorum (quorum): and when the number of nodes in the consensus cluster is n=3f+1, quorum is 2f+1, f is the number of the most tolerant Bayesian malicious nodes, and f is an integer greater than or equal to 1.
The application scenario of the blockchain node exception recovery method provided by the application is described by a specific embodiment.
Referring to fig. 1, fig. 1 is a schematic diagram illustrating an architecture of a blockchain system provided in an embodiment of the present application. As shown in FIG. 1, a plurality of consensus nodes, such as node 1, node 2, node 3, and node 4, may be included in the architecture of the blockchain system. In one scenario: the master node stops working and does not send any message any more; when no transaction occurs, the master node with normal behavior under the current view can send a null request to all the slave nodes to maintain normal communication connection between the nodes, and if the slave nodes do not receive the null request within a specified time, the cluster view change is triggered, and the master node under the new view is elected. In another scenario: the master node sends an error message; and the slave node verifies the message sent by the master node, and if the verification is not passed, the cluster view change is initiated, and the master node under the new view is elected. When the slave node detects that the master node has an abnormal condition (for example, no null request message is received on time) or receives cluster view change messages from other f+1 nodes, the slave node broadcasts the cluster view change message to the whole network.
For example, node 3 may be the master node in the current view, and send null requests to node 1, node 2, and node 4, respectively, to maintain a normal communication connection between the nodes, and when node 3 is abnormal, node 1, node 2, or node 4 triggers a view change of the cluster.
The embodiment of the application aims at the following scenes: in the blockchain system, an abnormal single node (hereinafter referred to as an abnormal node) exists, at least 2f+1 normal operation nodes exist (otherwise, all nodes enter cluster view change, so that the abnormal node can participate in and complete state recovery), and the abnormal node is in normal communication connection with at least f+1 nodes in the 2f+1 normal operation nodes. For example, in fig. 1, node 3 is a master node, node 2 is an abnormal node, nodes 1, 3 and 4 are normal operation nodes, and at least two nodes of node 1, node 3 and 4 are in normal communication connection with node 2.
It should be noted that fig. 1 illustrates only an architecture of an asynchronous network cluster, where a greater number of consensus nodes may be included, which is not specifically limited herein.
The following describes a specific implementation procedure of the block link point anomaly recovery method based on the architecture of the block chain system.
Referring to fig. 2, a flowchart of an implementation of a blockchain node exception recovery method according to an embodiment of the present application is shown. The method may be applied to the abnormal nodes in the block chain system of fig. 1 described above. As shown in fig. 2, the method may include the steps of:
s201, when a response of requesting view change in the normal mode is not acquired within a first preset time period, broadcasting a first view change message in the recovery mode to other nodes in the blockchain system.
Wherein the first view change message includes a resume identification of the resume mode.
In the embodiment of the present application, in order to distinguish an original cluster view change in the PBFT algorithm from a view change during single-node abnormal recovery in the embodiment, the original cluster view change is defined as a view change in a normal mode, and the view change during single-node abnormal recovery is defined as a view change in a recovery mode. The view change message triggered in the recovery mode comprises a recovery identifier corresponding to the recovery mode, so as to distinguish the view change message triggered in the common mode.
For example, when an abnormality exists in a single node, a view change request in a normal mode is triggered first, and a view change in the normal mode is attempted to be entered; at this time, at least 2f+1 nodes running normally exist in the blockchain system, that is, the cluster view change cannot be triggered (the view change requirement under the PBFT algorithm cannot be met). The abnormal node determines that the triggered view change in the normal mode is overtime after waiting for a first preset time period T1 through autonomous identification of the mode, initiates a view change request in the recovery mode again, and sends out a first view change message.
TABLE 1
For example, in order to distinguish between the message sent by the View Change in the normal mode and the message sent by the View Change in the Recovery mode, a Recovery identifier (Recovery) field of the Recovery mode is added to the View Change message structure in the original PBFT algorithm to mark whether the message is in the Recovery mode or not, as shown in table 1, and the content included in the modified View Change message structure is shown in the table 1.
Illustratively, the abnormal node broadcasts a View Change message in the recovery mode, where the View Change message recovers the identified field view=true.
When the abnormal node sends the first view change message in the recovery mode, the abnormal node exits the original view and enters a new view, for example, the view value of the view where the original abnormal node is located is 2, and after the abnormal node fails, the view value entering the new view is 3, and then the view value corresponding to the view value field carried in the first view change message is 3.
In some embodiments, before broadcasting the first view change message in the resume mode to other nodes in the blockchain system, the method further includes:
And when the heartbeat message broadcast by the main node in the blockchain system is not acquired, broadcasting a second view change message in the common mode to other nodes in the blockchain system.
The second view change message is used for triggering cluster view change of the blockchain system.
Illustratively, a slave node in a blockchain system ensures a normal communication connection with a master node by receiving a heartbeat message, e.g., a null request message, sent by the master node at a prescribed time. When a single node does not receive a heartbeat message broadcast by a main node in a specified time due to the reasons of downtime of the node, disconnection of network connection with the main node and the like, the node tries to enter into view change under a common mode; only when f+1 nodes initiate view changes will the cluster view changes of the blockchain system be triggered, and because 2f+1 nodes which are normal in operation exist in the blockchain system, the second view change message in the normal mode is not responded by other nodes in the blockchain system.
Illustratively, the resume identification field in the second view change message in normal mode may be false or empty, i.e., without a true value.
S202, f+1 nodes in 2f+1 normal operation nodes are obtained to obtain response messages fed back based on the recovery identification in the first view change message.
The response message comprises state information generated by f+1 nodes based on a practical Bayesian-busy-tolerant algorithm.
In some embodiments, after receiving a first view change message of an abnormal node, the normal operation node identifies a field of a recovery identifier in the first view change message, and when determining that a field of the recovery identifier, view change, recovery is true, determines that the first view change message is a view change request in a recovery mode, and feeds back a response message, recovery response, to the abnormal node.
For example, when the normal operation node discovers the abnormal node in the recovery state based on the message identification, in order to help the abnormal node to quickly perform the abnormal recovery, the normal operation node may provide some own state information for the abnormal node to use in the recovery stage. The state information is fed back to the abnormal node in a mode of a response message RecoveryResponse, wherein the response message RecoveryResponse can comprise a latest view certificate LatestNewView and a latest stable checkpoint certificate InitialCheckPoint generated by a normal operation node in the operation process. The message structure of the response message RecoveryResponse is shown in Table 2.
TABLE 2
The latest view value certificate LatestNewView can directly multiplex a new view NewView message structure body in the PBFT algorithm, wherein the new view message structure body comprises 2f+1 node signed view change ViewChange messages; the latest stable Checkpoint voucher initilcheckpoint may directly multiplex the Checkpoint message structure in the PBFT algorithm; thereby reducing redundancy of the newly added code.
In some embodiments, after obtaining a response message for f+1 nodes of the 2f+1 normal operation nodes based on the resume identification feedback in the first view change message, the method further comprises:
checking the validity of the latest view value certificate, and the consistency of the latest view value certificates of f+1 nodes and the consistency of the latest stable check point certificates; and when the latest view value certificate is legal, the latest view value certificates of f+1 nodes are consistent, and the latest stable check point certificates are consistent, the state information is checked and passed.
Wherein the state information includes a latest view value credential and a latest stable checkpoint credential.
Illustratively, after the abnormal node receives the response message, the legitimacy of the latest view value credential in the response message is verified based on new view value checking logic of the PBFT algorithm. And after the original cluster view changing process of the PBFT algorithm comprises the calculation process of the master node of the new view, the master node of the new view broadcasts a view changing message to the slave node after the calculation and determination, the view changing message passes through 2f+1 node signature consensus, and after the cluster view changing is completed based on the PBFT algorithm, the value of the new view NewView is generated and stored in a lasting mode.
In the embodiment of the application, after receiving a response message of a normal operation node, an abnormal node checks a signature of a latest view value certificate (namely, a value of a new view is generated after cluster view change is completed based on a PBFT algorithm) and a calculation result of a new view master node; for example, confirm that new view NewView includes 2f+1 node signed view change message, and the master node of new view is consistent with new view record calculated by the information included in new view NewView message structure, so as to complete verification of validity of the latest view value certificate, and record new view in memory after checking validity.
Then, the abnormal node compares the received latest view value certificates of the f+1 nodes to confirm whether the latest view value certificates are consistent; and comparing the received latest stable check point certificates of the f+1 nodes to confirm whether the latest stable check point certificates are consistent. When the latest view value credential states of the f+1 nodes are consistent, and the latest stable check point credential states of the f+1 nodes are consistent, the state information verification is passed.
For example, when the number corresponding to the view value after the cluster view change is increased by 1, for example, the current master node is node 3, the view number is 1, and if the master node is changed to node 1 after the cluster view change, the view number is 2; upon completion of a cluster view change, the value of the new view recorded by each node is updated.
Illustratively, the checkpoint is the latest request sequence number processed by the current node (the master node will number the request record when receiving the request); for example, a request number that a node is consensus is 101, then for this node its checkpoint is 101. The stable checkpoint stable checkpoint is the maximum request sequence number that most nodes (2f+1) have consensus completed; for example, the system has 4 nodes, and the number of the request that has been commonly recognized by all three nodes is 213, and then this 213 is stable checkpoint. The stable checkpoints of the blockchain system may be updated based on the number of the request from which each node initiates the consensus, for example, when the checkpoint of node 1 is 1034, the checkpoint of node 2 is 1133, the stable checkpoints of all nodes of the current blockchain system are 1034, and when the checkpoints of node 1 are 1112 after several rounds of consensus, the stable checkpoints of all nodes may also be updated to 1100.
When the state information is checked, the new view NewView message structure body in the PBFT algorithm can be directly multiplexed through the latest view value certificate LatestNewView in the response message, and the process of legitimacy check on the latest view value certificate can be directly checked according to the new view newView check logic of the PBFT algorithm; the difficulty of coding realization is reduced by multiplexing the data structure in the PBFT algorithm.
S203, after the state information is checked, the state information is restored to the target state corresponding to the state information, and the abnormal restoration is completed.
In some embodiments, in the blockchain system, states of f+1 nodes are consistent, and enough correct nodes reach a consistent state, so that the abnormal node can autonomously recover the acquired state information of the response message RecoveryResponse as a correct target state.
In some embodiments, after the verification of the state information is passed, restoring to the target state corresponding to the state information includes:
and taking the new view corresponding to the latest view value credential as a target view, and taking the checkpoint corresponding to the latest stable checkpoint credential as a target checkpoint height, and performing exception recovery.
Wherein the target state includes a target view and a target checkpoint height.
For example, an exception node may perform state restoration based on RecoveryResponse. InitialCheckPoint as the target checkpoint height targetHeight; and performing view restoration based on the RecoveryResponse.NewView as a target view targetView to complete exception restoration.
In some embodiments, performing exception recovery with the new view corresponding to the latest view value credential as the target view and the checkpoint corresponding to the latest stable checkpoint credential as the target checkpoint height, includes:
If the block height is smaller than the target check point height, synchronizing the block height to the target check point height; and recovering to the view value of the target view based on a new view recovery mechanism in the practical Bayesian fault tolerance algorithm.
For example, the block height may be a generated state height corresponding to the node executing the transaction; firstly, judging whether the block height of the abnormal node is smaller than the target check point height targetHeight or not by the abnormal node; if the state synchronization flow is smaller than the target check point height, the state synchronization flow is synchronized to the latest target check point height, and the flow of view restoration is entered after the synchronization is completed. If the block height of the self is equal to the target check point height targetHeight, directly entering the flow of view restoration.
The abnormal node can recover the view value according to the NewView recovery algorithm flow in the PBFT algorithm.
In some embodiments, after the verification of the state information is passed, the method returns to the target state corresponding to the state information to complete the abnormal recovery, including:
after the state information is checked, restoring to the view value corresponding to the target state; updating the view value to be the view value corresponding to the target state, and storing the view value corresponding to the target state as the latest view value certificate in a lasting way.
Illustratively, after the abnormal node recovers the complete view value, the view value is updated, and the value of the latest view value certificate LatestNewView is updated and persisted to complete the single-node abnormal recovery.
As shown in fig. 3, for the first node exception recovery mode, introducing a set of sub-protocols at the same level as the cluster view change of the PBFT algorithm, broadcasting recovery information after an exception occurs in a single node, comparing the received checkpoints and block heights based on the PBFT algorithm after the checkpoints and block heights of 2f+1 nodes are obtained, determining the checkpoint height of a target node, and obtaining state variables in the transaction information consensus process depending on the PBFT algorithm to recover the exception; because the sub-protocol is logically close to the implementation of cluster view modification initiated based on the master node exception, there is some code redundancy in the encoded implementation.
For the view changing mode of the second PBFT algorithm, when the master node is abnormal, the slave node broadcasts a view changing message, the master node in the new view is determined through calculation, after the master node in the new view receives the view changing message and the check point message initiated by 2f+1 nodes, the cluster view changing message (a data structure body of the new view message and the check point message is called), and after verification of the received cluster view changing message is passed, the slave node changes the cluster view.
In the third mode for recovering the node abnormality provided in the embodiment of the present application, when the node is abnormal (the abnormal node may also be a master node), a sub-flow of autonomous mode judgment and autonomous recovery is newly added, and a main flow and a data structure of view change in the PBFT algorithm are multiplexed, so that the difficulty in implementing coding and redundancy of the newly added coding are reduced. When the abnormal node is the main node, the flow of cluster view change can be triggered based on the second PBFT algorithm, and view recovery is realized; when the abnormal node is a single node (slave node under the current view), firstly triggering view change under the common mode (namely broadcasting a second view change message), and when no response message is received within a first preset time, triggering view change under the recovery mode again (namely broadcasting a first view change message), multiplexing a data structure of a new view message and a check point message under the PBFT algorithm based on a data structure of the response message after collecting response messages fed back by f+1 nodes, and performing view change of the single node based on a view recovery flow of the PBFT algorithm, so as to complete autonomous recovery of the single node abnormality.
According to the embodiment of the application, through the method, only the sub-processes of pattern recognition and self-recovery are added, the data structure and the main process in the PBFT algorithm can be multiplexed, and the difficulty of coding realization is reduced; the recovery of the abnormal node can be completed by the cooperation of f+1 normal working nodes, so that the recovery requirement is reduced; the coupling degree of the newly added sub-flow of pattern recognition and self-recovery and the PBFT algorithm is low, and the sub-flow can be expanded to other BFT algorithms; and the stability and the user experience of the PBFT algorithm in operation are improved.
As shown in fig. 4, the method for recovering abnormal blockchain nodes provided in the embodiment of the present application may be applied to nodes that normally operate in the architecture of fig. 1. Based on the same implementation principle as the process described in the above embodiment, a detailed description is omitted here. As shown in fig. 4, the method may include the steps of:
s401, receiving a first view change message in a recovery mode broadcast by an abnormal node in the blockchain system.
The first view changing message is sent when the abnormal node does not acquire the response of requesting view changing in the common mode within a first preset duration.
S402, when the recovery identification of the recovery mode in the first view change message is identified, a response message is sent to the abnormal node.
The response message comprises state information generated based on a practical Bayesian-busy-tolerant algorithm, and the response message is used for indicating the abnormal node to restore to a target state corresponding to the state information after the state information is checked.
The following describes a procedure for implementing node exception recovery through interaction between nodes in a specific application in conjunction with the blockchain system architecture shown in fig. 1. As shown in fig. 5, in the interaction process between nodes of the blockchain system provided in the embodiment of the present application, node 3 is used as a master node to send null requests to nodes 1, 2 and 4 according to a specified time, and at this time, the view values v=2 of all the nodes; when the node 2 is abnormal, if the null request sent by the master node is not received within a specified time or the time waiting for the null request is overtime, a view change message in a normal mode is sent to at least f+1 other nodes (for example, node 3 and node 4, and the communication connection between the node 1 and the node 2 is disconnected) which are in communication connection with the node 2, wherein the view change message carries a view value v=3 of a new view, at this time, the view value v=3 recorded by the node 2, and the view value v=2 corresponding to 2f+1 normal operation nodes (node 1, node 3 and node 4) in the system. If the node 2 does not receive the response message of other nodes or the time waiting for the response is overtime, the node 2 sends a first view changing message in the recovery mode again, wherein the first view changing message comprises a view value v=3 of the new view and a recovery identification field vc. At this time, the view value v=3 recorded by the node 2, and the view values v=2 corresponding to 2f+1 normal operation nodes (node 1, node 3 and node 4) in the system. After receiving the first view change message with the restoring identification field true, the node 3 and the node 4 feed back a response message to the node 2, wherein the response message comprises view values v=2 corresponding to the node 3 and the node 4, the node 2 carries out view restoration based on the view values of the response message, restores the view values to v=2, and completes abnormal restoration, so that the following consensus process can be normally participated.
According to the embodiment of the application, when a single node fails, the failed node does not repeatedly send an invalid View Change message, but introduces a View Change of a new mode, and after the View Change request in the normal mode is tried to fail once, the View Change is autonomously switched to the View Change in the recovery mode; instead of passively waiting for the cluster to enter the view change, the active view change is selectively tried to request other correct nodes to return state information to complete state recovery of the nodes; when the fault is recovered, f+1 pieces of normal and consistent state information are collected and can be used as a correct target state for carrying out abnormal recovery, so that the recovery requirement is reduced; meanwhile, the coupling degree between the node abnormal recovery process and the PBFT algorithm is reduced, and the newly added pattern recognition and self-recovery process can be expanded to other BFT type algorithms.
It should be understood that the sequence number of each step in the foregoing embodiment does not mean that the execution sequence of each process should be determined by the function and the internal logic of each process, and should not limit the implementation process of the embodiment of the present application in any way.
Corresponding to the blockchain node exception recovery method provided in the above embodiment, fig. 7 shows a schematic structural diagram of the blockchain node exception recovery device provided in the embodiment of the present application, and for convenience of explanation, only the portion relevant to the embodiment of the present application is shown.
Referring to fig. 6, the blockchain node exception recovery device includes:
a sending unit 61, configured to broadcast a first view change message in a recovery mode to other nodes in the blockchain system when a response requesting a view change in a normal mode is not acquired within a first preset duration; the first view change message includes a resume identification of the resume mode;
an obtaining unit 62, configured to obtain a response message fed back by f+1 nodes in 2f+1 normal operation nodes based on the recovery identifier in the first view change message; the response message comprises state information generated by the f+1 nodes based on a practical Bayesian-busy-tolerant algorithm;
a recovery unit 63, configured to recover to a target state corresponding to the state information after the state information is verified, and complete abnormal recovery;
wherein the blockchain system includes 3f+1 nodes, the blockchain system allows for nodes with up to f Byzantine errors, f being an integer greater than or equal to 1.
In a possible implementation manner, the sending unit 61 is further configured to broadcast, when a heartbeat message broadcast by a master node in the blockchain system is not acquired, a second view change message in the normal mode to other nodes in the blockchain system; the second view change message is used for triggering cluster view change of the blockchain system.
In one possible implementation, the state information includes a latest view value credential and a latest stable checkpoint credential; the device also comprises a verification unit, a verification unit and a verification unit, wherein the verification unit is used for checking the validity of the latest view value certificate, and the consistency of the latest view value certificates of the f+1 nodes and the consistency of the latest stable check point certificates; and when the latest view value certificates are legal, the latest view value certificates of the f+1 nodes are consistent, and the latest stable check point certificates are consistent, the state information verification is passed.
In a possible implementation manner, the restoring unit 63 is further configured to perform exception restoration by using the new view corresponding to the latest view value credential as a target view and using a checkpoint corresponding to the latest stable checkpoint credential as a target checkpoint height; the target state includes the target view and the target checkpoint height.
In a possible implementation, the recovery unit 63 is further configured to synchronize the block height to the target checkpoint height if the block height is smaller than the target checkpoint height; and recovering the view value of the target view based on a new view recovery mechanism in the practical Bayesian and busy-tolerant algorithm.
In a possible implementation manner, the restoring unit 63 is further configured to restore to the view value corresponding to the target state after the state information is verified; updating the view value to be the view value corresponding to the target state, and storing the view value corresponding to the target state as the latest view value certificate in a lasting way.
Corresponding to the blockchain node exception recovery method provided in the above embodiment, fig. 7 shows a schematic structural diagram of the blockchain node exception recovery device provided in the embodiment of the present application, and for convenience of explanation, only the portion relevant to the embodiment of the present application is shown.
Referring to fig. 7, the blockchain node exception recovery device includes:
a receiving unit 71 for receiving a first view change message in a recovery mode broadcast by an abnormal node in the blockchain system; the first view change message is sent when the abnormal node does not acquire a response for requesting view change in the common mode within a first preset duration;
A processing unit 72, configured to send a response message to the abnormal node when the recovery identifier of the recovery pattern in the first view change message is identified; the response message comprises state information generated based on a practical Bayesian-busy-tolerant algorithm, and is used for indicating the abnormal node to recover to a target state corresponding to the state information after the state information is checked;
wherein the blockchain system includes 3f+1 nodes, the blockchain system allows for nodes with up to f Byzantine errors, f being an integer greater than or equal to 1.
Fig. 8 shows a schematic diagram of the hardware configuration of the electronic device 8.
As shown in fig. 8, the electronic device 8 of this embodiment includes: at least one processor 80 (only one is shown in fig. 8), a memory 81, said memory 81 having stored therein a computer program 82 executable on said processor 80. The steps in the above-described method embodiments are implemented when the processor 80 executes the computer program 82, for example S201 to S203 shown in fig. 2 or S401 to S402 shown in fig. 4. Alternatively, the processor 80, when executing the computer program 82, performs the functions of the modules/units of the apparatus embodiments described above.
It is to be understood that the structure illustrated in the embodiments of the present application does not constitute a specific limitation on the electronic device 8. In other embodiments of the present application, the electronic device 8 may include more or fewer components than shown, or certain components may be combined, or certain components may be split, or different arrangements of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.
The electronic device 8 may be a node of the blockchain system, for example, a computing device such as a desktop computer, a notebook computer, a palm computer, and a cloud server. The electronic device 8 may include, but is not limited to, a processor 80, a memory 81. It will be appreciated by those skilled in the art that fig. 8 is merely an example of the electronic device 8 and is not meant to be limiting as the electronic device 8, and may include more or fewer components than shown, or may combine certain components, or different components, e.g., the server may also include an input transmitting device, a network access device, a bus, etc.
The processor 80 may be a central processing unit (Central Processing Unit, CPU), but may also be other general purpose processors, digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), off-the-shelf programmable gate arrays (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
A memory may also be provided in the processor 80 for storing instructions and data. In some embodiments, the memory in the processor 80 is a cache memory. The memory may hold instructions or data that the processor 80 has just used or recycled. If the processor 80 needs to reuse the instruction or data, it may be called directly from the memory. Repeated accesses are avoided and the latency of the processor 80 is reduced, thereby improving the efficiency of the system.
The above-mentioned memory 81 may in some embodiments be an internal storage unit of the electronic device 8, such as a hard disk or a memory of the electronic device 8. The memory 81 may also be an external storage device of the electronic device 8, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card) or the like, which are provided on the electronic device 8. Further, the memory 81 may also include both an internal storage unit and an external storage device of the electronic device 8. The memory 81 is used for storing an operating system, application programs, boot loader (BootLoader), data, other programs, etc., such as program codes of computer programs, etc. The memory 81 may also be used to temporarily store data that has been transmitted or is to be transmitted.
In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.
It should be noted that the structure of the electronic device is only illustrated by way of example, and other entity structures may be included based on different application scenarios, and the entity structure of the electronic device is not limited herein.
In the foregoing embodiments, the descriptions of the embodiments are emphasized, and in part, not described or illustrated in any particular embodiment, reference is made to the related descriptions of other embodiments.
The present application also provides a computer readable storage medium storing a computer program which, when executed by a processor, implements steps for implementing the various method embodiments described above.
The present embodiments provide a computer program product which, when run on a server, causes the server to perform steps that enable the implementation of the method embodiments described above.
The integrated modules/units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the present application may implement all or part of the flow of the method of the above embodiment, or may be implemented by a computer program to instruct related hardware, where the computer program may be stored in a computer readable storage medium, and when the computer program is executed by a processor, the computer program may implement the steps of each method embodiment described above. Wherein the computer program comprises computer program code, which may be in the form of source code, object code, executable files or in some intermediate form, etc. The computer readable medium may include: any entity or device capable of carrying computer program code, a recording medium, a U disk, a removable hard disk, a magnetic disk, an optical disk, a computer Memory, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), an electrical carrier signal, a telecommunications signal, a software distribution medium, and so forth.
The algorithm development platform, the electronic device, the computer storage medium, and the computer program product provided in the embodiments of the present application are all configured to execute the method provided above, so that the beneficial effects achieved by the algorithm development platform, the electronic device, the computer storage medium, and the computer program product can refer to the beneficial effects corresponding to the method provided above, and are not described herein again.
It should be understood that the foregoing is only intended to assist those skilled in the art in better understanding the embodiments of the present application and is not intended to limit the scope of the embodiments of the present application. It will be apparent to those skilled in the art from the foregoing examples that various equivalent modifications or variations can be made, for example, certain steps may not be necessary in the various embodiments of the detection methods described above, or certain steps may be newly added, etc. Or a combination of any two or more of the above. Such modifications, variations, or combinations are also within the scope of embodiments of the present application.
The technical features of the above embodiments may be arbitrarily combined, and all possible combinations of the technical features in the above embodiments are not described for brevity of description, however, as long as there is no contradiction between the combinations of the technical features, they should be considered as the scope of the description.
It should be understood that the foregoing is only intended to assist those skilled in the art in better understanding the embodiments of the present application and is not intended to limit the scope of the embodiments of the present application. It will be apparent to those skilled in the art from the foregoing examples that various equivalent modifications or variations can be made, for example, certain steps may not be necessary in the various embodiments of the detection methods described above, or certain steps may be newly added, etc. Or a combination of any two or more of the above. Such modifications, variations, or combinations are also within the scope of embodiments of the present application.
It should also be understood that the manner, condition, class and division of the embodiments in the embodiments of the present application are for convenience of description only and should not be construed as being particularly limited, and the various manners, classes, conditions and features of the embodiments may be combined without contradiction.
It is also to be understood that in the various embodiments of the application, terms and/or descriptions of the various embodiments are consistent and may be referenced to one another in the absence of a particular explanation or logic conflict, and that the features of the various embodiments may be combined to form new embodiments in accordance with their inherent logic relationships.
Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
In the embodiments provided in the present application, it should be understood that the disclosed apparatus/network device and method may be implemented in other manners. For example, the apparatus/network device embodiments described above are merely illustrative, e.g., the division of the modules or units is merely a logical functional division, and there may be additional divisions in actual implementation, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection via interfaces, devices or units, which may be in electrical, mechanical or other forms.
The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
The above embodiments are only for illustrating the technical solution of the present application, and are not limiting; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application, and are intended to be included in the scope of the present application.
Finally, it should be noted that: the foregoing is merely a specific embodiment of the present application, but the protection scope of the present application is not limited thereto, and any changes or substitutions within the technical scope of the present disclosure should be covered in the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims (11)

1. A block chain link point anomaly recovery method, characterized by being applied to anomaly nodes in a block chain system, wherein the block chain system comprises 3f+1 nodes, the block chain system allows nodes with at most f Bayesian errors, and f is an integer greater than or equal to 1; the method comprises the following steps:
a response of requesting view change in a common mode is not acquired within a first preset duration, and a first view change message in a recovery mode is broadcast to other nodes in the blockchain system; the first view change message includes a resume identification of the resume mode;
acquiring response messages fed back by f+1 nodes in 2f+1 normal operation nodes based on the recovery identification in the first view change message; the response message comprises state information generated by the f+1 nodes based on a practical Bayesian-busy-tolerant algorithm;
after the state information is checked, the state information is restored to a target state corresponding to the state information, and abnormal restoration is completed;
wherein the state information includes a latest view value credential and a latest stable checkpoint credential.
2. The method of claim 1, wherein prior to said broadcasting the first view change message in resume mode to other nodes in the blockchain system, the method further comprises:
When the heartbeat message broadcast by the main node in the blockchain system is not acquired, broadcasting a second view change message in the common mode to other nodes in the blockchain system; the second view change message is used for triggering cluster view change of the blockchain system.
3. The method of claim 1, wherein the state information includes a latest view value credential and a latest stable checkpoint credential; after the obtaining of the response message that f+1 nodes in 2f+1 normal operation nodes feed back based on the resume identification in the first view change message, the method further includes:
checking validity of the latest view value credential, and consistency of the latest view value credential and consistency of the latest stable checkpoint credential for the f+1 nodes;
and when the latest view value certificates are legal, the latest view value certificates of the f+1 nodes are consistent, and the latest stable check point certificates are consistent, the state information verification is passed.
4. A method according to claim 3, wherein said restoring to the target state corresponding to the state information after the verification of the state information is passed comprises:
Taking the new view corresponding to the latest view value evidence as a target view, taking a check point corresponding to the latest stable check point evidence as a target check point height, and performing exception recovery; the target state includes the target view and the target checkpoint height.
5. The method of claim 4, wherein the performing exception recovery with the new view corresponding to the latest view value credential as a target view and the checkpoint corresponding to the latest stable checkpoint credential as a target checkpoint height comprises:
synchronizing the block height to the height of the target checkpoint if the block height is less than the target checkpoint height;
and recovering the view value of the target view based on a new view recovery mechanism in the practical Bayesian and busy-tolerant algorithm.
6. The method according to any one of claims 1 to 5, wherein after the verification of the state information is passed, restoring to a target state corresponding to the state information, and completing the exception recovery, includes:
after the state information passes the verification, restoring to the view value corresponding to the target state;
updating the view value to be the view value corresponding to the target state, and storing the view value corresponding to the target state as the latest view value certificate in a lasting way.
7. A block link point anomaly recovery method applied to nodes operating normally in a block chain system including 3f+1 nodes, the block chain system allowing for the presence of at most f nodes with a bayer pattern error, f being an integer greater than or equal to 1, the method comprising:
receiving a first view change message in a recovery mode broadcast by an abnormal node in the blockchain system; the first view change message is sent when the abnormal node does not acquire a response for requesting view change in the common mode within a first preset duration;
when the recovery identification of the recovery mode in the first view change message is identified, a response message is sent to the abnormal node; the response message comprises state information generated based on a practical Bayesian-busy-tolerant algorithm, and is used for indicating the abnormal node to recover to a target state corresponding to the state information after the state information is checked;
wherein the state information includes a latest view value credential and a latest stable checkpoint credential.
8. A block link point anomaly recovery device, comprising:
The sending unit is used for broadcasting a first view changing message in a recovery mode to other nodes in the blockchain system when a response for requesting view changing in the normal mode is not acquired within a first preset time period; the first view change message includes a resume identification of the resume mode;
an obtaining unit, configured to obtain a response message fed back by f+1 nodes in 2f+1 normal operation nodes based on the recovery identifier in the first view change message; the response message comprises state information generated by the f+1 nodes based on a practical Bayesian-busy-tolerant algorithm;
the recovery unit is used for recovering to a target state corresponding to the state information after the state information is verified, and completing abnormal recovery;
wherein the blockchain system includes 3f+1 nodes, the blockchain system allowing for the presence of up to f nodes with a Bayesian error, f being an integer greater than or equal to 1; the state information includes a latest view value credential and a latest stable checkpoint credential.
9. A block link point anomaly recovery device, comprising:
a receiving unit, configured to receive a first view change message in a recovery mode broadcast by an abnormal node in a blockchain system; the first view change message is sent when the abnormal node does not acquire a response for requesting view change in the common mode within a first preset duration;
A processing unit, configured to send a response message to the abnormal node when a recovery identifier of the recovery mode in the first view change message is identified; the response message comprises state information generated based on a practical Bayesian-busy-tolerant algorithm, and is used for indicating the abnormal node to recover to a target state corresponding to the state information after the state information is checked;
wherein the blockchain system includes 3f+1 nodes, the blockchain system allowing for the presence of up to f nodes with a Bayesian error, f being an integer greater than or equal to 1; the state information includes a latest view value credential and a latest stable checkpoint credential.
10. An electronic device comprising a memory storing a computer program and a processor implementing the method of any one of claims 1 to 7 when the computer program is executed by the processor.
11. A computer readable storage medium, on which a computer program is stored, characterized in that the computer program, when being executed by a processor, implements the method of any of claims 1 to 7.
CN202311100937.1A 2023-08-30 2023-08-30 Block chain node exception recovery method and device, electronic equipment and storage medium Active CN116991623B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311100937.1A CN116991623B (en) 2023-08-30 2023-08-30 Block chain node exception recovery method and device, electronic equipment and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311100937.1A CN116991623B (en) 2023-08-30 2023-08-30 Block chain node exception recovery method and device, electronic equipment and storage medium

Publications (2)

Publication Number Publication Date
CN116991623A CN116991623A (en) 2023-11-03
CN116991623B true CN116991623B (en) 2024-01-02

Family

ID=88526746

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311100937.1A Active CN116991623B (en) 2023-08-30 2023-08-30 Block chain node exception recovery method and device, electronic equipment and storage medium

Country Status (1)

Country Link
CN (1) CN116991623B (en)

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109784916A (en) * 2018-12-12 2019-05-21 广东工业大学 A method of ether mill common recognition mechanism that improving PBFT is applied to alliance's chain
CN110460484A (en) * 2019-10-10 2019-11-15 杭州趣链科技有限公司 A kind of single node exception active restoration methods based on PBFT algorithm improvement
CN110796547A (en) * 2019-10-30 2020-02-14 桂林电子科技大学 Improved practical Byzantine fault-tolerant system based on alliance block chain
CN111444211A (en) * 2020-03-26 2020-07-24 腾讯科技(深圳)有限公司 Block chain consensus node checking method, device, equipment and storage medium
CN115296812A (en) * 2022-06-22 2022-11-04 国网河北省电力有限公司信息通信分公司 Block chain-based high-reliability recovery and check mechanism for electric power data storage nodes
CN115473908A (en) * 2022-11-03 2022-12-13 山东区块链研究院 Block chain link point fault recovery method and block chain system
CN115632933A (en) * 2019-12-24 2023-01-20 杭州趣链科技有限公司 PBFT algorithm-based cluster exception recovery method
CN116633942A (en) * 2023-04-26 2023-08-22 浙江大学 Bayesian-busy fault tolerance consensus method for high-speed response client

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6880227B2 (en) * 2019-03-18 2021-06-02 アドバンスド ニュー テクノロジーズ カンパニー リミテッド Recovery of consensus system downtime
WO2019170169A2 (en) * 2019-06-05 2019-09-12 Alibaba Group Holding Limited Consensus system and method

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109784916A (en) * 2018-12-12 2019-05-21 广东工业大学 A method of ether mill common recognition mechanism that improving PBFT is applied to alliance's chain
CN110460484A (en) * 2019-10-10 2019-11-15 杭州趣链科技有限公司 A kind of single node exception active restoration methods based on PBFT algorithm improvement
CN110796547A (en) * 2019-10-30 2020-02-14 桂林电子科技大学 Improved practical Byzantine fault-tolerant system based on alliance block chain
CN115632933A (en) * 2019-12-24 2023-01-20 杭州趣链科技有限公司 PBFT algorithm-based cluster exception recovery method
CN111444211A (en) * 2020-03-26 2020-07-24 腾讯科技(深圳)有限公司 Block chain consensus node checking method, device, equipment and storage medium
CN115296812A (en) * 2022-06-22 2022-11-04 国网河北省电力有限公司信息通信分公司 Block chain-based high-reliability recovery and check mechanism for electric power data storage nodes
CN115473908A (en) * 2022-11-03 2022-12-13 山东区块链研究院 Block chain link point fault recovery method and block chain system
CN116633942A (en) * 2023-04-26 2023-08-22 浙江大学 Bayesian-busy fault tolerance consensus method for high-speed response client

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
基于改进的PBFT算法的性能模型研究;储劲松;鲍可进;夏纯中;;计算机与数字工程(第09期);全文 *

Also Published As

Publication number Publication date
CN116991623A (en) 2023-11-03

Similar Documents

Publication Publication Date Title
CN111258822B (en) Data processing method, server, and computer-readable storage medium
US5941999A (en) Method and system for achieving high availability in networked computer systems
US6671821B1 (en) Byzantine fault tolerance
US8464091B2 (en) Byzantine fault tolerant dynamic quorum using a trusted platform module
US6754845B2 (en) Method of achieving optimistic multiple processor agreement in potentially asynchronous networks
US20180150501A1 (en) Database system, server device, computer program product, and information processing method
CN110535680B (en) Byzantine fault-tolerant method
CN111049696B (en) Method, node and computing device for node management of blockchain system
CN111046110B (en) Method, node and computing device for node management of blockchain system
CN105069152B (en) data processing method and device
EP3908932B1 (en) Topology-driven byzantine fault-tolerant consensus protocol with vote aggregation
US20240097919A1 (en) Consensus trusted cluster changing method, computer device and computer-readable storage medium
CN111555858B (en) Practical Byzantine fault-tolerant consensus method based on block chain type storage
CN114338715A (en) Data synchronization method, block chain system, terminal device and storage medium
CN111582845A (en) Cross-chain transaction method and device of block chain and electronic equipment
CN113965578A (en) Method, device, equipment and storage medium for electing master node in cluster
CN102013997B (en) Backup method and system for dual-computer data in telecom network management system
CN114936253A (en) Block chain consensus method and device, electronic equipment and storage medium
CN115134086A (en) Method and device for dynamic committee secret sharing and updating of asynchronous network
CN110417833B (en) Data processing method and device based on block chain and storage medium
CN114554593A (en) Data processing method and device
CN106951443B (en) Method, equipment and system for synchronizing copies based on distributed system
CN112636987B (en) Cross-chain gateway determination method and system for block chain and terminal equipment
CN116991623B (en) Block chain node exception recovery method and device, electronic equipment and storage medium
CN116232893A (en) Consensus method and device of distributed system, 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
GR01 Patent grant
GR01 Patent grant