Consensus network health real-time detection method based on behavior divergence device

Abstract

The invention discloses a consensus network health real-time detection method based on a behavior diverging device, and particularly relates to the technical field of electronics and information. A behavior detector is deployed to collect behavior data of a target node in real time, and behavior characteristics are analyzed through four models of activeness, security, correctness and fairness; constructing a set of valid transactions, invalid transactions and camouflage attack transactions based on randomly generated transaction data and mutation rules; recording the response behavior of the target node after injecting the target node; in combination with a tree state view construction function, a network health state is analyzed based on indexes such as block confirmation time, bifurcation depth and link length; detecting consensus vulnerabilities by dynamically adjusting injection rules in an iterative manner; according to the network health degree scoring rule, the overall risk score is calculated and the alarm is triggered, malicious nodes and potential consensus vulnerabilities can be found in real time, and the method is suitable for the block chain network of various consensus mechanisms and effectively defends complex attack behaviors.

Description

Technical Field

[0001] The present invention relates to the field of electronics and information technology, and more specifically, to a consensus network health real-time detection method based on behavior divergence. Background Art

[0002] The blockchain consensus mechanism is the core of ensuring the advancement and consistency of the state of distributed systems. However, with the widespread application of blockchain technology, consensus security issues have become increasingly prominent, especially in the face of hidden and complex attacks from malicious nodes, such as double-spending attacks, selfish mining, and DDos attacks. Existing technologies usually rely on historical attack data and specific consensus design logic for vulnerability detection, such as generating data based on simulated networks and analyzing consensus behavior through machine learning. However, these methods are difficult to adapt to dynamically changing actual networks, especially when dealing with unknown attacks and diverse consensus mechanisms.

[0003] In order to solve the above problems, a technical solution is now provided. Summary of the invention

[0004] In order to overcome the above-mentioned defects of the prior art, an embodiment of the present invention provides a consensus network health real-time detection method based on behavior divergence to solve the problems raised in the above-mentioned background technology.

[0005] To achieve the above object, the present invention provides the following technical solutions:

[0006] A real-time detection method for consensus network health based on behavior divergence includes the following steps:

[0007] Deploy a behavior detector in the target blockchain network to collect the behavior data of the target node in real time, and analyze the behavior characteristics of the target node based on four behavior detection models: activity, security, correctness, and fairness;

[0008] Based on randomly generated transaction data and mutation rules, a transaction set containing valid transactions, invalid transactions, and disguised attack transactions is constructed;

[0009] Inject the transaction set into the target node and record the target node's response to each type of transaction in the transaction set;

[0010] Build a tree-like state view of the target blockchain network and analyze network health indicators, including block confirmation time, fork depth, and link length;

[0011] Compare the actual response of the target node with the expected behavior and analyze the behavioral deviation; adjust the transaction injection rules based on the deviation data and iteratively detect potential consensus vulnerabilities;

[0012] Based on the network health scoring rules, the overall risk score of the target network is calculated; if the overall risk score is lower than the set threshold, it is marked as a high-risk network and an alarm is triggered.

[0013] In a preferred embodiment, a behavior detector is deployed in the target blockchain network to collect the behavior data of the target node in real time, and analyze the behavior characteristics of the target node based on four behavior detection models: activity, security, correctness, and fairness. Specifically:

[0014] Use detectors to collect behavior data of target nodes in real time;

[0015] Use the activity model to monitor whether the target node executes all valid transactions;

[0016] Through the security model, determine whether the target node correctly rejects all invalid transactions;

[0017] Use the correctness model to confirm whether a hard fork occurs on the target node;

[0018] Through the fairness model, it is evaluated whether the target node has a fair chance of becoming a block producer.

[0019] In a preferred embodiment, based on randomly generated transaction data and mutation rules, a transaction set including valid transactions, invalid transactions and disguised attack transactions is constructed, specifically:

[0020] Generate an initial transaction set, including the transaction sender, receiver, and amount;

[0021] According to the mutation rules, generate valid transactions that comply with the account balance and system rules, invalid transactions that exceed the account balance limit, and disguised attack transactions that simulate double-spending attacks or abnormal transaction mutations;

[0022] The constructed transaction set is saved in the transaction injection module.

[0023] In a preferred embodiment, the transaction set is injected into the target node, and the response behavior of the target node to each type of transaction in the transaction set is recorded, specifically:

[0024] Inject various transactions in the transaction set into the target node;

[0025] Monitor the target node’s response to various transactions, including whether they were successfully executed, rejected, or unresponsive;

[0026] Compare the response behavior of the target node with the expected behavior and record the deviation data;

[0027] Based on the deviation data, the target node’s ability to handle abnormal transactions is evaluated.

[0028] In a preferred embodiment, a tree state view of the target blockchain network is constructed to analyze network health indicators, including block confirmation time, fork depth, and link length, specifically:

[0029] Build a tree diagram from the latest confirmed block before the test starts and record the node status;

[0030] Mark the forked block and confirm the fork depth and quantity;

[0031] Evaluate the health of the network based on the latest confirmed block confirmation time, fork status and link length.

[0032] In a preferred embodiment, the actual response of the target node is compared with the expected behavior, and the behavior deviation is analyzed; according to the deviation data, the transaction injection rules are adjusted, and potential consensus vulnerabilities are iteratively detected, specifically:

[0033] Compare the actual transaction processing results of the target node with the expected results of the behavior detector to identify behavioral deviations;

[0034] Adjust mutation rules and optimize transaction injection strategies based on identified behavioral deviations;

[0035] Iteratively inject the optimized transaction set to continue detecting potential consensus vulnerabilities in the target node.

[0036] In a preferred embodiment, based on the network health scoring rule, the overall risk score of the target network is calculated; if the overall risk score is lower than the set threshold, it is marked as a high-risk network and an alarm is triggered, specifically:

[0037] Scores are calculated based on confirmation time, fork depth, and link length;

[0038] The scores are weighted and summed according to the set weights to obtain the total score;

[0039] If the total score is lower than the threshold or the individual score is lower than the threshold, the network is marked as high-risk and an alert is automatically triggered.

[0040] The technical effects and advantages of the consensus network health real-time detection method based on behavior divergence of the present invention are as follows:

[0041] The combination of behavior detector, abnormal divergence message injection module and tree state view effectively improves the security and dynamic defense capability of blockchain consensus network. The behavior detector analyzes the behavior of target nodes in real time based on four dimensions: activity, security, correctness and fairness, and can quickly identify potential anomalies. The abnormal divergence message injection module induces node behavior by generating disguised transactions, revealing hidden vulnerabilities and attack paths. At the same time, the tree state view uses fork depth, block confirmation time and link length as core indicators to provide intuitive network health analysis to help accurately assess network risks. It solves the problems of lag and poor adaptability caused by relying on historical attack data and simulated networks, and can also achieve rapid response and dynamic adjustment for complex real-time attacks. In addition, the use of a highly versatile behavior detection mechanism is not limited to a specific consensus protocol, which effectively improves flexibility and adaptability, is applicable to a variety of blockchain scenarios, significantly reduces the risks brought by consensus failure, and improves the overall robustness and security of the blockchain system. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 This is a schematic diagram of a consensus network health real-time detection method based on a behavior divergence device according to the present invention. DETAILED DESCRIPTION

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

[0044] Example 1

[0045] Figure 1 The present invention provides a consensus network health real-time detection method based on behavior divergence, which includes the following steps:

[0046] Deploy a behavior detector in the target blockchain network to collect the behavior data of the target node in real time, and analyze the behavior characteristics of the target node based on four behavior detection models: activity, security, correctness, and fairness;

[0047] Based on randomly generated transaction data and mutation rules, a transaction set containing valid transactions, invalid transactions, and disguised attack transactions is constructed;

[0048] Inject the transaction set into the target node and record the target node's response to each type of transaction in the transaction set;

[0049] Build a tree-like state view of the target blockchain network and analyze network health indicators, including block confirmation time, fork depth, and link length;

[0050] Compare the actual response of the target node with the expected behavior and analyze the behavioral deviation; adjust the transaction injection rules based on the deviation data and iteratively detect potential consensus vulnerabilities;

[0051] Based on the network health scoring rules, the overall risk score of the target network is calculated; if the overall risk score is lower than the set threshold, it is marked as a high-risk network and an alarm is triggered.

[0052] Specifically, a behavior detector is deployed in the target blockchain network to collect the behavior data of the target node in real time, and the behavior characteristics of the target node are analyzed based on four behavior detection models: activity, security, correctness, and fairness, including:

[0053] Use detectors to collect the behavior data of target nodes in real time; specifically, through the deployed behavior detectors, the behavior information of target nodes is collected in real time from the blockchain network. These data include the response of the node to process transactions, the record of participating in the block generation process, the interaction information with other nodes, etc., which are used to fully grasp the real-time status of the node;

[0054] Use the activity model to monitor whether the target node executes all valid transactions. Specifically, the activity model is used to check the target node's ability to process legitimate transactions. Valid transactions are transactions that comply with the rules of the blockchain network and should be accurately executed by the target node. If the node does not correctly execute valid transactions, it may indicate that it is behaving abnormally or is affected by an attack.

[0055] Through the security model, determine whether the target node correctly rejects all invalid transactions; specifically, the security model is used to analyze whether the target node handles invalid transactions accurately; invalid transactions may be format errors, excessive amounts, or forged transactions, and the node should be able to reject these transactions;

[0056] Use the correctness model to confirm whether the target node has a hard fork. Specifically, the correctness model is used to detect whether the target node has a state divergence (hard fork) when participating in the consensus. A hard fork indicates that the consensus of the network may be destroyed, and the node fails to reach a consistent state with other nodes, which may affect the overall stability of the blockchain.

[0057] The fairness model is used to evaluate whether the target node has a fair chance of becoming a block producer. Specifically, the fairness model is used to evaluate whether the target node's chance of participating in block production is distributed according to the expectations of the consensus mechanism. For example, under the PoW or PoS mechanism, the chance of producing blocks should be proportional to the computing power or equity. Abnormal block distribution may indicate that the node is cheating.

[0058] Specifically, based on randomly generated transaction data and mutation rules, a transaction set containing valid transactions, invalid transactions, and disguised attack transactions is constructed, including:

[0059] Generate an initial transaction set, including the transaction sender, receiver, and amount. Specifically, the initial transaction set is the basis of the test data and contains the basic elements of the transaction, such as the transaction sender address, receiver address, and transaction amount. These elements follow the basic rules of the blockchain network to ensure the legitimacy of the initial transaction.

[0060] According to the mutation rules, generate valid transactions that meet the account balance and system rules, invalid transactions that exceed the account balance limit, and disguised attack transactions that simulate double-spending attacks or abnormal transaction mutations; specifically, valid transactions refer to transactions whose amounts meet the balance of the sending account, follow network rules, and simulate normal business scenarios; invalid transactions refer to transactions whose amounts exceed the account balance or violate other rules, and test the node's ability to reject abnormal transactions; disguised attack transactions refer to simulated double-spending attacks, signature anomalies and other attack behaviors, which are used to detect the performance of nodes in malicious transaction scenarios;

[0061] The constructed transaction set is saved in the transaction injection module.

[0062] Specifically, the transaction set is injected into the target node, and the target node's response behavior to various transactions in the transaction set is recorded, including:

[0063] Inject all kinds of transactions in the transaction set into the target node; specifically, inject the constructed transaction into the target node; the injection process should ensure that the transaction flow is consistent with the normal network transaction, so that the node cannot distinguish between the test transaction and the real transaction;

[0064] Monitor the target node's response to various transactions, including whether it is successfully executed, rejected, or unresponsive. Specifically, successful execution: the node correctly processes the transaction and updates the blockchain status; rejection: the node recognizes that the transaction is invalid and refuses to execute it; no response: the node does not provide any feedback on the transaction, which may be affected by an attack or failure.

[0065] Compare the response behavior of the target node with the expected behavior and record the deviation data;

[0066] Based on the deviation data, the target node's ability to handle abnormal transactions is evaluated; specifically, based on the recorded deviation data, whether the target node can accurately distinguish between valid transactions and abnormal transactions is analyzed, and its security and robustness are evaluated.

[0067] Specifically, we build a tree-like state view of the target blockchain network and analyze network health indicators, including block confirmation time, fork depth, and link length, including:

[0068] Build a tree diagram from the latest confirmed block before the test starts to record the node status; specifically, based on the latest confirmed block at the start of the test, extract block data from the blockchain network, build a tree status view, and display the relationship and fork status between nodes;

[0069] Mark forked blocks and confirm the depth and number of forks. Specifically, mark forked blocks caused by conflicts or attacks in the tree diagram, count the number of forks and their depth, and analyze the impact of forks on consensus health.

[0070] Based on the latest confirmed block confirmation time, fork situation and link length, the health status of the network is evaluated; specifically, the consensus health of the target network is comprehensively judged based on the confirmed block time, fork depth and link growth.

[0071] Specifically, compare the actual response of the target node with the expected behavior and analyze the behavioral deviation; adjust the transaction injection rules based on the deviation data and iteratively detect potential consensus vulnerabilities, including:

[0072] Compare the actual transaction processing results of the target node with the expected results of the behavior detector to identify behavioral deviations; specifically, compare the target node's response to the transaction with the expected results of the behavior detector one by one, and find and record node behavior deviations, including erroneous execution, rejection, or delayed response;

[0073] According to the identified behavioral deviations, the mutation rules are adjusted and the transaction injection strategy is optimized. Specifically, the transaction generation rules are dynamically adjusted according to the deviation information. For example, for unidentified double-spending attacks, the data structure of disguised transactions is optimized to increase the complexity of the attack.

[0074] Iteratively inject the optimized transaction set to continue to detect potential consensus vulnerabilities of the target node; specifically, repeatedly inject the optimized transaction set to continuously iteratively detect weaknesses and vulnerabilities of the target node until the test coverage is reached or the vulnerability is confirmed.

[0075] Specifically, based on the network health scoring rules, the overall risk score of the target network is calculated; if the overall risk score is lower than the set threshold, it is marked as a high-risk network and an alarm is triggered, including:

[0076] Scores are calculated based on confirmation time, fork depth, and link length. Specifically, confirmation time is the efficiency of blockchain in processing transactions. A long time may indicate network congestion or attack impact. Fork depth is a large fork depth that may indicate selfish mining or network splitting. Link length is the stability of chain growth. Abnormal interruptions or too many forks may indicate health problems.

[0077] The calculation formula for the confirmation time score is:

[0078] Among them, S t is the confirmation time score value; T node is the delay time of the target node; T avg is the historical average confirmation time of the network; α, β are delay tolerance coefficients;

[0079] The calculation formula of the fork depth score is: Among them, S f N is the bifurcation depth score; fork ,N max ,D fork ,D max They are the number of forks in the current network, the maximum number of tolerable forks, the maximum depth of forks, and the maximum tolerable depth of forks;

[0080] The link length score calculation formula is: Among them, S l is the link length score; L max ,L min are the longest path length and the shortest path length of the chain respectively; k is the sensitivity parameter; T block is the number of blocks generated per unit time;

[0081] The scores are weighted and summed according to the set weights to obtain the total score. Specifically, according to the network health scoring rules, weights are assigned to each indicator to calculate the total score.

[0082] The total score is calculated as follows: total =ω t *S t +ω f *S f +ω l *S l ; Among them, S total is the total score; t ,ω f ,ω l are the weights of the confirmation time score, fork length score, and link length score respectively;

[0083] If the total score is lower than or the individual score is lower than the threshold, it will be marked as a high-risk network and an alarm will be automatically triggered; specifically, when the total score or the individual score is lower than the set threshold, the network will be marked as high-risk and an alarm will be sent to remind users to stop performing important transactions in the network;

[0084] Set a scoring threshold. Networks below this threshold will be marked as abnormal behavior. At the same time, set a threshold for each indicator. The scoring interval is set as follows:

[0085] High-risk network: The total score is lower than a certain threshold (such as 0.4) or a single indicator is lower than 0.3, and there are many abnormal behaviors. At this time, users need to bear great risks when trading in this network state;

[0086] Potentially risky networks: The total score is between 0.4 and 0.6. There may be intermittent or slight behavioral deviations. At this time, users need to bear certain risks when trading in this network state, and users need to compromise between transaction benefits and network risks.

[0087] Normal network: The total score is higher than 0.6. The risk of users trading in this network state is low.

[0088] The above formulas are all dimensionless and numerical calculations. The formula is a formula for the most recent real situation obtained by collecting a large amount of data and performing software simulation. The preset parameters and thresholds in the formula are set by technicians in this field according to actual conditions.

[0089] The above embodiments can be implemented in whole or in part by software, hardware, firmware or any other combination. When implemented using software, the above embodiments can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that contains one or more available media sets. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium. The semiconductor medium can be a solid-state hard disk.

[0090] Those of ordinary skill in the art will appreciate that the modules and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0091] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and modules described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0092] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the modules is only a logical function division. There may be other division methods in actual implementation, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.

[0093] The modules described as separate components may or may not be physically separated, and the components shown as modules may or may not be physical modules, and may be located in one place or distributed on multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0094] In addition, each functional module in each embodiment of the present application may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0095] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0096] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0097] Finally: The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

Claims

1. A consensus network health real-time detection method based on behavior divergence, characterized in that: The steps include: Deploy a behavior detector in the target blockchain network to collect the behavior data of the target node in real time, and analyze the behavior characteristics of the target node based on four behavior detection models: activity, security, correctness, and fairness; Based on randomly generated transaction data and mutation rules, a transaction set containing valid transactions, invalid transactions, and disguised attack transactions is constructed; Inject the transaction set into the target node and record the target node's response to each type of transaction in the transaction set; Build a tree-like state view of the target blockchain network and analyze network health indicators, including block confirmation time, fork depth, and link length; Compare the actual response of the target node with the expected behavior and analyze the behavioral deviation; Adjust transaction injection rules based on deviation data and iteratively detect potential consensus vulnerabilities; Based on the network health scoring rules, the overall risk score of the target network is calculated; if the overall risk score is lower than the set threshold, it is marked as a high-risk network and an alarm is triggered.

2. According to claim 1, a consensus network health real-time detection method based on behavior divergence is characterized in that: Deploy a behavior detector in the target blockchain network to collect the behavior data of the target node in real time, and analyze the behavior characteristics of the target node based on four behavior detection models: activity, security, correctness, and fairness. Specifically: Use detectors to collect behavior data of target nodes in real time; Use the activity model to monitor whether the target node executes all valid transactions; Through the security model, determine whether the target node correctly rejects all invalid transactions; Use the correctness model to confirm whether a hard fork occurs on the target node; Through the fairness model, it is evaluated whether the target node has a fair chance of becoming a block producer.

3. According to claim 1, a consensus network health real-time detection method based on behavior divergence is characterized in that: Based on randomly generated transaction data and mutation rules, a transaction set containing valid transactions, invalid transactions, and disguised attack transactions is constructed, specifically: Generate an initial transaction set, including the transaction sender, receiver, and amount; According to the mutation rules, generate valid transactions that comply with the account balance and system rules, invalid transactions that exceed the account balance limit, and disguised attack transactions that simulate double-spending attacks or abnormal transaction mutations; The constructed transaction set is saved in the transaction injection module.

4. According to claim 1, a consensus network health real-time detection method based on behavior divergence is characterized in that: Inject the transaction set into the target node and record the target node's response to each type of transaction in the transaction set, specifically: Inject various transactions in the transaction set into the target node; Monitor the target node’s response to various transactions, including whether they were successfully executed, rejected, or unresponsive; Compare the response behavior of the target node with the expected behavior and record the deviation data; Based on the deviation data, the target node’s ability to handle abnormal transactions is evaluated.

5. According to claim 1, a consensus network health real-time detection method based on behavior divergence is characterized in that: Construct a tree-like state view of the target blockchain network and analyze network health indicators, including block confirmation time, fork depth, and link length, specifically: Build a tree diagram from the latest confirmed block before the test starts and record the node status; Mark the forked block and confirm the fork depth and quantity; Evaluate the health of the network based on the latest confirmed block confirmation time, fork status and link length.

6. According to claim 1, a consensus network health real-time detection method based on behavior divergence is characterized in that: Compare the actual response of the target node with the expected behavior and analyze the behavioral deviation; adjust the transaction injection rules based on the deviation data and iteratively detect potential consensus vulnerabilities, specifically: Compare the actual transaction processing results of the target node with the expected results of the behavior detector to identify behavioral deviations; Adjust mutation rules and optimize transaction injection strategies based on identified behavioral deviations; Iteratively inject the optimized transaction set to continue detecting potential consensus vulnerabilities in the target node.

7. The method for real-time detection of consensus network health based on behavior divergence according to claim 1 is characterized in that: Based on the network health scoring rules, the overall risk score of the target network is calculated; if the overall risk score is lower than the set threshold, it is marked as a high-risk network and an alarm is triggered. Specifically: Scores are calculated based on confirmation time, fork depth, and link length; The scores are weighted and summed according to the set weights to obtain the total score; If the total score is lower than the threshold or the individual score is lower than the threshold, the network is marked as high-risk and an alert is automatically triggered.

Images