Byzantine-resilient aggregation is better understood as a research note than as a standalone project. It is a technique layer that many decentralized federated learning systems need when peers may be unreliable, delayed or actively malicious.
The problem
In centralized FL, the server can apply a defense before producing the global model. In DFL, each node may aggregate updates from neighbors. That makes poisoning more subtle because influence is local, repeated and topology-dependent.
The practical question is: how can a node decide whether to accept, reduce or reject a peer update?
Defense families
Three families are especially useful as a baseline:
- median-based aggregation,
- trimmed mean,
- trust-weighted aggregation.
They are not perfect. Their value is that they are understandable, cheap enough for many settings and useful for comparing more advanced defenses.
Interpretability
In cyberdefense, a defense mechanism should be explainable to an operator or researcher. If an update is down-weighted, the system should expose why: distance from neighbors, historical trust, abnormal parameter shift, delay pattern or disagreement with local validation.
Robust aggregation is not just math. It is part of the trust layer of DFL.
Key takeaway
Byzantine-resilient aggregation should be evaluated as both a statistical defense and an operational trust mechanism. A peer update is not only accepted or rejected; it should leave an auditable reason for that decision.
Open research question
How can a peer explain why it reduced or rejected another peer's update without exposing sensitive local validation data or creating a new attack surface?
