Security protection methods and blockchain service systems based on blockchain and big data

Abstract

This invention relates to the field of blockchain security protection technology, and discloses a security protection method and blockchain service system based on blockchain and big data. The method first acquires real-time behavioral data streams of each participating node in the target blockchain network, extracting behavioral feature vectors and their current security level status. Then, for each participating node, based on the distribution pattern of its behavioral feature vectors within historical time windows, it calculates the expected security level corresponding to each historical time window. Next, based on the difference between the expected security level and the current security level status, a dynamic threat score is generated. Finally, based on the dynamic threat score and the node's expected security level and current security level status in each historical time window, the predicted security level for the next time window is calculated. This method combines blockchain and big data technologies to achieve dynamic assessment and prediction of node security status, thereby improving the security protection capabilities of the blockchain network.

Description

Technical Field

[0001] This invention relates to the field of blockchain security protection technology, specifically to security protection methods and blockchain service systems based on blockchain and big data. Background Technology

[0002] With the rapid development of blockchain technology, its applications in finance, logistics, healthcare, and other fields are becoming increasingly widespread. While blockchain, with its decentralized, distributed ledger, and immutable characteristics, should possess high security, various security threats continue to emerge in practical applications.

[0003] Currently, attack methods targeting blockchain networks are constantly evolving, including malicious node injection, consensus mechanism attacks, and smart contract vulnerability exploitation. These attacks not only lead to data breaches and asset losses but also undermine the stability and credibility of blockchain networks. Traditional blockchain security methods often rely on static rules or single-dimensional monitoring indicators, making it difficult to cope with dynamically changing network environments and complex and diverse attack methods.

[0004] In terms of node behavior monitoring, existing technologies often only acquire partial behavioral data from nodes, lacking continuous tracking and analysis of node behavior throughout its entire lifecycle. Due to the large and dynamic number of nodes in a blockchain network, traditional methods struggle to achieve real-time monitoring and evaluation of all nodes. Furthermore, the classification of node security levels is relatively fixed and cannot be adjusted promptly based on changes in node behavior, leading to delays in identifying potential threats.

[0005] While big data technology has made it possible to process massive amounts of blockchain data, existing security solutions have shortcomings in data fusion, feature extraction, and analytical modeling. Most solutions fail to effectively combine the distributed nature of blockchain with the analytical capabilities of big data, making it difficult to extract valuable threat information from massive, heterogeneous node behavior data. Furthermore, in terms of security level prediction, existing methods mostly rely on simple trend inferences based on historical data, ignoring the correlation and dynamism of node behavior. This results in poor accuracy and timeliness of predictions, failing to provide effective decision-making references for proactive defense of blockchain networks. Summary of the Invention

[0006] The purpose of this invention is to provide a security protection method and blockchain service system based on blockchain and big data to solve the problems mentioned in the background art.

[0007] To achieve the above objectives, the present invention provides a security protection method based on blockchain and big data, the method comprising:

[0008] Obtain real-time behavioral data streams of each participating node in the target blockchain network, and extract the behavioral feature vectors and current security level status of the participating nodes;

[0009] For each participating node in the target blockchain network, it is taken as the target evaluation node. Based on the distribution pattern of the behavioral feature vector of the target evaluation node in the historical time window, the expected security level of the target evaluation node in each historical time window is calculated.

[0010] Based on the difference between the expected security level and the current security level, a dynamic threat score is generated for the target assessment node.

[0011] Based on the dynamic threat score and the expected security level and current security level status of the target assessment node in each historical time window, the predicted security level of the target assessment node in the next time window is calculated.

[0012] Preferably, the step of obtaining the expected security level includes:

[0013] Mark participating nodes that are continuously active within the historical time window as consensus nodes;

[0014] Based on the transaction behavior patterns, address distribution characteristics, and resource consumption of each consensus node within a historical time window, calculate the trust weight of each consensus node in each historical time window.

[0015] For non-consensus nodes, the trust weight of each non-consensus node in each historical time window is calculated based on its resource consumption within its active time window and its topological distance to neighboring consensus nodes.

[0016] The expected security level of each participating node is generated based on the trust weight mapping.

[0017] Preferably, the step of calculating the trust weight of each consensus node in each historical time window includes:

[0018] For any consensus node and any historical time window, the abnormal transaction feature points and feature point coordinates of each consensus node in each historical time window are extracted by the hash feature matching algorithm.

[0019] Based on the spatial coordinates of the registration addresses of each consensus node in the blockchain topology model and their historical transaction location information, combined with the network traffic direction, the effective communication node set of each consensus node and the coordinates of each node are determined.

[0020] The difference between the number of abnormal transaction feature points and the number of valid communication nodes is calculated as the behavior anomaly degree;

[0021] The reciprocal of the sum of the behavioral anomaly degree and the preset baseline value is marked as the initial trust coefficient;

[0022] Based on the proximity matching algorithm between the coordinates of the abnormal transaction feature points and the coordinates of the effective communication nodes, the number of successfully matched feature points is obtained as the effective interaction quantity.

[0023] Extract the percentage of resource consumption of each consensus node within each historical time window as the resource reliability coefficient;

[0024] The product of the effective interaction amount, the initial trust coefficient, and the resource trust coefficient is normalized to generate the trust weight of each consensus node.

[0025] Preferably, the step of calculating the trust weight of each non-consensus node in each historical time window includes:

[0026] For any non-consensus node and its active historical time window, calculate the minimum path hops between each non-consensus node and each consensus node within each historical time window, and use this as the network isolation degree.

[0027] The reciprocal of the sum of the network isolation degree and the preset isolation threshold is denoted as the topology reliability coefficient;

[0028] Extract the proportion of resource consumption of each non-consensus node within each historical time window, and use it as the resource contribution coefficient;

[0029] The product of the topology credibility coefficient and the resource contribution coefficient is normalized to generate a reference trust weight.

[0030] The difference between the total number of blockchain security levels and the preset level will be used as the base for level adjustment.

[0031] Divide the aforementioned level adjustment base by the total number of blockchain security levels to generate a weight correction factor;

[0032] The product of the weight correction factor and the reference trust weight is used as the final trust weight of each non-consensus node.

[0033] Preferably, the step of generating the expected security level of each participating node based on the trust weight mapping includes:

[0034] The range of trust weight values ​​is divided into continuous intervals, and the number of such continuous intervals is equal to the total number of blockchain security levels.

[0035] Each consecutive interval is assigned a corresponding security level label, where the interval with the highest trust weight corresponds to the lowest security risk level.

[0036] For any participating node and historical time window, when the trust weight of each participating node falls into a specific continuous interval, the security level label corresponding to the specific continuous interval is taken as the expected security level of each participating node.

[0037] Preferably, the step of generating the dynamic threat score for the target assessment node includes:

[0038] For any target evaluation node, calculate the level offset between its expected security level and current security level status in each historical time window;

[0039] The sum of the level offsets of all historical time windows is subjected to negative correlation transformation and normalization to generate the dynamic threat score of the target evaluation node.

[0040] Preferably, the step of calculating the predicted security level of the target evaluation node in the next time window includes:

[0041] If the dynamic threat score of the target assessment node is greater than the preset threat threshold, then the predicted security level of the target assessment node in the next time window is calculated based on its current security level status and its current security level status sequence in each historical time window.

[0042] If the dynamic threat score of the target assessment node is less than or equal to the preset threat threshold, then the predicted security level of the target assessment node in the next time window is calculated based on the comparison between the expected security level and the current security level status.

[0043] Preferably, the step of calculating the predicted security level of the target assessment node in the next time window based on its current security level status and its current security level status sequence in each historical time window if the dynamic threat score of the target assessment node is greater than a preset threat threshold includes:

[0044] Arrange the historical time windows involved in the target evaluation nodes in chronological order to generate a historical window sequence;

[0045] Extract the current security level status of the target evaluation node in each historical time window, and generate a security level sequence according to the historical window sequence order;

[0046] The safety level sequence is fitted to a linear function to generate a safety level change trend line;

[0047] If the slope of the security level change trend line is positive, the security level adjustment direction of the target evaluation node is set to an increasing mode;

[0048] If the slope of the security level change trend line is zero, the security level adjustment direction of the target evaluation node is set to stable mode;

[0049] If the slope of the security level change trend line is negative, the security level adjustment direction of the target evaluation node will be set to a decreasing mode.

[0050] The current security level status of the target evaluation node is superimposed with the security level adjustment direction to generate its predicted security level in the next time window.

[0051] Preferably, the step of calculating the predicted security level of the target assessment node in the next time window based on the comparison between the expected security level and the current security level status of the target assessment node if the dynamic threat score is less than or equal to a preset threat threshold includes:

[0052] Within the current time window, if the expected security level of the target evaluation node is less than or equal to the current security level, the expected security level of the target evaluation node will be used as its predicted security level in the next time window.

[0053] If the expected security level of the target evaluation node is greater than the current security level, the current security level will be used as its predicted security level in the next time window.

[0054] Preferably, the present invention also includes a blockchain service system, the system comprising a distributed storage module, a processor module, and a blockchain protocol program deployed in the distributed storage module, wherein when the processor module executes the blockchain protocol program, it implements the operation steps of the security protection method based on blockchain and big data as described above, wherein:

[0055] The distributed storage module synchronizes the behavioral data streams of each participating node in real time.

[0056] The processor module includes a threat analysis engine for calculating dynamic threat scores and predicting security levels;

[0057] The blockchain protocol program includes a security policy generator that dynamically adjusts node access permissions based on predicted security levels.

[0058] Compared with the prior art, the beneficial effects of the present invention are:

[0059] By acquiring real-time behavioral data streams from each participating node in the target blockchain network, and extracting behavioral feature vectors and current security level status, comprehensive and dynamic capture of node behavior is achieved. The real-time data stream collection covers various node operations, and combined with big data analytics, it enables the extraction of feature information reflecting the node's security status from multiple dimensions. This allows the understanding of nodes to extend beyond single static data to the dynamic process of changing behavior.

[0060] For each participating node, it is treated as a target evaluation node. The expected security level is calculated based on the distribution pattern of behavioral feature vectors within a historical time window. This approach fully utilizes historical data on node behavior to uncover hidden patterns in behavioral dynamics. The division of historical time windows ensures that the analysis of node behavior has both temporal continuity and reflects the behavioral characteristics of different stages, avoiding evaluation bias caused by data from a single point in time. This makes the calculation of the expected security level more closely aligned with the actual behavioral trends of the nodes.

[0061] A dynamic threat score is generated based on the difference between the expected security level and the current security level, which can intuitively reflect the degree of deviation between the node's current behavior and historical patterns. This difference calculation does not rely on a fixed threshold, but is based on the node's own behavioral history, making the threat score more targeted and dynamic. It can promptly detect abnormal changes in node behavior, whether subtle abnormal fluctuations or obvious malicious behavior, all of which can be reflected in the threat score.

[0062] Based on dynamic threat scoring and the expected and current security levels of target assessment nodes across historical time windows, the predicted security level for the next time window is calculated. This multi-factor fusion prediction method comprehensively considers the historical patterns, current status, and degree of anomalies in node behavior. By combining historical and real-time data, it is possible to more accurately predict the security status trends of nodes over a future period. This allows protective measures to move beyond simply responding to threats that have already occurred, enabling proactive planning and preemptive handling of potential risks. Attached Figure Description

[0063] Figure 1 This is a schematic diagram illustrating the working principle of the security protection method based on blockchain and big data described in this invention.

[0064] Figure 2 A flowchart for obtaining the expected security level;

[0065] Figure 3 A flowchart for calculating the trust weight of non-consensus nodes;

[0066] Figure 4 A flowchart for calculating the predicted security level when the dynamic threat score is high;

[0067] Figure 5 A flowchart for calculating the predicted security level when the dynamic threat score is low. Detailed Implementation

[0068] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0069] Please see Figure 1 This invention provides a security protection method based on blockchain and big data, the method comprising:

[0070] This method monitors the real-time behavioral data streams of participating nodes in a blockchain network, extracts behavioral feature vectors and their current security level status, and predicts the security level change trend of nodes based on historical behavioral feature distribution patterns. First, it acquires real-time behavioral data streams of all participating nodes in the target blockchain network, including transaction behavior, resource consumption, address distribution, and network topology. Behavioral feature vectors are extracted from these data, and the current security level status is determined based on preset security level assessment rules. For each participating node, it is used as the target assessment node, and its behavioral feature vector distribution patterns within historical time windows are analyzed to calculate the expected security level for each historical time window. By comparing the difference between the expected security level and the current security level status, a dynamic threat score is generated, and the security level for the next time window is predicted based on this score and historical security status data. This method achieves proactive defense against potential threats by dynamically adjusting the security level of nodes.

[0071] Example 1: See Figure 2 In the process of obtaining the expected security level, participating nodes that are continuously active within the historical time window are marked as consensus nodes. The trust weight of consensus nodes is calculated based on their transaction behavior patterns, address distribution characteristics, and resource consumption within the historical time window. In specific implementation, the system first collects real-time behavioral data streams of each participating node from the blockchain network, including transaction records, network communication data, computing resource consumption, and the node's location information in the blockchain topology. After preprocessing, this data extracts key indicators that reflect the node's behavioral characteristics, forming a behavioral feature vector.

[0072] For any consensus node and historical time window, the system employs a hash feature matching algorithm to analyze its transaction behavior. This algorithm identifies anomalous transaction characteristics by comparing the hash features of transaction data and records the specific locations of these characteristics within the transaction sequence. Simultaneously, based on the node's registration address information and the blockchain network's topology model, the system determines the node's spatial coordinates. The location information from historical transaction records is further used to construct the node's effective communication node set, i.e., the set of other nodes with which the node has direct or indirect transaction interactions.

[0073] The difference between the number of anomalous transaction feature points and the number of valid communication nodes is calculated and used as an indicator to measure the degree of anomalousness in node behavior. This indicator is added to a preset benchmark value and the reciprocal is taken to generate an initial trust coefficient. The initial trust coefficient reflects the credibility of a node's transaction behavior; a higher value indicates that the node's behavior is more consistent with expectations. Furthermore, the system uses a proximity matching algorithm to compare the coordinates of anomalous transaction feature points with the coordinates of valid communication nodes, counting the number of successfully matched feature points as the effective interaction quantity. A higher effective interaction quantity indicates a stronger consistency between the node's transaction behavior and the network topology.

[0074] Resource consumption percentage is another important indicator. The system statistically analyzes the computing resource consumption of consensus nodes within a historical time window, including the utilization rate of resources such as CPU, memory, and bandwidth, and compares this with the total resource consumption of the entire network to generate a resource reliability coefficient. The resource reliability coefficient reflects the stability of a node's resource contribution; excessively high or low resource consumption percentages may affect its reliability.

[0075] Different strategies are used to calculate the trust weight of non-consensus nodes. Since non-consensus nodes have low activity levels within historical time windows, the system primarily focuses on their network topology relationships with consensus nodes. For any non-consensus node and its active historical time window, the system calculates the minimum path hop count between it and each consensus node, which is used as the network isolation degree. The lower the minimum path hop count, the tighter the connection between the node and the consensus nodes, and the lower the network isolation degree. The network isolation degree is added to a preset isolation threshold, and the reciprocal is taken to generate a topology trust coefficient. The topology trust coefficient reflects the trustworthiness of non-consensus nodes in the network structure; the lower the hop count, the higher the coefficient.

[0076] The resource consumption percentage of non-consensus nodes is also included in the calculation as a resource contribution coefficient. The product of the resource contribution coefficient and the topology trust coefficient is normalized to generate a reference trust weight. To further adjust the trust weight of non-consensus nodes, the system introduces a level adjustment base and a weight correction factor. The level adjustment base is obtained by subtracting a preset level from the total number of blockchain security levels, while the weight correction factor is the ratio of the level adjustment base to the total number of blockchain security levels. The product of the reference trust weight and the weight correction factor ultimately determines the trust weight of the non-consensus node. This adjustment mechanism ensures that the trust weight of a non-consensus node matches its actual contribution and network position, avoiding excessive penalties for low activity.

[0077] When generating the expected security level using trust weight mapping, the system divides the numerical range of trust weights into several consecutive intervals, the number of which matches the total number of blockchain security levels. Each interval corresponds to a unique security level label, with the highest trust weight interval corresponding to the lowest security risk level. When a participating node's trust weight falls into a certain interval, the system automatically marks its expected security level with the security level label corresponding to that interval. For example, if the total number of blockchain security levels is 5, and the trust weight range is divided into 5 intervals, when a node's trust weight falls into the 3rd interval, its expected security level is marked as level 3.

[0078] Example 2: See Figure 3 In blockchain networks, calculating the trust weight of non-consensus nodes requires comprehensive consideration of their network topology and resource contributions. Since non-consensus nodes lack continuous activity, their behavioral data is relatively sparse, making traditional transaction-based evaluation methods difficult to apply directly. This embodiment analyzes the network connection characteristics between non-consensus nodes and consensus nodes, combined with resource consumption patterns, to construct a trust weight calculation mechanism adapted to the characteristics of non-consensus nodes.

[0079] The system first collects activity records of non-consensus nodes from the blockchain network to determine their online status within a historical time window. For each active non-consensus node, the system traverses the current blockchain network topology and calculates the minimum path hop count between that node and all consensus nodes. The minimum path hop count reflects the network distance between nodes; a lower hop count indicates a shorter connection path and a closer network relationship. The system records the minimum hop count between each non-consensus node and each consensus node, and selects the minimum value as the network isolation index for that non-consensus node. A higher network isolation value indicates a more marginalized position in the topology.

[0080] To convert network isolation into a quantifiable trust metric, the system introduces a preset isolation threshold. This threshold is dynamically adjusted based on the scale of the blockchain network and historical operational data to balance evaluation standards under different network environments. The system adds the network isolation to the preset isolation threshold and takes the reciprocal to generate a topological trust coefficient. This conversion process results in higher coefficient values ​​for nodes with closer topological relationships, while edge nodes receive relatively lower coefficient values. The topological trust coefficient, as an important indicator reflecting the reliability of a node's network location, lays the foundation for subsequent trust weight calculations.

[0081] Resource consumption analysis is another important dimension for evaluating non-consensus nodes. The system statistically analyzes the computing resource usage of non-consensus nodes within an active time window, including specific indicators such as CPU processing time, memory usage ratio, and network bandwidth consumption. This resource usage data is compared with the total network resources to calculate the node's resource consumption percentage within a specific time window. The resource consumption percentage directly reflects the node's contribution to network resources; a higher percentage indicates a stronger initiative in the node's participation in network activities. The system uses this percentage as a resource contribution coefficient for subsequent comprehensive evaluation.

[0082] The product of the topological trust coefficient and the resource contribution coefficient is normalized to generate a preliminary reference trust weight. The normalization process maps the calculation results of all non-consensus nodes to a unified numerical range, eliminating dimensional differences between different indicators. At this point, the obtained reference trust weight can basically reflect the trustworthiness of non-consensus nodes in the network. However, to more accurately match the blockchain security level system, the system further introduces a weight correction mechanism.

[0083] The weight adjustment mechanism is implemented by analyzing the overall distribution characteristics of blockchain security levels. The system first obtains the total number of security levels currently used by the blockchain network, and then determines preset level parameters based on network security management strategies. Subtracting the preset level from the total number of security levels yields the level adjustment base, which reflects the flexible adjustment space of the security level system. The system then divides the level adjustment base by the total number of security levels to calculate the weight adjustment factor. This factor, as an adjustment coefficient, is multiplied by the reference trust weight to generate the final trust weight value. Through this adjustment process, the trust weights of non-consensus nodes can better adapt to the security level classification standards of the specific blockchain network.

[0084] In the process of mapping trust weights to the expected security level, the system divides the entire range of trust weight values ​​into several consecutive intervals. The number of intervals strictly corresponds to the total number of blockchain security levels, and each interval corresponds to a specific security level label. When dividing the intervals, the system uses a dynamic boundary adjustment algorithm to automatically optimize the boundary values ​​of each interval based on the trust weight distribution of all nodes within the historical period. This dynamic division method ensures that each security level interval covers an appropriate number of nodes, avoiding situations where some levels have too many or too few nodes.

[0085] Once the trust weights of non-consensus nodes are calculated, the system automatically matches their values ​​with pre-defined intervals. The matching process uses a binary search algorithm to quickly locate the interval containing the weight value, and then assigns the corresponding security level label to the node. It's worth noting that the highest trust weight interval corresponds to the lowest security risk level; this inverse mapping relationship aligns with the conventional logic of network security assessments. For example, in a blockchain network employing a five-level security system, the 20% of nodes with the highest trust weights will be assigned the lowest-risk Level 1 security level, while the 20% of nodes with the lowest weights will be labeled as the highest-risk Level 5.

[0086] Example 3: The dynamic threat scoring generation process is based on the analysis of historical behavioral characteristics of target assessment nodes. The system first extracts behavioral data of target assessment nodes from the blockchain network across multiple historical time windows, including key indicators such as transaction records, communication patterns, and resource consumption. This data, after preprocessing, is transformed into standardized behavioral feature vectors for subsequent analysis and calculation. Each historical time window corresponds to an independent dataset, and the system numbers these windows chronologically to establish a complete historical behavioral sequence.

[0087] The expected security level is calculated using the same method as in Examples 1 and 2. However, in this process, the system additionally records the current security level status of the target evaluation node within each historical time window. The current security level status is provided by the blockchain network's real-time monitoring system and reflects the node's actual security rating within the corresponding time window. The system compares the expected security level with the current security level status window-by-window and calculates the difference between the two. The difference is calculated using the concept of a level offset, specifically the absolute difference between the expected security level value and the current security level status value.

[0088] For each historical time window, the system records the corresponding level offset. To comprehensively assess the threat level of a node, the system sums the level offsets from all historical time windows. This summation reflects the degree of behavioral deviation of a node over a longer period; the larger the cumulative offset, the more significant the difference between the node's actual behavior and the expected pattern. The formula for calculating the cumulative offset is as follows:

[0089]

[0090] Among them, T sum This represents the total cumulative offset, where n represents the total number of historical time windows, and E i C is the expected security level value for the i-th time window. iThis represents the current security level status value for the i-th time window. Absolute value calculations ensure that deviations from the intended direction do not affect the overall threat level assessment.

[0091] The cumulative offset sum needs to undergo a negative correlation transformation to generate the final dynamic threat score. The purpose of the negative correlation transformation is to ensure that a larger offset corresponds to a higher threat score. This transformation is achieved by subtracting the cumulative offset sum from a sufficiently large baseline value. The baseline value is chosen considering the maximum possible cumulative offset in historical data to ensure that the transformed result remains within a reasonable range. The transformed value is then linearly normalized and mapped to a preset scoring interval to generate a standardized dynamic threat score. The normalization process uses a max-min scaling method to ensure that the scores of all nodes are comparable.

[0092] The calculation of the predicted security level employs different strategies based on the comparison between the dynamic threat score and the preset threat threshold. The preset threat threshold is dynamically adjusted according to the blockchain network's security policy, reflecting the network administrator's control requirements for risk tolerance. When the dynamic threat score of a target evaluation node exceeds the preset threat threshold, the system determines that the node poses a high security risk, requiring a more stringent prediction method. In this case, the system analyzes the node's current security level status sequence across historical time windows and uses time series analysis techniques to predict its security level for the next time window.

[0093] Time series analysis employs a linear fitting method, arranging historical security level states chronologically and fitting them to a linear equation. The slope of the fitted line reflects the trend of changes in the node's security level: a positive slope indicates an upward trend, a negative slope indicates a downward trend, and a slope of zero indicates that the level remains stable. The system determines the direction of security level adjustment based on the sign and magnitude of the slope value, and then combines the current security level state with the adjustment direction to calculate the predicted security level for the next time window. This trend-based prediction method can effectively capture long-term behavioral pattern changes in nodes.

[0094] When the dynamic threat score is less than or equal to a preset threat threshold, the system employs a simplified prediction strategy. In this case, the system primarily focuses on comparing the expected security level of the target evaluation node within the current time window with its current security level. If the expected security level is less than or equal to the current security level, it indicates that the node's actual behavior is better than or in line with expectations, and the system directly uses the expected security level as the predicted value for the next time window. Conversely, if the expected security level is greater than the current security level, the system maintains the current security level unchanged as the predicted value. This conservative strategy avoids over-adjusting the node's security level under low-threat conditions.

[0095] The entire dynamic threat scoring and prediction process operates automatically. The system periodically collects the latest data from the blockchain network, updating the behavioral feature vectors and security level status of each node. Historical data windows employ a sliding update mechanism, always ensuring a fixed number of the most recent time windows are used in the calculation. This design ensures the timeliness of the assessment results, reflecting changes in node behavior within the network promptly. The update frequency of the scoring and prediction results is matched to the blockchain network's security policy, typically set to be synchronized with or an integer multiple of the block generation cycle.

[0096] The dynamic threat scoring mechanism provides a quantitative risk assessment tool for blockchain networks. By continuously monitoring the degree of deviation in node behavior, the system can promptly detect potential security threats. The calculation method for predicting security levels adopts differentiated strategies based on the degree of risk, ensuring strict control over high-risk nodes while avoiding excessive intervention in normal nodes. This tiered response mechanism effectively balances the relationship between network security and operational efficiency, providing crucial assurance for the stable operation of the blockchain network.

[0097] The scoring and prediction results are stored using distributed ledger technology, ensuring the immutability and traceability of the data. The results generated in each calculation cycle are packaged into transaction records in a specific format, verified by a consensus mechanism, and then written to the blockchain. This design allows all participating nodes in the network to access consistent security assessment data, laying the foundation for collaborative security protection. Simultaneously, the complete preservation of historical assessment records provides data support for subsequent security audits and strategy optimization.

[0098] The dynamic threat scoring system operates independently of centralized control nodes; all computations are performed in a distributed environment. The allocation of computational tasks and the aggregation of results are implemented using smart contracts, ensuring transparency and reliability. Data communication between nodes employs encrypted transmission protocols to prevent information leakage during the assessment process. The entire system architecture fully embodies the decentralized nature of blockchain technology and maintains a high degree of consistency with the security model of the underlying blockchain network.

[0099] Example 4: See Figure 4 In a blockchain network, when a participating node's dynamic threat score exceeds a preset threshold, the system needs to employ more detailed analysis methods to predict its future security level. In this case, simple static assessment is insufficient to accurately reflect the node's risk change trend; therefore, time series analysis technology needs to be introduced to infer its future trajectory by studying the historical patterns of changes in the node's security level.

[0100] Taking a real-world blockchain network as an example, suppose there is a participating node NodeX in the network. Its security level records for the most recent six time windows are as follows: Time window W1 Level 3, W2 Level 3, W3 Level 4, W4 Level 4, W5 Level 5, W6 Level 5. The system first arranges these historical data in chronological order to form a complete security level sequence. This sequence clearly shows the process of NodeX's security status changing over a period of time, gradually rising from the initial Level 3 to Level 5.

[0101] The system performs linear trend analysis on this security level sequence. Using the time window as the independent variable and the security level as the dependent variable, it fits a straight line using the least squares method to best represent the data's changing trend. In this example, the slope of the fitted line is clearly positive, indicating that the NodeX's security level shows a continuously increasing trend. This upward trend may mean that the node's behavior pattern is undergoing adverse changes, or its network environment is deteriorating. According to preset rules, when the slope of the trend line is positive, the system marks the node's security level adjustment direction as "increasing mode".

[0102] After determining the adjustment direction, the system needs to calculate the predicted security level for the next time window W7. The current security level for the latest time window W6 is 5. Following the incremental adjustment pattern, the system will raise the level by one, setting the predicted security level for W7 to 6. If the highest security level for the blockchain network is 5, the system will maintain the level at 5, but will trigger an additional risk warning mechanism. This trend-based prediction method can identify potential risk nodes in advance, providing more response time for network security management.

[0103] Another example is node NodeY, whose safety levels for the most recent six time windows are: W1 level 4, W2 level 4, W3 level 4, W4 level 4, W5 level 4, and W6 level 4. After linear fitting this perfectly stationary sequence, the resulting trend line slope is zero. Therefore, the system marks NodeY's safety level adjustment direction as "stable mode." In this case, the system considers that the node's safety status has no significant trend and directly uses the current level 4 as the predicted safety level for the next time window W7. This approach is suitable for nodes whose behavioral patterns remain stable over a long period.

[0104] Consider the example of node Z. Its security level record shows: W1 level 5, W2 level 5, W3 level 4, W4 level 4, W5 level 3, W6 level 3. After linear fitting this sequence, the trend line slope is negative, indicating that the node's security level is gradually improving. The system marks the adjustment direction as "decreasing mode." When predicting the security level of the next time window W7, it will reduce the current level 3 by one level, predicting it as level 2. This decreasing adjustment reflects the improving trend of node behavior or network environment, and the system can correspondingly reduce the monitoring intensity of that node.

[0105] In practical applications, the system creates an independent security level change profile for each node exceeding the threat threshold. These profiles not only record the original security level data but also save the results of trend analysis and the basis for predictions. When a network administrator views the detailed information of a high-risk node, they can see not only the current security level but also its historical change curve and the trend judgments made by the system. This transparent recording method helps administrators understand the system's decision-making process and allows for manual intervention when necessary.

[0106] The way time windows are divided directly affects the accuracy of trend analysis. In typical implementations, the length of each time window is consistent with the block generation cycle of the blockchain network. For example, if the network generates a new block every 10 minutes on average, then a time window can be set to 1 hour, encompassing a generation cycle of 6 blocks. This alignment ensures the comparability of data within each time window and avoids analytical biases caused by improper time division.

[0107] The system also has strict requirements regarding the number of historical data windows. Too few windows will result in a lack of statistical significance in trend analysis, while too many may cause the analysis results to lag behind the actual changes in the nodes. Practical experience has shown that using data from 6-12 historical time windows for trend analysis achieves a good balance between response speed and accuracy. When the network operating environment changes, the system dynamically adjusts this parameter to adapt to different security monitoring needs.

[0108] Verifying the reliability of prediction results is a crucial step in the implementation process. The system continuously tracks the actual accuracy of each prediction, comparing the predicted security level with the subsequent actual security level of each node. When a significant deviation is detected between the predicted result and the actual situation for a particular node, the system automatically triggers a recalibration of the prediction model. This self-correcting mechanism ensures that the prediction method can adapt to changes in node behavior patterns within the network, maintaining high prediction accuracy.

[0109] The security level prediction results are updated in real time to the node management system of the blockchain network. Other security modules in the network, such as access control and transaction verification, can adjust their operating strategies based on this prediction data. For example, when the predicted security level of a node indicates that its risk is rising, the system may temporarily limit the number or frequency of transactions initiated by that node until its security status improves.

[0110] Example 5: See Figure 5 In the security protection system of a blockchain network, when the dynamic threat score of a participating node does not exceed a preset threshold, the system uses a relatively simplified prediction strategy to determine its security level for the next time window. In this case, the node's behavior pattern is considered to be in a relatively stable state, eliminating the need for complex trend analysis. Instead, the judgment is made by directly comparing the numerical relationship between the expected security level and the current security level. This design ensures the accuracy of the prediction while avoiding unnecessary consumption of computational resources.

[0111] Taking NodeA in a real-world blockchain network as an example, the system calculates its dynamic threat score to be 0.25 within the latest time window, which is lower than the network's set threat threshold of 0.3. At this point, the system enters a simplified prediction process, first acquiring two key data points for the node in the current time window: the expected security level and the current security level status. Assume NodeA's expected security level is level 2, and its current security level status is level 3. Since the expected security level is lower than the current security level status, it indicates that the node's actual behavior is better than the system's expectations. Therefore, the system directly uses the expected security level of 2 as the predicted security level for the next time window. This approach reflects the positive changes in the node's behavior and appropriately lowers its security risk rating.

[0112] The situation is different for NodeB. This node's dynamic threat score is 0.28, also below the threshold of 0.3. Within the current time window, its expected security level is 4, while its current security level is 3. The expected security level being higher than the current security level indicates that the node's actual performance is slightly below system expectations. According to the prediction rules, the system will maintain the current security level of 3 as the predicted value for the next time window. This conservative strategy avoids frequent adjustments to the node's security level when the threat score is low, thus maintaining the stability of the network rating.

[0113] While this comparison-based prediction method is simple, it requires consideration of various boundary conditions in practical applications. For example, when the expected security level is equal to the current security level, the system directly uses this common value as the prediction result. In this case, the node's behavior perfectly matches expectations, requiring no adjustments. Furthermore, in certain special scenarios, a node's expected security level may fluctuate drastically due to data anomalies. However, because its dynamic threat score remains below the threshold, the system will still use the current security level as the prediction value. This design effectively prevents temporary data anomalies from interfering with the prediction results.

[0114] The security level values ​​used in the prediction process all come from the standard rating system of the blockchain network. This system typically uses a numerical rating system, with lower values ​​indicating lower security risk. In a typical five-level system, level 1 represents the highest security level, and level 5 represents the highest risk level. All rating values ​​are stored and processed in a standardized format within the system to ensure data consistency between different modules. When the prediction results need to be displayed to the network administrator, the system automatically converts the numerical ratings into corresponding text descriptions for easy human understanding and use.

[0115] The system generates detailed logs for the prediction process of each node. These logs include complete information such as prediction time, prediction method used, input data, decision basis, and output results. The log data is stored in a structured format, supporting rapid retrieval and analysis by node identifier, time range, and other criteria. When network administrators need to review the prediction results of a particular node, they can access these historical records at any time to understand the specific reasons why the system made that prediction. This transparent recording mechanism enhances the credibility and auditability of the prediction system.

[0116] During implementation, the system periodically evaluates the accuracy of the simplified prediction method. The evaluation method compares the prediction results with the actual security level of the node afterward, calculating the percentage of accurate predictions. When the prediction accuracy of a node is consistently lower than expected, the system marks that node as requiring special attention, and more complex analysis methods may be used in subsequent predictions. This self-monitoring mechanism ensures that the prediction method can adapt to changes in node behavior patterns within the network, maintaining high prediction quality.

[0117] The prediction results are updated in sync with the blockchain network's operating cycle. At the end of each predetermined time window, the system automatically initiates a new round of prediction calculations. This periodic update mechanism ensures that the security level of all nodes reflects their latest status in a timely manner. For certain critical nodes or special scenarios, the system also supports manually triggering prediction updates to meet temporary management needs. The scheduling of prediction calculation tasks employs a priority mechanism to ensure that predictions for important nodes are completed first.

[0118] The predicted security level of each node is synchronized in real time to all functional modules of the blockchain network. For example, the consensus mechanism may adjust the voting weight of a node based on its predicted security level, and the network routing module may optimize data transmission paths based on the prediction results. This cross-module collaboration forms a complete security protection system, enabling the prediction results to truly play their role. All modules obtain prediction data through standardized interfaces, ensuring the accuracy and timeliness of information transmission.

[0119] The implementation of the prediction system also takes into account the differences in characteristics among various blockchain networks. For private or consortium blockchains with a small number of nodes, the system can employ more refined prediction strategies, even customizing prediction parameters for each node. In contrast, in public blockchain environments with a large number of nodes, the system uses more general prediction rules to ensure processing efficiency. This flexibility allows the prediction method to adapt to diverse blockchain application scenarios and meet the management needs of networks of different sizes.

[0120] Node authentication information also affects the prediction process. For nodes that have passed strict authentication, the system may appropriately relax prediction conditions, granting them greater trust. Anonymous nodes or newly joined nodes may be subject to stricter prediction rules. This differentiated approach ensures network security while avoiding excessive restrictions on trusted nodes. The integration of identity information with the prediction system adopts a modular design, allowing for flexible configuration based on the specific authentication requirements of the network.

[0121] The prediction system operates independently of a centralized control node; all computations are performed in a distributed environment. Each participating node receives its own security-level prediction results but cannot view the complete prediction data of other nodes. This design protects node privacy while maintaining the network's decentralized nature. The allocation of prediction tasks and the aggregation of results are implemented through smart contracts, ensuring transparency and reliability.

[0122] The system sets reasonable default values ​​for all parameters used in the prediction process. These default values ​​are derived from statistical analysis of the operating characteristics of typical blockchain networks. Network administrators can adjust these parameters according to actual needs, such as modifying the threat threshold or adjusting the security level classification criteria. All parameter adjustments are recorded on the blockchain, forming a complete modification history for easy auditing and traceability.

[0123] The interface design for displaying prediction results prioritizes practicality and ease of use. Administrators can intuitively view changes in the security level of each node through a graphical interface, with prediction results highlighted using color coding. The interface supports various filtering and sorting functions for easy and quick location of nodes requiring attention. Significant prediction changes automatically trigger a notification mechanism, alerting administrators to potentially risky nodes. These design details significantly enhance the system's practical value and management efficiency.

[0124] The entire prediction system's architecture is designed with scalability and compatibility in mind. The core prediction algorithm is decoupled from specific blockchain platforms, interacting with the underlying network through standardized interfaces. This design allows the system to be adapted relatively easily to different blockchain frameworks, reducing deployment and maintenance workload. The system components are modularly designed, allowing for flexible addition or removal of functional modules based on actual needs, meeting customized management requirements.

[0125] The implementation of the prediction system also includes a robust anomaly handling mechanism. When data anomalies or calculation errors occur during the prediction process, the system automatically switches to a safe mode, adopts the most conservative prediction strategy, and generates a detailed error report. Network administrators can view these anomaly records at any time and address potential problems promptly. This robust design ensures that the system can maintain normal operation of its basic functions under various abnormal conditions.

[0126] The prediction of node security levels is not only used for real-time network management but also provides data support for long-term security strategy development. The system regularly generates a comprehensive security status analysis report for all network nodes, statistically analyzing the distribution ratio of nodes at each security level and identifying clustering patterns of risky nodes. This macro-level analytical data helps network administrators grasp the overall security situation and formulate more targeted protection strategies. All analysis reports are stored in a standardized format, supporting comparison with historical data and trend analysis.

[0127] The operation and maintenance of the prediction system includes regular algorithm evaluation and optimization. Utilizing historically accumulated prediction data, statistical analysis methods are used to continuously improve the prediction logic and parameter settings. Algorithm updates employ a gradual deployment strategy, first validating the effectiveness in a test environment before gradually rolling it out to the production environment. This continuous optimization process enables the prediction method to adapt to changes in the network environment and node behavior, maintaining the accuracy of the prediction results.

[0128] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0129] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A security protection method based on blockchain and big data, characterized in that, include: Obtain real-time behavioral data streams of each participating node in the target blockchain network, and extract the behavioral feature vectors and current security level status of the participating nodes; For each participating node in the target blockchain network, it is taken as the target evaluation node. Based on the distribution pattern of the behavioral feature vector of the target evaluation node in the historical time window, the expected security level of the target evaluation node in each historical time window is calculated. Based on the difference between the expected security level and the current security level, a dynamic threat score is generated for the target assessment node. Based on the dynamic threat score and the expected security level and current security level status of the target assessment node in each historical time window, the predicted security level of the target assessment node in the next time window is calculated. The step of generating the dynamic threat score for the target assessment node includes: For any target evaluation node, calculate the level offset between its expected security level and current security level status in each historical time window; The sum of the level offsets of all historical time windows is negatively correlated and normalized to generate the dynamic threat score of the target assessment node. The step of calculating the predicted security level of the target evaluation node in the next time window includes: If the dynamic threat score of the target assessment node is greater than the preset threat threshold, then the predicted security level of the target assessment node in the next time window is calculated based on its current security level status and its current security level status sequence in each historical time window. If the dynamic threat score of the target assessment node is less than or equal to the preset threat threshold, then the predicted security level of the target assessment node in the next time window is calculated based on the comparison between the expected security level and the current security level status. The steps for obtaining the expected security level include: Mark participating nodes that are continuously active within the historical time window as consensus nodes; Based on the transaction behavior patterns, address distribution characteristics, and resource consumption of each consensus node within a historical time window, calculate the trust weight of each consensus node in each historical time window. For non-consensus nodes, the trust weight of each non-consensus node in each historical time window is calculated based on its resource consumption within its active time window and its topological distance to neighboring consensus nodes. The expected security level of each participating node is generated based on the trust weight mapping. The steps for calculating the trust weight of each consensus node in each historical time window include: For any consensus node and any historical time window, the abnormal transaction feature points and feature point coordinates of each consensus node in each historical time window are extracted by the hash feature matching algorithm. Based on the spatial coordinates of the registration addresses of each consensus node in the blockchain topology model and their historical transaction location information, combined with the network traffic direction, the effective communication node set of each consensus node and the coordinates of each node are determined. The difference between the number of abnormal transaction feature points and the number of valid communication nodes is calculated as the behavior anomaly degree; The reciprocal of the sum of the behavioral anomaly degree and the preset baseline value is marked as the initial trust coefficient; Based on the proximity matching algorithm between the coordinates of the abnormal transaction feature points and the coordinates of the effective communication nodes, the number of successfully matched feature points is obtained as the effective interaction quantity. Extract the percentage of resource consumption of each consensus node within each historical time window as the resource reliability coefficient; The product of the effective interaction amount, the initial trust coefficient, and the resource trust coefficient is normalized to generate the trust weight of each consensus node.

2. The security protection method as described in claim 1, characterized in that, The steps for calculating the trust weight of each non-consensus node in each historical time window include: For any non-consensus node and its active historical time window, calculate the minimum path hops between each non-consensus node and each consensus node within each historical time window, and use this as the network isolation degree. The reciprocal of the sum of the network isolation degree and the preset isolation threshold is denoted as the topology reliability coefficient; Extract the proportion of resource consumption of each non-consensus node within each historical time window, and use it as the resource contribution coefficient; The product of the topology credibility coefficient and the resource contribution coefficient is normalized to generate a reference trust weight. The difference between the total number of blockchain security levels and the preset level will be used as the base for level adjustment. Divide the aforementioned level adjustment base by the total number of blockchain security levels to generate a weight correction factor; The product of the weight correction factor and the reference trust weight is used as the final trust weight of each non-consensus node.

3. The security protection method as described in claim 1, characterized in that, The step of generating the expected security level of each participating node based on the trust weight mapping includes: The range of trust weight values ​​is divided into continuous intervals, and the number of such continuous intervals is equal to the total number of blockchain security levels. Each consecutive interval is assigned a corresponding security level label, where the interval with the highest trust weight corresponds to the lowest security risk level. For any participating node and historical time window, when the trust weight of each participating node falls into a specific continuous interval, the security level label corresponding to the specific continuous interval is taken as the expected security level of each participating node.

4. The security protection method as described in claim 1, characterized in that, If the dynamic threat score of the target assessment node is greater than a preset threat threshold, the step of calculating its predicted security level in the next time window based on the target assessment node's current security level status and its current security level status sequence in each historical time window includes: Arrange the historical time windows involved in the target evaluation nodes in chronological order to generate a historical window sequence; Extract the current security level status of the target evaluation node in each historical time window, and generate a security level sequence according to the historical window sequence order; The safety level sequence is fitted to a linear function to generate a safety level change trend line; If the slope of the security level change trend line is positive, the security level adjustment direction of the target evaluation node is set to an increasing mode; If the slope of the security level change trend line is zero, the security level adjustment direction of the target evaluation node is set to stable mode; If the slope of the security level change trend line is negative, the security level adjustment direction of the target evaluation node will be set to a decreasing mode. The current security level status of the target evaluation node is superimposed with the security level adjustment direction to generate its predicted security level in the next time window.

5. The security protection method as described in claim 4, characterized in that, If the dynamic threat score of the target assessment node is less than or equal to a preset threat threshold, the step of calculating its predicted security level in the next time window based on the comparison between the expected security level and the current security level status of the target assessment node includes: Within the current time window, if the expected security level of the target evaluation node is less than or equal to the current security level, the expected security level of the target evaluation node will be used as its predicted security level in the next time window. If the expected security level of the target evaluation node is greater than the current security level, the current security level will be used as its predicted security level in the next time window.

6. A blockchain service system, comprising a distributed storage module, a processor module, and a blockchain protocol program deployed in the distributed storage module, characterized in that, When the processor module executes the blockchain protocol program, it implements the operation steps of the security protection method based on blockchain and big data as described in any one of claims 1 to 5, wherein: The distributed storage module synchronizes the behavioral data streams of each participating node in real time. The processor module includes a threat analysis engine for calculating dynamic threat scores and predicting security levels; The blockchain protocol program includes a security policy generator that dynamically adjusts node access permissions based on predicted security levels.

Images