A blockchain-based network security protection method and system

Abstract

The application provides a blockchain-based network security protection method and system, applied to the technical field of blockchain, which can effectively identify and distinguish the specific transaction confirmation time delay abnormal extension phenomenon caused by hidden computing power manipulation, and distinguish it from the transaction time delay caused by universal network congestion or normal network fluctuation, thereby accurately maintaining the fairness and timeliness of network transactions.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchains, and particularly relates to a network security protection method and system based on a blockchain. BACKGROUND

[0002] In a globally distributed public blockchain network using a proof of work (PoW) consensus mechanism, tens of thousands of independent nodes compete for the right to record new blocks through computing power devices, and the security and decentralization of the network depend on the wide dispersion of computing power and the fair packaging of block content. However, a new mode of abuse of computing power has emerged: a small number of associated entities accumulate and control a significant proportion of the network's computing power by dispersing identities or disguising themselves, although they do not reach the absolute majority of 51% attacks, but enough to have a hidden impact on the transaction processing process.

[0003] When these entities mine new blocks, they will intermittently or periodically exclude specific types of transactions, such as transactions from specific addresses or interactions with specific applications, or even manipulate the timing of block propagation. For example, if the block contains transactions that are favorable to it, it will be immediately broadcast; if it contains competitive or delayed transactions, it will selectively delay or discard the block, resulting in significantly slower confirmation of specific transactions than normal transactions. This attack mode is highly covert and does not directly violate the longest chain principle, but rather erodes transaction fairness and timeliness by manipulating block content and propagation timing.

[0004] Traditional computing power attack detection mechanisms are difficult to deal with this covert attack. Attackers use dispersed identities or multi-entity coordinated operations to make it difficult for monitoring based on mining pool identities to track their true intentions, and their behavior does not cause significant abnormalities in the network's block output speed. Therefore, how to effectively identify and distinguish the phenomenon of abnormal extension of specific transaction confirmation time delay caused by covert computing power manipulation in complex scenarios, and distinguish it from universal network congestion or normal fluctuations, so as to accurately maintain the fairness and confirmation timeliness of network transactions, has become a technical problem to be solved.

[0005] In view of the above problems, the prior art needs to be improved. SUMMARY

[0006] In view of the above problems of the prior art, the present application provides a network security protection method and system based on a blockchain, which is applied to the technical field of elevator safety monitoring and has the advantages of being able to effectively identify and distinguish the phenomenon of abnormal extension of specific transaction confirmation time delay caused by covert computing power manipulation, and distinguish it from the transaction time delay caused by universal network congestion or normal network fluctuations, so as to accurately maintain the fairness and confirmation timeliness of network transactions.

[0007] In a first aspect, a network security protection method based on a blockchain, the method comprising the steps of:

[0008] S1: Obtain transaction features of transactions to be confirmed in a blockchain network, and divide the transactions to be confirmed into multiple transaction categories according to the transaction features;

[0009] S2: Monitor actual confirmation time delay of each transaction category in the multiple transaction categories;

[0010] S3: For each of the transaction categories, establish a confirmation time delay baseline under normal network conditions, and calculate a deviation value between the actual confirmation time delay and the confirmation time delay baseline;

[0011] S4: When the deviation value is greater than or equal to a preset deviation threshold, obtain a first average residence time of the corresponding transaction category in a memory pool, and compare the first average residence time with a second average residence time of other transaction categories in the memory pool at the same period to obtain a relative residence time;

[0012] S5: According to the deviation value, the relative residence time, and a block generation speed of the entire network, it is judged whether there is a transaction anomaly caused by hidden computing power manipulation, and if the transaction anomaly exists, a security protection alarm is issued.

[0013] The network security protection method based on a blockchain provided in the application can accurately find malicious delay or exclusion behaviors for specific transactions that are not easily detected by traditional methods by classifying transactions in detail and combining multiple dimensions of indexes, including confirmation time delay deviation, memory pool relative residence time, and block generation speed of the entire network, effectively distinguishing normal network fluctuations from hidden attacks, and maintaining the fairness and timeliness of network transactions.

[0014] Further, step S1 includes:

[0015] S11: Obtain transaction features of transactions to be confirmed in a blockchain network;

[0016] S12: Monitor real-time distribution of the transaction features in the blockchain network;

[0017] S13: Obtain a normal distribution of the transaction features under normal network conditions, and compare the real-time distribution with the preset normal distribution to obtain a feature distribution deviation value,

[0018] S14: Identify an abnormal feature set of an abnormal transaction whose feature distribution deviation value is greater than or equal to a preset feature distribution deviation threshold;

[0019] S15: Divide multiple transaction categories according to the abnormal feature set and the corresponding feature distribution deviation value.

[0020] The blockchain-based network security protection method provided in the application can more finely identify the features of abnormal transactions by comparing the real-time distribution of transaction features with the normal distribution, and provide more accurate basis for subsequent transaction classification.

[0021] Further, step S15 comprises:

[0022] S151: taking the to-be-confirmed transaction as a data point and taking the features in the abnormal feature set as feature dimensions;

[0023] S152: clustering the to-be-confirmed transaction according to the feature distribution deviation value to obtain a plurality of clustering results;

[0024] S153: dividing the to-be-confirmed transaction into a plurality of transaction categories according to the clustering results.

[0025] The blockchain-based network security protection method provided in the application adopts a clustering method to divide transaction categories according to feature distribution deviation values, so that the classification results are more objective and accurate, and it is helpful to accurately locate the affected transaction types.

[0026] Further, step S3 comprises:

[0027] S31: identifying a plurality of time periods related to periodic congestion patterns in the blockchain network;

[0028] S32: maintaining a set of recent confirmation delay data samples for each transaction category and each time period;

[0029] S33: calculating statistical parameters based on the recent confirmation data samples to obtain a confirmation delay baseline under the time period;

[0030] S34: obtaining the occurrence time of the actual confirmation delay and selecting the confirmation delay baseline under the time period corresponding to the occurrence time;

[0031] S35: calculating the deviation value between the actual confirmation delay and the confirmation delay baseline.

[0032] The blockchain-based network security protection method provided in the application considers the periodic congestion patterns in the blockchain network and establishes a confirmation delay baseline for different time periods, so that the calculation of the deviation value is more accurate, and false judgments caused by periodic congestion are avoided.

[0033] Further, step S31 comprises:

[0034] S311: monitoring network performance indicators in the blockchain network;

[0035] S312: Identify a combined change pattern that periodically recurs in the network performance indicators.

[0036] S313: Define the plurality of time periods according to the start and end points of the combined change pattern.

[0037] Further, step S32 comprises:

[0038] S321: Set a fixed time window for each type of transaction category and each time period;

[0039] S322: Collect recent confirmation delay data of each type of transaction category in the time period within the fixed time window;

[0040] S323: Take all the recent confirmation delay data as the recent confirmation delay data sample.

[0041] Further, step S33 comprises:

[0042] S331: Calculate the mean and standard deviation of the recent confirmation data sample based on the recent confirmation data sample;

[0043] S332: Determine a confidence interval according to the mean and standard deviation;

[0044] S333: Take the confidence interval as the confirmation delay baseline for the time period.

[0045] Further, step S4 comprises:

[0046] When the deviation value is greater than or equal to a preset deviation threshold, the first average residence time of the corresponding transaction category in the memory pool is obtained, and the second average residence time of other transaction categories in the memory pool at the same period is obtained;

[0047] Divide the first average residence time by the second average residence time to obtain the relative residence time.

[0048] Further, step S5 comprises:

[0049] S51: Obtain the deviation value, the relative residence time, and the network-wide block output speed;

[0050] S52: Weight and combine the deviation value, the relative residence time, and the network-wide block output speed to obtain a comprehensive abnormality indicator;

[0051] S53: Compare the comprehensive abnormality indicator with a preset abnormality threshold;

[0052] S54: determining whether there is a transaction anomaly caused by hidden computing power manipulation according to a comparison result of the comprehensive anomaly index and the preset anomaly threshold value;

[0053] S55: issuing a security protection alarm if the transaction anomaly exists.

[0054] In a second aspect, a blockchain network security protection system is used to implement the method described in any of the above aspects, and the system comprises:

[0055] An acquisition module is configured to acquire transaction features of to-be-confirmed transactions in a blockchain network, and divide the to-be-confirmed transactions into multiple transaction categories according to the transaction features;

[0056] A monitoring module is configured to monitor actual confirmation time delays of each transaction category in the multiple transaction categories;

[0057] A first calculation module is configured to establish a confirmation time delay baseline under normal network conditions for each transaction category, and calculate a deviation value between the actual confirmation time delay and the confirmation time delay baseline;

[0058] A second calculation module is configured to acquire a first average residence time of the corresponding transaction category in a memory pool when the deviation value is greater than or equal to a preset deviation threshold value, and compare the first average residence time with a second average residence time of other transaction categories in the memory pool at the same period to obtain a relative residence time;

[0059] A security protection module is configured to determine whether there is a transaction anomaly caused by hidden computing power manipulation according to the deviation value, the relative residence time, and a network block generation speed, and issue a security protection alarm if the transaction anomaly exists.

[0060] The blockchain-based network security protection method and system proposed in the present application can effectively identify and distinguish the specific transaction confirmation time delay anomaly extension phenomenon caused by hidden computing power manipulation, and distinguish it from the transaction time delay caused by universal network congestion or normal network fluctuation, so as to accurately maintain the fairness of network transactions and the timeliness of confirmation. BRIEF DESCRIPTION OF DRAWINGS

[0061] Figure 1 The flowchart of the blockchain-based network security protection method proposed in the present application is shown.

[0062] Figure 2 The structural diagram of the blockchain network security protection system proposed in the present application is shown.

[0063] Figure 3 A block chain network security protection system architecture is provided.

[0064] Label description: 201, acquisition module; 202, monitoring module; 203, first calculation module; 204, second calculation module; 205, security protection module. DETAILED DESCRIPTION

[0065] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments. The components of the embodiments of the present application described and indicated in the accompanying drawings can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the claimed present application, but only represents selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present application.

[0066] It should be noted that: similar labels and letters represent similar items in the following drawings, therefore, once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings. Meanwhile, in the description of the present application, the terms "first, second" and the like are only used to distinguish the description, and cannot be understood as indicating or implying relative importance.

[0067] Please refer to Figure 1 A block chain-based network security protection method, the method comprising the steps of:

[0068] S1: acquiring transaction features of transactions to be confirmed in a block chain network, and dividing the transactions to be confirmed into multiple transaction categories according to the transaction features;

[0069] S2: monitoring the actual confirmation delay of each transaction category in the multiple transaction categories;

[0070] S3: for each transaction category, establishing a confirmation delay baseline under normal network conditions, and calculating a deviation value between the actual confirmation delay and the confirmation delay baseline;

[0071] S4: when the deviation value is greater than or equal to a preset deviation threshold, acquiring a first average residence time of the corresponding transaction category in the memory pool, and comparing the first average residence time with a second average residence time of other transaction categories in the memory pool at the same period to obtain a relative residence time;

[0072] S5: According to the deviation value, the relative residence time and the block speed of the whole network, it is judged whether there is transaction anomaly caused by hidden computing power manipulation. If there is transaction anomaly, a security protection alarm is sent out.

[0073] Among them, the transaction characteristics refer to the inherent attributes or behavioral attributes of the to-be-confirmed transactions in the blockchain network, which can be obtained by using transaction sender address, receiver address, transaction type, transaction amount, transaction attached data, transaction fee, transaction size and other information. Its main purpose is to finely distinguish and classify a large number of transactions and provide basic data for subsequent classification monitoring and anomaly identification.

[0074] Transaction category refers to a transaction set with similar attributes or behavior patterns divided according to transaction characteristics, such as division based on transaction type, address group or fee interval. Its main purpose is to structure the grouping of to-be-confirmed transactions in order to monitor and analyze the behavior of specific transaction groups, thereby improving the pertinence of anomaly detection.

[0075] Confirmation delay baseline refers to the average or expected time range of a specific transaction category from broadcast to being packaged and confirmed under normal network conditions. For example, the confidence interval is determined by calculating the mean and standard deviation of recent confirmation data samples. Its main purpose is to provide an objective reference standard for quantifying the difference between actual confirmation delay and normal state, thereby distinguishing between normal network fluctuations and potential abnormal behavior.

[0076] Deviation value refers to the quantitative difference between actual confirmation delay and confirmation delay baseline, which can be calculated by using absolute difference, relative percentage difference or standard deviation multiple in statistics. Its main purpose is to intuitively reflect whether the confirmation speed of a specific transaction category deviates from the normal expectation, serving as a quantitative basis for preliminary judgment of whether there is an anomaly.

[0077] Relative residence time refers to the comparison result between the average residence time of a specific transaction category in the memory pool and the average residence time of other transaction categories in the memory pool at the same period. Its main purpose is to analyze the waiting situation of a specific transaction category in the memory pool in depth, judge whether it is selectively delayed for processing, and further exclude the influence of general network congestion to locate hidden manipulation behavior.

[0078] Transaction anomaly caused by hidden computing power manipulation refers to the selective intervention in the packaging or propagation of specific transactions by entities that master part of the computing power advantage through dispersed identity or multi-entity collaborative operation, resulting in abnormal extension of the confirmation delay of these transactions, while the whole network macro indicator may remain normal. Its main purpose is to clarify the threat type identified and warned by the method, which is different from other network problems.

[0079] As a preferred embodiment, the scheme of the present application is implemented as follows:

[0080] The system can be deployed on one or more monitoring nodes in the blockchain network, and can collect the sending address, receiving address, transaction type, transaction fee, and transaction data load size of a transaction to obtain transaction features of the transaction to be confirmed. Based on these features, the system can use a clustering algorithm, such as K-means, to automatically divide the transaction to be confirmed into different transaction categories, such as “high-fee small-amount transfer”, “specific smart contract interaction”, or “large-amount low-fee transaction”, and the like.

[0081] When monitoring the actual confirmation latency, the system records the timestamp of each transaction from the first time it is monitored to the time it is broadcast to the network, and the timestamp of when it is finally packaged into a block, calculates the difference between the two as the actual confirmation latency, and aggregates it by transaction category. When establishing the confirmation latency baseline, the system can maintain a historical database to store the confirmation latency data of each transaction category under different network loads and time periods in the past period of time. For example, the time period can be divided by hour or by day, and the mean and standard deviation of the confirmation latency in each time period can be calculated for each transaction category to build a dynamic baseline range. When the actual confirmation latency exceeds the baseline range, the deviation value is calculated.

[0082] When the deviation value reaches a preset threshold, the system further obtains the average residence time of the abnormal transaction category in the memory pool. This can be calculated by tracking the time when the transaction enters the memory pool and the time when it is packaged or discarded. At the same time, the system calculates the average residence time of all other transaction categories in the memory pool at the same period, and performs a ratio operation on the two to obtain the relative residence time. For example, if the average residence time of the abnormal transaction category is twice that of the other transaction categories, the relative residence time is 2. Finally, the system performs a weighted combination calculation on the deviation value, the relative residence time, and the real-time network block generation speed obtained from the blockchain network, and when the calculation result exceeds a preset abnormal threshold, it is determined that there is a transaction anomaly. Once it is determined that there is a transaction anomaly, the system will send an alarm message to the administrator or related security module through the network interface, such as through email, SMS, or API call.

[0083] Through the above scheme, the present application can identify the specific transaction confirmation latency anomaly caused by hidden computing power manipulation in the blockchain network, and distinguish it from the transaction latency caused by general network congestion or normal network fluctuations. The method classifies transactions in detail, establishes a dynamic confirmation latency baseline, introduces relative residence time in the memory pool, and comprehensively considers multi-dimensional indicators such as network block generation speed, to detect hidden attack behavior, avoid false positives and false negatives of traditional detection methods, and thus maintain the fairness and timeliness of the blockchain network transaction confirmation.

[0084] Further, step S1 comprises:

[0085] S11: Obtain transaction features of transactions to be confirmed in the blockchain network;

[0086] S12: Monitor real-time distribution of the transaction features in the blockchain network;

[0087] S13: Obtain a pre-set normal distribution of the transaction features under normal network conditions, and compare the real-time distribution with the pre-set normal distribution to obtain a feature distribution deviation value,

[0088] S14: Identify an abnormal feature set of an abnormal transaction whose feature distribution deviation value is greater than or equal to a pre-set feature distribution deviation threshold;

[0089] S15: Divide multiple transaction categories according to the abnormal feature set and the corresponding feature distribution deviation value.

[0090] The real-time distribution refers to the actual statistical distribution of a certain transaction feature or a group of transaction features of all transactions to be confirmed in the blockchain network within a certain time window. The normal distribution refers to the statistical distribution pattern of the transaction features when the blockchain network is running under stable and non-anomalous manipulation conditions.

[0091] The present scheme refines the transaction classification, aiming to classify transactions in a more intelligent and dynamic way, so as to more effectively identify and isolate the transaction categories that may be manipulated by hidden computing power.

[0092] Firstly, as the starting point of the entire classification process, the system obtains various basic attributes of the transactions to be confirmed from the memory pool of the blockchain network through step S11, such as transaction ID, sender, receiver, transaction amount, transaction fee, transaction size, smart contract interaction data, etc. These features are the basis for all subsequent analysis and provide necessary data support for the intrinsic properties of the transactions.

[0093] Then, in step S12, on the basis of obtaining the transaction features, the system further dynamically monitors the real-time distribution of these transaction features in the blockchain network. This is not just a simple collection of feature values, but focuses on the overall statistical pattern of these features under the current network environment, such as the number of transactions in a certain transaction fee interval, the proportion of a certain transaction type in the memory pool, etc. The monitoring of real-time distribution enables the system to capture group and pattern abnormalities caused by hidden manipulation, rather than just isolated abnormal transactions.

[0094] Subsequently, in step S13, the system compares the real-time monitored transaction feature distribution with the pre-established normal transaction feature distribution obtained under normal network conditions. By calculating the feature distribution deviation value between the two, the system can quantify the difference between the current transaction feature distribution and the normal state. This quantification mechanism is key to identifying potential abnormal behavior, even if the manipulation behavior is slight and not easily detected, it can be captured through its cumulative impact on the feature distribution, thereby providing an objective basis for subsequent anomaly identification.

[0095] Further, in step S14, based on the feature distribution deviation value calculated in step S13, the system identifies the abnormal feature set of abnormal transactions whose deviation value is greater than or equal to the pre-set feature distribution deviation threshold. This step effectively filters out transaction attributes that deviate from the normal pattern, forming a feature subset focused on abnormal behavior. In this way, the subsequent classification process can effectively focus on transaction attributes that are truly likely to be manipulated, avoiding misjudgment of normal network fluctuations or random deviations as abnormal, improving the accuracy of detection.

[0096] Finally, in step S15, the system classifies the pending transactions in the memory pool according to the abnormal feature set identified in step S14 and the corresponding feature distribution deviation value, dividing them into multiple transaction categories. This classification method no longer relies solely on the inherent attributes of transactions, but dynamically based on the abnormality degree and type of their feature distribution. This means that transactions with similar abnormal feature distributions will be classified into the same category, allowing subsequent confirmation delay monitoring and anomaly judgment (steps S2-S5) to effectively target specific transaction groups that may be manipulated by hidden computing power.

[0097] This improved classification mechanism provides accurate input for subsequent confirmation delay monitoring, baseline establishment and deviation value calculation, memory pool retention time analysis, and final anomaly judgment. When transaction categories are divided based on the abnormality degree of their feature distribution, subsequent steps can more effectively focus on transaction groups that are truly likely to be manipulated by hidden computing power, thereby improving the accuracy and relevance of the entire security protection method in identifying hidden computing power manipulation, avoiding false positives for normal transactions, and ensuring timely response to abnormal transactions.

[0098] Further, step S15 includes:

[0099] S151: taking the pending transaction as a data point and the features in the abnormal feature set as feature dimensions;

[0100] S152: clustering the pending transactions according to the feature distribution deviation value to obtain multiple clustering results;

[0101] S153: Based on the clustering results, the transactions to be confirmed are divided into multiple transaction categories.

[0102] In the aforementioned technical solutions, clustering is a core technological approach. Clustering is an unsupervised machine learning technique that aims to group data points in a dataset based on their similarity or distance. In the context of blockchain network security protection, clustering can be used to identify transaction groups with similar anomalous behavior patterns.

[0103] Specifically, clustering algorithms can automatically divide transactions into different groups based on their anomaly characteristics and deviations. This ensures that transactions within the same group exhibit high consistency in their anomaly behavior, while transactions between different groups show significant differences. For example, clustering can employ the K-means algorithm, iteratively optimizing the allocation of data points into a predetermined number of clusters; the DBSCAN algorithm, discovering clusters of arbitrary shapes based on data point density; or hierarchical clustering algorithms, constructing nested clusters to form a clustering tree. Through clustering, the system can discover and distinguish transaction anomaly patterns caused by different reasons (such as covert computing power manipulation, widespread network congestion, or specific application behavior), providing a foundation for subsequent targeted analysis.

[0104] This solution introduces clustering analysis to provide a concrete and data-driven approach for classifying transactions into multiple categories based on anomaly feature sets and corresponding feature distribution deviations. This addresses the challenge of accurately and effectively grouping transactions with similar anomaly patterns in complex network environments to improve the accuracy and targeting of covert computing power manipulation detection. As a specific implementation, when treating transactions to be confirmed as data points, each transaction can be represented as a data vector, with each component corresponding to an anomaly feature. For example, if the anomaly feature set includes "transaction fee deviation," "target address type deviation," and "smart contract interaction deviation," then each transaction to be confirmed can be represented as a three-dimensional vector, with its components representing the deviations of these features.

[0105] Further, when clustering the to-be-confirmed transactions according to the feature distribution deviation values, the K-means clustering algorithm can be used. First, a cluster number K can be preset, or the K value can be dynamically determined by elbow rule, silhouette coefficient, etc. Then, the algorithm randomly selects K initial cluster centers, and iteratively assigns each to-be-confirmed transaction to the nearest cluster center, and then recalculates each cluster center until the cluster center no longer changes significantly or reaches the maximum iteration number. For example, if the system detects three main abnormal patterns, K can be set to 3. During the clustering process, the "distance" between transactions can be calculated based on the Euclidean distance or cosine similarity of their feature distribution deviation values, so as to ensure that transactions with similar deviation patterns are divided into the same group.

[0106] Thus, when dividing the to-be-confirmed transactions into multiple transaction categories according to the clustering results, each clustering result can be assigned a unique transaction category identifier. For example, if the clustering algorithm produces three clustering results, they can be named "transaction category A", "transaction category B" and "transaction category C" respectively. All to-be-confirmed transactions clustered into "transaction category A" will be classified into this specific transaction category. In this way, the subsequent analysis module can specifically monitor and analyze the transactions of "transaction category A", for example, calculate the average confirmation time delay of "transaction category A", and compare it with the confirmation time delay baseline of this category, so as to more accurately identify specific abnormalities caused by hidden computing power manipulation.

[0107] Further, step S3 comprises:

[0108] S31: identifying a plurality of time periods related to periodic congestion patterns in the blockchain network;

[0109] S32: maintaining a set of recent confirmation time delay data samples for each transaction category and each time period;

[0110] S33: calculating statistical parameters based on the recent confirmation data samples to obtain the confirmation time delay baseline in the time period;

[0111] S34: obtaining the occurrence time according to the actual confirmation time delay, and selecting the confirmation time delay baseline in the time period corresponding to the occurrence time;

[0112] S35: calculating the deviation value between the actual confirmation time delay and the confirmation time delay baseline.

[0113] Wherein, the periodic congestion pattern refers to the regular and predictable downward or fluctuating trend of network performance (such as transaction confirmation speed) in a specific time period in the blockchain network due to factors such as transaction volume or specific events.

[0114] The multiple time periods refer to dividing a complete cycle (e.g., a day or a week) into several sub-intervals with different network behavior characteristics.

[0115] The recent confirmation time delay data sample refers to a set of actual transaction confirmation time delay data collected for a specific transaction category within a specific time period before the current time point. The specific time period is set by the technical personnel according to the actual situation and can be one week or ten days, fifteen days.

[0116] The statistical parameter refers to a quantitative index used to describe the distribution characteristics of the recent confirmation time delay data sample. It can be calculated using the mean and median.

[0117] The confirmation time delay baseline refers to the range or reference value of the transaction confirmation time delay that is considered "normal" under a specific time period and for a specific transaction category. It can be determined using the confidence interval calculated by the statistical parameter. The deviation value refers to the difference between the actual confirmation time delay and the corresponding confirmation time delay baseline.

[0118] The present scheme aims to improve the accuracy of transaction anomaly judgment and effectively distinguish between hidden computing power manipulation and normal network fluctuations by establishing more refined and adaptive confirmation time delay baselines.

[0119] Specifically, in the process of establishing the confirmation time delay baseline for each transaction category and calculating the deviation value, first, multiple time periods related to periodic congestion patterns in the blockchain network are identified. This is because the actual operating environment of the blockchain network is complex, and its congestion status often shows a predictable periodicity, such as a significant increase in transaction volume leading to a general increase in confirmation time delay in a specific time period. By pre-identifying and dividing these time periods with different network characteristics, a refined context can be provided for subsequent baseline establishment.

[0120] On this basis, step S32 not only distinguishes according to transaction categories, but also collects data according to the specific time period when the transaction occurs, and only retains recent data to ensure that the baseline can dynamically reflect the current network status and avoid using outdated or unrepresentative data.

[0121] Subsequently, based on these recent, classified, and time-periodic data samples, statistical parameters are calculated to obtain the confirmation time delay baseline under a specific time period. These statistical parameters can quantitatively describe the "normal" confirmation time delay range for a specific transaction category within a specific time period, thereby forming a robust and representative reference standard. When the confirmation time delay of an actual transaction occurs, the system will obtain the time of its occurrence and intelligently select the pre-established confirmation time delay baseline under the time period corresponding to the occurrence time. This dynamic matching mechanism ensures that the comparison of the actual time delay is conducted in the most relevant "normal" background, avoiding misjudgment of universal network congestion or normal network fluctuations as anomalies.

[0122] Finally, the deviation value between the actual confirmation latency and the selected confirmation latency baseline is calculated. Since the baseline has fully considered the time period, transaction category, and dynamic changes in recent network conditions, the calculated deviation value can more accurately reflect whether there is an anomaly caused by hidden mining manipulation, rather than just normal network fluctuations or periodic congestion.

[0123] In this way, the present scheme can effectively distinguish between transaction anomalies caused by hidden mining manipulation and transaction latency caused by general network congestion or normal network fluctuations, thereby significantly improving the accuracy of anomaly judgment and providing a reliable basis for subsequent security protection alerts.

[0124] Further, step S31 includes:

[0125] S311: Monitor network performance indicators in the blockchain network;

[0126] S312: Identify a combined change pattern that periodically recurs in the network performance indicators;

[0127] S313: Define a plurality of time periods based on the start and end points of the combined change pattern.

[0128] The network performance indicators refer to quantitative data reflecting the operational status and efficiency of the blockchain network, which can be measured by transaction throughput, memory pool size, block propagation delay, average transaction fee, number of unconfirmed transactions, number of node connections, or block generation interval.

[0129] The combined change pattern that periodically recurs refers to the dynamic change rule in which multiple network performance indicators appear in coordination within a specific time period and repeatedly appear at a predictable frequency.

[0130] The start and end points of the combined change pattern refer to the specific time markers at which the combined change pattern begins and ends.

[0131] The present application achieves accurate identification of periodic congestion patterns in the blockchain network through a series of closely related steps, thereby laying the foundation for subsequent establishment of an accurate confirmation latency baseline. In one specific embodiment, in order to identify multiple time periods related to periodic congestion patterns in the blockchain network, the system can deploy a data collection module to continuously obtain real-time network performance indicators from the blockchain full node or public API interface. For example, the number of unconfirmed transactions in the current memory pool, the average transaction fee for the past five minutes, the propagation delay of the latest block, and the transaction throughput per second are collected every minute. These data can be stored in a time series database.

[0132] Subsequently, the time series data can be processed using a pattern analysis engine. The engine can employ Fourier transform or wavelet analysis-based methods to detect periodic components in the data, and combine clustering algorithms (e.g., K-means or DBSCAN) to identify periodically recurring combination change patterns exhibited by multiple indicators. For example, when transaction throughput generally decreases, while memory pool size significantly increases, and average transaction fee consistently rises from 9:00 AM to 11:00 AM every Monday, this can be identified as a typical periodic congestion pattern. Once such a pattern is identified, the system can further utilize statistical-based methods, such as sliding window mean and standard deviation-based anomaly detection, to accurately determine the start and end points of the combination change pattern. For example, when memory pool size continuously exceeds a certain threshold, and transaction fee growth rate reaches a certain value, it is marked as the start of congestion; when these indicators fall back to the normal range and stabilize for a period of time, it is marked as the end of congestion. In this way, the system can dynamically define multiple specific periodic congestion time periods, such as from 9:00 AM to 11:00 AM every Monday.

[0133] Further, step S32 includes:

[0134] S321: For each transaction category and each time period, set a fixed time window;

[0135] S322: Within the fixed time window, collect recent confirmation latency data for each transaction category in the time period;

[0136] S323: Take all recent confirmation latency data as recent confirmation latency data samples.

[0137] The "fixed time window" refers to a specific time interval preset for data collection, which can use a sliding window mechanism, such as rolling forward every fixed time (e.g., 1 hour or 4 hours), or a fixed period window, such as a specific time period every day (e.g., 9:00 AM to 10:00 AM) or a specific date every week. The setting of such a window aims to ensure the timeliness and relevance of the collected data.

[0138] Recent confirmation latency data refers to the actual time value experienced by a transaction from broadcast to packaged confirmation within these fixed time windows for a specific transaction category and a specific time period. These data are raw, unprocessed confirmation latency observations.

[0139] This scheme aims to ensure that the obtained samples are representative and stable enough to provide a reliable data basis for subsequent establishment of accurate confirmation latency baselines, thereby improving the accuracy of abnormal transaction detection.

[0140] Specifically, the present solution first sets a fixed time window for each transaction category and each time period. This setting is crucial as it addresses the issue of how to define "recent" data in a dynamic network environment. By setting a clear and fixed time window for different transaction categories and identified periodic congestion time periods, the scope and timeliness of data collection are controllable and consistent. This enables the subsequent collected data to more accurately reflect the normal behavior patterns of specific transaction categories under specific periodic network conditions, avoiding the problem of inaccurate baseline caused by ambiguous or inconsistent data collection scope.

[0141] On this basis, within the fixed time window, the system collects the recent confirmation time delay data of each transaction category in the time period. This step clearly defines the specific operation of data collection. By strictly limiting data collection within the set fixed time window, it ensures that the collected confirmation time delay data is up-to-date and highly relevant to the current network conditions. At the same time, collecting data for each transaction category and each time period separately ensures the refinement and relevance of the data, enabling the capture of confirmation time delay characteristics of different types of transactions under different network periods, laying the foundation for the establishment of a fine-grained confirmation time delay baseline.

[0142] Finally, all recent confirmation time delay data is taken as a recent confirmation time delay data sample. This step defines the data set used for baseline calculation. By aggregating all recent confirmation time delay data collected within the above fixed time window into a complete sample set, it ensures that the amount of data used for subsequent statistical analysis is sufficient and representative.

[0143] Further, step S33 includes:

[0144] S331: Based on the recent confirmation data sample, calculate the mean and standard deviation of the recent confirmation data sample;

[0145] S332: Determine the confidence interval according to the mean and standard deviation;

[0146] S333: Take the confidence interval as the confirmation time delay baseline for the time period.

[0147] Wherein, the confidence interval refers to an interval range used to estimate the population parameter in statistics, which can be calculated based on the sample mean and standard deviation, combined with a pre-set confidence level (such as 95% or 99%) through statistical formulas (such as Z distribution or t distribution).

[0148] The present solution aims to establish a confirmation time delay baseline through a more rigorous statistical method, to more accurately reflect the delay characteristics under normal network conditions, thereby improving the detection accuracy of transaction anomalies caused by hidden computing power manipulation.

[0149] Specifically, when establishing the confirmation latency baseline, first, based on the recently collected confirmation data samples, the mean and standard deviation of these samples are calculated. The mean provides the central tendency of the recent confirmation latency, that is, the average time consumption of transaction confirmation under normal circumstances, while the standard deviation quantifies the degree of dispersion of these data points, reflecting the variability of the confirmation latency within the normal fluctuation range. By combining the mean and standard deviation, a preliminary and comprehensive understanding of the overall distribution characteristics of the recent confirmation latency can be obtained, providing necessary data support for subsequent accurate definition of the "normal" range.

[0150] On this basis, according to the calculated mean and standard deviation, a confidence interval is further determined using statistical principles. This confidence interval represents the range in which the true population parameter may fall under a certain confidence level. When applied to the confirmation latency, it means that the reasonable fluctuation range of the confirmation latency of a specific transaction category within a specific time period under normal network conditions can be scientifically defined. This interval-based definition method can more comprehensively capture the latency changes caused by normal network fluctuations, thereby avoiding misjudgment of normal fluctuations as abnormal and improving the robustness of the baseline.

[0151] Finally, this determined confidence interval is directly used as the confirmation latency baseline of the transaction category in this time period. This means that subsequent judgment of whether the actual confirmation latency is abnormal is no longer compared with a fixed value, but rather whether it falls within this pre-set "normal" fluctuation range. If the actual confirmation latency exceeds this confidence interval, it indicates that it deviates from the normal range, which may indicate an abnormal situation.

[0152] Further, step S4 includes:

[0153] When the deviation value is greater than or equal to the preset deviation threshold, the first average residence time of the corresponding transaction category in the memory pool is obtained, and the second average residence time of other transaction categories in the memory pool during the same period is obtained.

[0154] The first average residence time is divided by the second average residence time to obtain the relative residence time.

[0155] The first average residence time is the average waiting time of a specific transaction category in the memory pool from entering to being packaged and confirmed, which can be achieved by taking the arithmetic mean of the residence time of all transactions of the transaction category within a specific time window.

[0156] The second average residence time is the average waiting time of all transaction categories in the memory pool during the same period, except for the specific transaction category, from entering to being packaged and confirmed, which can be achieved by taking the arithmetic mean of the residence time of all transactions of other transaction categories within the same time window.

[0157] The relative retention time refers to a ratio value obtained by dividing the first average retention time by the second average retention time, which can be a dimensionless ratio value for quantifying the retention degree of a specific transaction category relative to other transaction categories.

[0158] By dividing the first average retention time by the second average retention time, the present scheme can obtain a dimensionless ratio value as the relative retention time. This enables the system to accurately quantify the multiple of retention of a specific transaction category relative to other transaction categories, effectively distinguishing between disproportionate delay of specific transactions caused by hidden computing power manipulation and universal transaction delay caused by universal network congestion. This calculation method provides more robust data support, significantly improves the accuracy of identifying hidden computing power manipulation behavior, thereby reducing the risk of false positives and false negatives, and improving the effectiveness of blockchain network security protection.

[0159] Further, step S5 comprises:

[0160] S51: obtaining the deviation value, the relative retention time, and the network block speed;

[0161] S52: combining the deviation value, the relative retention time, and the network block speed by weighting to obtain a comprehensive anomaly index;

[0162] S53: comparing the comprehensive anomaly index with a preset anomaly threshold;

[0163] S54: determining whether there is a transaction anomaly caused by hidden computing power manipulation according to the comparison result of the comprehensive anomaly index and the preset anomaly threshold;

[0164] S55: if there is a transaction anomaly, issuing a security protection alarm.

[0165] In order to solve the problem of insufficient accuracy and robustness of the above simple judgment mechanism in identifying hidden computing power manipulation behavior, the present application proposes a more detailed judgment mechanism. The mechanism first obtains three key indicators: deviation value, relative retention time, and network block speed. The deviation value is calculated based on the difference between the actual confirmation delay of a specific transaction category and the normal baseline, directly reflecting the abnormality of transaction confirmation, while the normal baseline is established through identification of periodic congestion patterns and statistical analysis of recent confirmation delay data, ensuring the accuracy and adaptability of the baseline. The relative retention time is obtained by comparing the average retention time of a specific transaction category in the memory pool with the average retention time of other transaction categories at the same period, revealing whether the transaction category is abnormally prioritized or delayed for packaging. The network block speed as an indicator of macro network state is used to assist in distinguishing between local manipulation and universal network congestion.

[0166] In one specific embodiment, the method can be implemented as follows:

[0167] First, the system continuously obtains the deviation value, relative retention time, and network-wide block speed for a specific transaction category. For example, for a certain transaction identified as potentially abnormal, its deviation value may be 0.8 (indicating that the actual confirmation delay is 0.8 times the normal baseline), the relative retention time may be 2.5 (indicating that its retention time in the memory pool is 2.5 times that of other transactions), and the network-wide block speed may be 6 blocks per 10 minutes (close to the normal level).

[0168] To obtain the comprehensive abnormality index, a linear weighted sum method can be used. For example, the weight of the deviation value can be set to 0.4, the weight of the relative retention time can be set to 0.4, and the weight of the network-wide block speed can be set to 0.2. These weights can be obtained through historical data analysis, expert experience, or by training machine learning algorithms (such as logistic regression, support vector machines, etc.) to optimize detection performance.

[0169] Based on the above example data, the calculation of the comprehensive abnormality index can be:

[0170] Comprehensive abnormality index = (deviation value * 0.4) + (relative retention time * 0.4) + (network-wide block speed normalized value * 0.2).

[0171] It should be noted that the network-wide block speed may need to be normalized to match the numerical range of other indicators, for example, it can be converted into a percentage or ratio of deviation from the normal block speed. Assuming the normalized network-wide block speed indicator is 0.1 (indicating slightly lower than the normal level).

[0172] Then, the comprehensive abnormality index = (0.8 * 0.4) + (2.5 * 0.4) + (0.1 * 0.2) = 0.32 +1.0 + 0.02 = 1.34.

[0173] Next, the calculated comprehensive abnormality index is compared with a pre-set abnormality threshold. This pre-set abnormality threshold can be determined by statistical analysis of historical normal and abnormal data, for example, by analyzing the distribution of comprehensive abnormality indexes during a large number of normal operations, setting an upper limit of a 99% confidence interval as the threshold, or by receiving operating characteristic (ROC) curve analysis to select the best threshold to balance the false positive rate and the false negative rate. Assuming the pre-set abnormality threshold is set to 1.2.

[0174] Since the calculated comprehensive abnormality index 1.34 is greater than the preset abnormality threshold 1.2, the system can determine that there is a transaction abnormality caused by hidden computing power manipulation. Once this determination is made, the system will immediately issue a security protection alert, for example, by sending an email, an SMS message to the network administrator, or displaying a high-priority alert on the monitoring dashboard, so that timely intervention measures can be taken, such as reviewing the relevant nodes, adjusting the network routing strategy, or temporarily limiting the confirmation of specific transactions.

[0175] The present scheme combines the deviation value, the relative retention time, and the network block speed to form a comprehensive abnormality index, and makes a judgment based on the index, thereby providing a more refined and robust hidden computing power manipulation detection method. This solves the problem that when a simple judgment is made based on these indicators, the complexity of hidden computing power manipulation may not be fully captured, and the importance of each indicator varies in different scenarios, resulting in insufficient accuracy and robustness of the judgment. Therefore, the present scheme can effectively identify hidden and complex computing power manipulation behavior, thereby improving the fairness and timeliness of blockchain network transactions.

[0176] Please refer to Figure 2 , Figure 3 A blockchain network security protection system based on the above method, the system comprises:

[0177] The acquisition module 201 acquires the transaction characteristics of the transactions to be confirmed in the blockchain network, and divides the transactions to be confirmed into multiple transaction categories according to the transaction characteristics;

[0178] The monitoring module 202 monitors the actual confirmation delay of each transaction category in the multiple transaction categories;

[0179] The first calculation module 203 establishes a confirmation delay baseline under normal network conditions for each transaction category, and calculates the deviation value between the actual confirmation delay and the confirmation delay baseline;

[0180] The second calculation module 204 acquires the first average retention time of the corresponding transaction category in the memory pool when the deviation value is greater than or equal to the preset deviation threshold, and compares the first average retention time with the second average retention time of other transaction categories in the memory pool at the same period to obtain the relative retention time;

[0181] The security protection module 205 judges whether there is a transaction abnormality caused by hidden computing power manipulation according to the deviation value, the relative retention time, and the network block speed, and issues a security protection alert if there is a transaction abnormality.

[0182] Among them, the acquisition module 201 refers to the functional unit responsible for collecting raw transaction data from the blockchain network and performing preliminary processing, which can be realized by network data grabber, blockchain node API interface or distributed data collection agent.

[0183] The monitoring module 202 refers to the functional unit that continuously tracks and records the actual confirmation time required for specific transaction categories in the blockchain network, which can be realized by real-time data stream processing engine, event listener or timing query mechanism.

[0184] The first calculation module 203 refers to the functional unit for analyzing historical data to establish a normal confirmation delay pattern and quantify the degree of deviation of the current delay, which can be realized by statistical analysis engine, machine learning model or adaptive baseline algorithm.

[0185] The second calculation module 204 refers to the functional unit that further analyzes the retention of transactions in the memory pool when detecting confirmation delay anomalies, which can be realized by memory pool data parser, queue management system or time series analysis tool.

[0186] The security protection module 205 refers to the functional unit that integrates various abnormal indicators, makes a final judgment and triggers an alarm response, which can be realized by rule engine, expert system or multi-factor risk assessment model.

[0187] In order to effectively solve the efficiency and integration problems that the above method may face in actual deployment and operation, the present application proposes a blockchain network security protection system. Through modular design, the complex method steps are visualized into operational components, providing an efficient and reliable implementation platform for identifying and alerting transaction anomalies caused by hidden computing power manipulation.

[0188] Specifically, the system first acquires transaction features of transactions to be confirmed from the blockchain network through the acquisition module 201, and divides the transactions into multiple transaction categories according to these features. This classification process is the basis for subsequent refined analysis, ensuring differentiated processing of potential abnormal transactions. Subsequently, the monitoring module 202 continuously tracks and records the actual confirmation delay of each transaction in different transaction categories, providing real-time data for subsequent abnormal judgment.

[0189] On this basis, the first calculation module 203 establishes a confirmation delay baseline under normal network conditions for each transaction category and calculates the deviation value between the actual confirmation delay and the confirmation delay baseline. In this way, the system can quantify the difference between the actual situation and the normal expectation, effectively distinguish between general network congestion and specific transaction anomalies caused by hidden computing power manipulation, and avoid false positives.

[0190] When the deviation value reaches or exceeds the preset threshold, the second calculation module 204 is triggered to further obtain the first average residence time of the corresponding transaction category in the memory pool, and compare it with the second average residence time of other transaction categories in the memory pool at the same period to obtain the relative residence time. The introduction of the memory pool residence time and the calculation of the relative residence time further refine the dimensions of the abnormality judgment, because malicious delay packaging often leads to unreasonable long residence of specific transactions in the memory pool.

[0191] Finally, the security protection module 205, as the decision-making core of the system, comprehensively utilizes the deviation value, the relative residence time and the network block speed to make a comprehensive judgment. This multi-factor fusion analysis can effectively identify behaviors that do not affect the network block speed but manipulate specific transactions in a hidden manner. Once it is judged that there is a transaction anomaly, the security protection module will immediately issue a security protection alarm, thereby providing timely basis for the network to take countermeasures.

[0192] Through such a systematic construction, the present application not only provides a method for identifying hidden computing power manipulation, but also provides a platform that can efficiently and automatically implement the method, significantly improving the accuracy of detection and the timeliness of response, enabling the stable operation of complex method logic and effectively addressing the challenges in actual deployment.

[0193] In this document, relational terms such as first and second and the like can be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions.

[0194] The above only describes the embodiments of the present application and is not used to limit the protection scope of the present application. For those skilled in the art, the present application can have various modifications and changes. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A blockchain-based cyber security protection method, characterized in that, The method comprises the steps of: S1: obtaining transaction features of a to-be-confirmed transaction in a blockchain network, and dividing the to-be-confirmed transaction into multiple transaction categories according to the transaction features; S2: monitoring an actual confirmation time delay of each transaction category in the multiple transaction categories; S3: for each transaction category, establishing a confirmation time delay baseline under normal network conditions, and calculating a deviation value between the actual confirmation time delay and the confirmation time delay baseline; S4: when the deviation value is greater than or equal to a preset deviation threshold, obtaining a first average residence time of the corresponding transaction category in an in-memory pool, and comparing the first average residence time with a second average residence time of other transaction categories in the in-memory pool at the same period to obtain a relative residence time; S5: judging whether there is a transaction anomaly caused by hidden computing power manipulation according to the deviation value, the relative residence time and a network block generation speed, and if there is the transaction anomaly, issuing a security protection alarm.

2. The blockchain-based network security protection method of claim 1, wherein, Step S1 comprises: S11: obtaining transaction features of a to-be-confirmed transaction in a blockchain network; S12: monitoring real-time distribution of the transaction features in the blockchain network; S13: obtaining a normal distribution of the transaction features under normal network conditions, and comparing the real-time distribution with the preset normal distribution to obtain a feature distribution deviation value, S14: identifying an abnormal feature set of an abnormal transaction whose feature distribution deviation value is greater than or equal to a preset feature distribution deviation threshold; S15: dividing multiple transaction categories according to the abnormal feature set and the corresponding feature distribution deviation value.

3. The blockchain-based network security protection method of claim 2, wherein, Step S15 comprises: S151: taking the to-be-confirmed transaction as a data point and taking the features in the abnormal feature set as feature dimensions; S152: clustering the to-be-confirmed transaction according to the feature distribution deviation value to obtain multiple clustering results; S153: dividing the to-be-confirmed transaction into multiple transaction categories according to the clustering results.

4. The blockchain-based network security protection method of claim 1, wherein, Step S3 comprises: S31: identifying multiple time periods related to a periodic congestion mode in a blockchain network; S32: maintaining a set of recent confirmation time delay data samples for each transaction category and each time period; S33: calculating statistical parameters based on the recent confirmation data samples to obtain a confirmation time delay baseline under the time period; S34: obtaining an occurrence time according to the actual confirmation time delay, and selecting the confirmation time delay baseline under the time period corresponding to the occurrence time; S35: calculating a deviation value between the actual confirmation time delay and the confirmation time delay baseline.

5. The blockchain-based network security protection method of claim 4, wherein, Step S31 comprises: S311: monitoring network performance indicators in a blockchain network; S312: identifying a combined change mode that periodically recurs in the network performance indicators; S313: defining the multiple time periods according to start and end points of the combined change mode.

6. The blockchain-based network security protection method of claim 5, wherein, Step S32 comprises: S321: setting a fixed time window for each transaction category and each time period; S322: collecting recent confirmation time delay data of each transaction category in the time period within the fixed time window; S323: take all the recent confirmation time delay data as the recent confirmation time delay data sample.

7. The blockchain-based network security protection method of claim 6, wherein, Step S33 comprises: S331: based on the recent confirmation data sample, calculate the mean and standard deviation of the recent confirmation data sample; S332: determine a confidence interval according to the mean and standard deviation; S333: take the confidence interval as the confirmation time delay baseline under the time period. 8.The blockchain-based network security protection method of claim 1, wherein, Step S4 comprises: When the deviation value is greater than or equal to a preset deviation threshold, obtain the first average residence time of the corresponding transaction category in the memory pool, and obtain the second average residence time of other transaction categories in the memory pool at the same period; Divide the first average residence time by the second average residence time to obtain the relative residence time. 9.The blockchain-based network security protection method of claim 1, wherein, Step S5 comprises: S51: obtain the deviation value, the relative residence time, and the network block output speed; S52: weight and combine the deviation value, the relative residence time, and the network block output speed to obtain a comprehensive abnormality index; S53: compare the comprehensive abnormality index with a preset abnormality threshold; S54: determine whether there is a transaction abnormality caused by hidden computing power manipulation according to the comparison result of the comprehensive abnormality index and the preset abnormality threshold; S55: if there is the transaction abnormality, issue a security protection alarm. 10.A blockchain-based network security protection system, characterized in that, For implementing the method of any one of the above claims 1-9, the system comprises: an acquisition module: acquiring transaction features of transactions to be confirmed in a blockchain network, and dividing the transactions to be confirmed into multiple transaction categories according to the transaction features; a monitoring module: monitoring the actual confirmation time delay of each transaction category in the multiple transaction categories; a first calculation module: for each transaction category, establishing a confirmation time delay baseline under normal network conditions, and calculating a deviation value between the actual confirmation time delay and the confirmation time delay baseline; a second calculation module: when the deviation value is greater than or equal to a preset deviation threshold, obtaining the first average residence time of the corresponding transaction category in the memory pool, and comparing the first average residence time with the second average residence time of other transaction categories in the memory pool at the same period to obtain a relative residence time; a security protection module: determining whether there is a transaction abnormality caused by hidden computing power manipulation according to the deviation value, the relative residence time, and the network block output speed, and issuing a security protection alarm if there is the transaction abnormality.

Images