A consensus network health real-time detection method based on a behavior diverter

Abstract

The application discloses a consensus network health real-time detection method based on a behavior diverter, and particularly relates to the field of electronic and information technology; behavior data of a target node is collected in real time through a behavior detector, and behavior characteristics are analyzed through four models of activity, security, correctness and fairness; based on randomly generated transaction data and mutation rules, a set of effective transactions, invalid transactions and disguised attack transactions is constructed; the response behavior of the target node after injection is recorded; a tree state view construction function is combined to analyze the network health state based on indexes such as block confirmation time, bifurcation depth and link length; consensus vulnerabilities are iteratively detected through dynamic adjustment of injection rules; and according to network health degree scoring rules, overall risk scores are calculated and alarms are triggered, so that malicious nodes and potential consensus vulnerabilities can be found in real time, the method is suitable for blockchain networks of various consensus mechanisms, and complex attack behaviors can be effectively prevented.

Description

Technical Field

[0001] This invention relates to the field of electronics and information technology, and more specifically, to a method for real-time health detection of consensus networks based on behavioral divergent generators. Background Technology

[0002] Blockchain consensus mechanisms are central to ensuring the state progression and consistency of distributed systems. However, with the widespread application of blockchain technology, consensus security issues have become increasingly prominent, especially when facing attacks from malicious nodes that are covert and complex, such as double-spending attacks, selfish mining, and DDoS attacks. Existing technologies typically 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 struggle to adapt to dynamically changing real-world networks, exhibiting significant limitations, particularly when dealing with unknown attacks and diverse consensus mechanisms.

[0003] To address the aforementioned problems, a technical solution is provided. Summary of the Invention

[0004] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a real-time health detection method for consensus networks based on behavior divergers to address the problems mentioned in the background art.

[0005] To achieve the above objectives, the present invention provides the following technical solution:

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

[0007] Deploy behavior detectors in the target blockchain network to collect behavior data of target nodes in real time, and analyze the behavior characteristics of target nodes 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 spoofed attack transactions is constructed.

[0009] Inject the transaction set into the target node and record the target node's response behavior to various types of transactions in the transaction set;

[0010] Construct a tree-structured 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 to 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 behavioral data of target nodes in real time. The behavior characteristics of the target nodes are then analyzed based on four behavior detection models: activity, security, correctness, and fairness. Specifically:

[0014] Utilize detectors to collect real-time behavioral data of target nodes;

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

[0016] The security model is used to determine whether the target node correctly rejects all invalid transactions.

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

[0018] The fairness model is used to assess whether the target node has a fair chance of becoming a block producer.

[0019] In a preferred embodiment, a transaction set comprising valid transactions, invalid transactions, and spoofing / attack transactions is constructed based on randomly generated transaction data and mutation rules, specifically as follows:

[0020] Generate an initial set of transactions, including the sender, receiver, and amount.

[0021] Based on the mutation rules, generate valid transactions that conform to the account balance and system rules, invalid transactions that exceed the account balance limit, and fake 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, a transaction set is injected into the target node, and the target node's response behavior to various types of transactions in the transaction set is recorded, specifically as follows:

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

[0025] Monitor the target node's response to various types of transactions, including whether the transaction was successfully executed, rejected, or not responded to.

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

[0027] Based on the deviation data, assess the target node's ability to handle abnormal transactions.

[0028] In a preferred embodiment, a tree-structured 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 of the latest confirmed blocks before the test begins and record the node status;

[0030] Mark the forked blocks and confirm the fork depth and number;

[0031] Assess 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 to analyze behavioral deviations; based on the deviation data, the transaction injection rules are adjusted, and potential consensus vulnerabilities are iteratively detected, specifically as follows:

[0033] By comparing the actual transaction processing results of the target node with the expected results of the behavior detector, behavioral deviations can be identified.

[0034] Based on the identified behavioral deviations, adjust the mutation rules and optimize the transaction injection strategy;

[0035] The optimized transaction set is injected iteratively, and potential consensus vulnerabilities in the target node are further detected.

[0036] In a preferred embodiment, the overall risk score of the target network is calculated based on network health scoring rules; if the overall risk score is lower than a 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 or a single score is lower than the threshold, the network is marked as high-risk and an alarm is automatically triggered.

[0040] The technical effects and advantages of the real-time health detection method for consensus networks based on behavior divergers proposed in this invention are as follows:

[0041] By combining a behavior detector, an anomaly message injection module, and a tree-structured state view, the security and dynamic defense capabilities of the blockchain consensus network are effectively enhanced. The behavior detector analyzes target node behavior in real time based on four dimensions: activity, security, correctness, and fairness, enabling rapid identification of potential anomalies. The anomaly message injection module induces node behavior by generating fake transactions, revealing hidden vulnerabilities and attack paths. Simultaneously, the tree-structured state view provides intuitive network health analysis using fork depth, block confirmation time, and link length as core indicators, helping to accurately assess network risks. This addresses the lag and poor adaptability issues caused by relying on historical attack data and simulated networks, and also enables rapid response and dynamic adjustment for complex real-time attacks. Furthermore, the adoption of a highly versatile behavior detection mechanism, not limited to a specific consensus protocol, effectively improves flexibility and adaptability, making it suitable for various blockchain scenarios, significantly reducing the risk of consensus failure, and enhancing the overall robustness and security of the blockchain system. Attached Figure Description

[0042] Figure 1 This is a schematic diagram of a real-time health detection method for consensus networks based on a behavior diverger, according to the present invention. Detailed Implementation

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

[0044] Example 1

[0045] Figure 1 This invention presents a real-time health detection method for consensus networks based on behavior divergers, comprising the following steps:

[0046] Deploy behavior detectors in the target blockchain network to collect behavior data of target nodes in real time, and analyze the behavior characteristics of target nodes 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 spoofed attack transactions is constructed.

[0048] Inject the transaction set into the target node and record the target node's response behavior to various types of transactions in the transaction set;

[0049] Construct a tree-structured 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 to 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 real-time behavioral data of the target nodes. The behavioral characteristics of the target nodes are analyzed based on four behavior detection models: activity, security, correctness, and fairness.

[0053] The system utilizes detectors to collect real-time behavioral data from target nodes. Specifically, by deploying behavioral detectors, it gathers real-time behavioral information about target nodes from the blockchain network. This data includes the node's response to transaction processing, records of its participation in the block production process, and interaction information with other nodes, providing a comprehensive understanding of the node's real-time status.

[0054] The activity model is used 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 those that conform to the rules of the blockchain network and should be executed accurately by the target node. If a node fails to execute valid transactions correctly, it may indicate abnormal behavior or that it has been attacked.

[0055] The security model determines whether the target node correctly rejects all invalid transactions. Specifically, the security model analyzes whether the target node's handling of invalid transactions is accurate. Invalid transactions may be due to format errors, exceeding amount limits, or forgery, and the node should be able to reject these transactions.

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

[0057] The fairness model assesses whether the target node's chance of becoming a block producer is fair. Specifically, the fairness model is used to assess whether the target node's chance of participating in block production is distributed as expected by the consensus mechanism. For example, under the PoW or PoS mechanism, the opportunity to produce blocks should be proportional to computing power or stake. Abnormal block distribution may indicate that nodes are cheating.

[0058] Specifically, based on randomly generated transaction data and mutation rules, a transaction set is constructed that includes valid transactions, invalid transactions, and spoofed attack transactions, 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 a transaction, such as the sender's address, receiver's address, and transaction amount. These elements follow the basic rules of the blockchain network to ensure the legitimacy of the initial transactions.

[0060] Based on mutation rules, valid transactions that conform to account balance and system rules, invalid transactions that exceed account balance limits, and spoofed attack transactions that simulate double-spending attacks or abnormal transaction mutations are generated. Specifically, valid transactions refer to transactions whose amounts conform to the sending account balance, follow network rules, and simulate normal business scenarios; invalid transactions refer to transactions whose amounts exceed the account balance or violate other rules, testing the node's ability to reject abnormal transactions; spoofed attack transactions refer to simulated attacks such as double-spending attacks and signature anomalies, used to detect the node's performance 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, recording the target node's response behavior to various types of transactions in the transaction set, including:

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

[0064] Monitor the target node's response to various types of transactions, including whether it is successfully executed, rejected, or unresponsive. Specifically, successful execution means the node correctly processes the transaction and updates the blockchain state; rejection means the node identifies the transaction as invalid and refuses to execute it; and unresponsive means the node does not provide any feedback on the transaction, which may be due to an attack or malfunction.

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

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

[0067] Specifically, a tree-structured state view of the target blockchain network is constructed, and network health indicators are analyzed, including block confirmation time, fork depth, and link length, including:

[0068] A tree diagram is constructed from the latest confirmed block before the test begins, recording the node status; specifically, based on the latest confirmed block at the start of the test, block data is extracted from the blockchain network to construct a tree state view, showing the relationships and forks 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 and depth of forks, and analyze the impact of forks on consensus health.

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

[0071] Specifically, the actual response of the target node is compared with the expected behavior to analyze behavioral deviations; based on the deviation data, the transaction injection rules are adjusted, and potential consensus vulnerabilities are iteratively detected, including:

[0072] By comparing the actual transaction processing results of the target node with the expected results of the behavior detector, behavioral deviations are identified. Specifically, the target node's response to the transaction is compared with the expected results of the behavior detector one by one to discover and record node behavioral deviations, including erroneous execution, rejection, or delayed response.

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

[0074] The optimized transaction set is injected iteratively to continue detecting potential consensus vulnerabilities in the target node. Specifically, the optimized transaction set is injected repeatedly to continuously iterate and detect the weaknesses and vulnerabilities of the target node until test coverage is achieved or the vulnerability is confirmed.

[0075] Specifically, based on network health scoring rules, an overall risk score for the target network is calculated; if the overall risk score is lower than a 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 reflects the efficiency of the blockchain in processing transactions; excessively long times may indicate network congestion or attacks. Fork depth indicates selfish mining or network splitting issues. Link length reflects the stability of chain growth; abnormal interruptions or excessive forks may indicate health problems.

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

[0078] Among them, S t To confirm the time score; T node T represents the delay time of the target node. avg The network's historical average confirmation time is α; β are latency tolerance coefficients.

[0079] The formula for calculating the bifurcation depth score is: Among them, S f N represents the bifurcation depth score. fork N max D fork D max These are the current number of forks, the maximum tolerable number of forks, the maximum depth of forks, and the maximum tolerable fork depth, respectively.

[0080] The formula for calculating the link length score is: Among them, S l Link length score; L max ,L min These are the longest path length and shortest path length of the chain, respectively; k is the sensitivity parameter; T block The number of blocks generated per unit of 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 and the total score is calculated.

[0082] The formula for calculating the total score is: S total =ω t *S t +ω f *S f +ω l *S l Among them, S total For the total score; ω t ,ω f ,ω l The weights are respectively the confirmation time score, the fork length score, and the link length score;

[0083] If the total score or a single score is below the threshold, the network is marked as high-risk and an alarm is automatically triggered. Specifically, when the total score or a single score is below the set threshold, the network is marked as high-risk and an alarm is sent to prompt the user to stop important transactions on that network.

[0084] A scoring threshold is set; networks falling below this threshold will be flagged as exhibiting abnormal behavior. Individual metric thresholds are also established. The scoring ranges are set as follows:

[0085] High-risk network: The total score is below a certain threshold (such as 0.4) or a single indicator is below 0.3, indicating a lot of abnormal behavior. Users will face great risks when trading in this network.

[0086] Potentially risky network: The total score is between 0.4 and 0.6, which may indicate intermittent or slight behavioral biases. Users in this network state will be subject to certain risks when making transactions, and need to make a trade-off between transaction gains and network risks.

[0087] Normal network: The overall score is higher than 0.6, and the risk of transactions is low for users in this network state.

[0088] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters and thresholds in the formulas are set by those skilled in the art according to the actual situation.

[0089] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as 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, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. 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 includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0090] Those skilled in the art will recognize that the modules and algorithm steps of the various examples 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 implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

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

[0092] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

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

[0094] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0095] If the aforementioned functions are implemented as software functional 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 this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0096] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0097] In conclusion, 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 within the protection scope of the present invention.

Claims

1. A real-time health detection method for consensus networks based on behavior divergers, characterized in that, Includes the following steps: Deploy behavior detectors in the target blockchain network to collect behavior data of target nodes in real time, and analyze the behavior characteristics of target nodes 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 spoofed attack transactions is constructed. Inject the transaction set into the target node and record the target node's response behavior to various types of transactions in the transaction set; Construct a tree-structured 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; Based on the deviation data, adjust the transaction injection rules 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. The real-time health detection method for consensus networks based on behavior divergers according to claim 1, characterized in that, A behavior detector is deployed in the target blockchain network to collect real-time behavior data of the target nodes. The behavior characteristics of the target nodes are analyzed based on four behavior detection models: activity, security, correctness, and fairness. Specifically: Utilize detectors to collect real-time behavioral data of target nodes; Use an activity model to monitor whether the target node has executed all valid transactions; The security model is used to determine whether the target node correctly rejects all invalid transactions. Use the correctness model to confirm whether the target node has undergone a hard fork; The fairness model is used to assess whether the target node has a fair chance of becoming a block producer.

3. The real-time health detection method for consensus networks based on behavior divergers according to claim 1, characterized in that, Based on randomly generated transaction data and mutation rules, a transaction set is constructed that includes valid transactions, invalid transactions, and spoofed attack transactions, specifically: Generate an initial set of transactions, including the sender, receiver, and amount. Based on the mutation rules, generate valid transactions that conform to the account balance and system rules, invalid transactions that exceed the account balance limit, and fake attack transactions that simulate double-spending attacks or abnormal transaction mutations. The constructed transaction set is saved in the transaction injection module.

4. The real-time health detection method for consensus networks based on behavior divergers according to claim 1, characterized in that, Inject the transaction set into the target node and record the target node's response behavior to various types of transactions in the transaction set, specifically: Inject various transactions from the transaction set into the target node; Monitor the target node's response to various transactions, including whether the transaction was successfully executed, rejected, or not responded to. Compare the response behavior of the target node with the expected behavior and record the deviation data; Based on the deviation data, assess the target node's ability to handle abnormal transactions.

5. The real-time health detection method for consensus networks based on behavior divergers according to claim 1, characterized in that, Construct a tree-structured state view of the target blockchain network and analyze network health metrics, including block confirmation time, fork depth, and link length, specifically: Build a tree diagram of the latest confirmed blocks before the test begins and record the node status; Mark the forked blocks and confirm the fork depth and number; Assess the health of the network based on the latest confirmed block confirmation time, fork status, and link length.

6. The real-time health detection method for consensus networks based on behavior divergers according to claim 1, characterized in that, Compare the actual response of the target node with the expected behavior to analyze behavioral deviations; based on the deviation data, adjust the transaction injection rules and iteratively detect potential consensus vulnerabilities, specifically as follows: By comparing the actual transaction processing results of the target node with the expected results of the behavior detector, behavioral deviations can be identified. Based on the identified behavioral deviations, adjust the mutation rules and optimize the transaction injection strategy; The optimized transaction set is injected iteratively, and potential consensus vulnerabilities in the target node are further detected.

7. The real-time health detection method for consensus networks based on behavior divergers according to claim 1, characterized in that, Based on network health scoring rules, the overall risk score of the target network is calculated; if the overall risk score is lower than a 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 or a single score is lower than the threshold, the network is marked as high-risk and an alarm is automatically triggered.

Images