BlockFedIDS: A Blockchain-Enabled Federated Learning Framework for Privacy-Preserving Intrusion Detection in Heterogeneous IoT Networks

2.1. Federated Learning for IoT Intrusion Detection

Recent work has increasingly adopted FL for network-based IDS. Sater and Ben Hamza [15] demonstrated that a federated LSTM model trained on heterogeneous IoT traffic achieves competitive detection rates while reducing data-transmission overhead by more than 80%. Jithish et al. [2] provided a systematic review of FL-based IDS architectures, identifying non-IID data heterogeneity and adversarial client behaviour as the two dominant unresolved challenges. Agrawal et al. [16] proposed FedCER, an emotion recognition framework using FL based on CNN architectures for EEG signal recordings. None of these systems addresses the trust and auditability of the aggregation step itself, a gap that BlockFedIDS resolves through blockchain.

2.2. Attacks on Federated Learning

Lyu et al. [17] provided a detailed taxonomy of FL privacy attacks, classifying gradient leakage, membership inference, and property inference as the three primary threat vectors. Fowl et al. [18] showed that an adversarial server can embed linear traps into the global model to extract private training records verbatim, which motivates our adoption of DP-SGD. Shejwalkar et al. [19] formalised local model poisoning as a constrained optimisation problem, generating attacks that evade norm clipping, RONI, and FLTrust; our on-chain Multi-Krum integration is specifically designed to counter this class of attack.

2.3. Byzantine-Robust and Privacy-Preserving Aggregation

Fang et al. [20] demonstrated that most existing Byzantine defences including Krum and coordinate-wise median are vulnerable to optimised attacks; they additionally showed that combining robust aggregation with server-side anomaly detection improves resilience. Naseri et al. [21] analysed the interaction between differential privacy and Byzantine robustness, proving that DP noise and BFT filtering are complementary rather than redundant, a finding that directly motivates our integrated framework. Li et al. [22] proposed Ditto, which adds a personalisation regularisation term to FL to improve accuracy under non-IID distributions; we adopt a similar per-client weighting in our aggregation phase.

2.4. Blockchain-Enabled Federated Learning

Passerat-Palmbach et al. [8] evaluated blockchain FL for healthcare, highlighting the gap between theoretical security guarantees and practical on-chain overhead. Mugunthan et al. [9] proposed PRIVACYFL, using smart contracts on Ethereum to coordinate training, but relying on an off-chain trusted execution environment for aggregation. Sguanci et al. [10] designed a layer-2 rollup scheme to reduce on-chain aggregation costs, achieving a 3.2× throughput improvement over naive on-chain approaches, but without any DP or BFT integration. More recently, Begum et al. [23] proposed BFLIDS, a blockchain-driven FL framework for intrusion detection in Internet-of-Medical-Things networks that improves transparency of aggregation but does not incorporate a formal DP mechanism or a certified Byzantine-robust aggregator. Govindaram and Jegatheesan [24] presented FLBC-IDS, combining FL and blockchain for IoT intrusion detection with a focus on secure model sharing rather than on-chain gradient verification. Ali et al. [25] surveyed blockchain and FL-based IDS frameworks for edge-enabled industrial IoT and identifying the joint treatment of privacy, Byzantine robustness, and verifiable aggregation as an open gap rather than a solved problem. Table 1 summarises how BlockFedIDS relates to these and the other blockchain-FL systems discussed above. BlockFedIDS is among the first framework in this comparison set to unify formal (ϵ, δ)-DP, on-chain certified Byzantine-robust (Multi-Krum) aggregation, Pedersen-commitment gradient verification, and a hybrid InterPlanetary File System (IPFS)/ledger storage design within a single IoT-IDS-oriented system; no single prior system in Table 1 combines all four properties.

3.1. System Architecture

Figure 1 shows the four logical layers of BlockFedIDS including the IoT client layer, the cryptographic commitment layer, the Hyperledger Fabric chaincode/consensus layer, and the IPFS storage layer. It also describes how they map onto the formal model introduced below. The detailed eight-step per-round protocol that ties these layers together is presented separately in Section 4.

Figure 1.

BlockFedIDS operates over a permissioned Hyperledger Fabric network shared by N IoT gateway clients C = {c₁, …, c_N} and M endorsing validator peers V = {v₁, …, v_M} running PBFT consensus and chaincode execution. Each client c_i holds a private local dataset $D_i={\{(x_j,y_j)\}}_{j=1}^{n_i}$ of network flow records with attack labels.

The global objective is (Equation (1)):

Table 2 summarises the principal symbols used throughout the remainder of the paper; each symbol is defined at first use and is included here purely as a forward reference for the reader.

3.2. Threat Model

The following threat model follows directly from the architecture in Section 3.1 as the clients, validators, and external observers each interact with a different layer of the stack (local training, chaincode execution, and the public ledger, respectively), they are given correspondingly distinct capabilities and are analysed as three separate adversary classes. This separation is what allows the security analysis in Section 5 to reason about privacy, Byzantine robustness, and auditability independently rather than under a single monolithic adversary.

Byzantine clients. Up to f < N/2 clients are corrupted and submit arbitrarily crafted gradient updates to degrade accuracy or embed backdoors [5, 19].

Honest-but-curious validators. Validators execute the chaincode correctly but may attempt to infer private training data from committed gradient ciphertexts.

External eavesdropper. A passive adversary observes all blockchain transactions but cannot break INDCPA encryption, collision-resistant hashing, or discrete-log hardness.

Out-of-scope assumptions: We exclude consensus-layer attacks (which require ≥ 1/3 validator corruption), supply-chain attacks on chaincode, and hardware side-channels.

4.1. Overview and Round Protocol

Figure 1 illustrates the BlockFedIDS four-layer stack, and Figure 2 details the eight-step per-round protocol. A training epoch proceeds as follows.

Figure 2.

• Step 1 – Model fetch. Each client c_i queries the ledger for the current global model hash H(w^t), retrieves the full weights from IPFS via the content identifier (CID) stored in the latest committed block, and verifies integrity using SHA-256.

• Step 2 – Local DP-SGD. The client trains on D i for E local epochs using DP-SGD (Section 4.2), producing a clipped, noise-perturbed gradient ${\text{g}}_i^t$ .

• Step 3 – Commitment generation. The client computes the Pedersen commitment ${\text{com}}_i^t=g^{({\text{g}}_i^t)}{h}^{r_i}$ and encrypts the gradient under the chaincode's public key: ${\text{enc}}_i^t={\text{Enc}}_{pk}({\text{g}}_i^t)$ .

• Step 4 – Transaction submission. The client broadcasts a signed Fabric transaction containing ( ${\text{com}}_i^t$ , ${\text{enc}}_i^t$ , sig_i ) to the ordering service.

• Step 5 – Commitment validation. The chaincode verifies each transaction for signature validity, correct commitment format, and consistency of n_i with the client's registered dataset size. Invalid transactions are rejected and the offending client's reputation score is decremented.

• Step 6 – Opening and decryption. Once K ≥ 2f + 3 valid commitments are collected, the chaincode emits an opening request. Each client responds with ( ${\text{g}}_i^t$ , r_i); the chaincode verifies $g^{({\text{g}}_i^t)}{h}^{r_i}\stackrel{?}{=}{\text{com}}_i^t$ before admitting the gradient to aggregation.

• Step 7 – On-chain Multi-Krum aggregation. Algorithm 1 is executed independently by every endorsing peer; consensus ensures identical outputs. The selected set S ⊆ [K] of benign gradients is averaged to produce w^t+1.

• Step 8 – Ledger commit. The updated model weights are pushed to IPFS. The chaincode writes the block record {H(w^t+1), S, t + 1, τ} (where τ is the Unix timestamp) to the Fabric ledger, completing the round.

4.2. Client-Side DP-SGD

At each round t, client c_i initialises from w^t and runs E epochs of DP-SGD [11]. For each mini-batch β of size B:

1. Compute per-sample gradients ${\tilde{g}}_{i,j}={\nabla }_w\mathcal{l}(w;x_j,y_j)$ .

2. Clip each per-sample gradient: ${\widehat{g}}_{i,j}={\tilde{g}}_{i,j}\cdot min(1,C/{{\tilde{g}}_{i,j}‖}_2)$ .

3. Aggregate the clipped gradients and add calibrated Gaussian noise (Equation (2)):

   (2)

   $$g_i^t=\frac{1}{B}\left({\displaystyle \sum _{j\in \beta }{\widehat{g}}_{i,j}+N(0,{\sigma }^2{C}^{2}I)}\right)$$

The noise multiplier σ is calibrated via the Rényi differential privacy (RDP) accountant [26], a tighter method than moments accounting for satisfying a per-round (ϵ 0,δ 0)-DP guarantee. After T rounds, the cumulative budget satisfies (Equation (3)):

Local training uses cosine learning-rate decay (Equation (4)) [27]:

4.3. Pedersen Commitment and Gradient Verification

Let 𝔾 be a prime-order group of order q in which the discrete-log problem is hard, with public generators g, h ∈ 𝔾. For each gradient update ${\text{g}}_i^t$ , serialized as a vector $u\in {\mathbb{Z}}_q^d$ , client c_i samples r_i ← ℤ_q and computes (Equation (5)):

During the opening phase, the client reveals ( ${\text{g}}_i^t$ , r_i); the chaincode recomputes $g^{({\text{g}}_i^t)}{h}^{r_i}$ and checks equality with the stored ${\text{com}}_i^t$ . Mismatches are treated as Byzantine submissions. The scheme is computationally binding under the discrete-log assumption and is perfectly hiding, meaning that no information about ${\text{g}}_i^t$ leaks from the commitment alone.

Client-side computational overhead. Computing ${\text{com}}_i^t$ requires two fixed-base modular exponentiations in 𝔾 (one for g^〈u〉, one for h^r_i) plus one multiplication, independent of the gradient dimension d once the polynomial encoding ⟨u⟩ has been folded into a single scalar; on a 256-bit prime-order group this costs on the order of a few milliseconds on a constrained IoT gateway (e.g., a Cortex-A72 class SoC), which is negligible next to the seconds-scale local DP-SGD training time per round. This is substantially cheaper than a general-purpose zk-SNARK, recent blockchain-FL work using Groth16-style proofs reports proof-generation times ranging from roughly one millisecond per round for small models to tens of seconds for larger ones [28, 29], with verification remaining cheap in all cases. We therefore adopt Pedersen commitments rather than zk-SNARKs because our threat model only requires consistency verification (did the client open what it committed to?) rather than a general-purpose proof of correct DPSGD execution; the latter would additionally need an arithmetic circuit for gradient clipping and noise addition, which is exactly the heavier proof-of-training setting explored in [28, 29] and which we identify as a natural upgrade path once client-side hardware allows it.

4.4. On-Chain Multi-Krum Aggregation

Once the chaincode has verified openings from K ≥ 2 f + 3 clients, it executes Algorithm 1 within a deterministic Golang chaincode function endorsed by all M validators. The endorsement policy requires M − f matching results before the block is committed, making any deviation from the algorithm equivalent to a consensus-layer attack.

Complexity. The pairwise distance computation costs O(K²d), where d is the gradient dimension (67,908 for our MLP). For K = 20 clients, this amounts to approximately 2.7×10¹⁰ floating-point operations, which completes in ∼4 s on an Intel Xeon E5-2699 validator node.

4.5. Reputation-Weighted Aggregation

Beyond Multi-Krum's binary selection, BlockFedIDS maintains a persistent reputation score ρ_i ∈ [0,1] per client, initialised to 1.0. After each round, ρ i is updated as (Equation (6)):

4.6. Hybrid Storage Design

Full model weights (∼260 KB for our MLP) are stored on IPFS under content-addressed identifiers (CIDs). The Fabric ledger stores only the hashes of the weights, the IPFS CID, the selected client set S, the round number, and a Unix times-tamp totalling ≈ 1.4 KB per round. End-to-end integrity is preserved, any weight modification changes the CID, which would no longer match the on-chain hash. This design limits blockchain storage growth to ≤ 15 MB per 10,000 rounds, making it practical for long-running IoT deployments. A naive scheme that stores full model weights on-chain instead of on IPFS would require ≈ 260 KB of ledger state per round amounting to roughly 186× more than the 1.4 KB hybrid design and its effect on committed transactions-per-second and commit latency, is the subject of an ongoing follow-up experiment on the same Fabric testbed (see the Limitations discussion in Section 7).

Table 2 (Section 3) summarises the main symbols used throughout the paper.

6.1. Experimental Setup

Platform. Hyperledger Fabric 2.5, Golang chaincode, 20 Ubuntu 22.04 VMs (4vCPU, 8GB RAM) as clients, 3 bare- metal Xeon E5-2699 nodes as validators, and 1 IPFS node.

Datasets. NSL-KDD [13]: 125,973 training and 22,544 test records across 5 classes (Normal, DoS, Probe, R2L, U2R). CIC-IDS-2017 [14]: 2.8million records across 15 attack classes. Data are partitioned non-IID using a Dirichlet distribution (α=0.5) across 20 clients.

Model. A four-layer MLP with batch normalisation: 78 → 256 → 128 → 64 → #classes; 67,908 parameters for the NSL-KDD setting.

Hyperparameters. T = 100, E = 5, B = 64, C = 1.0, σ = 1.1, (ϵ, δ) = (8, 10⁻⁵), f = 6 (30%), β = 0.9, η max = 0.01, η min = 10 − 4. These values follow common practice rather than an exhaustive per-task search: (ϵ, δ) = (8, 10⁻⁵) and σ = 1.1 correspond to the standard “moderate-privacy” operating point used in the Opacus reference implementation of DP-SGD [11] and lie within the ϵ ∈ [1,16] envelope we sweep explicitly in Section 6.4; β = 0.9 is the conventional exponential-moving-average decay rate used for reputation and trust scores in the FL literature, chosen to average out a single noisy round without erasing a client's multi-round history; and α=0.5 is a moderately non-IID Dirichlet setting commonly used to stress-test FL aggregation rules.

Baselines. (1) Centralised oracle; (2) FedAvg [3]; (3) FedAvg with DP; (4) Biscotti-style BC-FL [10]; (5) FLTrust [20].

6.2. Detection Performance

Table 3 reports accuracy, F1-score, false positive rate (FPR), and detection rate (DR) on both benchmarks at 0% Byzan-tine clients.

BlockFedIDS narrows the gap to the centralised oracle to 1.17pp on NSL-KDD, compared with 1.86pp for FedAvg. The reduced FPR (0.91% vs. 1.23%) reflects the benefit of Multi-Krum filtering: high-variance Byzantine updates that would inflate false alarms under FedAvg are discarded before aggregation.

6.3. Robustness Under Byzantine Attacks

Figure 3 plots NSL-KDD accuracy against the Byzantine fraction (0–30%) under a label-flipping attack. FedAvg collapses to near-random performance (50.3%) at 30% Byzantine clients; BlockFedIDS retains 81.2% accuracy, representing a 74.3% reduction in accuracy degradation. FLTrust reaches only 63.2% at the same adversarial level because its server-centric root of trust can itself be targeted when the server is not unconditionally trusted. The evaluation above uses label-flipping because it is the attack most directly comparable across all five baselines; a stronger evaluation against a distributed backdoor injection or a model-replacement attack [5] against FLTrust specifically is planned as a direct follow-up on the same testbed and is listed as an explicit limitation in Section 7 rather than estimated here.

Figure 3.

6.4. Privacy–Utility Trade-off

Figure 4 reports the measured accuracy of BlockFedIDS and the FedAvg+DP-SGD baseline at each swept value of ϵ. Both curves rise steeply for ϵ ≤ 8 as the DP noise multiplier σ decreases, then flatten for ϵ > 8, indicating that little additional utility is gained by further relaxing the privacy budget beyond the operating point.

Figure 4.

At the strictest setting tested (ϵ = 1), BlockFedIDS reaches 89.60% accuracy against 87.90% for FedAvg+DP-SGD, a 1.70pp gap driven by the large Gaussian noise multiplier σ required at low ϵ. As ϵ increases to 4, both methods gain more than 5pp, narrowing the relative noise floor. At ϵ = 8, BlockFedIDS attains 97.14% versus 95.87% for the baseline (Table 3), a 1.27pp gap. Beyond ϵ = 8, accuracy saturates for both methods: moving from ϵ = 8 to ϵ = 16 yields only a further 0.76pp gain for BlockFedIDS (97.14% to 97.90%), confirming diminishing marginal utility from relaxing the privacy budget further.

6.5. Convergence Analysis

Figure 5 plots the global training loss over 100 rounds under 0% and 20% Byzantine clients on NSL-KDD.

Figure 5.

FedAvg diverges after round 40 under20% Byzantine clients (loss climbs to 0.44), while BlockFedIDS stabilises at 0.080, which is a 5.5× improvement. The two clean-setting curves are nearly coincident, confirming that Multi-Krum incurs negligible overhead when no adversary is present.

6.6. Blockchain Performance

Table 4 reports Fabric throughput, per-round latency, and on-chain storage as the number of clients scales from 5 to 30, for both our hybrid storage design and a naive on-chain baseline in which the full model weight vector (∼260 KB) is written directly to the ledger each round instead of being pushed to IPFS with only a 1.4 KB hash/CID retained on-chain.

For the hybrid design, TPS degrades gracefully from 312 to 171 as N scales from 5 to 30, dominated by the O(N² d) Multi-Krum computation, while on-chain storage remains below 1.5 KB/round at all tested scales. The naive on-chain baseline exhibits a markedly different scaling behaviour because Fabric's endorsement, gossip dissemination, and block-commit steps all scale with payload size: writing full weights on-chain increases per-round latency from 0.88s to an estimated 48.7s at N = 20 and reduces committed throughput from 234 to an estimated 4.2 TPS, a ∼98% reduction. Ledger growth scales correspondingly, reaching an estimated 2.6GB per 10,000 rounds versus 15 MB for the hybrid design, a ∼173× reduction.

6.7. Ablation Study

Table 5 quantifies the contribution of each component on NSL-KDD at 20% Byzantine clients and ϵ = 8.

Multi-Krum is the dominant defence (+27.6pp over no defence); DP and the blockchain layer together add a further 6.0pp; and the reputation mechanism contributes an additional 1.4pp by excluding clients with a history of abnormal updates, demonstrating its complementary value. Multi-Krum dominates because it acts within every round, directly discarding Byzantine gradients before they can influence w^t+1; the reputation mechanism, by contrast, only removes a client from future rounds after its behaviour has been consistently flagged over several rounds (Eq. 6), so its marginal benefit is smaller once Multi-Krum is already active but non-zero because it prevents the small residual influence of borderline clients that oscillate around the acceptance boundary from accumulating over T rounds. Table 5 reports this decomposition on NSL-KDD, confirming that the same ordering (Multi-Krum > DP+blockchain > reputation) holds on CIC-IDS-2017 requires re-running the ablation on that dataset.