Blockchain node adaptive synchronization fault recovery method and system based on ai prediction

Abstract

The application relates to a blockchain node adaptive synchronization fault recovery method and system based on AI prediction. A multi-task hybrid neural network is used to jointly and actively predict five types of risks. An integrated risk score is used to drive intelligent hierarchical recovery and dynamic synchronization strategy selection, forming a full closed-loop self-healing mechanism from prediction, decision-making, execution to verification. The view switching process is optimized, and cross-chain fault scenarios are considered. The defects of passive lag, rigid strategy and system fragmentation in the prior art are effectively overcome, and the self-healing ability, stability and security of the blockchain node in a complex environment are significantly improved.

Description

Technical Field

[0001] This invention belongs to the field of blockchain technology, and in particular relates to a method and system for adaptive synchronization fault recovery of blockchain nodes based on AI prediction. Background Technology

[0002] As blockchain technology continues to develop and network scale expands, the operating environment for nodes is becoming increasingly complex. On the one hand, nodes face problems commonly found in traditional IT systems, such as hardware failures, network jitter, and resource overload. On the other hand, the unique distributed architecture and consensus mechanism of blockchain bring new challenges, including malicious node attacks, data tampering, view switching failures, and cross-chain interaction compatibility issues. According to industry security reports, blockchain system downtime events caused by node failures account for a significant proportion globally, with each failure resulting in substantial economic losses. In financial-grade application scenarios, system availability requirements reach a high level, and traditional node failure recovery mechanisms can no longer meet these stringent requirements.

[0003] Existing blockchain node failure recovery technologies have mainly gone through two stages of development. The first stage is the traditional passive failure recovery mechanism, which is also the mainstream solution adopted by the vast majority of blockchain systems. This mechanism detects node failures through periodic checkpoints, heartbeat detection, or timeout mechanisms. When a node anomaly is detected, a preset recovery process is triggered. For example, public chains such as Bitcoin and Ethereum use checkpointing mechanisms, triggering full synchronization when a node's block height falls behind by more than a certain threshold; consortium chains such as Hyperledger Fabric use heartbeat detection mechanisms, initiating a view switching process to elect a new master node when the master node is unresponsive. However, this passive mechanism has inherent drawbacks: failure detection has a significant delay, and it usually takes a long time from the occurrence of a failure to the initiation of recovery. During this period, the node cannot provide services normally, which seriously affects transaction processing efficiency; the synchronization strategy is fixed and singular, and cannot be adjusted according to dynamic factors such as network bandwidth and node load, resulting in low recovery efficiency and serious resource waste; the election of backup nodes during view switching is highly random, with a high failure rate, which can easily cause network-wide consensus stagnation.

[0004] The second stage is AI-assisted blockchain operation and maintenance technology. In recent years, with the development of artificial intelligence technology, some research has begun to try to apply machine learning to blockchain node failure prediction. For example, some scholars have proposed predicting the risk of node block lag based on LSTM models, and some vendors have developed rule-based node health monitoring systems. In addition, existing technologies have also seen frameworks that integrate machine learning predictive analysis with real-time network monitoring, as well as adaptive defense methods based on Bayesian inference. However, existing AI-assisted solutions still have obvious limitations: most studies only predict single failure types, requiring the deployment of multiple independent models, consuming large amounts of computational resources and failing to utilize the correlation between different failures; the model architecture is simple, mostly using pure LSTM or pure GRU, unable to simultaneously meet the needs of long-term dependency capture and lightweight inference; there is a lack of joint prediction capabilities for malicious attacks, data tampering, and cross-chain interaction failures, making it unable to adapt to the development trend of multi-chain interconnection; risk prediction results are mostly directly mapped to fixed recovery actions or single-level triggers, without establishing a unified comprehensive score and hierarchical recovery mapping relationship for multiple risk dimensions; solutions are mostly fragmented functional modules, lacking unified coordination and closed-loop management, failing to achieve full-process automation from prediction to recovery.

[0005] Furthermore, with the rapid development of cross-chain technology, multi-chain interconnection has become an important development direction for blockchain technology. Cross-chain interaction introduces new failure modes, such as cross-chain message loss, validator node failure, and cross-chain data inconsistency. These failures not only affect the operation of a single chain but may also lead to cross-chain asset loss and data security issues. Existing fault recovery mechanisms almost completely ignore cross-chain interaction scenarios and cannot effectively address the challenges posed by cross-chain failures.

[0006] Therefore, existing blockchain node failure recovery technologies generally suffer from problems such as passive and delayed response, fixed synchronization strategies, fragmented consensus mechanisms, and disorganized system architecture, which cannot meet the requirements of blockchain systems for high availability, high security, and high reliability in complex heterogeneous environments. Summary of the Invention

[0007] The purpose of this invention is to provide a blockchain node adaptive synchronization fault recovery method and system based on AI prediction, so as to solve the problems of passive response lag, fixed synchronization strategy, lack of joint prediction of multiple risks and insufficient adaptation to cross-chain scenarios in existing blockchain node fault recovery technologies.

[0008] To achieve one of the above-mentioned objectives, one embodiment of the present invention provides a blockchain node adaptive synchronization fault recovery method based on AI prediction, characterized in that it includes:

[0009] Collect basic operational data, transaction and business data, and security and fault data of blockchain nodes, and preprocess them to form a standardized dataset.

[0010] Based on the standardized dataset, a hybrid neural network model integrating long short-term memory network, gated recurrent unit and attention mechanism is constructed and trained. The model outputs the block lag risk score, view lag risk score, malicious attack risk score, data tampering risk score and cross-chain interaction failure risk score of the node in real time through multi-task learning.

[0011] A comprehensive risk score is calculated based on five risk scores. Based on the preset threshold range into which the comprehensive risk score falls, the corresponding recovery level is determined from multiple preset recovery levels and the recovery process of the corresponding level is triggered. At the same time, the state of the blockchain node is switched from the normal state to the recovery state.

[0012] Based on the dynamic operating factors of the blockchain node, a synchronization strategy is adaptively selected through a dynamic weight decision model to synchronize the data of the blockchain node; after the data synchronization is completed, the synchronization results are sequentially verified by data hash, consensus state verification and business logic testing, and after all verifications are passed, the state of the blockchain node is switched from the recovery state back to the normal state.

[0013] During the period when the blockchain node is in a normal or recovery state, an election score is obtained by fusing the node's historical stability score with the AI ​​real-time risk prediction results, and a backup master node is elected in advance; when the failure risk score of the current master node exceeds a preset threshold, the view switching process is optimized based on the backup master node.

[0014] As a further improvement to one embodiment of the present invention, the method further includes preprocessing the collected basic operational data, transaction and business data, and security and fault data of blockchain nodes to form a standardized dataset, including...

[0015] The basic operational data collected includes at least block synchronization delay time, consensus message response time, network jitter frequency, and CPU utilization. The transaction and business data includes at least transaction processing success rate, transaction processing delay, and cross-chain transaction volume. The security and fault data includes at least malicious attack records, data tampering attempt records, and node historical fault records.

[0016] The collected multidimensional feature data is sequentially subjected to data cleaning, data standardization, and redundant feature removal to obtain the standardized dataset. The data cleaning is used to identify and process outliers and missing values, the data standardization is used to map the data to a uniform numerical range, and the redundant feature removal is used to filter and retain features based on the correlation between features and node faults and dimensionality reduction analysis.

[0017] The standardized dataset is divided into a training set, a validation set, and a test set according to a preset ratio. The training set is used for training the hybrid neural network model, the validation set is used for validating the hybrid neural network model, and the test set is used for performance evaluation of the hybrid neural network model.

[0018] As a further improvement to one embodiment of the present invention, the method further includes, in the step of constructing and training a hybrid neural network model integrating a long short-term memory network, a gated recurrent unit, and an attention mechanism, including,

[0019] The input layer dimension of the hybrid neural network model corresponds to the feature dimension of the standardized dataset. The hidden layer includes multiple long short-term memory network units, multiple gated recurrent units, and at least one attention layer. The output layer includes five output nodes corresponding to the block lag risk score, view lag risk score, malicious attack risk score, data tampering risk score, and cross-chain interaction failure risk score, respectively.

[0020] During the training process of the hybrid neural network model, the comprehensive loss function is minimized using the backpropagation algorithm. The comprehensive loss function is expressed as:

[0021] ;

[0022] in, , , , , These are the loss functions for the block lag risk prediction task, view lag risk prediction task, malicious attack risk prediction task, data tampering risk prediction task, and cross-chain interaction failure risk prediction task, respectively. , , , , These are the weight coefficients for the corresponding tasks, and , and All greater than , and .

[0023] As a further improvement to one embodiment of the present invention, the method further includes determining a corresponding recovery level from multiple preset recovery levels based on the preset threshold range into which the comprehensive risk score falls, triggering a recovery process for the corresponding level, and simultaneously switching the state of the blockchain node from a normal state to a recovery state, including:

[0024] The comprehensive risk score Represented as:

[0025] ;

[0026] in, , , , , These are respectively the block lag risk score, view lag risk score, malicious attack risk score, data tampering risk score, and cross-chain interaction failure risk score;

[0027] The preset threshold range includes a first threshold that increases sequentially. Second threshold and the third threshold Specifically, including,

[0028] when When, the recovery process is not triggered; when When, trigger Level 1 recovery; when When, trigger level 2 recovery; when At that time, a level 3 recovery is triggered;

[0029] The first-level recovery includes triggering an incremental synchronization strategy and allowing the node to continue processing transactions; the second-level recovery includes pausing the node's transaction processing function and executing a sharding synchronization strategy; and the third-level recovery includes isolating the node, executing a full synchronization strategy, and initiating a security scan.

[0030] During the recovery process, if the comprehensive risk score is... If the current recovery level is upgraded to the higher recovery level corresponding to the higher threshold range entered, then the recovery level will be upgraded accordingly. If the price drops to a lower range and continues for more than the preset time window, then a downgrade will be implemented.

[0031] As a further improvement to one embodiment of the present invention, the method further includes, based on the dynamic operating factors of the blockchain node, adaptively selecting a synchronization strategy to synchronize data between the blockchain nodes using a dynamic weight decision model, including,

[0032] Four dynamic operating factors are obtained: block difference, network bandwidth, node load health, and data importance level. These four dynamic operating factors are then standardized to a uniform value range, wherein node load health is negatively correlated with node load rate.

[0033] The comprehensive decision score S is calculated based on four dynamic operating factors, and the comprehensive decision score S is expressed as follows:

[0034] ;

[0035] in, , , , These are the standardized block differences, network bandwidth, node load health, and data importance level, respectively. , , , These are the weight coefficients of the corresponding factors, and , ;

[0036] Based on the comprehensive decision score The preset interval into which the score falls is selected by choosing a corresponding synchronization strategy from full synchronization, incremental synchronization, fragmented synchronization, and emergency synchronization. The preset interval includes a first score threshold that decreases sequentially. Second scoring threshold and the third scoring threshold Specifically, including,

[0037] when When selecting full synchronization, When choosing incremental synchronization, When selecting split synchronization, when Select emergency synchronization at this time;

[0038] Among them, Level 1 recovery prioritizes triggering the incremental synchronization strategy, Level 2 recovery prioritizes triggering the sharded synchronization strategy, and Level 3 recovery forcibly triggers the full synchronization strategy. The dynamic weight decision model further adaptively selects based on the priority or forced strategy of the corresponding recovery level.

[0039] As a further improvement to one embodiment of the present invention, the method further includes, after data synchronization is completed, performing data hash verification, consensus state verification, and business logic testing on the synchronization results in sequence, including,

[0040] The data hash verification is used to perform hash calculation on the synchronized block data and compare it with the hash value of the latest block in the entire network. After the comparison is successful, it enters the consensus state verification.

[0041] The consensus state verification is used to verify whether the view number, consensus message signature and voting result of the blockchain node are correct. After the verification is passed, the business logic test is initiated.

[0042] The business logic test is used to execute a preset set of test transactions to verify whether the transaction processing results of the blockchain node are consistent with those of the entire network.

[0043] After the data hash verification, consensus state verification, and business logic test are all passed in sequence, the state of the blockchain node is switched from the recovery state back to the normal state; if any verification fails, the processing corresponding to the failed item is re-executed.

[0044] As a further improvement to one embodiment of the present invention, the method further includes: electing a backup master node in advance based on the election score obtained by fusing the node's historical stability score with the AI ​​real-time risk prediction result; including...

[0045] Based on the blockchain node's online rate, consensus participation rate, view switching success rate, and / or transaction processing success rate over a preset period, calculate the... Historical stability score of each node The historical stability score Represented as:

[0046] ;

[0047] in, , , , These are the weighting coefficients for the corresponding indicators, and ;

[0048] The real-time risk score output by the hybrid neural network model is combined with the data. Calculate the fusion election score The fusion election score Represented as:

[0049] ;

[0050] Where α and β are weighting coefficients, and α + β = 1, Take the maximum or weighted value among the five risk scores;

[0051] The fusion election score is selected according to a preset block height interval. The maximum preset number of nodes are designated as backup master nodes, and the election results are broadcast to the entire network; if a node's real-time risk score... If the threshold is exceeded, the node will be removed from the list of standby master nodes or downgraded.

[0052] When the failure risk score of the current master node exceeds a preset threshold, the fusion election score is selected from the backup master nodes. The node with the highest real-time risk score and a score below a preset threshold is designated as the new master node, and a view switching notification message containing the new master node information is broadcast to the entire network. The view switching is completed after receiving a confirmation message.

[0053] To achieve one of the above-mentioned objectives, an embodiment of the present invention also provides an AI-predictive-based adaptive synchronization fault recovery system for blockchain nodes, the system comprising:

[0054] The data acquisition module is used to collect basic operational data, transaction and business data, and security and fault data of blockchain nodes, and to preprocess them to form a standardized dataset.

[0055] The AI ​​prediction module is used to construct and train a hybrid neural network model that integrates long short-term memory network, gated recurrent unit and attention mechanism based on the standardized dataset. It outputs the block lag risk score, view lag risk score, malicious attack risk score, data tampering risk score and cross-chain interaction failure risk score of the node in real time through multi-task learning.

[0056] The intelligent decision-making module is used to calculate a comprehensive risk score based on five risk scores, and determine the corresponding recovery level from multiple preset recovery levels based on the preset threshold range in which the comprehensive risk score falls, and trigger the recovery process of the corresponding level, while switching the state of the blockchain node from the normal state to the recovery state.

[0057] The synchronization execution module is used to adaptively select a synchronization strategy to synchronize data of the blockchain node based on the dynamic operating factors of the blockchain node through a dynamic weight decision model; after the data synchronization is completed, the synchronization result is sequentially subjected to data hash verification, consensus state verification and business logic testing, and after all verifications are passed, the state of the blockchain node is switched from the recovery state back to the normal state.

[0058] The status monitoring module is used to elect a backup master node in advance based on the election score obtained by fusing the node's historical stability score and the AI ​​real-time risk prediction results while the blockchain node is in a normal or recovery state; when the fault risk score of the current master node exceeds a preset threshold, the view switching process is optimized based on the backup master node.

[0059] To achieve one of the above-mentioned objectives, an embodiment of the present invention also provides an electronic device, including a memory and a processor, characterized in that the memory stores a computer program that can run on the processor, and when the program is executed on the processor, it implements the steps in the AI-predictive-based adaptive synchronization fault recovery method for blockchain nodes as described above.

[0060] To achieve one of the above-mentioned objectives, an embodiment of the present invention also provides a storage medium storing a computer program, characterized in that, when the computer program is executed by a processor, it implements the steps in the AI-predictive-based adaptive synchronization fault recovery method for blockchain nodes as described above.

[0061] Compared with existing technologies, the present invention provides a blockchain node adaptive synchronization fault recovery method and system based on AI prediction. It realizes joint active prediction of five types of risks through multi-task hybrid neural networks, and drives intelligent hierarchical recovery and dynamic synchronization strategy selection with comprehensive risk scoring, forming a closed-loop self-healing mechanism from prediction, decision-making, execution to verification. At the same time, it optimizes the view switching process and takes into account cross-chain fault scenarios, effectively overcoming the defects of passive lag, rigid strategies and fragmented systems in existing technologies, and significantly improving the self-healing ability, stability and security of blockchain nodes in complex environments. Attached Figure Description

[0062] Figure 1 This is an overall flowchart of the AI-predictive-based adaptive synchronization fault recovery method for blockchain nodes described in this invention.

[0063] Figure 2 This is a flowchart illustrating the AI-predictive-based adaptive synchronization fault recovery method for blockchain nodes described in this invention.

[0064] Figure 3 This is a schematic diagram of the architecture of the AI-predictive adaptive synchronization fault recovery system for blockchain nodes described in this invention. Detailed Implementation

[0065] This embodiment is a specific implementation of the method described in this invention in a consortium blockchain scenario, deployed on a consortium blockchain network consisting of 12 participating organizations, 100 peer nodes, and 4 orderer nodes. This embodiment fully reproduces all the technical features described in the claims, and all parameter settings, module implementations, and execution flows are consistent with the specification, without introducing any new technology content beyond the protection scope of this invention.

[0066] This system adopts a three-tier deployment architecture of distributed data acquisition, centralized decision-making, and local execution, and is integrated with the existing Hyperledger Fabric 2.5.4 network.

[0067] Table 1

[0068] Software environment configuration:

[0069] Operating System: Ubuntu 22.04 LTS

[0070] Containerization platforms: Docker 24.0.6, Docker Compose 2.23.0

[0071] Blockchain platform: Hyperledger Fabric 2.5.4

[0072] Deep learning frameworks: TensorFlow 2.13.0, TensorFlow Lite 2.15.0

[0073] Monitoring systems: Prometheus 2.45.0, Grafana 10.2.0

[0074] Database: MySQL 8.0.35, MinIO (2024-01-01)

[0075] The present invention will now be described in detail with reference to the specific embodiments shown in the accompanying drawings. However, these embodiments do not limit the present invention, and any structural, methodological, or functional modifications made by those skilled in the art based on these embodiments are included within the scope of protection of the present invention.

[0076] In Embodiment 1 of the present invention, the present invention provides a blockchain node adaptive synchronization fault recovery method based on AI prediction, such as... Figure 1 As shown, the method includes,

[0077] S1: Collect basic operational data, transaction and business data, and security and fault data of blockchain nodes, and preprocess them to form a standardized dataset;

[0078] S2: Based on the standardized dataset, construct and train a hybrid neural network model that integrates long short-term memory network, gated recurrent unit and attention mechanism, and output the block lag risk score, view lag risk score, malicious attack risk score, data tampering risk score and cross-chain interaction failure risk score of the node in real time through multi-task learning method.

[0079] S3: Calculate a comprehensive risk score based on the five risk scores, and determine the corresponding recovery level from multiple preset recovery levels based on the preset threshold range in which the comprehensive risk score falls, and trigger the recovery process of the corresponding level, while switching the state of the blockchain node from the normal state to the recovery state.

[0080] S4: Based on the dynamic operating factors of the blockchain node, an adaptive synchronization strategy is selected through a dynamic weight decision model to synchronize the data of the blockchain node; after the data synchronization is completed, the synchronization results are sequentially verified by data hash, consensus state verification and business logic testing, and after all verifications are passed, the state of the blockchain node is switched from the recovery state back to the normal state.

[0081] S5: During the period when the blockchain node is in a normal or recovery state, a backup master node is elected in advance based on the election score obtained by fusing the node's historical stability score with the AI ​​real-time risk prediction results; when the fault risk score of the current master node exceeds a preset threshold, the view switching process is optimized based on the backup master node.

[0082] In one specific embodiment of the present invention, basic operational data, transaction and business data, and security and fault data of blockchain nodes are collected and preprocessed to form a standardized dataset. Specifically,

[0083] The basic operational data collected includes at least block synchronization delay time, consensus message response time, network jitter frequency, and CPU utilization. The transaction and business data includes at least transaction processing success rate, transaction processing delay, and cross-chain transaction volume. The security and fault data includes at least malicious attack records, data tampering attempt records, and node historical fault records.

[0084] The collected multidimensional feature data is sequentially subjected to data cleaning, data standardization, and redundant feature removal to obtain the standardized dataset. The data cleaning is used to identify and process outliers and missing values, the data standardization is used to map the data to a uniform numerical range, and the redundant feature removal is used to filter and retain features based on the correlation between features and node faults and dimensionality reduction analysis.

[0085] The standardized dataset is divided into a training set, a validation set, and a test set according to a preset ratio. The training set is used for training the hybrid neural network model, the validation set is used for validating the hybrid neural network model, and the test set is used for performance evaluation of the hybrid neural network model.

[0086] It should be noted that constructing a standardized dataset is crucial for providing a high-quality, learnable input data foundation for the subsequent training and real-time inference of hybrid neural network models. In actual operation, blockchain nodes generate heterogeneous operational logs and monitoring metrics from multiple sources. This raw data directly reflects the node's synchronization status, consensus participation, resource load level, transaction processing capacity, and the security threats it faces. Without systematic collection and preprocessing, noise, missing data, dimensional differences, and redundant information will severely affect the model's accurate characterization of fault risks. Therefore, this step involves the comprehensive collection and standardization of three types of key data to construct a standardized dataset that retains fault-related information while being suitable for neural network learning. This supports the closed-loop implementation of subsequent multi-task risk prediction, comprehensive score calculation, and adaptive recovery decision-making.

[0087] Furthermore, basic operational data, transaction and business data, and security and fault data of blockchain nodes are collected. Basic operational data includes at least block synchronization latency, consensus message response time, network jitter frequency, and CPU utilization. These metrics directly characterize the synchronization gap between the node and the entire network, the timeliness of consensus message processing, network stability, and computing resource consumption, serving as the core basis for judging the risk of block and view lag. Transaction and business data includes at least transaction processing success rate, transaction processing latency, and the number of cross-chain transactions. These metrics reflect the node's processing capacity at the business level and the activity level of cross-chain interactions, helping to identify potential faults caused by business overload or cross-chain anomalies. Security and fault data includes at least malicious attack records, data tampering attempt records, and historical node fault records. These metrics capture external attack behaviors, internal data integrity threats, and historical fault patterns faced by the node, providing direct evidence for predicting malicious attack risks and data tampering risks. The joint collection of these three types of data can cover a complete profile of the node from its underlying operation to its upper-layer business and security threats, avoiding predictive blind spots caused by single-dimensional data.

[0088] Furthermore, after data collection, the acquired multidimensional feature data undergoes sequential data cleaning, standardization, and redundant feature removal to obtain a standardized dataset. Data cleaning identifies and handles outliers and missing values, aiming to eliminate noise and gaps introduced during data collection due to sensor malfunctions, network packet loss, or log errors. This prevents abnormal samples from misleading model training and ensures the authenticity and stability of subsequent feature distributions. Data standardization maps features of different dimensions and magnitudes to a unified numerical range, eliminating the interference of dimensional differences on model parameter learning. This allows each feature to participate in gradient updates at an equal scale in the neural network, improving training convergence speed and prediction fairness. Redundant feature removal uses correlation analysis and dimensionality reduction based on features and node faults to filter and retain effective features. Its purpose is to eliminate redundant dimensions with weak or high correlation to fault prediction, reducing input space complexity and overfitting risk, while retaining information that contributes most to fault identification, improving the model's generalization ability and inference efficiency. The above three steps proceed sequentially: cleaning to ensure data quality, standardizing to unify data scale, and removing redundancy to refine the feature space, together forming a standardized dataset suitable for model learning.

[0089] Furthermore, the standardized dataset is divided into training, validation, and test sets according to a predetermined ratio. The training set is used for parameter learning and multi-task loss function optimization of the hybrid neural network model, enabling the model to mine the temporal patterns and correlations of five types of failure risks from historical data. The validation set is used to monitor model performance during training and guide hyperparameter tuning and early stopping decisions to prevent overfitting and ensure the model's generalization ability on unseen data. The test set is used to objectively evaluate the model's final prediction performance after training, verifying the model's comprehensive discrimination effect on block lag, view lag, malicious attacks, data tampering, and cross-chain interaction failure risks. The division of the dataset into three parts ensures the independence and scientific nature of the model training, tuning, and evaluation processes, providing a reliable model foundation for subsequent real-time risk scoring output.

[0090] In a specific implementation scenario of the present invention, preferably, 20-dimensional feature data in three categories are collected: basic operational data, transaction and business data, and security and fault data. Specifically:

[0091] Deploy Prometheus Node Exporter v1.7.0 and FabricExporter v0.9.0 on each Peer and Orderer node to collect 20-dimensional runtime data at a sampling frequency of once per minute. The specific metric mapping relationship is as follows:

[0092] Basic operational data (8 dimensions):

[0093] Block synchronization latency: The difference between the current block height of a node and the height of the longest chain in the entire network, and the synchronization time, accurate to milliseconds;

[0094] Consensus message response time: The time it takes for a node to send a response after receiving a consensus message, accurate to milliseconds;

[0095] Network jitter frequency: The number of times per minute that network latency changes by more than 50ms;

[0096] View switching failure log: including the time of failure, reason for failure, and nodes involved;

[0097] CPU utilization: Average utilization per minute, peak utilization;

[0098] Memory usage: Average usage per minute, peak usage;

[0099] Disk I / O rates: read rate and write rate per minute;

[0100] Network connections: Average connections per minute, maximum connections per minute.

[0101] Transaction and business data (4 dimensions):

[0102] Transaction processing success rate: The ratio of the number of transactions successfully processed per minute to the total number of transactions;

[0103] Transaction processing latency: Average transaction processing time per minute;

[0104] Cross-chain transaction count: The number of cross-chain transactions per minute;

[0105] Cross-chain data interaction logs include interaction time, source chain, target chain, data volume, and interaction result.

[0106] Safety and Fault Data (8 Dimensions):

[0107] Malicious attack log: attack time, attack type, attack intensity, and impact;

[0108] Data tampering attempt log: attempt time, tampering location, tampering result;

[0109] Node historical fault records: fault occurrence time, fault type, fault duration, recovery measures, and recovery effect;

[0110] Network topology change record: node joining / leaving time, changes in network connection relationships;

[0111] Data transmission error rate: The ratio of the number of data transmission errors per minute to the total number of transmissions;

[0112] Consensus anomaly log: number of consensus message signature failures, number of voting timeouts, number of illegal proposals, number of consensus message replays, etc.;

[0113] Security alerts and audit event statistics: number of alerts, alert levels, alert types, etc. generated by firewalls, IDS / IPS, and audit logs;

[0114] Node identity and certificate anomaly log: the number of times anomalies such as certificate expiration, certificate revocation, identity authentication failure, and key negotiation failure have occurred.

[0115] Furthermore, data preprocessing includes data cleaning, data standardization, and redundant feature removal. Data cleaning uses the Laida criterion (3σ principle) to identify outliers; continuous missing values ​​are filled using linear interpolation, and discrete missing values ​​are filled using mode imputation, while duplicate data is removed. Data standardization uses the Min-Max standardization method to transform the data to the [0,1] interval. Redundant feature removal uses Pearson correlation analysis to screen features with a correlation higher than 0.6 with node failures, and principal component analysis is used to retain principal components with a cumulative variance contribution rate of over 95%. The preprocessed data is divided into training, validation, and test sets in a 7:2:1 ratio, preferably in chronological order to prevent data leakage. The training set contains 367,920 data records, the validation set contains 105,120 data records, and the test set contains 52,560 data records.

[0116] In one specific embodiment of the present invention, a hybrid neural network model integrating a long short-term memory network, a gated recurrent unit, and an attention mechanism is constructed and trained, specifically as follows:

[0117] The input layer dimension of the hybrid neural network model corresponds to the feature dimension of the standardized dataset. The hidden layer includes multiple long short-term memory network units, multiple gated recurrent units, and at least one attention layer. The output layer includes five output nodes corresponding to the block lag risk score, view lag risk score, malicious attack risk score, data tampering risk score, and cross-chain interaction failure risk score, respectively.

[0118] During the training process of the hybrid neural network model, the comprehensive loss function is minimized using the backpropagation algorithm. The comprehensive loss function is expressed as:

[0119] ;

[0120] in, , , , , These are the loss functions for the block lag risk prediction task, view lag risk prediction task, malicious attack risk prediction task, data tampering risk prediction task, and cross-chain interaction failure risk prediction task, respectively. , , , , These are the weight coefficients for the corresponding tasks, and , and All greater than , and .

[0121] It should be noted that the purpose of constructing and training a hybrid neural network model that integrates Long Short-Term Memory (LSTM) networks, gated recurrent units (GRUs), and attention mechanisms is to build a unified predictive model capable of simultaneously capturing long-term temporal dependencies, short-term dynamic changes, and the importance of key features in node operation data. This model outputs five types of fault risk scores in a single, multi-task learning approach, providing real-time, multi-dimensional risk input for subsequent comprehensive risk score calculation, tiered recovery triggering, and adaptive synchronization strategy selection. Traditional single models struggle to balance long-term synchronization lag patterns with rapid response to sudden security events, and also fail to leverage the potential correlations between different fault types. This step, by integrating the advantages of three network structures and employing a weighted multi-task learning mechanism, achieves joint modeling of fault risks such as block lag, view lag, malicious attacks, data tampering, and cross-chain interaction. This enables the model to possess both temporal memory capabilities and the ability to focus on key anomaly features, while balancing the learning priorities of different risk tasks, providing a reliable predictive foundation for the entire adaptive fault recovery closed loop.

[0122] Furthermore, the overall structure of the hybrid neural network model is constructed. The input layer dimension of the model corresponds to the feature dimension of the standardized dataset, ensuring that the preprocessed multidimensional runtime data can be input into the network completely and without loss. The hidden layer includes multiple layers of long short-term memory network units, multiple layers of gated recurrent units, and at least one attention layer. The long short-term memory network units are mainly used to capture long-term temporal dependencies in node runtime data, such as the cumulative trend of block synchronization delay, the periodic changes in consensus message response time, and the long-term impact of historical failure modes, thereby effectively identifying progressive risks such as block lag and view lag. The gated recurrent units, while retaining temporal modeling capabilities, reduce computational overhead with a lighter structure, making them suitable for modeling rapidly changing features such as short-term network jitter and resource load fluctuations, improving the model's inference efficiency on resource-constrained nodes. The attention layer further weights and focuses the temporal features output by the hidden layer, automatically highlighting the key time steps or feature dimensions most relevant to the current risk, suppressing interference from irrelevant noise, and improving the model's sensitivity to sudden malicious attacks, data tampering attempts, and cross-chain anomalies. The output layer is set up with five independent nodes, corresponding to block lag risk score, view lag risk score, malicious attack risk score, data tampering risk score, and cross-chain interaction failure risk score, respectively. This enables the model to provide quantitative assessment results for all five types of risks in one forward propagation, avoiding the waste of resources and inconsistency in decision-making caused by deploying multiple independent models.

[0123] Furthermore, after the model structure is determined, the training process begins. During training, the backpropagation algorithm is used to minimize the comprehensive loss function, enabling the model parameters to simultaneously optimize the performance of five risk prediction tasks. The comprehensive loss function adopts a weighted summation form, combining the loss functions of each task according to preset weights. The weight settings reflect the different impacts of various risks on system stability: block lag and view lag directly relate to whether nodes can participate in consensus and transaction processing, having a more fundamental and frequent impact on system availability, and are therefore given relatively higher weights; malicious attacks, data tampering, and cross-chain interaction failures, although serious, occur relatively infrequently, and are given appropriate weights to avoid the model overly favoring rare events while ignoring routine operational risks. Through this weighted multi-task learning approach, the model can utilize shared representations and correlation information between different tasks during training, improving the overall robustness and generalization ability of predictions, while ensuring sufficient attention to high-priority risks.

[0124] In a specific embodiment of the present invention, preferably,

[0125] Model Architecture: A hybrid neural network model integrating LSTM, GRU, and Attention mechanisms is built based on the TensorFlow deep learning framework. The input layer receives preprocessed 20-dimensional feature data. The hidden layer contains 3 LSTM units (64 neurons per layer), 2 GRU units (32 neurons per layer), and 1 Attention layer. The output layer has 5 neurons, corresponding to the risk scores of node block lag, view lag, malicious attack, data tampering, and cross-chain interaction failure, respectively. Dropout technology (dropout rate=0.2) is used between layers to prevent overfitting, and the ReLU function is used as the activation function.

[0126] Training parameters: Optimizer: Adam optimizer, initial learning rate 0.001, learning rate decays to 0.9 every 10 epochs; Loss function: weighted multi-task mean squared error loss function, weights are allocated as follows: block lag 0.3, view lag 0.3, malicious attack 0.2, data tampering 0.1, cross-chain interaction failure 0.1; Training epochs: 100; Batch size: 64; Early stopping mechanism: training stops when the validation set performance no longer improves for 5 consecutive epochs.

[0127] Multi-task learning and training: During training, five prediction tasks are trained simultaneously, with different weights assigned to each task. Based on the impact of each task on system stability, the weights for block lag risk prediction and view lag risk prediction are set to 0.3, malicious attack risk prediction and data tampering risk prediction are set to 0.2, and cross-chain interaction failure risk prediction is set to 0.2. The model parameters are continuously adjusted using the backpropagation algorithm to minimize the overall loss function value of the model across all tasks.

[0128] Furthermore, the acquisition and labeling of real data for five types of risk scores involves: collecting raw records from Prometheus, FabricExporter, on-chain event logs, SIEM / IDS, cross-chain gateways, maintenance work orders, and security audit systems; initial screening by a rule engine based on preset fault definitions to generate candidate fault events; and then review by blockchain maintenance experts and security experts to form labeled events. The specific label definitions are as follows:

[0129] Block lagging risk: refers to a node's block height being lower than the network median or the longest chain height exceeding a preset threshold and continuously exceeding a preset number of blocks;

[0130] View Lagging Risk: This refers to a node's view number lagging behind the current view number, or failure to participate in consensus within the timeout period;

[0131] Malicious attack risks: These refer to abnormal connections, Sybil attacks, DDoS attacks, replay attacks, etc., confirmed by IDS, firewalls, or audit logs.

[0132] Data tampering risk: refers to hash verification failures, ledger inconsistencies, unauthorized write operations, or tampering attempts confirmed by audits;

[0133] Cross-chain interaction failure risks: These include cross-chain message timeouts, relay or verification node failures, target chain receipt failures, and cross-chain data inconsistencies.

[0134] The annotation process uses a future time window approach: predicting whether a corresponding fault will occur within the next T minutes based on feature data from W minutes prior to the current time, with 1 marked if it occurs and 0 if it does not; alternatively, it can be annotated with a continuous risk value from 0 to 1 based on the severity of the fault. For imbalanced samples, oversampling, undersampling, or cost-sensitive loss can be used for handling; annotation consistency is evaluated using the Kappa coefficient, preferably greater than 0.8. The training, validation, and test sets are divided chronologically to prevent data leakage.

[0135] Model Validation and Optimization: After each training epoch, the model is validated using a validation set, and various prediction metrics (such as accuracy, precision, recall, and F1 score) are calculated. Training is stopped when the model's performance on the validation set no longer improves for five consecutive epochs to prevent overfitting. Hyperparameters, such as the number of hidden layer neurons, learning rate, and dropout rate, are adjusted using a grid search method. The training process is repeated until the model's metrics on the validation set reach preset standards (accuracy exceeding 0.9 and F1 score exceeding 0.85).

[0136] Furthermore, the trained model is converted to TensorFlow Lite format and deployed to the local AI prediction module on each node. The model file size is small, single inference time is in the millisecond range, resource consumption is low, and it has no significant impact on the normal operation of the nodes. Docker containerization technology is used to package the model deployment environment, ensuring consistency and portability of the model across different nodes. Simultaneously, a monitoring interface is provided for model deployment to monitor the model's running status in real time (such as inference time, memory usage, and prediction accuracy), and to issue timely alerts when anomalies occur.

[0137] In one specific embodiment of the present invention, based on the preset threshold range into which the comprehensive risk score falls, a corresponding recovery level is determined from multiple preset recovery levels and a recovery process for that level is triggered. Simultaneously, the state of the blockchain node is switched from a normal state to a recovery state. Specifically,

[0138] The comprehensive risk score Represented as:

[0139] ;

[0140] in, , , , , These are respectively the block lag risk score, view lag risk score, malicious attack risk score, data tampering risk score, and cross-chain interaction failure risk score;

[0141] The preset threshold range includes a first threshold that increases sequentially. Second threshold and the third threshold Specifically, including,

[0142] when When, the recovery process is not triggered; when When, trigger Level 1 recovery; when When, trigger level 2 recovery; when At that time, a level 3 recovery is triggered;

[0143] The first-level recovery includes triggering an incremental synchronization strategy and allowing the node to continue processing transactions; the second-level recovery includes pausing the node's transaction processing function and executing a sharding synchronization strategy; and the third-level recovery includes isolating the node, executing a full synchronization strategy, and initiating a security scan.

[0144] During the recovery process, if the comprehensive risk score is... If the current recovery level is upgraded to the higher recovery level corresponding to the higher threshold range entered, then the recovery level will be upgraded accordingly. If the price drops to a lower range and continues for more than the preset time window, then a downgrade will be implemented.

[0145] It should be noted that determining the corresponding recovery level from multiple preset recovery levels and triggering the corresponding recovery process involves unifying the five discrete risk scores output by the hybrid neural network into actionable recovery decisions, achieving a crucial transformation from multi-dimensional risk perception to tiered response execution. Traditional fault recovery often employs fixed actions for single anomalies, easily leading to over- or under-response issues. This step introduces a comprehensive risk score and establishes a clear mapping relationship between it and multi-level recovery actions, enabling the system to automatically select the appropriate recovery intensity based on the severity of the current highest risk dimension. This ensures sensitive response to anomalies in any dimension while avoiding unnecessary heavy recovery triggered by slight fluctuations in a single dimension, thus maintaining business continuity while ensuring node safety. The state switching mechanism ensures clear boundaries between node behavior during recovery and normal operation, providing a unified state management foundation for subsequent synchronous execution and verification.

[0146] Furthermore, a comprehensive risk score is calculated based on the five risk scores. The comprehensive risk score is the maximum value among the five risk categories, designed to characterize the overall risk level currently faced by the node in the most conservative and secure way. If any risk dimension exceeds the security boundary, it may have a substantial impact on node functionality or network consensus. Therefore, using the highest risk as the triggering criterion ensures that the recovery process remains sufficiently sensitive to potential serious failures and avoids masking the true threat due to lower scores in other dimensions.

[0147] Furthermore, after obtaining the comprehensive risk score, it is compared with preset thresholds that increase sequentially. , and The comparison is performed to determine the corresponding recovery level and trigger the appropriate process. When the overall risk score is lower than... When the overall risk score falls within a certain range, it indicates that all risk dimensions are within the safe range, the system does not trigger any recovery actions, the nodes maintain normal operation, and unnecessary intervention is avoided. and In the interim, a Level 1 recovery is triggered, which only executes an incremental synchronization strategy and allows nodes to continue processing transactions. Its purpose is to correct minor data lags or early anomalies with minimal disruption, while maintaining maximum business availability. When the comprehensive risk score falls into... and During this period, a secondary recovery is triggered, suspending node transaction processing and executing a sharding synchronization strategy. The purpose is to prevent further spread of the anomaly by limiting business load and adopting a more efficient sharding method to accelerate data alignment when the risk has already substantially impacted consensus or transactions. When the comprehensive risk score reaches or exceeds [a certain threshold], [further action is taken]. When this occurs, a Level 3 recovery is triggered, immediately isolating nodes, performing full synchronization, and initiating a security scan. The purpose is to address high-risk states that may have been compromised or have deviated significantly from consensus. Through thorough isolation and comprehensive repair, the security and data integrity of the entire network are protected to the greatest extent possible.

[0148] Furthermore, during the recovery process, the system continuously monitors changes in the comprehensive risk score and supports dynamic upgrades and downgrades. If the score crosses into a higher preset threshold range, the current recovery level is immediately upgraded to the corresponding higher level. This aims to respond promptly to worsening risk trends and prevent recovery actions from lagging behind the actual threat. If the score drops to a lower range and persists for more than a preset time window, downgrading is allowed. This aims to reduce the recovery intensity in a timely manner when the risk has been mitigated, restoring some or all of the node's business capabilities and avoiding prolonged unnecessary resource occupation and business interruption. This dynamic adjustment mechanism enables the recovery process to be adaptive, flexibly matching the optimal response intensity according to real-time risk evolution.

[0149] In a specific embodiment of the present invention, five types of fault risk scores output by the hybrid neural network model are acquired in real time: block lag risk score. View Lagging Risk Score Malicious attack risk score Data tampering risk score Cross-chain interaction failure risk scoring Each score ranges from [0,1]. To standardize the triggering criteria for the recovery process, this invention introduces a comprehensive risk score. The maximum value among the five risk categories is taken as the comprehensive risk score. The reason for adopting the maximum value criterion is that if the risk in any dimension exceeds the security boundary, it may have an irreversible impact on node functionality or network consensus. Therefore, the highest risk dimension is used as the triggering basis to ensure the conservatism and security of the recovery process.

[0150] Furthermore, the initial thresholds for each risk score are determined through ROC and PR curve analysis, aiming to maximize the Youden index or the F1 score. Preferred values ​​are: 0.7 for block lag risk, 0.65 for view lag risk, 0.75 for malicious attack risk, 0.8 for data tampering risk, and 0.6 for cross-chain interaction failure risk. These thresholds are preferred embodiments and can be adjusted according to chain type, network size, and business SLA requirements.

[0151] When any risk score exceeds its independent preset threshold, the system calculates a comprehensive risk score. and based on By comparing the risk score with the preset threshold range, the following mapping relationship between risk score and recovery level is established.

[0152] Table 2

[0153] Mapping relationship explanation:

[0154] (1) When When the value is less than 0.6, all risk dimensions are within the safe range, the node maintains normal operation, and the recovery process is not triggered.

[0155] (2) The trigger condition for Level 1 recovery (low risk) is 0.6≤ <0.7. At this point, the score for at least one risk dimension has exceeded its corresponding independent threshold (such as the cross-chain interaction failure threshold of 0.6 or the view lag threshold of 0.65), but the overall risk is still within a controllable range. Only incremental synchronization is performed, which does not affect the normal transaction processing of the node.

[0156] (3) The trigger condition for Level 2 recovery (medium risk) is 0.7≤ <0.85. At this point, at least two or more risk dimensions, or higher-risk dimensions, have exceeded the threshold, posing a risk to consensus and transaction processing. Suspend the node's transaction processing function and execute the sharding synchronization strategy.

[0157] (4) The triggering condition for Level 3 recovery (high risk) is: ≥0.85. This indicates a serious risk of failure; the node may have been compromised or significantly deviated from the consensus. Immediately isolate the node, perform a full synchronization, and initiate a security scan.

[0158] Furthermore, when multiple risk dimensions simultaneously exceed their respective thresholds, the recovery level is determined based on the comprehensive risk score. Determined; when the independent thresholds corresponding to different risk types span different recovery level ranges, The range in which the data falls shall be used as the standard. For example, if the data tampering risk score... =0.82 (exceeding its independent threshold of 0.8 but not exceeding 0.85), while other risk scores are all below their respective thresholds, then =0.82, falling into the level 2 recovery range, and the medium-risk recovery process will be executed. If If it continues to rise to 0.86, then =0.86, upgraded to Level 3 recovery.

[0159] Recovery level can be dynamically adjusted: during the recovery process, if... If the price drops to a lower range and persists for more than a preset time window (e.g., 5 minutes), it can be downgraded for execution; if If the price continues to rise and enters a higher range, the recovery level should be upgraded immediately.

[0160] Furthermore, the AI ​​prediction module outputs risk score messages to the intelligent decision-making layer via gRPC, REST, or message queues. The message format includes node ID, timestamp, block lag score, view lag score, malicious attack score, data tampering score, cross-chain interaction failure score, and confidence level. The intelligent decision-making layer subscribes to or polls these messages, comparing each risk score with its corresponding threshold; if any risk score exceeds the threshold, a calculation is performed. The system then invokes the node agent interface to trigger the recovery process. Interface parameters include the node ID, risk type, risk score, recovery level, and policy hints. Upon receiving the information, the node agent switches the node status to "recovery status" and returns a confirmation receipt. The recovery event is written to the audit log and optionally to the blockchain via hash-based notation. The interface employs mTLS, certificate or token authentication, idempotent IDs, and a timeout retry mechanism.

[0161] Furthermore, the list of standby master nodes includes the view number or block height, node ID, public key, stability score, real-time risk score, version number, and signature. The list is calculated independently by each node or by a smart contract, confirmed by a 2f+1 signature using PBFT consensus, and then broadcast to the entire network via the Gossip protocol. Upon receiving the list, nodes verify the signature, height, version number, and random number. Once verified, the list is stored in a protected local key-value database or trusted execution environment. The Merkle root or hash value of the list can be written to the Orderer log or stored on-chain to prevent malicious tampering and replay. List updates must meet multi-signature or threshold signature conditions. If a standby master node is found to be malicious, unreachable, or has a risk score exceeding a threshold, other nodes can add it to a blacklist and trigger a re-election.

[0162] Furthermore, to prevent adversarial attacks on the model and reduce false positives, this invention employs the following mechanisms: range verification, rate verification, and distribution drift detection are performed on the input data; Gaussian noise, adversarial examples, and regularization are added during the training phase to improve model robustness; multi-model or multi-task consistency verification, confidence gating, and sliding window smoothing are used during the deployment phase; the recovery process is triggered only when the risk score exceeds the threshold N times consecutively and the confidence level is greater than a preset value; a hysteresis interval is set to avoid frequent recovery caused by score fluctuations near the threshold; secondary verification, such as hash sampling, signature verification, or manual review, can be performed before triggering high-risk recovery; low-risk recovery supports rollback. The system records false positive samples and uses them for subsequent incremental updates.

[0163] In one specific embodiment of the present invention, based on the dynamic operating factors of the blockchain nodes, a synchronization strategy is adaptively selected through a dynamic weight decision model to synchronize the data of the blockchain nodes. Specifically,

[0164] Four dynamic operating factors are obtained: block difference, network bandwidth, node load health, and data importance level. These four dynamic operating factors are then standardized to a uniform value range, wherein node load health is negatively correlated with node load rate.

[0165] The comprehensive decision score S is calculated based on four dynamic operating factors, and the comprehensive decision score S is expressed as follows:

[0166] ;

[0167] in, , , , These are the standardized block differences, network bandwidth, node load health, and data importance level, respectively. , , , These are the weight coefficients of the corresponding factors, and , ;

[0168] Based on the comprehensive decision score The preset interval into which the score falls is selected by choosing a corresponding synchronization strategy from full synchronization, incremental synchronization, fragmented synchronization, and emergency synchronization. The preset interval includes a first score threshold that decreases sequentially. Second scoring threshold and the third scoring threshold Specifically, including,

[0169] when When selecting full synchronization, When choosing incremental synchronization, When selecting split synchronization, when Select emergency synchronization at this time;

[0170] Among them, Level 1 recovery prioritizes triggering the incremental synchronization strategy, Level 2 recovery prioritizes triggering the sharded synchronization strategy, and Level 3 recovery forcibly triggers the full synchronization strategy. The dynamic weight decision model further adaptively selects based on the priority or forced strategy of the corresponding recovery level.

[0171] It should be noted that the adaptive selection of synchronization strategies for blockchain nodes through a dynamic weighted decision model aims to further select the most suitable data synchronization method based on the dynamic changes in the node's current operating environment, under the constraints of a determined recovery level. This achieves dual adaptation of "risk-driven grading" and "environment-driven strategy." Traditional fault recovery often employs fixed synchronization strategies, which cannot take into account real-time changes in factors such as block size differences, network conditions, node load, and data importance, easily leading to excessively long recovery times or wasted resources. This step introduces four core dynamic operating factors and constructs a weighted comprehensive decision score, enabling the system to flexibly choose full, incremental, sharded, or emergency synchronization within the priority or mandatory strategy framework given by the recovery level. This ensures that the recovery action matches the severity of the risk while maximizing the utilization of currently available resources, improving synchronization efficiency and overall system availability.

[0172] Furthermore, four dynamic operational factors—block difference, network bandwidth, node load health, and data importance level—are identified and standardized to a uniform numerical range. Block difference reflects the gap between a node's current ledger and the latest state of the entire network, serving as the core basis for determining the amount of data to be synchronized. Network bandwidth characterizes a node's available data transmission capacity, directly impacting synchronization speed and feasibility. Node load health is negatively correlated with node load rate, measuring a node's current capacity to handle additional synchronization tasks; lower load indicates higher health, making it more suitable for resource-intensive synchronization operations. Data importance level distinguishes the priority of ordinary business data from critical business or cross-chain related data. By standardizing these four factors, differences in dimensions and magnitudes are eliminated, allowing them to participate in subsequent weighted calculations on the same scale, ensuring the fairness and stability of the decision-making results.

[0173] Furthermore, after obtaining the four standardized dynamic operating factors, a comprehensive decision score is calculated based on them. This score is obtained by weighted summation after assigning different weights to each factor. The weight settings reflect the priority of each factor's impact on the selection of synchronization strategies: block difference, as the primary factor determining the amount of synchronized data, is given the highest weight; network bandwidth, as a key condition restricting transmission efficiency, is given the second highest weight; node load health reflects the feasibility of performing synchronization and is given a moderate weight; data importance level is used to fine-tune priorities and is given a relatively low weight. Through this weighting method, the comprehensive decision score can comprehensively reflect the suitability of executing different synchronization strategies in the current environment, providing a quantitative basis for subsequent strategy selection.

[0174] Furthermore, based on the preset intervals into which the comprehensive decision score falls, a corresponding synchronization strategy is selected from full synchronization, incremental synchronization, fragmented synchronization, and emergency synchronization. The preset intervals are divided using progressively decreasing score thresholds. When the comprehensive decision score is in a high interval, it indicates significant block differences and network and load conditions allow; full synchronization is selected to thoroughly align the ledger. When the score is in a medium-high interval, it indicates manageable differences and moderate resource conditions; incremental synchronization is selected to synchronize only the missing parts, improving efficiency. When the score is in a medium-low interval, it indicates significant differences but limited bandwidth or load; fragmented synchronization is selected for parallel transmission, fully utilizing limited resources. When the score is in the lowest interval, it indicates an extremely constrained environment or an urgent need to restore basic functionality; emergency synchronization is selected to synchronize only the most recent critical blocks, quickly restoring minimum node availability. This mapping relationship ensures that the synchronization strategy selection closely matches the current environmental conditions, avoiding forced heavy-load synchronization when resources are insufficient, or the use of inefficient methods when conditions permit.

[0175] It is important to emphasize that the adaptive selection based on the comprehensive decision score is not entirely independent, but rather constrained by the priority or mandatory strategies given for the corresponding recovery level. Level 1 recovery prioritizes and triggers an incremental synchronization strategy, Level 2 recovery prioritizes and triggers a sharded synchronization strategy, and Level 3 recovery forcibly triggers a full synchronization strategy. Within the above priority or mandatory framework, the dynamic weighted decision model further optimizes or confirms the results based on the real-time comprehensive decision score, thereby ensuring that the recovery strength matches the risk level while fully utilizing the current dynamic environmental information, achieving dual adaptation of risk and resources.

[0176] In a specific implementation scenario of this invention, the optimal synchronization strategy is selected based on a dynamic weighted decision model, comprehensively considering four dynamic factors: block difference, network bandwidth, node load health, and data importance level. The Analytic Hierarchy Process (AHP) is used to determine the weights of each factor: block difference weight is 0.4, network bandwidth weight is 0.3, node load health weight is 0.2, and data importance level weight is 0.1. A comprehensive decision score is then calculated. All factors have been standardized to the [0,1] interval.

[0177] Select a synchronization strategy based on the overall score range:

[0178] When S ≥ 0.8, select the full synchronization strategy: suitable for scenarios with large block differences (more than 1000 blocks), sufficient network bandwidth, and low node load, to ensure data integrity and consistency;

[0179] When 0.5 ≤ S < 0.8, choose the incremental synchronization strategy: suitable for scenarios with moderate block differences (100-1000 blocks) and general network bandwidth, only synchronize missing block data to improve synchronization efficiency;

[0180] When 0.2 ≤ S < 0.5, select the fragmentation synchronization strategy: suitable for scenarios where there are large differences between blocks but limited network bandwidth, the block data is divided into multiple fragments and synchronized in parallel to make full use of network resources;

[0181] When S < 0.2, select the emergency synchronization strategy: suitable for emergency recovery scenarios, only synchronize the most recent 100 blocks and key business data to quickly restore the basic functions of the node, and then perform a full synchronization later.

[0182] Furthermore, during sharded synchronization, block data is divided into multiple shards based on block height ranges or state roots. Each shard calculates its Merkle root, and all shards are combined to verify the global state root after synchronization. During synchronization, nodes are marked as "recovering," "read-only," or "observational," suspending participation in consensus voting and initiating cross-chain transactions. Transactions can be forwarded to other normal nodes or placed in a buffer queue. In emergency synchronization, only the most recent 100 blocks and critical business data are synchronized. Nodes operate in restricted mode, ensuring temporary verifiable consistency through checkpoints, state roots, and hashes of critical business data. After subsequent full synchronization is completed and passes three levels of verification, the nodes switch to normal mode.

[0183] In one specific embodiment of the present invention, after data synchronization is completed, the synchronization result is sequentially subjected to data hash verification, consensus state verification, and business logic testing, specifically,

[0184] The data hash verification is used to perform hash calculation on the synchronized block data and compare it with the hash value of the latest block in the entire network. After the comparison is successful, it enters the consensus state verification.

[0185] The consensus state verification is used to verify whether the view number, consensus message signature and voting result of the blockchain node are correct. After the verification is passed, the business logic test is initiated.

[0186] The business logic test is used to execute a preset set of test transactions to verify whether the transaction processing results of the blockchain node are consistent with those of the entire network.

[0187] After the data hash verification, consensus state verification, and business logic test are all passed in sequence, the state of the blockchain node is switched from the recovery state back to the normal state; if any verification fails, the processing corresponding to the failed item is re-executed.

[0188] It should be noted that performing data hash verification, consensus state verification, and business logic testing on the synchronization results sequentially is to conduct multi-layered, progressive verification of the correctness and consistency of the synchronized node data. This ensures that nodes can safely and reliably rejoin the network consensus and business processing after recovery, preventing faulty nodes from being reintegrated into the system due to incomplete synchronization, state deviations, or abnormal business logic. Traditional recovery mechanisms often rely solely on simple hashing or height comparisons, making it difficult to detect inconsistencies in the consensus state or deviations in business execution. This step constructs a three-tiered verification system of "data integrity → consensus state correctness → business logic consistency," forming a comprehensive closed-loop check from the underlying data to the upper-level functions. Only after all verifications pass can the node be allowed to switch back to the normal state, thereby effectively guaranteeing recovery quality and network-wide security.

[0189] Furthermore, a data hash verification is performed. This verification calculates the hash of all synchronized block data and compares it with the hash value of the latest block in the entire network. The purpose is to confirm at the data level that no tampering, loss, or transmission errors occurred during the synchronization process, ensuring that the node's local ledger is completely consistent with the entire network in terms of block content. Only if the hash comparison passes can the next level of verification proceed, avoiding further checks if the data itself has problems, thus preventing resource waste or misjudgments.

[0190] Furthermore, after the data hash verification passes, the consensus state verification begins. This verification checks whether the node's view number matches the current view number across the entire network. Figure 1 The consensus mechanism verifies key consensus parameters such as the validity of consensus message signatures and the correctness of voting results. Its purpose is to confirm that nodes possess the capability to correctly participate in subsequent consensus processes at the consensus protocol level, preventing consensus failures or view switching oscillations caused by lagging views, abnormal signatures, or voting state discrepancies after a node rejoins. Only after the consensus state verification is successful is the node allowed to proceed to the final check at the business logic level.

[0191] Furthermore, business logic testing is then performed. This test verifies whether the node's transaction processing results and smart contract execution outputs are consistent with the entire network by executing a pre-set set of test transactions (including ordinary transfers, smart contract calls, and cross-chain interaction transactions). Its purpose is to confirm from the perspective of actual business functionality that the node has fully recovered its normal processing capabilities, especially its support for cross-chain related businesses, preventing nodes that appear normal in terms of data and consensus but have hidden business logic vulnerabilities from being re-launched. Business logic testing is the final checkpoint in the three-tier verification process; only when this test passes can it be confirmed that the node truly possesses the conditions to provide services externally. In this embodiment, a pre-set set of 100 test transactions is executed. If the business logic test fails, a secondary recovery process is triggered.

[0192] Furthermore, after the data hash verification, consensus state verification, and business logic test all pass sequentially, the system switches the blockchain node's state from the recovery state back to the normal state, restoring its transaction processing and consensus participation functions. If any verification fails, the corresponding processing is re-executed for the specific level that failed: if hash verification fails, the corresponding block data is resynchronized; if consensus state verification fails, view switching or state alignment is re-executed; if business logic test fails, a higher-level recovery process or further investigation is triggered. This "step-by-step verification, failure rollback" mechanism ensures the rigor and recoverability of the verification process.

[0193] In one specific embodiment of the present invention, an election score is obtained by fusing the historical stability score of a node with the real-time risk prediction result of AI, and a backup master node is elected in advance. Specifically,

[0194] Based on the blockchain node's online rate, consensus participation rate, view switching success rate, and / or transaction processing success rate over a preset period, calculate the... Historical stability score of each node The historical stability score Represented as:

[0195] ;

[0196] in, , , , These are the weighting coefficients for the corresponding indicators, and ;

[0197] The real-time risk score output by the hybrid neural network model is combined with the data. Calculate the fusion election score The fusion election score Represented as:

[0198] ;

[0199] Where α and β are weighting coefficients, and α + β = 1, Take the maximum or weighted value among the five risk scores;

[0200] The fusion election score is selected according to a preset block height interval. The maximum preset number of nodes are designated as backup master nodes, and the election results are broadcast to the entire network; if a node's real-time risk score... If the threshold is exceeded, the node will be removed from the list of standby master nodes or downgraded.

[0201] When the failure risk score of the current master node exceeds a preset threshold, the fusion election score is selected from the backup master nodes. The node with the highest real-time risk score and a score below a preset threshold is designated as the new master node, and a view switching notification message containing the new master node information is broadcast to the entire network. The view switching is completed after receiving a confirmation message.

[0202] It should be noted that the early election of backup master nodes optimizes the view switching process in the traditional PBFT consensus algorithm. By pre-electing and maintaining a set of highly reliable backup master nodes, the switching latency in the event of a master node failure is significantly shortened, while reducing the risk of switching failure. Traditional PBFT view switching relies on temporary requests and voting processes after a failure occurs, which suffers from problems such as multiple rounds of message interaction, strong election randomness, and susceptibility to immediate risks. This step integrates the long-term performance of nodes with the real-time risk prediction results of AI models to form an election score that balances historical reliability and current security. During normal operation, the backup master node list is continuously maintained, enabling the system to quickly switch directly from the pre-selected list when a master node faces high risk, thereby improving consensus continuity and the overall fault tolerance of the system.

[0203] Furthermore, based on the online rate, consensus participation rate, view switching success rate, and transaction processing success rate of blockchain nodes over a preset period, a historical stability score is calculated for each node. These indicators reflect the long-term reliability of nodes from different dimensions: the online rate reflects the node's continuous availability; the consensus participation rate reflects its activity and correctness in the consensus process; the view switching success rate measures its stability during historical switching events; and the transaction processing success rate characterizes the continued effectiveness of its business processing. By weighting and synthesizing the above indicators, a score that objectively characterizes the long-term stability of nodes is obtained, providing a historical basis for subsequent elections.

[0204] Furthermore, after obtaining the historical stability score, a fused election score is calculated by combining it with the real-time risk score output by the hybrid neural network model. The real-time risk score reflects the immediate threats faced by nodes, such as block lag, view lag, malicious attacks, data tampering, or cross-chain interaction failures. The fusion process weights and combines historical stability with real-time risk, ensuring that the election results prioritize nodes with excellent long-term performance while proactively avoiding nodes that currently exhibit high risks. In this way, the election score can dynamically balance the two dimensions of "long-term reliability" and "immediate security," avoiding the selection of nodes that are about to fail based solely on historical data, or the selection of nodes that are about to fail based solely on real-time data while ignoring long-term stability.

[0205] Furthermore, at preset block height intervals, a predetermined number of nodes with the highest fusion election scores are periodically elected as backup master nodes, and the election results are broadcast to the entire network. The purpose of periodic advance elections is to continuously maintain a backup list confirmed by the entire network during normal system operation, ensuring that when a master node fails, there are already readily available high-scoring candidate nodes that can be directly selected without initiating a complete election process on an ad hoc basis. The broadcast mechanism ensures that all nodes in the network have a consistent understanding of the backup list. At the same time, if a node's real-time risk score exceeds a preset threshold, the node is immediately removed from the backup master node list or downgraded to prevent high-risk nodes from entering or remaining in the candidate sequence, further enhancing the security of the list.

[0206] Furthermore, when the fault risk score of the current master node exceeds a preset threshold, the system directly selects the node with the highest fusion election score and a real-time risk score below the preset threshold from the list of standby master nodes as the new master node. It then broadcasts a view switch notification message containing information about the new master node to the entire network. After receiving sufficient confirmation messages, the view switch is completed. This process simplifies the traditional multi-round "request-vote-confirmation" interaction into a two-step "notification-confirmation" process, significantly reducing the number of message interactions and switchover latency. Because the standby node has already undergone fusion score screening and network-wide broadcast confirmation, the switchover process significantly improves response speed and success rate while maintaining Byzantine fault tolerance.

[0207] In one specific implementation scenario of the present invention, during the node recovery process, the view switching process of the PBFT consensus algorithm is optimized, and a backup master node early election mechanism based on the fusion of historical stability scores and AI real-time risk prediction results is designed.

[0208] A basic stability score is calculated based on the node's online rate, consensus participation rate, view switching success rate, and transaction processing success rate over the past 30 days. The rating ranges from 0 to 1, with higher ratings indicating greater node stability. The calculation formula is:

[0209] = 0.3 × Online Rate + 0.3 × Consensus Participation Rate + 0.2 × View Switching Success Rate + 0.2 × Transaction Processing Success Rate

[0210] Historical stability scores are also dynamically influenced by real-time risk predictions from AI. During elections, the node's basic stability score is calculated first. Then obtain the real-time risk score predicted by AI. , The maximum value or weighted value among the five risk categories can be selected; final election score. = 0.7× + 0.3×(1- ).like If the risk threshold is exceeded, the node is removed from the list of standby master nodes or downgraded. Thus, historical stability ensures long-term reliability, and real-time risk prediction prevents the election of nodes that are about to fail or be attacked.

[0211] Furthermore, under normal operating conditions, the fusion election score of all Orderer nodes is automatically calculated every 100 block heights. ,election The top 3 nodes are selected as backup master nodes, and the election results are broadcast to the entire network. All nodes maintain a list of backup master nodes.

[0212] The backup master node early election process possesses Byzantine fault tolerance: the online rate, consensus participation rate, view switching success rate, and transaction processing success rate, upon which the stability score relies, are all verifiable indicators on-chain or in the monitoring system; each node independently calculates candidate node scores and exchanges signature results, which are aggregated and confirmed according to the PBFT 2f+1 rule; the backup master node list is submitted as the consensus result, including view height, version number, random number, and node signature. If a backup master node acts maliciously or becomes unreachable, other nodes reject its message and select the next candidate node in turn; view switching requires Quorum confirmation to prevent a single node from forging switching results.

[0213] Furthermore, when the primary node failure risk score exceeds the threshold (0.75 in this embodiment), a primary node is directly selected from the list of standby primary nodes. Below the threshold and The highest-ranking node becomes the new master node, skipping the traditional PBFT view request and voting phases, significantly shortening the view switching time.

[0214] Furthermore, in a specific implementation scenario of the present invention, new operational data is collected periodically to perform incremental updates and version management on the hybrid neural network model.

[0215] Preferably, the model is updated weekly, with new node running data and failure cases collected weekly to update the dataset. An incremental update strategy is adopted, where only the model parameters are fine-tuned on the new dataset, and the learning rate is set to 1 / 10 of the initial learning rate, reducing model update time and computational resource consumption.

[0216] Establish a sound model version management mechanism to save different versions of the model and their performance indicators. When a new model experiences performance degradation or anomalies, it can be quickly rolled back to the previous stable version.

[0217] Set a model performance monitoring threshold. When the model's prediction accuracy is below 0.85 for three consecutive days, automatically trigger a full update process to retrain the model to adapt to the new failure mode.

[0218] Model updates employ a canary release and secure switchover mechanism: the new model is first run in shadow mode in a bypass environment, inferring in parallel with the old model and comparing the results; canary releases are gradually rolled out at node ratios of 1%, 5%, 20%, and 100%, prioritizing deployment during off-peak periods and on backup nodes; the accuracy, false positive rate, inference latency, and resource consumption of the new model are monitored, and if any metrics are abnormal, the model is automatically rolled back to the previous stable version; model files are converted to TensorFlow Lite and hashed, Docker images are signed and verified, and historical versions are saved in the repository; during switching, dual-model voting or A / B testing can be used to ensure update security.

[0219] In a second embodiment of the present invention, the present invention provides an AI-predictive-based adaptive synchronization fault recovery system for blockchain nodes, the system comprising:

[0220] Data acquisition module 1 is used to collect basic operational data, transaction and business data, and security and fault data of blockchain nodes, and to preprocess them to form a standardized dataset;

[0221] AI prediction module 2 is used to construct and train a hybrid neural network model that integrates long short-term memory network, gated recurrent unit and attention mechanism based on the standardized dataset. It outputs the block lag risk score, view lag risk score, malicious attack risk score, data tampering risk score and cross-chain interaction failure risk score of the node in real time through multi-task learning.

[0222] The intelligent decision module 3 is used to calculate a comprehensive risk score based on five risk scores, and determine the corresponding recovery level from multiple preset recovery levels based on the preset threshold range into which the comprehensive risk score falls, and trigger the recovery process of the corresponding level, while switching the state of the blockchain node from the normal state to the recovery state.

[0223] The synchronization execution module 4 is used to adaptively select a synchronization strategy to synchronize data of the blockchain node based on the dynamic operating factors of the blockchain node through a dynamic weight decision model; after the data synchronization is completed, the synchronization result is sequentially subjected to data hash verification, consensus state verification and business logic testing, and after all verifications are passed, the state of the blockchain node is switched from the recovery state back to the normal state.

[0224] The status monitoring module 5 is used to elect a backup master node in advance based on the election score obtained by fusing the node's historical stability score and the AI ​​real-time risk prediction results while the blockchain node is in a normal or recovery state; when the fault risk score of the current master node exceeds a preset threshold, the view switching process is optimized based on the backup master node.

[0225] In a third embodiment of the present invention, the present invention provides an electronic device, including a memory and a processor, characterized in that the memory stores a computer program that can run on the processor, and when the program is executed on the processor, it implements the steps in the AI-predictive-based adaptive synchronization fault recovery method for blockchain nodes as described above.

[0226] In Embodiment 4 of the present invention, the present invention provides a storage medium storing a computer program, characterized in that, when the computer program is executed by a processor, it implements the steps in the AI-predictive-based adaptive synchronization fault recovery method for blockchain nodes as described above.

[0227] In summary, the present invention provides a blockchain node adaptive synchronization fault recovery method and system based on AI prediction. It achieves joint active prediction of five types of risks through a multi-task hybrid neural network, and drives intelligent hierarchical recovery and dynamic synchronization strategy selection with comprehensive risk scoring, forming a closed-loop self-healing mechanism from prediction, decision-making, execution to verification. At the same time, it optimizes the view switching process and takes into account cross-chain fault scenarios, effectively overcoming the shortcomings of passive lag, rigid strategies and fragmented systems in existing technologies, and significantly improving the self-healing ability, stability and security of blockchain nodes in complex environments.

[0228] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the modules described above can be referred to the corresponding process in the aforementioned method implementation, and will not be repeated here.

[0229] The modules described as separate components may or may not be physically separate. Similarly, the components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0230] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated module can be implemented in hardware or in a combination of hardware and software functional modules.

[0231] The integrated modules implemented as software functional modules described above can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer system (which may be a personal computer, server, or network system, etc.) or processor to execute some steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0232] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application 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. Such 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 this application.

Claims

1. A blockchain node adaptive synchronization fault recovery method based on AI prediction, characterized in that: include, Collect basic operational data, transaction and business data, and security and fault data of blockchain nodes, and preprocess them to form a standardized dataset. Based on the standardized dataset, a hybrid neural network model integrating long short-term memory network, gated recurrent unit and attention mechanism is constructed and trained. The model outputs the block lag risk score, view lag risk score, malicious attack risk score, data tampering risk score and cross-chain interaction failure risk score of the node in real time through multi-task learning. A comprehensive risk score is calculated based on five risk scores. Based on the preset threshold range into which the comprehensive risk score falls, the corresponding recovery level is determined from multiple preset recovery levels and the recovery process of the corresponding level is triggered. At the same time, the state of the blockchain node is switched from the normal state to the recovery state. Based on the dynamic operating factors of the blockchain node, a synchronization strategy is adaptively selected through a dynamic weight decision model to synchronize the data of the blockchain node; after the data synchronization is completed, the synchronization results are sequentially verified by data hash, consensus state verification and business logic testing, and after all verifications are passed, the state of the blockchain node is switched from the recovery state back to the normal state. During the period when the blockchain node is in a normal or recovery state, an alternative master node is elected in advance based on the election score obtained by fusing the node's historical stability score with the AI ​​real-time risk prediction result. When the failure risk score of the current master node exceeds a preset threshold, the view switching process is optimized based on the backup master node.

2. The AI-predictive-based adaptive synchronization fault recovery method for blockchain nodes according to claim 1, characterized in that: The collected basic operational data, transaction and business data, and security and fault data of blockchain nodes are preprocessed to form a standardized dataset. include, The basic operational data collected includes at least block synchronization delay time, consensus message response time, network jitter frequency, and CPU utilization. The transaction and business data includes at least transaction processing success rate, transaction processing delay, and cross-chain transaction quantity. The security and fault data includes at least malicious attack records, data tampering attempt records, and node historical fault records. The collected multidimensional feature data is sequentially subjected to data cleaning, data standardization, and redundant feature removal to obtain the standardized dataset. The data cleaning is used to identify and process outliers and missing values, the data standardization is used to map the data to a uniform numerical range, and the redundant feature removal is used to filter and retain features based on the correlation between features and node faults and dimensionality reduction analysis. The standardized dataset is divided into a training set, a validation set, and a test set according to a preset ratio. The training set is used for training the hybrid neural network model, the validation set is used for validating the hybrid neural network model, and the test set is used for performance evaluation of the hybrid neural network model.

3. The AI-predictive-based adaptive synchronization fault recovery method for blockchain nodes according to claim 2, characterized in that: The construction and training of the hybrid neural network model integrating long short-term memory networks, gated recurrent units, and attention mechanisms includes, The input layer dimension of the hybrid neural network model corresponds to the feature dimension of the standardized dataset. The hidden layer includes multiple long short-term memory network units, multiple gated recurrent units, and at least one attention layer. The output layer includes five output nodes corresponding to the block lag risk score, view lag risk score, malicious attack risk score, data tampering risk score, and cross-chain interaction failure risk score, respectively. During the training process of the hybrid neural network model, the comprehensive loss function is minimized using the backpropagation algorithm. The comprehensive loss function is expressed as: ； in, , , , , These are the loss functions for the block lag risk prediction task, view lag risk prediction task, malicious attack risk prediction task, data tampering risk prediction task, and cross-chain interaction failure risk prediction task, respectively. , , , , These are the weight coefficients for the corresponding tasks, and , and All greater than , and .

4. The AI-predictive-based adaptive synchronization fault recovery method for blockchain nodes according to claim 3, characterized in that: The step of determining the corresponding recovery level from multiple preset recovery levels based on the preset threshold range into which the comprehensive risk score falls, and triggering the corresponding recovery process, while simultaneously switching the state of the blockchain node from normal to recovery state, includes: The comprehensive risk score Represented as: ； in, , , , , These are respectively the block lag risk score, view lag risk score, malicious attack risk score, data tampering risk score, and cross-chain interaction failure risk score; The preset threshold range includes a first threshold that increases sequentially. Second threshold and the third threshold Specifically, including, when When, the recovery process is not triggered; when When, trigger Level 1 recovery; when When, trigger level 2 recovery; when At that time, a level 3 recovery is triggered; The first-level recovery includes triggering an incremental synchronization strategy and allowing the node to continue processing transactions; the second-level recovery includes pausing the node's transaction processing function and executing a sharding synchronization strategy; and the third-level recovery includes isolating the node, executing a full synchronization strategy, and initiating a security scan. During the recovery process, if the comprehensive risk score is... If the current recovery level is upgraded to the higher recovery level corresponding to the higher threshold range entered, then the recovery level will be upgraded accordingly. If the price drops to a lower range and continues for more than the preset time window, then a downgrade will be implemented.

5. The AI-predictive-based adaptive synchronization fault recovery method for blockchain nodes according to claim 4, characterized in that: Based on the dynamic operating factors of the blockchain nodes, a dynamic weighted decision model is used to adaptively select a synchronization strategy to synchronize the data of the blockchain nodes, including: Four dynamic operating factors are obtained: block difference, network bandwidth, node load health, and data importance level. These four dynamic operating factors are then standardized to a uniform value range, wherein node load health is negatively correlated with node load rate. The comprehensive decision score S is calculated based on four dynamic operating factors, and the comprehensive decision score S is expressed as follows: ； in, , , , These are the standardized block differences, network bandwidth, node load health, and data importance level, respectively. , , , These are the weight coefficients of the corresponding factors, and , ; Based on the comprehensive decision score The preset interval into which the score falls is selected by choosing a corresponding synchronization strategy from full synchronization, incremental synchronization, fragmented synchronization, and emergency synchronization. The preset interval includes a first score threshold that decreases sequentially. Second scoring threshold and the third scoring threshold Specifically, including, when When selecting full synchronization, When choosing incremental synchronization, When selecting split synchronization, when Select emergency synchronization at this time; Among them, Level 1 recovery prioritizes triggering the incremental synchronization strategy, Level 2 recovery prioritizes triggering the sharded synchronization strategy, and Level 3 recovery forcibly triggers the full synchronization strategy. The dynamic weight decision model further adaptively selects based on the priority or forced strategy of the corresponding recovery level.

6. The AI-predictive-based adaptive synchronization fault recovery method for blockchain nodes according to claim 5, characterized in that: After data synchronization is complete, the synchronization results are sequentially subjected to data hash verification, consensus state verification, and business logic testing, including: The data hash verification is used to perform hash calculation on the synchronized block data and compare it with the hash value of the latest block in the entire network. After the comparison is successful, it enters the consensus state verification. The consensus state verification is used to verify whether the view number, consensus message signature and voting result of the blockchain node are correct. After the verification is passed, the business logic test is initiated. The business logic test is used to execute a preset set of test transactions to verify whether the transaction processing results of the blockchain node are consistent with those of the entire network. After the data hash verification, consensus state verification, and business logic test are all passed in sequence, the state of the blockchain node will be switched from the recovery state back to the normal state. If any of the validations fails, the processing corresponding to the failed item will be re-executed.

7. The AI-predictive-based adaptive synchronization fault recovery method for blockchain nodes according to claim 6, characterized in that: The election score, obtained by fusing the node's historical stability score with the AI ​​real-time risk prediction result, is used to elect a backup master node in advance, including... Based on the blockchain node's online rate, consensus participation rate, view switching success rate, and / or transaction processing success rate over a preset period, calculate the... Historical stability score of each node The historical stability score Represented as: ； in, , , , These are the weighting coefficients for the corresponding indicators, and ; The real-time risk score output by the hybrid neural network model is combined with the data. Calculate the fusion election score The fusion election score Represented as: ； Where α and β are weighting coefficients, and α + β = 1, Take the maximum or weighted value among the five risk scores; The fusion election score is selected according to a preset block height interval. The maximum preset number of nodes are designated as backup master nodes, and the election results are broadcast to the entire network; if a node's real-time risk score... If the threshold is exceeded, the node will be removed from the list of standby master nodes or downgraded. When the failure risk score of the current master node exceeds a preset threshold, the fusion election score is selected from the backup master nodes. The node with the highest real-time risk score and a score below a preset threshold is designated as the new master node, and a view switching notification message containing the new master node information is broadcast to the entire network. The view switching is completed after receiving a confirmation message.

8. A blockchain node adaptive synchronization fault recovery system based on AI prediction, applied to the blockchain node adaptive synchronization fault recovery method based on AI prediction as described in any one of claims 1-7, characterized in that, include: The data acquisition module is used to collect basic operational data, transaction and business data, and security and fault data of blockchain nodes, and to preprocess them to form a standardized dataset. The AI ​​prediction module is used to construct and train a hybrid neural network model that integrates long short-term memory network, gated recurrent unit and attention mechanism based on the standardized dataset. It outputs the block lag risk score, view lag risk score, malicious attack risk score, data tampering risk score and cross-chain interaction failure risk score of the node in real time through multi-task learning. The intelligent decision-making module is used to calculate a comprehensive risk score based on five risk scores, and determine the corresponding recovery level from multiple preset recovery levels based on the preset threshold range in which the comprehensive risk score falls, and trigger the recovery process of the corresponding level, while switching the state of the blockchain node from the normal state to the recovery state. The synchronization execution module is used to adaptively select a synchronization strategy to synchronize data of the blockchain node based on the dynamic operating factors of the blockchain node through a dynamic weight decision model; after the data synchronization is completed, the synchronization result is sequentially subjected to data hash verification, consensus state verification and business logic testing, and after all verifications are passed, the state of the blockchain node is switched from the recovery state back to the normal state. The status monitoring module is used to elect a backup master node in advance based on the election score obtained by fusing the node's historical stability score with the AI ​​real-time risk prediction results while the blockchain node is in a normal or recovery state. When the failure risk score of the current master node exceeds a preset threshold, the view switching process is optimized based on the backup master node.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements any one of claims 1 to 7 a blockchain node adaptive synchronization fault recovery method based on AI prediction.

10. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements any one of the AI ​​prediction-based adaptive synchronization fault recovery methods for blockchain nodes according to any one of claims 1 to 7.

Images