DP2Guard: Privacy-Preserving FL for IIoT

• DP2Guard is a lightweight, privacy-preserving federated learning framework designed for Industrial IoT with a dual-server and blockchain architecture.
• It integrates gradient masking, hybrid poisoning detection using SVD and cosine similarity, and trust score–based adaptive aggregation to safeguard data and counteract malicious updates.
• Experimental evaluations on MNIST and Fashion-MNIST demonstrate robust convergence and enhanced resilience under various poisoning attacks in both IID and non-IID settings.

DP2Guard is a privacy-preserving federated learning framework for Industrial IoT that combines lightweight gradient masking, hybrid poisoning detection, trust score–based adaptive aggregation, and blockchain-backed auditability within a dual-server architecture. It is designed to address two problems emphasized in privacy-preserving federated learning: local gradient updates can leak sensitive information even when raw data never leaves the device, and malicious clients can submit poisoned updates that degrade or manipulate the global model. The framework is presented as a lightweight alternative to homomorphic encryption and secure multi-party computation in resource-constrained IIoT settings, while also targeting robustness against adaptive model poisoning attacks (Han et al., 22 Jul 2025).

1. Definition and design objectives

DP2Guard is described as a lightweight, privacy-preserving, and Byzantine-robust federated learning framework for Industrial IoT. Its stated purpose is to let edge devices collaboratively train a global model without exposing raw data and while resisting model poisoning. The paper identifies two central shortcomings in prior privacy-preserving federated learning schemes: reliance on heavyweight encryption techniques produces substantial communication and computation overhead, and single-strategy poisoning defenses often fail against adaptive adversaries (Han et al., 22 Jul 2025).

The framework therefore combines four components. The first is a lightweight gradient masking mechanism that replaces heavier cryptographic protection for local updates. The second is a hybrid defense strategy that uses singular value decomposition and cosine similarity to characterize uploaded gradients. The third is a trust score–based adaptive aggregation scheme that uses historical behavior to adjust client influence over time. The fourth is a blockchain layer that records aggregated results and trust information for tamper resistance and auditability.

The IIoT setting is central to the method’s motivation. The paper emphasizes that devices in such environments are often resource-constrained and operate under reliability and latency constraints. This suggests that DP2Guard is intended as a systems compromise: lighter than HE- or SMPC-centered privacy-preserving federated learning, but more robust than defenses based on a single anomaly score. A plausible implication is that its design priorities are shaped as much by deployment constraints as by threat modeling.

2. System model, architecture, and threat assumptions

DP2Guard uses a dual-server plus blockchain architecture. The main entities are clients or edge devices $E_i$, two servers $S_1$ and $S_2$, a consortium blockchain, and a task publisher. The publisher initializes the task by defining the initial global model $\mathbf{w}^{(0)}$ and publishing it to the blockchain. Clients download the current global model, train locally, compute gradients, and then participate in a privacy-preserving upload procedure (Han et al., 22 Jul 2025).

At training round $t$, the local gradient is written as

$g_i^{(t)}=\nabla_\omega \mathcal{L}_i(\omega_t).$

The corresponding local model update is

$\omega_i^t=\omega_t-\eta g_i^{(t)},$

and equivalently

$\Delta_i^{(t)}=\omega_i^t-\omega_t.$

The two servers have different roles. Server $S_1$ receives one masked share from each client and performs mean-centering on that share. Server $S_2$ receives the complementary share, reconstructs centered gradients, runs anomaly detection, computes trust scores, and aggregates its own share. Blockchain stores the initial model, aggregated outputs, and trust-related information. The paper presents this ledger as an auditable and tamper-resistant record of the training process.

The threat model assumes that malicious clients may submit poisoned gradients and that the proportion of malicious clients is less than half. The two servers are modeled as curious-but-honest and are assumed to follow the protocol while trying to infer private information from what they receive. A critical assumption is that $S_1$0 and $S_1$1 do not collude. The blockchain is assumed to operate under a permissioned-chain BFT-style trust model with at least

$S_1$2

trustworthy nodes. The paper explicitly identifies non-collusion between the two servers as a limitation; collusion is not handled by the current design.

3. Privacy mechanism: additive splitting, masking, and centered reconstruction

The privacy mechanism begins by splitting each client gradient into two additive shares. For local gradient

$S_1$3

the client forms

$S_1$4

A random mask

$S_1$5

is then sampled, and the two masked shares are defined as

$S_1$6

The first masked share is sent to $S_1$7, and the second is sent to $S_1$8 (Han et al., 22 Jul 2025).

Each server performs mean-centering on its received share. At $S_1$9,

$S_2$0

At $S_2$1,

$S_2$2

Server $S_2$3 then reconstructs the centered gradient

$S_2$4

Expanding the reconstruction yields

$S_2$5

The paper states a formal privacy theorem for this mechanism: under the assumption that $S_2$6 and $S_2$7 do not collude, execution of DP2Guard does not leak information about the true local gradients $S_2$8 to either server individually. The proof is given by a hybrid argument comparing the real protocol view to an ideal execution with a trusted functionality, ending with the indistinguishability statement

$S_2$9

This privacy claim is specific. It is framed against individual semi-honest servers, not against colluding servers or fully malicious active deviations. That boundary is important for interpreting the framework’s guarantees.

4. Hybrid poisoning detection and trust-based aggregation

After reconstruction, server $\mathbf{w}^{(0)}$0 operates on centered gradients

$\mathbf{w}^{(0)}$1

These are stacked into

$\mathbf{w}^{(0)}$2

DP2Guard then performs singular value decomposition,

$\mathbf{w}^{(0)}$3

and uses the top right singular vector $\mathbf{w}^{(0)}$4 as the dominant direction for feature extraction (Han et al., 22 Jul 2025).

Each client receives an SVD-derived score

$\mathbf{w}^{(0)}$5

The algorithm box in the summary also gives a closely related form,

$\mathbf{w}^{(0)}$6

Both expressions play the same role in the description: they quantify how strongly a client’s centered gradient aligns with the dominant direction in the batch.

Directional consistency is measured through pairwise cosine similarity: $\mathbf{w}^{(0)}$7 Each client is assigned the median of its pairwise similarities,

$\mathbf{w}^{(0)}$8

These two statistics are fused into a feature vector

$\mathbf{w}^{(0)}$9

The paper describes the next stage as a clustering-based separation of benign and anomalous clients. The main text states that K-means clustering with predefined cluster number $t$0 is applied, and that the largest cluster is treated as benign. However, the algorithm box says Mean Shift clustering. This discrepancy is explicitly noted in the summary and is one of the paper’s reproducibility ambiguities. The surrounding prose more consistently describes the intended method as K-means with two clusters, but the inconsistency remains unresolved in the provided description.

Trust is then computed from distance to the benign centroid. For client $t$1 at round $t$2,

$t$3

and direct trust is defined as

$t$4

Historical trust is updated by exponential smoothing: $t$5 Aggregation weights are then normalized as

$t$6

This makes DP2Guard different from FedAvg and from hard-selection robust aggregators. It does not use uniform weighting, nor does it select a single subset once per round using one metric. Instead, it assigns continuous weights that depend on both current anomaly features and historical behavior. The paper presents this as a stronger response to adaptive attackers than single-strategy defenses.

5. Weighted masked aggregation and blockchain-backed auditability

Aggregation is performed separately on the two masked shares using the trust-derived weights. At $t$7,

$t$8

and at $t$9,

$g_i^{(t)}=\nabla_\omega \mathcal{L}_i(\omega_t).$0

When both are combined, the random masks cancel: $g_i^{(t)}=\nabla_\omega \mathcal{L}_i(\omega_t).$1 Thus the framework preserves exact weighted aggregation while keeping each individual server from seeing the full local gradient (Han et al., 22 Jul 2025).

Blockchain is used as a record-keeping and dissemination layer rather than as the numerical aggregation engine. The initial global model $g_i^{(t)}=\nabla_\omega \mathcal{L}_i(\omega_t).$2 is published on-chain. After trust-weighted aggregation at $g_i^{(t)}=\nabla_\omega \mathcal{L}_i(\omega_t).$3, the server publishes $g_i^{(t)}=\nabla_\omega \mathcal{L}_i(\omega_t).$4 and the trust weights $g_i^{(t)}=\nabla_\omega \mathcal{L}_i(\omega_t).$5 to the blockchain. Server $g_i^{(t)}=\nabla_\omega \mathcal{L}_i(\omega_t).$6 then retrieves these values, computes its own weighted share aggregate, and finishes reconstruction. Aggregated results and trust-related metadata are recorded to provide tamper resistance and auditability.

The blockchain component is therefore auxiliary but structurally important. It supports transparency and traceability in consortium-style settings, especially in industrial deployments spanning multiple administrative domains. At the same time, the paper does not provide a detailed latency or throughput study for the blockchain layer. This suggests that the blockchain is a governance mechanism in the current presentation, not the main performance focus.

6. Experimental results, overhead analysis, and limitations

DP2Guard is evaluated on MNIST and Fashion-MNIST using LeNet-5, with 50 clients, 300 global rounds, one local epoch per round, SGD with learning rate

$g_i^{(t)}=\nabla_\omega \mathcal{L}_i(\omega_t).$7

batch size 32, and both IID and non-IID partitions. The non-IID setting uses Dirichlet partitioning with

$g_i^{(t)}=\nabla_\omega \mathcal{L}_i(\omega_t).$8

The malicious-client ratio is varied over

$g_i^{(t)}=\nabla_\omega \mathcal{L}_i(\omega_t).$9

Baselines are Multi-Krum, DnC, FLTrust, and ShieldFL. Four poisoning attacks are considered: Label-Flipping, Fang, Min-Max, and Min-Sum (Han et al., 22 Jul 2025).

Under no attack, the paper reports that DP2Guard converges within about 50 rounds, while FedAvg and Multi-Krum need over 100 rounds to stabilize. Under attack, the strongest results are reported at 40% malicious clients. In IID settings, DP2Guard reaches 94.26% on MNIST and 79.4% on Fashion-MNIST under Fang attack, 95.5% and 79.97% under Min-Max, and 96.24% and 78.3% under Min-Sum. In non-IID settings, the reported results include 90.24% on MNIST and 68.91% on Fashion-MNIST under Min-Max, and 91.04% on MNIST and 72.6% on Fashion-MNIST under Min-Sum. The paper’s central empirical claim is that DP2Guard remains strong under adaptive attacks and non-IID data, where several baselines degrade sharply.

The framework also includes a complexity analysis. Client-side masking costs

$\omega_i^t=\omega_t-\eta g_i^{(t)},$0

in both computation and communication. Mean-centering and reconstruction cost

$\omega_i^t=\omega_t-\eta g_i^{(t)},$1

while the detection stage is dominated by SVD and pairwise similarities, reported as

$\omega_i^t=\omega_t-\eta g_i^{(t)},$2

and summarized elsewhere as

$\omega_i^t=\omega_t-\eta g_i^{(t)},$3

Trust updates cost

$\omega_i^t=\omega_t-\eta g_i^{(t)},$4

and weighted aggregation costs

$\omega_i^t=\omega_t-\eta g_i^{(t)},$5

This supports the paper’s positioning of DP2Guard as client-lightweight but leaves open the question of server-side scaling when both client count $\omega_i^t=\omega_t-\eta g_i^{(t)},$6 and gradient dimension $\omega_i^t=\omega_t-\eta g_i^{(t)},$7 are large.

Several limitations are explicit. The privacy guarantee fundamentally relies on the non-colluding two-server assumption; if $\omega_i^t=\omega_t-\eta g_i^{(t)},$8 and $\omega_i^t=\omega_t-\eta g_i^{(t)},$9 collude, the masking mechanism can fail. The paper provides a formal privacy theorem but does not provide an equally strong theorem for Byzantine robustness under specified attack models. It also does not provide a full ablation isolating the contributions of masking, SVD, cosine similarity, clustering, trust smoothing, and blockchain individually. Finally, the inconsistency between K-means in the main description and Mean Shift in the algorithm box is a notable methodological ambiguity.

These limitations do not negate the paper’s main contribution, but they bound its claims. The strongest evidence presented is that, within an industrial consortium setting that can support two non-colluding semi-honest servers, DP2Guard offers a concrete compromise between privacy, robustness, efficiency, and accountability.