A Blockchain-Based Distributed Network Intrusion Incident Tracing Method and System

Abstract

This invention discloses a blockchain-based distributed network intrusion event tracing method and system, belonging to the field of network intrusion tracing technology. The method includes: collecting intrusion event-related data on the distributed node side and establishing a multi-dimensional event fingerprint chain; generating tracing fragments and completing their signatures on the chain; initiating a splicing proposal, with multiple participating nodes voting on the splicing proposal on-chain based on their local verification results and reputation weights; establishing a cross-node attack path sketch; and after global verification of the cross-node attack path sketch through on-chain voting, constructing a tracing pattern library. This invention solves the technical problems of easily tampered distributed network intrusion event tracing data and poor cross-node verification consistency in existing technologies, leading to insufficient accuracy and reliability of tracing results. It achieves secure and accurate tracing of distributed network intrusion event tracing data, improving the accuracy and reliability of distributed network intrusion event tracing.

Description

Technical Field

[0001] This invention relates to the field of network intrusion tracing technology, specifically to a distributed network intrusion event tracing method and system based on blockchain. Background Technology

[0002] In distributed network environments, the large number of network nodes, complex topologies, and frequent data interactions often lead to intrusion incidents exhibiting characteristics of cross-node propagation and concealed attack paths, making intrusion incident tracing difficult. Current technologies for tracing distributed network intrusion incidents often store tracing data on a single node or centralized platform, making it susceptible to node attacks and human tampering, resulting in insufficient data credibility and unreliability as a tracing basis. During cross-node tracing, clock synchronization among nodes is difficult, and the lack of a unified verification mechanism makes it difficult to achieve consistency verification of tracing information generated by different nodes, hindering accurate reconstruction of attack paths. Furthermore, the lack of a structured extraction and reuse mechanism for intrusion incident characteristics necessitates repeated data collection and analysis for each tracing attempt, which is not only inefficient but also makes it difficult to develop standardized tracing templates to address similar intrusion incidents.

[0003] Existing technologies suffer from technical problems such as the susceptibility of data tampering in distributed network intrusion event tracing and poor cross-node verification consistency, leading to insufficient accuracy and reliability of tracing results. Summary of the Invention

[0004] This application provides a blockchain-based distributed network intrusion event tracing method and system to address the technical problems in existing distributed network intrusion event tracing technologies, such as easy tampering of data and poor cross-node verification consistency, which lead to insufficient accuracy and reliability of tracing results.

[0005] In view of the above problems, this application provides a blockchain-based distributed network intrusion event tracing method and system.

[0006] The first aspect of this application provides a blockchain-based distributed network intrusion event tracing method, the method comprising:

[0007] Intrusion event-related data is collected on the distributed node side. Event fingerprints are extracted from the intrusion event-related data to establish a multi-dimensional event fingerprint chain, which includes a traffic pattern fingerprint chain, an attack behavior sequence fingerprint chain, and an environmental context fingerprint chain. The multi-dimensional event fingerprint chain is input into a tracing agent set on the distributed nodes. The tracing agent generates tracing fragments and signs them on the blockchain. After the indexes of several tracing fragments are written to the blockchain, any qualified synthesizer initiates a splicing proposal. Multiple participating nodes vote on the splicing proposal on the blockchain based on their local verification results and reputation weights. During the on-chain voting process for the splicing proposal, time-causal consistency analysis of the tracing fragments of the corresponding participating nodes is performed to establish a cross-node attack path sketch. After global verification of the cross-node attack path sketch through on-chain voting, a network intrusion event tracing chain is constructed. The network intrusion event tracing chain is written to the blockchain to build a tracing pattern library.

[0008] A second aspect of this application provides a blockchain-based distributed network intrusion event tracing system, the system comprising:

[0009] The system comprises three modules: a fingerprint chain establishment module, a source tracing module, and a tracing pattern library. The fingerprint chain is used to collect intrusion event-related data on distributed nodes, extract event fingerprints from the data, and establish a multi-dimensional event fingerprint chain, including a traffic pattern fingerprint chain, an attack behavior sequence fingerprint chain, and an environmental context fingerprint chain. A source tracing fragment generation module is used to input the multi-dimensional event fingerprint chain into a tracing agent located on distributed nodes, generate source tracing fragments, and sign and upload them to the blockchain. An on-chain voting module is used to initiate a splicing proposal by any qualified synthesizer after the indexes of several source tracing fragments are written to the blockchain. Multiple participating nodes vote on the splicing proposal on-chain based on their local verification results and reputation weights. An attack path sketch establishment module is used to perform time-causal consistency analysis of the source tracing fragments of the corresponding participating nodes during the on-chain voting process for the splicing proposal, and establish a cross-node attack path sketch. A tracing pattern library construction module is used to construct a network intrusion event tracing chain after global verification of the cross-node attack path sketch through on-chain voting, write the network intrusion event tracing chain to the blockchain, and construct a tracing pattern library.

[0010] One or more technical solutions provided in this application have at least the following technical effects or advantages:

[0011] Intrusion event-related data is collected on the distributed node side. Event fingerprints are extracted from the intrusion event-related data to establish a multi-dimensional event fingerprint chain. The multi-dimensional event fingerprint chain is input into a tracing agent set on the distributed nodes. The tracing agent generates traceability fragments and signs them on the blockchain. After the indices of several traceability fragments are written to the blockchain, any qualified synthesizer initiates a splicing proposal. Multiple participating nodes vote on the splicing proposal on the blockchain based on their local verification results and reputation weights. A cross-node attack path sketch is established. After global verification of the cross-node attack path sketch through on-chain voting, a network intrusion event tracing chain is constructed, written to the blockchain, and a tracing pattern library is built. This achieves the technical effect of secure and accurate tracing of distributed network intrusion event tracing data, improving the accuracy and reliability of distributed network intrusion event tracing. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 A schematic diagram of the blockchain-based distributed network intrusion event tracing method provided in the embodiments of this application;

[0014] Figure 2 This is a schematic diagram of the structure of a blockchain-based distributed network intrusion event tracing system provided in an embodiment of this application.

[0015] Figure labeling: Fingerprint chain establishment module 10, traceability fragment generation module 20, on-chain voting module 30, attack path sketch establishment module 40, traceability pattern library construction module 50. Detailed Implementation

[0016] This application provides a blockchain-based distributed network intrusion event tracing method and system to address the technical problems in existing distributed network intrusion event tracing technologies, such as easy tampering of data and poor cross-node verification consistency, which lead to insufficient accuracy and reliability of tracing results.

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0018] Example 1, as Figure 1 As shown, this application provides a blockchain-based distributed network intrusion event tracing method, the method comprising:

[0019] Step S100: Collect intrusion event association data on the distributed node side, extract event fingerprints from the intrusion event association data, and establish a multi-dimensional event fingerprint chain, which includes a traffic pattern fingerprint chain, an attack behavior sequence fingerprint chain, and an environmental context fingerprint chain.

[0020] Specifically, on the distributed node side, network traffic data is captured in real time using traffic capture tools deployed on each node, such as customized collection modules based on tcpdump or Wireshark. This is combined with system log collection components, such as syslog and auditd, to obtain node runtime logs and process operation records. Simultaneously, environmental parameters such as node CPU utilization, memory usage, and network topology location are collected using environmental sensors or system monitoring interfaces. These combined data form a dataset associated with intrusion events. Next, a hash algorithm, such as SHA-256, is used to extract features from the collected traffic data, generating traffic feature values ​​that characterize packet size, transmission frequency, and protocol type, forming the basis of the traffic pattern fingerprint. Basic data; for attack behavior data, sequence pattern mining algorithms, such as the AprioriAll algorithm, are used to analyze the execution order of attack instructions and vulnerability exploitation paths, extracting attack behavior sequence identifiers with temporal characteristics to form attack behavior sequence fingerprint data; for environmental context data, environmental parameters are converted into standardized feature vectors through feature encoding technology to generate environmental context fingerprint data; finally, according to a preset data structure, such as a chained storage structure, traffic pattern fingerprint data, attack behavior sequence fingerprint data, and environmental context fingerprint data are organized into independent chain structures, and then integrated to form a multi-dimensional event fingerprint chain containing traffic pattern fingerprint chain, attack behavior sequence fingerprint chain, and environmental context fingerprint chain.

[0021] Step S200: Input the multidimensional event fingerprint chain into the traceability agent set in the distributed node, and use the traceability agent to generate traceability fragments and complete the signing and chaining.

[0022] Specifically, a multi-dimensional event fingerprint chain, including a traffic pattern fingerprint chain, an attack behavior sequence fingerprint chain, and an environmental context fingerprint chain, is constructed and fully input into the tracing agent pre-deployed on each distributed node. Upon receiving the multi-dimensional event fingerprint chain, the tracing agent extracts key feature information of the intrusion event from the chain, such as fragment identifier, author node identifier, time identifier, logical clock value, fingerprint digest, context index, and off-chain evidence reference, based on its built-in event parsing and fragment generation logic, generating a structured tracing fragment. Subsequently, the tracing agent uses an asymmetric encryption algorithm to digitally sign the generated tracing fragment, ensuring its authenticity, integrity, and immutability. After signing, the index information of the tracing fragment is written into the blockchain ledger, achieving on-chain evidence storage of the index. Simultaneously, the original content of the tracing fragment is encrypted using a symmetric encryption algorithm and stored in off-chain verifiable storage space, completing the on-chain signing operation of the tracing fragment while ensuring data security.

[0023] Step S300: After the indexes of several traceability fragments are written into the blockchain, any eligible synthesizer initiates a splicing proposal, and multiple participating nodes vote on the splicing proposal on-chain based on their local verification results and reputation weights.

[0024] Specifically, assuming several traceability fragment indexes are successfully written to the blockchain, qualified synthesizers are identified. These are typically distributed nodes that meet predefined node qualifications, such as a qualified reputation level and a good historical participation record. These synthesizers can initiate a splicing proposal to integrate the scattered traceability fragments based on the existing on-chain traceability fragment indexes. The proposal must include a list of the traceability fragment indexes to be spliced, a description of the splicing logic, and other core information. After the proposal is initiated, multiple qualified distributed nodes begin the processing flow: first, they perform local verification on the locally acquired traceability fragments to be spliced, such as verifying the validity of the fragment signature and its consistency with the on-chain index, generating their respective local verification results; simultaneously, they invoke the node's predefined reputation weight system to obtain the initial reputation weight of each participating node, which can be dynamically adjusted based on the verification results. Finally, participating nodes combine their local verification results and reputation weights to vote on the splicing proposal according to predefined on-chain voting rules, such as a weighted voting mechanism. The voting results are synchronized to the blockchain in real time, providing a decision-making basis for whether to approve the splicing proposal and advance the integration of traceability fragments.

[0025] Step S400: During the on-chain voting process of splicing proposals, perform time-causal consistency analysis of the source fragments of the corresponding participating nodes to establish a cross-node attack path sketch.

[0026] Specifically, based on the list of nodes participating in on-chain voting, the corresponding traceability segments to be analyzed for each node are precisely located, and these segments are identified as candidate traceability segments for time-causal consistency analysis. Next, signature verification is performed on each candidate traceability segment to verify the validity of the segment's digital signature, ensuring it has not been tampered with, and consistency verification with the on-chain index, checking whether the segment information matches the index stored in the blockchain to ensure the reliability of the data source. If any verification fails, the candidate traceability segment is removed. After successful verification, the three core scores of the candidate traceability segments are calculated, along with the time compatibility score, which evaluates the segment. The analysis includes: the rationality and relevance of timestamps; fingerprint similarity score, which compares the matching degree between fragment fingerprints and multidimensional event fingerprint chains; explicit causal reference matching score, which analyzes whether there is a clear causal reference relationship between fragments, and synthesizes the three scores into time-causal matching degree according to preset weights to complete the consistency analysis; then, a preset matching degree threshold is constructed, and candidate tracing fragments that meet the threshold requirements are selected. These fragments are used as directed weighted edges, and the weights of the edges are connected in the fragment graph according to the matching degree, finally forming a cross-node attack path sketch that can reflect the propagation path of the intrusion event.

[0027] Step S500: After performing global verification of the cross-node attack path sketch through on-chain voting, construct a network intrusion event tracing chain, write the network intrusion event tracing chain into the blockchain, and construct a tracing pattern library.

[0028] Specifically, a global verification of the established cross-node attack path sketch is conducted through on-chain voting. Firstly, a global event sparsity analysis is performed on all candidate events included in the sketch, statistically analyzing the distribution density of events in time and space to determine if any events are missing or redundant, thus establishing a first global consistency contribution. Secondly, the system resource usage of each node in the sketch during the intrusion event is examined, such as CPU usage, memory consumption, and network bandwidth usage, verifying the matching between resource status and event occurrence logic, thus establishing a second global consistency contribution. Subsequently, combining the on-chain voting results of multiple participating nodes, a global aggregation analysis is performed on the first and second global consistency contributions. If the aggregation result meets the preset global consistency standard, the global verification of the cross-node attack path sketch is completed. After successful verification, based on the time-causal relationship and connection logic of each tracing segment in the sketch, the scattered tracing segments are integrated into a complete and coherent network intrusion event tracing chain, clearly presenting the occurrence order, propagation path, and associated nodes of the intrusion event. Finally, the constructed network intrusion event tracing chain is completely written into the blockchain, utilizing the immutability of the blockchain to achieve secure evidence storage of the tracing chain. Finally, based on the multiple network intrusion event tracing chains already written into the blockchain, common characteristics and propagation patterns of different types of intrusion events are extracted, and a tracing pattern library is constructed according to preset classification rules and storage structure, providing a reference for the rapid identification and tracing of similar network intrusion events in the future.

[0029] In one possible implementation, step S300 further includes:

[0030] Step S310: Establish random sampling rules and use the random sampling rules to extract source fragments of peer nodes for cross-questioning verification.

[0031] Step S320: In the cross-questioning verification process, the questioning party of the peer node performs fragment logic consistency verification on the questioned party and extracts supporting features.

[0032] Step S330: After the party being challenged constructs a zero-knowledge proof, it uses the corroborating features and the zero-knowledge proof to identify the challenge and establish the challenge identification result.

[0033] Step S340: Complete cross-questioning verification based on the questioning identification results, and complete on-chain voting of the splicing proposal based on the cross-questioning verification.

[0034] Specifically, firstly, based on the unique identifiers of peer nodes participating in the on-chain voting for the splicing proposal, such as node IDs, a cryptographically secure random number generation mechanism is adopted. A random seed is derived from the real-time block hash value of the blockchain ledger, establishing random selection rules. These rules specify the selection ratio, ensuring coverage of a sufficient number of nodes to guarantee the objectivity of verification and the number of selection rounds. This avoids the randomness of a single selection and prevents repeated selections, thus preventing the same node's traceability fragment from being selected multiple times. The rules are also written into the blockchain smart contract for transparent execution. Next, the random selection algorithm encapsulated in the smart contract is invoked. From the existing traceability fragment index library on the blockchain, the traceability fragment index of the target peer node is matched and located according to the selection rules. Then, the index is used to retrieve the encrypted traceability fragment data from the off-chain verifiable storage space, corresponding to the encrypted storage location of the original traceability fragment content. Finally, the extracted traceability fragments are distributed to other peer nodes (not the original node) as challengers. Before fragment transmission, digital signature verification confirms that the fragments have not been tampered with, ensuring that subsequent cross-challenge verification is based on authentic and complete traceability fragment data.

[0035] During the cross-questioning verification process, the peer node acting as the questioner will conduct logical consistency verification on the traceability fragments provided by the questioned node, including fragment identifiers, author node identifiers, time identifiers, logical clock values, fingerprint digests, context indexes, and off-chain evidence references. The questioner first verifies the temporal continuity of the time identifiers and logical clock values ​​within the traceability fragment, ensuring that the order of events reflected by both is consistent. Next, it checks the matching of the fingerprint digest in the fragment with the established multi-dimensional event fingerprint chain, including traffic pattern fingerprint chains, attack behavior sequence fingerprint chains, and environmental context fingerprint chains, confirming that the fingerprint information has not been tampered with or deviated. Subsequently, it verifies the complete correspondence between the context index and the off-chain evidence references, ensuring that the index accurately points to the relevant evidence stored off-chain. While completing the above logical consistency verification, the questioner extracts key supporting information from the verification process, including temporally consistent combinations of time identifiers and logical clock values, successfully matched fingerprint segment information, and valid association records between the context index and off-chain evidence. This information is retained as corroborating features to provide data support for subsequent questioning identification.

[0036] The party under investigation constructs a zero-knowledge proof using Elliptic Curve Cryptography (ECC) based on core information such as fragment identifiers, time signatures, logical clock values, and fingerprint digests contained in its traceability fragment. By generating key pairs and signature parameters based on the discrete logarithm problem, the party proves the authenticity and integrity of the fragment information without revealing the original content of the traceability fragment, including sensitive data referenced by off-chain evidence. Subsequently, the party under investigation uploads the constructed zero-knowledge proof, along with the supporting features extracted by the challenger, such as the temporally coherent combination of time signatures and logical clock values, fingerprint segments matching the multi-dimensional event fingerprint chain, context indexes, and valid association records with off-chain evidence, to a pre-set challenge identification module on a distributed node. This module first verifies the correspondence between the supporting features and the key information of the traceability fragment through hash comparison to confirm that the features have not been tampered with; then, according to the zero-knowledge proof verification rules, it verifies the correctness of the elliptic curve signature to determine whether the proof meets the validity requirements. Finally, the challenge identification module uses a weighted fusion algorithm to combine the supporting feature matching score and the zero-knowledge proof verification result to generate challenge identification results of "challenge valid", "challenge invalid" or "requires further verification", and synchronizes the results to the blockchain to provide data support for the subsequent cross-challenge verification and on-chain voting of the splicing proposal.

[0037] Based on the challenge identification results – "challenge valid," "challenge invalid," or "requires further verification" – the final conclusion of the cross-challenge verification is determined: If the challenge identification result is "challenge invalid," the traceability fragment of the challenged party is deemed authentic and valid, and included in the reference scope of subsequent splicing proposals; if the result is "challenge valid," the traceability fragment is marked as having logical contradictions or data tampering issues, and removed from the set of valid fragments; if the result is "requires further verification," a secondary verification process is initiated, requiring the challenged party to supplement relevant supporting materials until a clear conclusion of validity or invalidity is reached, thus completing the cross-challenge verification. After completing the cross-challenge verification, the on-chain voting of the splicing proposal is advanced based on the verification conclusion: first, the initial reputation weight of each participating node is obtained; then, based on the challenge identification results, a dynamic correction factor for the reputation weight, dynamically constructed through challenge game theory, is configured. For example, if a participating node's fragment verification is valid when it is the challenged party, or if it raises a reasonable challenge when it is the challenger, its correction factor is positive; otherwise, it is negative. This correction factor is used to correct the initial reputation weight, resulting in the final reputation weight of each node. Simultaneously, the previous local verification results of participating nodes are compensated based on the cross-verification results, such as removing local verification opinions corresponding to invalid traceability fragments and supplementing verification conclusions of valid fragments. Finally, based on the corrected reputation weight, a weighted vote is performed on the compensated local verification results, and the vote support rate is calculated. If the support rate reaches a preset threshold (e.g., exceeding 50%), the splicing proposal is approved; otherwise, it is rejected, thus completing the on-chain voting of the splicing proposal.

[0038] In one possible implementation, step S340 further includes:

[0039] Step S341: Obtain the initial reputation weight of each participating node.

[0040] Step S342: Configure a reputation weight dynamic correction factor based on the questioning identification result. The reputation weight dynamic correction factor is dynamically constructed through questioning game.

[0041] Step S343: After correcting the initial reputation weight using the reputation weight dynamic correction factor, establish the reputation weight.

[0042] Step S344: After compensating the local verification results based on cross-questioning verification, use reputation weights to perform weighted voting on the corresponding local verification results after compensation, and complete the on-chain voting of the splicing proposal.

[0043] Specifically, relying on the pre-defined node reputation management mechanism in the distributed network, the initial reputation weights of each node participating in the on-chain voting of this splicing proposal are retrieved from the node reputation files stored on the blockchain. These initial reputation weights are derived from a comprehensive evaluation of the node's performance in tracing network intrusion events in its history. This evaluation specifically covers the accuracy of the node's past participation in verifying traceability fragments, such as the matching degree between local verification results and the final global verification conclusion, the timeliness of responding to cross-judgment verification, and whether there are any historical records of providing false fragments or malicious voting. All evaluation criteria must be synchronized to the blockchain to ensure immutability. By extracting the initial values ​​from the node reputation files after quantification and calculation based on the above dimensions, the initial reputation weight of each participating node is determined. This provides benchmark data for subsequent dynamic weight correction based on the results of challenge identification, ensuring the credibility and fairness of subsequent weighted voting.

[0044] Clearly define the dual roles of participating nodes in cross-questioning verification: questing party or questioned party, and associate them with the corresponding quest identification results. If a node, as the questioned party, has its source fragment determined to be "question invalid" (meaning the fragment is authentic and valid), or if its quest as the questing party is determined to be "question valid" (meaning the quest is reasonable and accurate), then the node is considered to have performed positively in the questioning game, and a positive dynamic correction factor is configured accordingly, such as a value in the range of 0.05-0.2, with fine-tuning based on the verification contribution. If a node, as the questioned party, has its source fragment determined to be "question valid" (meaning the fragment has a problem), or if its quest as the questing party is determined to be "question invalid" (meaning the quest is invalid or malicious), then the node is considered to have performed negatively in the questioning game, and a negative dynamic correction factor is configured accordingly, such as a value in the range of -0.2 to -0.05. If the result is "requires supplementary verification," a neutral correction factor (such as 0) is temporarily configured, and the correction direction and value are updated after a clear conclusion is reached through secondary verification. The entire process of constructing the correction factor relies on the questioning interaction data recorded by the blockchain to ensure the transparency and traceability of the game judgment. Ultimately, it forms a dynamic correction factor of reputation weight that is strongly bound to the actual verification performance of the node, providing a basis for the accurate correction of the initial reputation weight in the future.

[0045] The dynamic correction factor is correlated with the initial reputation weight in a calculation process that complies with the blockchain traceability system's requirements for weight accuracy and rationality, avoiding excessive weight deviation caused by a single factor. Specifically, if the dynamic correction factor corresponding to a node is positive (e.g., the node's fragment verification is valid when it is the object of the challenge, and the challenge is reasonable when it is the challenger), the initial reputation weight is calculated as (1 + positive correction factor value). If the dynamic correction factor is negative (e.g., the fragment verification is invalid when the node is the object of the challenge, and the challenge is invalid when it is the challenger), the initial reputation weight is calculated as (1 - absolute value of the negative correction factor). If it is a neutral correction factor, such as a provisional value of 0 in the "requires supplementary verification" scenario, the initial reputation weight remains unchanged. After the correction calculation is completed, the results must be verified for compliance to ensure that the final reputation weight is within the system's preset valid range (e.g., 0-1), avoiding abnormal situations such as negative weights or weights exceeding 1. After verification, the final reputation weight of each participating node will be synchronized to the node reputation management module of the blockchain for storage, serving as the basis for subsequent weighted voting and ensuring the fairness and reliability of on-chain voting for the splicing proposal.

[0046] Based on the conclusions of previous cross-verification, namely the determination of whether the traceability fragment is "valid," "invalid," or "requires supplementary verification," the local verification results of each participating node are compensated and corrected: if the traceability fragment on which the participating node's previous local verification result is based is determined to be "invalid" after cross-verification, the local verification opinion corresponding to the invalid fragment is removed to avoid erroneous data affecting the accuracy of voting; if there is a traceability fragment that is confirmed to be valid after secondary supplementary verification, the verification conclusion corresponding to the fragment is added to the local verification result to ensure that the local verification result can truly reflect the actual validity of the traceability fragment. After compensating for the local verification results, the final reputation weights of each participating node are retrieved, and a weighted vote is performed on the compensated local verification results. Each participating node, based on the compensated local verification results, either supports or opposes the splicing proposal, generating a voting score based on its own final reputation weight. For example, a node supporting the proposal has a voting score of "final reputation weight × 1," while a node opposing the proposal has a voting score of "final reputation weight × (-1)." The total voting scores of all participating nodes are then calculated and compared with a system-preset passing threshold, such as 50% of the sum of the total reputation weights of the participating nodes. If the total voting score reaches or exceeds the passing threshold, the splicing proposal is deemed passed; otherwise, it is deemed rejected. This completes the on-chain voting for the splicing proposal. Throughout the entire voting process, node opinions, reputation weights, score calculations, and the final results are synchronized to the blockchain storage, ensuring that the voting process is traceable and the results are tamper-proof.

[0047] In one possible implementation, step S400 further includes:

[0048] Step S410: Locate candidate traceability segments based on participating nodes.

[0049] Step S420: Perform signature verification and on-chain index consistency verification on the candidate traceability fragment.

[0050] Step S430: If the verification passes, calculate the time compatibility score, fingerprint similarity score, and explicit causal reference matching score of the candidate source fragment.

[0051] Step S440: Synthesize the time-causal matching degree based on the time compatibility score, fingerprint similarity score and explicit causal reference matching score to complete the time-causal consistency analysis.

[0052] Specifically, the process involves extracting a list of all nodes participating in the on-chain voting for this splicing proposal from the blockchain's voting participant records, identifying the unique identifier of each participating node, such as the author node identifier; then, calling the query interface of the traceability fragment index library stored in the blockchain, using the author node identifier of the participating node as the search condition, to filter out traceability fragments in the index information whose "author node identifier" matches the participating node identifier. These fragments are all traceability fragments generated by the participating nodes through traceability agents and whose indexes have been written into the blockchain, meeting the process requirement in the document that "traceability fragments are signed and stored in the blockchain after being indexed"; finally, these filtered traceability fragments are determined as candidate traceability fragments, ensuring that the objects of subsequent time-causal consistency analysis all come from the participating nodes in this vote, limiting the effective scope for subsequent verification and analysis, and ensuring the correlation between the analysis results and the splicing proposal.

[0053] The candidate traceability segments are subjected to dual operations: signature verification and on-chain index consistency verification. First, signature verification is performed: the digital signature verification algorithm preset by the distributed nodes is called to extract the digital signature attached to the candidate traceability segment, which is signed by the traceability agent that generated the segment. Combined with the public key of the corresponding generating node, the signature is decrypted and verified from the blockchain node identity management module. If the decrypted data is consistent with the core information of the segment, such as the segment identifier and fingerprint digest, the signature verification is deemed to have passed, confirming that the segment has not been tampered with. If the decryption result does not match, the candidate segment is directly removed. After signature verification is completed, on-chain index consistency verification is performed on the candidate traceability fragments that have passed signature verification: from the traceability fragment index library of the blockchain ledger, the corresponding on-chain index record is retrieved according to the fragment identifier of the candidate fragment, which includes key information such as fragment identifier, author node identifier, time identifier, and fingerprint digest. The on-chain index record is compared with the actual content of the candidate fragment item by item, with a focus on checking whether the fingerprint digest is completely consistent and whether the time identifier matches the author node identifier. If all comparison items are indistinguishable, the on-chain index consistency verification is determined to be passed; if any information is mismatched, the candidate fragment is also removed, and only candidate traceability fragments that have passed both verifications are retained.

[0054] After both signature verification and on-chain index consistency verification pass, time compatibility score, fingerprint similarity score, and explicit causal reference matching score are calculated for the candidate traceability segments that pass the verification. When calculating the time compatibility score, based on the time identifier and logical clock value contained in the candidate traceability segment, and in accordance with the composition definition of traceability segments in the file, the time logic relationship between segments is compared through a time sequence analysis algorithm. If the time identifier of the later candidate segment is later than that of the previous associated segment and the logical clock value is greater than that of the previous associated segment, the time sequence is determined to be continuous. According to the preset scoring rules, if continuous, a score of 0.8-1.0 is assigned; if there is a slight deviation, a score of 0.5-0.7 is assigned; and if the deviation is too large, a score of 0-0.4 is assigned, and the corresponding time compatibility score is assigned. When calculating the fingerprint similarity score, the fingerprint digest of the candidate traceability fragment is extracted and hashed against the established multidimensional event fingerprint chain, which includes traffic pattern fingerprint chain, attack behavior sequence fingerprint chain, and environmental context fingerprint chain. The matching degree is quantified by the cosine similarity algorithm. If the matching degree between the fingerprint digest and the corresponding sub-chain in the multidimensional event fingerprint chain reaches 90% or more, a score of 0.9-1.0 is assigned; if the matching degree is between 70% and 90%, a score of 0.7-0.8 is assigned; if the matching degree is less than 70%, a score of 0-0.6 is assigned according to the actual matching ratio, thus obtaining the fingerprint similarity score. When calculating the explicit causal reference matching score, the correspondence between the context index of the candidate source fragment and the off-chain evidence reference, as well as the rationality of the causal reference between fragments, are checked. If the context index can accurately point to the off-chain related evidence, and the causal reference logic between fragments is closed, such as the attack result of fragment A and the attack cause of fragment B, a score of 0.8-1.0 is assigned; if only a partial match is possible or there is a slight gap in the causal logic, a score of 0.4-0.7 is assigned; if no match is possible or the causal logic is completely broken, a score of 0-0.3 is assigned, and the explicit causal reference matching score is finally obtained.

[0055] Using the calculated time compatibility score, fingerprint similarity score, and explicit causal reference matching score as basic data, and combining the core requirements of time-causal consistency analysis in the document, a weighted synthesis algorithm is used to synthesize the time-causal matching degree to complete the analysis. First, based on the importance of the three scores in tracing the causal relationship of network intrusion events, reasonable weights are assigned to them. For example, considering the core identifying role of fingerprint information in event correlation, the fingerprint similarity score weight can be set to 0.4; time logic is the foundation of causal relationships, so the time compatibility score weight is set to 0.3; explicit causal references directly reflect the causal relationship between segments, so the weight is also set to 0.3. Specific weights can be preset according to the system's emphasis on different dimensions. Then, the time-causal matching degree is calculated according to the formula: "Time-causal matching degree = Time compatibility score × corresponding weight + Fingerprint similarity score × corresponding weight + Explicit causal reference matching score × corresponding weight," obtaining the specific value of the time-causal matching degree for each candidate tracing segment. The value is usually in the range of 0-1. This matching score allows for a direct assessment of the overall consistency of candidate source tracing segments in terms of temporal logical coherence, fingerprint information relevance, and the reasonableness of causal citations. The closer the matching score is to 1, the stronger the consistency of the segment in terms of time and causality, and the more it conforms to the actual development of the network intrusion event; conversely, the weaker the consistency, the lower the score. This completes the time-causal consistency analysis of candidate source tracing segments.

[0056] In one possible implementation, step S440 further includes:

[0057] Step S441: Construct a preset matching threshold.

[0058] Step S442: After filtering the time-causal matching degree using a preset matching degree threshold, candidate tracing fragments that meet the preset matching degree threshold are connected as directed weighted edges in the fragment graph to establish a cross-node attack path sketch.

[0059] Specifically, a preset matching threshold is constructed, and its setting should refer to two core criteria: First, the historical distribution data of the time-causal matching degree of candidate tracing segments that have been globally verified and confirmed as valid during the tracing of past distributed network intrusion events, ensuring that the threshold can cover most truly valid segments; Second, the system's requirements for the accuracy of intrusion event tracing. If priority is given to ensuring path accuracy, the threshold should be appropriately increased; if priority is given to ensuring path integrity, the threshold can be appropriately decreased. In the context of the document, the threshold is usually set in the range of 0.6-0.7, which balances the two. The specific value can be dynamically adjusted according to the actual tracing scenario. At the same time, to ensure the transparency and immutability of the threshold application, the constructed preset matching threshold should be synchronously stored in the blockchain smart contract as a unified standard for screening candidate tracing segments, avoiding deviations in the attack path sketch due to inconsistent screening criteria.

[0060] The preset matching threshold, constructed and stored in the blockchain smart contract, is retrieved and used as a screening criterion to compare the time-causal matching degree of each synthesized candidate traceability segment one by one. If the time-causal matching degree of a candidate traceability segment is greater than or equal to the preset threshold, the segment is determined to meet the requirements for constructing a cross-node attack path in terms of temporal logical coherence, fingerprint information correlation, and causal reference rationality, and is retained as a valid candidate segment. If the matching degree is lower than the preset threshold, the segment is deemed to have insufficient correlation with the core context of the intrusion event and is eliminated. After screening, based on the retained valid candidate traceability fragments, directed weighted edges are constructed in a pre-defined fragment graph. The "directed" attribute is determined by the time identifier and logical clock value of the valid fragments, using earlier fragments with smaller logical clock values ​​as starting points and pointing to later fragments with larger logical clock values ​​and causal relationships. For example, the attack result of fragment A matches the cause of the attack in fragment B, thus reflecting the development sequence and causal flow of the intrusion event. The "weighted" attribute directly uses the time-causal matching degree of the valid fragments as the edge weight value; the higher the matching degree, the greater the weight, intuitively reflecting the credibility of the association between fragments. By sequentially connecting all valid fragments that meet the threshold in this form of directed weighted edges in the fragment graph, a cross-node attack path sketch is finally formed, clearly showing the propagation path, temporal relationship, and association credibility of the intrusion event across different distributed nodes. This provides a visual path analysis carrier for subsequent on-chain voting global verification of the sketch.

[0061] In one possible implementation, step S500 further includes:

[0062] Step S510: Perform global event sparsity analysis on all candidate events in the cross-node attack path sketch to establish the first global consistency contribution.

[0063] Step S520: Verify the system resources of each node in the cross-node attack path sketch at the time of the event, and establish a second global consistency contribution.

[0064] Step S530: Use the on-chain voting to perform global aggregation analysis of the first global consensus contribution and the second global consensus contribution to complete global verification.

[0065] Specifically, from the traceability fragment index and event records stored in the blockchain, the time identifier, associated node information and event type of all candidate events are extracted, such as port scanning, data tampering, and permission theft, to construct a global distribution matrix of candidate events. The matrix dimensions cover "time interval-node-event type", which intuitively presents the spatiotemporal distribution characteristics of events in the distributed network. Next, sparsity analysis is conducted based on this matrix: In the time dimension, time intervals are divided according to the typical cycle of intrusion event propagation, such as the initial detection period, penetration attack period, lateral movement period, and data theft period. The number and density of candidate events in each interval are statistically analyzed to determine if there is a sudden drop in the number of events in a critical time interval. For example, if there are event records in the initial detection period but no corresponding events in the penetration attack period, a time sparsity problem is identified. In the node dimension, combined with the distributed network topology, key nodes that the intrusion propagation may pass through are identified, such as gateway nodes and core server nodes. The presence of missing candidate events at these nodes is checked. If no event records are found at key nodes, a node sparsity problem is identified. In the event type dimension, the typical behavioral sequences of similar intrusion events are compared, such as "port scanning → vulnerability exploitation → privilege acquisition → lateral movement," to check if the candidate event types cover the complete sequence. If key behavioral types are missing, an event type sparsity problem is identified. Finally, the first global consistency contribution is quantitatively calculated based on the sparsity analysis results: The ideal state with no sparsity gaps is scored as 1. For sparsity issues in the three dimensions of time, nodes, and event types, deduction values ​​are assigned according to the severity of the gaps, such as 0.1 for minor gaps, 0.3 for moderate gaps, and 0.5 for severe gaps. The specific value of the first global consistency contribution is calculated by "1 - the sum of the deduction values ​​for each dimension". The closer this value is to 1, the more complete the candidate events in the cross-node attack path sketch are in terms of spatiotemporal distribution and behavioral sequence, and the stronger the global consistency. The lower the value, the more significant the sparsity problem, requiring further verification to improve the event set and provide core evidence for the event coverage level of the global verification of the cross-node attack path sketch.

[0066] From the blockchain's node resource archives, based on each node's unique identifier (such as the author node identifier and the candidate event's timestamp), the original system resource records of the node at the precise time point or time interval of the event are retrieved. These records must include key resource dimensions such as CPU utilization, memory usage, network inflow / outflow traffic, port access logs, and process running status, and must be verified by the blockchain's hash function to ensure that the resource records have not been tampered with. Next, based on the intrusion behavior characteristics described in the candidate event, resource verification rules are formulated: for example, if a node's candidate event is a DDoS attack, the verification rules must clearly define the typical resource characteristics corresponding to this behavior, such as a sudden increase in network traffic within a short period and a sustained high CPU load; if the event is an "exploitation attempt," it is necessary to check for abnormal process creation, high-frequency access requests to specific ports, and other resource anomalies. According to the verification rules, the retrieved system resource data is matched item by item with the event characteristics, and the number of matching and non-matching items for each node is counted. If the resource data contains an anomaly corresponding to the event characteristics, it is counted as one valid match; if no corresponding anomaly is found or the resource data contradicts the event characteristics, it is counted as one non-match. Subsequently, the resource matching rate of a single node is calculated as the number of valid matching items per node divided by the total number of verification items. A resource matching rate threshold is set, such as 0.7: if a node's resource matching rate reaches or exceeds the threshold, the node is considered to have passed the system resource verification and is counted as one valid contributing node; if it is below the threshold, it is considered to have failed the verification and is not counted as a valid contribution. Finally, the proportion of valid contributing nodes among all participating nodes is calculated, and this proportion is determined as the second global consistency contribution. The closer the proportion is to 1, the higher the degree of fit between the system resource status of each node in the cross-node attack path sketch and the characteristics of the corresponding intrusion event. The stronger the global consistency of the path sketch at the resource behavior level, the more crucial the consistency basis for the node resource dimension of subsequent global aggregation analysis.

[0067] The process involves retrieving the list of participating nodes from the previous proposal chain voting and their final reputation weights after dynamic correction. This ensures that the scope of nodes participating in the global aggregation analysis is consistent with the voting nodes, and that the weights reflect the current credibility of the nodes. Next, the established first and second global consistency contributions are synchronized to all participating nodes. Each node independently votes for or against the two contributions based on its own assessment of their reasonableness. If a node believes both contributions meet the global consistency requirements, it votes in favor; if it believes either contribution has a significant bias—for example, a low score for the first contribution indicating serious event deficiencies, or a low score for the second contribution indicating poor resource matching—it votes against. Subsequently, a weighted voting algorithm is used to aggregate node opinions: each node's vote is counted as 1 for support and 0 for opposition, multiplied by its final reputation weight to obtain the node's weighted voting score. The weighted voting scores of all participating nodes are then summed, and the ratio of the total score to the sum of the total reputation weights of the participating nodes is calculated; this is the weighted support rate. Simultaneously, a preset global verification threshold is retrieved from the blockchain smart contract. This threshold needs to be set in conjunction with the traceability system's requirements for the accuracy of the path sketch, typically between 0.6 and 0.7. The weighted support rate is compared with the threshold: if the weighted support rate reaches or exceeds the threshold, the first and second global consistency contributions are deemed to have passed the global aggregation analysis, and the cross-node attack path sketch meets the global verification requirements; if the threshold is not reached, the global verification is deemed to have failed, and the process must return to the time-causal consistency analysis stage to re-screen candidate traceability fragments or supplement node system resource verification data until the weighted support rate reaches the standard after the global aggregation analysis is performed again, thus completing the global verification of the cross-node attack path sketch and providing a compliance basis for the subsequent construction of a network intrusion event traceability chain.

[0068] In one possible implementation, step S500 further includes:

[0069] Step S540: After re-collecting the multidimensional event chain, compare the re-collected multidimensional event chain with the attack patterns in the traceability pattern library to establish a similarity comparison result.

[0070] Step S550: If the similarity comparison result meets the first preset threshold range, an attack threat warning is generated.

[0071] Step S560: If the similarity comparison result meets the second preset threshold range, an attack notification is generated.

[0072] Specifically, relying on the intrusion event data collection component of distributed nodes, and following the same standard as the initially established multi-dimensional event fingerprint chain—that is, collecting intrusion event-related data and extracting three types of fingerprints: traffic patterns, attack behavior sequences, and environmental context—the system re-collects event-related data that may pose intrusion risks in the current network environment. After event fingerprint extraction, a new multi-dimensional event chain is generated, ensuring that the re-collected multi-dimensional event chain is consistent with the feature carriers of attack patterns in the tracing pattern library in terms of structure and dimensions. Subsequently, the system retrieves the constructed tracing pattern library from the blockchain. This library stores attack patterns extracted from historically globally verified network intrusion event tracing chains. Each attack pattern contains corresponding multi-dimensional event fingerprint chain features, such as specific traffic anomaly patterns, attack behavior step sequences, and environmental parameter combinations. A sequence matching algorithm combining hash-based fingerprint comparison and cosine similarity is employed to compare the newly collected multidimensional event chains with each attack pattern in the tracing pattern library dimension by dimension: In the traffic pattern dimension, the matching degree of features such as packet size, transmission frequency, and source-destination IP distribution is compared; in the attack behavior sequence dimension, the consistency of attack steps and behavior types, such as port scanning, vulnerability exploitation, and data theft, is compared; in the environmental context dimension, the fit of parameters such as node topology, system version, and network protocol at the time of the event is compared. Finally, based on the comparison results of each dimension, a weighted sum is calculated. The weight of each dimension can be preset according to its importance to attack pattern identification, such as setting the weight of the attack behavior sequence dimension to 0.4, and the traffic pattern and environmental context dimensions to 0.3 each. The overall similarity value between the newly collected multidimensional event chains and each attack pattern is calculated. All similarity values ​​and corresponding attack pattern identifiers are organized into structured data to establish the similarity comparison results, providing a core basis for subsequent threat alert generation based on threshold ranges.

[0073] The system retrieves a first preset threshold range from its preset threshold configuration module. This range is typically set to a high similarity range, such as 0.8-1.0. The specific values ​​are predefined based on the typical characteristics of attack patterns in the traceability pattern library and network security protection requirements, and are stored in a blockchain smart contract to ensure immutability. Subsequently, the established similarity comparison results—that is, the overall similarity values ​​between the newly collected multi-dimensional event chain and each attack pattern in the traceability pattern library—are matched one by one with the first preset threshold range. Attack pattern association records whose similarity values ​​fall within this range are selected. If at least one attack pattern association record has a similarity value that meets the first preset threshold range, it indicates that the currently re-collected multi-dimensional event chain highly matches a verified attack pattern in the traceability pattern library, and the network is highly likely to be under attack of this type. An attack threat alert must be generated immediately. The alert must include key information: First, the type of attack pattern being matched, such as DDoS attack, SQL injection attack, port scanning attack, etc., to help operations and maintenance personnel quickly identify the nature of the attack; second, the specific similarity value and details of the matching dimensions, such as a traffic pattern dimension matching degree of 0.92 and an attack behavior sequence dimension matching degree of 0.88, to provide data support for threat assessment; third, the risk level, set as "high risk" based on the first preset threshold range, and suggested countermeasures, such as activating traffic blocking rules, isolating suspected attacked nodes, and enabling deep intrusion detection. After generating the attack threat alert, the alert information must be synchronized to two places to ensure timeliness and traceability: First, it must be pushed to the distributed network operations and maintenance management platform to trigger real-time early warning notifications, facilitating timely response from operations and maintenance personnel; second, the alert information, along with the corresponding similarity comparison results, matched attack pattern characteristics, and other data, must be written into the blockchain ledger in encrypted form to form an immutable threat event record, providing a basis for subsequent attack tracing and review and protection strategy optimization, ultimately completing the generation and implementation of the attack threat alert.

[0074] The system retrieves a pre-configured second preset threshold range from the blockchain smart contract. This range is typically set to a low to medium similarity range, such as 0.5-0.79, lower than the first preset threshold range. The specific value is determined based on the characteristic differences of attack patterns in the traceability pattern library and the network early warning sensitivity requirements, and it does not overlap with the first range. Subsequently, the established similarity comparison results are used to match the overall similarity value of the newly collected multidimensional event chain with each attack pattern in the traceability pattern library against the second preset threshold range, filtering out attack pattern association records whose similarity values ​​fall within this range. If such association records exist, it indicates that the currently re-collected multidimensional event chain has partial feature matching with a known attack pattern, but not a complete match. The network may be in the initial stage of an attack, such as the attacker conducting probing operations or there is a potential risk of being attacked. An attack alert needs to be generated to trigger early protection. The alert must include core information: First, the type of suspected attack pattern matched, such as suspected port scanning or suspected vulnerability detection, to help operations personnel pinpoint potential threats; second, the specific similarity score and details of matching / non-matching dimensions, such as a matching score of 0.65 in the environmental context dimension and 0.48 in the attack behavior sequence dimension, clarifying the correlation of the current threat; third, the risk level, set as "medium risk" based on a second preset threshold range, and suggested actions, such as strengthening real-time monitoring of key nodes, recording current abnormal network behavior, and updating intrusion detection rules to cover suspected features. After generating the attack alert, it needs to be synchronized to the distributed network operations and maintenance early warning platform to remind operations personnel to pay attention and intervene in the investigation; at the same time, the alert information, corresponding similarity comparison data, and suspected attack pattern characteristics are encrypted and written into the blockchain to form a traceable risk event record, which not only provides a basis for subsequent threat development trend analysis but also ensures the auditability of the early warning process, ultimately completing the generation and application of the attack alert.

[0075] In one possible implementation, step S200 further includes:

[0076] Step S210: Use the traceability agent to digitally sign the traceability fragment and write the index information of the traceability fragment into the blockchain ledger.

[0077] Step S220: After encrypting the original content of the traceability fragment, store it in the off-chain verifiable storage space.

[0078] Specifically, relying on traceability agents deployed on distributed nodes, the digital signature and indexing of traceability fragments are completed in two steps. First, the traceability agent retrieves the private key of the node that generated the traceability fragment. This private key is stored in pairs with the node's public key for authentication and data signing. The agent performs a hash operation on the core information of the traceability fragment, including the fragment identifier, author node identifier, time stamp, logical clock value, and fingerprint digest, conforming to the definition of a traceability fragment in the file. A fixed-length hash value is generated, which is then encrypted using the node's private key to form a unique digital signature. This signature can be decrypted and verified using the node's public key, ensuring the authenticity of the traceability fragment's origin and the lack of tampering. Next, the traceability agent extracts key index information from the traceability fragment, retaining only the hash values ​​of the fragment identifier, author node identifier, digital signature digest, time stamp, and fingerprint digest, and organizes them into index data according to the blockchain ledger's writing format specifications. Next, following blockchain consensus mechanisms such as PoS and PBFT, the consistency and security of data writing are ensured. The organized index data is submitted to the blockchain network, and after verification by node consensus, it is written into the blockchain ledger and a corresponding on-chain index address is generated. Through this process, the traceability and tamper-proof nature of the traceability fragments are achieved, while avoiding excessive blockchain storage load by only uploading index information. This provides an efficient on-chain query basis for subsequent location, verification, and voting of traceability fragments.

[0079] For the traceability fragments that have completed digital signatures, their complete original content is extracted, including fragment identifiers, author node identifiers, timestamps, logical clock values, fingerprint digests, context indexes, off-chain evidence references, and corresponding detailed evidence data, conforming to the complete structure of the traceability fragments in the file. Subsequently, a pre-defined hybrid encryption scheme is used to encrypt the original content: first, a symmetric encryption algorithm, such as AES-256, is used to encrypt the original content, generating an encrypted original content file. This symmetric encryption key will serve as the key for subsequent decryption. Then, an asymmetric encryption algorithm, such as RSA, is used to encrypt the symmetric key, preventing leakage of the symmetric key during transmission or storage, ensuring that only authorized nodes can decrypt and obtain the symmetric key using the corresponding private key. After encryption, the encrypted original content file is stored in an off-chain verifiable storage space. This storage space has distributed and verifiable characteristics, such as a distributed file system based on IPFS, or an encrypted storage cluster shared among nodes. During storage, the unique storage address of the file must be recorded, such as the IPFS hash value and the associated decryption key index. The key index is bound to the identity information of the generating node, and only authorized participating nodes can obtain it through blockchain queries. Meanwhile, to ensure the verifiability of the stored content, the hash value of the encrypted original content file and its corresponding storage address must be synchronously written into the blockchain ledger. If the original content needs to be retrieved later, the hash value on the chain can be compared with the hash value of the off-chain stored file to verify whether the file has been tampered with. This ultimately achieves secure storage and verifiable access to the original content of the traceability fragment, which reduces the storage pressure on the blockchain and ensures the security and integrity of the original data.

[0080] In one possible implementation, step S200 further includes:

[0081] Step S230: The traceability fragment includes fragment identifier, author node identifier, time identifier, logical clock value, fingerprint digest, context index, and off-chain evidence reference.

[0082] Specifically, the defined traceability fragments contain seven types of information, each with a clear function and role: Fragment identifiers assign a unique digital code to the traceability fragment, which can be used to quickly locate a specific fragment in the blockchain and off-chain storage system, avoiding confusion with other fragments; author node identifiers record the identity information of the distributed nodes that generated the fragment, facilitating the tracing of the fragment's origin and clarifying the data contribution of each node in the intrusion event tracing; time identifiers precisely record the timestamp of the fragment's generation, providing a temporal basis for subsequent time-causal consistency analysis and ensuring the restoration of the order of events; logical clock values ​​are used to solve the clock synchronization problem between distributed nodes, assisting in determining the logical sequence of events corresponding to the fragment in the global context through logical temporal relationships; and fingerprint digests are generated by the intrusion event... The multidimensional event fingerprints extracted from the linked data are generated through hash operations and are the key basis for verifying the integrity of the fragment content and comparing fingerprint similarity with other fragments. The context index associates the environmental information of the intrusion event corresponding to the fragment, such as node topology and network protocol version, to support the analysis of the environmental background of the event. The off-chain evidence reference records the addresses of the original evidence related to the fragment, such as complete data packet logs and system operation records, in the off-chain verifiable storage space. This avoids the original evidence occupying too much blockchain storage resources and allows for quick retrieval of the original data for further verification. The seven types of information together constitute a structurally complete and functionally clear traceability fragment, providing basic data support for subsequent splicing proposals, cross-questioning verification, and attack path construction.

[0083] Example 2, based on the same inventive concept as the blockchain-based distributed network intrusion event tracing method in the foregoing examples, such as... Figure 2 As shown, this application provides a blockchain-based distributed network intrusion event tracing system. The system and method embodiments in this application are based on the same inventive concept. The system includes:

[0084] The fingerprint chain establishment module 10 is used to collect intrusion event association data on the distributed node side, extract event fingerprints from the intrusion event association data, and establish a multi-dimensional event fingerprint chain. The multi-dimensional event fingerprint chain includes a traffic pattern fingerprint chain, an attack behavior sequence fingerprint chain, and an environmental context fingerprint chain.

[0085] The traceability fragment generation module 20 is used to input the multi-dimensional event fingerprint chain into the traceability agent set in the distributed node, and use the traceability agent to generate traceability fragments and complete the signing and chaining.

[0086] The on-chain voting module 30 is used to initiate a splicing proposal by any qualified synthesizer after the index of several traceability fragments is written into the blockchain, and multiple participating nodes vote on the splicing proposal on-chain based on their local verification results and reputation weight.

[0087] The attack path sketching module 40 is used to perform time-causal consistency analysis of the source fragments of the corresponding participating nodes during the on-chain voting process of splicing proposals, and to establish cross-node attack path sketches.

[0088] The traceability pattern library construction module 50 is used to perform on-chain voting for global verification of the cross-node attack path sketch, construct a network intrusion event traceability chain, write the network intrusion event traceability chain into the blockchain, and construct a traceability pattern library.

[0089] Furthermore, the system is also used to implement the following functions:

[0090] A random sampling rule is established, and the source fragments of peer nodes are extracted using the random sampling rule for cross-questioning verification. During the cross-questioning verification process, the questioner of the peer node performs fragment logic consistency verification on the questioned party and extracts supporting features. After the questioned party constructs a zero-knowledge proof, it uses the supporting features and the zero-knowledge proof to perform question identification and establish a question identification result. Cross-questioning verification is completed based on the question identification result, and on-chain voting of the splicing proposal is completed based on the cross-questioning verification.

[0091] Furthermore, the system is also used to implement the following functions:

[0092] Obtain the initial reputation weight of each participating node; configure a dynamic correction factor for the reputation weight based on the challenge identification result, which is dynamically constructed through challenge game; after correcting the initial reputation weight using the dynamic correction factor, establish the reputation weight; after compensating the local verification result based on cross-challenge verification, use the reputation weight to perform weighted voting on the corresponding local verification result after compensation, and complete the on-chain voting of the splicing proposal.

[0093] Furthermore, the system is also used to implement the following functions:

[0094] Candidate traceability segments are located based on participating nodes; signature verification and on-chain index consistency verification are performed on the candidate traceability segments; if the verification passes, the time compatibility score, fingerprint similarity score, and explicit causal reference matching score of the candidate traceability segments are calculated; the time-causal matching degree is synthesized based on the time compatibility score, fingerprint similarity score, and explicit causal reference matching score to complete the time-causal consistency analysis.

[0095] Furthermore, the system is also used to implement the following functions:

[0096] Construct a preset matching degree threshold; after filtering the time-causal matching degree using the preset matching degree threshold, connect the candidate tracing fragments that meet the preset matching degree threshold as directed weighted edges in the fragment graph to establish a cross-node attack path sketch.

[0097] Furthermore, the system is also used to implement the following functions:

[0098] A global event sparsity analysis is performed on all candidate events in the cross-node attack path sketch to establish a first global consistency contribution; a second global consistency contribution is established by verifying the system resources of each node in the cross-node attack path sketch when the event occurs; and a global aggregation analysis of the first and second global consistency contributions is performed using the on-chain voting to complete global verification.

[0099] Furthermore, the system is also used to implement the following functions:

[0100] After re-collecting the multidimensional event chain, the re-collected multidimensional event chain is compared with the attack patterns in the traceability pattern library to establish a similarity comparison result; if the similarity comparison result meets the first preset threshold range, an attack threat warning is generated; if the similarity comparison result meets the second preset threshold range, an attack warning is generated.

[0101] Furthermore, the system is also used to implement the following functions:

[0102] The traceability agent digitally signs the traceability fragment and writes the index information of the traceability fragment into the blockchain ledger; the original content of the traceability fragment is encrypted and stored in off-chain verifiable storage space.

[0103] Furthermore, the system is also used to implement the following functions:

[0104] The traceability fragment includes a fragment identifier, author node identifier, time identifier, logical clock value, fingerprint digest, context index, and off-chain evidence reference.

[0105] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, the above description focuses on specific embodiments of this specification. Additionally, the processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In some implementations, multitasking and parallel processing are possible or may be advantageous.

[0106] The above description is only a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

[0107] This specification and accompanying drawings are merely illustrative examples of this application and are intended to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from its scope. Therefore, if such modifications and variations fall within the scope of this application and its equivalents, this application intends to include such modifications and variations.

Claims

1. A blockchain-based distributed network intrusion incident traceback method, characterized in that, The method comprises: Collecting intrusion event correlation data on the distributed node side, extracting event fingerprints from the intrusion event correlation data, and establishing a multi-dimensional event fingerprint chain, wherein the multi-dimensional event fingerprint chain comprises a traffic pattern fingerprint chain, an attack behavior sequence fingerprint chain, and an environment context fingerprint chain; Inputting the multi-dimensional event fingerprint chain into a tracing agent arranged on the distributed node, generating a trace segment using the tracing agent, and completing signature chaining; After the indexes of a plurality of trace segments are written into the blockchain, any qualified synthesizer initiates a splicing proposal, and a plurality of participating nodes perform on-chain voting of the splicing proposal based on respective local verification results and reputation weights; During the on-chain voting of the splicing proposal, time-causality consistency analysis of the corresponding trace segments of the participating nodes is performed, and a cross-node attack path sketch is established; After global verification of the on-chain voting of the cross-node attack path sketch, a network intrusion event tracing chain is constructed, the network intrusion event tracing chain is written into the blockchain, and a tracing mode library is constructed; The on-chain voting of the splicing proposal by the plurality of participating nodes based on respective local verification results and reputation weights comprises: Establishing a random extraction rule, and using the random extraction rule to extract trace segments of peer nodes for cross-challenge verification; In the cross-challenge verification process, the challenging party of the peer nodes performs segment logic consistency verification on the challenged party, and extracts evidence features; After the challenged party constructs zero-knowledge proof, the evidence features and the zero-knowledge proof are used for challenge identification, and a challenge identification result is established; According to the challenge identification result, the cross-challenge verification is completed, and the on-chain voting of the splicing proposal is completed based on the cross-challenge verification.

2. The blockchain-based distributed network intrusion incident traceback method of claim 1, wherein, The on-chain voting of the splicing proposal based on the cross-challenge verification comprises: Obtaining initial reputation weights of each participating node; According to the challenge identification result, a reputation weight dynamic correction factor is configured, and the reputation weight dynamic correction factor is dynamically constructed through challenge game; After correcting the initial reputation weights using the reputation weight dynamic correction factor, a reputation weight is established; After compensating the local verification results based on the cross-challenge verification, the corresponding local verification results after compensation are weighted and voted using the reputation weight, and the on-chain voting of the splicing proposal is completed.

3. The blockchain-based distributed network intrusion incident traceback method of claim 1, wherein, The time-cause consistency analysis of the corresponding trace segments of the participating nodes comprises: Positioning candidate trace segments according to the participating nodes; Performing signature verification and on-chain index consistency verification on the candidate trace segments; If the verification is passed, the time compatibility score, the fingerprint similarity score, and the explicit cause reference matching score of the candidate trace segment are calculated; According to the time compatibility score, the fingerprint similarity score, and the explicit cause reference matching score, a time-cause matching degree is synthesized to complete the time-cause consistency analysis.

4. The blockchain-based distributed network intrusion incident traceback method of claim 3, wherein, After synthesizing the time-cause matching degree according to the time compatibility score, the fingerprint similarity score, and the explicit cause reference matching score, the following steps are included: A preset matching degree threshold is constructed; After filtering the time-cause matching degree using the preset matching degree threshold, the candidate trace segments meeting the preset matching degree threshold are connected as directed weighted edges in the segment graph to establish a cross-node attack path sketch.

5. The blockchain-based distributed network intrusion incident traceback method of claim 1, wherein, The global verification of the on-chain voting of the cross-node attack path sketch includes: The global event sparsity analysis of all candidate events in the cross-node attack path sketch is performed to establish a first global consistency contribution; The system resource verification of each node in the cross-node attack path sketch at the time of event occurrence is performed to establish a second global consistency contribution; The global aggregation analysis of the first global consistency contribution and the second global consistency contribution is performed by using the on-chain voting to complete the global verification.

6. The blockchain-based distributed network intrusion incident traceback method of claim 1, wherein, The construction of the traceability mode library includes: After the multi-dimensional event chain is re-collected, the re-collected multi-dimensional event chain is compared with the attack mode in the traceability mode library to establish a similarity comparison result; If the similarity comparison result meets a first preset threshold interval, an attack threat prompt is generated; If the similarity comparison result meets a second preset threshold interval, an attacked prompt is generated.

7. The blockchain-based distributed network intrusion incident traceback method of claim 1, wherein, The traceability agent is used to generate a traceability segment and complete signature on-chain, including: The traceability agent is used to digitally sign the traceability segment, and the index information of the traceability segment is written into a blockchain ledger; The original content of the traceability segment is encrypted and stored in an off-chain verifiable storage space.

8. The blockchain-based distributed network intrusion incident traceback method of claim 7, wherein, The traceability segment includes a segment identifier, an author node identifier, a time identifier, a logical clock value, a fingerprint digest, a context index, and an off-chain evidence reference.

9. A blockchain-based distributed network intrusion incident traceback system, characterized by, The system is used to implement the blockchain-based distributed network intrusion event traceability method of any one of claims 1-8, and the system includes: A fingerprint chain establishment module is configured to collect intrusion event associated data on the distributed node side, extract event fingerprints from the intrusion event associated data, and establish a multi-dimensional event fingerprint chain, wherein the multi-dimensional event fingerprint chain includes a traffic pattern fingerprint chain, an attack behavior sequence fingerprint chain, and an environmental context fingerprint chain; A traceability segment generation module is configured to input the multi-dimensional event fingerprint chain to a traceability agent arranged on the distributed node, and use the traceability agent to generate a traceability segment and complete signature on-chain; An on-chain voting module is configured to, after the indexes of a plurality of traceability segments are written into a blockchain, initiate a splicing proposal by any qualified synthesizer, and perform on-chain voting of the splicing proposal by a plurality of participating nodes based on their local verification results and reputation weights; An attack path sketch establishment module is configured to, during the on-chain voting of the splicing proposal, perform time-causal consistency analysis of the traceability segments of the corresponding participating nodes to establish a cross-node attack path sketch; A traceability mode library construction module is configured to, after the global verification of the on-chain voting of the cross-node attack path sketch, construct a network intrusion event traceability chain, write the network intrusion event traceability chain into a blockchain, and construct a traceability mode library.

Images