A method and system for detecting blockchain node failures

Abstract

This invention relates to the field of blockchain technology, and in particular to a blockchain node fault detection method and system, comprising: S1: real-time collection of raw operating data of each node in the blockchain network; S2: extraction of feature data from the raw operating data; S3: combining the feature data and using a consensus node mechanism to determine whether each node has a fault, and issuing an alarm if so; S4: analysis of multi-dimensional data at the time of the fault and repair of the blockchain. This invention solves the problem of insufficient universality in node fault detection methods by constructing a fault detection mechanism using a fusion of PBFT and PoS consensus algorithms, ensuring the stable operation of the blockchain network and improving the reliability of the entire blockchain system in the face of various complex operating environments and potential fault risks.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a blockchain node fault detection method and a blockchain node fault detection system. Background Technology

[0002] Blockchain technology, as the core of distributed ledger technology, has been widely applied in many fields such as finance, supply chain, and the Internet of Things. A blockchain consists of multiple nodes, and the stable operation of these nodes is crucial to the reliability and security of the blockchain system.

[0003] With the widespread application of blockchain technology in numerous fields such as finance, supply chain, and digital copyright, the scale and complexity of blockchain networks are constantly increasing. Blockchain networks rely on numerous nodes to jointly maintain the consistency and integrity of the ledger. However, in actual operation, nodes may fail due to various reasons such as hardware malfunctions, network problems, and software vulnerabilities. If node failures are not detected and addressed in a timely manner, it may lead to problems such as transaction processing delays, data inconsistencies, or even partial functional paralysis of the blockchain network, seriously affecting the reliability and availability of the blockchain system.

[0004] Node failures are frequent due to factors such as complex network environments, hardware malfunctions, and software vulnerabilities. Once a node fails, it can lead to data inconsistencies, transaction delays, or even system paralysis, severely impacting the normal operation of the blockchain system. Existing node failure detection methods often suffer from insufficient universality, low timeliness and accuracy, and a lack of systematic guidance for blockchain failure repair. These methods fail to meet the stringent requirements of blockchain systems for node stability and reliability, and the demand for accurate and rapid node failure detection in increasingly complex blockchain network environments. Therefore, a more effective blockchain node failure detection method is urgently needed to address these issues. Summary of the Invention

[0005] This invention provides a blockchain node fault detection method and system to address the problems of insufficient universality, low timeliness and accuracy of fault detection, and lack of systematic guidance for blockchain fault repair in existing node fault detection methods.

[0006] This invention provides a blockchain node fault detection method system, comprising:

[0007] S1: Real-time collection of raw operational data from each node in the blockchain network.

[0008] S2: Extract feature data from the raw runtime data.

[0009] S3: Combining feature data, use the consensus node mechanism to determine whether each node is faulty, and if so, issue an alarm.

[0010] S31: Extract the common forms related to fault detection from the PBFT and PoS fusion consensus algorithms, and construct a general detection framework based on the common forms.

[0011] S32: Design a unified data input interface and summarize the general pattern of PBFT and PoS fusion consensus algorithm in fault detection.

[0012] S33: Modifications were made to the data generation and transmission parts of the fusion consensus algorithm by simplifying the data structure, optimizing data encoding, reducing the number of message interactions, and improving the data transmission protocol. Parallel processing, asynchronous operations, and logical simplification were employed to adjust the internal logic of the fusion consensus algorithm, resulting in an optimized PBFT and PoS fusion consensus algorithm.

[0013] S34: Apply the optimized PBFT and PoS fusion consensus algorithm and general detection framework to the blockchain network to obtain fault detection results in a unified output format.

[0014] S4: Analyze multi-dimensional data at the time of the failure and repair the blockchain.

[0015] According to the blockchain node fault detection method provided by the present invention, in step S1, the original operating data includes: actual behavior time obtained from various operation logs recorded by the blockchain node, network connection data obtained from network monitoring software, hardware resource data obtained from connection statistics of network monitoring software, and blockchain business data obtained from blockchain monitoring platform.

[0016] According to the blockchain node fault detection method provided by the present invention, in step S2, feature extraction of the original operating data includes:

[0017] Feature data includes: the mean and variance of CPU utilization over consecutive periods, and the timing and magnitude of bandwidth peaks.

[0018] The formula for calculating CPU utilization variance is:

[0019]

[0020] In the formula, s 2 Let x be the variance, n be the sample size, and x be the variance. i Let i be the value of the i-th sample data. This is the sample mean.

[0021] According to the blockchain node fault detection method provided by the present invention, in step S31, the PBFT and PoS fusion consensus algorithm includes:

[0022] The underlying layer uses the PoS consensus algorithm to handle daily transactions, while the top layer uses the PBFT consensus algorithm to handle operations involving asset transfers.

[0023] The consensus protocol switch is triggered by marking the transaction type through contract metadata. Dual-channel communication is established between nodes. Routine transactions go through the PoS channel, while critical transactions are automatically routed to the PBFT channel.

[0024] PBFT blocks are verified by random sampling from PoS nodes.

[0025] According to a blockchain node fault detection method provided by the present invention, in step S31, extracting the same form related to fault detection includes:

[0026] Node behavioral characteristics include the time of participation in consensus, the completeness of participation in consensus operations, and the consistency of operation results.

[0027] Time constraint characteristics: longest response time, consensus cycle duration.

[0028] Data interaction characteristics: message sending frequency and message loss rate.

[0029] Resource usage characteristics: CPU utilization, memory utilization.

[0030] According to the blockchain node fault detection method provided by the present invention, the specific steps for constructing a general detection framework in step S32 are as follows:

[0031] S321: Based on the same format, use the data acquisition model to obtain node operation data from the operating environment, and organize and store the node operation data in a unified format.

[0032] S322: Using node operation data as input, a unified time threshold is set for the PBFT and PoS fusion consensus algorithm based on the time monitoring model.

[0033] S323: Determine whether the actual behavior time exceeds the preset time threshold. If so, it is determined to be an abnormal situation, and an abnormal behavior record containing the abnormal node identifier and abnormal time is generated.

[0034] S324: Abnormal behavior records are processed through interface conversion and result output model to obtain a general detection framework.

[0035] According to the blockchain node fault detection method provided by the present invention, the specific steps of optimizing the consensus algorithm in step S33 are as follows:

[0036] S331: The message passing path of the PBFT and PoS converged consensus algorithm is simplified by using two-stage merging and weighted stake broadcasting. The verification method of the PBFT and PoS converged consensus algorithm is simplified by using threshold signature and dynamic stake snapshot, resulting in a simplified message passing path and verification method.

[0037] S332: Based on simplifying the message passing path and verification method, the consensus operation when a node receives a new block is redesigned using parallel computing and asynchronous processing techniques, resulting in an optimized PBFT and PoS fusion consensus algorithm.

[0038] According to a blockchain node fault detection method provided by the present invention, in step S34, the optimized PBFT and PoS fusion consensus algorithm and general detection framework are applied to the blockchain network by integrating the optimized PBFT and PoS fusion consensus algorithm and general detection framework into each node of the blockchain network, and re-updating and configuring the node software. The optimized PBFT and PoS fusion consensus algorithm processes transactions and reaches consensus, while simultaneously transmitting the node's operating data to the general detection framework in real time.

[0039] According to a blockchain node fault detection method provided by the present invention, in step S4, blockchain repair includes:

[0040] Node software repair: For configuration errors, readjust parameters according to the blockchain network configuration specifications and node functional requirements. When versions are incompatible, upgrade the software to a version compatible with other nodes in the network.

[0041] Network connectivity repair: When IP address conflicts occur, unused IP addresses are reallocated. When network congestion occurs, network equipment is upgraded and network topology is optimized.

[0042] Data consistency repair: Use blockchain data synchronization tools to compare the data of the faulty node with that of other normal nodes and correct the erroneous data.

[0043] Hardware repair: After a comprehensive inspection of the faulty node hardware using hardware testing tools, the hardware is replaced, the operating system and blockchain-related software are reinstalled, the environment is configured, and performance testing is performed.

[0044] A blockchain node fault detection system provided by the present invention includes:

[0045] The data acquisition module is used to collect the operational data of each node in the blockchain network in real time to obtain the raw operational data.

[0046] The feature extraction module is used to extract features from the raw running data to obtain feature data.

[0047] The fault detection module uses a consensus node mechanism, combined with feature data, to determine whether a node is faulty.

[0048] The fault diagnosis module allows staff to review multi-dimensional data at the time of the fault and repair the blockchain after receiving a fault alarm.

[0049] This invention provides a blockchain node fault detection method and system. By employing a fusion of PBFT and PoS consensus algorithms to construct a fault detection mechanism, it solves the problems of insufficient universality, low timeliness and accuracy of fault detection methods, and lack of systematic guidance for blockchain fault repair. The beneficial effects achieved are as follows:

[0050] This invention employs a fusion of PBFT and PoS consensus algorithms to construct a fault detection mechanism, combining the advantages of both algorithms. Furthermore, the process involves extracting common forms, constructing a general detection framework, and optimizing the consensus algorithm, making the method both versatile and professional.

[0051] This invention, through an accurate and timely fault detection mechanism coupled with a comprehensive repair process, enables the rapid detection and proper handling of node faults in blockchain networks. This minimizes network instability and data inconsistencies caused by node failures, ensuring the stable operation of the blockchain network and improving the reliability of the entire blockchain system in the face of various complex operating environments and potential fault risks. Furthermore, the constructed general detection framework and optimized adaptation to the fusion consensus algorithm make this fault detection method applicable not only to the current PBFT and PoS fusion scenarios but also provide a reusable framework and approach for fault detection when introducing other consensus algorithms or further expanding blockchain application scenarios and adjusting network architecture. This facilitates system expansion and upgrades, and reduces development and maintenance costs.

[0052] This invention employs clear and explicit fault detection and repair steps, enabling maintenance personnel to quickly learn and operate the system. When faced with a fault, they can rapidly locate the problem and take appropriate corrective measures, reducing troubleshooting and repair time, improving the overall operational efficiency of the blockchain network, and ensuring continuous business operations. By proactively detecting blockchain node faults, the timeliness of fault discovery is improved, reducing the impact of faults on the normal operation of the blockchain system. Accurate fault cause identification assists maintenance personnel in quickly locating the problem, improving operational efficiency, reducing business downtime caused by lengthy fault investigation, ensuring the stable and reliable operation of the blockchain system, and guaranteeing the consistency and reliability of the detection results. Attached Figure Description

[0053] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0054] Figure 1 This is a flowchart of a blockchain node fault detection method provided in an embodiment of the present invention;

[0055] Figure 2 This is a flowchart illustrating a blockchain node fault detection method based on an embodiment of the present invention, which uses a consensus node mechanism to determine node faults.

[0056] Figure 3 This is a module of a blockchain node fault detection system provided in an embodiment of the present invention. Detailed Implementation

[0057] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0058] Example 1

[0059] like Figure 1 As shown in the figure, an embodiment of the present invention provides a blockchain node fault detection method, including:

[0060] S1: Real-time collection of raw operational data from each node in the blockchain network.

[0061] The actual time of the action is obtained from various operation logs recorded by blockchain nodes. In a blockchain system, nodes record every key operation in detail, and these records usually include timestamps accurate to milliseconds or even higher.

[0062] Network connection data is obtained from network monitoring software. Within the operating system environment, command-line tools are used to obtain relevant data about network interfaces to calculate network bandwidth.

[0063] Hardware resource data obtained through connection statistics from network monitoring software.

[0064] Blockchain business data is obtained from a blockchain monitoring platform. Blockchain nodes record the processing of each transaction in detail, including key node information such as transaction reception time, verification start time, verification completion time, and time of being packaged into a block. By analyzing transaction records, the number of successfully processed transactions is counted within a set time interval. This number is then divided by the corresponding number of seconds to obtain the number of transactions processed per second.

[0065] S2: Extract feature data from the raw runtime data.

[0066] The collected raw operational data is transmitted to the feature extraction module, which uses singular value decomposition, wavelet transform, principal component analysis, and rule-based extraction to extract key features. The stability of CPU utilization is measured by calculating the mean and variance of CPU utilization over multiple consecutive acquisition periods. Features such as the timing and magnitude of bandwidth peaks are extracted from the fluctuation curve of network bandwidth usage. These features more intuitively reflect changes in the node's operational status, providing a basis for subsequent fault diagnosis.

[0067] The formula for calculating CPU utilization variance is:

[0068]

[0069] In the formula, s 2 Let x be the variance, n be the sample size, and x be the variance. i Let i be the value of the i-th sample data. This is the sample mean.

[0070] S3: Combining feature data with the consensus node mechanism, determine whether a node is faulty. If so, issue an alarm; otherwise, leave it unchanged. The consensus node mechanism is closely integrated with the core operating mechanism of the blockchain, has relatively high accuracy, and can detect abnormal situations in the node's participation in the consensus process.

[0071] like Figure 2 As shown, the consensus node mechanism specifically includes:

[0072] S31: Extract the common forms related to fault detection from the PBFT (Practical Byzantine Fault Tolerance) and PoS (Proof-of-Stake) fusion consensus algorithm. Conduct in-depth research on various mainstream consensus algorithms, such as PoW, PoS, and PBFT, analyzing their commonalities in fault detection. Use the PoS and PBFT fusion consensus algorithm to locate worker nodes, combining the strong consistency of PBFT and the efficiency of PoS, applicable to different transaction scenarios, significantly shortening the fault node location time. Determine the key information of node behavior records and the universal standard for time constraints. Based on these commonalities, design a unified interface specification to ensure that different consensus algorithms can interact with the framework. In PoW, nodes need to continuously calculate hash values ​​to compete for the right to record transactions; normal nodes will periodically submit valid proofs of work. If a fault occurs, it may be unable to submit proofs for a long time. In PoS, nodes participate in consensus based on their stake; under normal circumstances, they will participate in voting or verification according to the stipulated time. Faulty nodes may miss the voting time or provide incorrect verification results.

[0073] Extracting the same forms related to fault detection includes: node behavior features, time constraint features, data interaction features, and resource usage features.

[0074] Node behavior characteristics include the time of participation in consensus, the completeness of participation in consensus operations, and the consistency of operation results.

[0075] Completeness of Consensus Participation: In both PBFT and PoS, nodes must participate in the consensus process according to specific rules. In PBFT, nodes go through pre-preparation, preparation, and confirmation phases. In PoS, nodes must participate in voting or verification operations. If a node omits or fails to complete these operations—for example, a PBFT node fails to complete the confirmation phase, or a PoS node fails to vote—it may indicate a node failure.

[0076] Consistency of operation results: Under normal circumstances, different nodes should process the same data in the same way. In PBFT, all honest nodes should verify the same block. In PoS, nodes should also verify the same transaction. If a node's operation result differs from that of the majority of other nodes, a failure may exist.

[0077] The time constraints include the longest response time and the consensus cycle duration.

[0078] Response Time: Both algorithms have requirements on node response time. In PBFT, nodes need to respond to messages within a specified time. In PoS, there are also time limits for nodes participating in voting or validation. If a node's response time exceeds the threshold, it may be due to network latency, insufficient node processing capacity, or a malfunction.

[0079] Consensus Cycle Time: Both PBFT and PoS have their own consensus cycles. Within a consensus cycle, nodes need to complete the corresponding operations. If a node fails to complete its tasks on time within multiple consensus cycles, a failure may occur.

[0080] Data interaction characteristics include message sending frequency and message loss rate.

[0081] Message sending frequency: Nodes need to interact with other nodes during the consensus process. Under normal circumstances, the message sending frequency of a node should be relatively stable. If the message sending frequency of a node suddenly becomes too high or too low, it may indicate that the node is malfunctioning.

[0082] Message loss rate: Message loss is a common problem during data exchange. However, if the message loss rate of a certain node is significantly higher than that of other nodes, it may be due to an unstable network connection or a software failure on that node.

[0083] Resource usage characteristics include CPU utilization and memory utilization.

[0084] CPU utilization: Nodes consume CPU resources when performing consensus operations. If a node's CPU utilization remains consistently high or low, it may indicate a fault in the node. High utilization may suggest the node is performing abnormal computations, while low utilization may indicate the node is not participating properly in consensus.

[0085] Memory usage: Memory is a critical resource for node operation. If a node's memory usage is abnormal, such as consistently high or fluctuating significantly, it may affect the normal operation of the node and lead to failure.

[0086] S32: Design a unified data input interface, summarize the general pattern of PBFT and PoS fusion consensus algorithm in fault detection, and build a general detection framework based on the same form.

[0087] Given that consensus detection mechanisms rely on specific algorithms and exhibit significant differences in detection logic, different consensus algorithms, while differing in details regarding the determination of whether a node is participating correctly, all involve recording node behavior and adhering to time constraints. Based on these commonalities, a standard behavior recording module and a time monitoring module can be designed. The behavior recording module is responsible for uniformly collecting and organizing various operations performed by nodes during the consensus process, while the time monitoring module sets and checks time thresholds according to a unified standard. In this way, regardless of the consensus algorithm used, all nodes can be integrated into this framework for fault detection, reducing dependence on specific algorithms and improving the universality of the detection process.

[0088] S321: Based on the same format, use the data acquisition model to obtain node operation data from the operating environment, and organize and store the node operation data in a unified format.

[0089] S322: Using node operation data as input, a unified time threshold is set for the PBFT and PoS fusion consensus algorithm based on the time monitoring model.

[0090] S323: Develop a time monitoring module based on common time constraint standards. Determine whether the actual behavior time exceeds a preset time threshold. If so, it is judged as an abnormal situation, and an abnormal behavior record containing an abnormal node identifier and abnormal time is generated.

[0091] S324: Abnormal behavior records are processed through interface conversion and result output model to obtain a general detection framework.

[0092] S33: Modify the data generation and transmission parts of the fusion consensus algorithm, adjust the internal logic of the fusion consensus algorithm, and obtain an optimized PBFT and PoS fusion consensus algorithm. Specifically, this includes:

[0093] S331: The message passing path of the PBFT and PoS converged consensus algorithm is simplified by using two-stage merging and weighted stake broadcasting. The verification method of the PBFT and PoS converged consensus algorithm is simplified by using threshold signatures and dynamic stake snapshots, resulting in a simplified message passing path and verification method. This reduces unnecessary redundant message passing between nodes, optimizes message verification logic, and uses threshold signature verification or merges some verification steps, thereby reducing the number of messages and processing steps required to confirm node status and lowering the algorithm's complexity.

[0094] Optimize message delivery paths: Design a simpler message delivery strategy. This can reduce the number of message rounds by using a two-phase merging approach, combining the pre-preparation and preparation phases into one. The master node directly sends a merged message containing more information to the slave nodes, reducing the number of interactions between nodes. Optimize message broadcasting by employing weighted broadcast, using more efficient multicast or broadcast protocols to ensure messages reach all nodes quickly and accurately. Utilize a network layered structure to group nodes; messages are first broadcast within a group and then transmitted between groups, reducing the scope and time of message propagation.

[0095] The threshold signature method simplifies node verification. Unnecessary verification content is removed, or the verification order and logic are adjusted. For example, for signature verification, a more efficient signature algorithm can be used to reduce the computational load required for signature verification. For message consistency verification, data structures such as hash trees can be used to quickly compare the overall hash value of the message, rather than checking each field of the message one by one, thus improving verification efficiency. Dynamic stake snapshots are used to freeze the node stake state during the consensus period, avoiding the additional communication overhead of real-time stake calculation.

[0096] S332: Based on simplifying the message passing path and verification method, the consensus operation when a node receives a new block is redesigned using parallel computing and asynchronous processing techniques, resulting in an optimized PBFT and PoS fusion consensus algorithm.

[0097] Parallel computing design: When a node verifies a new block, the block data is divided into multiple parts. Parallel computing technology allows multiple computing cores on the node to simultaneously handle the transaction and data verification tasks for different parts. A block containing a large number of transactions is divided according to transaction type or account address. Each computing core is responsible for verifying the legality of a portion of the transactions, including checking transaction signatures and whether the account balance is sufficient. In this way, the verification time of a single block is greatly reduced.

[0098] Asynchronous processing implementation: Determine which operations can be executed asynchronously. For auxiliary operations that do not affect consensus, such as recording transaction logs and updating local state, set them as asynchronous tasks. When a node receives a new block, while performing the main verification and consensus operations, these auxiliary operations are placed in an asynchronous task queue and processed in the background by a dedicated thread or process. This allows the node to continue the subsequent consensus process without waiting for these auxiliary operations to complete, improving overall processing efficiency.

[0099] The architecture uses a PBFT (Practical Byzantine Fault Tolerance) and PoS convergence to ensure strong consistency during critical transaction verification phases, while PoS is used for daily transactions to improve efficiency.

[0100] The underlying layer uses PoS consensus to handle daily transactions, and nodes obtain the right to record transactions by staking tokens. Block generation speed can reach the second level. The top layer uses PBFT consensus to handle sensitive operations involving asset transfers, and strong consistency is ensured through three-stage voting.

[0101] Developers can mark transaction types through contract metadata to trigger consensus protocol switching. Dynamic channel allocation: Nodes establish dual-channel communication; routine transactions use the PoS channel, while critical transactions are automatically routed to the PBFT channel.

[0102] PBFT blocks require random sampling verification by PoS nodes to prevent collusion among PBFT nodes. A node's performance in both protocols is factored into its reputation score, affecting its future block priority. This is based on a node's historical behavior, such as double-signature records and response latency, resulting in a credit score.

[0103] S34: Apply the optimized PBFT and PoS fusion consensus algorithm and general detection framework to the blockchain network to obtain fault detection results in a unified output format.

[0104] S341: Integrate the optimized PBFT and PoS converged consensus algorithm and general detection framework into each node of the blockchain network. Update and configure the node software to ensure the converged consensus algorithm and framework function correctly on the nodes. During integration, ensure the algorithm accurately provides the framework with node behavior data during the consensus process, following the unified interface specification of the general detection framework.

[0105] S342: During the operation of the blockchain network, an optimized PBFT and PoS fusion consensus algorithm processes transactions and reaches consensus, while simultaneously transmitting node operational data to a general detection framework in real time. The general detection framework determines whether the actual behavior of nodes is abnormal based on preset time thresholds, and detects the communication status of nodes by analyzing data such as message sending frequency and message loss rate.

[0106] S343: The general detection framework determines whether a node is faulty based on the analysis results. If so, it generates fault detection results in a unified format.

[0107] S4: After receiving a fault alarm, staff can use the fault diagnosis function to view multi-dimensional data at the time of the fault.

[0108] Node software repair: Node failures may stem from software vulnerabilities, configuration errors, or version incompatibility. Staff first check the software logs of the malfunctioning node. If software vulnerabilities are found, patches are promptly obtained from official software channels and installed. For configuration errors, parameters are readjusted according to blockchain network configuration specifications and node functional requirements. If version incompatibility is the issue, the software is upgraded to a version compatible with other nodes in the network. After the upgrade, compatibility testing is performed to ensure the software functions correctly.

[0109] Network connectivity repair: Network problems can cause node failures. Staff use network testing tools to check the network connectivity of the faulty node. If IP address conflicts are found, unused IP addresses are reassigned. When network congestion occurs, network equipment is upgraded, network topology is optimized, or network bandwidth allocation is adjusted. If network equipment hardware fails, such as a damaged network cable or a faulty network card, the faulty equipment is replaced, and the network connection stability and speed are tested after repair.

[0110] Data consistency repair: Inconsistent node data can affect the normal operation of the blockchain. Staff use blockchain data synchronization tools to compare the data of faulty nodes with that of other healthy nodes to identify discrepancies. If data is missing, complete data is synchronized from other nodes. When data errors occur, the erroneous data is corrected according to the blockchain consensus mechanism and data verification rules. During the data repair process, temporary isolation measures are taken to prevent the spread of erroneous data, and data consistency is checked again after the repair is complete.

[0111] Hardware Repair: Hardware failure is also a cause of node failure. Staff use hardware testing tools to perform a comprehensive check on the faulty node's hardware. If the memory is faulty, the faulty memory module is replaced. If the hard drive is faulty, important data is backed up, the hard drive is replaced, and the data is restored. If the CPU is faulty, the faulty CPU is replaced. After hardware replacement, the operating system and blockchain-related software are reinstalled, the environment is configured, and performance tests are performed to ensure stable hardware operation.

[0112] This invention provides a blockchain node fault detection method and system. By employing a fusion of PBFT and PoS consensus algorithms to construct a fault detection mechanism, it solves the problems of insufficient universality, low timeliness and accuracy of fault detection methods, and lack of systematic guidance for blockchain fault repair. The beneficial effects achieved are as follows:

[0113] The fault detection mechanism is constructed by integrating the consensus algorithms PBFT and PoS, which combine the advantages of both algorithms. The process involves extracting common forms, constructing a general detection framework, and optimizing the consensus algorithm, making the method both universal and professional.

[0114] This invention's accurate and timely fault detection mechanism, coupled with a comprehensive repair process, enables the rapid discovery and proper handling of node faults in the blockchain network. This minimizes network instability and data inconsistency caused by node failures, ensuring the stable operation of the blockchain network and improving the reliability of the entire blockchain system in the face of various complex operating environments and potential fault risks. The constructed general detection framework and optimized adaptation to the fusion consensus algorithm make this fault detection method applicable not only to the current PBFT and PoS fusion scenarios but also provide a reusable basic framework and approach for fault detection when introducing other consensus algorithms or further expanding blockchain application scenarios and adjusting network architecture. This facilitates system expansion and upgrades, and reduces development and maintenance costs.

[0115] Example 2

[0116] like Figure 3 As shown, this embodiment provides a blockchain node fault detection system, which can adopt a blockchain node fault detection method of embodiment 1. The fault detection system includes:

[0117] The data acquisition module is used to collect the operational data of each node in the blockchain network in real time to obtain the raw operational data.

[0118] The feature extraction module is used to extract features from the raw running data to obtain feature data.

[0119] The fault detection module uses a consensus node mechanism, combined with feature data, to determine whether a node is faulty.

[0120] The fault diagnosis module allows staff to review multi-dimensional data at the time of the fault and repair the blockchain after receiving a fault alarm.

[0121] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, 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 can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0122] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for detecting blockchain node failures, characterized in that, include: S1: Real-time collection of raw operational data from each node in the blockchain network; S2: Extract feature data from the original operating data; S3: Combining the aforementioned feature data, use the consensus node mechanism to determine whether each node is faulty; if so, issue an alarm. S31: Extract the common forms related to fault detection from the PBFT and PoS fusion consensus algorithms, and construct a general detection framework based on the common forms; S32: Design a unified data input interface and summarize the general pattern of PBFT and PoS fusion consensus algorithm in fault detection; S33: Modify the data generation and transmission parts of the fusion consensus algorithm by simplifying the data structure, optimizing data encoding, reducing the number of message interactions, and improving the data transmission protocol; adopt parallel processing, asynchronous operation, and logic simplification to adjust the internal logic of the fusion consensus algorithm and obtain the optimized PBFT and PoS fusion consensus algorithm; S331: The message passing path of the PBFT and PoS converged consensus algorithm is simplified by using two-stage merging and weighted stake broadcasting. The verification method of the PBFT and PoS converged consensus algorithm is simplified by using threshold signature and dynamic stake snapshot, resulting in a simplified message passing path and verification method. S332: Based on the simplified message passing path and verification method, the consensus operation when a node receives a new block is redesigned using parallel computing and asynchronous processing techniques, resulting in an optimized PBFT and PoS fusion consensus algorithm; S34: Apply the optimized PBFT and PoS fusion consensus algorithm and general detection framework to the blockchain network to obtain fault detection results in a unified output format; S4: Analyze multi-dimensional data at the time of the failure and repair the blockchain.

2. The blockchain node fault detection method according to claim 1, characterized in that, In step S1, the raw operating data includes: actual behavior time obtained from various operation logs recorded by blockchain nodes, network connection data obtained from network monitoring software, hardware resource data obtained from connection statistics of network monitoring software, and blockchain business data obtained from blockchain monitoring platform.

3. The blockchain node fault detection method according to claim 1, characterized in that, In step S2, feature extraction of the raw running data includes: Feature data includes: the mean and variance of CPU utilization over consecutive periods, and the timing and magnitude of bandwidth peaks. The formula for calculating CPU utilization variance is: ； In the formula, s 2 Let x be the variance, n be the sample size, and x be the variance. i Let i be the value of the i-th sample data. This is the sample mean.

4. The blockchain node fault detection method according to claim 1, characterized in that, In step S31, the PBFT and PoS fusion consensus algorithm includes: The underlying layer uses the PoS consensus algorithm to handle daily transactions, while the top layer uses the PBFT consensus algorithm to handle operations involving asset transfers. The consensus protocol switch is triggered by marking the transaction type through contract metadata. Dual-channel communication is established between nodes. Routine transactions go through the PoS channel, while critical transactions are automatically routed to the PBFT channel. PBFT blocks are verified by random sampling from PoS nodes.

5. The blockchain node fault detection method according to claim 1, characterized in that, In step S31, extracting the same forms related to fault detection includes: Node behavioral characteristics include the time of participation in consensus, the completeness of consensus operations, and the consistency of operation results; Time constraint characteristics: longest response time, consensus cycle duration; Data interaction characteristics: message sending frequency, message loss rate; Resource usage characteristics: CPU utilization, memory utilization.

6. The blockchain node fault detection method according to claim 4, characterized in that, In step S32, the specific steps for constructing the general detection framework are as follows: S321: According to the same form, use the data acquisition model to obtain node operation data from the operating environment, and organize and store the node operation data in a unified format. S322: Using the node operation data as input, set a unified time threshold for the PBFT and PoS fusion consensus algorithm based on the time monitoring model; S323: Determine whether the actual behavior time exceeds the preset time threshold. If so, it is determined to be an abnormal situation, and an abnormal behavior record containing the abnormal node identifier and abnormal time is generated. S324: The abnormal behavior records are processed through interface conversion and result output model to obtain a general detection framework.

7. The blockchain node fault detection method according to claim 1, characterized in that, In step S34, the optimized PBFT and PoS fusion consensus algorithm and general detection framework are applied to the blockchain network as follows: the optimized PBFT and PoS fusion consensus algorithm and general detection framework are integrated into each node of the blockchain network, and the node software is re-updated and reconfigured; the optimized PBFT and PoS fusion consensus algorithm processes transactions and reaches consensus, while transmitting the node's operating data to the general detection framework in real time.

8. The blockchain node fault detection method according to claim 1, characterized in that, In step S4, the blockchain repair includes: Node software repair: For configuration errors, readjust parameters according to the blockchain network configuration specifications and node functional requirements; when versions are incompatible, upgrade the software to a version that matches other nodes in the network; Network connectivity repair: When IP address conflicts occur, unused IP addresses are reallocated; when network congestion occurs, network equipment is upgraded and network topology is optimized. Data consistency repair: Use blockchain data synchronization tools to compare the data of the faulty node with that of other normal nodes and correct the erroneous data; Hardware repair: After a comprehensive inspection of the faulty node hardware using hardware testing tools, the hardware is replaced, the operating system and blockchain-related software are reinstalled, the environment is configured, and performance testing is performed.

9. A blockchain node fault detection system, which employs a blockchain node fault detection method as described in any one of claims 1 to 8, characterized in that, The fault detection system includes: The data acquisition module is used to collect the operational data of each node in the blockchain network in real time to obtain the raw operational data; The feature extraction module is used to extract features from the original running data to obtain feature data; The fault detection module uses a consensus node mechanism to determine whether a node is faulty, based on the aforementioned feature data. The fault diagnosis module allows staff to review multi-dimensional data at the time of the fault and repair the blockchain after receiving a fault alarm.

Images