Blockchain node fault recovery method, device, equipment and storage medium

Abstract

The application discloses a kind of blockchain node fault recovery method, device, equipment and storage medium.It includes obtaining the historical consensus information of blockchain node, according to the historical consensus information, the blockchain node is clustered, obtain multiple node nested clusters, including consensus node for consensus and account book node for storing account book data in the node nested cluster;When detecting blockchain node failure, determine the node nested cluster corresponding to the fault blockchain node;Based on the node nested cluster, the fault recovery is carried out to the fault blockchain node.Due to the account book node of the present application only stores account book data, and the consensus node is only used for blockchain consensus, compared with the existing blockchain node, both node consensus and full amount of account book data are stored, the above-mentioned method of the present application can only recover the fault according to the type of node when the blockchain node fails, without recovering full amount of account book data and consensus information, improve the efficiency of node fault recovery.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method, apparatus, device, and storage medium for blockchain node fault recovery. Background Technology

[0002] Blockchain is a distributed database that links data blocks in an orderly manner and uses cryptography to ensure their immutability and tamper-proof nature. It enables all data within the system to be publicly transparent, immutable, tamper-proof, and traceable without the need for third-party endorsement.

[0003] One of the core characteristics of blockchain is decentralization. System nodes are equal in status, each storing the full ledger data and possessing identical roles and permissions. This organizational structure, combined with cryptographic algorithms and consensus mechanisms, enables nodes to complete trusted peer-to-peer transactions without a central third-party institution. However, in actual operation, blockchain systems can encounter problems such as insufficient node computing resources and disk corruption, leading to faulty nodes failing to generate blocks. If the number of faulty nodes exceeds the fault tolerance limit, the entire system will malfunction. Therefore, fault tolerance and recovery efficiency is a crucial capability of blockchain. Current mainstream blockchain systems employ the following fault tolerance method: each node stores the full ledger information. When a node malfunctions and its data is corrupted, the entire ledger needs to be synchronized during data recovery. Due to the massive amount of ledger data, storing the entire ledger on each node wastes storage space, and the need to synchronize the entire ledger data during node recovery results in low fault tolerance and recovery efficiency. Therefore, improving the fault tolerance and recovery efficiency of blockchain nodes has become a pressing technical problem. Summary of the Invention

[0004] The main objective of this invention is to provide a method, apparatus, device, and storage medium for blockchain node failure recovery, aiming to solve the technical problem that the need to synchronize the full ledger data and consensus information during blockchain node failure recovery in the prior art results in low node failure recovery efficiency.

[0005] To achieve the above objectives, the present invention provides a blockchain node failure recovery method, the method comprising the following steps:

[0006] Obtain historical consensus information of blockchain nodes, and cluster the blockchain nodes according to the historical consensus information to obtain multiple nested node clusters. The nested node clusters include consensus nodes used for consensus and ledger nodes storing ledger data.

[0007] When a blockchain node failure is detected, the node nesting cluster corresponding to the failed blockchain node is determined;

[0008] The faulty blockchain node is recovered based on the nested node cluster.

[0009] Optionally, the step of fault recovery of the faulty blockchain node based on the node nesting cluster includes:

[0010] Determine the node type of the faulty blockchain node;

[0011] The faulty blockchain node is recovered based on the node type and the node nesting cluster.

[0012] Optionally, the step of fault recovery of the faulty blockchain node based on the node type and the node nesting cluster includes:

[0013] When the node type is a first type node, the consensus node in the nested cluster of nodes is determined;

[0014] Determine the consensus pointer based on the consensus node;

[0015] The faulty blockchain node is recovered based on the consensus pointer.

[0016] When the node type is a second type node, the ledger node in the nested cluster of nodes is determined;

[0017] The partitioned ledger data is determined based on the ledger nodes;

[0018] The faulty blockchain node is recovered based on the partitioned ledger data.

[0019] Optionally, the step of obtaining historical consensus information of blockchain nodes and clustering the blockchain nodes based on the historical consensus information to obtain multiple nested clusters of nodes includes:

[0020] Obtain historical consensus information from blockchain nodes;

[0021] The consensus feature vector of the blockchain node is determined based on the historical consensus information;

[0022] The centroid of the nested forest in the blockchain is determined based on the consensus feature vector.

[0023] Based on the centroid of the nested forest of the blockchain, the blockchain nodes are clustered to obtain multiple nested node clusters.

[0024] Optionally, the step of clustering the blockchain nodes based on the centroids of the nested forest to obtain multiple nested clusters of nodes includes:

[0025] Start traversing from the second blockchain node to determine the target blockchain node to be traversed;

[0026] Obtain the currently generated nested node clusters, and determine the centroid and diameter of the nested node clusters;

[0027] The target blockchain nodes are clustered based on the centroid and diameter of the nested clusters to obtain multiple nested clusters.

[0028] Optionally, the step of clustering the target blockchain nodes based on the centroid of the nested cluster and the diameter of the nested cluster to obtain multiple nested clusters includes:

[0029] Determine the Euclidean distance from the target blockchain node to the centroid of the nested cluster of the node;

[0030] Determine the target distance based on the Euclidean distance;

[0031] Determine the diameter of the nested cluster of nodes corresponding to the target distance;

[0032] The target blockchain nodes are clustered based on the target distance and the diameter of the node nesting cluster to obtain multiple node nesting clusters.

[0033] Optionally, after the steps of obtaining historical consensus information of blockchain nodes and clustering the blockchain nodes according to the historical consensus information to obtain multiple nested clusters of nodes, the method further includes:

[0034] Determine the number of nested clusters of the node nested clusters and the full ledger data;

[0035] The full ledger data is divided based on the number of nested clusters to obtain partitioned ledger data;

[0036] Determine the block identifier corresponding to the partitioned ledger data and the nested cluster identifier corresponding to the node nested cluster;

[0037] The hash ring is determined based on the nested cluster identifier and the block identifier;

[0038] The storage location of the partitioned ledger data is determined based on the hash ring.

[0039] The full ledger data is stored in partitions based on the storage location and the ledger nodes in the nested node cluster.

[0040] Furthermore, to achieve the above objectives, the present invention also provides a blockchain node fault recovery device, the device comprising:

[0041] The clustering module is used to obtain historical consensus information of blockchain nodes, and to cluster the blockchain nodes according to the historical consensus information to obtain multiple nested clusters of nodes.

[0042] The detection module is used to determine the nested cluster of nodes corresponding to the faulty blockchain node when a fault is detected.

[0043] The fault recovery module is used to perform fault recovery on the faulty blockchain node based on the node nesting cluster.

[0044] Furthermore, to achieve the above objectives, the present invention also proposes a blockchain node fault recovery device, the device comprising: a memory, a processor, and a blockchain node fault recovery program stored in the memory and executable on the processor, the blockchain node fault recovery program being configured to implement the steps of the blockchain node fault recovery method described above.

[0045] In addition, to achieve the above objectives, the present invention also proposes a storage medium storing a blockchain node fault recovery program, which, when executed by a processor, implements the steps of the blockchain node fault recovery method described above.

[0046] This invention acquires historical consensus information of blockchain nodes, clusters the blockchain nodes based on this information to obtain multiple nested node clusters, each cluster including consensus nodes for consensus and ledger nodes for storing ledger data. When a blockchain node failure is detected, the nested node cluster corresponding to the failed blockchain node is determined. Fault recovery of the failed blockchain node is then performed based on these nested clusters. Because the ledger nodes of this invention only store ledger data, and the consensus nodes are only used for blockchain consensus, compared to existing blockchain nodes that require both node consensus and storage of all ledger data, the above method of this invention can perform fault recovery on a blockchain node only based on its type, without needing to recover all ledger data and consensus information, thus improving node fault recovery efficiency. Attached Figure Description

[0047] Figure 1 This is a schematic diagram of the structure of a blockchain node fault recovery device in the hardware operating environment involved in the embodiments of the present invention;

[0048] Figure 2 This is a flowchart illustrating the first embodiment of the blockchain node failure recovery method of the present invention;

[0049] Figure 3 This is a schematic diagram of a hash ring representing the first embodiment of the blockchain node failure recovery method of the present invention;

[0050] Figure 4 This is a flowchart illustrating the second embodiment of the blockchain node failure recovery method of the present invention;

[0051] Figure 5This is a schematic diagram of a hierarchical nested forest in the second embodiment of the blockchain node fault recovery method of the present invention;

[0052] Figure 6 This is a structural block diagram of the first embodiment of the blockchain node fault recovery device of the present invention.

[0053] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0054] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0055] Reference Figure 1 , Figure 1 This is a schematic diagram of the structure of a blockchain node fault recovery device in the hardware operating environment involved in the embodiments of the present invention.

[0056] like Figure 1 As shown, the blockchain node fault recovery device may include: a processor 1001, such as a central processing unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen or an input unit such as a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wireless-Fidelity (Wi-Fi) interface). The memory 1005 may be high-speed random access memory (RAM) or stable non-volatile memory (NVM), such as a disk drive. The memory 1005 may also optionally be a storage device independent of the aforementioned processor 1001.

[0057] Those skilled in the art will understand that Figure 1 The structure shown does not constitute a limitation on the blockchain node failure recovery device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0058] like Figure 1 As shown, the memory 1005, which serves as a storage medium, may include an operating system, a network communication module, a user interface module, and a blockchain node fault recovery program.

[0059] exist Figure 1 In the blockchain node fault recovery device shown, the network interface 1004 is mainly used for data communication with the network server; the user interface 1003 is mainly used for data interaction with the user; the processor 1001 and the memory 1005 in the blockchain node fault recovery device of the present invention can be set in the blockchain node fault recovery device, and the blockchain node fault recovery device calls the blockchain node fault recovery program stored in the memory 1005 through the processor 1001 and executes the blockchain node fault recovery method provided in the embodiment of the present invention.

[0060] Based on the aforementioned blockchain node fault recovery device, this invention provides a blockchain node fault recovery method, referring to... Figure 2 , Figure 2 This is a flowchart illustrating the first embodiment of the blockchain node fault recovery method of the present invention.

[0061] In this embodiment, the blockchain node failure recovery method includes the following steps:

[0062] Step S10: Obtain historical consensus information of blockchain nodes, and cluster the blockchain nodes according to the historical consensus information to obtain multiple nested node clusters. The nested node clusters include consensus nodes used for consensus and ledger nodes storing ledger data.

[0063] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a mobile phone, tablet computer, or personal computer, or an electronic device or blockchain node fault recovery device capable of performing the above functions. The following description uses the blockchain node fault recovery device as an example to illustrate this embodiment and the subsequent embodiments.

[0064] It should be noted that the historical consensus information can be the consensus status of various blockchain nodes within a preset time period. For example, a correct consensus is recorded as 1, and an incorrect consensus is recorded as 0. Clustering the blockchain nodes based on the historical consensus information to obtain multiple nested clusters can be achieved by grouping blockchain nodes with the same historical consensus information within the preset time period into one category, resulting in multiple nested clusters. The blockchain nodes within each nested cluster have the same consensus information within the preset time period. The preset time period can be a pre-set time cycle, such as one month. To improve the consensus efficiency of blockchain nodes, the blockchain nodes within the same nested cluster can be further divided into consensus nodes and ledger nodes. The consensus nodes are used for consensus based on the consensus information in the blockchain, and the ledger nodes are used to store the ledger data corresponding to the nested cluster. Specifically, half of the nodes within a nested cluster can be used as consensus nodes. The consensus nodes in the nested cluster only store consensus pointer information, not the actual ledger data. The pointer connects to the ledger data, allowing for quick location of the ledger data. Since the pointer information occupies very little storage space, when a consensus node fails, only the consensus pointer needs to be restored, significantly improving fault tolerance and recovery efficiency. For ledger nodes: The remaining nodes in the node nesting cluster serve as ledger nodes. The nodes store the ledger data in the blockchain in a highly available manner, but do not store consensus information.

[0065] This embodiment employs a storage and consensus separation architecture. Ledger nodes store the ledger data; consensus nodes only store consensus pointer information, which points to the ledger data of the ledger nodes and are connected via a linked list. This approach improves storage space utilization by eliminating the need for each node to store the full ledger information. Furthermore, in the event of a consensus node failure, only the consensus pointer needs to be restored, not the entire ledger. Similarly, in the event of a ledger node failure, only the ledger data corresponding to the nested clusters of nodes needs to be restored, not the entire ledger, thus improving fault tolerance and recovery efficiency. Multiple nested clusters of nodes can share the full ledger data by dividing the full ledger data into partitioned ledger data based on the number of nested clusters, with each nested cluster storing only one copy of the partitioned ledger data.

[0066] Step S20: When a blockchain node failure is detected, determine the node nesting cluster corresponding to the failed blockchain node.

[0067] It should be noted that the node nesting cluster corresponding to the faulty blockchain node can be the node nesting cluster to which the faulty blockchain node belongs. The faulty blockchain node can be a blockchain node that has experienced a failure.

[0068] Step S30: Perform fault recovery on the faulty blockchain node based on the node nesting cluster.

[0069] It should be noted that the fault recovery of the faulty blockchain node based on the node nesting cluster can involve determining whether the faulty blockchain node is a consensus node or a ledger node. If it is a consensus node, then the consensus pointers and consensus information (consensus mechanism) stored in other normal consensus nodes in the node nesting cluster are obtained to recover the faulty blockchain node. If it is a ledger node, then ledger data is synchronized from other normal ledger nodes in the node nesting cluster.

[0070] Furthermore, in order to improve the fault recovery efficiency of blockchain nodes, step S30 may include: determining the node type of the faulty blockchain node;

[0071] The faulty blockchain node is recovered based on the node type and the node nesting cluster.

[0072] It should be noted that the node types include consensus-type and ledger-type. Consensus-type nodes can be those that perform blockchain node consensus. Ledger-type nodes can be those that store partition ledger data corresponding to nested node clusters. The step of fault recovery of the faulty blockchain node based on the node type and the nested node cluster includes:

[0073] When the node type is a first type node, the consensus node in the nested cluster of nodes is determined;

[0074] Determine the consensus pointer based on the consensus node;

[0075] The faulty blockchain node is recovered based on the consensus pointer.

[0076] When the node type is a second type node, the ledger node in the nested cluster of nodes is determined;

[0077] The partitioned ledger data is determined based on the ledger nodes;

[0078] The faulty blockchain node is recovered based on the partitioned ledger data.

[0079] It should be noted that the first type of node can be the consensus node mentioned above. The second type of node can be the ledger node mentioned above. The partitioned ledger data can be the ledger data stored in the corresponding nested cluster of nodes.

[0080] Furthermore, to improve the storage efficiency and fault tolerance recovery efficiency of the blockchain system, all blocks are stored in clusters based on their block IDs using random consistent hashing. Each cluster stores only a portion of the ledger data, rather than the entire ledger. Therefore, this embodiment also includes: determining the number of nested clusters and the full ledger data for each nested node cluster;

[0081] The full ledger data is divided based on the number of nested clusters to obtain partitioned ledger data;

[0082] Determine the block identifier corresponding to the partitioned ledger data and the nested cluster identifier corresponding to the node nested cluster;

[0083] The hash ring is determined based on the nested cluster identifier and the block identifier;

[0084] The storage location of the partitioned ledger data is determined based on the hash ring.

[0085] The full ledger data is stored in partitions based on the storage location and the ledger nodes in the nested node cluster.

[0086] It should be noted that the full ledger data can be the ledger data to be stored in the blockchain. Dividing the full ledger data based on the number of nested clusters to obtain partitioned ledger data can be achieved by dividing the full ledger data evenly according to the number of nested clusters. Assuming there are v nested clusters, each ledger node stores only 1 / v of the original data, resulting in a storage cost of 1 / v. During fault recovery, the ledger nodes are stored in clusters, allowing recovery to be completed in 1 / v of the original time, significantly improving fault recovery efficiency. The block identifier can be the block ID of the block storing the partitioned ledger data. The nested cluster identifier corresponding to the node's nested cluster can be the nested cluster ID of the node's nested cluster. For example, the ID of each level of nested cluster is represented as clusterID, and the block ID corresponding to the partitioned ledger data is represented as blockID. Determining the hash ring based on the nested cluster identifier and the block identifier can be achieved by performing a consistent hash operation on each clusterID and blockID, mapping clusterID and blockID to [0, 2]. 32 The hash value is then placed in the range [0, 2]. 32 In a hash ring consisting of [-1] values, refer to Figure 3 , Figure 3 This is a schematic diagram of a hash ring representing the first embodiment of the blockchain node fault recovery method of the present invention. All clusterIDs and blockIDs are mapped onto the hash ring.

[0087] The method of determining the storage location of the partitioned ledger data based on the hash ring can be that each block ID is stored in the cluster ID on the left side of the hash ring. For example... Figure 3BlockID1 is assigned to clusterID1, and blockID2 is assigned to clusterIDV. Blocks are stored in a clustered manner, which divides the ledger blocks into fragments for storage, instead of storing the entire ledger on all nodes. This improves both storage efficiency and fault tolerance and recovery efficiency.

[0088] Furthermore, in this embodiment, the block ID can be generated by hashing the current block cluster ID, parent block ID, parent block cluster ID, block version number, block size, Merkle tree ledger details in the block, and the block creation time field. The specific calculation formula is as follows:

[0089] Block ID = hash(Current Block Cluster ID, Parent Block ID, Parent Block Cluster ID, Block Version Number, Block Size, Merkle Tree Ledger Details in the Block, Block Creation Time)

[0090] Specifically, the block message generation format can be found in Table 1 below - Block Message Format;

[0091] Table 1 - Block Message Format

[0092]

[0093] In this embodiment, the consensus nodes in the hierarchical nested clusters consist of nodes other than the ledger nodes. Each consensus node in a hierarchical nested cluster does not store specific block information, but only stores pointers to the ledger nodes, which are connected via a linked list. Blockchain consensus only requires consensus among these nodes. The consensus node pointer storage format is shown in Table 2 - Consensus Node Pointer Storage Architecture:

[0094] Table 2 Consensus Node Pointer Storage Architecture

[0095] Serial Number key value 1 blockID1 Cluster 1: Block ID 1 2 blockID2 Cluster 1: Block ID 2 3 blockID3 Cluster 1: Block ID3 4 blockID4 Cluster 1: Block ID4 ...... ...... ......

[0096] This embodiment acquires historical consensus information of blockchain nodes, clusters the blockchain nodes based on this information to obtain multiple nested node clusters, each cluster including consensus nodes for consensus and ledger nodes for storing ledger data. When a blockchain node failure is detected, the nested node cluster corresponding to the failed blockchain node is determined. Fault recovery of the failed blockchain node is then performed based on these nested clusters. Since the ledger nodes in this embodiment only store ledger data, and the consensus nodes are only used for blockchain consensus, compared to existing blockchain nodes that require both node consensus and storage of all ledger data, this embodiment's method, when a blockchain node fails, can perform fault recovery only based on the node type, without needing to recover all ledger data and consensus information, thus improving node fault recovery efficiency.

[0097] The core drawback of existing fault-tolerance methods is that blockchain nodes store the full ledger. Given the massive amount of ledger data, storing the entire ledger on each node wastes storage space and, during node failure recovery, requires synchronizing the entire ledger, resulting in low fault-tolerance recovery efficiency. Therefore, this embodiment proposes a sharded storage and consensus separation blockchain architecture. First, based on historical consensus results, nodes are divided into hierarchical nested clusters, with nodes having high similarity in consensus results grouped into the same hierarchical nested cluster. Second, all blocks are sharded and stored within hierarchical nested clusters using a consistent hash of the blockchain ID. Ledger nodes do not need to store the full ledger, only the sharded ledger, thereby improving storage efficiency and fault-tolerance recovery efficiency.

[0098] refer to Figure 4 , Figure 4 This is a flowchart illustrating the second embodiment of the blockchain node fault recovery method of the present invention.

[0099] Based on the first embodiment described above, in this embodiment, step S10 includes:

[0100] Step S101: Obtain the historical consensus information of the blockchain node.

[0101] It should be noted that the historical consensus information may be the consensus status of various blockchain nodes within a preset time period.

[0102] Step S102: Determine the consensus feature vector of the blockchain node based on the historical consensus information.

[0103] In practical implementation, it is recommended that the hierarchical nested clusters (i.e., node nested clusters) be updated monthly. The consensus status of all blockchain nodes in the blockchain system over the past month should be selected as the feature vector, with "1" for correct consensus and "0" for incorrect consensus. Assuming there are N nodes in the blockchain, and the historical consensus information is shown in Table 3 - Historical Consensus Information Table, then the consensus feature vector of node 1 is (1, 1, 0, 1):

[0104] Table 3 - Historical Consensus Information

[0105]

[0106]

[0107] Any nested cluster can be represented by a tuple (P, Q). Here, P represents the number of nodes in the cluster (including consensus nodes and ledger nodes); Q represents the vector sum of the feature dimensions of each node in the cluster. Taking the data in Table 3 as an example, a nested cluster has four nodes: (1, 1, 0, 1), (1, 1, 1, 1), (1, 1, 1, 0), and (0, 1, 1, 1). Its corresponding tuple (P, Q) is:

[0108] P = 4

[0109] Q = (1+1+1+0, 1+1+1+1, 0+1+1+1, 1+1+0+1) = (3, 4, 3, 3), which can represent a hierarchical nested cluster in the manner described above.

[0110] Step S103: Determine the centroid of the nested forest in the blockchain based on the consensus feature vector.

[0111] It should be noted that clustering blockchain nodes results in multiple nested clusters that together form a blockchain nested forest. The centroid of this nested forest represents its center and can be calculated using the following formula:

[0112]

[0113] in, The centroid of the nested forest in the blockchain is used to represent the number of blockchain nodes, and x is used to represent the number of nodes in the blockchain. i The consensus feature vector used to characterize the i-th blockchain node. Assume there are n nodes in the blockchain system, x i Let x represent the consensus feature vector of the i-th blockchain node. Assuming that the blockchain node has participated in h consensuses over the past month, for any x i ={a1,a2,..,a h}, a h The consensus result used to characterize the h-th consensus.

[0114] Step S104: Cluster the blockchain nodes based on the centroid of the nested forest of the blockchain to obtain multiple nested clusters of nodes.

[0115] It should be noted that the clustering of blockchain nodes based on the centroid of the blockchain nested forest to obtain multiple node nested clusters can be achieved by calculating the distance from each blockchain node to the centroid of the blockchain nested forest, and dividing blockchain nodes within the same distance range into the same node nested cluster according to the distance, thus obtaining multiple node nested clusters.

[0116] Furthermore, in order to improve the similarity of consensus results among consensus nodes in the same nested cluster, step S104 may include: traversing from the second blockchain node to determine the target blockchain node to be traversed;

[0117] Obtain the currently generated nested node clusters, and determine the centroid and diameter of the nested node clusters;

[0118] The target blockchain nodes are clustered based on the centroid and diameter of the nested clusters to obtain multiple nested clusters.

[0119] It should be noted that when the hierarchical nested forest (i.e., the aforementioned blockchain nested forest) is initially generated, both the hierarchical nested forest and the hierarchical nested clusters are empty. First, the first blockchain node is read from all blockchain nodes and placed into a hierarchical nested cluster, resulting in the first hierarchical nested cluster. Determining the centroid of the nested cluster can be achieved by obtaining all nodes in the nested cluster and calculating the centroid according to Formula 1 above. When the nested cluster contains only one blockchain node, the centroid of the nested cluster is that single blockchain node. Determining the diameter of the nested cluster can be achieved by calculating the average distance between all nodes in the cluster using the following formula:

[0120]

[0121] Where D represents the diameter of the nested cluster, k represents the total number of nodes in the nested cluster, and x represents the total number of nodes in the nested cluster. i and x j These represent the i-th blockchain node and the j-th blockchain node, respectively.

[0122] For nested clusters of nodes with only one blockchain node, it is impossible to calculate the diameter of the nested cluster. Therefore, this embodiment also calculates the radius of the hierarchical nested forest, which is the average distance from all blockchain nodes in the blockchain system to the centroid of the nested forest.

[0123]

[0124] Where R is used to characterize the radius of a hierarchical nested forest. The centroid of the nested forest in the blockchain is used to represent the number of blockchain nodes, and x is used to represent the number of nodes in the blockchain. i The consensus feature vector used to characterize the i-th blockchain node.

[0125] At this point, when D = 0, let D = R, then any D can be represented as:

[0126]

[0127] The step of clustering the target blockchain node based on the centroid and diameter of the nested node cluster to obtain multiple nested node clusters can be as follows: For any target blockchain node traversed, calculate the distance between it and the centroid of each nested node cluster corresponding to the currently generated nested node cluster, select the smallest distance, and determine whether the selected distance is less than the diameter of the nested node cluster corresponding to the nested node cluster. If it is less, the target blockchain node is assigned to the nested node cluster; otherwise, a new nested node cluster is generated based on the target blockchain node, with the centroid of the newly generated nested node cluster being the target blockchain node and the diameter of the nested node cluster being R.

[0128] Following the above method, the blockchain nodes are divided into hierarchical nested clusters, ultimately forming a structure as follows: Figure 5 The hierarchical nested forest shown Figure 5 This is a schematic diagram of a hierarchical nested forest, representing the second embodiment of the blockchain node fault recovery method of the present invention.

[0129] Furthermore, in order to accurately divide the blockchain nodes, the step of clustering the target blockchain nodes according to the centroid and diameter of the nested clusters to obtain multiple nested clusters includes:

[0130] Determine the Euclidean distance from the target blockchain node to the centroid of the nested cluster of the node;

[0131] Determine the target distance based on the Euclidean distance;

[0132] Determine the diameter of the nested cluster of nodes corresponding to the target distance;

[0133] The target blockchain nodes are clustered based on the target distance and the diameter of the node nesting cluster to obtain multiple node nesting clusters.

[0134] It should be noted that the Euclidean distance from the target blockchain node to the centroid of the nested cluster can be determined according to the following formula:

[0135]

[0136] Among them, R l The Euclidean distance used to characterize the centroid of the nested cluster l of the target blockchain node. x is used to characterize the centroid of a nested cluster of nodes with arbitrary nesting levels l. i Used to characterize the target blockchain node.

[0137] Determining the target distance based on the Euclidean distance can be done by selecting the distance with the smallest Euclidean distance as the target distance. Determining the node nesting cluster diameter corresponding to the target distance can be done by determining the node nesting cluster diameter corresponding to the centroid of the node nesting cluster with the shortest distance to the target blockchain node. Clustering the target blockchain node based on the target distance and the node nesting cluster diameter to obtain multiple node nesting clusters can be done by determining whether the target distance is less than the node nesting cluster diameter; if it is less, the target blockchain node is assigned to the node nesting cluster; otherwise, a new node nesting cluster is generated based on the target blockchain node.

[0138] Furthermore, to further optimize the boundary range of the hierarchical nested clusters, a similarity evaluation analysis is performed between the hierarchical nested clusters. A hierarchical nested cluster (P, Q) represents the consensus feature within the cluster. For any two hierarchical nested clusters (P, Q), a cosine similarity calculation is performed. The higher the cosine similarity, the more similar the clusters are. Clusters with a cosine similarity greater than a preset threshold are merged again to form the final hierarchical nested cluster. The preset threshold can be a custom similarity threshold such as 0.8.

[0139] This embodiment acquires historical consensus information of blockchain nodes; determines consensus feature vectors of blockchain nodes based on the historical consensus information; determines the centroids of the nested forest of blockchain nodes based on the consensus feature vectors; and clusters the blockchain nodes based on the centroids of the nested forest of blockchain nodes to obtain multiple nested clusters of nodes. Within the hierarchical nested clusters, this embodiment adopts a storage and consensus separation architecture. Ledger storage nodes store ledger information, while consensus nodes only store consensus pointer information, with the pointers pointing to the actual addresses of the ledger storage, and are connected via a linked list. This eliminates the need for each node to store the full ledger information, improving storage space utilization. Furthermore, when a consensus node fails and recovers, the consensus node only needs to restore the consensus pointers, not the entire ledger. When a ledger node fails and recovers, only the partitioned ledger data needs to be restored, not the entire ledger, thereby improving fault tolerance and recovery efficiency.

[0140] Reference Figure 6 , Figure 6 This is a structural block diagram of the first embodiment of the blockchain node fault recovery device of the present invention.

[0141] like Figure 6 As shown, the blockchain node fault recovery device proposed in this embodiment of the invention includes:

[0142] Clustering module 10 is used to obtain historical consensus information of blockchain nodes, and to cluster the blockchain nodes according to the historical consensus information to obtain multiple nested clusters of nodes;

[0143] The detection module 20 is used to determine the node nesting cluster corresponding to the faulty blockchain node when a blockchain node failure is detected.

[0144] The fault recovery module 30 is used to perform fault recovery on the faulty blockchain node based on the node nesting cluster.

[0145] This embodiment acquires historical consensus information of blockchain nodes, clusters the blockchain nodes based on this information to obtain multiple nested node clusters, each cluster including consensus nodes for consensus and ledger nodes for storing ledger data. When a blockchain node failure is detected, the nested node cluster corresponding to the failed blockchain node is determined. Fault recovery of the failed blockchain node is then performed based on these nested clusters. Since the ledger nodes in this embodiment only store ledger data, and the consensus nodes are only used for blockchain consensus, compared to existing blockchain nodes that require both node consensus and storage of all ledger data, this embodiment's method, when a blockchain node fails, can perform fault recovery only based on the node type, without needing to recover all ledger data and consensus information, thus improving node fault recovery efficiency.

[0146] It should be noted that the workflow described above is merely illustrative and does not limit the scope of protection of this invention. In practical applications, those skilled in the art can select some or all of the workflow to achieve the purpose of this embodiment according to actual needs, and no restrictions are imposed here.

[0147] In addition, for technical details not described in detail in this embodiment, please refer to the blockchain node failure recovery method provided in any embodiment of the present invention, which will not be repeated here.

[0148] Based on the first embodiment of the blockchain node fault recovery device of the present invention, a second embodiment of the blockchain node fault recovery device of the present invention is proposed.

[0149] In this embodiment, the fault recovery module 30 is further configured to determine the node type of the faulty blockchain node;

[0150] The faulty blockchain node is recovered based on the node type and the node nesting cluster.

[0151] Furthermore, the fault recovery module 30 is also used to determine the consensus node in the nested cluster of nodes when the node type is a first type node;

[0152] Determine the consensus pointer based on the consensus node;

[0153] The faulty blockchain node is recovered based on the consensus pointer.

[0154] When the node type is a second type node, the ledger node in the nested cluster of nodes is determined;

[0155] The partitioned ledger data is determined based on the ledger nodes;

[0156] The faulty blockchain node is recovered based on the partitioned ledger data.

[0157] Furthermore, the clustering module 10 is also used to obtain historical consensus information of blockchain nodes;

[0158] The consensus feature vector of the blockchain node is determined based on the historical consensus information;

[0159] The centroid of the nested forest in the blockchain is determined based on the consensus feature vector.

[0160] Based on the centroid of the nested forest of the blockchain, the blockchain nodes are clustered to obtain multiple nested node clusters.

[0161] Furthermore, the clustering module 10 is also used to traverse from the second blockchain node and determine the target blockchain node to be traversed.

[0162] Obtain the currently generated nested node clusters, and determine the centroid and diameter of the nested node clusters;

[0163] The target blockchain nodes are clustered based on the centroid and diameter of the nested clusters to obtain multiple nested clusters.

[0164] Furthermore, the clustering module 10 is also used to determine the Euclidean distance from the target blockchain node to the centroid of the nested cluster of the node;

[0165] Determine the target distance based on the Euclidean distance;

[0166] Determine the diameter of the nested cluster of nodes corresponding to the target distance;

[0167] The target blockchain nodes are clustered based on the target distance and the diameter of the node nesting cluster to obtain multiple node nesting clusters.

[0168] Furthermore, the clustering module 10 is also used to determine the number of nested clusters of node nested clusters and the full ledger data;

[0169] The full ledger data is divided based on the number of nested clusters to obtain partitioned ledger data;

[0170] Determine the block identifier corresponding to the partitioned ledger data and the nested cluster identifier corresponding to the node nested cluster;

[0171] The hash ring is determined based on the nested cluster identifier and the block identifier;

[0172] The storage location of the partitioned ledger data is determined based on the hash ring.

[0173] The full ledger data is stored in partitions based on the storage location and the ledger nodes in the nested node cluster.

[0174] Other embodiments or specific implementations of the blockchain node fault recovery device of the present invention can be referred to the above-described method embodiments, and will not be repeated here.

[0175] Furthermore, this embodiment of the invention also proposes a storage medium storing a blockchain node fault recovery program, which, when executed by a processor, implements the steps of the blockchain node fault recovery method described above.

[0176] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0177] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0178] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory / random access memory, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0179] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A method for recovering from blockchain node failures, characterized in that, The blockchain node failure recovery method includes the following steps: Obtain historical consensus information of blockchain nodes, and cluster the blockchain nodes according to the historical consensus information to obtain multiple nested node clusters. The nested node clusters include consensus nodes used for consensus and ledger nodes storing ledger data. When a blockchain node failure is detected, the node nesting cluster corresponding to the failed blockchain node is determined; The faulty blockchain node is recovered based on the nested node cluster. The steps of obtaining historical consensus information of blockchain nodes and clustering the blockchain nodes based on the historical consensus information to obtain multiple nested clusters of nodes include: Obtain historical consensus information from blockchain nodes; The consensus feature vector of the blockchain node is determined based on the historical consensus information; The centroid of the nested forest in the blockchain is determined based on the consensus feature vector. Start traversing from the second blockchain node to determine the target blockchain node to be traversed; Obtain the currently generated nested node clusters, and determine the centroid and diameter of the nested node clusters; The target blockchain nodes are clustered based on the centroid of the nested cluster and the diameter of the nested cluster to obtain multiple nested clusters of nodes. The fault recovery of the faulty blockchain node based on the nested node cluster includes: The nodes used for fault recovery are determined based on the node type of the faulty blockchain node and the node nesting cluster; The faulty blockchain node is recovered based on the node used for fault recovery.

2. The blockchain node failure recovery method as described in claim 1, characterized in that, The step of fault recovery of the faulty blockchain node based on the node nesting cluster includes: Determine the node type of the faulty blockchain node; The faulty blockchain node is recovered based on the node type and the node nesting cluster.

3. The blockchain node failure recovery method as described in claim 2, characterized in that, The step of performing fault recovery on the faulty blockchain node based on the node type and the node nesting cluster includes: When the node type is a first type node, the consensus node in the nested cluster of nodes is determined; Determine the consensus pointer based on the consensus node; The faulty blockchain node is recovered based on the consensus pointer. When the node type is a second type node, the ledger node in the nested cluster of nodes is determined; The partitioned ledger data is determined based on the ledger nodes; The faulty blockchain node is recovered based on the partitioned ledger data.

4. The blockchain node failure recovery method as described in claim 1, characterized in that, The step of clustering the target blockchain nodes based on the centroid and diameter of the nested clusters to obtain multiple nested clusters includes: Determine the Euclidean distance from the target blockchain node to the centroid of the nested cluster of the node; Determine the target distance based on the Euclidean distance; Determine the diameter of the nested cluster of nodes corresponding to the target distance; The target blockchain nodes are clustered based on the target distance and the diameter of the node nesting cluster to obtain multiple node nesting clusters.

5. The blockchain node fault recovery method as described in any one of claims 1-4, characterized in that, After the steps of obtaining historical consensus information of blockchain nodes and clustering the blockchain nodes based on the historical consensus information to obtain multiple nested clusters of nodes, the method further includes: Determine the number of nested clusters of the node nested clusters and the full ledger data; The full ledger data is divided based on the number of nested clusters to obtain partitioned ledger data; Determine the block identifier corresponding to the partitioned ledger data and the nested cluster identifier corresponding to the node nested cluster; The hash ring is determined based on the nested cluster identifier and the block identifier; The storage location of the partitioned ledger data is determined based on the hash ring. The full ledger data is stored in partitions based on the storage location and the ledger nodes in the nested node cluster.

6. A blockchain node fault recovery device, characterized in that, The blockchain node fault recovery device includes: The clustering module is used to obtain historical consensus information of blockchain nodes, and to cluster the blockchain nodes according to the historical consensus information to obtain multiple nested clusters of nodes. The detection module is used to determine the nested cluster of nodes corresponding to the faulty blockchain node when a fault is detected. The fault recovery module is used to perform fault recovery on the faulty blockchain node based on the node nesting cluster; The steps of obtaining historical consensus information of blockchain nodes and clustering the blockchain nodes based on the historical consensus information to obtain multiple nested clusters of nodes include: Obtain historical consensus information from blockchain nodes; The consensus feature vector of the blockchain node is determined based on the historical consensus information; The centroid of the nested forest in the blockchain is determined based on the consensus feature vector. Start traversing from the second blockchain node to determine the target blockchain node to be traversed; Obtain the currently generated nested node clusters, and determine the centroid and diameter of the nested node clusters; The target blockchain nodes are clustered based on the centroid of the nested cluster and the diameter of the nested cluster to obtain multiple nested clusters of nodes. The fault recovery of the faulty blockchain node based on the nested node cluster includes: The nodes used for fault recovery are determined based on the node type of the faulty blockchain node and the node nesting cluster; The faulty blockchain node is recovered based on the node used for fault recovery.

7. A blockchain node fault recovery device, characterized in that, The device includes: a memory, a processor, and a blockchain node fault recovery program stored in the memory and executable on the processor, the blockchain node fault recovery program being configured to implement the steps of the blockchain node fault recovery method as described in any one of claims 1 to 5.

8. A storage medium, characterized in that, The storage medium stores a blockchain node fault recovery program, which, when executed by a processor, implements the steps of the blockchain node fault recovery method as described in any one of claims 1 to 5.

Images