A Survey on Decentralized Federated Learning

This survey systematically reviews decentralized federated learning methods from 2018 to early 2026, categorizing them into traditional distributed and blockchain-based architectures, proposing a unified challenge-driven taxonomy, and outlining future research directions to address security, privacy, and system-level trade-offs in coordinator-free settings.

The Gist

Imagine you are trying to teach a giant, super-smart robot how to recognize cats, but you have a problem: you can't show the robot the actual photos.

Why? Because those photos are private. They are on your phone, your neighbor's laptop, and your friend's tablet. Laws (like GDPR) and privacy concerns say, "Don't move those photos to a central computer."

The Old Way: The "Classroom" Model (Standard Federated Learning)

In the traditional method, called Federated Learning (FL), imagine a teacher (the central server) standing at the front of a classroom.

1. The teacher sends a blank notebook to every student.
2. Each student studies their own private photos at their desk.
3. They write down what they learned (not the photos themselves) and hand it back to the teacher.
4. The teacher combines all the notes into one "Master Notebook" and sends it back out.

The Problem: The teacher is a single point of failure. If the teacher gets sick, the class stops. Also, the teacher sees everyone's notes, so if the teacher is a spy or gets hacked, everyone's privacy is at risk. Plus, if 1,000 students try to talk to the teacher at once, the teacher gets overwhelmed.

The New Way: The "Potluck" Model (Decentralized Federated Learning - DFL)

This paper is a massive review of a new idea: What if we get rid of the teacher entirely?

In Decentralized Federated Learning (DFL), there is no head teacher. Instead, the students sit in a circle (or a complex web) and talk only to their neighbors.

1. You study your own photos.
2. You whisper what you learned to the person sitting next to you.
3. They mix your notes with theirs and whisper the result to their neighbor.
4. The knowledge ripples through the whole room until everyone has a good idea of what a cat looks like.

This paper is a survey (a giant map) of all the different ways researchers have tried to build this "teacher-less" system between 2018 and early 2026.

---

The Two Main Schools of Thought

The authors found that researchers are trying to solve this "Potluck" problem in two very different ways:

1. The "Neighborhood Watch" Approach (Traditional Distributed FL)

This group uses standard computer networking tricks. They treat the devices like a group of friends passing notes around.

• How it works: Devices talk directly to each other. If one friend leaves the room (disconnects), the others just talk to the remaining friends.
• The Good: It's fast, lightweight, and doesn't need expensive technology.
• The Bad: It can get messy. If the group is huge, passing notes takes forever. If one friend is lying (a hacker), they can poison the whole group's notes.

2. The "Digital Ledger" Approach (Blockchain-based FL)

This group uses Blockchain (the same tech behind Bitcoin) to act as a public, unchangeable record book.

• How it works: Every time someone learns something, they write it in a public ledger that everyone can see but no one can erase. It's like a "Trustless" system where you don't need to trust your neighbor; you just trust the math of the ledger.
• The Good: It's very secure and transparent. You can prove exactly who contributed what.
• The Bad: It's slow and expensive. Writing in a public ledger takes a lot of energy and time. The authors noticed that while this was popular a few years ago, researchers are moving away from it because it's often too heavy for the job.

---

The Big Hurdles (The "Gotchas")

The paper explains that removing the teacher creates new headaches:

• The "Echo Chamber" Problem (Data Heterogeneity):
  Imagine one student only sees pictures of black cats and another only sees orange cats. If they only talk to each other, they might both think "all cats are orange" or "all cats are black." In a decentralized system, it's hard to make sure everyone agrees on what a "real" cat looks like without a teacher to balance the scales.

• The "Liar in the Crowd" Problem (Security):
  In a classroom, the teacher can spot a student cheating. In a circle of friends, a malicious neighbor can whisper fake notes to everyone. If they are clever enough, they can trick the whole group into learning the wrong thing.

• The "Free Rider" Problem (Incentives):
  Why should your phone work hard to learn for the group if it drains your battery? In the old system, Google might give you a better keyboard as a reward. In the new system, who pays you? The paper notes that we don't have a great answer for how to reward people fairly without a central boss.

• The "Traffic Jam" Problem (Bandwidth):
  If everyone talks to everyone, the network gets clogged. It's like a party where everyone is shouting at once. Researchers are trying to figure out how to whisper efficiently so the message gets through without the whole room exploding.

---

What's Next? (The Future)

The authors conclude that while we have made great progress, we still need to figure out:

1. Better Security: How do we stop hackers who are trying to trick the system, especially when there's no teacher to catch them?
2. Fair Rewards: How do we make sure people want to participate without a boss telling them to?
3. Real-World Chaos: Most tests are done in perfect labs. We need to see how this works when phones die, internet connections drop, and people move around (like in a city).

The Bottom Line

This paper is a guidebook for the future of AI. It tells us that while getting rid of the "Big Brother" server is a great idea for privacy and reliability, it turns a simple classroom lesson into a complex, chaotic, and fascinating game of "telephone" that we are still learning how to play perfectly.

Technical Summary

Here is a detailed technical summary of the survey paper "A Survey on Decentralized Federated Learning" by Gabrielli et al.

1. Problem Statement

Standard Federated Learning (FL) relies on a central server to orchestrate training, aggregate model updates, and manage client selection. While this preserves data privacy by keeping raw data local, it introduces critical systemic vulnerabilities:

• Single Point of Failure (SPOF): If the central server crashes, the entire system halts.
• Trust and Security Concentration: The server holds a complete view of all local model updates, making it a prime target for model inversion, membership inference, and data reconstruction attacks. It also acts as a single point for model poisoning.
• Scalability and Latency: Coordinating millions of devices through a single server creates bandwidth bottlenecks and high latency.
• Privacy Regulations: Centralized data aggregation often conflicts with strict regulations like GDPR and HIPAA.

Decentralized Federated Learning (DFL) addresses these issues by removing the central coordinator. In DFL, nodes (peers) communicate directly in a peer-to-peer (P2P) fashion, training locally and aggregating updates from neighbors. However, this shift introduces new challenges:

• Topology Dependence: Learning dynamics depend heavily on the network structure.
• Heterogeneity: Handling non-IID (non-independent and identically distributed) data without a central harmonizer.
• Security & Incentives: Peers must defend against malicious neighbors and incentivize honest participation without a trusted third party.

2. Methodology

The authors conducted a Systematic Literature Review (SLR) following the PRISMA (Preferred Reporting Items for Systematic Reviews and Meta-Analyses) guidelines.

• Scope: Literature from 2018 to early 2026.
• Search Strategy: Queries were performed across IEEE Xplore, ScienceDirect, ACM Digital Library, and Google Scholar using Boolean logic.
• Selection Criteria:
  • Inclusion: Papers must explicitly address the removal of the central coordinator, delegate aggregation to peers, and propose architectural or algorithmic novelties.
  • Exclusion: Papers focusing solely on server-side improvements (e.g., compression in standard FL) or hybrid systems that retain a central orchestrator were excluded.
• Process: From an initial pool of 123 articles, duplicates were removed, followed by title/abstract screening and full-text review. 35 articles were selected for the final analysis.
• Data Extraction: The authors extracted details on datasets, model architectures, partitioning methods (horizontal/vertical), and the specific challenges addressed (fault tolerance, privacy, incentives, etc.).

3. Key Contributions

The paper makes four primary contributions:

1. Unified, Challenge-Driven Taxonomy: Unlike previous surveys that focus on specific axes (e.g., only security or only blockchain), this paper proposes a unified taxonomy that categorizes DFL works based on the core bottlenecks they address. It maps two architectural families to these challenges:
   • Traditional Distributed FL (TD-FL): Uses standard P2P distributed computing techniques.
   • Blockchain-based FL (BC-FL): Utilizes blockchain ledgers for coordination, auditability, and incentives.
2. Comprehensive Landscape Analysis: The survey covers the evolution of the field, noting a shift where BC-FL proposals were concentrated between 2019–2022, while TD-FL has seen sustained growth (2023–2025) focusing on lighter-weight P2P coordination, heterogeneity handling, and theoretical guarantees.
3. Evaluation Gap Identification: The authors analyze prevailing evaluation practices, highlighting a heavy reliance on small, clean benchmarks (MNIST, CIFAR) and horizontal partitioning. They expose a lack of realistic testing for heterogeneous, resource-constrained, and dynamic network environments.
4. Future Research Directions: The paper outlines critical open problems, including topology-aware threat models, privacy notions specific to decentralized exposure, and incentive mechanisms robust to manipulation.

4. Results and Findings

The survey organizes 35 representative works into specific challenge categories:

A. Traditional Distributed FL (TD-FL)

• Fault Tolerance: Works like IPLS and DSpodFL use P2P dissemination layers and neighbor-based aggregation to handle node churn and intermittent links without a coordinator.
• Privacy & Security:
  • ProxyFL uses a public proxy model to hide private model details.
  • ERIS and f-Differential Privacy employ gradient partitioning and decentralized noise injection to limit information leakage.
  • Trusted DFL and BALANCE use local trust scores and similarity checks to filter malicious updates.
• Bandwidth Utilization: Combo and GossipFL reduce communication overhead via model segmentation, sparsification, and gossip protocols.
• Data Heterogeneity: Def-KT and PANM mitigate "client drift" (divergence due to non-IID data) by using knowledge transfer and adaptive neighbor selection (clustering similar peers).
• Theory: Works like FDFL and NTK-DFL provide theoretical bounds on convergence and statistical inference for decentralized settings.

B. Blockchain-based FL (BC-FL)

• Coordination & Auditability: Systems like FED-BC and GFL use smart contracts and ring topologies to replace the server, providing tamper-evident logs of training rounds.
• Privacy: DeepChain and Biscotti use encryption (Paillier) and secure aggregation (secret sharing) to protect updates while maintaining ledger transparency.
• Security: BytoChain and PIRATE implement consensus mechanisms (Proof-of-Accuracy, BFT) and committee-based validation to filter poisoned updates.
• Incentives: BlockFL and FedCoin use blockchain tokens to reward participants based on data volume or Shapley values (marginal contribution).
• Resource Efficiency: BAFL and BLADE-FL co-design the learning loop with block generation rates to minimize latency and energy consumption.

Key Observation: The survey finds that while BC-FL offers strong auditability and incentive mechanisms, it often introduces significant overhead (latency, storage, energy). Consequently, recent research has shifted toward TD-FL for solving core system bottlenecks (heterogeneity, bandwidth), treating blockchain as an optional component for specific needs (auditability) rather than a default substrate.

5. Significance and Future Directions

This survey is significant because it moves beyond a simple catalog of algorithms to provide a systematic mapping of the DFL design space. It clarifies that "decentralization" is not a monolithic solution but a trade-off space involving topology, trust, and efficiency.

Critical Future Directions Identified:

1. Topology-Aware Threat Models: Security defenses must account for the fact that a node's neighbors might be colluding, and local validation sets may be biased.
2. Decentralized Privacy Notions: Privacy metrics must reflect the reality that in DFL, updates are exposed to multiple peers over time, not just a single server.
3. Robust Incentive Mechanisms: Current incentives often rely on self-reported data. Future work needs mechanisms that are robust to manipulation and compatible with privacy constraints.
4. Redefining the "Global Model": In highly decentralized, churn-prone networks, a single global model may be unachievable. Research should explicitly define objectives: is the goal a global consensus, cluster-specific models, or personalized solutions?
5. Realistic Evaluation: The field needs standardized benchmarks that include dynamic topologies, realistic non-IID data distributions, and resource constraints to move from theoretical protocols to robust deployments.

In conclusion, the paper argues that while DFL solves the SPOF and trust issues of standard FL, it requires a fundamental rethinking of system design, security assumptions, and evaluation metrics to be viable in real-world, large-scale applications.