Decentralized Federated Learning: A Survey on Security and Privacy

Ehsan Hallaji; Roozbeh Razavi-Far; Mehrdad Saif; Boyu Wang; Qiang Yang

Source-linked AI summary

Decentralized Federated Learning: A Survey on Security and Privacy

Ehsan Hallaji, Roozbeh Razavi-Far, Mehrdad Saif, Boyu Wang, Qiang Yang

arXiv:2401.17319v1Jan 25, 2024cs.CRcs.AIcs.LGstat.ML

TL;DR

Federated learning reduces direct data sharing but exposes model exchanges to attacks affecting performance and privacy. This survey analyzes threats, adversaries, defenses, trustability, and verifiability in decentralized federated learning, including blockchain-based designs. It concludes that DFL removes server dependence while introducing distinct security, privacy, and deployment challenges.

Problem
Model-update exchange creates attack surfaces, while centralized FL depends on a server whose compromise can jeopardize the federation.
Method
The survey reviews DFL threats and adversaries, analyzes defense mechanisms, and examines blockchain integration, trustability, and verifiability.
Results
The survey identifies DFL’s security benefits and analyzes attacks, defenses, and blockchain-related risks across the decentralized architecture.
Takeaways & Limitations
Removing the central server can improve federation reliability, but practical DFL defenses must address diverse threats and resource constraints.

Abstract

from arXiv · show

Federated learning has been rapidly evolving and gaining popularity in recent years due to its privacy-preserving features, among other advantages. Nevertheless, the exchange of model updates and gradients in this architecture provides new attack surfaces for malicious users of the network which may jeopardize the model performance and user and data privacy. For this reason, one of the main motivations for decentralized federated learning is to eliminate server-related threats by removing the server from the network and compensating for it through technologies such as blockchain. However, this advantage comes at the cost of challenging the system with new privacy threats. Thus, performing a thorough security analysis in this new paradigm is necessary. This survey studies possible variations of threats and adversaries in decentralized federated learning and overviews the potential defense mechanisms. Trustability and verifiability of decentralized federated learning are also considered in this study.

I. INTRODUCTION

Federated learning reduces privacy and communication burdens by sharing model parameters rather than user data, but centralized coordination remains vulnerable. This survey addresses the resulting decentralized federated learning attack surface by reviewing threats, defenses, and blockchain’s security and privacy effects.

Motivation: Privacy concerns and communication overhead are especially acute in large-scale systems that collect data from millions of users and edge devices.The paper frames privacy and network burden as joint challenges for modern intelligent systems.
Federated learning: Federated learning trains local models and shares model parameters with a central server, reducing direct data exposure and communication volume.The approach still depends on centralized aggregation and broadcasting.
Limitations of centralized FL: Centralized FL remains exposed to parameter sniffing, inference attacks, questionable server trust, and dependence on a single point of failure.These weaknesses motivate architectures that remove the central server.
Decentralized federated learning: DFL replaces centralized coordination with peer-to-peer or blockchain-based aggregation, improving reliability and scalability while introducing new trust and privacy concerns.Aggregator selection and aggregation functions vary across DFL architectures.
Survey scope: The survey reviews robust DFL methods, identifies threats, analyzes defenses, and studies blockchain integration’s effects on DFL security and privacy.Its stated contributions span methods, attacks, countermeasures, and blockchain-related effects.

II. BACKGROUND

The background distinguishes DFL from federated learning and introduces blockchain as a possible coordination infrastructure. It emphasizes decentralized data exchange, traceability, consensus, and the resulting architectural variants.

DFL fundamentals: DFL can combine federated learning with blockchain, but it can also operate independently of blockchain.The distinction motivates separate treatment of FL and blockchain fundamentals.
DFL fundamentals: Unlike centralized FL, DFL distributes verification, aggregation, and update broadcasting across client networks rather than relying on a central server.This changes how participant coordination and model aggregation are performed.
Blockchain: Blockchain stores decentralized data in linked blocks whose hashes support traceability and make tampering more difficult.Each block contains data, a unique hash, and a pointer to the previous hash.
Blockchain: Blockchain consensus seeks shared verification without allowing one participant to control the network, but fair evaluator assignment remains an open problem.Proof of Work and Proof of Stake are identified as common consensus mechanisms.
Blockchain: Blockchain networks are categorized as public, private, consortium, or hybrid according to participation and storage or construction arrangements.The categories differ in permissioning, governance, and where block construction or storage occurs.

III. DECENTRALIZED FEDERATED LEARNING

DFL removes dependence on a central server by using peer-to-peer communication and, often, blockchain for model-update exchange and aggregation. The survey traces DFL architectures and methods while noting that blockchain introduces communication delays and resource demands.

III. DECENTRALIZED FEDERATED LEARNING: DFL replaces the central server with peer-to-peer communication so model aggregation and participant verification can occur serverlessly.Blockchain can facilitate inter-node communication by treating model updates as block data governed by consensus.
III. DECENTRALIZED FEDERATED LEARNING: Blockchain-based DFL architectures differ in block structure, headers, aggregation, and consensus mechanisms.A generic design initializes the chain with a global model and adds each client update as a linked block.
III. DECENTRALIZED FEDERATED LEARNING: Research extensions target efficiency, security, privacy, fairness, authentication, reputation management, and malicious-node penalties.Examples include smart contracts, gossip learning, differential privacy, lattice-based cryptography, reputation schemes, and monetary penalties.
III. DECENTRALIZED FEDERATED LEARNING: Results reported in the reviewed literature indicate an overall improvement over centralized FL.
III. DECENTRALIZED FEDERATED LEARNING: Blockchain integration can make aggregation and consensus impractical when edge devices lack sufficient computational resources.Communication delay and resource consumption are especially problematic for mechanisms such as proof of work.

IV. THREATS TO DECENTRALIZED FEDERATED LEARNING

DFL threats target privacy, model performance, and blockchain operation, involving malicious clients, data or model poisoning, communication disruption, and privacy poisoning. Blockchain removes a single server target but creates additional attack surfaces and legal risks.

IV. THREATS TO DECENTRALIZED FEDERATED LEARNING: DFL threats generally affect privacy, global-model performance, or blockchain operation, while malicious clients may act semi-honestly or aggressively.Aggressive attacks can target the whole model or a specific class.
IV. THREATS TO DECENTRALIZED FEDERATED LEARNING: Poisoning attacks corrupt training data or updates, whereas blockchain-specific attacks exploit the infrastructure supporting DFL.The surveyed categories include data poisoning, communication disruption, backdoors, and privacy poisoning.
IV. THREATS TO DECENTRALIZED FEDERATED LEARNING: DDoS attacks can delay valid updates by filling blockchain capacity with spam transactions despite the absence of a single point of failure.
IV. THREATS TO DECENTRALIZED FEDERATED LEARNING: Backdoor attacks inject triggers into local models so poisoned parameters propagate to other DFL participants.Reported mechanisms include label flipping and pixel-patch backdoors.
IV. THREATS TO DECENTRALIZED FEDERATED LEARNING: Privacy poisoning can insert personal data into immutable blockchain records, potentially making the DFL system legally non-compliant.The passage identifies regional data-protection law as a relevant constraint.

2) Model Poisoning:

Model poisoning manipulates training objectives or gradients to degrade the shared DFL model, while blockchain connectivity and consensus mechanisms introduce additional operational and consensus risks.

2) Model Poisoning:: Model poisoning maliciously controls global training by changing local objectives or injecting deviating gradients without necessarily altering training data.
2) Model Poisoning:: Byzantine nodes can inject deviating gradients or Gaussian noise into the blockchain to degrade the shared DFL model.
2) Model Poisoning:: Breached service-provider networks can tamper with packet routing because blockchain does not control the network layer.Such tampering can discard transferred information.
2) Model Poisoning:: 51% and Sybil attacks seek majority approval or influence over consensus by controlling nodes or creating multiple fake identities.
2) Model Poisoning:: The survey evaluates DFL attacks by ease of implementation, effectiveness, and defense feasibility.

2) Membership Inference Attacks:

DFL clients can expose private information through observed updates and gradients, enabling membership inference and other attacks. The survey also catalogs implementation difficulty and blockchain-related attack characteristics relevant to defense planning.

2) Membership Inference Attacks:: Membership inference attacks use client updates or leaked gradients to infer record-level information about local datasets.
2) Membership Inference Attacks:: Smart-contract coding vulnerabilities can allow attackers to manipulate contract contents or gain unauthorized access to associated assets.The survey emphasizes code review and rigorous testing as safeguards.
2) Membership Inference Attacks:: Backdoor, denial-of-service, and gradient-manipulation attacks differ substantially in implementation difficulty.Backdoors and gradient manipulation require extensive system knowledge, whereas denial-of-service attacks are comparatively less complicated.

2) Effectiveness of Attacks:

DFL attacks vary substantially in effectiveness: backdoor, membership inference, and blockchain-targeting attacks are classified as high, while several model and availability attacks are moderate. Backdoor attacks are difficult to detect and mitigate, whereas defenses for other attacks range from moderate to challenging.

Backdoor, membership inference, and blockchain-targeting attacks are classified as highly effective, threatening model integrity, privacy, or system trust.Blockchain-targeting attacks include private-key hijacking, 51% attacks, consensus attacks, Sybil attacks, double spending, and routing attacks.
Gradient manipulation, training-objective manipulation, evasion, model inversion, and DoS/DDoS attacks have moderate effectiveness.Their impact depends on system robustness, deployed defenses, and whether attacks alter model parameters or primarily disrupt operation.
Backdoor attacks require advanced detection and rigorous model verification because malicious behavior can be embedded in training data or models.
Membership inference attacks are challenging to defend against, while DoS/DDoS, gradient manipulation, training-objective manipulation, evasion, and model inversion are moderately defensible.Listed defenses include anomaly detection, differential privacy, secure aggregation, robust aggregation, secure communication, and secure multiparty computation.
Blockchain attacks such as private-key hijacking, 51% attacks, and double spending are difficult to defend against because they exploit blockchain infrastructure vulnerabilities.Robust consensus, multifactor authentication, and encryption can improve defensibility against these attacks.

V. DEFENSE MECHANISMS

The survey organizes DFL defenses around homomorphic encryption, secure multiparty computation, and differential privacy, while summarizing their applicability to privacy and performance threats. These mechanisms protect computations or updates but introduce communication, processing, or model-quality trade-offs.

DFL defense mechanisms are reviewed for privacy and performance threats and summarized by characteristics, applicability, and use across state-of-the-art methods.
The surveyed privacy-preserving defenses primarily comprise homomorphic encryption, secure multiparty computation, and differential privacy.
1) Homomorphic Encryption: Homomorphic encryption enables arithmetic on ciphertext without decryption, but fully homomorphic encryption is more flexible and less efficient than restricted variants.Partial homomorphic encryption supports one operation, whereas substantial homomorphic encryption supports several operations with restricted additions and multiplications.
1) Homomorphic Encryption: Homomorphic encryption increases memory and processing costs, creating a utility–privacy trade-off when encrypted computation and nonlinear model estimation are required.
2) Secure Multiparty Computation: Secure multiparty computation protects participant data by distributing random values for local function computation, but large-scale DFL can incur substantial communication and processing costs.The resulting function outputs are averaged to obtain the desired estimation.

3) Differential Privacy:

Differential privacy protects DFL updates by adding noise and can address privacy and some poisoning threats without the computational burden of homomorphic encryption or secure multiparty computation. Its trade-offs include degraded model quality and cumulative privacy loss, motivating distributed and hybrid approaches.

Differential privacy injects random noise into updates to make data interpretation difficult and can protect against inference and gradient-based data-poisoning attacks.
Differential privacy has lower computational cost than homomorphic encryption and secure multiparty computation, but injected noise can deteriorate model quality.
Iterative training can accumulate privacy loss in conventional differential privacy, motivating subsampling and privacy amplification by iteration.These approaches aim to mitigate cumulative privacy loss and improve privacy guarantees while preserving model utility.
Hybrid defenses combine differential privacy with other mechanisms to balance privacy, utility, trust, and system costs.One described approach combines secure multiparty computation with differential privacy to offset excessive noise as client numbers grow.
Differential privacy is applied at user or instance level, with user-level privacy also protecting whether a client participated in training.
Distributed and local differential privacy fit DFL because they do not require trusting a server, unlike centralized differential privacy.In local differential privacy, participants add noise to estimated gradients before sharing them over the blockchain.

1) Anomaly Detection:

DFL anomaly detection extends centralized-FL defenses to fraudulent transactions and blockchain changes, but remains less studied. Reviewed mechanisms address poisoning, Sybil groups, privacy, and backdoors while introducing computational and implementation trade-offs.

DFL anomaly detection must address both malicious model updates and anomalies arising from fraudulent transactions or blockchain changes.
Multi-KRUM detects poisoning attacks, while FoolsGold identifies Sybil groups coordinating malicious activity.
Pruning can complicate backdoor injection by removing inactive neurons, but DFL research on pruning remains limited.
TEEs can hide local model parameters and secure blockchain smart-contract data, but limited memory restricts the model portion they protect.
Zero-knowledge proofs can verify training features without data exchange and generally maintain performance across data volumes, but require further implementation research.
Zero-knowledge proofs introduce computational overhead, implementation complexity, scalability concerns, and setup-phase trust assumptions.

6) Knowledge Distillation:

Knowledge distillation transfers behavior from a large teacher to a compact student model and can strengthen resistance to some attacks. However, distillation alone may not directly address backdoors, which require broader defenses.

Knowledge distillation transfers knowledge from a large teacher model to a compact student without significantly sacrificing performance.
Smaller distilled models have fewer parameters and are less susceptible to overfitting, making reverse-engineering or manipulation more difficult.
Knowledge distillation alone may not directly counter backdoors because attackers modify training data or parameters to embed hidden triggers.
Regularization methods such as L2 regularization and dropout can reduce the effects of malicious samples that promote overfitting and membership inference.
Verifiable DFL complements post-attack defenses by checking whether clients performed tasks without compromising privacy and by filtering malicious participants.
Worker-based verification evaluates submitted updates before aggregation, while proof-of-correctness schemes use selected workers and reliability information.

B. Trustable DFL Workers

Trustable DFL workers require defenses against unreliable aggregation, privacy-preserving computation, and resource constraints. The survey emphasizes that diverse threats and continuing evaluation complicate practical deployment.

B. Trustable DFL Workers: Even trustworthy trainers cannot guarantee a secure aggregate when the worker responsible for aggregation is unreliable.
B. Trustable DFL Workers: Privacy-preserving techniques trade computational burden and possible accuracy loss for stronger privacy, while cryptographic implementations can introduce security holes if poorly configured.
B. Trustable DFL Workers: DFL defenses often require extra computational power, which may be infeasible in resource-constrained environments such as mobile networks.
B. Trustable DFL Workers: Different threats require different countermeasures, making comprehensive defense design complex across varied threat models.
B. Trustable DFL Workers: Blockchain deployments add resource and computational constraints, making defense scalability and efficient smart-contract execution critical.
B. Trustable DFL Workers: Continuous evaluation, benchmarking, and improvement are needed because threats and technologies evolve.

C. Blockchain-Related Security Issues

Blockchain integration removes the server and improves communication, but introduces infrastructure, privacy, heterogeneity, and trust-evaluation challenges. The survey identifies stronger blockchain designs and privacy-preserving verification as continuing needs.

C. Blockchain-Related Security Issues: Blockchain-targeting cyberattacks can manipulate infrastructure and compromise DFL integrity, reliability, confidentiality, and participant privacy.
C. Blockchain-Related Security Issues: Improved consensus mechanisms, cryptographic protocols, and smart-contract designs are proposed to strengthen the blockchain layer.
C. Blockchain-Related Security Issues: Heterogeneous computation power and connectivity can delay aggregation and reduce DFL efficiency.
C. Blockchain-Related Security Issues: Asynchronous DFL makes secure aggregation difficult because existing protocols require all clients to participate in aggregation.
C. Blockchain-Related Security Issues: Trust evaluation of joining parties can exhaust computational and communication resources when privacy prevents direct information disclosure.
C. Blockchain-Related Security Issues: SMC, HE, and behavioral anomaly detection can support privacy-preserving trust evaluation and identify client misbehavior over time.
C. Blockchain-Related Security Issues: Blockchain-backed DFL eliminates the server and can improve communication while removing a single point of failure.