{'fraction_non_alphanumeric': 0.028228755302033056, 'fraction_numerical': 0.005956892310556198, 'mean_word_length': 4.74457684081882, 'pattern_counts': {'":': 0, '<': 4, '<?xml version=': 0, '>': 2, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 7, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Federated Learning and Differential Privacy: Software tools analysis, the Sherpa.ai FL framework and methodological guidelines for preserving data privacy

The high demand of artificial intelligence services at the edges that also preserve data privacy has pushed the research on novel machine learning paradigms that fit those requirements. Federated learning has the ambition to protect data privacy through distributed learning methods that keep the data in their data silos. Likewise, differential privacy attains to improve the protection of data privacy by measuring the privacy loss in the communication among the elements of federated learning. The prospective matching of federated learning and differential privacy to the challenges of data privacy protection has caused the release of several software tools that support their functionalities, but they lack of the needed unified vision for those techniques, and a methodological workflow that support their use. Hence, we present the Sherpa.ai Federated Learning framework that is built upon an holistic view of federated learning and differential privacy. It results from the study of how to adapt the machine learning paradigm to federated learning, and the definition of methodological guidelines for developing artificial intelligence services based on federated learning and differential privacy. We show how to follow the methodological guidelines with the Sherpa.ai Federated Learning framework by means of a classification and a regression use cases.


Introduction
The last advances in fundamental and applied research in artificial intelligence (AI) has aroused the interest of the industry and end users in it. This interest goes beyond the traditional centralised setting of AI, and nowadays there is a high demand of AI services at the edges.
One of the main pillars of AI is data, whose larger availability has boosted the progress of AI in the last years. However, data is a sensitive element, especially when data describe personal features from users as clinical or financial data do. This sensitive nature of personal data has led to the awareness of the protection of data privacy in end users, promoting the publication of legal frames for private data protection [1] and of recommendations for developing AI services that preserve data privacy [2].
In this context, the progress of the application of AI depends on (1) using data generated or stored at the edges, (2) the combination of the data from different sources to work with larger amounts of data, and (3) the protection of data privacy because of legal restrictions and end users concerns. Some use cases of AI with these dependencies are: • When data contains sensitive information, such as email accounts, personalised recommendations or health records, applications should employ privacy-preserving techniques to learn from a population of users whilst keeping the sensitive information on each user's device [3].
• When information is located in data silos, for instance, healthcare industry is usually reluctant to disclose their information records, and this is kept as sequestered data [4]. Nevertheless, it would benefit models that learn from the information of the data silos of different health institutions, because this will allow a joint learning that would contribute to improve the robustness of the resulting models.
• Due to data privacy legislation, banks [5] and telecom [6] companies, for example, cannot share individual records, but they would benefit from models that learn from data across several entities.
The standard machine learning paradigm does not match the previous dependencies, as it learns from a centralised data source. Likewise, distributed machine learning does not fit the preserving data privacy challenge, because the data is shared among several computational elements. Moreover, distributed machine learning is not valid for the associated challenges of the decentralised processing of data, such as the capacity of working with a great amount of clients and with non homogeneous data distributions [7].
Federated learning (FL) is a nascent machine learning paradigm where many clients, in the sense of electronic devices or entire organisations, jointly train a model under the orchestration of a central server, while keeping the training data decentralised [8]. Roughly speaking, data is not shared with the central server, and indeed it is kept in the devices where it is stored or generated. Accordingly, FL have arisen to address the challenges of developing AI services on scattered data in a large amount of clients with a non homogeneous data distribution.
Maintaining the data in their corresponding data silos does not completely assure the preservation of their privacy, since several adversarial attacks can still compromise them [9]. Data obfuscation, anonymisation techniques such as blindly trusting artificial intelligence black box models (i.e. convolutional neural networks) or randomly sampling client model's data have been proven to be inadequate to preserve privacy [10,11]. Moreover, the complete obfuscation of the data greatly reduces its value, thus a balance between privacy and usefulness is needed. Differential privacy (DP) is proposed as a data access technique which aims to keep personal data privacy while maximising its utility [12].
The characteristics of FL and DP, and by extension their combination, make them candidates to address the challenges of distributed AI services that preserve data privacy. The research and progress of FL and DP need the support of software tools that avoid their development from scratch and ease the prototyping AI services with their features. Consequently, several software tools with FL and DP functionalities have been released with the aim of easing the development of AI services that protect data privacy.
We perform a comparative analysis of the FL and DP software tools released so far, and we conclude that their lack of an holistic view of FL and DP hinders the development of unified FL and DP AI services, as well as the furtherance of addressing the challenges of AI services at the edges that preserve data privacy. Therefore, we present the Sherpa.ai Federated Learning framework, 1,2 an open-source unified FL and DP framework for artificial intelligence.
Sherpa.ai FL aims to bridge the gap between the fundamental and applied research. Moreover, it will facilitate open research and the development of new solutions built upon FL and DP for the challenges posed by AI at the edges and the protection of data privacy. A flexible approach to a wide range of problems is assured by its modular design that takes into account all the key elements and functionalities of FL and DP, which consist of: 7. DP mechanisms. The fundamental DP mechanisms, such as the Laplace mechanism, as well as the composition of DP mechanisms are incorporated.
The progress of AI is not only supported by the release of software tools, but it needs fundamental guidelines that define how to put together the different facilities of those software tools for reaching the intended learning goal while at same time matching the problem restrictions. Accordingly, since FL is a machine learning paradigm, we first study the principles of machine learning and how to make them fit the FL requirements. We see that most machine learning methods can be directly adapted to a FL setting, but some of them need some ad-hoc amendments. As a result of this study, we define the experimental workflow of FL as methodological guidelines for preserving data privacy in the development of AI services at the edges. These methodological guidelines are grounded in the machine learning workflow, and they have guided the design and development of Sherpa.ai FL, therefore they can be followed with Sherpa.ai FL.
We show how to follow the mentioned methodological guidelines with Sherpa.ai FL through two examples encompassing a classification and a regression use cases, namely: 1. Classification. We use the EMNIST Digits dataset to describe how to conduct a classification task with Sherpa.ai FL. We also compare the federated classification with its centralised counterpart reaching both of them similar results.
2. Regression. We describe how to perform a regression experiment using the California Housing dataset. We compare the FL experiment with its centralised version. In addition, we show how to limit the privacy loss using DP.
The main contributions of this paper are: 1. To analyse the most recent released FL and DP software tools, which lack a unified view of FL and DP that hinders the addressing the challenges of AI at the edges and data privacy.
2. To present Sherpa.ai FL that is an open-source unified FL and DP framework for AI.
3. To study the adaptation of machine learning models to the principles of FL, and accordingly to define the methodological guidelines, which can be followed with Sherpa.ai FL for developing AI services that preserve data privacy with FL and DP.
The rest of the paper is organised as follows: the next section formally defines FL and DP as well as their key elements. Section 3 analyses the main FL and DP frameworks' features. Section 4 introduces Sherpa.ai FL including software architecture and functionalities. Section 5 explains the adaptation of the machine learning paradigm to FL, taking into account the adaptation of core algorithms and the methodological guidelines of an experimental workflow. Section 6 shows some illustrative examples consisting in a classification and regression problem. Finally, the concluding remarks and future work are described in Section 7.

Federated Learning and Differential Privacy
The development of a framework for FL and DP requires a thorough understanding of what FL is and what its key elements are. Accordingly, we formally define FL in Section 2.1, and we detail each key element of a FL scheme in Section 2.2. Similarly, DP is defined in Section 2.3, and its key elements are described in Section 2.4.

The definition of Federated Learning
FL is a distributed machine learning paradigm that consists of a network of nodes where we distinguish two types of them: (1) Data owner nodes, {C 1 , . . . , C n }, that own a collection of data, {D 1 , . . . , D n }, and (2) Aggregating nodes, {G 1 , . . . , G k }, aiming at learning a model from the Data owners' data preserving data privacy. The way of deployment of this two types of nodes defines, at least, two kind of federated architectures according to Yang et al. [13], namely: 1. Peer-to-peer: It is the architecture in which all the nodes are both Data owner and Aggregation ones. This scheme does not require a coordinator. The advantages are the elevated security and data privacy while the main disadvantage is the computation cost. This FL architecture is illustrated in Figure 1.
2. Client-server: It consists of a coordinator Aggregation node named server and a set of Data owner nodes named clients. 1 In this architecture, the local data of the clients never leaves the clients ensuring the data privacy. We represent the client-server scheme in Figure 2.
Since the peer-to-peer model is a generalisation of the client-server model, we consider the last one for the formal definition of FL. In this architecture, each of the clients C i has a local learning model LLM i represented by the parameters θ i . FL aims at learning the global learning model GLM, represented by θ, using the scattered data across clients through an iterative learning process known as round of learning. For that purpose, in each round of learning t, each client trains the LLM i over their local training data D t i , updating the local parameters θ t i . Subsequently, the global parameters θ t are computed aggregating the local parameters {θ t 1 , . . . , θ t n } using a specific federated aggregation operator ∆:  After the aggregation of the parameters in the GLM, the LLMs are updated with the aggregated parameters: The communication between server and clients can be synchronous or asynchronous. In the first option, the server waits for the clients updates, aggregates all the local parameters and sends the aggregated parameters to all the clients. Nevertheless, in the second option, the server merges the local parameters with the GLM as soon as it receives them, using a weighted scheme based on the age difference among the models.
We repeat this iterative process for as many rounds of learning as needed. Thus, the final value of θ will sum up the clients' underlying knowledge.
In particular, the learning goal is typically to minimise the following objective function: where n is the total number of clients, F i is the local objective function for the i-th client which is the common objective function of the problem fitted to each client's data, w i ≥ 0 and ∑ i w i = 1.

Key elements of Federated Learning
The setting up of a FL environment requires the right combination of a set of necessary key elements. Since FL is a specific configuration of a machine learning environment, FL shares some key elements with it, namely: (1) data and (2) the learning model. However, the particularities of FL make necessary additional key elements, such as: (1) federated aggregation operators, (2) clients, (3) federated server and (4) communication among the federated server and the clients. The adaptation of the common key elements among FL and machine learning, and the FL specific ones are described as what follows.
Data. It also plays a central role in FL as in machine learning. The distribution of data becomes crucial in FL since the data are distributed among the different clients. Regarding the splitting of the data among clients, there are two possibilities depending on the resulting data distribution: • IID (Independent and Identically Distributed) scenario: when the data distribution in each client corresponds to the population data distribution. In other words, the data in each client are independent and identically distributed, as well as representative of the population data distribution.
• Non-IID (non Independent and Identically Distributed) scenario: when the data distribution in each client is not independent or identically distributed from the population data distribution.
In a real FL scenario, the data stored at each client is generated by each client. This distributed character of the data ensures the non-IID aspect of the global distribution of the data in the learning scheme. Hence, the non-IID scenario is the most likely one and represents a real challenge for FL.
Learning model. It is the shared structure between the server and the clients, where each client trains a local model using its own data, while the global model on the server is never trained, but instead it is obtained aggregating the clients' model parameters. This configuration essentially differs from the classical (centralised) learning paradigm in that multiple models are trained without data sharing.
Federated aggregation operators. The aggregation operator is in charge of the aggregation of the parameters in the server. It has to: (1) assure a proper fusion of the local learning models in order to optimise the objective function in Equation 3; (2) reduce the number of communication rounds among the clients and the federated server and (3) be robust against clients with poor data and against malicious clients.
There are some federated aggregation operators in the literature and some of the most commonly used are: • Federated Averaging (FedAvg) [14]. It is based on keeping a shared global model that is periodically updated by averaging models that have been trained locally on clients. It arranges training by a central server which hosts the shared global model. However, the actual optimisation is done locally on clients.
• CO-OP [15]. It proposes an asynchronous approach. It merges any received client model with the global model. Instead of directly averaging the models, the merging between a local model and the global model is carried out using a weighting scheme based on a measure of the difference in the age of the models. This is motivated by the fact that in an asynchronous framework, some clients will be trained on obsolete models while others will be trained on more up-to-date models.
Clients. Each client of a federated scenario represents a node of the distributed scheme. Typical clients in FL could be smartphones, IoT devices or connected vehicles. Each client owns its specific training dataset and its local model. Their principal aim is to train local models on their own private data and share the model parameters with the federated server where the parameters fusion is performed.
Federated server. It orchestrates the iterative learning of FL, which is composed of several rounds of learning, which the server participates in: (1) receiving the parameters of local models after their local training, (2) aggregating the parameters of each client model using federated aggregation operators and (3) updating every learning model with the aggregated parameters. The learning process involved from training the local models to updating them is known as a round of learning. The global model, which is stored in the federated server, represents the final model after the learning process. Therefore it is used for predicting, testing or any posterior evaluation.
Communication among the federated server and the clients. Communication between clients and server is the most tricky element of a FL scheme. On the one hand, an efficient communication is a crucial requirement due to the high communication times needed due to internet network speed limitations, WiFi availability and so on. For that reason, FL should minimise communications and maximise their efficiency by, for example, reducing the number of rounds of learning. On the other hand, the interchange of model parameters between the server and the clients is a vulnerability of the federated server scheme, since the original data may be reconstructed from the model parameters through modelinversion adversarial attacks [16], which would mean a leak in the data privacy. For that reason, DP techniques [12] are commonly used in order to share parameters model information [17], and we implement them in Sherpa.ai FL.

The definition of Differential Privacy
DP is the property of an algorithm whose input is typically a database, and whose encoded response allows to obtain relatively accurate answers to potential queries [12,18]. The motivation for DP stems from the necessity of ensuring the privacy of individuals whose sensitive details are part of a database, while at the same time being able to gain accurate knowledge about the whole population when learning from the database. DP does not imply a binary concept, i.e., the guarantee or not of an individual's data privacy. Instead DP establishes a formal measure of privacy loss, allowing for comparison between different approaches. Thus, DP will rigorously bound the possible harm to an individual whose sensitive information belongs to the database by fixing a budget for privacy loss.
The formal definition of DP requires a few preliminary notions. Namely, we define the probability simplex over a discrete set B, denoted ∆(B), as the set of real valued vectors whose |B| components sum up to one and are non-negative: A randomised algorithm M : A → B, with B a discrete set, is defined as a mechanism which is associated with a mapping M : A → ∆(B) such that, with input a ∈ A, the mechanism produces M(a) = b with probability (M(a)) b = P(b|a), for each b ∈ B. The probability is taken over the randomness employed by the mechanism M.
In general, databases are collections of records from a universe X . It is convenient to express databases x by their histogram x ∈ N |X | , where each component x i stands for the number of elements in the database of type i in X .
This interpretation naturally leads to define the distance between databases: two databases x, y are said to be n-neighbouring if they differ by n entries as ||x − y|| 1 = n, where || · || 1 denotes the 1 norm. In particular, if the databases only differ in a single data element (n = 1), the databases are simply addressed as neighbouring.
At this stage, DP can be formally introduced. A randomised algorithm (mechanism) M with domain N |X | preserves -DP for > 0 if for all neighbouring databases x, y ∈ N |X | and all S ⊆ Range(M) it holds that: If, on the other hand, for 0 < δ < 1 it holds that: then the mechanism possesses the weaker property of ( , δ)-DP. The probability is taken over the randomness employed by the mechanism M.
In essence, Equation 5 tells us that for every run of the randomisation mechanism M(x), it is almost equally likely to observe the same output for every neighbouring database y, such probability is governed by . Equation 6 is weaker since it allows us to exceed with probability δ.
In other words, DP specifies a "privacy budget" given by and δ. The way in which it is spent is given by the concept of privacy loss. We define the privacy loss incurred in observing the output µ employing the randomised algorithm M in two neighbouring databases x, y: Since the privacy loss can be both positive and negative, we consider the absolute value of it in the following interpretation. The privacy loss allows us to reinterpret both and δ in a more intuitive way: • limits the quantity of privacy loss permitted, that is, our privacy budget.
• δ is the probability of exceeding the privacy budget given by , so that we can ensure that with probability 1 − δ, the privacy loss will not be greater than .
DP is immune to post-processing, that is, if and algorithm protects an individual's privacy, then there is not any way in which privacy loss can be increased, stated in a more formal way: let M : N |X | → R be a ( , δ)-differentially private mechanism and let f : R → R , then f • M : N |X | → R is ( , δ)-differentially private.

Key elements of Differential Privacy
DP arose as the principal setting for privacy-preserving of sensitive data when delivering trained models to unreliable parties. The possibilities of DP are built upon the modular structure of its elements, which allows to construct more sophisticated DP mechanisms, and to design, analyse and post-process DP mechanisms for a specific privacy-preserving learner [12,19]. These necessary or key elements of DP are the DP mechanisms, the composition DP mechanisms, and the subsampling techniques to increase the privacy. We subsequently detail them.

DP mechanisms.
We describe the main privacy-preserving mechanisms as what follows: • Randomised response mechanism. It is aimed at evaluating the frequency of an embarrassing or illegal practice. When answering whether it engaged in the aforementioned activity in the past period of time, the following procedure is proposed: 1. Flip a coin; 2. If tails, respond truthfully; 3. If heads, flip a second coin and if heads, respond "Yes", and respond "No" if tails.
This approach provides privacy due to "plausible deniability" since the response "Yes" may have been submitted when both coins flips turned out heads. By direct computation it can be shown that this is an -differentially private mechanism with = log(3) [12, Section 3.2].
• Laplace mechanism [18]. It is usually employed for preserving privacy in numeric queries f : N |X | → R k , which map databases x ∈ N |X | to k real numbers. At this point, it is important to introduce a key parameter associated to the accuracy of such queries, namely the 1 sensitivity: Since the above definition must hold for every neighbouring x, y ∈ N |X | , it is also denoted as global sensitivity [19]. This parameter measures the maximum magnitude of change in the output of f associated to a single data element, thus, intuitively, it establishes the amount of uncertainty (i.e., noise) to be introduced in the output to preserve the privacy of a single individual.
Moreover, we denote as Lap(b) the Laplace distribution with probability density function with scale b and centred at 0. Given any function f : N |X | → R k , the Laplace mechanism can be defined as where the components Y i are IID drawn from the distribution Lap(∆ f / ). In other words, each component of the output of f is perturbed by Laplace noise according to the sensitivity of the function ∆ f . It can be shown that this is an -differentially private mechanism with = ∆ f /b [12, Section 3.3].
The exponential mechanism [20] • Exponential mechanism [20]. It is a general DP mechanism that has been proposed for situations in which adding noise directly to the output function (as for Laplace mechanism) would completely ruin the result. Thus the exponential mechanism constitutes the building component for queries with arbitrary utility, where the goal is to maximise the utility while preserving privacy. For a given arbitrary range R, the utility function u : N |X | × R → R maps database/output pairs to utility values. We introduce the sensitivity of the utility function as where the sensitivity of u with respect to the database is of importance, while it can be arbitrarily sensitive with respect to the range r ∈ R. The exponential mechanism M E (x, u, R) is defined as a randomised algorithm which picks as output an element of the range r ∈ R with probability proportional to exp ( u(x, r)/(2∆u)).
When normalised, the mechanism details a probability density function over the possible responses r ∈ R. Nevertheless, the resulting distribution can be rather complex and over an arbitrarily large domain, thus the implementation of such mechanism might not always be efficient [12]. It can be shown that this is a (2 ∆u)differentially private mechanism [20].
• Gaussian mechanism [12]. It is a DP mechanism that adds Gaussian noise to the output of a numeric query. It has two great advantages over the differentially private mechanisms stated previously: -Common source noise: the added Gaussian noise is the same as the one which naturally appears when dealing with a database.
-Additive noise: the sum of two Gaussian distributions is a new Gaussian distribution, therefore it is easier to statistically analyse this DP mechanism.
Instead of scaling the noise to the 1 sensitivity, as we previously did with the Laplacian mechanism, it is scaled to the 2 sensitivity: Moreover, we denote as N(0, σ 2 ) the Gaussian distribution with probability density function with mean 0 and variance σ 2 . Given any function f : N |X | → R k , the Gaussian mechanism can be defined as: where the components Y i are IID drawn from the distribution N(0, σ).
To sum up, the main idea behind DP mechanisms is adding a certain amount of noise to the query output, while preserving the utility of the original data. Such noise is calibrated to the privacy parameters ( , δ) and the sensitivity of the query function.
Composition of DP mechanisms. An appealing property of DP is that more advanced private mechanisms can be devised by combining DP mechanisms, such as the general building components described in Section 2.4. The resulting mechanism then still preserve DP, and the new values of and δ can be computed according to the composition theorems. Before the composition theorems are provided, we state an experiment with an adversarial which proposes a composition scenario for DP [12].
Composition experiment b ∈ {0, 1} for adversary A with a given set, M, of DP mechanisms. For i = 1, . . . , k: 1. A generates two neighbouring databases x 0 i and x 1 i and selects a mechanism M i from M.

2.
A receives the output y i ∈ M i (x b i ) In the experiments the adversary preserves its state between iterations, and we define A's view of the experiment b as V b = {y 1 , . . . , y k }. In order to ensure DP in these Composition experiments we need to introduce a statistical distance which resembles the privacy loss (Equation 7).
The δ-Approximate Max Divergence between random variables Y and Z is defined as: We say that the composition of a sequence of DP mechanisms under the Composition experiment is ( , δ)-differentially private if D δ ∞ (V 0 ||V 1 ) ≤ . Now, we are ready to introduce the composition theorems: • Basic composition theorem. The composition of a sequence {M k } of ( i , δ i )differentially private mechanisms under the Composition experiment with More advanced versions of Equation 14 that allow the composition of private mechanisms with diverse and δ values and provide tighter bounds can be found in [21].
Privacy filters [22]. While composition theorems are quite useful, they require some parameters to be defined upfront, such as the number of mechanisms to be composed. Therefore, no intermediate result can be observed and the privacy budget can be wasted.
In such situations it is required a more fine grained composition techniques which allows to observe the result of each mechanism without compromising the privacy budget spent.
In order to remove some of the stated constraints, a more flexible experiment of composition is introduced [22]: Adaptive composition experiment b ∈ {0, 1} for adversary A. For i = 1, . . . , k: 1. A generates two neighbouring databases x 0 i and x 1 i and selects a mechanism M i that is ( i , δ i )-differentially private.

2.
A receives the output y i ∈ M i (x b i ) In these situations, the i and δ i of each mechanism is adaptively selected based on the outputs of previous iterations. For the adaptive composition experiment, the privacy loss of the adversary's view V = {y 1 , . . . , y k } for each pair of neighbouring databases x, y is defined as follows: where we write V i = {y 1 , . . . , y i }, that is, the adversary's view at the beginning of the i th -iteration of the adaptive composition experiment. In particular, if the adaptive composition experiment has only one iteration (k = 1), the Equation 15 is the same as the definition of privacy loss (see Equation 7).
The function COMP g ,δ g : R 2k ≥0 → {HALT, CONT} is a valid privacy filter for , δ ≥ 0 if for all adversaries in the adaptive composition experiment, the following "bad event" occurs with probability at most δ g when the adversary's view V: A privacy filter can be used to guarantee that with probability 1 − δ g , the stated privacy budget g is never exceeded. That is, fixed a privacy budget ( g , δ g ), the function COMP g ,δ g : R 2k ≥0 → {HALT, CONT} controls the composition. It returns HALT if the composition of k given DP mechanisms surpasses the privacy budget, otherwise it returns CONT. Privacy filters have similar composition theorems to the ones given above: • Basic composition for privacy filters. For any g , δ g ≥ 0, COMP g ,δ g is valid Privacy Filter, where: • Advanced composition for privacy filters. We define K as follows: 28.04 ln(1/δ g ) .
Then COMP g ,δ g is a valid Privacy Filter for δ g ∈ (0, 1/e) and g > 0, where: The value of K might be strange at first sight, however if we assume j = for all j, it remains: which is quite similar to Equation 14.
Increase privacy by subsampling. The privacy of a DP mechanism can be further improved whether instead of querying all the stored data, a random subsample is queried. That is, if an ( , δ)-differentially private mechanism is used to query random subsample from a database with n records, then an improved ( , δ ) parameters can be provided according to the type of random subsample [23]. If the random subsample of size m < n is performed without replacement then: This expression for ( , δ ) is better than the original ( , δ) in the sense that it is smaller and so is the privacy budget spent. The noise considered in such situation comes from a different source than the noise added by the DP mechanism itself. That is, the DP mechanism is adding a certain quantity of noise specified by the ( , δ) parameters to a random subsample of the database, therefore the information extracted is influenced by the individuals contained in it. This random subsample is sampled each time the DP mechanism is used, which may result in slightly different results for the same query applied multiple times, that is, a new source of noise is added to the query.
Particularly, the improvement is greatly noticeable when < 1, which makes the Gaussian Mechanism ideal, since to achieve ( , δ)-DP must be smaller than 1. That is, the Gaussian Mechanism and the subsampling methods, when applied together, can ensure a minor quantity of noise and a tinier privacy budget expenditure at the cost of accessing a small random subsampling of the data.
This technique is particularly suited for FL, where the data does not come from all the clients in each iteration, but it does from a random sample of them. Moreover, it is well suited for programs in which the privacy parameters are hardcoded, so the privacy budget must be carefully spent.

Software tools: FL and DP frameworks analysis
The high demand of AI services at the edges that at the same time must preserve data privacy has pushed the release of several software tools or frameworks of FL and DP. In this Section, we discuss the strengths and weakness of those software frameworks, we compare them and stress out their main shortcomings. 1

PySyft
PySyft 2 is a Python library for secure and private deep learning. PySyft decouples private data from model training, using FL, DP, and Encrypted Computation (like Multi-Party Computation (MPC) and Homomorphic Encryption (HE)) within the main deep learning frameworks like PyTorch and TensorFlow.
Features. It is compatible with existing DL frameworks such as TensorFlow and PyTorch. Their low level FL implementation allows developing and debugging projects with complex communication networks in a local environment with almost no overhead. It is mainly focused on providing Secure MPC through HE, it thus allows to apply computations on ciphertext which is ideal for developing FL models while preserving privately the results of the computations to the participants. Last, they offer many Python notebooks, which greatly softens the learning curve of this framework.

Shortcomings.
Its low level of FL support is missing some key features: neither it implements any dataset by default nor any model aggregation operators. Its low level implementation and the two drawbacks stated before make this framework quite complex to use, it requires a developer with a great amount of knowledge in this field to correctly assemble a FL model. While its webpage 3 advertises it implements many DP mechanisms, they are nowhere to be found. As a matter of fact, in their github documentation they state the following: "Do NOT use this code to protect data (private or otherwise) -at present it is very insecure. Come back in a couple of months".
Overview. We conclude that PySyft is a low level FL framework for advanced users which is compatible with many well-known deep learning frameworks and it does provide neither any DP mechanism nor any DP algorithm.

TensorFlow
TensorFlow implements DP and FL through its libraries TensorFlow Privacy and Tensor-Flow Federated, respectively.
Features. TensorFlow Privacy 1 is a Python library for training machine learning models with privacy for training data. It integrates seamlessly with existing TensorFlow models and allows the developer to train its models with DP techniques. In addition they have many tutorials to quickly learn how to use it.
TensorFlow Federated 2 is an open-source framework for machine learning and other computations on decentralised data. As TensorFlow Privacy, it integrates easily with existing TensorFlow Models. In addition, it has built-in many known training datasets.

Shortcomings.
TensorFlow Privacy only focuses on differentially private optimisers and it does not provide any DP mechanisms to implement your own differentially private optimisers. It does not officially support any other deep learning library and it is still not compatible with the latest TensorFlow 2.
x. In addition, it is a "library under continual development" according to its Github documentation, 3 it is not thus mature enough for production usage.
While TensorFlow Federated provides both low level and high level interfaces for FL settings and it has some high level interfaces to create aggregation operators, it does not provide any built-in aggregation operators. Last, it is not yet compatible with the latest TensorFlow 2.x.
Overview. These TensorFlow frameworks in conjunction allow us to develop FL models, but they are tied to the TensorFlow framework, which greatly denies any portability of the generated model. They are neither compatible with the latest version of TensorFlow nor they are ready for final products. In addition, it lacks of DP mechanisms to implement new privacy-preserving algorithms.

FATE
FATE 4 is an open-source project initiated by Webank's AI Department to provide a secure computing framework to support the federated AI ecosystem.
Features. It provides many interesting FL algorithms and it exposes 1 a high level interface driven by custom scripts.
Shortcomings. Its high level interface made of scripts relies too much on command line parameters and on a poorly documented domain specific language. It is unclear how to implement a low level FL model, which makes us think this framework is designed as a black box model. Their modular architecture seems quite complex. Also, it does not feature any DP algorithm, and there are no signs of future plans for implementing them.
Overview. This framework is mainly focused on FL, making one of its biggest weaknesses that it does not implement any DP algorithm, in order to improve its data protection regulation compliance. Secure computation protocols ensure that data is not eavesdropped by an adversary, but it does not ensure that individuals' privacy, roughly speaking, is preserved. In addition, it is expected to be used as a high level interface which relies on a barely documented custom language.

LEAF
LEAF 2 is a benchmarking framework for learning in federated settings, with applications including FL, multi-task learning, meta-learning, and on-device learning.
Features. This framework mainly focuses on benchmarking FL settings. It provides some basic FL mechanisms such as the Federated Averaging Aggregator and given its modular design it can be adapted to work on any existing framework. Last, it has some known built-in datasets such as FEMNIST, Shakespeare and Celeba.
Shortcomings. It does not provide any benchmark for preserving privacy in a FL setting, even though privacy must be taken into consideration as it is a desired property of many FL settings. Moreover, it does not offer as many official documentation or tutorials as the other frameworks discussed in this section.
Overview. LEAF offers a baseline implementation for some basic FL methods but its main purpose is benchmarking FL settings. However, DP benchmarks are not provided, even though nowadays privacy is a concern in most FL settings.

PaddleFL
PaddleFL 1 is an open source FL framework based on PaddlePaddle. 2 PaddlePaddle is an industrial platform with advanced technologies and rich features that cover core deep learning frameworks, basic model libraries, end-to-end development kits, tool and component as well as service platforms.
Features. PaddleFL provides a high level developer interface to develop FL models with DP. In the FL field it implements the Federated Averaging Aggregator and its secure multi-party computation equivalent. When it comes to DP, it provides an implementation of the differentially private stochastic gradient descent.
Shortcomings. This framework has little documentation. It lacks any other DP algorithm so there is great difficulty in developing alternative privacy-preserving techniques. Last, since it is based on PaddlePaddle it is not compatible with other frameworks and its little documentation which makes it really hard to use and understand.
Overview. PaddleFL provides a high level interface for some basic and well-known FL aggregators and implements a differentially private algorithm, being one of its main drawbacks that it is little documented and it does not implement any tool to easily extend its capabilities.

Frameworks analysis
The discussed software tools share some shortcomings for developing distributed AI services that preserves data privacy, which we stress out as what follows: 1. They focus on FL or DP, but they do not provide a unified approach for both of them.
2. They poorly support the own development of new DP algorithms.
3. Only the most basic federated aggregation operators are implemented.
4. They are mainly focused on deep learning models, and they do not provide support for other machine learning algorithms that may be also used in FL setting.
We summarise and compare the characteristics of the frameworks reviewed in Table 1. We conclude that a unified FL and DP framework is required, and this is the ambitious aim of Sherpa.ai FL that we present in the following section.

Sherpa.ai Federated Learning Framework
We develop Sherpa.ai FL, 1,2 which is an open-research unified FL and DP framework that aims to foster the research and development of AI services at the edges and to preserve data privacy. We describe the hierarchical and modular software architecture of Sherpa.ai FL, related to the key elements of FL and DP shown in Section 4.1. Likewise, we detail the functionalities and the implementation details of Sherpa.ai FL in Section 4.2 and Section 4.3.

Software architecture
The software is structured in several modules that encapsulate the specific functionality of each key element of a FL setting. The architecture of those software modules allows the extension of the framework in relation to the progress of the research on FL. Figure 3 shows the backbone of the software architecture of Sherpa.ai FL, and we describe each module as what follows: • data _ base: it is in charge of reading the data according to the chosen database. It is related to the data key element.
• data _ distribution: it performs the federated distribution of among the clients involved in the FL process. It is also related to the data key element and completes its functionality. • private: it includes several interfaces such as node interface which represents clients key element and other ones that allow to access and modify the federated data distributions.
• learning _ approach: it represents the whole FL scheme including the federated server model and the communication and coordination among federated server and clients. It encapsulates federated server and communication key elements.
• federated _ aggregator: it defines the software structure to develop federated aggregation operators. It is linked to the federated aggregation operator key element.
• model: it defines the learning model architectures using predefined models and their functionalities. This learning model could be any machine learning model that can be aggregated by its representation in parameters. It is related to the model key element, as we associate a model object with each client and the federated server.
• differential _ privacy: it preserves DP of the clients by specifying the data access. It is related with the DP key elements, and also with data, clients and communication FL key elements.

Software functionalities
In this section we highlight the main contributions of Sherpa.ai FL, which are summarised in a wide range of functionalities, namely: • To define and customise a FL simulation with a fixed number of clients using classical data sets.
• To define the previous FL simulation using high-level functionalities.
• To train machine learning models among different clients. Currently, Sherpa.ai FL offers support for a Keras model (neural network), and for several models from Scikit-Learn (linear regression, k-means clustering, logistic regression).
• To aggregate the information learned from each of the clients into a global model using classical federated aggregation operators such as: FedAvg, weighted FedAvg [24] and an aggregation operator for the adaptation of the k-means algorithm to a federated setting [25].
• To apply modifications on federated data such as normalisation or reshaping.
• To evaluate a FL approach in comparison with the classical centralised one.
• To preserve DP of clients' data and model parameters in the FL context. The platform currently offers support for the fundamental DP mechanisms (Randomized Response, Laplace, Exponential, Gauss), and for the composition of DP mechanisms (Basic and Advanced adaptive composition using privacy filters for the maximum privacy loss). Moreover, it is possible to increase privacy by subsampling.
In the  Thanks to the hierarchical implementation of each module, the aforementioned functionalities can be extended and customised just by adding software classes that inherit from the original software class. For example, the already available machine learning models, DP mechanisms and federated aggregation operators can be modified, or new ones can be created, simply by overwriting the corresponding methods in the classes TrainableModel, DataAccessDefinition, FederatedAggregator, respectively.

Implementation details
Sherpa.ai FL has been developed by DaSCI 1 Institute and Sherpa.ai. 2 We developed the software using Python language for the whole architecture. Furthermore, Keras 3 , TensorFlow 4 and scikit-kearn 5 APIs are employed for the machine learning part which ensures efficiency and compatibility.
It can also be run on computing devices such as CPUs or GPUs. In order to use GPUs, the right versions of TensorFlow and CUDA must be installed. For detailed installation instructions, please see the installation guide. 6,7 The framework is licensed under the Apache License 2.0, 8 a permissive license whose main conditions require preservation of copyright and license notices.

Machine learning matches federated learning. Methodological guidelines for preserving data privacy
FL is a paradigm of machine learning, but its particularities force to adapt the machine learning settings to FL. For this reason, Sherpa.ai FL functionalities outlined in Section 4 stem from the need to develop machine learning algorithms specialised for Federated Artificial Intelligence that protect clients' data privacy. However, the adaptation is not only focused on the algorithms, but also on the workflow of machine learning.
In this section, we first discuss the key aspects of distributed computing for machine learning in the federated setting. Following, Section 5.2 defines a rather specific paradigm for adapting machine learning models to the federated setting, which is followed in Section 5.3 with some remarkable exceptions to the defined adaptation. Finally, we also define the adaptation of the machine learning workflow to FL in Section 5.4 as methodological guidelines for preserving data privacy with FL using Sherpa.ai FL.

Key aspects of distributed computing for Federated Machine Learning
The recent introduction of FL [26,14,7] responds to the need for novel distributed machine learning algorithms in a setting that clashes with several assumptions of conventional parallel machine learning in a data centre. The differences are substantially origi-nated by the unreliable and poor network connection of the clients, since these are typically mobile phones. Thus reducing the number of rounds of learning is essential as communication constrains are more severe. Additionally, the data is unevenly scattered across K clients and must be considered as non-IID, that is, the data accessible locally is in any way representative of the overall trend. 1 The data is in general sparse, where the features of interest take place on a reduced number of clients or data points. 2 Ultimately, the number of total clients greatly exceeds the number of training points available locally on each client (K n/K).
In the federated machine learning setting, the training is decoupled from the access to the raw data. In fact, the raw data never leave users' mobile devices and a high-accuracy model is produced in a central server by aggregating locally computed updates. At each FL round, an update vector θ ∈ R d is sent from each client to the central server to improve the global model, with d the parameters' dimension of the computed model. It is worth noting that the magnitude of the update θ is thus independent from the amount of raw data available on the local client (e.g., θ might be a gradient vector). One of the advantages of this approach is the considerable bandwidth and time save in data communication.
Another motivation for the FL setting (but that also constitutes one of its intrinsic advantages) is the concern for privacy and security. By not transferring any raw data to the central server, the attack surface reduces to only the single client, instead of both client and server. On the other hand, the update θ sent by the client might still reveal some of its private information, however the latter will be almost always dramatically reduced with respect to the raw training data. Besides, after improving the current model by the update θ, this can (and should) be deleted.
Additional privacy can be provided by randomised algorithms providing DP [12], as detailed in Sections 2.3 and 2.4. In particular, the centralised algorithm could be equipped with a DP layer allowing the release of the global model without compromising the privacy of the individual clients who contributed to its training (see e.g., Abadi et al. [27]). On the other hand, in the case of a malicious or compromised server, or in the case of potential eavesdropping, DP can be applied on the local clients 3 for protecting their privacy [28,29,30].

The Machine Learning paradigm in a federated setting
In the following, we describe the federated machine learning paradigm by recognising some relevant attributes that ease the natural adaptation of a ML model in the federated setting.
Primarily, we observe that a great number of machine learning methods resemble the minimisation of an objective function with finite-sum as in Equation 3. The aforementioned problem structure encompasses both linear and logistic regression, support vector machines, and also more elaborated techniques such as conditional random fields and neural networks [26]. Indeed, in neural networks predictions are made through a nonconvex function, yet the resulting objective function can still be expressed as F i (θ) and the gradients can be efficiently obtained by backpropagation, thus resembling Equation 3.
A variety of algorithms have been proposed to solve the minimisation problem in Equation 3 in the federated setting, where, as mentioned earlier, the primary constrain is the communication efficiency for reducing the number of FL rounds in the aggregation of local models. In this context, another characteristic trait of the Federated ML paradigm is constituted by the intrinsic compatibility with baseline aggregation operators (e.g. Federated Averaging), and where no ad-hoc adaptation is required.
Ultimately, several of these FL algorithms have been supplied with DP [27,29,30]. We thus identify a rather important aspect of the Federated machine learning paradigm as being prone to straightforward application of the common building components of DP.
In addition, the latter feature eases the task of estimating the privacy loss in the FL rounds by the application of composition theorems for DP. 1 To summarise, a machine learning method is prone to adaptation in the federated setting if it adheres to the principles of the federated machine learning paradigm described above, namely: (1) the problem structure resembling the minimisation of an objective function as in Equation 3, (2) the attribute of easy aggregation of local models' parameters, and (3) the direct applicability of DP techniques for additional privacy. Among such machine learning models we cite neural networks [31], linear [32,33] and logistic [34] regression. 2

Models deviating from the federated machine learning paradigm
It is worth mentioning specific machine learning models whose structure only partially fits in the federated machine learning paradigm described above. Although the problem structure can still be represented by a minimisation of an objective function as in Equation  3, their adaptation to a federated setting requires additional and ad-hoc procedures.
One example is found in the k-means clustering algorithm for unsupervised learning [35,36], where the non-IID nature of the data distribution is seen as a major obstacle in a federated setting. Namely, the direct application of average aggregation is unfeasible due to potentially different number and ordering of local clusters, and more advanced algorithms need to be employed. A workable solution is to fix the number of local clusters, and apply an additional k-means clustering in the average aggregation. 1 Alternatively, one might try grouping the clients' population sharing jointly trainable data distributions, as proposed by Sattler et al. [37] in the context of deep neural networks. An additional complication is constituted by the preservation of clients' privacy. For instance, the baseline DP building components necessitate some adjustments in order to be applied. Although not in a FL context, in Zhang et al. [38] the authors adjust the Laplace noise added to each centroid based on the contour coefficients.
Another notable example is represented by the federated version of matrix factorizationbased ranking algorithms for recommendation systems [39,40]. The peculiar architecture of this algorithm involves the communication of only a portion of the update vector for improving the model, thus the round of learning implies additional communications between the central server and the clients. Moreover, the multiple communication iterations necessitates further caution with privacy loss in the DP context. A viable approach is to implement a two-stage randomised response mechanism on the local data, and to allow the clients to specify their privacy level [30].

Methodological guidelines for preserving data privacy with federated learning in Sherpa.ai FL
The experimental settings of FL and machine learning are very similar because FL is a machine learning paradigm. Nonetheless, the particularities of FL force to revise the machine learning workflow, and adapt it to FL definition. In this section, we define the workflow of FL based on the machine learning workflow, and we present it as methodological guidelines. Sherpa.ai FL comply with these methodological guidelines assuring the following of good practises in the development of AI services at the edges that preserve data privacy.
We distinguish two scenarios in FL: (1) a real one, where we do not actually know the underlying distribution of the data and (2) a simulation of a FL scenario, where it is possible to emulate a federated data distribution in order to analyse its use case. The guidelines are focused on the real FL scenario although we remark the particularities of a simulated FL experiment.
Moreover, we assume that the problem is properly formulated, that is, the data features and the target variable are previously defined and agreed upon by the clients. Based on this hypothesis, we show the scheme of the workflow of a FL experiment in Figure 4 and detail it in the following sections.

Data collection
In a real FL scenario, the data naturally belong to the clients. Therefore, data collection is generated locally at each client, which results in a distributed approach from the outset. In a strict FL scenario, the server has no knowledge at all of the data. However there is a possibility of the server having prior minor knowledge of the problem that uses as global validation or test sets. Here, we assume that the server does not have any information, which is the most restrictive and common situation.
Remark: When simulating a FL scenario in scientific research, data collection is reduced to accessing a database. The distribution of the data among clients is simulated in the data preparation step.

Data preparation
Data preparation involves two tasks: (1) Data partition, where we split data in training, evaluation and test sets, and (2) data preprocessing, where we transform the training data in order to improve its quality.
Data partition. The process of splitting data into training, evaluation and test datasets in FL is similar to centralised machine learning process with the difference of replicating the process for the data stored on each client. That is, each client dataset is split into training, evaluation and test sets.
Remark: When it comes to a FL scenario for scientific research, it is feasible to have global evaluation and test datasets by extracting them before assigning the rest of the data to the clients as local training datasets. Moreover, in a simulation it could be a good practise to use both global and local evaluation and test datasets combining both methodologies.
Data preprocessing. Preprocessing is the most tricky task in FL due to the distributed and private character of the data. The challenge is to consistently preprocess distributed datasets in several clients without any clue about the underlying data distribution.
The process of adapting centralised preprocessing techniques to federated data is timeconsuming. For those techniques based on statistics of data distributions (e.g. normalisation) it is necessary to use robust aggregation of the statistics, which is a challenge in some situations. Algorithms based on intervals (e.g. discretisation) require a global interval that includes all of them. Moreover, there are complicated methods of robust adaptation such as feature selection [41]. Because of these intricacies, it is advisable to rely on preprocessing techniques adapted to distributed scenarios.
Regarding distributed data preprocessing, we might take inspiration from different distributed preprocessing techniques that have already been developed [42]. However, most of these methods need to be adapted in order to respect data privacy. A distributed model that suits privacy restrictions is MapReduce [43]. Therefore, Big Data preprocessing techniques [44] that are interactively applicable can be adapted to a FL scenario in compliance with data constraints.
Remark: When simulating FL, it is possible to use centralised preprocessing methods before splitting the data between the clients. It is not a recommended practice, but a useful trade-off in terms of experimentation.

Model selection
This step implies besides the choice of the learning model as in any centralised approach, the choice of the parameter aggregation mechanism used in the server.
Choosing the learning model. This task consists of choosing the learning model structure stored both in the server and the clients. Clearly, the model has to correspond to the type of problem being addressed. The only restriction is that the learning model has to be representable using parameters in order to get the server learning model by aggregating local parameters. The canonical example of a learning model that can be represented using parameters is deep learning, but this is not the only one.
Remark: When we simulate a FL scenario, server learning model can be initialised using global previous information. However, in a strict FL scenario it is initialised with the first aggregation of local parameters.
Choosing the aggregation operator. We also need to choose the aggregation operator used for client parameters aggregation at this point. There are different types of aggregation operators: (1) operators which aggregate every client parameters (such as FedAvg), (2) operators which select the clients that take part in the aggregation (e.g. based on the performance) and (3) asynchronous aggregation operators (such as CO-OP).

Model training
The iterative FL training process is divided into rounds of learning, and each round consists of: 1. To train the local models on their local training dataset, 2. to share of the local parameters to the server, 3. to aggregate the parameters of local models on the server using the aggregation operator and 4. to update the local models with the aggregated global model.

Model evaluation
The evaluation of a FL model consists of assessing the aggregated model after assigning it to each client using the local evaluation datasets. After that, each client share the performance with the server which combines the local performances resulting in global evaluation metrics. Since the amount of data per client can be variable, we recommend using absolute metrics on clients (e.g. confusion matrix) and combine them on the server to get the remaining evaluation metrics.
Remark 1: When simulating FL, we can use a global evaluation dataset in order to evaluate the performance of the aggregated model. Moreover, we can use cross-validation methodologies to evaluate the model's performance by partitioning all the folds at the beginning and replicating the whole workflow for each of the fold combinations.

Remark 2:
Although it is not the purpose of FL, it might be worthwhile to evaluate the local models prior to the aggregation for measuring the customisation of the local model to each client.

Hyper-parameter tuning
We base the tuning of the hyper-parameters of the learning models on the metrics obtained in the previous step, and modify certain learning model parameters in order to improve the performance on the evaluation datasets.
Remark: According to the previously mentioned customisation, although it is not the objective of the FL, we could tune each of the local models independently according to the local evaluation performance before the aggregation in order to improve customisation.

Predictions making
The last step in the machine learning workflow, and by extension in the corresponding FL one, after the training of the learning model is to predict the label of unknown examples. Those predictions are done with test sets of each client.
Remark: When simulating FL, we can use global test dataset for prediction. Moreover, we can test local learning models prior to aggregation using instances of other clients (unknown targets) in order to measure the capability of generalisation of local models.

Illustrative cases of study
One of the main characteristics of Sherpa.ai FL is its development upon the methodological guidelines for FL detailed in Section 5.4. In this section, we show how to follow those methodological guidelines with Sherpa.ai FL through two experimental use cases, namely: 1. Classification with FL (see Section 6.1): showing how to create each of the keyelements of a FL experiment and combine them using our framework. To end with this example, we also compare the FL approach with a centralised one.
2. Regression with FL and DP (see Section 6.2): we compare the centralised with the FL approach with DP. Moreover, we demonstrate how to limit the privacy loss through the Privacy Filters implemented in Sherpa.ai FL.
For more illustrative examples of the framework use, please see the notebook examples. 1

Classification with FL
In this section we provide a simple example of how to develop a classification experiment in a FL setting with Sherpa.ai FL. We use a popular dataset to start the experimentation in a federated environment, and we finish the example with a comparison between federated and centralised approaches.

Case of study
In order to show the functionality of the software, we implement a simple and instructive case of study. We use the EMNIST 2 Digits dataset [45]. It consists of an extended version of the classic MNIST dataset which includes writings of several authors with different features. This fact provides the non-IID character to the data which is useful for the simulation of federated environments. Table 3 shows the size of the dataset.
For the simulation of the FL scenario we use 5 clients among which the instances of the dataset are distributed following a non-IID distribution. We use as learning model a simple CNN (Convolutional Neural Networks) based neural network represented in Figure  5, and as federated aggregation operator the widely used operator FedAvg. The code of the illustrative example is detailed in the following section.

Description of the code
We start the simulation with the first step of the methodological guidelines, i.e. the preprocessing of the data collection. Accordingly, we begin with loading the dataset. Sherpa.FL provides some functions to load the EMNIST Digits dataset.
[ As we see, our dataset is composed by a set of matrix of 28 by 28. Before starting with the federated scenario, we can take a look to a sample of the training data. Now, we simulate a FL scenario with a set of 5 client nodes containing private data, and a central server which is responsible to coordinate the different clients. First of all, we simulate the data contained in every client with a IID distribution of the data. [4]: iid _ distribution = shfl.data _ distribution.IidDataDistribution(database) federated _ data, test _ data, test _ labels = iid _ distribution.
→get _ federated _ data(num _ nodes=5, percent=50) As a result, we have created federated data from the EMNIST dataset with 5 nodes and using every available data. Hence, the data collection process have finished. This data is a set of data nodes containing private data. As we can see, private data in a node is not accesible directly but the framework provides mechanisms to use this data in a machine learning model.
Once data is prepared, the next step is the definition of the neural network architecture (model selection) used along the learning process. The framework provides a class to adapt a Keras (or Tensorflow) model to the framework, so you only have to create a function that will act as model builder. The following step is the definition of the federated aggregation operator in order to complete the model selection in FL. The framework provides some aggregation operators that we can use immediately and the possibility to define your own operator. In this case, we use the provided FedAvg operator. [7]: aggregator = shfl.federated _ aggregator.FedAvgAggregator() federated _ government = shfl.federated _ government.
→FederatedGovernment(model _ builder, federated _ data, aggregator) The framework also provides the possibility of making data transformation for the data preprocessing step, defining federated operations using FederatedTransformation interface. We first reshape data and then normalise it using test data mean and standard deviation (std) as normalisation parameters. If we focus our attention on test accuracy in each client, we realise that there are widely varying results. 1 This is because of the scattered nature of the data distribution, which causes disparity in the quality of training data between clients.

Comparison with a centralised convolutional neural network approach
We analyse the behaviour of the FL approach in comparison with the equivalent centralised approach, which means training the neural network represented in Figure 5 on the same data using centralised learning.
For this experiment, we use 25 clients and 10 rounds of learning with 5 epochs in both IID and non-IID scenario. For a fair comparison, in the classical approach we train for epochs FL × rounds FL epochs.

IID non-IID
Centralised approach 0.9904 0.9901 Federated approach 0.9921 0.9855 Table 4: Comparison between FL and a classical approach in both IID and non-IID scenarios distributed over 25 clients. We use 10 FL rounds of learning with 5 epochs per client.
The high performance of the federated approach stands out in Table 4. In the IID scenario, it beats the centralised approach results which shows the robustness of the approach caused by the combination of the information learned by each client. In the non-IID scenario, the federated approach gets lower results than the centralised one due to the additional challenge of non-homogeneous distribution of data across clients. However, the results are very competitive highlighting the strength of the federated approach.

Linear regression with DP
This section presents a linear regression FL simulation with DP following the methodological guidelines with Sherpa.ai FL. 1 The Laplace mechanism is used when the model's sensitivity is estimated by a sampling procedure [19]. Moreover, we demonstrate the application of the advanced composition theorem for DP for not exceeding the maximum privacy loss allowed (see Section 2.4).

Case of study
We will use the California Housing dataset, 2 which consists of approximately 20 000 samples for median house prices in California. Although the dataset possesses eight features, in this example we will only make use of the first two, in order to reduce the variance in the prediction. The (single) target is the cost of the house. As it can be observed in the code below, we retain 2 000 samples for later use with the sensitivity sampling for DP, and the rest of the data is split in train and test sets as detailed in Table 5.

Train set Test set Total
14 912 3 728 18 640 For the FL simulation we use 5 clients among which the train dataset is IID. FedAvg is chosen as the federated aggregation operator. The code of the example is detailed in the following section. In the case of applying the Laplace privacy mechanism (see Section 2.4), the noise added has to be of the order of the sensitivity of the model's output, i.e. the model parameters of our linear regression. In the general case, the model's sensitivity might be difficult to compute analytically. An alternative approach is to attain random differential privacy through a sampling over the data [19]. That is, instead of computing analytically the global sensitivity ∆ f , we compute an empirical estimation of it by sampling over the dataset. This approach is convenient since it allows for the sensitivity estimation of an arbitrary model or a black-box computer function. The Sherpa.FL framework provides this functionality in the class SensitivitySampler.
In order to carry out this approach, we need to specify a distribution of the data to sample from. This in general requires previous knowledge and/or model assumptions. In order not make any specific assumption on the distribution of the dataset, we can choose a uniform distribution. To the end, we define our class of ProbabilityDistribution that uniformly samples over a data-frame. We use the previously retained part of the dataset for sampling: class UniformDistribution(shfl.differential _ privacy.

→ProbabilityDistribution):
""" Implement Uniform sampling over the data """ def __ init __ (self, sample _ data): self. _ sample _ data = sample _ data def sample(self, sample _ size): row _ indices = np.random.randint(low=0, high=self. _ sample _ data. sample _ data = np.hstack((sampling _ data, sampling _ labels.reshape(-1,1))) The class SensitivitySampler implements the sampling given a query, i.e. the learning model itself in this case. We only need to add the method get to our model since it is required by the class SensitivitySampler. We choose the sensitivity norm to be the 1 norm and we apply the sampling. The value of the sensitivity depends on the number of samples n: the more samples we perform, the more accurate the sensitivity. Indeed, increasing the number of samples n, the sensitivity gets more accurate and typically decreases. from shfl.differential _ privacy import SensitivitySampler from shfl.differential _ privacy import L1SensitivityNorm In the above example we observed that the performance of the model has slightly deteriorated due to the addition of DP. In general, the privacy increases at expenses of accuracy (i.e. for smaller values of ).

Comparison with centralised and non private approaches
It is of practical interest to assess the performance loss due to DP in the FL context. Table  6 reports the performance metrics for the centralised model, for the FL non-private model, and for the FL differentially-private model. In all the cases, the models have learned on the train set, and the performance results have been computed over the test set. The data is IID over 5 clients in the FL cases. For the federated DP cases, different values of = {0.2, 0.5, 0.8} are used and the total privacy expense is limited at T = 4. Thus, for each case, we took the average over the total runs before the budget is expended (see discussion about advanced composition theorems for privacy filters in Section 2.4). The sensitivity is fixed, employing the value obtained from sampling above.  Table 6: Federated linear regression: comparison between the classical centralised model, the non-private FL model, and the FL model with a DP layer using the Laplace mechanism. For the DP cases, the results are the average over the total runs allowed for the maximum privacy budget T = 4. Different values of = {0.2, 0.5, 0.8} are considered, and the sensitivity is fixed. The data is IID distributed over 5 clients.
It can be observed that the centralised model and the non-private FL model exhibit comparable performance, thus the accuracy is not degraded by applying a FL approach. The application of the Laplace mechanism guarantees -DP, and the accuracy of the FL model can be leveraged by setting the value of : for higher values, lower privacy is guaranteed, but the accuracy increases.

Concluding remarks
The characteristics of FL and DP make them good candidates to support AI services at the edges and to preserve data privacy. Hence, several software tools for FL and DP have been released. After a comparative analysis, we conclude that they do not provide a unified support for FL and DP, and they do not follow any particular methodological guidelines that direct the developing of AI services to preserve data privacy.
Since FL is a machine learning paradigm, we have studied how to adapt the machine learning principles to the FL ones, and consequently we have also defined the workflow of an experimental setting of FL. The main result of that study is Sherpa.ai FL, which is a new software framework with a unified support for FL and DP, that allows to follow the defined methodological guidelines for FL.
The combination of the methodological guidelines and Sherpa.ai FL is shown by means of a classification and a regression use cases. Those illustrative examples also show that the centralised and federated setting of the same experiments achieve similar results, which means that the joint use FL and DP can support the development of AI services at the edges that preserve data privacy.
Sherpa.ai FL is in continuous development. Since FL and DP fields are constantly growing, we plan to extend the framework's functionalities by new federated aggregation operators, machine learning models, and data distributions. Moreover, new DP mechanisms such as RAPPOR [46] will be added, together with relaxations of DP such as Concentrated DP [47] or RÃl'nyi DP [48].