Federated aggregation: dropout, contribution caps and privacy limits

Last updated: 6 Oct 20265 min read

tutorial

An aggregate should reflect an explicit participant set and contribution rule, with dropout and privacy limitations stated plainly.

Count who actually contributed

Invited clients are not accepted clients. A scanner may download the base model but disconnect before uploading an update, fail validation or arrive after the deadline. Report participation by stage and cohort. If aggregation uses example-count weighting, cap the reported count to prevent one client from dominating the round; the cap is an operational guard, not proof against malicious updates. Store accepted update IDs and the exact weighting rule with the aggregate. Round identity fixes the eligible base and deadline.

Handle partial rounds

Set a minimum number of accepted clients and a minimum cohort mix before aggregation. If the floor is missed, abort or extend under a new recorded deadline and reassess eligibility. Do not silently lower the floor because the model appears to improve on one central validation set. A region with more dropouts may be missing from that set. Keep a clear policy for whether stragglers enter the next round; their update must be retrained against its new base, never relabeled and reused. Cohort uncertainty matters after dropout.

Separate security properties

Secure aggregation can limit what the server learns from individual updates, but it does not establish that an aggregate is accurate, fair or free of harmful influence. Differential privacy requires a stated mechanism and accounting policy; it is not achieved by clipping alone. Keep authentication, transport security, access control and update validation as separate controls. Validate any privacy claim against the implemented protocol and threat model. Logging privacy also applies to per-device diagnostics and rejected-update records.

Evaluate the released model

After aggregation, test the candidate against the prior global artifact on independent holdouts, device classes and rare defect types. Run a small edge cohort with a reversible package and watch real-world failures before broad installation. A good aggregate metric can conceal harm to a site that rarely participated. The project aborts one low-participation round, then tests a revised round without claiming privacy properties its protocol did not implement.

Implementation

def aggregate_client_rates(updates, minimum_clients, contribution_cap):
    if minimum_clients <= 0 or contribution_cap <= 0:
        raise ValueError("invalid round policy")
    if len(updates) < minimum_clients:
        return {"state": "abort:participation", "rate": None}
    total_weight = 0
    weighted_rate = 0.0
    for update in updates:
        if not 0 <= update["local_error_rate"] <= 1 or update["examples"] <= 0:
            raise ValueError("invalid client metric")
        weight = min(update["examples"], contribution_cap)
        total_weight += weight
        weighted_rate += weight * update["local_error_rate"]
    return {"state": "review:aggregate", "rate": weighted_rate / total_weight}

updates = [{"examples": 47, "local_error_rate": 0.2},
           {"examples": 820, "local_error_rate": 0.1},
           {"examples": 39, "local_error_rate": 0.3}]
assert aggregate_client_rates(updates[:2], 3, 82)["state"] == "abort:participation"
assert aggregate_client_rates(updates, 3, 82)["state"] == "review:aggregate"

Performance and operating cost

The illustrative scalar aggregation is O(c) time and O(1) extra space for c clients. Real parameter aggregation costs O(cd) for d parameters per client and may require secure-aggregation communication overhead. The example aggregates reported error rates, not model weights; a production optimizer needs a separate reviewed algorithm and privacy accounting where claimed.

Common Mistakes

Counting invited devices as completed participants.
Letting one client claim an unlimited example count.
Treating secure aggregation as proof of model quality or full privacy.
Changing participation floors after seeing a candidate score.