Bristle: Decentralized Federated Learning in Byzantine, Non-i.i.d. Environments

Federated learning (FL) is a privacy-friendly type of machine learning where devices locally train a model on their private data and typically communicate model updates with a server. In decentralized FL (DFL), peers communicate model updates with each other instead. However, DFL is challenging since (1) the training data possessed by different peers is often non-i.i.d. (i.e., distributed differently between the peers) and (2) malicious, or Byzantine, attackers can share arbitrary model updates with other peers to subvert the training process. We address these two challenges and present Bristle, middleware between the learning application and the decentralized network layer. Bristle leverages transfer learning to predetermine and freeze the non-output layers of a neural network, significantly speeding up model training and lowering communication costs. To securely update the output layer with model updates from other peers, we design a fast distance-based prioritizer and a novel performance-based integrator. Their combined effect results in high resilience to Byzantine attackers and the ability to handle non-i.i.d. classes. We empirically show that Bristle converges to a consistent 95% accuracy in Byzantine environments, outperforming all evaluated baselines. In non-Byzantine environments, Bristle requires 83% fewer iterations to achieve 90% accuracy compared to state-of-the-art methods. We show that when the training classes are non-i.i.d., Bristle significantly outperforms the accuracy of the most Byzantine-resilient baselines by 2.3x while reducing communication costs by 90%.


Introduction
Machine learning applications have gained significant traction and are widely used for various purposes, such as understanding consumer preferences [10], recognizing pictures [42], predicting keystrokes [14], or translating texts [17]. Traditionally, these applications use neural networks trained on a single server using a tremendous amount of data generated by a large number of geo-distributed, heterogeneous edge devices such as smartphones, IoT devices, or autonomous vehicles [35]. However, centralized training on data streams generated by such devices is limited by the following three factors. First, transmitting training data over the Internet can pose a significant burden on backbone networks. This burden is particularly problematic when media such as photos or videos are used as training data and is worsened by the fact that most learning applications communicate with cloud providers over wireless links [46,78]. Second, maintaining a central server architecture can quickly become expensive and time-consuming as the number of devices increases [24]. Third, transmitting personal and sensitive information over the Internet, such as text conversations or photos, to cloud providers raises privacy concerns and is in certain jurisdictions not even allowed by regulations such as the US HIPAA [28] and the European GDPR law [75].
Federated Learning (FL) overcomes these three limitations. With FL, edge devices do not send their data to the server training the model but instead communicate model updates to a so-called parameter server, also see the left side of Figure 1 [15]. The parameter server coordinates the learning process by pushing model updates to devices (step 1 ), and peers train the model with their private data on-device (step 2 ). Then they send the updated model back to the parameter server (step 3 ), after which the server aggregates the incoming model updates into a global model (step 4 ). FL sidesteps the need for the data to leave the device, improving privacy, lowering the computational burden for the server, and decreasing the communication overhead when the model update is smaller than the data to be transmitted per iteration. FL is nowadays used for various applications, including nextword prediction on keyboards [2, 11,13,32], speech recognition [64], wireless communications [12,59], human activity recognition [66], and health applications [9,54,61,63].
The centralized architecture shown in Figure 1 is typical for FL systems. However, even though the parameter server synchronizes the learning process between remote edge devices, this approach comes with significant drawbacks [7,51,84]. Notably, the parameter server not only poses a single point of failure susceptible to crashes or hacks, but it may also become a performance bottleneck as the number of devices pushing model updates increases [51]. These issues motivate further research to remove dependency on the parameter server and train models in a decentralized manner [22,44,51,73]. With decentralized federated learning (DFL), each peer is connected to a subset of the other peers in the network from which it receives incoming models and to which it pushes its updated models [58]. We visualize this approach on the right side of Figure 1. DFL has resulted in a new wave of learning methods that achieve comparable model accuracy as state-of-the-art FL approaches [34] while boasting several significant advantages. First, decentralized networks are fault-tolerant by design since peers continuously update their knowledge about which other peers are online or stopped communicating [76]. Second, decentralized networks are self-scaling. When a new peer joins the network, other peers can start communicating with the newly-joined peer seamlessly. Because there is usually a maximum number of other peers with which each peer communicates, the connection ratio will drop, but the network will typically still be strongly connected [27]. Third, DFL unlocks AI with zero-cost infrastructure (from the developer's perspective) since the computational power needed to train the network is delivered by all peers in the network working together instead of a parameter server under centralized control [25].
Limitations of DFL. Despite the benefits of DFL, we identify three challenges that reduce its potential for practical applications. The first barrier is that both existing FL and DFL architectures have to consider Byzantine attacks, the situation where malicious peers aim to undermine the model's training by purposefully sending specific model updates to the parameter server or other peers [90]. Since malicious peers keep their data private, they can easily "poison" their model and disseminate this malicious model without repercussions. Byzantine attacks are often addressed by the Gradient Aggregation Rule (GAR), which aggregates and combines incoming model updates [6,56,90]. At the same time, stateof-the-art GARs typically assume that the majority of peers act honestly, which is hard to guarantee in networks with open participation [88].
The second challenge is that the performance of conventional FL systems degrades significantly when being deployed in an environment where the distribution of the training data differs between peers. This is also known as non-i.i.d.
(not independent and identically distributed) data. Given that data is typically non-i.i.d. in an FL environment [6,14,90], dealing with non-i.i.d. data is considered a key challenge in FL [38]. The inability of most GARs to handle non-i.i.d. data results in Catastrophic Forgetting, a phenomenon where the peers overwrite model parameters that were important to predict a particular class distribution with parameters essential to predict another class distribution [91].
The third challenge relates to the communication requirements to disseminate model updates among peers in the network. In DFL, each peer disseminates a copy of the current model at every training iteration to several other peers. However, modern neural networks may consist of millions of parameters [33,36], sometimes requiring gigabytes of data to be transferred for each model exchange. Facilitating this amount of data quickly becomes infeasible when the number of devices and the frequency of model updates increase [62].
Although some DFL systems are to a certain extent Byzantineresilient [6,31,56,85], able to deal with non-i.i.d. data [15,65,93], or focus on reducing the communication costs [3,21,80], there exists -to the best of the author's knowledge -no DFL solution that addresses all three challenges simultaneously. We argue that such a solution is a key requirement for a wide deployment of DFL systems.
Our Contributions. To the best of the author's knowledge [31,85,86,94], only four papers have ever been published about DFL that are Byzantine-resilient (first challenge), none of which are suitable for situations where the data is non-i.i.d. (second challenge) or decrease the communication requirements (third challenge). Therefore, we present Bristle: the first Byzantine-resilient and communication-efficient approach for DFL in environments with non-i.i.d. classes. 1 Bristle is a pure edge solution and acts as a middleware between the machine learning application and the decentralized network layer by combining three techniques: Similar to related work in the FL domain, Bristle focuses on supervised learning problems that train a neural network for classification [55,56,81]. We implement all elements of Bristle as an Android library and open-source our implementation (see Section 3.4).
With an extensive set of experiments with the popular MNIST dataset, we evaluate the performance and resilience of Bristle. We compare Bristle with five related approaches for FL and quantify the Byzantine-resilience of these approaches under four attacks in the domain of FL, aimed at reducing the model's accuracy. The experiments show that even in highly Byzantine environments where the classes are non-i.i.d., Bristle not only withstands all evaluated attacks but also outperforms all related approaches in terms of convergence speed, accuracy, consistency, and communication efficiency. We highlight one of the key results from our experiments in Figure 2, showing model accuracy as peers train the model. In this figure, the performance of Bristle and evaluated DFL approaches is illustrated in a Byzantine (40% of the peers perform a label-flip attack) and non-i.i.d. environment (the class overlap between the peers is just 40%). Despite this challenging environment, Bristle quickly converges and outperforms all other approaches in terms of accuracy while reducing communication costs by over 90%.

System and Threat model
We now describe our system and threat model, and state the assumptions underlying our work.
Network Model. We consider an unstructured, strongly connected peer-to-peer network with peers. Each peer knows the network addresses of other peers in the network. We assume unreliable and unordered network channels between peers. In addition, we do not place any restriction on peers joining the system, and peers can join or leave the system at any time. We consider the mitigation of attacks targeted at the network layer, e.g., the Eclipse Attack, beyond the scope of this work.
Training Data. Each participating peer acts on local training dataset which size is denoted by | |. Training data never leaves the device, and is only known to peer . In contrast to most related work, we assume that the number of samples per class is not distributed uniformly among peers (non-i.i.d), which is a key characteristic of FL environments [6,14,90]. However, we also assume that for each class the samples are distributed uniformly (i.i.d.) between peers as a prerequisite for the performance-based integrator (see Section 3.3).
Model Training. Our approach focuses on supervised classification problems where the dataset consists of a collection of input-output pairs. The input is a chunk of data with a fixed size, and the output is a qualitative label associated with a class. The devices aim to minimize the loss function by tuning the parameters in the neural network such that its predictive capabilities are maximized. We use the negative log-likelihood of the ground truth class as the loss function. Since this problem is intractable for complex models, we use, in line with most literature [47,70,71,90], a technique called Gradient Descent (GD) which iteratively takes the derivative of the loss function with respect to the training data and then moves the hyperparameters in the direction of the gradient. However, because the local dataset can be large, it can take a long time for GD to converge [8]. Therefore, we use the faster Stochastic Gradient Descent (SGD), where a subset (mini-batch) of five samples is stochastically sampled from the dataset to update the parameters in a particular iteration.
Threat Model. Our work assumes an environment with an unconstrained number of Byzantine attackers aiming to subvert the model's performance. This includes the Sybil Attack, an attack where a malicious peer joins the network under many different identities to prevent model convergence [23]. It also includes collusion, the situation where malicious peers in concert attempt to undermine model convergence. Byzantine attackers can send arbitrary model updates to any peer in the network, but have no access to the private samples of benign peers.

Bristle: Middleware for Decentralized Federated Learning
Bristle enables DFL that can handle non-i.i.d. classes and thwart Byzantine attacks while improving communication costs compared to existing approaches. We provide a highlevel overview of Bristle and the actions performed during a training iteration in Figure 3. First, Bristle takes advantage of deep transfer learning to determine the non-output layers of each node before the first training iteration (step 1 ). As we will experimentally demonstrate in Section 5, this  significantly reduces communication costs compared to communicating the entire model, speeds up the model convergence rate, and acts as a prerequisite to learning on non-i.i.d. classes.
The main innovation of Bristle is its two-phased GAR that integrates received models. During each training iteration, a peer trains the local model on a mini-batch of their private dataset and only updates the output layers (step 2 ). It then forwards the updated output layer 2 and the output layers it has received from other peers to a distance-based prioritizer (step 3 ). This fast distance-based prioritizer estimates the best candidates for integration based on an exploreexploit ratio and forwards them to the performance-based integrator (step 4 ). The performance-based integration is more computationally demanding and integrates the prioritized output layers into the peer's current output layer. This integration process is both Byzantine-resilient and capable of continual learning, facilitated by selective updating of the output layer, per-class performance evaluations, and a carefully crafted weighted averaging function. Our main motivation to use a two-staged approach is that a distancebased prioritizer on itself is ineffective and performancebased integration on all received models is too computationally expensive since it requires the evaluation of incoming models on private data. Finally, Bristle transmits the output layer to a few connected peers (step 5 ) and uses the new output layer as input for the next training iteration (step 6 ). In the remainder of this section, we elaborate on the model pre-training, the distance-based prioritizer, and the performance-based integrator.

Bootstrapping Bristle with Transfer Learning
In conventional FL settings, the parameters of the entire neural network are shared with the parameter server or, when using DFL, with other peers. These parameters include all weights and biases of the input layer, hidden layers, and the 2 We use the terms output layer and model interchangeably in this work. output layer. In Bristle, we avoid exchanging the full neural network between peers. Instead, we leverage a popular ML technique called deep transfer learning which re-uses a neural network that has been trained on another dataset with comparable low-level features as the training data (step 1 in Figure 3) [72]. More specifically, we copy and subsequently freeze the non-output layers from another model. Bristle then only trains and exchanges the output layer, which has three major advantages: 1. Copying the non-output layers from a well-trained model significantly improves the convergence rate when training the model in a decentralized fashion on devices with lower hardware capabilities. 2. Freezing non-output layers reduces communication overhead since only the output layers have to be shared among peers. 3. Freezing the non-output layers is a key step towards continual learning, which further increases the performance and robustness of Bristle (see Section 3.3).
To bootstrap Bristle with a pre-trained model, we must assume that for the dataset we want to train on, there exists a vastly bigger dataset with roughly the same low-level features that we can use to pre-train a similar model. Considering the extent to which transfer learning is nowadays used in practical learning problems, we argue that this assumption is realistic and does not prohibitively degrade the applicability of Bristle [1,60]. The training of the initial neural network can be performed offline by system designers or volunteers. The pre-trained model can then be shared with peers by bundling them in the (mobile) application or be served by a trusted server that sends interested peers the pre-trained model upon request. We assume that the developer knows the number of classes beforehand to determine the size of the output layer. 0 1 2 Euclidean distance to its own model Figure 4. Average Euclidean distance from a given model to benign (green) and malicious (red) models, and models trained on an entirely different data distribution (orange).

Distance-based prioritizer (DBP)
We now elaborate on the distance-based prioritizer (DBP) in Bristle (step 2 in Figure 3). The inputs to the DBP are the output layers received from other peers during the last training iteration. To explain the motivation behind the DBP, we first examine Figure 4 where the average Euclidean distance is shown from a non-i.i.d. model (configured as explained in Section 5.3) to two benign models (shown in green), a benign model that is trained on an entirely different data distribution (shown in orange), and several Byzantine models (shown in red). The distances in this figure are based on the models exchanged during our experiments (see Section 5). For each distance shown in Figure 4, we took the average distance over 100 runs (with the current and the other model both trained ten times on different training data) and trained all models to convergence before comparing the distances. The figure shows that based on the Euclidean distance alone, we cannot reliably determine if a certain model is benign because, in this example, the distance to a Trimmed Mean attack model is between the distances to two benign models. However, the distance may clearly help prioritizing certain models since models with rather low or high distances appear to be more likely to be malicious.
Based on this insight, we segment the received models into three equally-sized categories with a low, medium, and high distance from our current model. Then, we uniformly sample models from each of these categories. The number of models sampled from each category depends on the explorationexploitation ratio where = 0 exclusively samples lowdistance models (exploitation-dominant) and = 1 exclusively samples high-distance models (exploration-dominant). The optimal value of depends on the maximum distance that benign models can reasonably have to each other, which is highly dependent on the degree of asynchrony (higher asynchrony → higher ), the expected ratio of benign to Byzantine peers (more Byzantine peers → lower ), and the degree of non-i.i.d.-ness (higher non-i.i.d.-ness → higher ). The advantage of using three categories is that in situations where the accuracy is clearly sub-optimal and a significant number of Byzantine attackers are present, the developer may want to emphasize integrating models with a medium distance since these will often perform best. , and ℎ denote the fraction of samples from the low, medium and high distance categories, and are determined as follows: Note that + + ℎ = 1. Figure 5 visualizes the relation between the above values and . We also parameterize the maximum number of models that pass our DBP, denoted by . Since the runtime of our performance-based integrator scales with the input size, devices with lower performance can opt for a lower value for .

Performance-based Integrator (PBI)
The ability of our distance-based prioritizer to recognize Byzantine or stale models that are trained on a lower number of iterations is rather limited. Byzantine attacks are easy to launch in open networks, and stale models are a regular phenomenon in FL systems [49]. To address these concerns, we assess the performance of each model that passes the distance-based prioritizer on a small test dataset (step 4 in Figure 3) using a performance-based integrator (PBI). This test dataset is a random subset of the full private dataset owned by the peer. Figure 6 shows how the PBI works, given a model with three classes ( , and ). In summary, the PBI selectively integrates the parameters of classes that perform well to achieve Byzantine-resilience and to handle non-i.i.d. classes Prioritized output layers My output layer Data  properly. This is different from existing approaches that integrate each received model as a whole instead. We refer to the parameters in the output layer that are connected to a particular class as Class-specific parameters (CSPs). The integration process in Bristle first evaluates the performance of each class of each received model on a test dataset (step 1 ). Based on this evaluation, we compute a certainty score that estimates how benign a received model is (Step 2 ). Then, we calculate for all CSPs of each model a weight (step 3 ). Finally, we integrate the received models into our current model, based on the computed weights (step 4 ).
The selective integration of parameters is inspired by the continual learning algorithm CWR* [52] that enables noni.i.d. learning by initializing the output layer to zero, applying a mean-shift, and replicating the hippocampus-cortex duality by selectively copying and resetting parts of the output layer. Related work demonstrates that this approach provides excellent performance in regular non-FL environments and enables per-class updates [52]. Applying continual learning requires that the non-output layers are frozen and equal between all peers. We already addressed this by using transfer learning (see Section 3.1) to train these layers before the first iteration.
We now elaborate on the PBI logic, which pseudocode is given in Listing 1. The input for this algorithm is the current model of the peer (myModel), and the prioritized models that passed the DBP (prioritizedModels).
Step 1 (per-class performance measurements). Based on a subset of the local dataset, we first calculate the F1-score for the CSPs of all familiar classes of both the peer's own output layer and the prioritized output layers (line [4][5][6][7][8]. We refer to a class as familiar when the peer has a sufficient number of samples, denoted by , to reliably estimate the performance of that class of a given model. This threshold is determined by the developer. With a higher value of , the PBI can more reliably determine F1-scores, but the number of classes for which insufficient samples are available to evaluate, also known as foreign classes, might decrease. We chose to measure F1-scores instead of the accuracy as a proxy for the performance since the former is more suited for imbalanced datasets [16]. The data subset used by the PBI is never used to train the peer's own model since this would result in an overestimation of the performance of the peer's own model. Since these measurements depend on the availability of sufficient private data samples, Bristle avoids integrating models from other peers until sufficient private data samples are available to test them reliably.
Step 2 (certainty computation). Then, we calculate for each prioritized model a certainty score, which is a (rough) estimate of the degree to which this model is benign (line [10][11][12]. This certainty score is determined by subtracting the standard deviation from the average F1-score of the bestperforming familiar classes (line [11][12], thus rewarding high class performance and punishing high variation among the class performance. We do not consider all classes when computing the certainty score since it is not realistic to assume that all classes of each benign received model perform well in a non-i.i.d. environment. The larger is, the more robust the algorithm is against Byzantine attacks, but the less able it is to learn about foreign classes in the case of a non-i.i.d. setting. Step 3 (weight computation). Furthermore, we estimate for each familiar class of each prioritized model if integrating its corresponding CSP improves the model's performance by simply checking if the F1-score of that class of the received model exceeds the respective F1-score of the peer's own model (line 14). We call the extent to which it does the F1discrepancy, and we store this value in a two-dimensional array named disc. If the class-specific F1-score of the model being evaluated exceeds that of our own model, we calculated the F1-discrepancy as in line 15. Otherwise, we set the F1discrepancy to −∞ (line 17). The parameter increases the degree to which high-performing classes are integrated.
The computeFaWg function then computes the weights for the familiar classes for each model, taking the prior computed scores and certainty as input (line 19). This function computes the following Sigmoid function, where is the weight of familiar class , is the F1-discrepancy, and is the certainty of the model being considered: This function assigns a weight of one to equally performing classes and an increasingly higher weight to classes that show excellent performance, dependent on the values of 1 and 2 .
represents the boost for above-average performing models and the bounty for below-average performing models. The bigger this discrepancy, the faster the model can catch up with other better-performing models, but the bigger the impact of a malicious model that performs well on familiar classes and bad on foreign classes. We multiply the outcome of the Sigmoid function by the certainty score calculated earlier because the parameters of a class might be sub-optimal even when it has a perfect F1-score when other classes perform poorly. Figure 7 illustrates how the weight of CSPs is affected by their F1-score on a test dataset, assuming that the peer's current model yields a F1-score of 0.5 on that class and that the calculated certainty is 1.
Determining a weight for the CSPs of the foreign classes is challenging because we cannot directly measure their performance. Instead, we take the sum of the scores of all familiar classes and feed this into the same Sigmoid function as used for the familiar classes (Equation 2), albeit parameterized with separate variables 1 and 2 . This is done by the computeFoWg function (line 21).
is the extent to which foreign classes are integrated into the model. The higher this value, the better the model can be when the peer wants to use the model to classify formerly foreign classes, but also the higher the impact when a potentially malicious model is integrated. If the user is uninterested in achieving high performance on foreign classes, 1 can be set to 0.
Step 4 (model integration). Finally, we replace the CSPs of familiar and foreign classes with the weighted average of all CSPs by using the calculated weights (line 24-25).

Implementation
Bristle is implemented on top of an existing network library that provides support for peer discovery, decentralized overlay creation, and authenticated messaging [67,68]. Since we envision the usage of Bristle mostly in a mobile environment, our middleware is written in the Kotlin programming language (the default language for Android applications). We envision that Bristle runs as a background service on the end-users' devices to periodically receive or transmit models from and to peers when the device is connected to Wi-Fi.  Peers transmit model updates using the UDP protocol and network messages are compressed with Gzip. Model training is facilitated by the DeepLearning4j library (version 1.0.0-beta7) to enjoy compatibility with a wide range of advanced ML algorithms. We have published the Bristle source code and developer documentation in a GitHub repository. 3 Using Bristle. Developers can leverage the Bristle middleware by feeding the peer's current model and all received models into Bristle's GAR after each iteration and subsequently replacing the peer's model with the result. The moment a model is updated can be decided by the developer, for example, model training can take place when the device is charging to minimize the impact on end users. The peers should be able to selectively receive and integrate only models relevant to the current ML application. To this end, Bristle uses the functionality to form communication groups as provided by its network library. Deciding on the variables listed under Section 4 is a key part of machine learning. We recommend the developer to use heuristics, optimize them on a related dataset, or use A/B-testing to find the best values to obtain the desired accuracy on the models.

Experimental Setup
We now describe our experimental setup, datasets, and parameters.
Testbed. All experiments are run on an HPE DL385 Gen10 server. This server is equipped with 128 AMD EPYC 7452 CPUs, has 512 GB of DDR4 memory, and runs Debian 10.
Datasets. In line with related research [55,56,81], we consider an image classification application that applies Convolutional Neural Networks (CNNs) to classify images. We use the popular MNIST [45] dataset, consisting of 60,000 gray-scale training images and 10,000 test images of 28x28 pixels representing handwritten digits. To achieve better performance, we standardize the dataset by applying Z-score normalization such that the features are re-scaled to a normal distribution with = 0 and = 1. We pre-train -until convergence -a neural network with the same configuration on the EMNIST-Letters [18] dataset, which features resemble MNIST, but contains characters instead of digits. We then include the resulting neural network in the Bristle software.
Experiment parameters. We list all default parameters used during our experiments in Table 1. An explorationexploitation ratio of 0.4 slightly prioritizes model with lower distance.
Non-i.d.d. data. To evaluate Bristle with non-i.d.d. data, we first sort the data per class, divide the data into equallysized shards, and then assign to every peer several shards, which is also the approach taken by related work [19,77,79]. We note that the more shards we assign to every peer, the better every peer can recognize and defend against Byzantine attacks (see Section 3.3), but the less non-i.i.d. the classes are. We opt to assign -unless specified otherwise -without loss of generality to every peer four shards which cover 40% of the classes to balance between the ability to learn non-i.i.d. classes and to recognize Byzantine attacks.
Model training. We train the dataset on the same CNN architecture used by McMahan et al. [55], except that we use Leaky ReLu instead of the regular ReLu as the activation function for the hidden layers since the former seems to give slightly better performance (specifically, suffers less from the vanishing gradients problem). The model consists of twice a convolutional layer (kernel size = 5, stride = 1, padding = 0) followed by a max pooling layer (kernel size = 2, stride = 2, padding = 0), and finally the output layer (with 800 hidden nodes). For the output function, we use the softmax function, and as the loss function, we use negative log-likelihood. To train the model, we use the Adam optimizer, parameterized as shown in Table 1. Since these values significantly impact the model's performance, we used a grid search with typically 7-9 values for each parameter and ensured that the optimal values were approximately in the middle. Although the baselines were originally not developed to be used in combination with transfer learning, we decided to use transfer learning for all baselines for all experiments anyway since the performance increase is so significant that otherwise any comparison with Bristle would be meaningless (also see Section 5.1).
Baselines. To compare Bristle with existing methods, we implemented five other GARs commonly used in FL: We initialized Krum and BRIDGE, which are dependent on a-priori knowledge of the number of attackers, with = 4 (the maximum number of attackers) and Mozi with = 0.5 (the ratio of benign to Byzantine peers). Byzantine attacks. We also evaluate Bristle under the following four Byzantine attacks, which are commonly considered in the domain.
1. The Label-flip attack [4] assigns an incorrect label to each input [4,29,74]. We implement this attack by numbering all labels and reassigning each sample with label to label ( + 1) % | |. 2. The Additive noise attack [48] adds some noise to the parameters of outgoing models. When the noise has a larger variance, it can indeed prevent convergence but also makes the noise attack easier to detect [48]. Centering the noise around a value slightly different from 0 allows the attack to prevent convergence despite low variance, but since the mean of benign updates is always centered around 0, this attack can be easily    detected. We consider a variant where each half of the parameters are set to noise centered around a value just below and above 0, respectively. 3. The Krum attack [26] specifically targets the Krum aggregation rule. It is an effective, state-of-the-art attack by iteratively sending attack vectors that will be accepted by Krum whilst inflicting maximum damage to the peer's model. 4. The Trimmed Mean attack [26] targets the trimmed mean GAR (Bridge in our experiments). It determines the gradient direction for each parameter of the model and then creates an attack vector that points exactly in the opposite direction, scaled per parameter depending on the values of the other benign peers.

Experimental Evaluation
We now evaluate the performance of Bristle. Our evaluation answers the following questions:

Performance Gains of Transfer Learning
We first evaluate the performance gains of transfer learning when all peers are honest, and the data is i.i.d. For each experiment, we measure after every 10 iterations the performance of all peers and then take the average accuracy, defined as # # . Figure 8 shows the evolution of model accuracy for the baseline GARs and Bristle, both without transfer learning ( Figure 8a) and with transfer learning (Figure 8b). We note that Bristle requires a pre-trained model and therefore is not included in Figure 8a. Figure 8a shows that the evaluated GARs perform quite similarly, although Mozi has a slower convergence rate since it assigns  lower weights to benign models that have not been trained sufficiently yet to perform well. Transfer learning dramatically improves both the convergence rate and the maximum accuracy after 300 iterations of all GARs, which also supports literature [37]. More specifically, whereas reaching 70% accuracy takes on average 55 iterations with regular training, it takes merely four iterations with transfer learning, a reduction of 93%. Reaching 90% accuracy takes on average 180 iterations with regular learning, whereas it only takes 30 iterations with transfer learning, a reduction of 83%. This reduction in iterations to reach the desired level of model accuracy can significantly reduce the load on the network.

Byzantine Attacks
We now evaluate the Byzantine-resilience of Bristle under different attacks when data is i.i.d. Figure 9 shows the effect of different attacks. Bristle withstands all evaluated Byzantine attacks and quickly achieves high model accuracy. Figure 9a shows that the label-flip attack prevents model convergence when using the FedAvg GAR, but is, despite its relatively small influence on the model's parameters, successfully mitigated by all other GARs. Figure 9b shows that the FedAvg and Median GARs are susceptible to the additive noise attack. The Krum attack, shown in Figure 9c, is clearly very effective against Krum but has only a minor effect on the  convergence rate of the other GARs. The Trimmed Mean attack, see Figure 9d, is relatively ineffective against any Byzantine-resilient GAR. This is because all benign models are very close to each other in this scenario, making it hard for this attack to steer the model in another direction without clearly being an outlier.

Non-i.i.d. Classes
We now consider the scenario where the classes are noni.i.d., see Figure 10. In this experiment, there are 10 peers, each of which has access to two random samples of four consecutive classes. Thus, each peer has access to classes { , ( + 1)%10, ( + 2)%10, ( + 3)%10}. When we compare Figure 10b with Figure 10a, it is clear that Krum and Mozi fail to achieve desired model accuracy with non-i.i.d. classes, and we also observe that Bridge and Median converge significantly slower. FedAvg and Bristle show excellent performance and achieve 90% model accuracy in 65 and 55 iterations, respectively. This is because these methods (eventually) combine the information learned by every peer, while the other methods disregard a part of the received models under the incorrect assumption that those are Byzantine.

Combining Byzantine Attacks and Non-i.i.d. Classes
We now evaluate Bristle and other GARs in an environment containing both Byzantine attackers and where the classes are non-i.i.d. (see Figure 11). We use the label-flip attack in all experiments because this one is effective (see Figure 11a) and very popular in related work [26,57,82]. Except for Bristle, all baselines fare poorly in the Byzantine experiments with non-i.i.d. classes. Specifically, we observe that FedAvg is unable to defend against Byzantine attacks, although it achieves an accuracy of 87% in the first few iterations of the Krum attack (see Figure 11c). Although Bridge performs well in the experiments presented in Section 5.2, it performs poorly under the threat of Byzantine attacks when the classes are non-i.i.d. Krum is, as expected, unable to defend against the Krum attack but performs under the threat of the other attacks roughly on par with Mozi. Mozi shows the same accuracy as in the benign non-i.i.d. experiments (see Figure 9) because it successfully defends against Byzantine attacks but is also maxed out on the poor maximum accuracy that it can attain on the node's own dataset. The performance of the Median baseline varies significantly depending on the attack and may be quite inconsistent (as illustrated in Figure 11b and Figure 11d). An interesting finding is that the Trimmed Mean attack is relatively ineffective in the i.i.d. experiment (see Figure 9d) but impacts the performance of the same baselines significantly in the non-i.i.d. experiment (see Figure 11d). This results from the greater distance between the benign models in the non-i.i.d. experiment, giving the attack more leeway to steer the model in a different direction without being considered an outlier. Since the PBI assigns a weight of  Varying the Number of Byzantine Attackers. We now vary the number of Byzantine attackers, see Figure 12. Figure 12a shows that even with 10% Byzantine attackers, the performance of the baselines already degrades significantly. Bristle manages to maintain a quick increase in accuracy for all considered attack scenarios. With 10% and 30% Byzantine attackers, Mozi manages to keep a stable performance but is limited to predicting only the peer's familiar classes correctly. Figure 12d shows that the performance of Krum is inconsistent and that only Bristle achieves a consistent high performance. Bristle's excellent performance results from the fact that (a) in contrast to Mozi, Bristle evaluates and integrates the parameters per class instead of per model, and (b) in contrast to the other GARs, Bristle uses performance evaluations instead of just distance comparisons.
Varying the Degree of Non-i.i.d.-ness. We now compare the performance of the GARs in three situations where the classes are to a varying extent non-i.i.d. (see Figure 13).
FedAvg and Bridge are, regardless of the degree of non-i.i.d.ness, unable to provide any resilience to the label-flip attack. Mozi defends, similarly to the experiments in Figure 11, perfectly well against the label-flip attack but is limited to the maximum accuracy that can be obtained by training on its own dataset. The performance of Krum increases with the number of classes owned by the peer. The Median rule performs relatively well, even when the classes are highly non-i.i.d. Bristle, however, clearly performs best compared to all baselines, although its performance decreases when the peers have only 20% of the data (see Figure 13a).
Varying the Connection Ratio. In larger networks, it is unrealistic to assume all-to-all dissemination of model updates. To test the impact of the connection rate on the convergence rate more accurately, we set up an environment with 100 peers where the classes are again non-i.i.d. similarly to the previous experiments. We setup two experiments, connect each peer to a random subset of 2% and 5% of the other peers respectively, add an equal number of label-flip attackers that are connected to each benign peer, and measure the average accuracy over time. From Figure 14a, we observe that when the connection rate is only 2%, FedAvg and Median perform very poorly, but also the other GARs are unable to achieve satisfactory accuracy. When the connection rate increases to 5% in Figure 14b, Bristle and Krum perform quite well in contrast to the other baselines. Thus, it seems that in a setting with 100 peers, a connection rate of only 5% is already almost enough to reach the maximum accuracy. The number of iterations required to obtain this accuracy is relatively high compared to a connection rate of 100% (see Figure 11a). relatively inexpensive operations, such as calculating the distance between models and sorting the parameters of each dimension. Mozi is relatively slow because it has to evaluate the accuracy of each model. Bristle is initially by far the slowest GAR caused by the performance-based integrator that evaluates the performance not just for each model but for each familiar class of each model. However, when the number of connected peers exceeds (see Section 3.2), adding more peers has a negligible impact on the speed of Bristle because the distance-based prioritizer is efficient in reducing the number of models to .

Bristle Efficiency and Scalability
All baselines consume an equal amount of network traffic (roughly 3 MB per iteration per peer for our neural network), but because Bristle transmits only the output layer (roughly 300 KB), the bandwidth requirements of Bristle are reduced by 90%.

Related work
In the last five years, a considerable amount of literature has been devoted to creating more effective FL systems. Most work focuses on achieving Byzantine-resilience but also introduces several methods to reduce the bandwidth requirements and to improve learning on non-i.i.d. classes.
Byzantine-resilience. Several well-known Byzantineresilient GARs are Coordinate-wise Median (CM) [57] which takes the median across all models for each parameter, Krum [6] which selects the model that most closely resembles all other models, and Bulyan [56] which iteratively applies Krum followed by a variant of CM. However, these GARs use distances as a proxy for benignness, which it not reliable as we have seen in Section 3.2. In contrast, performance-based methods reject or accept received models based on their performance on a test dataset. Examples include RONI (Reject On Negative Influence) [5] which simply discards all models with a negative impact on the model, and Zeno [82] / Zeno++ [83] which use a central oracle to estimate the true gradient and only keep the gradients most similar to this estimation. Bristle uses distances only to prioritize the received models and uses per-class performance measurements to integrate models.
Communication efficiency. Because of the bandwidth limitations of cellular networks, numerous methods were proposed to improve the communication efficiency of FL. A popular method is to quantize the gradients to low-precision values [3,21,80] or only to transmit the most important parameters (sparse matrix methods) [40,69]. Bristle only updates the output layer, which works well together with existing techniques to reduce the communication overhead.
Non-i.i.d. learning. Several methods enable learning on non-i.i.d. classes, such as by sharing a small i.i.d. training dataset across all peers [93] or by reusing non-federated continual learning techniques [30,41,43,89]. Bristle also lends several concepts from a non-federated continual learning technique, namely CWR* [53] (see Section 3.3).
FL systems. Several FL systems try to combine Byzantineresilience with learning on non-i.i.d. data. RSA [47] uses a regularization-based strategy and although it performs relatively well when the data is non-i.i.d., it fares poorly against Byzantine attackers. FoolsGold [29] detects and rejects attacks executed by multiple sybils working together and works well with non-i.i.d. data. However, Zhao et al. [92] show that the Byzantine-resilience of FoolsGold is quite limited. FLeet [20] uses past observed staleness values and similarities with past learning tasks to achieve learning on non-i.i.d. data for a specific type of "soft" Byzantine attacks (namely the presence of stale models) but is unsuitable for other types.

Concluding Remarks
We have presented Bristle, middleware for decentralized, federated learning that tolerates Byzantine attacks, even when the classes of the training data are non-i.i.d. By leveraging deep transfer learning, Bristle achieves a high convergence rate despite having a low communication overhead. Through the combination of a fast distance-based prioritizer and a per-class performance integrator, Bristle is able to withstand attacks targeted at subverting the model accuracy. Our experimental evaluation using the popular MNIST dataset has demonstrated these desirable properties and shows that Bristle exhibits superior performance compared to related solutions. In this evaluation, we did not focus on privacy, communication compression, or other aspects that are supplementary to Bristle and addressed in the existing literature. We have implemented and open-sourced Bristle on GitHub.
Although we believe that Bristle is a significant step forward for DFL, we identify two directions for further work. First, communication costs could be further reduced by selectively sending parameters to peers with high class overlap. This can be estimated using Private Set Intersection Cardinality (PSI-CA). One can prevent peers from learning too much about the class distribution of others, e.g., by adding noise to the cardinality and by rate-limiting PSI-CA requests. Second, the accuracy could be increased even more when the non-output layers can also be fine-tuned rather than being fixed. Several popular continual learning algorithms are suitable for this purpose, such as LWF [50], AR1 [53], or EWC [39]. However, tuning also the non-output layers requires the transmission of information about these non-output layers, significantly increasing the communication costs. Additionally, it is non-trivial to maintain the Byzantine-resilience property because the parameters in the hidden layers do not correspond directly with the classes to be predicted.