Blockchain-based trusted sdns malicious information auditing and correction method and system

Abstract

The application discloses a blockchain-based trusted SDN malicious information auditing and correction method and system, which comprises the following steps: S1, system initialization; S2, sending the original data generated by the switch to a lightweight anomaly detection model for classification processing operation through a blockchain, and triggering a smart contract; S3, the ACMI auditing node in the region acquires the original data and performs deep analysis through a federated learning model, and verifies and judges the abnormal data in combination with the smart contract; S4, the abnormal data is verified again through a digital twin, and the smart contract generates a correction or isolation instruction through the verification results twice, and sends the instruction to an SDN controller; S5, the SDN controller executes the generated correction or isolation instruction; S6, a central aggregation server outputs abnormal information and associated data. The system comprises an edge perception and preprocessing layer, a federated learning collaborative auditing layer, a digital twin verification and strategy generation layer, and a trusted execution and feedback closed loop layer.

Description

Technical Field

[0001] This invention relates to the field of information auditing, and in particular to a blockchain-based trusted SDN method and system for auditing and correcting malicious information. Background Technology

[0002] The centralized management model of Software-Defined Networking (SDN) makes its decision-making highly dependent on critical information such as traffic statistics and rule matching counts reported by data plane switches. However, this information is easily distorted by device hardware and software failures or malicious tampering attacks (such as counter resetting or data spoofing). Once the controller performs routing calculations or load balancing based on erroneous information, it will directly lead to serious consequences such as network congestion and service interruption. Although existing research has proposed inserting an audit layer (such as the ACMI scheme) between the control and data planes to correct errors through flow path tracing and cross-comparison of multi-node information (large number adjudication), such methods have inherent limitations: First, the audit layer itself becomes a new centralized single point, and its credibility and security cannot be self-proven; second, relying on preset rules and static logic makes it difficult to cope with new and complex collaborative attack patterns; third, in multi-domain operation scenarios, data privacy barriers prevent information sharing, forming "data silos" that limit the detection capabilities based on global knowledge; finally, the audit process lacks transparent and tamper-proof records, making it difficult to trace and assign responsibility.

[0003] In recent years, emerging paradigms such as blockchain and federated learning have offered potential solutions to the aforementioned problems. Blockchain technology, through distributed ledgers and smart contracts, can build a decentralized trust infrastructure, ensuring the transparency, trustworthiness, and immutability of processes. Federated learning allows multiple participants to collaboratively train machine learning models without exchanging raw data, potentially breaking down data silos and achieving collective intelligence while protecting privacy. However, current technologies have not yet deeply integrated these cutting-edge paradigms with the data plane security auditing issues of SDN. Related research is mostly isolated exploration or simply piecing together concepts, failing to construct an organically collaborative, trust-enhanced auditing system covering the entire chain of "perception-decision-execution-traceability."

[0004] Therefore, there are significant technological gaps in the current field of SDN security auditing: on the one hand, traditional auditing methods have bottlenecks in trust mechanisms, adaptive defense, and privacy collaboration; on the other hand, emerging trust computing and privacy computing technologies have not yet formed systematic solutions in SDN security scenarios. The industry urgently needs a new method for auditing and correcting malicious SDN information that can deeply integrate cutting-edge technologies such as blockchain and federated learning to achieve decentralized trust, privacy-preserving collaborative learning, intelligent proactive defense, and full traceability. Summary of the Invention

[0005] The purpose of this invention is to address the above-mentioned problems by proposing a blockchain-based trusted SDN malicious information auditing and correction method and system. It constructs a decentralized trust, privacy protection collaboration, and intelligent security ecosystem with forward-looking verification and continuous evolution capabilities, filling the technological gap in the field of SDN security auditing.

[0006] To achieve the above objectives, the technical solution of the present invention is as follows:

[0007] A blockchain-based trusted SDN method for auditing and correcting malicious information includes the following steps:

[0008] S1. Perform system initialization and build a digital twin and a lightweight anomaly detection model;

[0009] S2. The raw data generated by the switch is sent to the lightweight anomaly detection model via the blockchain for classification and processing, and the smart contract is triggered at the same time.

[0010] S3. The ACMI audit nodes in the region acquire raw data and perform in-depth analysis through a federated learning model, and combine smart contracts to verify and judge abnormal data.

[0011] S4. The abnormal data is re-verified through the digital twin. The smart contract generates a correction or isolation instruction based on the results of the two verifications and sends it to the SDN controller.

[0012] The S5 and SDN controllers will send the generated correction or isolation commands to the corresponding switches for execution, and send the execution results back to the central aggregation server via the blockchain.

[0013] S6, the central aggregation server outputs abnormal information and its related data.

[0014] Furthermore, step S1 specifically includes the following steps:

[0015] S11. Deploy a blockchain based on the practical Byzantine fault-tolerant consensus algorithm, and add the SDN controller, ACMI audit nodes in each region, and switches as light nodes to the blockchain network.

[0016] S12. Deploy smart contracts on the blockchain, define evidence formats, verification node selection algorithms, consensus rules, and reward and punishment mechanisms for validators and nodes;

[0017] S13. Each participating region initializes an anomaly detection model locally, and the central aggregation server initializes the global model.

[0018] S14. Use the southbound interface of the network orchestration tool to synchronize the physical network topology and status in real time to build a digital twin;

[0019] S15. Deploy pruned and quantized anomaly detection models on switches or neighboring gateways.

[0020] Furthermore, step S3 specifically includes the following steps:

[0021] S31. After the ACMI audit node in the region listens to relevant transactions on the blockchain, it obtains complete raw data from the local database and uses a federated learning model for in-depth analysis.

[0022] S32. At regular training cycles, the federated learning model is trained using recent raw data and the global model is updated through the central aggregation server.

[0023] S33. When the smart contract receives an edge alert or an anomaly report actively submitted by the ACMI audit node, it enters the consensus process.

[0024] S34. The smart contract calls a verifiable random function to randomly select several verifiers from the node pool.

[0025] S35. The smart contract sends a verification request to the selected validators. Each validator independently analyzes the evidence of the same anomaly report using its own federated learning model and submits the verification result with a digital signature back to the blockchain.

[0026] S36. After the smart contract collects the verification results, if the number of abnormal votes exceeds the preset consensus threshold, the consensus decision will determine it as a malicious anomaly and generate a unique Anomaly_ID.

[0027] Furthermore, step S4 specifically includes the following steps:

[0028] S41. For malicious anomalies confirmed by the consensus procedure, the smart contract sends a verification request to the digital twin.

[0029] S42. The digital twin injects an abnormal virtual copy into a high-fidelity simulation environment, runs network simulation, records changes in key performance indicators, outputs a quantitative simulation report, and submits it to the blockchain after signing it.

[0030] S43. The Anomaly_ID generated by the smart contract is combined with the quantitative simulation report output by the digital twin to execute the pre-coded logic, generate correction or isolation instructions, and send them to the SDN controller.

[0031] Furthermore, the execution of the smart contract includes the following steps:

[0032] Step 1: Deploy smart contracts on the blockchain, defining the evidence format, the verifiable random function-based verifier node selection algorithm, the consensus threshold based on Byzantine fault tolerance, and the quantified verifier and node reward and punishment mechanism.

[0033] Step 2: The smart contract receives and verifies the original data of the compliance event proposal, and completes the filing on the blockchain;

[0034] Step 3: The smart contract enters the consensus process, coordinates according to the consensus protocol, and generates a consensus decision.

[0035] Step 4: Trigger the digital twin verification instruction based on the consensus decision. After the digital twin outputs the quantitative simulation report, the smart contract integrates the consensus decision and the quantitative simulation report to generate a correction or isolation instruction and send it to the SDN controller.

[0036] Step 5: The SDN controller verifies the digital signature of the smart contract on the correction or isolation instruction. The state change generated after the instruction is executed is signed as new trusted evidence and fed back to the smart contract via the blockchain. After receiving the feedback, the smart contract executes its pre-coded verifier and node reward and punishment mechanism and updates the reputation scores of the relevant nodes participating in the ACMI audit.

[0037] Furthermore, the execution of the verification node selection algorithm for the verifiable random function specifically includes the following steps:

[0038] Step 1: When an abnormal event requiring the initiation of the consensus process is detected, the smart contract first constructs a unique input seed for this random selection; let EVENT_HASH represent the unique evidence hash of the event to be adjudicated, B represent the current block hash, and C represent the state accumulator or round count within the contract, then the input to the VRF is defined as:

[0039] ;

[0040] Step 2: The smart contract calls the VRF pre-compiled contract on the blockchain to perform elliptic curve verifiable random function calculations on the input α. First, α is mapped to a point on the elliptic curve group G using the HashToCurve() function, and then the VRF private key is used. Calculate VRF value points The smart contract generates a corresponding cryptographic proof π, which, together with the VRF value, constitutes the proof package P = (Γ, π). The smart contract further hashes Γ to obtain a fixed-length random number.

[0041] ;

[0042] Step 3: Let the set of candidate ACMI audit nodes be N={1,2,…,N}, and each ACMI audit node i corresponds to a positive reputation weight w. i Define the total weight. And normalize the single sampling probability of each ACMI audit node to ;

[0043] Step 4: Calculate the intermediate quantity q based on the number of ACMI audit nodes n = N. i =n·p i Two mapping arrays, prob[j] and alias[j], are generated. During the formal sampling phase, a verifiable pseudo-random sequence is constructed based on the VRF random number R. , And normalize it to a real number Ut in the interval [0,1); for each Ut, calculate and order , .like < prob[j t If the index is j, then select index j. t Otherwise, choose alias[j] t The index pointed to by ] gives the selected ACMI audit node number;

[0044] Step 5: If a newly extracted ACMI audit node has not yet appeared in the ACMI audit node set, add it to the ACMI audit node set; otherwise, discard the result and continue using the next random number, continuing the above process until the size of the ACMI audit node set S reaches the preset number of validators k. The final ACMI audit node set is the validator set S participating in this consensus process.

[0045] Step 6: After execution, the smart contract writes the event evidence hash EVENT_HASH, block hash B, contract accumulator C, random number R, VRF proof package P, and the final selected set of verification nodes S as an atomic transaction into the blockchain; afterwards, the correctness of the selection of the ACMI audit nodes can be independently verified based on the above data.

[0046] Furthermore, the execution of the federated learning model includes the following steps:

[0047] Step 1: Perform deep inference; Each regional ACMI audit node loads a local copy of the global model, performs forward inference on the deep traffic features from the local area, and outputs structured anomaly detection, confidence level, and classification results.

[0048] Step 2: Training and Evolution; First, differential privacy noise is injected, then the model gradient is homomorphically encrypted, and then uploaded and updated through the blockchain. The central aggregation server completes secure aggregation in the encrypted state, generates a new generation of global model, and distributes it to all clients through the blockchain to achieve collective evolution of model capabilities.

[0049] Step 3: Cross-system data collaboration; the federated learning model, combined with smart contracts, makes consensus decisions, and the consensus decisions generate updated states, which are then fed back to the federated learning model for training and evolution, forming an enhanced closed-loop structure.

[0050] Furthermore, the execution of the lightweight anomaly detection model includes the following steps:

[0051] Step 1: Through pruning, quantization, and knowledge distillation, a standard anomaly detection model is transformed into a lightweight anomaly detection model and deployed on front-end network devices.

[0052] Step 2: Receive raw data from the switch, perform inference and output anomaly confidence level. Make a judgment based on the confidence level threshold. If the confidence level threshold is reached, immediately execute the local autonomous response and generate an edge alert to be transmitted to the blockchain.

[0053] Step 3: Edge alerts trigger smart contracts. The smart contracts, combined with federated learning models, enter the consensus process to optimize edge strategies.

[0054] A blockchain-based trusted SDN malicious information auditing and correction system includes an edge awareness and preprocessing layer for network deployment and data collection, a federated learning collaborative auditing layer for deep inference and global training evolution, a digital twin verification and policy generation layer for simulation verification and generating correction strategies, and a trusted execution and feedback closed-loop layer for execution and feedback. Data is transmitted sequentially between the edge awareness and preprocessing layer, the federated learning collaborative auditing layer, the digital twin verification and policy generation layer, and the trusted execution and feedback closed-loop layer.

[0055] Furthermore, the operation of the edge sensing and preprocessing layer includes the following steps:

[0056] Step 1: Pre-configure the lightweight anomaly detection model into the switch or edge gateway;

[0057] Step 2: Monitor and receive raw data from the switch in real time through the edge ACMI audit node;

[0058] Step 3: The deployed anomaly detection model analyzes the raw data, outputs anomaly confidence, and judges whether to enter the emergency response process based on the preset confidence threshold.

[0059] Step 4: Once the threshold is triggered, the edge ACMI audit node immediately executes a pre-programmed local action, generates and signs an edge alert, submits it to the blockchain first, and triggers the smart contract to enter the consensus process; at the same time, the edge ACMI audit node synchronizes the raw data to the SDN controller in its region.

[0060] Step 5: For normal or low-risk raw data that does not reach the threshold, simply record it without triggering further actions to ensure processing efficiency.

[0061] Compared with the prior art, the advantages and positive effects of this invention are:

[0062] This invention proposes a blockchain-based trusted SDN malicious information auditing and correction method and system. By deeply integrating blockchain, federated learning, digital twins, and edge intelligence, it constructs an intelligent security ecosystem with decentralized trust, privacy protection collaboration, and forward-looking verification and continuous evolution capabilities. By organically integrating the decentralized trust of blockchain, the privacy collaboration of federated learning, the forward-looking verification of digital twins, and the rapid response of edge intelligence, it solves the core problems of traditional solutions such as centralized bottlenecks, data silos, and correction risks, forming a closed-loop advantage of "perception-decision-execution-traceability", making a certain contribution to the field of SDN security auditing. Attached Figure Description

[0063] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the 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.

[0064] Figure 1 This is an overall flowchart of the present invention;

[0065] Figure 2 A flowchart illustrating the workflow of the edge sensing and preprocessing layer;

[0066] Figure 3 A flowchart illustrating the workflow of a smart contract;

[0067] Figure 4 Workflow diagram for the algorithm to select verification nodes;

[0068] Figure 5 A flowchart of the workflow for a federated learning model;

[0069] Figure 6 This is a flowchart of the workflow for a lightweight anomaly detection model. Detailed Implementation

[0070] 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, any modifications, equivalent substitutions, improvements, etc., made by those skilled in the art to all other embodiments obtained without creative effort should be included within the protection scope of the present invention.

[0071] This invention proposes a Trusted Audit and Correction System based on Blockchain and Federated Learning (TAC-BFL) for malicious information auditing and correction. By deeply integrating blockchain, federated learning, digital twins and edge intelligence, it constructs an intelligent security ecosystem with decentralized trust, privacy protection collaboration, forward-looking verification and continuous evolution capabilities.

[0072] like Figure 1 As shown, the overall architecture and workflow of the TAC-BFL system are divided into four core levels, forming a dynamic, closed-loop intelligent processing chain:

[0073] Edge awareness and preprocessing layer: Deployed at the network edge, responsible for data collection, lightweight anomaly screening, and millisecond-level rapid response.

[0074] Federated Learning Collaborative Audit Layer: Under the premise of protecting data privacy, a global detection model is trained collaboratively through federated learning, and decentralized, verifiable collaborative auditing and adjudication are achieved based on the blockchain consensus mechanism.

[0075] Digital Twin Verification and Policy Generation Layer: Utilizing a high-fidelity network digital twin, this layer performs forward-looking simulation verification of identified anomalies, quantifies their impact, and generates precise corrective policies.

[0076] Trusted Execution and Feedback Closed-Loop Layer: The blockchain smart contract ensures the trusted execution of authoritative instructions and feeds the execution results back to the chain, forming a closed loop of "detection-decision-execution-verification" to drive continuous system optimization.

[0077] The specific implementation steps are as follows:

[0078] Step S1: System Initialization and Trust Foundation Construction

[0079] Blockchain network initialization: Deploy a consortium blockchain based on the Practical Byzantine Fault Tolerance (PBFT) consensus algorithm. The SDN controller, regional ACMI audit nodes, and core switches join the network as light nodes.

[0080] Smart contract deployment: Deploy the core "audit ruling smart contract" on the chain, defining the evidence format, the verifier node selection algorithm based on verifiable random function (VRF), the consensus rules (two-thirds majority vote), and the reward and punishment mechanism for verifiers and nodes.

[0081] "Evidence format" specifically refers to "SDN anomaly event audit evidence structured format", which is a standard specification for switches and edge nodes to submit anomaly information to smart contracts. It ensures that the evidence is verifiable, tamper-proof, and seamlessly integrated with subsequent VRF algorithms and consensus rules, including: the hash value, timestamp, and signature of the original data.

[0082] Consensus Rules: "Consensus Rules" specifically refers to "Validator Judgment Consensus Rules," the core of which is "two-thirds majority decision," which is the decentralized decision-making logic for smart contracts to determine whether an abnormal event is valid.

[0083] The "reward and punishment mechanism" and the subsequent "reward and punishment function and reward and punishment logic" are the same concept, and the unified terminology is "verifier and node reward and punishment mechanism".

[0084] Federated learning framework initialization: Each participating domain initializes an anomaly detection model based on a temporal convolutional network locally, while the central aggregation server initializes the global model.

[0085] Digital Twin Construction: Utilizing the southbound interface of network orchestration tools, the physical network topology and status are synchronized in real time to construct a high-fidelity digital twin.

[0086] Edge model deployment: Deploy a pruned and quantized lightweight anomaly detection model (TinyML model) on a switch or nearby gateway with computing capabilities.

[0087] Step S2: Trusted Uploading of Multi-Source Information to the Blockchain and Edge Preprocessing

[0088] After generating statistical information, the data plane exchange digitally signs it and then submits the <signature, information hash, timestamp> as original evidence to the blockchain network, triggering the corresponding smart contract (corresponding to data flow ②). The original data is simultaneously sent to the associated edge nodes (corresponding to data flow ①).

[0089] Edge intelligent preprocessing: Edge nodes run lightweight models to perform millisecond-level analysis on the raw data, outputting anomaly confidence scores and preliminary classifications (corresponding to data stream ③). If the score exceeds the fast response threshold, the edge node immediately executes pre-defined local actions (e.g., adding rate limits to suspected abnormal flows), generates an edge alert, signs it, and uploads it to the blockchain as a high-priority transaction (corresponding to data stream ④), triggering the fast channel of the smart contract.

[0090] Step S3: Collaborative Auditing and Blockchain Consensus Based on Federated Learning

[0091] Local Deep Inference (S3.1): After the ACMI node of the domain (as a federated learning client) listens to relevant on-chain transactions, it obtains complete raw data from the local database and uses its local federated learning model to perform deep analysis.

[0092] Periodic Federated Model Evolution (S3.2): At regular training epochs, each client trains using recent local data. During gradient descent updates, Gaussian noise that satisfies differential privacy requirements is injected. Subsequently, the model parameter updates are encrypted using a homomorphic encryption algorithm and uploaded to the aggregation server (corresponding to data stream ⑤). The server securely aggregates the parameters in encrypted form, generates an updated global model, and distributes it to each client (corresponding to data stream ⑥).

[0093] Blockchain Consensus Audit Process (S3.3): When the smart contract receives an edge alert or an anomaly report actively submitted by a client, it enters the consensus process. a. Validator Selection: The contract calls a verifiable random function to randomly select several validators from the pool of online and reputable federated learning client nodes. b. Independent Verification: The contract sends verification requests to the selected validators (corresponding to data flow ⑦). Each validator independently analyzes the same anomaly evidence using its latest federated learning model and submits the verification result with a digital signature back to the blockchain (corresponding to data flow ⑧). c. Smart Judgment: After the contract collects enough verification results, if the number of "is an anomaly" votes exceeds the preset consensus threshold, it is automatically judged as a malicious anomaly and a unique Anomaly_ID is generated.

[0094] Step S4: Digital Twin Verification and Precise Strategy Generation

[0095] Forward-looking impact assessment (S4.1): For critical anomalies confirmed by consensus, the system automatically initiates digital twin verification. The smart contract sends a verification request to the digital twin system (corresponding data flow ⑨). a. State injection: The digital twin system injects a virtual copy of the anomaly into its high-fidelity simulation environment. b. Decision simulation: Simulates network decisions based on this error information (e.g., route recalculation). c. Simulation and quantification: Runs network simulation and records changes in key performance indicators (KPIs). d. Verification report generation: The digital twin system outputs a quantified simulation report, signs it, and submits it to the blockchain (corresponding data flow ⑩). This report provides objective evidence of the necessity and urgency of the correction.

[0096] Smart contract generation instructions (S4.2): The audit decision contract combines the consensus results and digital twin reports to automatically execute pre-coded logic, generate authoritative correction or isolation instructions, and send them to the SDN controller (corresponding data flow ⑪).

[0097] Step S5: Trusted Execution, Feedback, and Continuous Learning

[0098] Secure command issuance and execution (S5.1): After the controller verifies the contract signature of the command, it issues it to the corresponding switch for execution via the southbound interface (corresponding data flow ⑫).

[0099] Closed-loop feedback: The new state generated after the instruction is executed will serve as new evidence, be signed by the exchange, and then uploaded back to the blockchain (corresponding to data stream ⑬), forming a closed loop of "detection-decision-execution-verification". This not only verifies the correction effect through closed-loop processing, but also provides new, high-quality feedback data for the federated learning model, driving continuous model optimization.

[0100] Step S6: Output the results

[0101] Global network view, real-time list of abnormal events and their processing status, map of faulty switches and detailed chain of evidence, etc.

[0102] Key data flow:

[0103] The perception and reporting flow (①-④) reflects the transformation from raw data to credible evidence.

[0104] Collaborative Intelligent Flow (⑤-⑧): Demonstrates the model evolution and distributed consensus adjudication process under privacy protection.

[0105] Verification and Decision Flow (⑨-⑪): Reveals the decision chain from consensus ruling to the generation of authoritative instructions, in which digital twins provide a key verification link.

[0106] Execution and feedback flow (⑫-⑬): This forms a closed-loop trust mechanism from instruction issuance to effect verification, ensuring that actions are auditable and the system is evolvable.

[0107] Detailed explanation of key algorithms and models:

[0108] Specific implementation of the federated learning collaborative audit layer

[0109] The federated learning collaborative audit layer of this invention is designed for the special characteristics of SDN malicious information auditing scenarios. It adopts a "privacy protection-collaborative training-audit adaptation" implementation scheme. The specific operation runs through step S3 (local deep inference, federated model evolution, blockchain consensus audit), and the details are as follows: (1) Initialization of federated learning framework and model structure: Each ACMI audit node of the participating domain acts as a federated learning client and initializes a temporal convolutional network (TCN) anomaly detection model locally. The input of the model is 32-dimensional temporal features (including traffic statistics, rule matching count, port status, etc.). After two convolutional layers (convolutional kernel size = 3, stride = 1) to extract temporal features, and then after two fully connected layers (hidden unit number = 64), the probability distribution of 5 types of anomalies is finally output (normal, hardware failure, count clearing, data deception, compound attack). (2) Collaborative training process under privacy protection (corresponding to step S3.2): In order to protect the original data privacy of each participating domain during the training process, this invention designs a federated model evolution mechanism with differential privacy + homomorphic encryption dual protection. Differential privacy prevents malicious nodes from backtracking through gradients to retrieve original traffic data by injecting Gaussian noise (noise standard deviation σ = 0.1, satisfying the differential privacy requirement of ε = 1.0) into the gradient. Its mathematical guarantee is that for any adjacent datasets D and D' (differing by one sample), the model parameter update mechanism M satisfies: Where M represents the training mechanism and S represents any set of outputs. Subsequently, the CKKS homomorphic encryption scheme is used to encrypt the gradients after adding noise, enabling the aggregation server to securely aggregate the ciphertext gradients without decryption. The aggregation formula is: ;where w i The client weight (which can be set according to the amount of data) is represented by Enc, which indicates homomorphic encryption.

[0110] The client encrypts the model parameters after differential privacy noise enhancement using the CKKS homomorphic encryption scheme, and then securely uploads the encrypted model parameters to the central aggregation server through a designated data stream (data stream ⑤). The server does not need to decrypt the encrypted parameters, but directly performs a weighted average operation on the encrypted gradients from multiple clients in the encrypted state. After completing the secure parameter aggregation, the updated global model parameters are generated. The new global model parameters are then encrypted using the CKKS homomorphic encryption scheme. Finally, the encrypted global model parameters are distributed to all federated learning clients through a designated data stream (data stream ⑥), realizing privacy-preserving collaborative updates of model parameters. (3) Collaborative mechanism between federated learning and auditing: The core role of the federated model is to provide “quantifiable intelligent evidence” for blockchain consensus auditing, which is specifically reflected in step S3.3 (blockchain consensus auditing):

[0111] The core of the synergy between federated learning and audit adjudication is reflected in the blockchain consensus audit process. When a smart contract receives a high-priority alert from an edge node or an anomaly report actively submitted by an ACMI node, it immediately triggers the consensus process. The validator (federated learning client) selected by the smart contract through the VRF algorithm calls the latest local copy of the federated learning global model to perform independent deep reasoning on the same anomalous evidence, outputting a quantitative result including the anomaly confidence level and anomaly type. This reasoning result (anomaly confidence level ≥ 0.8 is judged as 'anomaly') is then bound to the validator's own digital signature as a valid voting result and uploaded to the chain. After the smart contract collects a sufficient number of valid votes, it counts the votes according to the preset two-thirds majority consensus threshold. If the number of "anomaly" votes reaches the threshold, it is automatically judged as a malicious anomaly and a unique Anomaly_ID is generated, completing the audit adjudication. This achieves the organic synergy between the distributed intelligence provided by federated learning and the blockchain consensus adjudication, ensuring the accuracy and decentralized credibility of the audit results.

[0112] Detailed Explanation of Blockchain Consensus Mechanisms, Decentralized Implementation, and VRF Verification Principles

[0113] The blockchain consensus mechanism is the Practical Byzantine Fault Tolerance (PBFT) consensus algorithm, specifically adapted for SDN multi-domain malicious information auditing scenarios. The PBFT consensus process is deeply integrated with the auditing logic of this invention, corresponding to step S3.3 (Blockchain Consensus Auditing Process), as follows:

[0114] Preparatory phase: After receiving high-priority alerts from edge nodes or anomaly reports from ACMI nodes, the smart contract generates an "audit proposal" (including anomaly evidence hash and the switch ID to be verified) and broadcasts it to all consensus nodes; consensus nodes verify the proposal format and signature validity, and proceed to the next phase after passing the verification.

[0115] Preparation phase: Consensus nodes randomly select 3-5 validators from the "online and reputable ACMI node pool" using the VRF algorithm and send "validation request + audit proposal" to them; validators call their local federated learning models to independently reason about anomalous evidence, generate "voting result (abnormal / normal) + reasoning log + digital signature", and feed it back to the consensus node;

[0116] Submission Phase: After the consensus node collects ≥ a preset number (3) of valid votes, it broadcasts the selected master node to the entire chain; the light node verifies the validity of the digital signatures of all votes, and records them to its local ledger after confirming that they have not been tampered with.

[0117] Adjudication phase: The smart contract counts the voting results across the entire chain. If the number of "abnormal" votes is greater than or equal to 2 / 3 of the consensus threshold, a unique Anomaly_ID is automatically generated, triggering subsequent digital twin verification.

[0118] In this system, "decentralization" does not mean the complete absence of a central point, but rather the elimination of a single, irreplaceable center of trust, distributing trust among a network and rules comprised of multiple independent participants. This is achieved specifically through the following methods:

[0119] Decentralized power: Abandoning the traditional ACMI scheme's "single audit layer" design, the audit capabilities are distributed across ACMI nodes (federated learning clients) in various domains. Each node is only responsible for local data inference and verification voting, and no node has "absolute audit power" or "final decision-making power".

[0120] Consensus Decision-Making: The final decision is not determined by any individual or single node, but is generated through the PBFT consensus process described above. A correct result is produced as long as a majority of nodes (more than 2 / 3) are genuine. This means that an attacker must simultaneously control more than 1 / 3 of the consensus nodes, which is extremely difficult and costly in real-world permissioned blockchains.

[0121] Equal cross-domain permissions: Regardless of the size of the domain (such as a large data center domain and a small branch domain), the voting weight of its ACMI nodes is consistent, and the validity of the vote is determined only by the "reputation score" (based on the accuracy of historical votes), thus avoiding the monopoly of auditing rights by large domains.

[0122] Edge sensing and preprocessing layer

[0123] The rapid response mechanism of edge awareness and preprocessing layers is the first line of defense. Its core lies in utilizing a local, lightweight AI model for real-time decision-making and immediately executing pre-defined containment actions without relying on a central controller, thus buying valuable time for subsequent in-depth auditing. The workflow is as follows: Figure 2 (1) Model initialization deployment: This step occurs when the system starts up. The lightweight anomaly detection model (a TinyML model that has been pruned and quantized) in the edge node is pre-installed in the smart switch or edge gateway to give it local intelligent analysis capabilities.

[0124] Pruning and quantization are two commonly used techniques for model compression, designed to reduce model size and computational cost, enabling deployment on resource-constrained edge devices.

[0125] The pruning process first uses weight importance assessment (L2 norm) to iteratively remove redundant parameters and fine-tunes the pruned model to restore performance. The quantization scheme adopts symmetric uniform quantization, which maps weights and activation values ​​from floating-point precision to 8-bit integers, and combines quantization-aware training (QAT) to simulate quantization error during training to minimize precision loss. To address the differences in precision sensitivity of different layers, a hybrid precision strategy (INT8 for convolutional layers and FP16 for output layers) is adopted. Finally, the model compression rate reaches 87.5%, the inference latency is reduced to 4ms, and the precision loss is controlled within 1.4%, meeting the multiple constraints of edge devices on real-time performance, low power consumption, and high precision. (2) Data reception: The edge node listens to and receives raw traffic statistics from the data plane switch in real time. This data stream is the Figure 1 The data stream marked in the middle ①. (3) Intelligent reasoning and threshold judgment: The deployed lightweight model analyzes the raw data and outputs the anomaly confidence level. The system judges whether to enter the emergency response process based on the preset "fast response threshold (threshold set to 0.8)". (4) Fast response and event reporting: Once the threshold is triggered, the edge node immediately executes the pre-programmed local action (such as rate limiting, discarding), generates and signs the "edge alarm", and submits it to the blockchain network as a high priority. This operation is Figure 1 The key data flow ④ directly triggers the backend smart contract and collaborative audit process (step S3). The edge node synchronizes the newly inserted temporary flow table entry information to the SDN controller of this domain to ensure the consistency of the controller view. (5) Normal processing: For normal or low-risk traffic that does not reach the threshold, only record it and do not trigger further actions to ensure processing efficiency.

[0126] Audit ruling smart contract

[0127] The audit decision smart contract does not correspond to a single isolated step, but rather serves as a central hub for automated execution and trust coordination across multiple key steps. For example... Figure 3 As shown, it demonstrates how the "audit decision smart contract" serves as the core driving engine, connecting and linking the corresponding relationships and workflows of each step from S1 to S5:

[0128] (1) Initialization Phase (corresponding to step S1): In step S1: System Initialization and Trust Foundation Construction, deploying the "Audit Decision Smart Contract" is a key technical action to realize the trust foundation of the system. This process essentially formally defines the core business rules—including the standardized structure of evidence, the selection algorithm of the Verifiable Random Function (VRF), the consensus threshold based on Byzantine fault tolerance (2 / 3 majority vote), and the quantified reward and punishment mechanism for validators and nodes—in the form of deterministic code and permanently deploys them to the distributed ledger. Once deployed, the contract becomes an immutable, transparent, and automated rule execution engine, providing a unified, intermediary-free trust and execution framework for all subsequent interactions (S2 evidence submission, S3 consensus auditing, S4 strategy generation, S5 trusted execution). Therefore, S1 completes the "formal solidification" from natural language rules to on-chain executable code, laying the technical foundation for the decentralized autonomy of the system.

[0129] (2) Core adjudication process (corresponding to S2-S4): The core runtime role of the smart contract is embodied in step S3: collaborative auditing and blockchain consensus based on federated learning. In this stage, the contract is activated from a static rule base into a dynamic, distributed state machine that coordinates multiple participants. Its execution logic forms a precise mapping with the S3.3 sub-step:

[0130] a. Event Reception and Verification (Input Phase): The contract receives and verifies compliance event proposals from S2, and completes on-chain case filing.

[0131] b. Consensus Protocol Coordination (Core Processing Phase): The contract acts as the protocol coordinator, sequentially executing its coded logic: First, it calls the built-in VRF algorithm (implementing S3.3.a) to randomly select a set of validators from the pool of verified nodes; then, it broadcasts audit requests to the selected validators and receives their independent votes, digitally signed and analyzed based on the local federated model (implementing S3.3.b); finally, it automatically counts the votes, applies a preset consensus algorithm (such as a Byzantine fault tolerance threshold) to make a decision (implementing S3.3.c), and generates a unique, on-chain confirmed Anomaly_ID. The entire S3.3 process is driven and instantiated by the smart contract, a deterministic state machine.

[0132] (3) Closed-loop guarantee (corresponding to S5): As the trust anchor of the system, the smart contract plays a role in ensuring the continuity and trustworthiness of cross-layer operations:

[0133] a. Strategy Generation Triggering and Signing (Corresponding to Step S4): The consensus decision generated by the contract in S3 automatically triggers Step S4: the authoritative instruction for digital twin verification. After the digital twin system submits the quantitative simulation report, the contract again acts as the aggregation and decision point, integrating on-chain consensus and simulation data to generate an "authoritative correction instruction" with its cryptographic signature. This instruction itself is an on-chain asset with complete traceability.

[0134] b. Trusted Execution Verification and Incentive Closed Loop (corresponding to step S5): In step S5: Trusted Execution, the SDN controller must verify the smart contract digital signature of the instruction to confirm its authority and integrity. The state change resulting from instruction execution must be signed and recorded on the blockchain as new trusted evidence. After capturing this feedback, the contract automatically executes its pre-encoded verifier and node reward / penalty mechanism, updating the reputation scores of the relevant participating nodes. Thus, through the contract's signing, verification, and state update mechanism, the system completes a global trusted closed loop from "threat detection - intelligent decision-making - strategy execution - effect feedback - incentive adjustment".

[0135] Verifiable Random Function (VRF) Verification Node Selection Algorithm

[0136] The Verifiable Random Function (VRF) verifier selection algorithm is not an independent step in the system, but rather a deterministic cryptographic protocol that implements step S3.3a (verifier selection). Its design aims to transform the text's description of "the contract calling the VRF function to randomly select several verifiers from a pool of online and reputable nodes" into a fair, transparent, manipulation-resistant, and auditable automated process. This algorithm is written within the "Audit Decision Smart Contract." Whenever a new anomaly requires initiating a consensus audit, the contract automatically executes this algorithm, triggering step S3.3 and providing a clear list of participants for the subsequent step S3.3b (independent verification), serving as the trust starting point for the entire consensus process. Its specific process is as follows: Figure 4 As shown;

[0137] Step 1: Input Preparation and Random Source Generation

[0138] Input: The algorithm receives two key inputs: first, the unique evidence hash of the event to be adjudicated, which ensures that each selected random source is bound to a specific event and prevents reuse attacks; second, the "pool of online and reputable nodes" obtained in real time from the blockchain state, which is derived from the system initialization and continuous maintenance in step S1.

[0139] Generating verifiable random numbers: The smart contract calls the VRF pre-compiled contract on the chain. This call uses the "current block hash" and an "internal accumulator of the contract" as seeds, and generates a pair of outputs through elliptic curve cryptography: a completely random value R and a cryptographic proof P. (1) Constructing VRF input: When the system detects an abnormal event that requires the initiation of consensus audit, the smart contract first constructs the unique input seed for this random selection. Let EVENT_HASH represent the unique evidence hash of the event to be adjudicated, B represent the current block hash, and C represent the state accumulator or round count inside the contract, then the input of VRF is defined as:

[0140] ;

[0141] (2) VRF generation and proof

[0142] Subsequently, the contract invokes the on-chain VRF pre-compiled contract to perform elliptic curve verifiable random function computation on the input α. First, the HashToCurve() function maps α to points on the elliptic curve group G. Then use the VRF private key Calculate VRF value points The contract generates a corresponding cryptographic proof π. This proof, along with the VRF value, constitutes the proof package P = (Γ, π). To facilitate subsequent random sampling, the contract further hashes Γ to obtain a fixed-length random bit string:

[0143] ;

[0144] The random number R and its proof P will be written into the blockchain, forming an immutable random source certificate.

[0145] Step 2: Reputation-based weighted random selection

[0146] Weighted Mechanism: The algorithm introduces a "reputation score" as a weight. Each node's reputation score is a quantitative reflection of its historical voting accuracy and activity. During random selection, nodes with higher reputation scores have a proportionally increased probability of being selected.

[0147] Let N = {1, 2, ..., N} be the set of currently online and reputable candidate nodes. Each node i corresponds to a positive reputation weight wi, used to quantify the reliability and activity of its historical behavior. Define the total weight. And normalize the single sampling probability of each node to ,

[0148] Efficient Execution (Alias ​​Sampling): To achieve efficient weighted random selection, the algorithm employs an "alias sampling" algorithm. Based on the number of nodes n = N, the intermediate quantity q is calculated. i =n·pi The algorithm generates two mapping arrays, prob[j] and alias[j]. During the formal sampling phase, the algorithm constructs a verifiable pseudo-random sequence based on the VRF random number R. , And normalize it to a real number in the interval [0,1). For each ,calculate and order like < prob[j t If the index is j, then select index j. t Otherwise, choose alias[j] t The index pointed to by ]. This gives the number of the selected node.

[0149] To achieve no-replacement selection, the system maintains a set S of selected nodes. If a newly selected node is not yet in S, it is added to the set; otherwise, the result is discarded and the next random number is used. This process continues until the size of set S reaches the preset number of validators k. The final set S is the set of validator nodes participating in this consensus audit.

[0150] Step 3: Outputting Evidence and Public Verification

[0151] After the algorithm executes, the smart contract writes the following data as an atomic transaction to the blockchain: event evidence hash (EVENT_HASH), block hash (B), contract accumulator (C), random number (R), VRF proof (P), and the final selected set of verification nodes (S). This on-chain record is equivalent to a public, immutable "notarized random draw".

[0152] Any system participant can independently verify the correctness of the node selection afterward based on on-chain data. The verification process consists of two parts: first, using the VRF public key to verify the proof P, confirming that the random number R was indeed generated by the input α and has not been tampered with; second, combining the publicly available node reputation weight wi with the alias sampling rule, re-execute the weighted random selection process to reproduce the verification node set S.

[0153] If both of the above verification steps pass, it can be confirmed that the selection process of the verification node is fair, transparent and auditable in a cryptographic sense, thus providing a reliable trust basis for the subsequent consensus decision process.

[0154] Federated learning global anomaly detection model

[0155] like Figure 5As shown in the flowchart, the federated learning global anomaly detection model is the core engine for achieving "privacy-preserving collaborative intelligence." Its fundamental purpose is to build a continuously evolving global detection capability capable of responding to new types of cyberattacks through collaborative training and knowledge sharing, without exchanging original data from participating domains. The diagram clearly illustrates the model's three dynamic roles in the system: real-time inference as an analysis tool (State 1), periodic training as an evolutionary entity (State 2), and driving the system's intelligent closed loop as a data hub (State 3).

[0156] (a): Reasoning state (corresponding to steps S3.1 and S3.3.b)

[0157] Each domain audit node loads a local copy of the global model and performs forward inference on the deep traffic characteristics from its local location. This process outputs structured anomaly detection, confidence level, and classification results. Its core output serves two key stages: first, it is used in step S3.1 (local deep inference) to form local deep analysis conclusions; second, it serves as a direct and quantifiable intelligent basis for the validator nodes to make voting judgments in step S3.3.b (independent verification), thereby injecting distributed intelligence into the blockchain consensus.

[0158] (b): Evolutionary state (corresponding to step S3.2)

[0159] The model evolution (training) process fully implements step S3.2 (periodic federated model evolution). Each client trains using local data, first injecting differential privacy noise to prevent back-calculation of the original data from the gradients; then, homomorphic encryption is applied to the model gradients to ensure that parameter updates are kept confidential throughout transmission and processing. Encrypted updates are transmitted via... Figure 1 Data stream ⑤ is securely uploaded, and the aggregation server completes secure aggregation in encrypted form, ultimately generating a new generation of global model and passing it through... Figure 1 Data stream ⑥ is distributed to all clients, enabling the collective evolution of model capabilities.

[0160] (C): Cross-system data collaboration

[0161] The initial screening events provided by the S2 / edge layer offer high-value targets for deep inference; the intelligent output of the model drives the S3.3 consensus layer to make authoritative decisions, while the high-quality labeled data generated by the consensus feeds back into model training; simultaneously, the S5 execution feedback layer provides real-world data on network actions to validate and strengthen the model's learning. This forms an enhanced closed loop from "data input -> intelligent analysis -> consensus decision -> action feedback -> model optimization," enabling the system's detection capabilities to continuously and adaptively evolve with changes in the network threat landscape.

[0162] Lightweight edge anomaly detection model

[0163] The core of the lightweight edge anomaly detection model is embodied in steps S1 (initial deployment) and S2 (real-time processing), and it serves as a bridge connecting the data plane and the collaborative audit layer. The specific process is as follows: Figure 6 As shown;

[0164] a. Initial deployment (corresponding to step S1.5): To meet the resource constraints of edge devices, a standard model is transformed into a lightweight version and deployed to the front-end devices of the network through model compression techniques such as pruning, quantization, and knowledge distillation.

[0165] b. Real-time processing and response (corresponding to step S2): Directly receive the raw data stream from the switch (corresponding to S2.1 and data stream ①), perform millisecond-level model inference, output confidence level, and make judgments based on thresholds. If the confidence level threshold is reached, immediately execute a local autonomous response (such as rate limiting). Generate and sign an edge alert (data stream ④), elevating the event from the data plane to the trust plane.

[0166] c. System Collaboration Phase (Connecting and Triggering Step S3): The on-chain alarm (data flow ④) directly triggers the smart contract, which is one of the core triggering events for starting step S3 (collaborative auditing and consensus). In addition, this data flow directly triggers the complex consensus auditing process of the backend (federated learning collaborative auditing layer), enabling cloud intelligence to optimize edge strategies.

[0167] The following specific embodiments and simulation experiments will verify the effectiveness of this technical solution; I: Simulation settings:

[0168] 1. Network Topology and Platform:

[0169] To ensure the validity and reliability of the simulation results, a highly controllable and realistic experimental platform was constructed. The physical network data plane was simulated and generated by Mininet 2.3.0, containing four autonomous systems. Each system consists of one ONOS controller, four Open vSwitch switches, and ten hosts, interconnected by a core router. The digital twin was constructed in real time based on the global view of ONOS and the simulation capabilities of Mininet.

[0170] 2. Deployment of core components:

[0171] SDN Network Topology: Simulates a multi-domain network of 3 data centers (DC1-DC3), each data center containing 10 OpenFlow switches, 1 ONOS controller, 1 ACMI audit node, and 50 terminal hosts; cross-domain connections are made to the backbone network via 2 redundant 10Gbps links, with link latency of: DC1-DC2=15ms, DC1-DC3=25ms, and DC2-DC3=20ms; terminal hosts simulate 3 types of load: low load (10% link utilization), medium load (50%), and high load (80%).

[0172] Blockchain network parameters: 4 consensus nodes + 33 light nodes (3 controllers, 3 ACMI nodes, 30 core switches); PBFT consensus fault tolerance rate 33%; Smart contract core parameters: consensus threshold 2 / 3, VRF seed update cycle 3600 seconds.

[0173] Federated learning parameters: Local TCN model (input 32-dimensional temporal features, 2 convolutional layers + 2 fully connected layers, output 5 types of anomalies); training period of 1 hour, batch size=32, learning rate=0.001; differential privacy Gaussian noise σ=0.1, homomorphic encryption CKKS scheme.

[0174] Digital twin parameters: synchronization frequency 1 time per second, simulation accuracy 96%, link delay / bandwidth error ≤5% compared to physical network; KPI monitoring indicators: link utilization, end-to-end delay, packet loss rate, controller decision time.

[0175] II. Simulation Scene Design

[0176] As shown in Table 1, a total of 6 core simulation scenarios were designed, covering key variables such as anomaly type, network load, and attack intensity. Each scenario was repeated 10 times and the average value was taken to ensure the reliability of the results.

[0177]

[0178] III. Definition of Simulation Indicators

[0179] For objective evaluation, three types of core indicators are defined:

[0180] (1) Performance indicators

[0181] Anomaly detection accuracy (Acc): (True positives + True negatives) / (Total number of samples), calculated based on the confusion matrix.

[0182] Anomaly Type Identification Accuracy (Type-Acc): Number of samples correctly identified as anomaly types (hardware failure / data spoofing / count reset, etc.) / Total number of anomaly samples.

[0183] Edge preprocessing latency: the time it takes for an edge node to receive raw data and output anomaly confidence levels;

[0184] Consensus audit delay: The time taken from when a smart contract receives an alert to when it generates an Anomaly_ID;

[0185] Digital twin verification latency: the time it takes for the twin system to receive a request and output a quantitative report;

[0186] End-to-end processing latency: The total time elapsed from when the switch reports abnormal data to when the correction command is executed.

[0187] System throughput: The number of abnormal events that can be processed per unit of time;

[0188] (2) Security and privacy indicators

[0189] Failure Rate (FRR): Number of undetected abnormal samples / Total number of abnormal samples × 100%;

[0190] False Alarm Rate (FAR): Number of normal samples misclassified as abnormal / Total number of normal samples × 100%;

[0191] Privacy risk (PLR): 1-differential privacy ε / 10 (ε=1.0), combined with homomorphic encryption cracking difficulty assessment;

[0192] Ledger immutability: the success rate of malicious nodes attempting to tamper with historical audit records;

[0193] Single point of failure tolerance: The probability that the system can complete the audit normally under a single point of failure (consensus node / controller);

[0194] Correction failure rate: (Number of abnormal events that did not recover after the correction command was executed / Total number of abnormal events) × 100%;

[0195] (3) Comparison indicators

[0196] Three existing solutions were selected as control groups, and their core metrics were compared with those of the TAC-BFL (experimental group):

[0197] Comparison Group 1 (Traditional Solution): ACMI Solution (Centralized Audit Layer + Large Number Decision);

[0198] Comparison Group 2 (Single Blockchain Solution): Blockchain + Static Rule Auditing (No Federated Learning + Digital Twin);

[0199] Comparison Group 3 (Single Federated Learning Scheme): Federated Learning Anomaly Detection + Centralized Controller Decision Making (No Blockchain + Digital Twin).

[0200] IV. Simulation Implementation Steps

[0201] Step 1: Environment Initialization and Baseline Testing

[0202] Start Mininet+ONOS to build a multi-domain SDN network, deploy a digital twin mirror synchronously, and verify the consistency between the physical network and the twin's state (error ≤ 5%).

[0203] Deploy the Hyperledger Fabric consortium blockchain, deploy the audit and adjudication smart contract, and complete the identity authentication and access of 37 nodes (4 consensus nodes + 33 light nodes);

[0204] Initialize the federated learning framework: The central server initializes the global TCN model (Xavier normal distribution weights), and after 10 rounds of warm-up training (learning rate 0.0005), it is distributed to 3 local training nodes;

[0205] Deploy an edge TinyML model (INT8 quantization, 680KB parameters) and set a fast response threshold of 0.8;

[0206] Run for 30 minutes under normal conditions to collect baseline data (link utilization 35%, latency 12ms, packet loss rate 0%) and verify the stability of the simulation environment.

[0207] Step 2: Execute scenario-based simulation

[0208] Configure the experimental parameters (anomaly type, load, attack script) sequentially according to scenario numbers S1-S6.

[0209] Use the Scapy tool to inject abnormal data / attack scripts (such as modifying the traffic reporting value of DC2-SW5 in S1, and injecting a script to clear the count in S2).

[0210] Grafana records time-series changes by collecting real-time metrics data (latency, accuracy, throughput, etc.) through Prometheus.

[0211] Each scenario was repeated 10 times, and the raw data (including abnormal event logs, model parameters, and consensus results) was recorded for each experiment.

[0212] Step 3: Privacy and Security Verification

[0213] In scenario S5, a malicious node is deployed to monitor the federated learning parameter transmission channel and attempt to tamper with the blockchain history.

[0214] Use the IBM Differential Privacy Library to assess the risk of privacy breaches in model parameters;

[0215] Verify the immutability of the blockchain ledger: Malicious nodes attempt to modify the audit records of the S2 scenario, and observe the changes in ledger hashes and system feedback.

[0216] Step 4: Data preprocessing and indicator calculation (30 minutes)

[0217] Invalid data (such as samples caused by sudden hardware failures) were removed, and 12,000 valid samples were retained.

[0218] Calculate the detection accuracy, false negative rate, and false positive rate based on the confusion matrix;

[0219] The average value and standard deviation of indicators such as delay and throughput at each stage are statistically analyzed.

[0220] Compare the differences in indicators between the experimental group and the control group, and calculate the percentage improvement in performance.

[0221] V. Simulation Results and Analysis

[0222] (1) Performance index results (as shown in Table 2)

[0223] Table 2. Core performance indicators of the system in various scenarios (mean ± standard deviation)

[0224]

[0225] analyze:

[0226] Under single anomaly scenarios (S1, S2), the system detection accuracy is ≥97.8%, the overall process latency is ≤7.5 seconds, and the correction failure rate is ≤0.4%, which fully meets the design goals and demonstrates the accuracy of edge preprocessing and federated learning collaborative detection.

[0227] Under the combined attack scenario (S3) and the high load scenario (S4 high load), the performance decreased slightly but still met the standard, indicating that the system has strong adaptability to complex working conditions. The edge lightweight model effectively filtered redundant data and reduced the pressure on the core layer.

[0228] In the single point of failure scenario (S6), the system still maintains a detection accuracy of 95.9% with a total latency of 8.8 seconds, which verifies the fault tolerance capability of PBFT consensus and the advantages of decentralized architecture.

[0229] (ii) Results of security and privacy indicators (as shown in Table 3)

[0230] Table 3. Measured Results of System Security and Privacy Indicators

[0231]

[0232] Based on the analysis in the table above:

[0233] With a false negative rate of only 1.2% and a false positive rate of 0.8%, the federated learning model has a strong ability to identify SDN anomalies. The combination of static rules and dynamic models effectively reduces false negatives and false positives.

[0234] The privacy leakage risk is 8.5%, which meets the GDPR requirements: the Gaussian noise injected by differential privacy ε=1.0 effectively prevents gradient backpropagation, and CKKS homomorphic encryption makes it take more than 72 hours for malicious nodes to crack the parameters (far exceeding the model update cycle of 1 hour).

[0235] The ledger is 100% immutable. When a malicious node attempts to tamper with the historical records, it is rejected by the consensus node due to the mismatch of block hashes, thus verifying the tamper-proof characteristics of the blockchain.

[0236] (III) Comparative experimental results (as shown in Table 4)

[0237] Table 4 Comparison of core indicators between the system and the comparison scheme.

[0238]

[0239] Based on the analysis in the table above:

[0240] Detection accuracy: TAC-BFL improves by 9.3 percentage points compared to ACMI and by 6.1 percentage points compared to a single blockchain. This is because federated learning and collaborative training incorporate cross-domain anomaly features, and blockchain consensus avoids misjudgments by a single node.

[0241] Processing latency: TAC-BFL reduces latency by 42.4% compared to ACMI. Edge preprocessing filters 60% of normal data, reducing audit pressure on the core layer. After PBFT consensus optimization, latency is compressed to 3.2 seconds.

[0242] Privacy protection: TAC-BFL's privacy leakage risk is only 24.1% of ACMI's. Federated learning does not transmit raw data, and encryption technology blocks the path of privacy leakage.

[0243] Fault tolerance and correction effectiveness: TAC-BFL's ability to resist single points of failure is 1.65 times that of ACMI, and its correction failure rate is only 4% of that of ACMI. The forward-looking verification of digital twins avoids "over-correction" or "under-correction".

[0244] VI. Simulation Conclusions

[0245] Performance meets standards and has significant advantages: The TAC-BFL system in this invention meets the design goals in various scenarios, with an anomaly detection accuracy of ≥95.9%, a total process delay of ≤8.8 seconds, and a correction failure rate of ≤0.8%. It surpasses traditional ACMI solutions and single-technology solutions in terms of detection accuracy, processing efficiency, and fault tolerance.

[0246] Reliable security and privacy protection: The system in this invention has a false negative rate of 1.2%, a false positive rate of 0.8%, a privacy leakage risk of 8.5%, and 100% ledger immutability. It can effectively resist threats such as malicious tampering, privacy theft, and single point of failure, and meet the security requirements of SDN multi-domain auditing.

[0247] This invention organically integrates the decentralized trust of blockchain, the privacy collaboration of federated learning, the forward-looking verification of digital twins, and the rapid response of edge intelligence, solving the core problems of centralized bottlenecks, data silos, and correction risks in traditional solutions, forming a closed-loop advantage of "perception-decision-execution-traceability".

Claims

1. A blockchain-based trusted SDN malicious information auditing and correction method, characterized in that: Includes the following steps: S1. Perform system initialization and build a digital twin and a lightweight anomaly detection model; S2. The raw data generated by the switch is sent to the lightweight anomaly detection model via the blockchain for classification and processing, and the smart contract is triggered at the same time. S3. The ACMI audit nodes in the region acquire raw data and perform in-depth analysis through a federated learning model, and combine smart contracts to verify and judge abnormal data. S4. The abnormal data is re-verified through the digital twin. The smart contract generates a correction or isolation instruction based on the results of the two verifications and sends it to the SDN controller. The S5 and SDN controllers will send the generated correction or isolation commands to the corresponding switches for execution, and send the execution results back to the central aggregation server via the blockchain. S6. The central aggregation server outputs abnormal information and its related data. The execution of the smart contract includes the following steps: Step 1: Deploy smart contracts on the blockchain, defining the evidence format, the verifiable random function-based verifier node selection algorithm, the consensus threshold based on Byzantine fault tolerance, and the quantified verifier and node reward and punishment mechanism. Step 2: The smart contract receives and verifies the original data of the compliance event proposal, and completes the filing on the blockchain; Step 3: The smart contract enters the consensus process, coordinates according to the consensus protocol, and generates a consensus decision. Step 4: Trigger the digital twin verification instruction based on the consensus decision. After the digital twin outputs the quantitative simulation report, the smart contract integrates the consensus decision and the quantitative simulation report to generate a correction or isolation instruction and send it to the SDN controller. Step 5: The SDN controller verifies the digital signature of the smart contract on the correction or isolation instruction. The state change generated after the instruction is executed is signed as new trusted evidence and fed back to the smart contract via the blockchain. After receiving the feedback, the smart contract executes its pre-coded verifier and node reward and punishment mechanism and updates the reputation scores of the relevant nodes participating in the ACMI audit. The execution of the verification node selection algorithm for the verifiable random function specifically includes the following steps: Step 1: When an abnormal event requiring the initiation of the consensus process is detected, the smart contract first constructs a unique input seed for this random selection; let EVENT_HASH represent the unique evidence hash of the event to be adjudicated, B represent the current block hash, and C represent the state accumulator or round count within the contract, then the input to the VRF is defined as: ； Step 2: The smart contract calls the VRF pre-compiled contract on the blockchain to perform elliptic curve verifiable random function calculations on the input α. First, α is mapped to a point on the elliptic curve group G using the HashToCurve() function, and then the VRF private key is used. Calculate VRF value points The smart contract generates a corresponding cryptographic proof π, which, together with the VRF value, constitutes the proof package P = (Γ, π). The smart contract further hashes Γ to obtain a fixed-length random number. ； Step 3: Let the set of candidate ACMI audit nodes be N={1,2,…,N}, and each ACMI audit node i corresponds to a positive reputation weight. w i Define the total weight. And normalize the single sampling probability of each ACMI audit node to ; Step 4: Based on the number of ACMI audit nodes n =N, calculate intermediate quantities q i = n · p i And generate two sets of mapping arrays prob[ j ] and alias[ j During the formal sampling phase, a verifiable pseudo-random sequence is constructed based on the VRF random number R. , And normalize it to a real number Ut in the interval [0,1); for each Ut, calculate and order , ;like < prob[ j t If so, select the index. j t Otherwise, choose alias[ j t The index pointed to by ] gives the selected ACMI audit node number; Step 5: If a newly extracted ACMI audit node has not yet appeared in the ACMI audit node set, add it to the ACMI audit node set; otherwise, discard the result and continue to use the next random number, and continue to execute the above process until the size of the ACMI audit node set S reaches the preset number of validators k. The final ACMI audit node set is the validator set S that participates in the consensus process this time. Step 6: After execution, the smart contract writes the event evidence hash EVENT_HASH, block hash B, contract accumulator C, random number R, VRF proof package P, and the final selected set of verification nodes S as an atomic transaction into the blockchain; afterwards, the correctness of the selection of the ACMI audit nodes can be independently verified based on the above data.

2. The blockchain-based trusted SDN malicious information auditing and correction method as described in claim 1, characterized in that: Step S1 specifically includes the following steps: S11. Deploy a blockchain based on the practical Byzantine fault-tolerant consensus algorithm, and add the SDN controller, ACMI audit nodes in each region, and switches as light nodes to the blockchain network. S12. Deploy smart contracts on the blockchain, define evidence formats, verification node selection algorithms, consensus rules, and reward and punishment mechanisms for validators and nodes; S13. Each participating region initializes an anomaly detection model locally, and the central aggregation server initializes the global model. S14. Use the southbound interface of the network orchestration tool to synchronize the physical network topology and status in real time to build a digital twin; S15. Deploy pruned and quantized anomaly detection models on switches or neighboring gateways.

3. The blockchain-based trusted SDN malicious information auditing and correction method as described in claim 2, characterized in that: Step S3 specifically includes the following steps: S31. After the ACMI audit node in the region listens to relevant transactions on the blockchain, it obtains complete raw data from the local database and uses a federated learning model for in-depth analysis. S32. At regular training cycles, the federated learning model is trained using recent raw data and the global model is updated through the central aggregation server. S33. When the smart contract receives an edge alert or an anomaly report actively submitted by the ACMI audit node, it enters the consensus process. S34. The smart contract calls a verifiable random function to randomly select several verifiers from the node pool. S35. The smart contract sends a verification request to the selected validators. Each validator independently analyzes the evidence of the same anomaly report using its own federated learning model and submits the verification result with a digital signature back to the blockchain. S36. After the smart contract collects the verification results, if the number of abnormal votes exceeds the preset consensus threshold, the consensus decision will determine it as a malicious anomaly and generate a unique Anomaly_ID.

4. The blockchain-based trusted SDN malicious information auditing and correction method as described in claim 3, characterized in that: Step S4 specifically includes the following steps: S41. For malicious anomalies confirmed by the consensus procedure, the smart contract sends a verification request to the digital twin. S42. The digital twin injects an abnormal virtual copy into a high-fidelity simulation environment, runs network simulation, records changes in key performance indicators, outputs a quantitative simulation report, and submits it to the blockchain after signing it. S43. The Anomaly_ID generated by the smart contract is combined with the quantitative simulation report output by the digital twin to execute the pre-coded logic, generate correction or isolation instructions, and send them to the SDN controller.

5. The blockchain-based trusted SDN malicious information auditing and correction method as described in claim 4, characterized in that: The execution of the federated learning model includes the following steps: Step 1: Perform deep inference; Each regional ACMI audit node loads a local copy of the global model, performs forward inference on the deep traffic features from the local area, and outputs structured anomaly detection, confidence level, and classification results. Step 2: Training and Evolution; First, differential privacy noise is injected, then the model gradient is homomorphically encrypted, and then uploaded and updated through the blockchain. The central aggregation server completes secure aggregation in the encrypted state, generates a new generation of global model, and distributes it to all clients through the blockchain to achieve collective evolution of model capabilities. Step 3: Cross-system data collaboration; the federated learning model, combined with smart contracts, makes consensus decisions, and the consensus decisions generate updated states, which are then fed back to the federated learning model for training and evolution, forming an enhanced closed-loop structure.

6. The blockchain-based trusted SDN malicious information auditing and correction method as described in claim 5, characterized in that: The execution of the lightweight anomaly detection model includes the following steps: Step 1: Through pruning, quantization, and knowledge distillation, a standard anomaly detection model is transformed into a lightweight anomaly detection model and deployed on front-end network devices. Step 2: Receive raw data from the switch, perform inference and output anomaly confidence level. Make a judgment based on the confidence level threshold. If the confidence level threshold is reached, immediately execute the local autonomous response and generate an edge alert to be transmitted to the blockchain. Step 3: Edge alerts trigger smart contracts. The smart contracts, combined with federated learning models, enter the consensus process to optimize edge strategies.

7. A blockchain-based trusted SDN malicious information auditing and correction system, used to implement the blockchain-based trusted SDN malicious information auditing and correction method as described in claim 1, characterized in that: The system includes an edge perception and preprocessing layer for network deployment and data acquisition, a federated learning collaborative auditing layer for deep inference and global training evolution, a digital twin verification and policy generation layer for simulation verification and generating correction strategies, and a trusted execution and feedback closed-loop layer for execution and feedback. Data is transmitted sequentially between the edge perception and preprocessing layer, the federated learning collaborative auditing layer, the digital twin verification and policy generation layer, and the trusted execution and feedback closed-loop layer.

8. The blockchain-based trusted SDN malicious information auditing and correction system as described in claim 7, characterized in that: The operation of the edge sensing and preprocessing layer includes the following steps: Step 1: Pre-configure the lightweight anomaly detection model into the switch or edge gateway; Step 2: Monitor and receive raw data from the switch in real time through the edge ACMI audit node; Step 3: The deployed anomaly detection model analyzes the raw data, outputs anomaly confidence, and judges whether to enter the emergency response process based on the preset confidence threshold. Step 4: Once the threshold is triggered, the edge ACMI audit node immediately executes a pre-programmed local action, generates and signs an edge alert, submits it to the blockchain first, and triggers the smart contract to enter the consensus process; at the same time, the edge ACMI audit node synchronizes the raw data to the SDN controller in its region. Step 5: For normal or low-risk raw data that does not reach the threshold, simply record it without triggering further actions to ensure processing efficiency.

Images