CN115473908A - Block chain link point fault recovery method and block chain system - Google Patents
Block chain link point fault recovery method and block chain system Download PDFInfo
- Publication number
- CN115473908A CN115473908A CN202211365055.3A CN202211365055A CN115473908A CN 115473908 A CN115473908 A CN 115473908A CN 202211365055 A CN202211365055 A CN 202211365055A CN 115473908 A CN115473908 A CN 115473908A
- Authority
- CN
- China
- Prior art keywords
- node
- block
- view
- state
- recovery
- 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
- 238000011084 recovery Methods 0.000 title claims abstract description 57
- 238000000034 method Methods 0.000 title claims abstract description 49
- 230000007246 mechanism Effects 0.000 claims abstract description 20
- 230000004044 response Effects 0.000 claims abstract description 12
- 230000008569 process Effects 0.000 claims description 24
- 230000001960 triggered effect Effects 0.000 description 5
- 230000008859 change Effects 0.000 description 4
- 238000012790 confirmation Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Hardware Redundancy (AREA)
Abstract
The invention provides a fault recovery method for a block chain link point and a block chain system, which relate to the technical field of block chains, and the method comprises the following steps: detecting node states of the block chain nodes, wherein the node states comprise a normal state and a recovery state; if the block chain link point is in a normal state, verifying and voting the generated block by using a Byzantine consensus mechanism, switching the node state from the normal state to a recovery state under the condition that the block chain link point block or the view is found to be backward, and sending a recovery request message; and receiving the fed back recovery response message, and recovering the block chain link points to the latest block and view according to the content carried in the recovery response message. Therefore, by adding a node block lagging discovery mechanism in the consensus, the node block lagging can be discovered in time, node synchronization is actively carried out, the latest block and view are recovered, the transaction request is processed, and the problem of node unavailability caused by node block lagging can be avoided.
Description
Technical Field
The invention belongs to the technical field of block chains, and particularly relates to a block chain link point fault recovery method and a block chain system.
Background
The statements in this section merely provide background information related to the present disclosure and may not necessarily constitute prior art that is already known to a person of ordinary skill in the art.
Block chains, i.e. chains of blocks one after the other. Each block stores certain information, which are connected into a chain according to the time sequence generated by each block, the chain is stored in all servers, and the whole block chain is safe as long as one server in the whole system can work. These servers, referred to as nodes in the blockchain system, provide storage space and computational support for the entire blockchain system. If the information in the block chain is to be modified, more than half of the nodes must be authenticated and the information in all the nodes must be modified, and the nodes are usually held in different hands of different subjects, and it is extremely difficult to tamper with the information in the block chain. Therefore, the information recorded by the block chain is more real and reliable, and the problem that people are not trusted mutually can be solved.
In the actual operation process of the blockchain network, problems of network jitter, disk faults and the like can occur, the execution speed of part of nodes lags behind most of nodes, and if the number of the lagged nodes exceeds the fault tolerance upper limit, the whole blockchain network presents an unavailable state, which is not acceptable in the actual production environment. The conventional block chain network recovery method of the Byzantine consensus mechanism (PBFT) has two types: when the main node has a problem or does not respond after overtime, the main node is triggered to switch the view change (viewchange) flow to the main node, and after the view change is completed, the main node is switched to the next node; at the time of checkpoint (checkpoint), if a node finds that a block falls behind, a recovery process is triggered, and data before a stable checkpoint is pulled from other nodes, and the following problems still exist in such a recovery mechanism:
(1) When the network is unstable, the view change process is easily triggered, and the view change process can be successfully switched only when the network is stable, so that the whole block chain network cannot normally process transactions due to network problem switching failure in the actual execution process;
(2) The triggering of the recovery flow at the check point is passive and can be triggered only by the execution process of the check point, and the check point usually has a certain time interval in an actual environment, so that the backward node cannot normally process the transaction for a long time;
(3) For the laggard nodes, if the checkpoint is found to lag behind the self-stability checkpoint, the laggard nodes can only recover to the latest stability checkpoint, and the laggard consensus information behind the checkpoint cannot be obtained, so that the laggard consensus information cannot really participate in the consensus all the time.
Disclosure of Invention
In order to solve the above problems, the present invention provides a method for recovering a failure of a link node of a block and a system of the link node of the block, which avoid the problem of unavailable nodes caused by node block lag by adding a node block lag discovery mechanism in consensus, discovering node block lag and actively performing node synchronization.
In order to achieve the above object, the present invention mainly includes the following aspects:
in a first aspect, an embodiment of the present invention provides a method for recovering a failure of a block link point, including:
detecting node states of a block chain node, wherein the node states comprise a normal state and a recovery state;
if the block chain link point is in a normal state, verifying and voting the generated block by using a Byzantine consensus mechanism, switching the node state from the normal state to a recovery state under the condition that the block chain link point block or the view is found to be backward, and sending a recovery request message;
and receiving the fed back recovery response message, and recovering the block chain nodes to the latest blocks and views according to the content carried in the recovery response message.
In a possible implementation manner, a target block height of the block chain node is obtained, and if a consensus message that a preset number of block heights are greater than the target block height is received, it is determined that the block of the block chain node lags behind.
And acquiring the target view height of the blockchain node, and if a consensus message that the preset number of view heights are greater than the target view height is received, judging that the view of the blockchain node lags behind.
Further, the method also comprises the following steps: and switching the node state from the normal state to the recovery state when the block of the block chain node is found to be lagged in the execution process of the check point, and sending a recovery request message.
After restoring the blockchain node to the latest block and view, further comprising: and switching the node state to a normal state to process the transaction request.
Further, the node states further include a view switching state; under the condition that the block link point is in a normal state, if the transaction request is not processed due to timeout or the view is found to be behind, the node state is switched from the normal state to a view switching state so as to switch the view.
And if the view switching confirmation message is received, judging that the view of the block chain node is behind.
And under the condition that the block chain node is in the view switching state, performing view switching, and when the view switching is finished, switching the node state from the view switching state to the normal state.
In the view switching process, if the master node in the view does not respond, the master node is reselected to carry out next round of view switching.
In a second aspect, an embodiment of the present invention further provides a blockchain system, which includes a plurality of blockchain nodes, where each blockchain node performs fault recovery by using the method for recovering a fault of a blockchain node according to the first aspect.
The above one or more technical solutions have the following beneficial effects:
(1) The invention provides a fault recovery method for block chain nodes, which is characterized in that a block lagging discovery mechanism of block chain nodes in consensus is added, the node blocks are found to be lagging, node synchronization is actively carried out, the latest blocks and views are recovered, transaction messages are processed in time, and the problem of node unavailability caused by node block lagging is avoided;
(2) By adding a node view lagging discovery mechanism, when the network is unstable, the node can still discover and synchronize the view in time when the node does not receive a transaction message or a view switching message, so that the problem of node unavailability caused by node view lagging is avoided.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, are included to provide a further understanding of the invention, and are incorporated in and constitute a part of this specification, illustrate exemplary embodiments of the invention and together with the description serve to explain the invention and not to limit the invention.
Fig. 1 is a schematic flowchart of a block link point failure recovery method according to an embodiment of the present invention.
Detailed Description
The invention is further described with reference to the following figures and examples.
It is to be understood that the following detailed description is exemplary and is intended to provide further explanation of the invention as claimed. 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 invention belongs.
It is noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of exemplary embodiments according to the invention. As used herein, the singular forms "a", "an", and "the" are intended to include the plural forms as well, and it should be understood that when the terms "comprises" and/or "comprising" are used in this specification, they specify the presence of stated features, steps, operations, devices, components, and/or combinations thereof, unless the context clearly indicates otherwise.
Example one
Referring to fig. 1, the present embodiment provides a method for recovering a failure of a block link point, which includes the following steps:
s101: detecting node states of a block chain node, wherein the node states comprise a normal state and a recovery state;
s102: if the block link point is in a normal state, verifying and voting the generated block by using a Byzantine consensus mechanism, switching the node state from the normal state to a recovery state under the condition that the block link point block or the view is found to be backward, and sending a recovery request message;
s103: and receiving the fed back recovery response message, and recovering the block chain nodes to the latest blocks and views according to the content carried in the recovery response message.
The consensus mechanism is how to achieve consensus among all blockchain nodes to identify the validity of a record, and is a means for identification and a means for preventing tampering. The block chain provides a plurality of different consensus mechanisms, is suitable for different application scenes, and balances efficiency and safety. The PBFT (physical Byzantine Fault permission) is a consistency algorithm based on message passing, and the algorithm achieves consistency through three stages. The PBFT consensus is high in efficiency, can meet the requirements of commercial real-time processing and high-frequency trading, and a block chain system based on the PBFT consensus is widely applied to the field of commercialization, and application groups mainly comprise banks, insurance, securities, business associations, enterprise groups and the like.
The existing PBFT Byzantine consensus mechanism does not realize the active recovery function, the execution speed of part of nodes lags behind most of nodes, and if the number of the lagged nodes exceeds the fault-tolerant upper limit, the whole block chain network can present an unavailable state.
Based on this, the embodiment of the present invention provides an active recovery mechanism for a block link point, where the recovery mechanism can be actively triggered to quickly recover the synchronous data of the laggard nodes to a normal state, so as to normally participate in subsequent consensus, thereby ensuring stable and normal operation of the whole block link network. In this embodiment, the block chain nodes are divided into different node states, where the node states include a normal state and a recovery state, the block chain nodes in the normal state can process any message, and the block chain nodes in the recovery state only process the recovery message.
The block chain node is started to default to a normal state, when the block chain node is in the normal state, the generated block is verified and voted by using a Byzantine consensus mechanism, and when the block chain node is found to be out of date, the node state is switched to a recovery state, and a recovery request message is sent; and after receiving the recovery response message, recovering the block chain nodes to the latest blocks and views by comparing the content of the recovery response message. Therefore, by adding a block backward discovery mechanism of the block chain node in the consensus, discovering that the block of the node is backward, actively synchronizing the node, recovering to the latest block and view, and timely processing transaction messages, the problem of node unavailability caused by backward block of the node is avoided.
As an alternative, a block link point block is found to be behind when:
(1) And acquiring the target block height of the block chain nodes, and if a consensus message that the block heights of a preset number of blocks are greater than the target block height is received, judging that the blocks of the block chain nodes fall behind.
In practical application, the total number of block link points is 3f +1, f is the number of Byzantine error nodes, each block link point stores a block height of the node, the consensus message includes the block height of the message source node, the block link receives 2f +1 consensus messages, and if the block height is greater than the block height of the node, the block of the block link node falls behind. For example, the block height of the node 0 is 1, the block height of the node 0 receiving the node 1 consensus message is 2, and if the node 0 receives 2f +1 block heights is 2, it means that the block of the node 0 is behind.
(2) And acquiring the target view height of the blockchain node, and if a consensus message that the preset number of view heights are greater than the target view height is received, judging that the view of the blockchain node lags behind.
In practical application, each node stores a view height, the consensus message contains the view height of the message source node, and the node receives 2f +1 consensus messages, wherein the view is larger than the view of the node, and the view of the node of the block chain is determined to be behind. For example, the view height of the node 0 is 1, the view height of the node 0 receiving the 1-node consensus message is 2, and if the node 0 receiving 2f +1 view heights are all 2, it indicates that the view of the node 0 is behind.
(3) And switching the node state into a recovery state when the block of the block chain node is found to be lagged in the execution process of the check point, and sending a recovery request message.
After restoring the blockchain node to the latest block and view, switching the node state to a normal state to process the transaction request.
As an optional implementation, the node states further include a view switching state; and under the condition that the block link point is in a normal state, if the transaction request is not processed due to timeout or the view is found to be behind, switching the node state from the normal state to a view switching state so as to switch the view.
Optionally, if 2f +1 view switching confirmation messages are received, it is determined that the view of the block chain node is behind. And under the condition that the block chain node is in the view switching state, performing view switching, and when the view switching is finished, switching the node state from the view switching state to the normal state. And in the view switching process, if the master node in the view does not respond, the master node is reselected to carry out the next view switching.
In a specific implementation, the block chain node states are first classified into the following three categories:
(1) Ready state: the Reay state is a normal state and can process any message;
(2) Viewchange status: the Viewchange state is that the node enters a view switching state and does not process the consensus information;
(3) Catch up status: the catcher state is that the node enters the recovery state and only the recovery message is processed.
Further, the node state switching mechanism is as follows:
(1) The block chain node is started and defaults to a Ready state;
(2) When the blockchain node is in the Ready state, the node is switched to the Viewchange state when the following conditions occur:
a) Transaction timeout is not processed;
b) Finding that the current view is behind in the view message processing process, the node receives 2f +1 view switching confirmation messages;
(3) When the blockchain node is in a Viewchange state, the node is switched to a Reay state when the following conditions occur:
a) The view switching is completed;
b) View switch timeout;
(4) When the block chain node is in a Viewchange state, if the master node in the view responds, the master node is reselected to switch the view of the next round;
(5) When the blockchain node is in a Ready state, the node is switched to a catch up state and sends a recovery request message to other nodes when the following conditions occur:
a) Finding that the node block lags behind in the execution process of the check point;
b) Finding that the block of the node is behind in real time in the consensus process, and receiving 2f +1 consensus messages by the node, wherein the block height is greater than the block height of the node;
c) In the consensus process, the node views are found to be behind in real time, and the nodes receive 2f +1 consensus messages, wherein the views are larger than the node views;
(6) When the blockchain node is in a cache state, the node is switched to a real state when the following conditions occur:
a) After receiving the recovery response message, the nodes compare the contents of the response message, and if the 2f +1 node confirms the contents of the block, the block is recovered, so that the latest block and view are recovered;
b) The node resumes timeout.
By adding a node view lagging discovery mechanism, when the network is unstable, the node can still discover and synchronize views in time when the node does not receive a transaction message or does not receive a combined view switching message, so that the problem of node unavailability caused by node view lagging is avoided; and a node view lagging discovery mechanism is also added, when the network is unstable, the node can still discover and synchronize the view in time when not receiving the transaction message or the view switching message, and the problem of node unavailability caused by node view lagging is avoided.
Example two
The embodiment of the invention also provides a block chain system which comprises a plurality of block chain nodes, wherein each block chain node adopts the block chain node fault recovery method to recover the fault.
The detailed description of the embodiment can be found in the foregoing embodiment of the block link point fault recovery method, and is not repeated herein.
The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention, and various modifications and changes may be made by those skilled in the art. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.
Claims (10)
1. A method for recovering from a failure of a block link point, comprising:
detecting node states of a block chain node, wherein the node states comprise a normal state and a recovery state;
if the block link point is in a normal state, verifying and voting the generated block by using a Byzantine consensus mechanism, switching the node state from the normal state to a recovery state under the condition that the block link point block or the view is found to be backward, and sending a recovery request message;
and receiving the fed back recovery response message, and recovering the block chain nodes to the latest blocks and views according to the content carried in the recovery response message.
2. The method of claim 1, wherein a target block height of the blockchain node is obtained, and if a predetermined number of consensus messages are received that the block heights are greater than the target block height, it is determined that the block of the blockchain node is behind.
3. The method according to claim 1, wherein a target view height of the blockchain node is obtained, and if a predetermined number of consensus messages having view heights greater than the target view height are received, it is determined that the view of the blockchain node is behind.
4. A block link point failure recovery method as claimed in claim 1, further comprising: and switching the node state from the normal state to the recovery state when finding out that the blocks of the block chain node lag behind in the execution process of the check point, and sending a recovery request message.
5. A block-link-point fault recovery method as claimed in claim 1, further comprising, after recovering the block-link node to the latest block and view: and switching the node state to a normal state to process the transaction request.
6. A block link point failure recovery method as claimed in claim 1 wherein the node states further comprise a view switch state; and under the condition that the block link point is in a normal state, if the transaction request is not processed due to timeout or the view is found to be behind, switching the node state from the normal state to a view switching state so as to switch the view.
7. The method of claim 6, wherein if a view switch acknowledgement message is received, determining that the view of the blockchain node is behind.
8. A block link point failure recovery method according to claim 6, wherein view switching is performed with the block link node in the view switching state, and the node state is switched from the view switching state to the normal state when the view switching is completed.
9. The method of claim 6, wherein during the view switching process, if the master node in the view does not respond, the master node is reselected for the next view switching.
10. A blockchain system comprising a plurality of blockchain nodes, wherein each blockchain node recovers from a failure using the method of recovering from a blockchain link point failure according to any one of claims 1 to 9.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211365055.3A CN115473908B (en) | 2022-11-03 | 2022-11-03 | Block chain link point fault recovery method and block chain system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211365055.3A CN115473908B (en) | 2022-11-03 | 2022-11-03 | Block chain link point fault recovery method and block chain system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115473908A true CN115473908A (en) | 2022-12-13 |
| CN115473908B CN115473908B (en) | 2023-04-28 |
Family
ID=84336383
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211365055.3A Active CN115473908B (en) | 2022-11-03 | 2022-11-03 | Block chain link point fault recovery method and block chain system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115473908B (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115952237A (en) * | 2023-01-28 | 2023-04-11 | 北京星途探索科技有限公司 | Multi-terminal data fusion system |
| CN116991623A (en) * | 2023-08-30 | 2023-11-03 | 杭州趣链科技有限公司 | Block chain node exception recovery method and device, electronic equipment and storage medium |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107423152A (en) * | 2017-04-24 | 2017-12-01 | 杭州趣链科技有限公司 | A kind of block chain common recognition node automatic recovery method |
| US20190251199A1 (en) * | 2018-02-14 | 2019-08-15 | Ivan Klianev | Transactions Across Blockchain Networks |
| CN110169015A (en) * | 2018-12-13 | 2019-08-23 | 阿里巴巴集团控股有限公司 | Reach common understanding between network node in a distributed system |
| CN110178340A (en) * | 2018-12-13 | 2019-08-27 | 阿里巴巴集团控股有限公司 | The recovery processing of network node is carried out in a distributed system |
| US20200167367A1 (en) * | 2019-07-31 | 2020-05-28 | Alibaba Group Holding Limited | Block chain state data synchronization method, apparatus, and electronic device |
| CN111612455A (en) * | 2020-04-21 | 2020-09-01 | 国网江苏省电力有限公司电力科学研究院 | Power consumption information protection-oriented Byzantine fault-tolerant alliance chain consensus method, system and storage medium |
| WO2021032138A1 (en) * | 2019-08-20 | 2021-02-25 | 深圳前海微众银行股份有限公司 | Consensus method and device based on blockchain system, and system |
| CN112800129A (en) * | 2020-12-31 | 2021-05-14 | 杭州趣链科技有限公司 | Block state updating method, device and system and electronic equipment |
| CN113783947A (en) * | 2021-08-26 | 2021-12-10 | 浙商银行股份有限公司 | Adaptive block link point fault tolerance improving method, equipment and storage medium |
| CN114422526A (en) * | 2021-12-31 | 2022-04-29 | 支付宝(杭州)信息技术有限公司 | Block synchronization method and device, electronic equipment and storage medium |
-
2022
- 2022-11-03 CN CN202211365055.3A patent/CN115473908B/en active Active
Patent Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107423152A (en) * | 2017-04-24 | 2017-12-01 | 杭州趣链科技有限公司 | A kind of block chain common recognition node automatic recovery method |
| US20190251199A1 (en) * | 2018-02-14 | 2019-08-15 | Ivan Klianev | Transactions Across Blockchain Networks |
| CN110169015A (en) * | 2018-12-13 | 2019-08-23 | 阿里巴巴集团控股有限公司 | Reach common understanding between network node in a distributed system |
| CN110178340A (en) * | 2018-12-13 | 2019-08-27 | 阿里巴巴集团控股有限公司 | The recovery processing of network node is carried out in a distributed system |
| US20200167367A1 (en) * | 2019-07-31 | 2020-05-28 | Alibaba Group Holding Limited | Block chain state data synchronization method, apparatus, and electronic device |
| WO2021032138A1 (en) * | 2019-08-20 | 2021-02-25 | 深圳前海微众银行股份有限公司 | Consensus method and device based on blockchain system, and system |
| CN111612455A (en) * | 2020-04-21 | 2020-09-01 | 国网江苏省电力有限公司电力科学研究院 | Power consumption information protection-oriented Byzantine fault-tolerant alliance chain consensus method, system and storage medium |
| CN112800129A (en) * | 2020-12-31 | 2021-05-14 | 杭州趣链科技有限公司 | Block state updating method, device and system and electronic equipment |
| CN113783947A (en) * | 2021-08-26 | 2021-12-10 | 浙商银行股份有限公司 | Adaptive block link point fault tolerance improving method, equipment and storage medium |
| CN114422526A (en) * | 2021-12-31 | 2022-04-29 | 支付宝(杭州)信息技术有限公司 | Block synchronization method and device, electronic equipment and storage medium |
Non-Patent Citations (2)
| Title |
|---|
| 蔡亮等: "基于双层协同的联盟区块链隐私数据保护方法", 《软件学报》 * |
| 邓铭巍等: "几种典型区块链共识机制的安全性分析", 《计算机与现代化》 * |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115952237A (en) * | 2023-01-28 | 2023-04-11 | 北京星途探索科技有限公司 | Multi-terminal data fusion system |
| CN115952237B (en) * | 2023-01-28 | 2023-06-09 | 北京星途探索科技有限公司 | Multi-terminal data fusion system |
| CN116991623A (en) * | 2023-08-30 | 2023-11-03 | 杭州趣链科技有限公司 | Block chain node exception recovery method and device, electronic equipment and storage medium |
| CN116991623B (en) * | 2023-08-30 | 2024-01-02 | 杭州趣链科技有限公司 | Block chain node exception recovery method and device, electronic equipment and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115473908B (en) | 2023-04-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| AU2019203865B2 (en) | Consensus system downtime recovery | |
| AU2019203864B2 (en) | Consensus system downtime recovery | |
| AU2019203862B2 (en) | System and method for ending view change protocol | |
| US11200123B2 (en) | Consensus process recovery method and related node | |
| US12045491B2 (en) | Resynchronization of individual volumes of a consistency group (CG) within a cross-site storage solution while maintaining synchronization of other volumes of the CG | |
| CN115473908A (en) | Block chain link point fault recovery method and block chain system | |
| CN106850260A (en) | A kind of dispositions method and device of virtual resources management platform | |
| CN106254094A (en) | A kind of method of data synchronization and system | |
| CN112506702B (en) | Disaster recovery method, device, equipment and storage medium for data center | |
| CN109117310A (en) | Realize disaster tolerance system, the method and device of data backup | |
| US7730029B2 (en) | System and method of fault tolerant reconciliation for control card redundancy | |
| CN112422341B (en) | Fault detection method of block chain network and related equipment | |
| US8527454B2 (en) | Data replication using a shared resource | |
| CN113965578A (en) | Method, device, equipment and storage medium for electing master node in cluster | |
| CN105988894A (en) | Disaster tolerance technique of active-active mode | |
| CN102438042B (en) | Dynamic parameter synchronizing method and system of multipoint access device | |
| CN110460484A (en) | A kind of single node exception active restoration methods based on PBFT algorithm improvement | |
| CN111555858B (en) | Practical Byzantine fault-tolerant consensus method based on block chain type storage | |
| CN115396296A (en) | Service processing method and device, electronic equipment and computer readable storage medium | |
| CN111404737B (en) | Disaster recovery processing method and related device | |
| Rong et al. | ERBFT: efficient and robust byzantine fault tolerance | |
| CN113630445B (en) | Data storage method and device based on block chain network | |
| US7051065B2 (en) | Method and system for performing fault-tolerant online validation of service requests | |
| KR102294048B1 (en) | Method and system for replicating blockchain application service | |
| CN114301763A (en) | Distributed cluster fault processing method and system, electronic device 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 | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20240930 Address after: 250000, 19th Floor, Building 4, Block A7, Hanyu Financial and Business Center, No. 7000 Jingshi Road, Jinan Area, China (Shandong) Pilot Free Trade Zone, Jinan City, Shandong Province Patentee after: Shandong Huaqing Cryptography Technology Co.,Ltd. Country or region after: China Address before: Room 1901-1, Building 4, Hanyu Financial and Business Center, No. 7000, Jingshi Road, High tech Zone, Jinan, Shandong 250000 Patentee before: Shandong blockchain Research Institute Country or region before: China |
|
| TR01 | Transfer of patent right |