Why does a curious aggregation server's reconstruction of a client's data degrade as that client's local batch grows?

## The setting A federation trains a shared model across clients — say a load-disaggregation model across household smart meters. Each round, a client receives the global weights, computes an update from its own consumption windows, and uploads it. The adversary is the aggregation server: honest-but-curious, holding the global model, reading updates as they arrive, wanting the training examples behind one of them. Its limit is that it sees the update and nothing else. The question is how much that limit costs it, and the answer is set almost entirely by three numbers the client's configuration chooses. ## Why batch size is the dominant one Start with the extreme. If the client's update came from a single example, the server has an observation of fixed, large dimension that was produced by one unknown input passed through a model it fully knows. It can propose a candidate input, compute what update that candidate would produce, and compare. The comparison is informative in every coordinate, so the search is heavily over-constrained and converges on something visually or numerically close to the real example. This is the case people demonstrate, and it is genuinely alarming. Now raise the batch. The uploaded update does not get bigger — it is still one parameter-shaped vector — but it is now a **sum over examples**, so: - **The unknowns multiply while the observation does not.** Recovering sixty-four windows from one vector is a far more underdetermined problem than recovering one, and many different batches produce nearly the same update. - **Contributions cancel.** Examples that push the model in opposing directions partly annihilate each other in the sum, so distinguishing features of individual rows are the first thing lost. - **What survives is the average.** Reconstructions from large batches tend to converge on a blend — plausible-looking but corresponding to no actual row, which is a much weaker disclosure. Empirically the curve is smooth: exact-looking recovery at a batch of one, degraded but semantically meaningful recovery for a handful, and mostly unusable output at the batch sizes ordinary training uses. Where exactly it breaks depends on the model, the data and how much prior knowledge the adversary can bring, which is why a red-team result must always report the batch size it was obtained at. ## Local steps: the second lever, often forgotten Most real federations do not upload a single gradient. The client runs several local steps — sometimes a full pass over its data — and uploads the difference between its final and initial weights. That changes the adversary's problem qualitatively, not just quantitatively. The observation is now the endpoint of a path through intermediate weight states the server never saw, each step taken on a different mini-batch in an order the server does not know. To invert it, the adversary must jointly guess the data and the entire trajectory. More local steps therefore reduce yield sharply, which is one reason a design that uploads after every single step is the worst case. ## Cohort aggregation: the same effect one level up Combining many clients' updates before anyone reads them makes the effective batch the union of all their examples. The mechanism is identical — more examples summed into one observation — which is why batch size, local steps and cohort size are best understood as one lever pulled at three places. ## What this does and does not establish The critical framing point: this is **degradation, not a guarantee**. A large batch makes reconstruction expensive and low-quality against the attack you ran. It does not bound what a better attack, or an adversary with a strong prior over household energy patterns, can recover — a strong prior partly substitutes for the missing constraints. Nor does it stop cheaper inferences: the structure of the final layer's update often reveals which target values or classes were present in the batch regardless of size, and that alone can be sensitive. If you need a statement that holds against attacks nobody has run yet, batch size cannot give it to you. Only bounding each example's contribution and adding noise calibrated to that bound produces a stated privacy claim, and it charges accuracy for it — mostly on the clients whose behaviour is unusual, which in an energy federation means exactly the households that differ from the population. ## How to talk about it in an interview Say what the observation is, say what the unknowns are, and note that the ratio between them is the whole story. Then add the caveat that separates a middle answer from a good one: the curve is smooth, adversary-dependent, and produces a cost, not a boundary.