CN109688012B - Method for hot standby switching of alliance link nodes - Google Patents
Method for hot standby switching of alliance link nodes Download PDFInfo
- Publication number
- CN109688012B CN109688012B CN201811639905.8A CN201811639905A CN109688012B CN 109688012 B CN109688012 B CN 109688012B CN 201811639905 A CN201811639905 A CN 201811639905A CN 109688012 B CN109688012 B CN 109688012B
- Authority
- CN
- China
- Prior art keywords
- node
- candidate
- nodes
- consensus
- connection
- 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
Links
Images
Classifications
-
- 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/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0668—Management of faults, events, alarms or notifications using network fault recovery by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure
-
- 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/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
- H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
-
- 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/08—Configuration management of networks or network elements
- H04L41/0889—Techniques to speed-up the configuration process
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
- H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
Abstract
The invention discloses a method for hot standby switching of alliance link nodes. The steps of the node hot standby switching are as follows: establishing connection between the candidate node and the consensus node; the consensus node sends the network configuration and the consensus routing table information thereof to the candidate node in real time for backup; the candidate node carries out fault detection on the consensus node and determines whether to trigger the process of node upgrading and replacing; and upgrading the candidate nodes to be common-identification nodes on line, connecting the common-identification nodes of the block chain network according to the backup network configuration, and initializing the common-identification state of the candidate nodes to the state when the common-identification nodes are down so as to finish replacement. In a block chain network of a alliance formed by a plurality of organizations, the method automatically finishes online upgrade of candidate nodes into the common nodes on the premise of not introducing manual operation when the common nodes of the organizations are abnormally down, and avoids single-point failure of the common nodes in the organizations on the basis of not influencing the common efficiency of the block chain network.
Description
Technical Field
The invention relates to a decentralized block chain CA certificate system, in particular to a method for hot standby switching of alliance chain nodes.
Background
With the popularization of the block chain technology, people gradually realize that the block chain technology can bring the advantages of safety, reliability, flow simplification, cost saving, trust enhancement and the like to the traditional industry, can make up for the defects of low efficiency, high cost, large operation risk and the like caused by multi-party cooperation, and is popular with enterprises needing multi-party peer-to-peer cooperation. Since multi-party cooperation often requires strict identity authentication and special admission and discharge authorization mechanisms, the federation blockchains also become their main choice.
In the block chain of the alliance, in order to prevent the business application transaction developed by the enterprise from being influenced by the Byzantine behavior of other enterprise nodes, the business application transaction developed by the enterprise is often sent to the node deployed by the enterprise for processing. At present, in a block chain of an alliance, if a node of a certain organization goes down abnormally or a server where the node is located goes wrong in hardware, although a block chain network with certain fault tolerance is not affected by the down of the node, for an enterprise, the service of the node needs to be recovered at the fastest speed. The recovery methods commonly adopted at present include the following two methods:
the nodes are restarted by relevant configuration before the operation nodes under the computer room operation and maintenance personnel online start, and if the data loss is caused by fatal errors of storage equipment, new node synchronous block chain network data needs to be involved.
And a plurality of consensus nodes are used for backing up data and services, and when one consensus node is abnormal, the upper layer application senses the service node to be switched later.
Both of the above methods have certain disadvantages, and the first method may cause the service of the node to be unrecoverable for a long time due to the introduction of manual operation, which is extremely disadvantageous for the application of intelligent contracts communicated with the node. In addition, if the data volume of the whole network is extremely large, the time spent for node data synchronization is difficult to estimate, and the node is in a temporary unavailable state. Although the second method has the advantage of fast recovery, in order to ensure the fairness of consensus voting among enterprises, all participating enterprises must deploy the same number of consensus nodes, and the increase of the number of consensus nodes will have a great influence on the consensus efficiency.
Disclosure of Invention
The invention aims to provide a method for hot-standby switching of union link nodes, which aims to overcome the defects of the prior art, and enables non-verification nodes to be upgraded into consensus nodes on line, completes authority upgrading and replacement, and realizes that the time spent on the on-line upgrading is second grade on the premise of not influencing the consensus efficiency.
The purpose of the invention is realized by the following technical scheme: a method for hot standby switching of alliance link nodes comprises the following steps:
(1) and (3) candidate node network configuration: the candidate node is essentially a special accounting node and holds ECert and RCert certificates issued by an offline third-party certificate authority; before the candidate node is started, the candidate node needs to specify which consensus node is the candidate node in the network configuration file;
(2) the candidate node and the consensus node establish connection: the candidate node initiates a connection establishment request to the consensus node, after the physical connection establishment is completed, identity authentication of both parties is started, and if the identity authentication fails, the connection establishment fails; if the identity authentication is passed and the consensus node confirms that the opposite end is the candidate node, performing Backup marking on the opposite end and putting the opposite end into a candidate list;
(3) backup is carried out on the network configuration of the consensus node by the candidate node: after the connection between the candidate node and the consensus node is established, the consensus node informs the candidate node to update and backup every time the network connection information is changed; the data backed up includes: address connection information of other consensus nodes in the block chain network, address connection information of accounting nodes connected with the consensus nodes, and a candidate list of the consensus nodes. Wherein the accounting nodes comprise candidate nodes because the candidate nodes are special accounting nodes;
(4) the candidate node carries out fault detection on the consensus node: the candidate node judges whether the consensus node is alive or not by adopting a keepalive + overtime mechanism so as to determine whether to trigger node upgrading replacement operation or not; determining the priority of upgrading replacement according to the positions of the candidate nodes in the candidate list, wherein the later candidate nodes can trigger upgrading replacement only when the candidate nodes arranged in the front fail;
(5) the candidate node disconnects the existing network connection: when the abnormal downtime of the common node is determined through heartbeat, fault detection and the like, the automatic upgrading replacement operation of the candidate node is triggered; this is the first step of the candidate node for upgrade replacement;
(6) and the candidate node updates the online network configuration file: reading the backup network configuration file by the candidate node, and updating the online network configuration information to be used as the basis for establishing the network connection in the step (8);
(7) registering and starting a consensus service: after the consensus service is started, the node has the function of consensus voting, but connection with other nodes of the consensus network is not established;
(8) the candidate nodes establish consensus network connection: and (3) the candidate nodes update the identity information of the candidate nodes, and initiate connection establishment requests to other nodes according to the latest network configuration information, wherein the nodes comprise other consensus nodes and accounting nodes which are originally connected with the consensus nodes, and the connection establishment process is the same as the step (2).
Further, in the step (1), it is determined that the node has different rights according to different certificates, and holding an ECert indicates that the node has a right to access the block chain network, and holding an RCert indicates that the node has a right to participate in consensus voting; the consensus node holds ECert and RCert; the accounting node holds ECert; the candidate node holds ECert and RCert, but RCert only exists as a backup, and the candidate node has no effect before the node carries out identity upgrading; in addition, one candidate node can only designate one consensus node to acquire related network connection information;
further, in the step (2), one consensus node may establish a connection with a plurality of candidate nodes.
Further, in the step (3), the candidate node persists the received network configuration information in the backup network configuration file, which does not affect the current online network configuration of the candidate node, only when the candidate node is triggered to perform upgrade replacement, the online network configuration file is replaced by the backup network configuration file, and after the node completes the upgrade replacement, the backup network configuration file is deleted.
Further, in the step (4), keepalive is used for heartbeat detection between the candidate node and the consensus node, and judging whether the consensus node is alive; the timeout mechanism is mainly used for judging whether the currently hit candidate node for upgrading and replacing fails, if the candidate node fails, the candidate list also needs to be updated, and the failed candidate node is removed from the candidate list.
Further, in the step (5), the candidate node is essentially a special accounting node, which may establish a connection with one or more consensus nodes, and thus needs to disconnect the candidate node from other consensus nodes before the online upgrade is performed.
Further, in the step (8), since the process of establishing the connection requires identity authentication, the candidate node first needs to update its own identity information before starting establishing the connection, and these identity information need to be in one-to-one correspondence with the designated consensus node. After the identity information is updated, the candidate node initiates connection to other nodes according to the latest network configuration.
The invention has the beneficial effects that: the method is applied to the blockchain network under the alliance chain background, ensures that the common identification nodes in the organization are automatically switched in hot standby mode on the premise of not influencing the common identification efficiency of the blockchain network and not introducing manual operation, and avoids the single point fault of the common identification nodes in the organization. For a traditional block chain, on one hand, along with the operation of the block chain, the data volume of the block chain is larger and larger, and when a consensus node has a fatal fault to cause data loss, the time spent for starting a new node to synchronize the data of the whole network cannot be estimated, which may cause that the node cannot process transactions in a short time. On the other hand, when the number of nodes reaches a certain number, the consensus efficiency is reduced in the BFT algorithm, and obviously, the method of adding consensus nodes is not an optimal method for solving single-point failures of nodes. The hot standby switching method of the alliance link nodes solves the problem, and the time consumed by fault recovery of the consensus nodes is only second.
Drawings
FIG. 1 is a flow diagram of a node establishing a connection;
FIG. 2 is a diagram of a consensus node connection state;
FIG. 3 is a connection state diagram after candidate node upgrade replacement;
Detailed Description
The present invention will be described in detail below with reference to the drawings and specific embodiments, and the objects and effects of the present invention will become more apparent.
A method for hot standby switching of alliance link nodes comprises the following steps:
(1) and (3) candidate node network configuration: the candidate node is essentially a special accounting node and holds ECert and RCert certificates issued by an offline third-party certificate authority; before the candidate node is started, the candidate node needs to specify which consensus node is the candidate node in the network configuration file;
(2) the candidate node and the consensus node establish connection: the candidate node initiates a connection establishment request to the consensus node, after the physical connection establishment is completed, identity authentication of both parties is started, and if the identity authentication fails, the connection establishment fails; if the identity authentication is passed and the consensus node confirms that the opposite end is the candidate node, performing Backup marking on the opposite end and putting the opposite end into a candidate list;
(3) backup is carried out on the network configuration of the consensus node by the candidate node: after the connection between the candidate node and the consensus node is established, the consensus node informs the candidate node to update and backup every time the network connection information is changed; the data backed up includes: address connection information of other consensus nodes in the block chain network, address connection information of accounting nodes connected with the consensus nodes, and a candidate list of the consensus nodes. Wherein the accounting nodes comprise candidate nodes because the candidate nodes are special accounting nodes;
(4) the candidate node carries out fault detection on the consensus node: the candidate node judges whether the consensus node is alive or not by adopting a keepalive + overtime mechanism so as to determine whether to trigger node upgrading replacement operation or not; determining the priority of upgrading replacement according to the positions of the candidate nodes in the candidate list, wherein the later candidate nodes can trigger upgrading replacement only when the candidate nodes arranged in the front fail;
(5) the candidate node disconnects the existing network connection: when the abnormal downtime of the common node is determined through heartbeat, fault detection and the like, the automatic upgrading replacement operation of the candidate node is triggered; this is the first step of the candidate node for upgrade replacement;
(6) and the candidate node updates the online network configuration file: reading the backup network configuration file by the candidate node, and updating the online network configuration information to be used as the basis for establishing the network connection in the step (8);
(7) registering and starting a consensus service: after the consensus service is started, the node has the function of consensus voting, but connection with other nodes of the consensus network is not established;
(8) the candidate nodes establish consensus network connection: and (3) the candidate nodes update the identity information of the candidate nodes, and initiate connection establishment requests to other nodes according to the latest network configuration information, wherein the nodes comprise other consensus nodes and accounting nodes which are originally connected with the consensus nodes, and the connection establishment process is the same as the step (2).
Further, in the step (1), it is determined that the node has different rights according to different certificates, and holding an ECert indicates that the node has a right to access the block chain network, and holding an RCert indicates that the node has a right to participate in consensus voting; the consensus node holds ECert and RCert; the accounting node holds ECert; the candidate node holds ECert and RCert, but RCert only exists as a backup, and the candidate node has no effect before the node carries out identity upgrading; in addition, one candidate node can only designate one consensus node to acquire related network connection information;
further, in the step (2), one consensus node may establish a connection with a plurality of candidate nodes. As shown in fig. 1, for the node 1 requesting to establish a connection, first, a request for establishing a connection is initiated to the node 2, and after the node 2 responds to the connection request, the node 1 and the node 2 establish a transport layer encrypted connection, and may start further identity authentication and key agreement. The node 1 sends its own identity authentication information, such as an ECert, an RCert, and whether it is a CVP, to the node 2. After receiving the message, the node 2 firstly verifies the ECert of the node 1, and if the ECert verification fails, the connection is disconnected; if the ECert passes the verification and the identity authentication information contains RCert, the fact that the opposite end node is a VP node is indicated, the validity of an RCert certificate is verified, if the verification fails, the connection is disconnected, if the verification passes, the two nodes generate a pair of shared keys, and safe encrypted communication can be started; if the ECert passes the verification and the identity authentication information has no RCert, the method indicates that the opposite node is an NVP node, and if the opposite node is a CVP, the opposite node is marked and orderly put into a candidate list, and a pair of shared keys is also generated, so that the secure encrypted communication can be started.
Further, in the step (3), the CVP persists the received network configuration information in the backup network configuration file, which does not affect the current online network configuration of the CVP, and only when the CVP is triggered to perform upgrade replacement, the online network configuration file is replaced by the backup network configuration file, and after the node completes the upgrade replacement, the backup network configuration file is deleted.
Further, in the step (4), keepalive is used for heartbeat detection between the candidate node and the consensus node, and judging whether the consensus node is alive; the timeout mechanism is mainly used for judging whether the currently hit candidate node for upgrading and replacing fails, if the candidate node fails, the candidate list also needs to be updated, and the failed candidate node is removed from the candidate list.
A plurality of fault situations may occur, and we take fig. 2 as an example to illustrate the processing manner of the system in each fault situation. As can be seen from the figure, the VP0 is currently connected with two common NVPs and two CVPs, the VP0 maintains a candidate list in which the information of CVP-1 and CVP-2 is stored in sequence, and the sequence of the candidate list determines who triggers the upgrade when the VP0 is abnormally stopped.
Scene one: VP0 abnormal downtime
After the VP0 is abnormally crashed, the connection between the VP and the NVP-1, the NVP-2, the CVP-1 and the CVP-2 is disconnected. At this time, as can be seen from the candidate list, CVP-1 performs upgrade replacement immediately after finding that VP0 heartbeat is lost for more than a certain time. Although the CVP-2 also finds the exception of VP0 in the process of heartbeat detection, since the CVP-2 is not the head of the candidate list, the upgrade is not triggered, but the CVP-1 is waited to complete the upgrade replacement, and the case that the VP0 and the CVP-1 are abnormally down at the same time will be discussed later.
Scene two: CVP-1 abnormal downtime
VP0 is still working properly in this scenario, so the process of upgrade replacement does not occur. At this point, however, the first bit of the VP0 candidate list has failed because CVP-1 has been down, which is very disadvantageous for VP0 if the failed information is still maintained. Therefore, after VP0 finds that CVP-1 is down, CVP-1 is removed from the candidate list, while the latest network connection information is sent to other CVPs.
Scene three: VP0 and CVP-1 are down at the same time
Since both VP0 and the leading candidate node CVP-1 are down, additional CVPs are needed to upgrade replacement VP 0. A configurable timeout time is provided for a system, when none of the candidate nodes which are not the first candidate nodes detect the existence of a new verification node within the timeout time, the node upgrading replacement process is considered to be overtime, the next candidate node is required to be upgraded and replaced, the hit candidate node updates the candidate list of the hit candidate node before the update and replacement, and the information of the candidate node which is known to fail is deleted.
Under the three scenarios, the network connection state after the candidate node upgrade replacement is shown in fig. 3.
Further, in the step 5), the CVP is essentially an NVP, and it may establish connections with multiple VPs, so that it needs to disconnect from other VP nodes before performing online upgrade.
Further, in the step 8), since the process of establishing the connection needs to perform identity authentication, the CVP first needs to update its own identity information before starting establishing the connection, and these identity information need to be in one-to-one correspondence with VP0, and in the present system, the CVP is mainly hostname information, which ensures that the unique identifier of the node remains unchanged after the node is upgraded and replaced, so that it is as if the VP0 is briefly disconnected and the network connection is replaced for other nodes of the consensus network. After the identity information is updated, the CVP initiates connection to other nodes according to the latest network configuration.
Claims (6)
1. A method for hot standby switching of alliance link nodes is characterized by comprising the following steps:
(1) and (3) candidate node network configuration: the candidate node is essentially a special accounting node and holds ECert and RCert certificates issued by an offline third-party certificate authority; before the candidate node is started, the candidate node needs to specify which consensus node is the candidate node in the network configuration file;
(2) the candidate node and the consensus node establish connection: the candidate node initiates a connection establishment request to the consensus node, after the physical connection establishment is completed, identity authentication of both parties is started, and if the identity authentication fails, the connection establishment fails; if the identity authentication is passed and the consensus node confirms that the opposite end is the candidate node, performing Backup marking on the opposite end and putting the opposite end into a candidate list;
(3) backup is carried out on the network configuration of the consensus node by the candidate node: after the connection between the candidate node and the consensus node is established, the consensus node informs the candidate node to update and backup every time the network connection information is changed; the data backed up includes: address connection information of other consensus nodes in the block chain network, address connection information of accounting nodes connected with the consensus nodes, and a candidate list of the consensus nodes; wherein the accounting node comprises a candidate node;
(4) the candidate node carries out fault detection on the consensus node: the candidate node judges whether the consensus node is alive or not by adopting a keepalive + overtime mechanism so as to determine whether to trigger node upgrading replacement operation or not; determining the priority of upgrading replacement according to the positions of the candidate nodes in the candidate list, wherein only when the candidate nodes arranged in front fail, the candidate nodes behind trigger the upgrading replacement;
(5) the candidate node disconnects the existing network connection: when the common node is determined to be abnormally crashed by a heartbeat and fault detection method, the automatic upgrading replacement operation of the candidate node is triggered; this is the first step of the candidate node for upgrade replacement;
(6) and the candidate node updates the online network configuration file: reading the backup network configuration file by the candidate node, and updating the online network configuration information to be used as the basis for establishing the network connection in the step (8);
(7) registering and starting a consensus service: after the consensus service is started, the node has the function of consensus voting, but connection with other nodes of the consensus network is not established;
(8) the candidate nodes establish consensus network connection: the candidate nodes update the identity information of the candidate nodes, and initiate connection establishment requests to other nodes according to the latest network configuration information, wherein the nodes comprise other consensus nodes and accounting nodes which are originally connected with the consensus nodes, and the connection establishment process is the same as the step (2);
in the step (8), since the process of establishing the connection needs to perform identity authentication, the candidate node first needs to update its own identity information before starting to establish the connection, the identity information needs to be in one-to-one correspondence with the designated consensus node, and the system is mainly hostname information, so that the unique identifier of the node is kept unchanged after the node is upgraded and replaced, and thus, for other nodes of the consensus network, only a certain consensus node is temporarily disconnected, and the network connection is replaced; after the identity information is updated, the candidate node initiates connection to other nodes according to the latest network configuration.
2. The method of claim 1, wherein in step (1), we determine that the nodes have different rights according to the difference of certificates, and hold an ECert to indicate that the nodes have the right to access the blockchain network, and hold an RCert to indicate that the nodes have the right to participate in consensus voting; the consensus node holds ECert and RCert; the accounting node holds ECert; the candidate node holds ECert and RCert, but RCert only exists as a backup, and the candidate node has no effect before the node carries out identity upgrading; in addition, only one consensus node can be designated by one candidate node to acquire the related network connection information.
3. The method of claim 1, wherein in step (2), a consensus node establishes a connection with a plurality of its candidate nodes.
4. The method according to claim 1, wherein in step (3), the candidate node persists the received network configuration information in a backup network configuration file, so that the current online network configuration of the candidate node is not affected, the online network configuration file is replaced by the backup network configuration file only when the candidate node is triggered to perform upgrade replacement, and the backup network configuration file is deleted after the node completes the upgrade replacement.
5. The method according to claim 1, wherein in step (4), keepalive is used to perform heartbeat detection between the candidate node and the consensus node to determine whether the consensus node is alive; the timeout mechanism is mainly used for judging whether the currently hit candidate node for upgrading and replacing fails, if the candidate node fails, the candidate list also needs to be updated, and the failed candidate node is removed from the candidate list.
6. The method of claim 1, wherein in step (5), the candidate node is essentially a special accounting node that may have established a connection with one or more common nodes, thereby requiring disconnection from other common nodes before making an online upgrade.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811639905.8A CN109688012B (en) | 2018-12-29 | 2018-12-29 | Method for hot standby switching of alliance link nodes |
| PCT/CN2019/103671 WO2020134152A1 (en) | 2018-12-29 | 2019-08-30 | Consortium blockchain node hot-standby switching method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811639905.8A CN109688012B (en) | 2018-12-29 | 2018-12-29 | Method for hot standby switching of alliance link nodes |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109688012A CN109688012A (en) | 2019-04-26 |
| CN109688012B true CN109688012B (en) | 2020-07-17 |
Family
ID=66190354
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811639905.8A Active CN109688012B (en) | 2018-12-29 | 2018-12-29 | Method for hot standby switching of alliance link nodes |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN109688012B (en) |
| WO (1) | WO2020134152A1 (en) |
Families Citing this family (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109688012B (en) * | 2018-12-29 | 2020-07-17 | 杭州趣链科技有限公司 | Method for hot standby switching of alliance link nodes |
| CN110221938A (en) * | 2019-05-06 | 2019-09-10 | 深圳壹账通智能科技有限公司 | The method and storage medium of electronic device, block chain common recognition |
| CN110351133B (en) * | 2019-06-28 | 2021-09-17 | 创新先进技术有限公司 | Method and device for main node switching processing in block chain system |
| US10944624B2 (en) | 2019-06-28 | 2021-03-09 | Advanced New Technologies Co., Ltd. | Changing a master node in a blockchain system |
| CN110572287B (en) * | 2019-09-05 | 2022-03-18 | 腾讯科技（深圳）有限公司 | Data disaster tolerance method and device, computer equipment and storage medium |
| CN110430087B (en) * | 2019-09-16 | 2022-04-05 | 上海保险交易所股份有限公司 | Block chain hot upgrade architecture design and implementation |
| CN111104282B (en) * | 2019-11-26 | 2024-01-16 | 众安信息技术服务有限公司 | Node processing method and device based on block chain |
| CN111277645B (en) * | 2020-01-16 | 2023-02-10 | 深圳市迅雷网络技术有限公司 | Hot switching method for main and standby nodes, block chain system, block chain node and medium |
| US11496558B2 (en) | 2020-01-29 | 2022-11-08 | Hewlett Packard Enterprise Development Lp | Peer-to-peer blockchain fabric management mechanism |
| CN111654393B (en) * | 2020-05-20 | 2023-01-06 | 中国工商银行股份有限公司 | Block chain networking method and system |
| CN111767347B (en) * | 2020-07-27 | 2021-09-10 | 腾讯科技（深圳）有限公司 | Switching method and device of consensus algorithm, node equipment and storage medium |
| CN111988188A (en) * | 2020-09-03 | 2020-11-24 | 深圳壹账通智能科技有限公司 | Transaction endorsement method, device and storage medium |
| CN112511337B (en) * | 2020-11-09 | 2023-03-14 | 迅鳐成都科技有限公司 | Block chain consensus network self-recovery method, electronic device, system and storage medium |
| CN112511338A (en) * | 2020-11-09 | 2021-03-16 | 迅鳐成都科技有限公司 | Block chain consensus network dynamic recovery method, electronic device, system and medium |
| CN113472566A (en) * | 2021-06-11 | 2021-10-01 | 北京市大数据中心 | Status monitoring method of union block chain and master node status monitoring system |
| CN113761063B (en) * | 2021-08-26 | 2024-04-16 | 浙商银行股份有限公司 | Non-stop blockchain migration method, equipment and storage medium |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107171829A (en) * | 2017-04-24 | 2017-09-15 | 杭州趣链科技有限公司 | A kind of dynamic node management method for algorithm realization of being known together based on BFT |
| CN107426157A (en) * | 2017-04-21 | 2017-12-01 | 杭州趣链科技有限公司 | A kind of alliance's chain authority control method based on digital certificate and ca authentication system |
| CN107995197A (en) * | 2017-12-04 | 2018-05-04 | 中国电子科技集团公司第三十研究所 | A kind of method for realizing across management domain identity and authority information is shared |
| CN108134706A (en) * | 2018-01-02 | 2018-06-08 | 中国工商银行股份有限公司 | Block chain high-availability system mostly living, computer equipment and method |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2018094297A2 (en) * | 2016-11-19 | 2018-05-24 | COSTANZ, Mario A | System and method for interaction object reconciliation in a public ledger blockchain environment |
| WO2018125989A2 (en) * | 2016-12-30 | 2018-07-05 | Intel Corporation | The internet of things |
| CN109426952B (en) * | 2017-08-22 | 2021-06-01 | 汇链丰(北京)科技有限公司 | Block chain structure |
| CN108667614B (en) * | 2018-04-19 | 2021-02-02 | 上海分布信息科技有限公司 | Byzantine fault-tolerant method and implementation system thereof |
| CN108665271A (en) * | 2018-05-02 | 2018-10-16 | 百度在线网络技术（北京）有限公司 | Block chain data processing method, device, equipment and storage medium |
| CN108769150B (en) * | 2018-05-14 | 2021-11-12 | 百度在线网络技术（北京）有限公司 | Data processing method and device of block chain network, cluster node and storage medium |
| CN109688012B (en) * | 2018-12-29 | 2020-07-17 | 杭州趣链科技有限公司 | Method for hot standby switching of alliance link nodes |
-
2018
- 2018-12-29 CN CN201811639905.8A patent/CN109688012B/en active Active
-
2019
- 2019-08-30 WO PCT/CN2019/103671 patent/WO2020134152A1/en active Application Filing
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107426157A (en) * | 2017-04-21 | 2017-12-01 | 杭州趣链科技有限公司 | A kind of alliance's chain authority control method based on digital certificate and ca authentication system |
| CN107171829A (en) * | 2017-04-24 | 2017-09-15 | 杭州趣链科技有限公司 | A kind of dynamic node management method for algorithm realization of being known together based on BFT |
| CN107995197A (en) * | 2017-12-04 | 2018-05-04 | 中国电子科技集团公司第三十研究所 | A kind of method for realizing across management domain identity and authority information is shared |
| CN108134706A (en) * | 2018-01-02 | 2018-06-08 | 中国工商银行股份有限公司 | Block chain high-availability system mostly living, computer equipment and method |
Non-Patent Citations (1)
| Title |
|---|
| 区块链共识算法的发展现状与展望;袁勇等;《自动化学报》;20181130;第44卷(第11期);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2020134152A1 (en) | 2020-07-02 |
| CN109688012A (en) | 2019-04-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109688012B (en) | Method for hot standby switching of alliance link nodes | |
| CN107040594B (en) | Method and device for allowing block chain node to be admitted based on PBFT | |
| CN101714916A (en) | Method, equipment and system for backing up | |
| US7730029B2 (en) | System and method of fault tolerant reconciliation for control card redundancy | |
| US20120179826A1 (en) | Address Distribution Method, Device and System Thereof | |
| CN108846745B (en) | Block chain transaction processing auxiliary system, block chain data processing system and method | |
| CN115473908B (en) | Block chain link point fault recovery method and block chain system | |
| CN113965578A (en) | Method, device, equipment and storage medium for electing master node in cluster | |
| CN112615914A (en) | Method for transmitting multicast hot standby table entries by using border gateway protocol | |
| CN112507019A (en) | PBFT consensus system and method based on intelligent contracts | |
| CN105323271B (en) | Cloud computing system and processing method and device thereof | |
| US10756975B2 (en) | Multiple site rolling upgrade protocol | |
| CN113630445B (en) | Data storage method and device based on block chain network | |
| CN107911339B (en) | Information maintenance method and device | |
| CN111338848B (en) | Failure application copy processing method and device, computer equipment and storage medium | |
| US7885184B2 (en) | Method and apparatus for re-establishing anonymous data transfers | |
| CN108038782B (en) | Security system for securities trading and security verification method for securities trading | |
| US20230188367A1 (en) | Apparatus and method for synchronizing consensus node information in blockchain network | |
| CN113535464B (en) | Disaster recovery backup method, server, cluster system and storage device | |
| CN112667449B (en) | Cluster management method and device | |
| CN115134220A (en) | Main/standby server switching method and device, computing equipment and storage medium | |
| CN108683637B (en) | Registration method and device for group members | |
| CN115277379B (en) | Distributed lock disaster recovery processing method and device, electronic equipment and storage medium | |
| KR102294048B1 (en) | Method and system for replicating blockchain application service | |
| WO2016165465A1 (en) | Network management method, emergency system 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 |