Block chain node fault recovery method and block chain system

Abstract

The invention relates to the technical field of block chains, and discloses a block chain node fault recovery method and a block chain system.The block chain node fault recovery method comprises the following steps that S1, the fault state of a block chain node is detected through a fault detection and notification module, whether a target node needs to be recovered or not is judged, and a recovery request is broadcasted; s2, through a recovery strategy generation module, generating initial probability distribution based on the recovery demand of the target node and the bandwidth and load state of the normal node, and determining a data distribution strategy of the normal node; and S3, according to the response state of the normal node, the probability distribution is adjusted through a dynamic adjustment and optimization module. According to the method, the problems of low node fault recovery efficiency, non-uniform task distribution, poor transmission reliability and long verification time consumption in the prior art are solved by dynamically adjusting probability distribution optimization, data blocking and multi-path parallel transmission, redundant coding combined consistency verification and a hierarchical priority strategy; and the efficiency and adaptability of data recovery are greatly improved.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a blockchain node failure recovery method and a blockchain system. Background Art

[0002] Blockchain technology has been widely used in finance, the Internet of Things, and supply chains due to its decentralization, high security, and data immutability. The stability and reliability of blockchain networks largely depend on the continuous operation of distributed nodes. However, in practical applications, node failures are inevitable due to hardware failures, network fluctuations, or node overloads. To ensure the integrity and consistency of the system, the failed node needs to complete the recovery operation by synchronizing data from other normal nodes. In the prior art, a variety of solutions have been proposed for the research on node failure recovery, such as full data synchronization, static path allocation, and single-path transmission.

[0003] In the construction of the existing technology, a full synchronization method is used to download all historical data of the target node from a normal node to a faulty node, or data is transmitted from a small number of high-performance nodes through a static path. However, these technical solutions have obvious shortcomings. On the one hand, full synchronization is extremely inefficient when the amount of blockchain data is large, and the recovery time is too long, resulting in the inability of the faulty node to quickly re-participate in the consensus. On the other hand, the static path allocation strategy is difficult to adapt to the dynamic changes in the network status, causing some nodes to be overloaded and uneven resource utilization. In addition, the existing single-path transmission method lacks fault tolerance, and data loss or transmission interruption will lead to recovery failure. At the same time, the existing technology uses a full verification method to verify the consistency of all recovered data, and cannot respond quickly when key data (such as the latest block) needs to be restored first. Summary of the invention

[0004] In view of the shortcomings of the prior art, the present invention provides a blockchain node fault recovery method and a blockchain system, which solve the problems of low transdermal absorption efficiency, insufficient dynamic release ability, poor drug stability and incomplete therapeutic effect of topical drugs in the prior art.

[0005] To achieve the above objectives, the present invention is implemented through the following technical solutions: a blockchain node failure recovery method and a blockchain system, comprising the following steps: S1. Detect the fault status of the blockchain node through the fault detection and notification module, determine whether the target node needs to be restored, and broadcast a recovery request; S2. Generate an initial probability distribution and determine the data allocation strategy for normal nodes through a recovery strategy generation module based on the recovery requirements of the target node and the bandwidth and load status of normal nodes; S3. According to the response status of normal nodes, the probability distribution is adjusted through the dynamic adjustment and optimization module to optimize the allocation of data requests and dynamically adjust the participation probability of normal nodes; S4. Send data requests to normal nodes according to the adjusted probability distribution through the data transmission and execution module to perform data transmission and recovery operations; S5. Perform consistency check on the transmitted data through the data consistency check module to verify the data integrity of the target node and ensure that the state of the target node is consistent with other normal nodes; S6. When the target node data is verified, it rejoins the blockchain network to participate in the consensus.

[0006] Preferably, in S2, the initial probability distribution is generated by the real-time bandwidth of the normal nodes, and the initial probability distribution is allocated according to the ratio of the bandwidth of each normal node to the total bandwidth of the normal node set, and the probability of the normal node is the bandwidth of the node divided by the total bandwidth.

[0007] Preferably, in S3, the probability distribution is adjusted by combining the participation cost-effectiveness of normal nodes through a dynamic adjustment and optimization module. The cost-effectiveness is the ratio of the participation reward of the node to the sum of the bandwidth cost and the load cost of the node. The probability distribution of the node is dynamically increased or decreased according to the cost-effectiveness.

[0008] Preferably, in S5, the consistency check performs data integrity verification through the blockchain status tree, including calculating the hash value of the data provided by each normal node and comparing it with the blockchain status tree. When the hash values ​​of all data blocks match, it is determined that the target node has been successfully recovered.

[0009] A blockchain node fault recovery system, comprising: Fault detection and notification module, recovery strategy generation module, dynamic adjustment and optimization module, data transmission and execution module and data consistency verification module, among which: The fault detection and notification module is used to detect the fault status of the target node, determine whether the target node needs to be restored, and send a restoration request to the normal node set; The recovery strategy generation module is used to generate an initial probability distribution based on the recovery requirements of the target node and the bandwidth and load status of the normal nodes, and determine the data allocation strategy of the normal nodes; The dynamic adjustment and optimization module is used to dynamically adjust the probability distribution according to the real-time response status of the normal nodes to optimize the data allocation strategy; The data transmission and execution module is used to send data requests to normal nodes according to the adjusted probability distribution and perform data transmission operations; The data consistency check module is used to perform consistency check on the data received after the target node is restored, verify the integrity of the target node data and ensure that the state of the target node is consistent with that of a normal node.

[0010] Preferably, the recovery strategy generation module includes a maximum entropy optimization unit, which is used to make the allocation probability of all normal nodes satisfy the maximum entropy distribution when generating the initial probability distribution, so as to ensure the balance of data requests.

[0011] Preferably, the dynamic adjustment and optimization module includes a feedback adjustment unit, which adjusts the probability distribution in real time according to bandwidth changes, load changes and response cost performance of normal nodes, and dynamically optimizes the data request allocation strategy of the recovery node.

[0012] Preferably, the data transmission and execution module includes a multi-path parallel transmission unit, which is used to split the data request of the target node and distribute the data transmission task to multiple normal nodes for parallel processing.

[0013] Preferably, the data consistency verification module includes a hash verification unit, which calculates the hash value of the data transmitted by each normal node and compares it with the hash value stored in the blockchain status tree to ensure the integrity and consistency of the data restored by the target node.

[0014] Preferably, the fault detection and notification module detects the running status of the target node by regularly sending heartbeat messages. When the target node does not respond for a long time, a fault determination is triggered and a recovery process is started. The present invention provides a blockchain node fault recovery method and a blockchain system. It has the following beneficial effects: 1. The present invention adopts a probability distribution optimization technology based on dynamic adjustment, monitors the status of normal nodes in real time, and dynamically adjusts the task allocation strategy, thereby achieving the technical effect of efficiently allocating recovery tasks in a complex network environment. Compared with the solution using fixed paths or static allocation in the prior art, it solves the problem of low recovery efficiency caused by network status fluctuations and significantly improves the adaptability and reliability of node fault recovery.

[0015] 2. The present invention combines the technical solutions of data segmentation and multi-path parallel transmission, which can flexibly adjust the data block size according to the bandwidth and load of the node, and complete the task transmission through parallel channels. This technical effect has demonstrated high transmission efficiency in actual operation. Compared with the single-path transmission or centralized task allocation solutions in the prior art, it solves the transmission bottleneck problem and effectively avoids the delay and packet loss caused by the overload of a single node.

[0016] 3. The present invention achieves the technical effects of high fault tolerance and fast verification in the process of data consistency verification by introducing redundant coding and Merkle tree verification mechanism. Compared with the prior art that only relies on simple hash verification, it solves the problem of recovery failure caused by data loss or damage, greatly improves the stability of data verification, and reduces retransmission overhead.

[0017] 4. The present invention uses a multi-level verification priority mechanism to perform hierarchical verification processing on key data blocks and historical data blocks, thereby achieving the technical effect of priority recovery of key data. Different from the one-size-fits-all verification strategy adopted in the prior art, this solution solves the problem of delaying the participation of recovery nodes in consensus due to the time-consuming unified verification, further shortens the recovery time, and improves the practicality and real-time performance of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 It is a schematic diagram of the method flow of the present invention; Figure 2 It is a system architecture diagram of the present invention. DETAILED DESCRIPTION

[0019] The following will be combined with the drawings in the specification of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0020] Please refer to the attached Figure 1 , an embodiment of the present invention provides a blockchain node failure recovery method, comprising the following steps: S1. Detect the fault status of the blockchain node through the fault detection and notification module, determine whether the target node needs to be restored, and broadcast a recovery request; In this embodiment, the fault detection and notification module adopts a two-layer detection mechanism based on heartbeat messages and status feedback. First, the system sends heartbeat messages to the target node regularly to confirm the online status of the node. Generally, the module sends a set of detection signals to the target node every preset time period. If the target node does not respond to the heartbeat message continuously within the preset time, the system will mark it as a potential fault node.

[0021] Specifically, the system will count the online status of the node based on the number of heartbeat responses. In some embodiments, the module will dynamically adjust the frequency of heartbeat detection in combination with parameters such as communication delay and packet loss rate in the network. For example, when the network fluctuates greatly, the module may reduce the frequency of heartbeat transmission to reduce the network load, and when the network state is stable, the module may increase the frequency of heartbeat detection to improve the accuracy of detection.

[0022] In one possible implementation, when the block synchronization lag of the target node persists and the difference with the entire network reaches a certain level, the module will mark it as a node that needs to be restored and trigger the fault recovery process.

[0023] In some embodiments, the fault detection and notification module also combines the target node's operation log to make fault determinations. By collecting and analyzing the target node's log data, the module can detect some more fine-grained fault conditions, such as consensus timeouts, transaction processing delays, or data reading errors. In general, when timeouts or error records frequently appear in a node's log, the module will consider the node to have a potential fault and broadcast a notification to the entire network.

[0024] As an option, when the module generates a fault recovery request, it will package the key information of the target node into a recovery notification and broadcast it. The recovery notification generally includes the following: The unique identifier of the target node, such as its public key or node address; The latest response status of the target node, such as the timestamp of the last heartbeat response; The block height information of the target node and the block range that needs to be restored; Exception log information of the target node (if any).

[0025] After receiving the fault notification, the normal nodes in the entire network will enter the recovery state and wait for the recovery strategy generated by the subsequent modules.

[0026] S2. Generate an initial probability distribution and determine the data allocation strategy for normal nodes through a recovery strategy generation module based on the recovery requirements of the target node and the bandwidth and load status of normal nodes; In this embodiment, after receiving the output of the fault detection and notification module, the recovery strategy generation module first collects the status feedback information of all normal nodes. Normal nodes provide the module with key information such as bandwidth, load, and response capability for generating a data request allocation strategy.

[0027] In general, the module pre-processes the feedback information of normal nodes, including removing nodes with abnormal status and filtering low reliability nodes. Specifically, the feedback information of normal nodes includes: Bandwidth status: used to determine the transmission capacity of the node; Current load: reflects the task processing pressure of the node; Historical response: used to evaluate the stability and reliability of the node.

[0028] Through comprehensive analysis of this information, the module can assign reasonable initial request tasks to each normal node.

[0029] In some embodiments, the module also combines historical response records to perform probability downgrade processing on nodes with higher failure rates to improve the reliability of data recovery. For example, for nodes with poor response stability, the module will appropriately reduce their data allocation ratio to ensure the stability of the recovery task.

[0030] Specifically, the initial data allocation strategy generated by the module is presented in the form of a probability distribution, where the allocation ratio of each node is positively correlated with its bandwidth and load status. In some embodiments, in order to further balance the network load, the module also introduces node priority parameters. For example, high-priority nodes can obtain a higher task allocation ratio based on their historical contribution.

[0031] As an option, the module also supports estimating the potential risks of data transmission. Generally, the module will combine the node's bandwidth fluctuation and historical packet loss rate information to generate a risk factor to assist in optimizing the task allocation strategy. By incorporating the risk factor into the allocation weight, the module can reduce the proportion of tasks allocated to low-reliability nodes, thereby reducing the probability of data recovery failure.

[0032] S3. According to the response status of normal nodes, the probability distribution is adjusted through the dynamic adjustment and optimization module to optimize the allocation of data requests and dynamically adjust the participation probability of normal nodes; In this embodiment, the dynamic adjustment and optimization module takes the initial probability distribution as input and updates the distribution in combination with the real-time status feedback of normal nodes. Specifically, the module collects the following status parameters of each normal node: Real-time transmission rate: used to evaluate the current data processing capability of the node; Packet loss rate: reflects the reliability of node data transmission; Current load: used to measure whether the node is in a high load state.

[0033] Generally, the module normalizes these state parameters to establish a weight relationship between different indicators and adjust the task allocation ratio of the node accordingly. For example, when the packet loss rate of a node increases, the module will reduce the allocation probability of the node, thereby allocating more tasks to other reliable nodes.

[0034] As an option, the dynamic adjustment and optimization module will also conduct a comprehensive evaluation of the response efficiency of normal nodes based on the task completion status of the target node. Specifically, the module will dynamically update the node weight based on the actual data transmission time, data integrity rate and other information of each node. The change in the node weight directly affects its task allocation ratio. For example, when the transmission time of a node is significantly extended, the module will reduce the tasks assigned to the node to improve the overall task execution efficiency.

[0035] In some embodiments, the module also supports estimating the performance of nodes through historical data. For example, when the historical response record of a node shows that its transmission rate fluctuates frequently within a specific time period, the module will reduce its allocation ratio in advance. This estimation mechanism can avoid data recovery failures caused by abnormal node status to a certain extent.

[0036] Specifically, the module adopts a segmented adjustment method when updating the task allocation strategy. Generally, the module divides normal nodes into different priority groups and assigns different task ratios to each priority group. For example: High priority group: contains nodes with high transmission rate, low packet loss rate and light load, and has a higher allocation ratio; Medium priority group: contains nodes with medium status and a moderate allocation ratio; Low priority group: contains nodes with high load or unstable status, and has a low allocation ratio.

[0037] This segment adjustment strategy can maintain the balance of task allocation in a dynamic network environment while ensuring full utilization of efficient nodes.

[0038] As another option, the dynamic adjustment and optimization module can also predict possible abnormal situations through statistical analysis of real-time monitoring data. For example, when the packet loss rate of a node shows a continuous upward trend, the module will immediately adjust its allocation ratio to the lowest level and mark it as an abnormal node to reduce the risk of data loss caused by abnormal nodes.

[0039] In some embodiments, the module supports iterative optimization of task allocation results. After each round of tasks is completed, the module will recalculate the probability distribution based on the latest status feedback of normal nodes, and the updated distribution will serve as the basis for the next round of task allocation. This iterative optimization mechanism can dynamically adapt to changes in network status and ensure that task allocation is always in the optimal state.

[0040] S4. Send data requests to normal nodes according to the adjusted probability distribution through the data transmission and execution module to perform data transmission and recovery operations; In this embodiment, the data transmission and execution module first divides the recovery data of the target node into blocks according to the optimized probability distribution. Generally, the module divides the target data D into several sub-data blocks, and each data block is allocated to different nodes according to the allocation probability of normal nodes.

[0041] Specifically, the allocation ratio of data blocks is dynamically adjusted according to the real-time response capability, bandwidth status and load conditions of the nodes. Through this block mechanism, the module can avoid overloading of a single node and improve transmission efficiency and network resource utilization.

[0042] In some embodiments, the module supports assigning a unique identifier to each data block according to the assignment result, so that the transmission status of each data block can be accurately tracked during the subsequent verification process.

[0043] As an option, the module uses multi-path parallel transmission to send data requests to multiple normal nodes at the same time. Generally, the module will allocate an independent network channel for each transmission path to ensure that the transmission tasks of different paths do not interfere with each other. The parallel transmission design can significantly improve the overall efficiency of data recovery.

[0044] Specifically, in order to further ensure the reliability of transmission, the module supports dynamic monitoring of the transmission rate and packet loss rate of each path during the transmission process. In some embodiments, when the packet loss rate of a path increases significantly, the module will promptly reduce the task allocation of the path and reallocate the remaining tasks to other paths.

[0045] In a possible implementation, the module also combines redundant coding technology to enhance the fault tolerance of data transmission. Generally, the module generates a certain number of redundant blocks for the original data after data segmentation, and the redundant data is transmitted to the target node together with the original data.

[0046] When some data blocks are lost or damaged during transmission, the target node can decode and recover the lost data blocks through the received redundant data. Redundant coding technology can reduce the frequency of data retransmission to a certain extent, further improving transmission efficiency and the success rate of recovery tasks.

[0047] Specifically, the module will allocate more network resources to high-priority tasks based on the allocation weights of the dynamic adjustment and optimization module. In some embodiments, the module also supports dynamic adjustment of priorities during transmission. For example, when the progress of a high-priority task lags behind expectations, the module will temporarily reduce the resource allocation of other low-priority tasks to ensure that the high-priority task is completed on time.

[0048] After the data transmission is completed, the module will generate a transmission result report and submit it to the data consistency verification module. In general, the report content includes: The data block identifier that has completed transmission; Status information such as transmission rate and packet loss rate of each transmission path; Integrity identifiers of all data blocks (such as hash values).

[0049] The above information can provide a reliable data basis for subsequent consistency verification, and also provide feedback information for subsequent iterative optimization of the dynamic adjustment and optimization module.

[0050] In some embodiments, the module supports a real-time status feedback mechanism to further improve the execution efficiency of transmission tasks. Specifically, during each round of task execution, the module receives real-time status feedback from normal nodes, such as current load changes and packet loss. Based on the feedback information, the module can fine-tune unfinished tasks and reallocate remaining tasks to efficient nodes to avoid wasting resources.

[0051] S5. Perform consistency check on the transmitted data through the data consistency check module to verify the data integrity of the target node and ensure that the state of the target node is consistent with other normal nodes; In this embodiment, the data consistency verification module first performs hash value verification on all data blocks received by the target node. Specifically, the module generates a corresponding hash value for each data block and organizes these hash values ​​into leaf nodes of the status tree. In general, the status tree structure can quickly verify the integrity of any data block and accurately locate the problem data block when inconsistencies are found.

[0052] In some embodiments, the data consistency check module also supports verification of the block order of received data. For example, when the transmission process of data blocks involves parallel channels, the module will ensure the integrity of data reception through the unique identification of the data blocks and the transmission path record. At the same time, the module will compare the number of data blocks with the target data requirements to avoid verification failures due to missing data blocks.

[0053] As an option, the module will compare the root hash value of the generated state tree with the root hash value of the state tree synchronized with the whole network. Generally, when the state tree root hash of the target node is consistent with the root hash of the whole network, it can be directly determined that the data recovery of the target node is successful. If the comparison results are inconsistent, the module will locate the abnormal data block and generate a detailed error report.

[0054] In some embodiments, in order to improve the efficiency of consistency verification, the module supports a hierarchical verification process. Specifically, the module will first verify the hash value of the latest block data to quickly confirm whether the target node can participate in the latest consensus process. For historical data blocks, the module can reduce the verification time overhead and improve the efficiency of the entire verification process by batch verification.

[0055] Specifically, when a data block is found to be inconsistent, the module triggers the data retransmission mechanism. Generally, the module returns the identification of the abnormal data block and the corresponding transmission path information to the data transmission and execution module, and the data transmission module re-requests the data block. The retransmission mechanism ensures that the target node recovery task can be completed even in the case of partial data loss or transmission errors.

[0056] In some embodiments, the module also supports generating a verification report on the recovery status of the target node. Generally, the verification report includes the following contents: The range of blocks that have passed data verification; The identification and number of data blocks that failed verification; Verification time and network status analysis.

[0057] The verification report will serve as an important basis for the target node to rejoin the consensus process, and at the same time provide credible proof of the node's recovery status to other nodes in the entire network.

[0058] As another option, the module also supports synchronization analysis of the state tree of the entire network. For example, when the state tree of the target node is partially inconsistent with the state tree of the entire network, the module can combine the state broadcast information of the nodes in the entire network to identify whether there are abnormal states of other nodes. Through this analysis, the module can further improve the comprehensiveness of consistency verification and ensure that the target node recovery process is not affected by abnormal state of the entire network.

[0059] S6. When the target node data passes the verification, it rejoins the blockchain network to participate in the consensus; In this embodiment, when the target node passes the data consistency check, the module will generate a recovery status notification of the target node and broadcast it to the entire network. Specifically, the recovery status notification includes the following contents: Identification information of the target node, such as its node ID or public key; The timestamp of recovery completion ensures that all nodes in the network can identify the recovery time; The data verification range and verification results serve as a reliable basis for the successful recovery of the target node.

[0060] After receiving the notification, normal nodes in the entire network will update the status of the target node stored locally, mark it as available, and allow it to participate in the subsequent consensus process.

[0061] In one possible implementation, when the latest block data of the target node is still delayed to a certain extent, the system will start a short-cycle state synchronization mechanism. Through short-cycle synchronization, the target node can obtain the latest block data and consensus status at a faster speed, thereby shortening the time required for its full recovery.

[0062] Specifically, when the target node re-participates in the consensus, the module will dynamically adjust the initial task allocation of the target node. For example, in the consensus mechanism, the voting weight or task allocation ratio of the target node may be appropriately restricted according to its recovery time. Through this mechanism, it can be ensured that the target node will not affect the operating efficiency of the entire network due to a backlog of tasks in a short period of time.

[0063] In some embodiments, in order to further enhance the recovery stability of the target node, the system will set a temporary status observation period for the target node. During the status observation period, all nodes in the network will monitor the operation of the target node, including its consensus response time, block efficiency and other indicators. Only nodes that perform normally during the status observation period will be fully restored to the consensus mechanism of the entire network.

[0064] As an extension, the process of target node recovery and re-participation in consensus also involves the consistency management of the blockchain network. For example, when the target node is recovered, if its status notification conflicts with the status information of other nodes, the module will automatically start the conflict resolution process. In some embodiments, the system will adjudicate the conflict based on the status data of the majority of nodes to ensure that the status information of the recovered node is consistent with the entire network.

[0065] Step S6 of the present invention also supports generating a recovery completion report of the target node and broadcasting the report to the entire network. The content of the report includes information such as the recovery status of the target node, task allocation, and data consistency verification results. In this way, the system can provide the entire network with a trusted status certificate of the recovery node, avoiding trust issues caused by information asymmetry.

[0066] Please see attached Figure 1 , a blockchain node fault recovery system, comprising: Fault detection and notification module, recovery strategy generation module, dynamic adjustment and optimization module, data transmission and execution module and data consistency verification module, among which: The fault detection and notification module is used to detect the fault status of the target node, determine whether the target node needs to be restored, and send a recovery request to the normal node set; In this embodiment, the fault detection and notification module adopts a dual fault determination mechanism based on heartbeat message detection and status data analysis to ensure the accuracy and real-time performance of detection.

[0067] In general, the system will periodically send heartbeat messages to each node through the network to detect the online status of the node. If the target node does not respond to the heartbeat message within the predetermined time interval, it will be marked as a potential faulty node. In addition, the module will also combine the status data of the target node, including block synchronization status and data integrity, to further verify whether it has any abnormalities.

[0068] Specifically, during the detection phase, the module will quantify the failure probability of the node using the following formula:

[0069] in: : The failure probability of the target node; : The number of times the target node does not respond to the heartbeat message during the monitoring period; : The total number of heartbeat messages sent during the monitoring period.

[0070] When the probability of failure Exceeding the set threshold , the target node will be judged as a faulty node.

[0071] In some embodiments, in order to improve the accuracy of fault detection, the module will also monitor the block synchronization status of the target node. Generally, each blockchain node will broadcast its latest block height through the chain status. This module compares the block height of the target node with the latest block height of the entire network. Compare if the following conditions are met:

[0072] in: : The difference between the target node and the latest block height of the entire network; : If the block height difference threshold is exceeded, the target node will be marked as synchronization abnormal, and further combined with the heartbeat message data to confirm whether it is a failure.

[0073] In one possible implementation, this module supports fault determination based on node log analysis. Specifically, the system periodically obtains the target node's operation log, including indicators such as the number of transactions processed and consensus response time. Generally, a fault notification is triggered when one of the following abnormal conditions exists in the log: The number of transactions processed by the target node within the set time period is lower than the set threshold; The consensus response time of the target node is significantly higher than the normal range.

[0074] For example, when the average consensus response time of the target node is satisfy:

[0075] in: : Average consensus response time of target nodes; : The response time threshold set for the entire network. The system will determine that the target node is operating abnormally and trigger further fault analysis.

[0076] As an option, when the module generates a fault notification, it will include key information and recovery requirements of the target node, including but not limited to: Unique identifier of the failed node (e.g. node public key); The amount of data that needs to be restored , the amount of data can be based on the block height difference and status data for estimation; The last response time of the target node is used to assist subsequent modules in determining the priority of the recovery strategy.

[0077] In one possible implementation, the module packages the above information into a recovery request and distributes it to the entire network using a broadcast mechanism based on a P2P network. The broadcast request will be digitally signed to ensure that the source of the request is credible.

[0078] In some embodiments, in order to improve the efficiency of fault determination and recovery startup, the module supports dynamic adjustment of the heartbeat detection frequency. Specifically, the system will adjust the heartbeat detection frequency according to the historical fault records of the target node. Dynamically adjust the heartbeat detection interval :

[0079] in: : The basic interval time of heartbeat detection; : The failure rate of the target node in the historical monitoring period; : Adjustment coefficient, used to control the dynamic change amplitude of frequency.

[0080] When the target node has a high historical failure rate, the system will shorten the heartbeat detection interval to increase the detection frequency and ensure that potential problems can be discovered quickly.

[0081] After the fault determination is completed, the system will mark the target node as a fault state and pass relevant information to the recovery strategy generation module. Generally, this information includes the fault identification of the target node, the fault probability, the data range that needs to be restored, etc. In addition, this module will also record the status information of normal nodes (such as bandwidth and load) to provide support for the formulation of subsequent recovery strategies.

[0082] The extended technology of this module also includes joint detection of multi-node failures. In some cases, when multiple nodes lose heartbeats or block synchronization anomalies at the same time, the module will trigger the multi-node failure mode. In this mode, the system will analyze the correlation between abnormal nodes in combination with the network topology. For example, by detecting whether the abnormal nodes are in the same network partition, it is determined whether there is a node separation problem caused by a network partition failure. If it is determined to be a network partition failure, additional network partition repair information will be attached to the broadcast request.

[0083] Through the above implementation, the fault detection and notification module can not only quickly and accurately determine the fault status of a single node or multiple nodes, but also provide necessary data support for the subsequent recovery module. The module is flexible and scalable in node detection, status analysis and recovery information generation, and is suitable for a variety of blockchain network environments.

[0084] The recovery strategy generation module is used to generate an initial probability distribution and determine the data allocation strategy of normal nodes based on the recovery requirements of the target node and the bandwidth and load status of the normal nodes; In this embodiment, the recovery strategy generation module generates an initial probability distribution strategy based on the recovery request provided by the fault detection module. The normal node will feed back its own state information to the recovery node, and the recovery node will generate a strategy based on the state information.

[0085] As an option, the normal node status information received by the recovery strategy generation module includes the node bandwidth , Node Load , Historical response time Etc. Among them: Representation Node The current real-time available bandwidth (in MB / s), which is determined by the node's network status; Representation Node The current computational load, which can usually be quantified by the length of its task queue; Representation Node The historical average response time of data transfers involved (in seconds).

[0086] Based on these parameters, the module calculates the initial cost-performance ratio of each node. ,in:

[0087] In the above formula: is the bandwidth cost coefficient, which reflects the cost of the node in terms of bandwidth occupation; is the load cost coefficient, which is used to measure the performance overhead caused by the increase in node load.

[0088] Generally speaking, nodes with high cost-effectiveness will be given priority to receive more data requests.

[0089] Specifically, the recovery strategy generation module generates the initial probability distribution through the following formula :

[0090] in: Indicates a normal node; The initial request probability of For Node bandwidth; Represents the sum of bandwidth of all normal nodes.

[0091] Through the above formula, the initial probability distribution can be generated according to the relative bandwidth capacity of each node, so that high-bandwidth nodes can be assigned more tasks.

[0092] In some embodiments, in order to further balance the network load, the module adopts the maximum entropy optimization method. The introduction of the maximum entropy principle can ensure that even if some nodes fail, the task allocation of the remaining nodes is still well balanced. The definition of entropy is as follows:

[0093] The goal of the module is to generate the final probability distribution by optimizing the following objective function:

[0094] in: Optimize weights for entropy and control the trade-off between entropy and recovery time; is the data transmission time, defined as:

[0095] Indicates the total amount of data that needs to be restored (unit: MB).

[0096] By optimizing the above objective function, the recovery strategy generation module can find the best balance between data recovery efficiency and network balance.

[0097] In one possible implementation, the module supports a hierarchical strategy for task priority. Specifically, when the target node has a large amount of recovery data, the module will prioritize the recovery of the latest block data. At this time, the recovery strategy generation module will dynamically adjust the probability distribution so that nodes with lower response latency are assigned the latest data blocks first.

[0098] As an option, the module also supports appropriately downgrading the probability of nodes with a high historical failure rate. , the module will calculate the fault correction factor :

[0099] in: Representation Node Historical failure rates; The value range is [0,1].

[0100] The probability distribution of the nodes is adjusted according to the correction factor:

[0101] As another possibility, the module supports the combined use of task splitting mechanisms. For example, when the target data volume When it is large, the module will split the data into Data blocks , the size of each data block is determined by the following formula:

[0102] In this way, data requests can be more accurately distributed to multiple normal nodes.

[0103] In this embodiment, the probability distribution generated by the recovery strategy generation module It will serve as the initial input for the subsequent dynamic adjustment and optimization module. The dynamic adjustment module will further optimize the probability distribution according to the actual network response, thereby further improving the data recovery efficiency.

[0104] In summary, this module can provide a good basic support for subsequent recovery tasks by generating initial probability distribution and optimizing task allocation strategy. By combining multi-dimensional information such as node bandwidth, load, and fault history, the module achieves high efficiency and balance in initial task allocation and has strong adaptability in a dynamic network environment.

[0105] The dynamic adjustment and optimization module is used to dynamically adjust the probability distribution according to the real-time response status of normal nodes to optimize the data allocation strategy; In this embodiment, the dynamic adjustment and optimization module iteratively optimizes the initial probability distribution through a feedback adjustment mechanism. Specifically, the recovery node monitors the response behavior of the normal node in real time, including information such as bandwidth consumption, task completion time, and data loss rate, and dynamically adjusts the probability distribution based on the node's cost performance.

[0106] As an option, this module first calculates the actual transmission time of each node , which includes data transmission time and processing delay:

[0107] in: :node The actual response time; :node The size of the received data block; :node bandwidth; :node processing delay.

[0108] The response cost performance of a node can be quantified based on the actual response time and cost. The specific formula is as follows:

[0109] in: :node Cost-effective response; : The participation cost of a node, defined as:

[0110] In the above formula, and They are bandwidth cost weight and load cost weight respectively.

[0111] Specifically, this module uses the following formula to dynamically adjust the probability distribution:

[0112] in: For the Wheel Node The probability distribution of To adjust the step size, the value range is (0,1), which is used to control the adjustment amplitude; It is the effective response cost performance of the node.

[0113] In general, The value of can be adjusted dynamically according to the network stability. For example, when the network response status fluctuates greatly, it is appropriate to reduce To improve the stability of the adjustment; when the network status is relatively stable, you can appropriately increase , to speed up the adjustment.

[0114] In some embodiments, this module will combine the historical response records of the nodes to further optimize the accuracy of dynamic adjustment. Specifically, the module will record the historical failure rate of each node. , and the adjustment result is corrected by the following formula:

[0115] in: Representation Node The historical failure rate of is in the range of [0,1].

[0116] Through the above correction method, the module can reduce the probability of task allocation to nodes with higher failure rates, thereby reducing data transmission interruptions caused by node instability.

[0117] As a possible implementation method, this module also supports dynamic adjustment strategies for high-priority tasks. Specifically, when the target node has a large amount of recovery tasks and some data has a high priority, this module will dynamically increase the allocation ratio of high-priority data. For example, when the data priority of the latest block is , the data priority of the historical block is , the module will adjust the priority of data block allocation:

[0118] in: Indicates the total amount of high priority data; Indicates the total amount of low priority data.

[0119] Through this weighted adjustment method, this module can dynamically respond to the recovery needs of the target node and ensure that key data is transmitted first.

[0120] In a possible implementation, this module also combines a dynamic feedback adjustment mechanism for packet loss rate. Exceeding the set threshold , the module will dynamically reduce the allocation probability of the node:

[0121] By monitoring the packet loss rate in real time, the module can effectively reduce the task allocation of low-reliability nodes, thereby improving the overall efficiency of the recovery process.

[0122] In this embodiment, the output result of the dynamic adjustment and optimization module is the probability distribution after multiple rounds of optimization. This probability distribution will be directly used to guide the task allocation strategy of the data transmission and execution modules. The dynamic feedback adjustment mechanism of the module can ensure that the data recovery tasks can always be allocated in the best way when the network status fluctuates.

[0123] In summary, this module significantly improves the flexibility and adaptability of the data recovery process through multiple optimization strategies such as feedback adjustment, priority weighting, and history correction. The module has good robustness in complex network environments and can continuously optimize data transmission strategies under dynamically changing conditions, thereby ensuring the efficiency and stability of the fault recovery process.

[0124] The data transmission and execution module is used to send data requests to normal nodes according to the adjusted probability distribution and perform data transmission operations; In this embodiment, the data transmission and execution module first calculates the target data volume In general, the module will divide the data into blocks according to the bandwidth and probability distribution of normal nodes. Divide into Sub-blocks Specifically, the size of a single data block The calculation formula is:

[0125] in: : Assigned to normal nodes The data block size; :node The probability of allocation; : The total amount of data that needs to be restored on the target node.

[0126] Through the above-mentioned block processing, task allocation can be accurately achieved according to the resource situation of each normal node, ensuring maximum bandwidth utilization efficiency.

[0127] As an option, this module uses a multi-path parallel transmission mechanism. Specifically, the recovery node will send data requests to multiple normal nodes at the same time and receive different data blocks in parallel. In general, the module will allocate an independent transmission channel for each data transmission path to avoid competition between channels and reduce transmission efficiency.

[0128] In order to further improve the fault tolerance of transmission, this module supports redundant encoding of data. Specifically, the module performs erasure coding on the data blocks before segmentation to generate Even if some normal nodes are interrupted due to network fluctuations or other reasons, the recovery node can still complete the recovery task through the remaining redundant data.

[0129] The generation formula of erasure code is as follows:

[0130] in: : Erasure code generator matrix; : original data block matrix; : The generated redundant data block matrix.

[0131] Through this mechanism, even if there is packet loss during transmission, the remaining redundant data can still be decoded to restore the original data.

[0132] Specifically, during data transmission, the module monitors the packet loss rate of each normal node. As a possible implementation method, when the packet loss rate of a node exceeds the set threshold When the node is in a state of failure, the module will dynamically reduce the task allocation of the node and reallocate the unfinished data blocks. For example, for a node with a packet loss rate higher than the threshold, its task allocation The calculation formula is:

[0133] The amount of data remaining after redistribution Will be distributed to other reliable nodes in proportion.

[0134] In one possible implementation, the data transmission and execution module also supports dynamic adjustment of transmission priority. Specifically, when the target data contains a data block with a higher priority (such as the latest block data), the module will give priority to transmitting the high priority data. In general, the module will assign a priority weight to each data block. , the transmission order is arranged in descending order of weight. The weight calculation formula is:

[0135] in: and are the priority adjustment coefficients respectively; Indicates the weight of the most recent update time of the data block; Represents the importance weight of the data block.

[0136] Through dynamic priority adjustment, it can ensure that key data blocks are transmitted first, improving the accuracy and real-time performance of data recovery.

[0137] As an extended technology, this module also introduces a transmission status feedback mechanism. Generally, the recovery node will send a status request to the normal node after each round of transmission is completed, and collect the following status information: Transfer rate ; Packet loss rate ; Data integrity verification results.

[0138] The above status information will be input into the dynamic adjustment and optimization module in real time to further optimize the data allocation strategy. For example, when the transmission rate of a node drops significantly, its allocation probability Will be dynamically lowered to reduce reliance on this node.

[0139] In this embodiment, the data transmission task result completed by the data transmission and execution module will be used as the input of the data consistency verification module. Generally, this module will output the following key data: Hash values ​​of all transferred data blocks; Transmission status statistics (such as bandwidth utilization, packet loss rate, etc.).

[0140] The above data will be directly used for the next step of consistency verification to ensure the accuracy and completeness of data recovery.

[0141] In summary, the data transmission and execution module of the present invention realizes the efficient execution of data recovery tasks through technical means such as block transmission, redundant coding, multi-path parallel and dynamic priority adjustment. The module can dynamically adapt to the state changes of normal nodes in a complex network environment to ensure the efficiency and stability of the transmission task. At the same time, by working in coordination with the dynamic adjustment and optimization module, the robustness of the recovery process is further improved, providing a strong guarantee for the data recovery of the target node.

[0142] The data consistency check module is used to perform consistency check on the data received after the target node is restored, verify the integrity of the target node data and ensure that the target node status is consistent with the normal node.

[0143] In this embodiment, after receiving the output result of the data transmission and execution module, the data consistency check module will first calculate the hash value of all the transmitted data blocks. Generate hash value , and its calculation formula is:

[0144] in: Represents a data block Hash value Represents a hash function, such as SHA-256.

[0145] For the hash values ​​of all data blocks, this module will organize them into leaf nodes of the Merkle tree and calculate and generate the Merkle root layer by layer. Specifically, the hash value of a parent node is calculated from the hash values ​​of its child nodes:

[0146] in: is the hash value of the parent node; and are the hash values ​​of the left and right child nodes respectively; Represents a string concatenation operation.

[0147] Finally, the module generates a Merkle root Will be compared with the root hash value in the whole network state tree When the following conditions are met, the data consistency check is considered to have passed:

[0148] As an option, the module supports rollback and retransmission of lost or erroneous data blocks during the consistency check. When the value does not match the corresponding value in the network status tree, the module will record the identifier of the data block and calculate the amount of data that needs to be retransmitted using the following formula:

[0149] in: Indicates the total amount of data that needs to be retransmitted; Represents a data block An indicator variable indicating whether retransmission is required, with a value of 0 or 1; The size of the data block.

[0150] The module will Pass it back to the data transmission and execution module to start the retransmission process until the hash value verification of all data blocks passes.

[0151] Specifically, in some embodiments, the data consistency check module supports verifying data integrity by combining redundant coding technology. When part of the data block is lost or damaged, the module can decode the remaining redundant data to restore the original data. The module can recover the original data through the following linear algebraic equations:

[0152] in: Generate matrix for encoding; is the original data block to be restored; The received redundant data.

[0153] By solving the above equations, the module can compensate for the packet loss problem in data transmission to a certain extent.

[0154] In one possible implementation, the module supports multi-level optimization of data verification. In general, the module adjusts the verification priority according to the importance of the data. For example, for the latest block data, the module will prioritize the verification of its hash value to ensure that the recovery node can participate in the latest consensus process in a timely manner. For historical block data, the module can use batch verification to reduce the computational burden of a single verification.

[0155] In this embodiment, the data consistency check module also supports comprehensive statistics and output of transmission results. The module will record the following key check information: The total number of verified data blocks ; The number of data blocks that have passed verification ; The number of data blocks that failed verification ; The identifier of the specific data block that failed the verification.

[0156] The above information will serve as the basis for the recovery node to re-participate in the consensus and will be notified to the entire network through broadcasting to ensure the credibility of data consistency.

[0157] In summary, the data consistency verification module of the present invention can efficiently verify the data consistency of the target node by combining Merkle tree hash verification, redundant coding recovery and multi-level verification optimization. The verification result of the module not only ensures the integrity of the recovered data of the target node, but also provides a reliable basis for its re-participation in the blockchain consensus. At the same time, the module further enhances the fault tolerance and robustness of the data recovery process through linkage with the data transmission and execution module, thereby providing a guarantee for the efficient operation of the blockchain network.

[0158] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A blockchain node failure recovery method, characterized in that: The following steps are involved: S1. Detect the fault status of the blockchain node through the fault detection and notification module, determine whether the target node needs to be restored, and broadcast a recovery request; S2. Generate an initial probability distribution and determine the data allocation strategy for normal nodes through a recovery strategy generation module based on the recovery requirements of the target node and the bandwidth and load status of normal nodes; S3. According to the response status of normal nodes, the probability distribution is adjusted through the dynamic adjustment and optimization module to optimize the allocation of data requests and dynamically adjust the participation probability of normal nodes; S4. Send data requests to normal nodes according to the adjusted probability distribution through the data transmission and execution module to perform data transmission and recovery operations; S5. Perform consistency check on the transmitted data through the data consistency check module to verify the data integrity of the target node and ensure that the state of the target node is consistent with other normal nodes; S6. When the target node data is verified, it rejoins the blockchain network to participate in the consensus.

2. A blockchain node failure recovery method according to claim 1, characterized in that: In S2, the initial probability distribution is generated by the real-time bandwidth of the normal nodes. The initial probability distribution is allocated according to the ratio of the bandwidth of each normal node to the total bandwidth of the normal node set. The probability of the normal node is the bandwidth of the node divided by the total bandwidth.

3. A blockchain node failure recovery method according to claim 1, characterized in that: In S3, the probability distribution is adjusted by combining the participation cost-effectiveness of normal nodes through a dynamic adjustment and optimization module. The cost-effectiveness is the ratio of the participation reward of the node to the sum of the bandwidth cost and the load cost of the node. The probability distribution of the node is dynamically increased or decreased according to the cost-effectiveness.

4. A blockchain node failure recovery method according to claim 1, characterized in that: In S5, the consistency check verifies the data integrity through the blockchain status tree, including calculating the hash value of the data provided by each normal node and comparing it with the blockchain status tree. When the hash values ​​of all data blocks match, it is determined that the target node has been successfully recovered.

5. A blockchain node fault recovery system, according to a blockchain node fault recovery method according to any one of claims 1-4, characterized in that: include: Fault detection and notification module, recovery strategy generation module, dynamic adjustment and optimization module, data transmission and execution module and data consistency verification module, among which: The fault detection and notification module is used to detect the fault status of the target node, determine whether the target node needs to be restored, and send a restoration request to the normal node set; The recovery strategy generation module is used to generate an initial probability distribution based on the recovery requirements of the target node and the bandwidth and load status of the normal nodes, and determine the data allocation strategy of the normal nodes; The dynamic adjustment and optimization module is used to dynamically adjust the probability distribution according to the real-time response status of the normal nodes to optimize the data allocation strategy; The data transmission and execution module is used to send data requests to normal nodes according to the adjusted probability distribution and perform data transmission operations; The data consistency check module is used to perform consistency check on the data received after the target node is restored, verify the integrity of the target node data and ensure that the state of the target node is consistent with that of a normal node.

6. A blockchain node fault recovery system according to claim 1, characterized in that: The recovery strategy generation module includes a maximum entropy optimization unit, which is used to make the allocation probability of all normal nodes satisfy the maximum entropy distribution when generating the initial probability distribution, so as to ensure the balance of data requests.

7. A blockchain node fault recovery system according to claim 1, characterized in that: The dynamic adjustment and optimization module includes a feedback adjustment unit, which adjusts the probability distribution in real time according to the bandwidth change, load change and response cost performance of the normal nodes, and dynamically optimizes the data request allocation strategy of the recovery node.

8. A blockchain node fault recovery system according to claim 1, characterized in that: The data transmission and execution module includes a multi-path parallel transmission unit, which is used to split the data request of the target node and distribute the data transmission task to multiple normal nodes for parallel processing.

9. A blockchain node failure recovery system according to claim 1, characterized in that: The data consistency verification module includes a hash verification unit, which calculates the hash value of the data transmitted by each normal node and compares it with the hash value stored in the blockchain status tree to ensure the integrity and consistency of the data restored by the target node.

10. A blockchain node fault recovery system according to claim, characterized in that: The fault detection and notification module detects the running status of the target node by sending heartbeat messages regularly. When the target node does not respond for a long time, a fault determination is triggered and a recovery process is started.

Images