← 목록

Federated Learning, Practically: The Protocol and What It Does Not Protect

devto 2026-08-08 원문 보기 ↗

Federated learning trains a shared model across many devices without collecting their data on a server. That is a real and useful property. It is also routinely stated as though it were three properties, and the other two — that the server learns nothing about individuals, and that the resulting model cannot leak training data — are not true unless you add machinery that costs something.

The protocol, step by step

The canonical algorithm is federated averaging. One round looks like this:

  1. The server selects a cohort of eligible clients — typically devices that are charging, idle and on an unmetered connection, because training is expensive and users must not notice.
  2. The server sends each selected client the current global model parameters.
  3. Each client trains locally for a small number of steps on its own data, producing updated parameters. The data never moves.
  4. Each client sends back the difference between its updated parameters and the ones it received — the update, not the data and not the full model.
  5. The server averages the updates, typically weighted by how many local examples each client trained on, and applies the average to the global model.
  6. Repeat, for hundreds or thousands of rounds. 
w_global(t+1) = w_global(t) + Σ_k ( n_k / N ) · Δw_k

  Δw_k  the update computed by client k
  n_k   examples client k trained on
  N     total examples across the cohort

Notice what determines the quality of that average: which clients were selected, how representative their data is, and how far each was allowed to drift locally before reporting. Those three are the engineering substance of federated learning, and they are where it diverges hardest from ordinary training.

The claim, and the three things it is not

“The data never leaves the device” is true and is a meaningfully different posture from collecting it. Three claims often packaged with it are separate and must be argued separately:

Secure aggregation: what it adds

Secure aggregation is a cryptographic protocol that lets a server compute the sum of many clients’ updates without seeing any individual update. The usual construction has clients agree pairwise on random masks: each client adds a mask for every other client, with the sign arranged so that when all the masked updates are summed, the masks cancel exactly.

client i sends:  Δw_i  +  Σ_{j > i} m_ij  −  Σ_{j < i} m_ji

summing over all clients, every m_ij appears once with each sign:

  Σ_i (masked update)  =  Σ_i Δw_i

The server sees only the total. Any single masked update is
indistinguishable from random.

The guarantee it provides is precise and narrow: the server sees the sum, not the terms. Its limitations are equally precise:

What still leaks

Three attack families are worth knowing by name, because they define the boundary of what the protocol delivers.

Gradient inversion

Given a model and a gradient computed on a small batch, an attacker can optimise for an input that would have produced that gradient — and recover recognisable training examples. Zhu, Liu and Han’s “Deep Leakage from Gradients” (NeurIPS 2019) demonstrated this directly, and a substantial literature has followed. The attack is hardest against large batches and many local steps, and easiest against a single example. Secure aggregation blocks it by denying the attacker any individual gradient, which is exactly why it is not optional.

Membership inference on the final model

Given the trained model and a candidate record, an attacker asks whether that record was in the training set — typically by exploiting that models are more confident on data they were trained on. Federation does nothing about this. The defence is differential privacy applied to training, and nothing else is a defence.

Poisoning, in the other direction

Federated learning inverts the usual trust relationship: you are training on data you cannot inspect, supplied by clients you do not control. A minority of malicious clients can steer the global model or insert a backdoor. Mitigations exist — update clipping, robust aggregation rules that discard outliers — and they trade off directly against the ability to learn from genuinely unusual but honest clients. There is no setting that gets both.

The deployment costs nobody mentions

This is the section that decides most projects, and it is missing from almost every introduction.

When it is actually the right choice

The conditions under which the costs are worth paying are narrow and identifiable:

Related