 Hello, thank you for coming to this talk. Today I'm going to talk about OpenFL, which is a project related with federated learning. It was initially developed by Intel, and now it's part of the Linux Foundation. But before I start talking about federated learning, I would like to talk about the models. So when we are training models, we need more data to improve the performance of those models. So even if the model is large, even if it's a large model, or if it's a traditional machine learning model, we need more data to improve our accuracy. But the thing is that even if we improve this amount of data, we can have the problem that the data could be biased in our model. So we need to have a lot of data, or multiple data, and also this data, it has to be diverse. And this is the challenge. Suppose that you have a bank, or if you are working in a health care system, you probably would need to use other information from other banks, from other health care systems, and so on to improve your model. You can try to do it with your own data, but it would be even better if you can use other data. But if we would like to do that, we can have challenges, because probably, like in this case, let's suppose that we are here in Canada, and we would like to use data that it's in Europe, or it's in China. And we can face some problems, because if we are working in a centralized way, we need to download all the data to the same point. I mean, I suppose that we are in Canada, and we need to download the data from Europe to Canada, from China to Canada, and so on. And it comes with challenges, because we have just to mention one of the problems that we can have. The data could be legally protected. So if we talk about health care, for instance, you cannot move the data from one country to another country. So it's a challenge if you would like to use this data. Or if the data is sensitive, if you are working with different banks, probably you don't want to share the data to other banks, because it's your data. I mean, it took years for you to join this data. Or it's too valuable. Or we have the data silo problem that if the data is huge, let's suppose that we have terabytes in one side and the other side, and if we need to download this data, or if we need to put this data in one centralized place, it could be expensive to download this data or to move the data from one silo to another one. So fortunately, what we have is federated learning that it comes to solve most of those problems. So instead of using a centralized way to train an algorithm, we can do the training in a federated way. Instead of training in one place, you can train the model in multiple ways. But it also comes with a problem because we need to be aware of the security. If we are moving the data from one country to another country, we need to be sure that the data is safe. I mean, it's not modified. So it's not just distributing the training. It's also about trying to secure this process and try to have additional mechanisms to make it more safer. If we compare, and this is how we, if you are working with machine learning or with AI, this is the way that you probably are training your models today, right? You have the data, let's suppose in free institutions, or in free countries, or in free banks, and you have to centralize the data in one place, right? So you have, let's suppose that you are in the aggregation side, that is your data center, could be right here, and if you'd like to train models, you need to download the data, right? So the data will come to your model and you will train it in a centralized way. So you can imagine that we can have a problem moving the data from institution one, institution two, and institution three to the centralized side. Which federated learning does is instead of moving the data from the institutions, we just move the models. So we train the data in each institution in which, and the model travels to the aggregator. So it's very important because now, if data is not moving, the data is in the place where it resides or where it lives, and the only thing that is modifying or is moving from the data, from the places to the centralized server is the model. Technically, it's the weight of the model, because if you have a, let's suppose an algorithm or machine learning to detect something in computer vision or whatever, you have the same model, so they may share the weight because they are trained in the same way with the similar data. So this way you can share the data between institution one, institution three, and also from the aggregator. How you can do that? We have, well, this is the open FL, which is a framework, and that is basically, it comes to help in that process, because you can do it, you can start thinking, okay, I would like to train in a federated way, but of course you need a framework to do it, right? So open FL is one of the frameworks available, and now it's part of the Linux Foundation. It was transitioned from, it was in March, I think. As I said at the beginning, it was initially developed by Intel, five years ago, six years ago, and when Intel decided to donate the project to the Linux Foundation, it was always a community-driven project, right? But now it's part of the Linux Foundation. So since we are Intel, we are embracing the open source concept and the open source mindset. We are doing that with these kind of projects. The main difference between, or the main value that open FL can bring is we have three main pillars. The first one is the privacy. So it adds or it provides additional mechanisms to make the conversation between the aggregators and the collaborators, or when you are moving the weights from one side to another side, it adds additional mechanisms to make it safer. I mean, it's not just TLS encrypted, it's TLS plus another more things that are also added here. I don't wanna go in details because it's pretty technical, but think just keep in mind that it's providing an extra layer of security. And the other one it's pretty easy to use. Easy to use, it's scalable. If probably if we as a data scientist is if you are working with a new framework, you don't want to learn a new language to learn everything, right? So if you have an API or if you have a framework that's pretty easy to use, it may help you to start adopting those kind of algorithms, right? And the way to use it is you can download in GitHub, pip install, and we have also our containers version, so you can download the containers and everything. And talking about security is these are the main, I just wanted to mention the main two problems that we can face when we are working in a federated learning environment. The first one is an attacker could poison the weights while they are traveling from 1.8 from 0.2, they can attack the weights and they have a way to access to the data. I mean, they made poison in the weights, they ingest that in the model in the process, and they have a way to access to the data. So even if we are using the vanilla way to use the federated learning frameworks, we are vulnerable to this kind of attacks. And the other one that is pretty important is that, as I said, if the model is going from one collaborator to the aggregators, we have the same model present in all the points of my federated learning, on my federated framework. So we can have the risk to someone who could probably steal our model in a collaborator because the weights are presented in all the points of the federation. So this is another process that is very important that we need to be aware of when we are working in federated environments is that we need additional processes to try to ensure that. How it works, it's a good animation, I mean, I like it, I just wanted to show you is like to see how it works, right? So we have the data, the data, it's encrypted, and it goes from the collaborator to the aggregator. The aggregator puts together all the weights, made weighted average of the weights, and has a new version of the model. And when they have the second round, and when I like to retrain the model in a second round, they send the model again to all the other collaborators. All the processes, it's encrypted, and the important thing is that whilst processed, it's also encrypted, it's also in a secure way, right? So this is enabled thanks to a feature that Intel chips provide, that is LGX, that is the part of the Confederation computing, that it's not just about the, protecting the data while it's in transit. So it's also protecting the data while it's processed, right? So it's not in the same, it's an additional layer. So I wanted to show a demo, a really brief demo, to show how it works. Just to explain what I will be showing is that we will have an aggregator, that the aggregator is the main part of the federation. He's capturing all the weights from all the other nodes or aggregators, and it's doing the weighted average of the model to get it updated. So what we'll have is an aggregator, and we have two nodes that can be, now they are running in my PC, but the reality is that in a real environment, it could be in different countries or in two countries or three countries, right? So let me, it should work. I should make it higher, right? It's okay, yeah. Here we go, this is right here. I need to change the fonts. So let's see, we have in the left, right here we will have the aggregator. Let's see, let's see here. And right here we will have the collaborators, and that's it, oh, it's not so big, but as I said, what we will do is, I will just pick the aggregator, which is the team that is centralizing. So what, how we will work in the beginning is we need to create a plan, right? We need to create how the federation will work and how it will be doing, right? So for that, we need to go to OpenFL, provide an API that you can use, you can use it in an API if you're working with Python or, yes, with Python. You can develop your own application or you can use the API that the algorithm gives. So if we do, for instance, federate effects minus, minus help, these are all the things, I mean, it's a bit complicated, but you can see that we have the workspace commands, the plan commands, the tutorials and so on. What we have is we have some tutorials that you can download and you have all the workspace downloaded for you to use it. So in that case, we'll have, put it here, we'll be training a CNN MNIST model. It's pretty easy, I mean, it's pretty simple, but it's not the idea to go in the details of the model, but it's running on PyTorch, so it's framework agnostic. You can train your models in PyTorch or TensorFlow. And if you go, we have some pretty cool files to see here. So if you go to see the plan, you can check the plan here. We can see, for instance, that we have all the configuration that each aggregator will take. Like, for instance, what will be the batch size of the model, what will be the model resides, what will be the address of each aggregator or each collaborator. So you are centralizing, but you also need to communicate to the other aggregator. So you need the FQN, FQDN, so the model can communicate to the other aggregators. And basically, what you define here is when we are starting that, we are saying, this is the model, this is how we are training the model. These are the parameters that all the models, all the collaborators will share, and we will agree on that. And it's also what you define here is how you would like to make the, how you would like to update your weights. Because in the first round, let's suppose that you train a model in the collaborator one or collaborator two, and they will send the models to the aggregator. And the aggregator, they should decide to see, okay, I would like to update the weights in a weighted average. I would like to put more importance in this node or this other node, and so on. These are all the things that you can define when you are working on, when you are defining your federator plan. The second good option to show is, if we go to the workplace, we can see the configuration of the algorithm, right? It's, of course, not to go in the details of all this stuff, but it's as usual when you train a model. It's the same thing. The only thing is, if you are probably aware about Biotorch, when you download your model, you need to use the model class, for instance. What OpenFL does is, instead of using this class, you can use a class that is defined by OpenFL, that is probably, it's the same, but underneath, it configures, like, for instance, how you can send, how you can share your weight or when you will update your model, and so on. So all these details, you have in that thing. And once you have it there, when you are defining the plan, all these files, we need to encrypt those files and you need to send the workplace to each collaborator, right? So here we go. Now what I will do is, I will start the plan. And what it does here is, it prepares this workspace module, right? If you put in one file, the model, the plan, and all the parameters that you can send to all the other collaborators, right? So I will not move to the other collaborators, but the files are there, right? I suppose that you do it offline, and it's in the aggregator, and it's also there for the other aggregator. But it also has a very important part, as I said at the beginning, security is the main goal of this framework. So what you can do is, it comes internally with a certificate authority, so you can use the certificate authority to sign all the certificates between the collaborator and the other aggregators. So it's pretty easy. You can use workspace, certificate, and you can validate that, let me clear. Workspace, certify. And it is that, the, FX aggregator, because I would like to certify the aggregator, certify, right? So it asked me if I would like to sign the certificate and it's now done. Now let's suppose that we are in the aggregator, and what we will do it will be generating a certification, a certificate request, a CSRA. So let's suppose that we have the collaborator, we will like generate a cert request for the collaborator once, right? So it will be generating a certificate to, and we will do the same for the second one, right? Now that we have both certificate requested, we will need to go to the CA so they can sign our certificates. Now we do collaborator, or yes, collaborator, collaborator, certify minus I, right? And now you are validating your certificate. What it will do right here is if you are working in another environment, in a real environment, you will probably send certificate out of bounds to the collaborators. And this is what I have already downloaded to the other parts of the certifications. So we have everything ready, we have all the plans, the plan is downloaded in each collaborator, the plan is ready in the aggregator, the certificates are ready to all the points of the certification, of the federation. What we will do now is we could start with our federated process, right? So what we can do is I will start with the collaborator, I will be starting the process, or the server, start, this is the one, and you can see here, right over here, it says that it is waiting for tasks. So the model will not start to do anything until the aggregator says, okay, you should start training, you should, this is your first round, this is your second round. So until they don't receive this information, they just can stand by waiting for instructions, or what is to do something. I will start, I started the first collaborator, I will do the same with the second one, and it's also, do the same, it's waiting for tasks. And what I will do now is I will start the aggregator, and now the aggregator that has the plan, he will say, okay, he will talk to the collaborator one, I will say start training in the round one model, and they will do the same with the second collaborator, right, so it's starting the process, it probably will take a time. It starts a GRPC server, because of communication between all the others, all the others, between the collaborators and the aggregators, each using a GRPC server. So if you see in that part, he said, okay, he received how to train the model, how they would do with the weights, and this is another configuration that is in the details of this class that each model uses, is that they need to know how they will update the weights, so you can define that internally in each particular process. So if you see here, it's already training over there, and in the left side, and, oh, sorry, in the right side, it's sending the task to the other one to start working on that. So it probably will take time because I'm running that on my PC, but if you work that in another, I don't know, probably in a cloud-provided services or in another provided services, it's probably much faster compared with my PC. And it runs, it works round after round, and it will be updating the weights, and you will see how the accuracy is working between how it's improving between one and the other one. And this is the demo, I just wanted to finish explaining that since OpenFL is an open source project and in multiple companies, they are using the project, so we did, just to mention some of you, we did things with VMware because they contributed and optimized an compression for the pipeline when you are sending the model from one point to another point, they added the compression, they added a compression weight to send the weights between one model and the other model. And we did a great, the University of Pennsylvania, they did a great job trying to do the largest validation healthcare process for tumor detection. They had a lot of data distributed in multiple countries, and they used OpenFL to train a model to detect tumor cancer. And the other that's pretty interesting is the NASA one, it's not the problem to use the data because they have the access to all the data, but the problem is that some data, it's not in the planet, right? So it's outside, so the problem that we have here is with this data is in silos, so downloaded data from a satellite or another planet, it could be a bit difficult and it could be harder and it could be expensive if we like to download this data. So OpenFL helped in that way because it helped it to train a model to detect something within the NASA and that is private, but we help on that because they can train a model, things that they have a federated learning process and because they would like to use in the traditional way, it could be pretty expensive if they would like to use it or to download the data. So as I said, the goal to action is if you are savvy or if you like to solve problems, we are OpenFL, it's an open source project, so go to the GitHub, try to pick some issues, try to solve the issues, if you want to be involved, we have a lot of tutorials, like this thing that I showed about Open, about CNN and M&S, we have a lot of different tutorials in bytes or in terms of low NLP computer vision, a lot of them that can give you an idea on how you can build your own federated learning process and we have read our blog post, explaining how the technology works and we are launching release after release, we are adding more security features that are provided by universities that are doing research and they donate all the things to the project. Check our documentation, if you'd like to learn about OpenFL, about how you do the federation, you can go online and you can see the sites and we have virtual community meetings every month, one for Europe time and the other one for Latin America, for North American time, so we are pretty open, we are thinking on adding some hackathons, we did some internal with some communities, some kind of hackathons for federated learning, which is pretty interesting, pretty nice, so if you are interested in that, we can try to think on that, so that's it, thank you so much, I'm open to questions, if you have any questions in it out, so thank you so much for your time, really appreciate it. For each collaborator, do they all have the same copy, the same model, but they all have different data and they're training it and it's aggregated, or can you segment the model and say collaborator, A and B, you train this section of it, and C and D, you train these ways and then the aggregator things them together. Thank you, yeah, that's a very good question. We can divide, the answer could be in two parts, the first one is you have horizontal federated learning and vertical federated learning, right, so when you're working with horizontal federated learning, you have the same data, it's not the same data, because it's distributed, but really I suppose that you have to explain in a very easy way, I suppose that you have a spreadsheet and you have the features as a columns and you have the rows as a timestamps or whatever, right, so in an horizontal, you have the same features distributed in all the collaborators, so how you distribute the data, of course we depend on which data is available for each particular collaborator, but the horizontal is you have the same shape of the data for the same things distributed between all the collaborators. The other option that is something that we are working on that is the vertical federation, that is instead of having all the features distributed in all the other collaborators, you have, as you said, you have a set of features in one collaborator, a set of other features in other collaborators and you put it together in a way so they can learn about it, yes, but you can use with both of them, could be horizontal, could be vertical, and they, yes, they are training in the same environment, yes, thank you so much for the question. Thank you for the talk, I have a question, how does OpenFL compare to other federated learning frameworks like Flour, for example, and why should I start using OpenFL and contribute to it? Awesome, great, good question. We work with Flour, the main difference between OpenFL, it's not a difference, I think that they are complementary, that we add this security layer that you probably don't get it on Flour, so we work with them, I think that they are pretty complementary because we add these mechanisms, as I said, the Confidation Computing mechanisms and all these security part, this is the main difference of OpenFL compared with the other ones, and also I could say that it was initially developed for healthcare, so if you have a new case that it's working with something similar with healthcare, you can use OpenFL for that because it was initially developed for that, of course it's not the main use case, now it's working with all the others use case, and this is why we need the community and we invite the community to provide new features and so on, but yes, this is a really different, and if you see the, once we donated the project to the Linux Foundation, initially our project was github.int-slash-intel-slash-OpenFL, and they changed the name of the folder to say secured federated AI-slash-OpenFL, so this is the main difference between the other ones. Thank you. You're welcome. All right, thank you. Thank you so much for your time, and I hope to see you. Thank you.