A Survey on Decentralized Federated Learning

In plain words

Federated learning lets many devices train one model together while their data stays on each device. Usually a central server collects the model updates and combines them. That server is a single point of failure and a point of trust.

This survey looks at the variant with no central server: devices pass updates directly to their neighbours, or record them on a shared ledger (a blockchain). The authors collected 35 papers on this idea, sorted them by the problem each one tries to solve, and listed what the field has not yet studied well. Their main worries are attacks by insiders, privacy when many peers can see each update, and what happens when devices drop out or the network splits.

TL;DR

• A systematic review (PRISMA) of 35 papers on decentralized federated learning (DFL), published from 2018 to early 2026 §3.2 fig. 2.
• Two families: traditional peer-to-peer methods (TD-FL, 23 works) and blockchain-based methods (BC-FL, 12 works) §5 tab. 2.
• Works are grouped by the challenge they mainly target. The paper runs no experiments of its own.
• Recurring gaps: topology-aware threat models, privacy notions that fit decentralized exposure, incentives robust to manipulation, and fault tolerance under churn. §6 §7

Problem

With a central server, one crash can stall training, and the server sees every client's model and can attack the system §1. Removing the server moves the burden to the peers. Peers must then handle heterogeneous devices, choose a topology that keeps bandwidth low, defend themselves, and be paid to take part §1. The paper also says a fully connected topology scales no better than standard FL §1.

The paper notes that prior DFL surveys did not follow a systematic review method, so their coverage may be biased §1.1. It asks four research questions: the problem framing, the taxonomy, how DFL is evaluated, and the open challenges §3.1.

Method

This is a literature review, not a learning method. The paper states the following steps §3.

1. Search. Four databases were searched (IEEE Xplore, ScienceDirect, ACM Digital Library, Google Scholar) for 2018 to early 2026 with Boolean queries. The query strings are not stated in the paper's text §3.2.
2. Screening. The paper applies inclusion criteria: the work addresses the centralized-orchestration problem, defines itself as decentralized, delegates aggregation to peers, and adds an architectural or algorithmic novelty §3.3.
3. Flow. 123 records were retrieved and 92 remained after duplicates were removed. Title and abstract screening excluded 36, leaving 56 for full-text review. Full-text review excluded 21, leaving 35 §3.2 fig. 2.
4. Extraction. For each of the 35 works the authors recorded: venue and year, datasets and federated settings, whether the implementation used standard distributed computing or blockchain, training algorithms, and metrics and limitations §3.4.
5. Taxonomy. The works are split into TD-FL and BC-FL §5. Within each family they are grouped by the challenge they mainly address §5.1 §5.2 and cross-tabulated against challenge columns tab. 2. A timeline of the works by year is in fig. 3.

The background gives the standard FL round the paper compares against. This is the description the paper uses, reproduced in our own words:

1. The server selects a subset of clients, sends them the current global model §2.1 (i).
2. Each selected client trains locally on its own data, starting from the global model, and sends back its result §2.1 (ii), eq. 3.
3. The server aggregates the received models with an aggregation function, by default the average (FedAvg) §2.1 (iii).

The global objective is a weighted sum of the clients' empirical risks eq. 1, eq. 2. Clients may send either full models or their updates relative to the global model; both forms are described §2.1.

A generic DFL round, as the paper's architecture figure describes it, has no server fig. 1b:

# Generic decentralized FL round  [fig. 1b] [§2.1]
# Input:  models[i] for each node i; neighbors[i]; local_data[i]
# Output: updated models[i] for each node i

def dfl_round(models, neighbors, local_data):
    # 1. Each node trains on its own private data  [fig. 1b]
    for node in nodes:
        models[node] = local_update(models[node], local_data[node])
    # 2. Each node sends its update to its neighbors only  [fig. 1b]
    received = exchange(models, neighbors)
    # 3. Each node aggregates what it received from neighbors  [fig. 1b]
    for node in nodes:
        models[node] = aggregate(models[node], received[node])
    return models

The paper does not give this as an algorithm; it is a summary of the three steps in the figure caption fig. 1.

Hyperparameters

Not applicable. The paper is a survey and runs no experiments of its own. It reports the experimental settings of the surveyed works (model family, partitioning, datasets) in tab. 3. Those settings are summarized below in Results.

Results

Author-reported review outcomes, not measured performance.

Taxonomy by challenge, as counted from the table's marks tab. 2:

• Fault tolerance: IPLS, DFL-UN, DSpodFL (TD-FL); FED-BC, GFL (BC-FL).
• Privacy: ProxyFL, PVD-FL, f-DP, ERIS (TD-FL); Privacy-Preserving FL for IoT, DeepChain, Biscotti (BC-FL).
• Security: Trusted DFL, BALANCE, BR-DFL, SelfishAttack (TD-FL); BytoChain, PIRATE, Trustworthy FL (BC-FL).
• Incentives: BlockFL, FedCoin (BC-FL) only.
• Bandwidth: Combo, GossipFL (TD-FL).
• Data heterogeneity: Def-KT, P2P FL over graphs, PANM, DeSA, NTK-DFL (TD-FL).
• Theory and task extensions: FDFL, BrainTorrent, Sharp Gaussian approximations, Statistical inference for DFL, Excalibur (TD-FL).
• Resource efficiency: BAFL, BLADE-FL (BC-FL).

Evaluation practice, from the surveyed works' settings tab. 3: nearly all use horizontal partitioning. Vertical partitioning appears in a few TD-FL works (IPLS, PVD-FL, Excalibur). Most evaluations use MNIST, Fashion-MNIST or CIFAR-style benchmarks. The paper says this suggests small, clean benchmarks rather than realistic deployments §5.

Paper vs code

No official code. The paper's LaTeX source contains no code, repository or project-page link. A GitHub repository search for "decentralized federated learning survey" returned no results (checked during compilation). Survey papers do not have an implementation to match.

Pitfalls

• Inconsistent challenge taxonomy. The introduction names eight challenge dimensions §1.1. The challenges section lists five groups §4. TD-FL is split into six groups §5.1, and BC-FL into four §5.2. Readers should not expect the same categories across sections.
• Inclusion criterion vs. one included work. Inclusion requires that aggregation be delegated to peers rather than a central entity §3.3. GossipFL is counted as TD-FL, but the paper itself states that its peer selection is coordinated by a central entity, which makes it hybrid §5.1.4.
• Search strings are missing. The Boolean queries are not reproduced in the live text; they survive only in commented-out source lines §3.2. The review cannot be repeated exactly from this paper.
• Timeline caption vs. figure. The caption of fig. 3 says BC-FL is concentrated in roughly 2019–2022 §5. The same figure places one BC-FL work in 2023.
• Table label mismatch. In tab. 3 the TD-FL group is labeled as spanning 22 rows, but it lists 23 works.
• Citation key mismatch. In fig. 4 DFL-UN is cited with a different key from the one used in tab. 2 and the text. The paper's figure key and table key refer to the same work by different bibliography keys, so check the reference before citing it.
• Unquantified scaling claim. The statement that full mesh communication costs O(n²) messages against O(n) for standard FL is the paper's own assertion, with no source given §4.2.
• Scope boundary. Server-based FL methods are excluded unless they run in a peer-to-peer or blockchain architecture §1. Methods such as compression or secure aggregation under a coordinator are therefore absent by design.
• Blockchain caveat. The paper argues that blockchain should be an optional component, justified by a concrete need such as auditability or incentive settlement, not a default §2.3. Its own reading of the surveyed BC-FL literature is that the ledger often shifts trust to miners or validators, creating a hierarchy like centralized FL §6.1 §6.3.

Lineage

• Surveys compared: Martínez Beltrán et al. (2023), Hallaji et al. (2024), Yuan et al. (2024), Zhang et al. (2024) §1.1 tab. 1. The paper says these surveys are axis-specific and did not use a systematic review method.
• Open problems carried forward: topology-aware threat models, strategic insider attacks, privacy in adversarial settings, incentives, fault tolerance under churn, and whether the goal is one global model or personalized models §6 §7.