forked from securefederatedai/openfl
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
OpenFL roadmap update (securefederatedai#1196)
* OpenFL 1.7 roadmap update Signed-off-by: Teodor Parvanov <[email protected]> * Addressing review comments Signed-off-by: Teodor Parvanov <[email protected]> --------- Signed-off-by: Teodor Parvanov <[email protected]> Signed-off-by: Chaurasiya, Payal <[email protected]>
- Loading branch information
1 parent
c083e6f
commit 9f17643
Showing
1 changed file
with
24 additions
and
56 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,74 +1,42 @@ | ||
| # OpenFL Project Roadmap | ||
|
|
||
| This document is intended to give users and contributors an idea of OpenFL product team's current priorities, features we plan to incorporate over the short, medium, and long term, and call out opportunities for the community to get involved. | ||
| This document is intended to give users and contributors an idea of the OpenFL team's current priorities, features we plan to incorporate over the short, medium, and long term, and call out opportunities for the community to get involved. | ||
|
|
||
| ## When will this document be updated? | ||
| At a minimum once each product release - which we expect to be on a cadence of every 3-4 months. | ||
| At a minimum once each product release - which we expect to be on quarterly cadence. | ||
|
|
||
| ## 1. Features and interfaces | ||
|
|
||
| ### 1.1 Workflows | ||
| All interfaces in OpenFL support the standard horizontal FL training workflow today: | ||
| 1. The collaborator downloads the latest model from the aggregator | ||
| 2. The collaborator performs validation with their local validation dataset on the aggregated model, and sends these metrics to the aggregator (aggregated_model_validation task) | ||
| 3. The collaborator trains the model on their local training data set, and sends the local model weights and metrics to the aggregator (train task) | ||
| 4. The collaborator performs validation with their local validation dataset on their locally trained model, and sends their validation metrics to the aggregator (locally_tuned_model_validation task) | ||
| 5. The aggregator applies an aggregation function (weighted average, FedCurv, FedProx, etc.) to the model weights, and reports the aggregate metrics. | ||
| ### 1.1 Decoupling the FL specification interface from the infrastructure | ||
| The task runner interface is coupled with the the single experiment aggregator / collaborator infrastructure, and the Interactive API is tied to the director / envoy infrastructure. | ||
| The Interactive API was originally designed to be a high-level API for OpenFL, but for the cases when more control is required by users, access to lower level interfaces is necessary. | ||
| In OpenFL 1.5, we introduced the Workflow API as an experimental feature, which can be used to specify the federated learning flow, independently of the underlying computing infrastructure. The Workflow API facilitates a seamless transition from local simulation to a federated setting. Additionally, this approach offers greater control over the sequence and content of the FL experiment steps, which enables more complex experiments beyond just horizontal FL. Workflow API also provides more granular privacy controls, allowing the model owner to explicitly permit or forbid the transfer of specific attributes over the network. | ||
|
|
||
| The [Task Assigner](https://github.com/securefederatedai/openfl/blob/develop/openfl-workspace/workspace/plan/defaults/assigner.yaml#L7-L9) determines the list of collaborator tasks to be performed, | ||
| and both in the task runner API as well as the interactive API these tasks can be modified (to varying degrees). | ||
| For example, to perform federated evaluation of a model, only the `aggregated_model_validation` task would be listed for the assigner's block of the federated plan. | ||
| Equivalently for the interactive API, this can be done by only registering a single validation task. | ||
| But there are *many* other types of workflows that can't be easily represented purely by training / validation tasks performed on a collaborator with a single model. | ||
| An example is training a Federated Generative Adversarial Network (GAN); because this may be represented by separate generative and discriminator models, and could leak information about a collaborator dataset, | ||
| the interface we provide should allow for better control over what gets sent over the network and how. | ||
| Another common request we get is for validation with an aggregator's dataset after training. Today there is not a great way to enable this in OpenFL. | ||
| ### 1.2 Consolidating interfaces | ||
| OpenFL has supported multiple ways of running FL experiments for a long time, many of which are not interoperable: TaskRunner API, Workflow API, Python Native API, and Interactive API. The strategic vision is to consolidate OpenFL around the Workflow API, as it focuses on meeting the needs of the data scientist, who is the main user of the framework. Over the upcoming 1.x releases, we plan to gradually deprecate and eliminate the legacy Python Native API and Interactive API. OpenFL 2.0 will be centered around the Workflow API, facilitating a seamless transition from local simulations to distributed FL experiments, and even enabling the setup of permanent federations, which is currently only possible through the Interactive API. | ||
|
|
||
| For these reasons, we are planning to add *experimental support* for complex distributed workflows in OpenFL 1.5, with the following goals: | ||
|
|
||
| In the process of thinking about federated workflows, and the properties that are important, these are our goals: | ||
|
|
||
| 1. Simplify the federated workflow representation | ||
| 2. Clean separation of workflow from runtime infrastructure | ||
| 4. Help users better understand the steps in federated learning (weight extraction, tensor compression, etc.) | ||
| 5. Interface makes it clear what is sent across the network | ||
| 6. The placement of tasks and how they connect should be straightforward | ||
| 7. Don't reinvent unless absolutely necessary | ||
|
|
||
| ### 1.2 Security, Privacy, and Governance | ||
| OpenFL is designed for security and privacy, and soon we will be releasing some exciting extensions that allow running OpenFL experiments within TEE environments. | ||
|
|
||
| ### 1.3 Decoupling interface from infrastructure | ||
| The task runner interface is coupled with the the single experiment aggregator / collaborator infrastructure, and the interactive API is tied to the director / envoy infrastructure. | ||
| The interactive API was originally designed to be a high-level API for OpenFL, but for the cases when more control is required by users, access to lower level interfaces is necessary. | ||
|
|
||
| ### 1.4 Consolidating interfaces | ||
| Today we support three interfaces: TaskRunner, native Python API, and interactive API. These are all distinct APIs, and are not particularly interoperable. | ||
| By the time we reach OpenFL 2.0, our intention is to deprecate the original native [Python API](https://openfl.readthedocs.io/en/latest/get_started/examples.html#python-native-api) used for simulations, | ||
| bring consistency to the remaining interfaces with a high level, middle level, and low level API that are **fully interoperable**. This will result in being able to use the interface you're most comfortable with for a simulation, | ||
| single experiment, or experiment session (with the director / envoy infrastructure). | ||
|
|
||
| ### 1.5 Component standardization and framework interoperability | ||
| ### 1.3 Component standardization and framework interoperability | ||
|
|
||
| Federated Learning is a [burgeoning space](https://github.com/weimingwill/awesome-federated-learning#frameworks). | ||
| Most core FL infrastructure (model weight extraction, network protocols, and serialization designs) must be reimplemented ad hoc by each framework. | ||
| This causes community fragmentation and distracts from some of the bigger problems to be solved in federated learning. In the short term, we want to collaborate on standards for FL, | ||
| first at the communication and storage layer, and make these components modular across other frameworks. Our aim is also to provide a library for FL algorithms, compression methods, | ||
| that can both be applied and interpreted easily. | ||
|
|
||
| ## Upcoming OpenFL releases | ||
| ### 1.4 Confidential computing support | ||
| Although OpenFL currently relies on Intel® SGX for trusted execution, the long term vision is towards broader confidential computing ecosystem support. This can be achieved by packaging OpenFL workspaces and workflows as Confidential Containers (CoCo), which supports a spectrum of TEE backends, including Intel® SGX and TDX, Arm TrustZone, and AMD SEV. | ||
|
|
||
| ### OpenFL 1.6 (Q4 2023) | ||
| 1. Use the OpenFL Workflow Interface on distributed infrastructure with the [FederatedRuntime](https://openfl.readthedocs.io/en/latest/about/features_index/workflowinterface.html#runtimes-future-plans) | ||
| 2. LLM Support | ||
| 3. New use cases enabled by custom workflows | ||
| * Standard ML Models (i.e. Tree-based algorithms) | ||
| 4. Federated evaluation documentation and examples | ||
| 6. Significantly improved documentation | ||
| ## Upcoming OpenFL releases | ||
|
|
||
| ### OpenFL 2.0 (2024) | ||
| 1. Interface Cohesion | ||
| * High level interface: Interactive API | ||
| * Low level interface: Workflow API | ||
| 2. Decoupling interfaces from infrastructure | ||
| 3. Well defined interfaces intended for building higher level projects on top of OpenFL | ||
| ### OpenFL 1.7 (Q1 2025) | ||
| This release is focused on enabling a great developer experience for OpenFL users: | ||
| 1. Introducing the [FederatedRuntime](https://openfl.readthedocs.io/en/latest/about/features_index/workflowinterface.html#runtimes-future-plans) for Workflow API, which allows running FL workflows in a distributed setting (after local simulation with the LocalRuntime). | ||
| 2. Adding support for federated XGBoost in OpenFL. See the example [XGBoost workspace](https://github.com/securefederatedai/openfl/tree/develop/openfl-workspace/xgb_higgs) based on Task Runner API. | ||
| 3. Revised Task Runner API workspace dockerization process, with TEE-ready containers (using Gramine and Intel® Software Guard Extensions). The current release contains an initial set of changes that enable OpenFL compatibility with the broader confidential containers ecosystem. | ||
| 4. Streamlining the Federated Evaluation experiments with TaskRunner API | ||
| 5. Migrating a selection of key OpenFL tutorials from Python Native API to Workflow API. Check out the updated [Tutorials folder](https://github.com/securefederatedai/openfl/tree/develop/openfl-tutorials/experimental/workflow) | ||
| 6. Deprecating the Python Native API | ||
| 7. Deprecating the Interactive API | ||
|
|
||
| ### OpenFL 1.8 (TBA) | ||
| Stay tuned for updates soon! |