Table 1.
Comparison of BlockFedIDS with representative blockchain-enabled FL systems. DP: differential privacy; BFT: certified Byzantine-fault-tolerant aggregation; Verif.: cryptographic per-update verification.
| Method | Domain | Blockchain platform | DP | BET | Verif. | Reported limitation |
|---|---|---|---|---|---|---|
| Passerat-Palmbach et al. [8] | Healthcare | Generic permissioned | – | – | – | On-chain overhead not quantified |
| PRIVACYFL [9] | General FL | Ethereum smart contract | – | – | TEE-based | Relies on off-chain trusted hardware |
| Biscotti-style [10] | General FL | Layer-2 rollup | – | – | – | No DP or certified BFT aggregation |
| FLTrust [20] | General FL | None (centralised server) | – | ✓ | – | Server root of trust is a single point of failure |
| BFLIDS [23] | IoMT IDS | Permissioned | – | – | – | No formal DP or certified BFT aggregator |
| FLBC-IDS [24] | IoT IDS | Permissioned | – | – | – | Focuses on model sharing, not gradient verification |
| BlockFedIDS (ours) | IoT IDS | Hyperledger Fabric | ✓ | ✓ | Pedersen | Complexity scales as O(K2 d) |
Figure 1.
BlockFedIDS four-layer stack: IoT clients running local DP-SGD, the Pedersen commitment/encryption layer, the Hyperledger Fabric chaincode executing verification and Multi-Krum aggregation under PBFT consensus, and the IPFS off-chain storage layer.
Table 2.
Summary of key notation.
| Symbol | Description |
|---|---|
| N, M | Number of IoT clients / Fabric validator peers (20, 4) |
| f | Maximum number of Byzantine clients tolerated (6) |
| T, E | Global training rounds / local epochs per round (100, 5) |
| B | Local mini-batch size (64) |
| wt | Global model parameters at round t |
| DP-SGD gradient of client ci at round t | |
| d | Dimensionality of the gradient vector (67,908) |
| C, σ | Gradient clip norm / DP noise multiplier (1.0, 1.1) |
| ϵ, δ | Cumulative DP privacy budget (8, 10−5) |
| K | Number of clients whose commitments are opened in a round |
| S | Multi-Krum selected (benign) client set, |S| = K − f |
| Pedersen commitment of | |
| ρi, τρ | Reputation score of client ci / suspension threshold (0.3) |
| β | Reputation exponential-decay factor (0.9) |
| H(·) | SHA-256 hash function |
| α | Dirichlet non-IID concentration parameter (0.5) |
Figure 2.
Per-round sequence diagram of BlockFedIDS. Solid arrows indicate data flow between layers; dashed arrows indicate control messages (opening requests).
Table 6.
Algorithm 1: On-Chain Multi-Krum Aggregation (Chain-code)
| Require: Verified gradients , current model wt, learning rate η, Byzantine bound f |
| Ensure: wt+1 committed to ledger; IPFS CID returned ▷ Score every opened gradient by its distance to its closest honest-sized neighbourhood |
| 1: for each client i ∈ [K] do |
| 2: nbrs (i) ← K − f − 2 nearest gradients by ℓ2 -distance ▷ excludes the f+1 points an outlier could bias |
| 3: ▷ lower s(i) = more consistent with the majority |
| 4: end for |
| 5: S ← top-(K−f) clients with smallest s(·) ▷ discard the f highest-scoring (most outlying) clients |
| 6: ▷ average only the surviving, presumed-benign gradients |
| 7: ▷ single deterministic SGD step, replicated by every peer |
| 8: cid ← IPFS.push(wt+1) ▷ full weights go off-chain; only the CID is committed |
| 9: ledger.put({H(wt+1), cid, S, t+1, τ}) ▷ ≈ 1.4 KB write: hash, CID, selected set, round, timestamp |
| 10: return wt+1 |
Table 3.
Detection performance on NSL-KDD and CIC-IDS-2017 (0 % Byzantine clients, ϵ = 8, δ = 10−5).
| Acc.(%) | F1 | FPR(%) | DR(%) | Acc.(%) | F1 | FPR(%) | DR(%) | |
|---|---|---|---|---|---|---|---|---|
| Centralised oracle | 98.31 | 0.991 | 0.47 | 99.12 | 98.74 | 0.993 | 0.38 | 99.21 |
| FedAvg [3] | 96.45 | 0.971 | 1.23 | 97.04 | 96.11 | 0.968 | 1.41 | 96.72 |
| FedAvg + DP | 95.87 | 0.964 | 1.55 | 96.32 | 95.43 | 0.960 | 1.72 | 95.91 |
| Biscotti-style [10] | 96.02 | 0.966 | 1.38 | 96.51 | 95.78 | 0.963 | 1.58 | 96.10 |
| FLTrust [20] | 96.73 | 0.973 | 1.14 | 97.21 | 96.39 | 0.970 | 1.29 | 96.88 |
| BlockFedIDS (ours) | 97.14 | 0.984 | 0.91 | 97.63 | 96.88 | 0.975 | 1.02 | 97.31 |
Figure 3.
NSL-KDD accuracy vs. Byzantine client fraction under a label-flipping attack. BlockFedIDS retains >81% accuracy at 30% Byzantine clients, a 30.9pp gain over vanilla FedAvg.
Figure 4.
Privacy–utility trade-off on NSL-KDD.
Figure 5.
Training loss on NSL-KDD. FedAvg diverges under 20% Byzantine clients.
Table 4.
Blockchain performance vs. number of clients: hybrid (IPFS + on-chain hash) design vs. naive on-chain full-weight storage. TPS: committed transactions per second. Latency: time from gradient submission to ledger commit.
| Clients | Storage | TPS | Lat.(s) | Round(s) | KB/round |
|---|---|---|---|---|---|
| 5 | Hybrid (ours) | 312 | 0.64 | 18.2 | 1.2 |
| 5 | Naive on-chain | 5.1 | 40.2 | 1120 | 260 |
| 10 | Hybrid (ours) | 287 | 0.71 | 29.5 | 1.3 |
| 10 | Naive on-chain | 4.8 | 43.6 | 1780 | 260 |
| 15 | Hybrid (ours) | 261 | 0.79 | 38.7 | 1.3 |
| 15 | Naive on-chain | 4.5 | 46.1 | 2150 | 260 |
| 20 | Hybrid (ours) | 234 | 0.88 | 47.3 | 1.4 |
| 20 | Naive on-chain | 4.2 | 48.7 | 2520 | 260 |
| 25 | Hybrid (ours) | 198 | 1.04 | 58.9 | 1.4 |
| 25 | Naive on-chain | 3.9 | 52.3 | 3180 | 260 |
| 30 | Hybrid (ours) | 171 | 1.22 | 73.1 | 1.5 |
| 30 | Naive on-chain | 3.6 | 55.9 | 3830 | 260 |