├── .gitignore ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── FATE_Project_Technical_Charter.pdf ├── FederatedAI_PROJECT_PROCESS_GUIDELINE.md ├── GOVERNANCE.md ├── LICENSE ├── PROPOSAL_TEMPLATE.md ├── README.md ├── RoundTable_slides ├── 10期圆桌会-2021.05.26.pdf ├── 11期圆桌会-2021.06.24.pdf ├── 12期圆桌会-2021.08.26.pdf ├── 13期圆桌会-2021.09.16.pdf ├── 14期圆桌会-2021.10.27.pdf ├── 1期圆桌会-2020.06.03.pdf ├── 2期圆桌会-2020.07.14.pdf ├── 3期圆桌会-2020.08.27.pdf ├── 4期圆桌会-2020.09.28.pdf ├── 5期圆桌会-2020.11.25.pdf ├── 6期圆桌会-2020.12.23.pdf ├── 7期圆桌会-2021.01.21.pdf ├── 8期圆桌会-2021.03.12.pdf └── 9期圆桌会-2021.04.22.pdf ├── SECURITY.md ├── SIGs ├── InterOP │ ├── FATE-sigInterOP-minutes-20220316.md │ └── README.md ├── Multiplatform │ └── README.md ├── README.md └── Security │ ├── Meeting-minutes-2022-03-22.md │ └── README.md ├── TSC Board.md ├── TSC MAINTAINERS.md ├── meeting-minutes ├── FATE_Dev_Meeting │ ├── FATEDevMeeting20220210.pdf │ ├── FATEDevMeeting20220224.pdf │ ├── FATEDevMeeting20220310.pdf │ ├── FATEDevMeeting20220324.pdf │ ├── FATEDevMeeting20220407.pdf │ ├── FATEDevMeeting20220421.pdf │ ├── FATEDevMeeting20220512.pdf │ ├── FATEDevMeeting20220601.pdf │ ├── FATEDevMeeting20220616.pdf │ ├── FATEDevMeeting20220630.pdf │ ├── FATEDevMeeting20220714.pdf │ ├── FATEDevMeeting20220804.pdf │ ├── FATEDevMeeting20220825.pdf │ └── README.md ├── TSC_Board_Meeting │ ├── 2021-12-02 │ │ └── TSC-Board-Meeting-20211202.pdf │ ├── 2022-01-20 │ │ └── TSC-Board-Meeting-20220120.pdf │ ├── 2022-06-23 │ │ └── TSC-Board-Meeting-20220623.pdf │ ├── 2022-08-11 │ │ └── TSC-Board-Meeting-20220811.pdf │ └── 2023-01-12 │ │ ├── TSC-Board-Meeting-20230112.pdf │ │ ├── TSC-Board-Member-Summary-CN.pdf │ │ └── TSC-Special-Committee-Summary-CN.pdf └── TSC_Meeting │ ├── 2020-01-15 │ └── minutes.md │ ├── 2020-06-10 │ └── minutes.md │ ├── 2020-10-21 │ └── FATE- TSC第三次会议.pdf │ ├── 2020-12-29 │ └── FATE- TSC第四次会议.pdf │ ├── 2021-04-01 │ └── FATE- TSC- 2021 Q1.pdf │ ├── 2021-06-24 │ └── FATE- TSC- 2021 Q2.pdf │ ├── 2021-11-11 │ └── FATE-TSC-2021-Q4.pdf │ └── 2022-03-17 │ └── FATE-TSC-2022-Q1.pdf └── proposal ├── 1.10.0 ├── KubeFATE_v1.10.0_new_feature_list.md └── fate-feature_list.md ├── 1.7.2 └── feature_list.md ├── 1.8.0 ├── KubeFATE_v1.8_new_feature_list.md └── feature_list.md ├── 1.9.0 ├── KubeFATE_v1.9_new_feature_list.md └── fate-feature_list.md ├── PROPOSAL_Eggroll.md ├── PROPOSAL_FATE-LLM.md ├── PROPOSAL_FedIPR.md ├── PROPOSAL_HARDWARE_ACC.md ├── PROPOSAL_HIGHFLIP_FATE_Adatper.md ├── PROPOSAL_PAILLIER_SCHEME_IPCL.md ├── architecture.jpg └── images ├── 163323639-4f33b5ad-3247-47d4-b385-680842181d00.png ├── 163324216-795479e1-0356-46b2-8e28-c0739e2bf356.png ├── 163325531-e248f3fe-6e7a-43c6-9788-c66ca6d514a6.png ├── FATE-LLM ├── FATE-LLM-plan.png └── FATE-LLM-roadmap.png ├── eggroll.png ├── fedipr ├── ar_1.jpg ├── fig5.png ├── fig6.png ├── fig7.png ├── paper.jpg └── t_1.png └── highflip └── fate_adapter.drawio.png /.gitignore: -------------------------------------------------------------------------------- 1 | .DS_Store 2 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Contributor Covenant Code of Conduct 2 | 3 | ## Our Pledge 4 | 5 | In the interest of fostering an open and welcoming environment, we as 6 | contributors and maintainers pledge to making participation in our project and 7 | our community a harassment-free experience for everyone, regardless of age, body 8 | size, disability, ethnicity, sex characteristics, gender identity and expression, 9 | level of experience, education, socio-economic status, nationality, personal 10 | appearance, race, religion, or sexual identity and orientation. 11 | 12 | ## Our Standards 13 | 14 | Examples of behavior that contributes to creating a positive environment 15 | include: 16 | 17 | * Using welcoming and inclusive language 18 | * Being respectful of differing viewpoints and experiences 19 | * Gracefully accepting constructive criticism 20 | * Focusing on what is best for the community 21 | * Showing empathy towards other community members 22 | 23 | Examples of unacceptable behavior by participants include: 24 | 25 | * The use of sexualized language or imagery and unwelcome sexual attention or 26 | advances 27 | * Trolling, insulting/derogatory comments, and personal or political attacks 28 | * Public or private harassment 29 | * Publishing others' private information, such as a physical or electronic 30 | address, without explicit permission 31 | * Other conduct which could reasonably be considered inappropriate in a 32 | professional setting 33 | 34 | ## Our Responsibilities 35 | 36 | Project maintainers are responsible for clarifying the standards of acceptable 37 | behavior and are expected to take appropriate and fair corrective action in 38 | response to any instances of unacceptable behavior. 39 | 40 | Project maintainers have the right and responsibility to remove, edit, or 41 | reject comments, commits, code, wiki edits, issues, and other contributions 42 | that are not aligned to this Code of Conduct, or to ban temporarily or 43 | permanently any contributor for other behaviors that they deem inappropriate, 44 | threatening, offensive, or harmful. 45 | 46 | ## Scope 47 | 48 | This Code of Conduct applies both within project spaces and in public spaces 49 | when an individual is representing the project or its community. Examples of 50 | representing a project or community include using an official project e-mail 51 | address, posting via an official social media account, or acting as an appointed 52 | representative at an online or offline event. Representation of a project may be 53 | further defined and clarified by project maintainers. 54 | 55 | ## Enforcement 56 | 57 | Instances of abusive, harassing, or otherwise unacceptable behavior may be 58 | reported by contacting the project team at contact@fedai.org. All 59 | complaints will be reviewed and investigated and will result in a response that 60 | is deemed necessary and appropriate to the circumstances. The project team is 61 | obligated to maintain confidentiality with regard to the reporter of an incident. 62 | Further details of specific enforcement policies may be posted separately. 63 | 64 | Project maintainers who do not follow or enforce the Code of Conduct in good 65 | faith may face temporary or permanent repercussions as determined by other 66 | members of the project's leadership. 67 | 68 | ## Attribution 69 | 70 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, 71 | available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html 72 | 73 | [homepage]: https://www.contributor-covenant.org 74 | 75 | For answers to common questions about this code of conduct, see 76 | https://www.contributor-covenant.org/faq 77 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing Guide 2 | 3 | FATE is an inclusive and open community. We welcome developers and users who are interested in making FATE better! Contributions of all types are welcome — opening issues, fixing typos, adding examples, bug fixes, or entire features. 4 | 5 | If you plan on contributing, please go through the existing issues and PRs to ensure no one else has been working on something similar. If no similar feature exists, please open an issue to describe what you plan to do. In this way, you can get feedback from the maintainers and the community. After an agreement has been reached between you and the community, you can start your implementation and contribute your code when you are done. 6 | 7 | You can contact the maintainers by email (FedAI-maintainers @ groups.io) if needed. 8 | 9 | This document covers the genernal guideline about contributing to FATE projects. 10 | However, there are different guidelines in different repositories of FATE. Please do read about the contributing guidelines of each repository to understand the process to participate. 11 | 12 | Please note, any contribution and interaction on any FATE projects MUST follow the [Code of Conduct](./CODE_OF_CONDUCT.md). 13 | 14 | ## Developer Certificate of Origin 15 | 16 | All FATE repositories enforce the Developer Certificate of Origin (DCO) on Pull Requests(PR). It requires all commit messages to contain the `Signed-off-by` line with an email address that matches the commit author. The DCO is a lightweight way for contributors to certify that they wrote or otherwise have the right to submit the code they are contributing to the project. Please make sure you have **signed every commit** with DCO. If your PR fails the DCO checking, your contribution cannot be accepted. 17 | 18 | Contributors *sign-off* by adding a `Signed-off-by` line to commit messages. 19 | 20 | ``` 21 | This is my commit message. 22 | 23 | Signed-off-by: Random Developer 24 | ``` 25 | 26 | The Git command has a `-s` command line option to append DCO automatically to your commit message: 27 | 28 | ```sh 29 | $ git commit -s -m 'This is my commit message.' 30 | ``` 31 | 32 | If you are not familiar with DCO, please check [this website](https://www.dita-ot.org/dco) for more information. 33 | 34 | 35 | ## License 36 | Please include a license at the top of new files your will be contributing. A license example is listed below. 37 | 38 | ``` 39 | # 40 | # Copyright 2019 The FATE Authors. All Rights Reserved. 41 | # 42 | # Licensed under the Apache License, Version 2.0 (the "License"); 43 | # you may not use this file except in compliance with the License. 44 | # You may obtain a copy of the License at 45 | # 46 | # http://www.apache.org/licenses/LICENSE-2.0 47 | # 48 | # Unless required by applicable law or agreed to in writing, software 49 | # distributed under the License is distributed on an "AS IS" BASIS, 50 | # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 51 | # See the License for the specific language governing permissions and 52 | # limitations under the License. 53 | # 54 | ``` 55 | 56 | ## Contact 57 | If you have questions regarding the contributing process, please contact [maintainers](https://github.com/FederatedAI/FATE-Community#getting-involved) for assistance. 58 | 59 | -------------------------------------------------------------------------------- /FATE_Project_Technical_Charter.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/FATE_Project_Technical_Charter.pdf -------------------------------------------------------------------------------- /FederatedAI_PROJECT_PROCESS_GUIDELINE.md: -------------------------------------------------------------------------------- 1 | # FederatedAI Project Process Guideline 2 | 3 | ## Goal 4 | The purpose of this document is to define the base guidelines of common project management for all projects hosted in FederatedAI. According to the TSC board, all projects in FederatedAI should follow stated governance processes, this document specifies the practices corresponding to them. 5 | 6 | ## No-Goals 7 | This document does not cover all details of managing a project. Flexibility is a must for the project manager to set out according to the actual situations of different projects. 8 | 9 | ## Roles 10 | * Project lead 11 | * Project manager 12 | * Feature developer 13 | 14 | ## Project Management Processes 15 | ### Release 16 | * Major release means a release consists of major new features and/or large architectural changes. It indicates the tenth place. e.g. 1.7, 1.8, 1.9, etc. 17 | * Minor release means a release merely a revision or a bug fix release. It indicates the hundreded place. e.g. 1.7.1, 1.7.2, etc. 18 | 19 | ``` 20 | #.#.# 21 | (Integer release).(Major release).(Minor release) 22 | ``` 23 | 24 | The community maintains the latest 2 major releases. Each major release, only maintains the latest minor release. 25 | 26 | ### Git 27 | Gitflow (what FATE project using) is recommended: 28 | * The project lead creates a *release developing branch* for initial a new release following practices: develop-%{release}%; 29 | * The feature developer creates a new *feature branch* for developing a new feature; 30 | * The project lead is responsible for managing PRs merge to the *release developing branch* with SIG on Security (SIGoS)' approval; [Ref: Before merging a PR to the *release developing branch*](#before-merging-a-pr-to-release-developing-branch); \* 31 | * The project lead PRs from the *release developing branch* to the *master branch* with the community's approval [Ref: Before release](#before-release); 32 | * The project lead publishes release from the *master branch*. 33 | 34 | > **_NOTE:_** the project lead decides if contributor PR to the *feature branch* or the *release developing branch*. This document ignores the flexibilities in the following sections. 35 | 36 | All commits must be signed by the contributor. A GPG sign is a plus. 37 | 38 | ### Development processes 39 | All FederatedAI projects. All features, bug fixes should be added to Github issues. All PRs should be linked to related issues. The PR should be set to require review. 40 | #### Gather requirements and issues 41 | All feature requirements come from Github issue -> Feature request. 42 | Each project must add a *Feature request* template to the project repo. 43 | 44 | The significant modifications expect a design proposal submitting to FederatedAI projects, for example: 45 | * Adding a new subproject, application, dependency or component 46 | * Any large-scale refactoring of existing subprojects or applications 47 | * Substantial changes to a public API, UX or UI 48 | 49 | Besides, the project lead may ask for a design proposal of feature contribution. 50 | 51 | The issue of *Feature request* should be updated to add the link of the corresponding design proposal once existed. 52 | 53 | ##### Design proposal workflow (Optional) 54 | The workflow for submitting and reviewing a new proposal is as follows: 55 | 1. A markdown file (\*.md) will be drafted for the proposal using [the template](https://github.com/FederatedAI/FATE-Community/blob/master/PROPOSAL_TEMPLATE.md); 56 | 2. A PR will be filed against [FATE-Community](https://github.com/FederatedAI/FATE-Community) in the folder *[proposal](https://github.com/FederatedAI/FATE-Community/tree/master/proposal)*; 57 | 3. The proposal will be announced in the community, and the related project will organize the meeting to discuss it; 58 | 4. Review and feedback take place on the PR, in standard PR review fashion; 59 | 5. At the end of the review period, a vote will be held. This vote will also take place on the PR. Different kinds of proposals should be different reviewers: 60 | - For the proposal of new subproject or matters across projects, the reviewer should be more than half of the FATE OSS Development Team members "approve" votes, the proposal will be accepted and added to the community repo; 61 | - For the proposal affected only one project, one reviewer is assigned by TSC board "approve" vote and the project leads "approve" vote, the proposal will be accepted and added to the community repo. 62 | The PR will be merged, and the label *accepted-proposal* will be added to the PR. 63 | 6. If a proposal is voted down, the PR will be left unmerged, and the label tabled-proposal will be added to the PR. 64 | 65 | #### Discuss and created a development plan 66 | In each release, the project manager should filter the issues of *feature requests* and organize a meeting to gather all issues (features), and PR the *"Develop_%{release}%_Features_List"* to the [FATE-Community](https://github.com/FederatedAI/FATE-Community) *Features_List* folder. The *"Develop_%{release}%_Features_List"* should include the feature, issue id for tracking. 67 | 68 | The project manager should organize the review meeting if necessary. 69 | 70 | At the end of the review period, a vote will be held. This vote will take place on the *"Develop_%{release}%_Features_List"* PR. If the PR of release features list receives more than half of the "approve" votes and the project leads "approve" vote, the feature list will be accepted and added to the community repo. The PR will be merged, and the label *accepted-proposal* will be added to the PR. 71 | 72 | After the release features list review, the *"Develop_%{release}%_Features_List"* will be triaged to stories or tasks and add them to *Github projects*. All approved issues (features) and their status should be found in related *Github projects*. 73 | 74 | The SIGoS labels *security_check_required* to the issues (features) which need special security checks during the review period. 75 | 76 | #### Dev plan tracking 77 | The project manager hosts the bi-weekly meeting and introduces the project issues with the *Github Projects*. 78 | 79 | #### Developing in progress 80 | The project manager is responsible for tracking the development progress in *Github Projects*. The development progress publishes to the community. 81 | 82 | #### Before merging a PR to *release developing branch* 83 | After a feature finishes development, the project lead is responsible for merging the PR from the *feature branch* to the *release developing branch*. But all PRs linked to the feature issues, which are labeled *security_check_required* must pass the security checks processed by SIGoS and be labeled *security_approved* before merging to the *release developing branch*. 84 | 85 | #### Before release 86 | Corresponding to the Gitflow introduced above, the project lead is responsible for PR from the *release developing branch* to the *master branch*. This PR must receive the of: 87 | * more than half of the *FATE OSS Development Team*; 88 | * project lead followed by the approval of TSC Board. 89 | 90 | Because FATE project consists of several subprojects, once FATE got approval for a new release, all the subprojects (e.g. FATE-Board, FATE-Flow, etc.) are derived the approval from the FATE project. Only FATE-Serving and KubeFATE requires seperated approvals by now. 91 | 92 | If only a subproject (e.g. FATE-Board) needs to be published a new release, it still needs the approval process. 93 | 94 | #### Exceptionals 95 | ##### Additional features or fixes add to developing release 96 | The features and fixes must come from Github issues, or the project manager responsible for creating related issues. The issues should be added to *Github projects* for tracking. 97 | 98 | If the features and fixes miss the windows of development, they should follow the process of creating a new release. 99 | 100 | ##### Fixes patch to old release 101 | If there is a patch that needs to apply to old but supporting release, the development team is suggested to follow the process: 102 | * The project lead creates a *release developing branch* for initial a new release following practices: develop-%{release}%; 103 | * The feature developer creates a new *feature branch* for developing a new feature; 104 | * The project lead is responsible for managing PRs merge to the *release developing branch* with SIG on Security (SIGoS)' approval; [Ref: Before merging a PR to the *release developing branch*](#before-merging-a-pr-to-release-developing-branch); \* 105 | * The project lead responsible for creating a *patch release branch*: release-%{release}%; 106 | * The project lead PRs from the *release developing branch* to the *patch release branch* with the community's approval [Ref: Before release](#before-release); 107 | * The project lead publishes release from the *patch release branch*. 108 | 109 | ## Tools 110 | The community Process WG is responsible for creating related tools to facilitate the project management process in the future. 111 | -------------------------------------------------------------------------------- /GOVERNANCE.md: -------------------------------------------------------------------------------- 1 | # **FATE GOVERNANCE** # 2 | 3 | This document defines the project governance for FATE. 4 | # Principles # 5 | The FATE community adheres to the following principles: 6 | 7 | - Open: FATE is an open source project. 8 | - Welcoming and respectful: See[ Code of Conduct](./CODE_OF_CONDUCT.md). 9 | - Transparent and accessible: Work and collaboration are done in public. 10 | - Merit: Ideas and contributions are accepted according to their technical merit and alignment with project objectives, scope, and design principles. 11 | - Vision: Benefit the ecosystem of federated AI solution providers, users and researchers, focused on federated AI use cases that will work across industries. 12 | 13 | # TSC member # 14 | The TSC consists of the TSC Board and the TSC Maintainers. 15 | 16 | ## Becoming a TSC board member ## 17 | The TSC Board will be responsible for the following aspects of the Project. 18 | - Providing advice and resources to guide or support the development of the Project. 19 | - Nominating and electing candidates for the TSC Chair. 20 | - Proposing improvements for the project, including its governance and community processes, and 21 | defining additional areas the TSC Board may assist the Project. 22 | - At least one dedicated volunteer should be assigned to work in the community, including but not limited to technical research and development, business application, community operation and SIG. The volunteers can come from the Board members themselves or recommended organization members. 23 | 24 | TSC Board members must meet these requirements: 25 | - Participate in the FATE project. 26 | - Must be an individual or organization that provides advice and resources and shows leadership to guide or support the development of the FATE project. 27 | 28 | The rules for electing TSC Board members are given below: 29 | - Any candidates must be nominated by existing board members, and introduce their plans and resource support for the FATE project during the election. 30 | - Voting rule: Existing board members will vote to elect new board members. The candidate will become a board member by winning a simple majority of the votes. 31 | - In the initial election, a total of 5 board members shall be elected. Existing TSC members shall nominate the candidates for the TSC Board, and each TSC member has only one nomination chance. During the election, all candidates shall introduce their plans and resource support for the FATE project. Then existing TSC members will vote for each candidate. Candidates winning a simple majority of the votes will become board members. 32 | - The term of office of each board member is 2 years. 33 | - Before the expiry of the term, the member may renew the term by participating in a defense and winning a simple majority of the votes of the board members. 34 | 35 | ## Withdrawing from the TSC Board ## 36 | Any member may withdraw from the TSC Board during the term of office. Existing members are entitled to remove any member who fails to perform his/her duties or violates regulations through voting. 37 | - Voluntary withdrawal during the term of office: The member may file a withdrawal application to the TSC Chair, which shall review the application and decide whether this member is eligible to the nomination of future board members. 38 | - Passive withdrawal: If a board member fails to perform his/her duties or violates regulations, the TSC Chair may propose to remove this member through voting. The removal will be approved by a simple majority of the votes from board members. This member is ineligible for future board election. 39 | - If the representative of an organization member that serves as a board member cannot fulfill its role due to resignation or personal reasons during the term of office, the organization shall designate a new representative and continue the previous representative’s term of office. 40 | 41 | ## Becoming a TSC maintainer ## 42 | The TSC Maintainers will be responsible for the following aspects. The TSC Maintainers must fulfill their duties during their terms of office. 43 | - Actively contributing to the project and the community, participating in the code review process, responding to and replying to contributions and issues in a timely manner, and ensuring the overall code review process progresses in a timely manner. 44 | - Managing issues, including bugs and problems. 45 | - Managing the repository and tracking the release process. 46 | - Preparing and updating documentation. 47 | 48 | The qualification requirements and application method for the TSC Maintainer are: 49 | - The TSC Maintainer must be a committer first. 50 | - The applicant must be proficient in at least one technical expertise. 51 | - The applicant must keep contributing some PRs, including contributing codes, documentations, or other technologies, and undertaking partial code review of the community. 52 | - All TSC members shall vote within one month after the applicant files an application. The applicant will become the Maintainer by winning a simple majority of votes. 53 | 54 | The term of office of the TSC maintainer：There is no limit for the term of office of the Maintainer as long as the maintainer carries out his/her duties as a maintainer. 55 | 56 | A Maintainer can become a board member. As described before, a board member must be nominated by an existing board member, and win a simple majority of the votes from existing board members. 57 | 58 | ## Withdrawing from the TSC maintainer ## 59 | The Maintainer may withdraw at any time. Existing TSC members are entitled to remove the Maintainer who fails to perform his/her duties or violates regulations through voting. 60 | - Voluntary withdrawal: The TSC Maintainer may withdraw by sending an email to all TSC members or submitting the PR on GitHub. 61 | - Passive withdrawal: If the TSC Maintainer fails to perform his/her duties or violates regulations, he/she will be removed by a simple majority of the votes from TSC members. 62 | 63 | ## Election of the TSC Chair ## 64 | The TSC Chair must meet the following requirement: 65 | - An individual who has a significant influence in the industry and can contribute to the federated learning sector. 66 | 67 | The TSC Chair election rules are given below: 68 | - The TSC Chair shall be selected from and nominated by the TSC Board. The candidate winning a simple majority of the votes from the existing TSC members will be the TCS Chair. 69 | - Candidates must be nominated by existing board members, each of which can nominate one candidate only. During election, all candidates shall introduce their plans and resource support for the FATE project. 70 | - Voting rule: Existing TSC members will vote to elect the new Chair. The candidate will become the TSC Chair by winning a simple majority of the votes. 71 | - The term of office of the TSC Chair is one year, and the Chair can be re-elected once. If the board membership of the TSC Chair expires during its term of office, he/she may renew the membership and proceed on the stipulated renewal procedure, while the term of office of the TSC Chair will not be affected. The TSC Chair may terminate his or her TSC membership, but this will be regarded as voluntary withdrawal from the board and voluntary resignation from the TSC Chair following the corresponding procedures. 72 | - To extend the terms for one more term, the current TSC Chair shall file an application for reelection 3 months in advance. Then TSC members will vote, and the reappointment will be approved if he/she wins a simple majority of the votes. 73 | - During the election of new chair, the candidate must be nominated and elected following the above steps. Upon resignation, the former Chair will remain a board member or may withdraw from the board. 74 | 75 | ## Resignation of the TSC Chair ## 76 | The TSC Chair may resign during the term of office. Existing board members are entitled to remove the Chair who fails to perform his/her duties or violates regulations through voting. 77 | - Voluntary resignation: The TSC Chair may file a resignation application to the TSC Board 3 months in advance, and directly resign after the election of the new Chair and handover the work to the new Chair within three months. 78 | - Passive resignation: If the TSC Chair fails to perform his/her duties or violates regulations, the LF or two (or above) board members may propose to remove the Chair through voting. The removal will be approved by a simple majority of the votes from TSC members. Upon the removal, the new Chair shall be elected following the stipulated chairperson election procedure. 79 | - The former Chair will be no longer a board member in the case of voluntary or passive resignation during the term of office. 80 | 81 | # Organization Member # 82 | ## Becoming an organization member ## 83 | The rights and responsibilities of the organization member include the following: 84 | - Assign at least one dedicated volunteer to participate in community building, including but not limited to technical research and development, business application, community operation and SIG. 85 | - Participate in the ecological construction of the community, drive the adoption of FATE’s application in organization member, and build a bridge of resource cooperation between the community and organization members. 86 | - Enjoy the priority right to participate in the SIGs, and to participate in the development, reports and activities of project-related standards. 87 | - The logo of organization members can be displayed on the official media of the community. 88 | 89 | The organization member must meet the following requirements: 90 | - Possess capabilities of technical research and development or have the business scenarios of applications in the field of privacy computing. 91 | - Willing to invest resources in participating in community construction and contribution, including but not limited to technology research and development, scenario application, community cooperation and community operation. 92 | 93 | The rules of becoming an Organization member are: 94 | - The applicant must submit related information to TSC, please contact xxxxxx for the application form. 95 | - Voting: All TSC Board members shall vote within one month after the applicant files an application. The applicant will become the Organization Member by winning a simple majority vote. 96 | - The term of the Organization Membership：There is no limit for the term of the organization membership as long as the organization member carries out their duties as an organization member. 97 | 98 | An organization member can become a TSC board member. As described before, a board member must be nominated by an existing board member, and win a simple majority vote from existing board members. 99 | 100 | ## Withdrawing from the organization member ## 101 | The organization member may withdraw at any time. Existing TSC Board members are entitled to remove the organization member who fails to perform their duties or violates regulations through voting. 102 | - Voluntary withdrawal: The organization member may withdraw by sending an email to TSC Board members or submitting the PR on GitHub. 103 | - Passive withdrawal: If an organization member fails to perform their duties or violates regulations, the organization member will be removed by a simple majority vote from TSC Board members. 104 | 105 | # Special Interest Groups(SIGs) # 106 | Special Interest Groups (SIGs) are sustained and open teams in the open source community that focus on a specific technical or specialist area or areas. The team achieves specific delivery targets through regular tasks and activities. A SIG is open and transparent and welcomes developers to join and contribute. SIGs can be initiated by TSC members or Organization Members. Members of a SIG are recruited from the community. SIGs can cover a wide range of research solutions, technologies and applications related to federated learning or privacy computing. 107 | 108 | ## SIG creation process ## 109 | - The SIG initiator invites other like-minded people to start the SIG together through the mailing list provided by the community. 110 | - The SIG initiator submits an application to the TSC for the starting of the SIG. The SIG’s objectives, organizational structure and other relevant information should be submitted with the application. 1-2 people should be nominated as the person in charge. 111 | - Voting rule: The SIG will be formally established by a vote of the existing TSC Board members, with more than 2/3 of the votes casted. 112 | - The first 3 months after the forming of the SIG is the trial period. During the trial period, the SIG should prepare and recruit contributors, and recruit at least 3 companies as participants; 113 | - At the end of the trial peroid, the SIG is required to report to the TSC on the results of the trial period, including the content of outputs and the active status of members. The TSC will then vote on whether the SIG will formally enter the operational phase. If the number of votes exceeds 1/2, the trial SIG will be approved to officially enter the operational phase, otherwise it will remain in the trial phase. 114 | - The fully operational SIG shall report the work progress to TSC regularly (quarterly). 115 | 116 | ## SIG Dissolution Process ## 117 | The SIG leader should organize regular meetings and discussion of relevant task progress among the members, who should in principle meet at least once per quarter. If the SIG is unable to organize activities with a certain number of participants on a regular basis or is unable to fulfil its organizational management responsibilities, the TSC may archive the projects it has developed and, if appropriate, have it dissolved. 118 | - If there is no activity for 3 months or more, the SIG should be dissolved. At this point the SIG can be treated as a trial SIG as mentioned above. The SIG can be reactivated following the "trial - fully operated" procedure to avoid dissolution. 119 | - If there is no activity for 6 months or more, the SIG must be dissolved. The community will archive the projects developed by the SIG and may reactivate them when a new SIG is formed. 120 | 121 | # Decision making and voting # 122 | - The project aims to operate as a consensus-based community, and decisions are built on the agreement reached by TSC members. Proposals and ideas for agreement can either be submitted via a GitHub issue or PR, or by sending an email to [FedAI-maintainers@groups.io](https://groups.io/g/FedAI-maintainers). 123 | - Decision making process should be transparent to adhere to the principles of FATE project. 124 | - If any decision requires a vote to move the Project forward, TSC member will vote on a one vote per voting TSC member basis. 125 | - Quorum for voting requires all voting TSC member to participate. 126 | - Any decisions require to be supported by a majority approval of TSC member vote. 127 | - For formal votes, a specific statement of what is being voted on should be added to the relevant GitHub issue or PR, and a link to that issue or PR should be added to the TSC meeting agenda document. TSC member should indicate their yes/no vote on that issue or PR, and after a reasonable period of time, the votes will be tallied and the outcome will be noted. 128 | - All proposals, ideas, and decisions made by TSC member should either be part of a GitHub issue or PR. 129 | 130 | # TSC meeting # 131 | TSC meetings include the TSC Board meeting and the TSC regular meeting, with the agenda and form of each meeting as follows: 132 | 133 | **TSC Board Meeting** 134 | - This meeting is held irregularly, and called and chaired by the TSC Chair or any board member; 135 | - The agenda of the meeting includes the discussion and communication of major issues including rules and regulations, project direction, project cooperation, community development and community operation, the election of the Chair, and voting on relevant issues. 136 | 137 | **TSC Regular Meeting** 138 | - It is held once a quarter and chaired by the TSC Chair; 139 | - The agenda of the meeting includes technical discussion, project/sub-project review and proposal discussion, conveying of board resolution, and voting on relevant issues; 140 | - TSC members shall not be absent from meetings more than 2 times in a year; otherwise, the member could be removed from the TSC Board or TSC Maintainer. 141 | # Responsibilities # 142 | - Making a community work requires input/effort from everyone. Maintainers should actively participate in Pull Request reviews. Maintainers are expected to respond to assigned Pull Requests in a reasonable time frame, either providing insights, or assigning it to other maintainers. And make sure that ongoing PRs are moving forward at the right pace or close them. 143 | - Diligently providing supports (via mailing list, GitHub, slack, email, WeChat, etc.), answering questions，responding to requests and replying to bugs, etc. 144 | - Publishing releases 145 | - Fixing bugs 146 | - Writing and updating documentation for usage and development 147 | - Getting the word out and making your project known 148 | - Monitoring the improper speech and behavior of the community and dealing with community conflicts and disputes. 149 | # Project # 150 | ## Release cadence ## 151 | - Our current release cycle is intended to be two months. We may change this based on user demand. 152 | - In general, master is assumed to be release candidate quality at all times for documented features. For undocumented or clearly under development features, use caution or ask about current status when running master. 153 | ## Proposal Process ## 154 | Significant changes to the codebase and / or new features must be first discussed and weighed, and sometimes formally documented, before they can be implemented. The process for proposal informs and involves all the members of the community in major improvements to the codebase and / or new features throughout the development process, to increase their sharing comments and ideas and offering to help. 155 | 156 | The proposal process is the process for reviewing a proposal and reaching an agreement on whether to accept or decline the proposal. 157 | 158 | **Design Documents** 159 | 160 | The proposal should be documented as a separated markdown file pushed to the root of the `proposals` folder in the community repository via PR. The name of the file should follow the name pattern `design/shortname.md`. 161 | Use the [Proposal Template](./PROPOSAL_TEMPLATE.md) as a starting point. 162 | 163 | **Proposal lifecycle** 164 | The proposal PR can be marked with different status labels to represent the status of the proposal: 165 | 166 | - **New**: Proposal is just created 167 | - **Reviewing**: Proposal is under review and discussion 168 | - **Accepted**: Proposal is reviewed and accepted (either by consensus or vote) 169 | - **Rejected**: Proposal is reviewed and rejected (either by consensus or vote) 170 | 171 | **Proposal Review** 172 | 173 | The maintainers hold “proposal review meetings” approximately weekly to review pending proposals. 174 | 175 | The principal goal of the review meeting is to make sure that proposals are receiving attention from the right people, by cc'ing relevant developers, raising important questions, pinging lapsed discussions, and generally trying to guide discussion toward agreement about the outcome. The discussion itself is expected to happen on the issue tracker, so that anyone can take part in. 176 | 177 | Once comments and revisions on the design doc wind down, there is a final discussion on the issue, to reach one of two outcomes: 178 | 179 | - Accepted proposal or 180 | - Declined proposal 181 | 182 | After the proposal is accepted, implementation work proceeds in the same way as any other contribution. 183 | 184 | ## Adding new sub-project to the FATE GitHub organization ## 185 | The `Federated AI Ecosystem` organization is open to receive new sub-projects under its umbrella. To apply a project as part of the Federated AI Ecosystem organization, it has to meet the following criteria: 186 | 187 | - Licensed under the terms of the Apache License v2.0 188 | - Project has been active for at least one year since its inception 189 | - Related to one or more scopes of FedAI ecosystem: 190 | - Federated machine learning 191 | - Federated transfer learning 192 | - Federated data network 193 | - Federated inference 194 | - Federated machine learning on Edge 195 | - Federated learning workload management using cloud native technologies 196 | - Multi-party security protocol 197 | - … 198 | - Be supported by 2/3 majority of the existing maintainers 199 | 200 | The submission process starts a Pull Request or Issue with the required information mentioned above. Once a project is accepted, it's considered as a Federated AI Ecosystem sub-project under the umbrella of Federated AI Ecosystem. 201 | ## Contributing ## 202 | Please see [CONTRIBUTING.md](./CONTRIBUTING.md) for general contribution guidelines 203 | ## Code of Conduct ## 204 | FATE adhere to the [Code of Conduct](./CODE_OF_CONDUCT.md). 205 | # Updating Governance # 206 | All substantive changes in Governance require total Maintainership vote supported by 2/3 majority of existing maintainers. 207 | 208 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright [yyyy] [name of copyright owner] 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | -------------------------------------------------------------------------------- /PROPOSAL_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | # Proposal: <`TITLE`> # 2 | Author: 3 | 4 | Discussion: Link do discussion issue, if applicable 5 | # Abstract # 6 | [A short summary of the proposal.] 7 | # Background # 8 | [An introduction of the necessary background and the problem being solved by the proposed change.] 9 | # Proposal # 10 | [A precise statement of the proposed change.] 11 | # Non-Goals # 12 | [Anything explicitly not covered by the proposed change.] 13 | # Rationale # 14 | [A discussion of alternate approaches and the trade offs, advantages, and disadvantages of the specified approach.] 15 | # Compatibility # 16 | [A discussion of any compatibility issues that need to be considered] 17 | # Implementation # 18 | [A description of the steps in the implementation, who will do them, and when.] 19 | # Open issues (if applicable) # 20 | [A discussion of issues relating to this proposal for which the author does not know the solution. This section may be omitted if there are none.] 21 | 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # FATE Community 2 | FATE is an inclusive and open community. This repository stores the documentation related to the activities of the FATE community. It serves as 3 | a place for community members to collaborate together. 4 | 5 | # Governance 6 | FATE is an open source project hosted by Linux Foundation. The [Technical Charter](FATE_Project_Technical_Charter.pdf) sets forth the responsibilities and procedures for technical contribution to, 7 | and oversight of, the FATE (“Federated AI Technology Enabler”) Project. [GOVERNANCE.md](./GOVERNANCE.md) defines the governance model of the project. 8 | 9 | # Technical Steering Committee 10 | 11 | The Technical Steering Committee (the “TSC”) is responsible for all technical oversight of the FATE open source project. 12 | The TSC consists of the [TSC Board](TSC%20Board.md) and the [TSC Maintainers](TSC%20MAINTAINERS.md). The roles and resposibilites of the TSC Board and the TSC Maintainers are documented in the [Technical Charter](FATE_Project_Technical_Charter.pdf). 13 | 14 | Under the leadership of the TSC, the [Development Committee](./meeting-minutes/FATE_Dev_Meeting) sets up democratic, open and public processes for the community to collaboratively develop the project. The Development Committee forms a few [Special Interest Groups (SIGs)](./SIGs) to discuss, review and determine the strategies of topics in a specific domain, such as security, interoperability and architecture design. 15 | 16 | The TSC Board, TSC Maintainers and Development Committee meet regularly mostly through online meetings. The meeting minutes can be found [here](./meeting-minutes). 17 | 18 | 19 | # Security Process 20 | The Security Response Committee (SRC) follows the disclosure and response policies formulated in the [Security Release Process](SECURITY.md) to ensure that key security concerns and issues are addressed promptly and responsibly. 21 | 22 | Community members who have security concerns should follow the [Security Release Process](SECURITY.md) to report their issues to the SRC for verification and obtain any remediation measures if needed. 23 | 24 | # Contributing 25 | The FATE project strives to abide by generally accepted best practices in open source software development. 26 | The maintainers of the FATE project welcome the contribution from the community. If you are interested in contributing to repositories or projects of the [Federated AI](https://github.com/FederatedAI) organization, please refer to the guidelines in the document [CONTRIBUTING.md](./CONTRIBUTING.md) about how to make contribution. 27 | 28 | Developers are welcome to submit pull requests (PRs) for bug fixes or feature enhancement. Before you start to contribute, be sure to read through the [Process Guidelines](FederatedAI_PROJECT_PROCESS_GUIDELINE.md) which provide the detailed information about the development and contribution process. 29 | 30 | 31 | # Getting Involved 32 | Here are channels through which the community members collaborate and interact with each other. 33 | 34 | **Mailing list**: Join the FATE [mailing list](https://groups.io/g/Fate-FedAI), and stay connected with the community and learn about the latest news and information of the FATE project. Discussion and feedback of FATE project are welcome. 35 | 36 | **Bugs or feature requests**: File bugs and features requests via the GitHub issue of each repository. If you need help, ask your questions via the mailing list. 37 | 38 | **Contact emails:** 39 | 40 | Maintainers: FedAI-maintainers @ groups.io 41 | 42 | Security Response Committee: FATE-security @ groups.io 43 | 44 | **Twitter:** [@FATEFedAI](https://twitter.com/FateFedAI) 45 | 46 | 47 | # Code of conduct 48 | The FATE project adheres to this [Code of Conduct](./CODE_OF_CONDUCT.md). By participating in this project, you are expected to uphold this code. 49 | 50 | -------------------------------------------------------------------------------- /RoundTable_slides/10期圆桌会-2021.05.26.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/RoundTable_slides/10期圆桌会-2021.05.26.pdf -------------------------------------------------------------------------------- /RoundTable_slides/11期圆桌会-2021.06.24.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/RoundTable_slides/11期圆桌会-2021.06.24.pdf -------------------------------------------------------------------------------- /RoundTable_slides/12期圆桌会-2021.08.26.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/RoundTable_slides/12期圆桌会-2021.08.26.pdf -------------------------------------------------------------------------------- /RoundTable_slides/13期圆桌会-2021.09.16.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/RoundTable_slides/13期圆桌会-2021.09.16.pdf -------------------------------------------------------------------------------- /RoundTable_slides/14期圆桌会-2021.10.27.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/RoundTable_slides/14期圆桌会-2021.10.27.pdf -------------------------------------------------------------------------------- /RoundTable_slides/1期圆桌会-2020.06.03.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/RoundTable_slides/1期圆桌会-2020.06.03.pdf -------------------------------------------------------------------------------- /RoundTable_slides/2期圆桌会-2020.07.14.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/RoundTable_slides/2期圆桌会-2020.07.14.pdf -------------------------------------------------------------------------------- /RoundTable_slides/3期圆桌会-2020.08.27.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/RoundTable_slides/3期圆桌会-2020.08.27.pdf -------------------------------------------------------------------------------- /RoundTable_slides/4期圆桌会-2020.09.28.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/RoundTable_slides/4期圆桌会-2020.09.28.pdf -------------------------------------------------------------------------------- /RoundTable_slides/5期圆桌会-2020.11.25.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/RoundTable_slides/5期圆桌会-2020.11.25.pdf -------------------------------------------------------------------------------- /RoundTable_slides/6期圆桌会-2020.12.23.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/RoundTable_slides/6期圆桌会-2020.12.23.pdf -------------------------------------------------------------------------------- /RoundTable_slides/7期圆桌会-2021.01.21.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/RoundTable_slides/7期圆桌会-2021.01.21.pdf -------------------------------------------------------------------------------- /RoundTable_slides/8期圆桌会-2021.03.12.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/RoundTable_slides/8期圆桌会-2021.03.12.pdf -------------------------------------------------------------------------------- /RoundTable_slides/9期圆桌会-2021.04.22.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/RoundTable_slides/9期圆桌会-2021.04.22.pdf -------------------------------------------------------------------------------- /SECURITY.md: -------------------------------------------------------------------------------- 1 | # **Security Release Process** # 2 | The FATE community follows the disclosure and response policies formulated in FATE Security to ensure that we address key issues responsibly. 3 | 4 | ## Security Response Committee (SRC) ## 5 | The Security Response Committee (SRC) is composed of the security director, relevant technical personnel, and operation personnel. It organizes the response to all security issues, including internal communication and external disclosure, and organizes relevant personnel to complete the process. 6 | 7 | ## Supported Versions ## 8 | The community maintains the LTS release and the latest 2 major releases. Each major release only maintains the latest minor version. 9 | 10 | ## Reporting a Vulnerability ## 11 | We thank all community members and users who report vulnerabilities to the FATE open-source community. The FATE SRC will thoroughly investigate all reported vulnerabilities. 12 | ### Private Disclosure Process ### 13 | All confirmed or suspected security vulnerabilities shall be reported privately to the FATE SRC to minimize attacks on FATE's current users before remediation. If you wish to notify the SRC of a vulnerability, you may send an email to FATE-security @groups.io or fate_security @groups.163.com so that we can respond and eliminate the issue as soon as possible. 14 | Important: To protect the user community, do not post security vulnerabilities on GitHub or other public media. 15 | 16 | **Recommended Vulnerability Reporting Format** 17 | 18 | Please include the following information in the body of the email, along with a descriptive subject line. 19 | - Basic identity information, such as your name and employer. 20 | - Specific steps for vulnerability recurrence (necessary scripts, screenshots, and compressed packet captures are all helpful). 21 | - Describe the impact of the vulnerability on FATE so that the FATE security team can reproduce the vulnerability. 22 | - Describe how this vulnerability affects FATE's usage and provide an estimate of the attack surface, if any. 23 | - List other projects or dependencies used with FATE to produce the vulnerability. 24 | 25 | **Security Vulnerability Response** 26 | 27 | After receiving your email, the FATE SRC will contact you within 3 working days and start to investigate the vulnerability, including the results of vulnerability identification and analysis, fixing plan, and any potential workarounds implemented during this period. Any vulnerability information shared with the SRC will remain within the FATE project and will not be disseminated to other projects unless it is necessary to fix the issue. 28 | ### When Should I Report a Vulnerability ### 29 | - You think you have found a potential security vulnerability in FATE. 30 | - You suspect that there is a potential vulnerability, but you are not sure if it affects FATE. 31 | - You know or suspect that a vulnerability has been found in another project on which FATE relies (for projects that have their own vulnerability reporting and disclosure procedure, please report vulnerabilities to the project). 32 | ### When Should I NOT Report a Vulnerability? ### 33 | - You need help turning FATE components for security. 34 | - You need help applying security-related updates. 35 | - Your problem is unrelated to security. 36 | 37 | ## Patch, Release, and Disclosure ## 38 | After receiving the vulnerability report, the FATE SRC will respond to the vulnerability as follows: 39 | 1. Normally, the SRC will contact you within 3 working days to investigate the vulnerability, confirm whether it is true, and determine its impact and severity; 40 | 41 | - If this problem is not a vulnerability, SRC will provide the specific reason for rejection and reply to you; 42 | - If the security vulnerability is confirmed, SRC will reply to you after completing the next step, including the results of vulnerability identification and analysis, patching plan, and any potential workarounds implemented during this period; 43 | 2. After confirmation, SRC will formulate the vulnerability fixing method and schedule, develop a mitigation plan, and communicate with the community, including determining the mitigation steps that the affected users can take to protect themselves until the release of a patch; 44 | 3. Fix and test the vulnerability and prepare for the release of a patch; 45 | 4. A corresponding minor version will be released in all supported versions (namely the latest two major versions and the LTS version of the project) to fix the vulnerability. Once the patched FATE version is released, SRC will follow the public disclosure process. 46 | 5. Public disclosure process: SRC will issue a public announcement to the FATE community through GitHub website to guide FATE users to learn about the vulnerability and obtain a patched version. SRC will also announce the mitigation measures that users can take until they can apply patches to their FATE services. 47 | 48 | ## Mailing list ## 49 | Security issues can be reported to the FATE SRC by sending email to FATE-security @groups.io or fate_security @groups.163.com. The FATE SRC will discuss security issues and patching methods privately via this email group before disclosure. 50 | 51 | ## Limitation of Liability ## 52 | The FATE community pays high attention to the vulnerabilities that impair the confidentiality and integrity of user data. The FATE community takes all reported, potential, and suspected vulnerabilities seriously and will investigate them promptly. 53 | The copyright owner of FATE/FederatedAI (the "Work") and each contributor (collectively, the "Licensor") openly grants a license to any individual or legal entity (the "Licensee"), but Licensee's acceptance of the license is also subject to [DISCLAIMER](https://github.com/FederatedAI/FATE/blob/master/DISCLAIMER) and the "Limitation of Liability" clause herein. -------------------------------------------------------------------------------- /SIGs/InterOP/FATE-sigInterOP-minutes-20220316.md: -------------------------------------------------------------------------------- 1 | # 会 议 记 录 2 | ## 文档编号： 3 | - FATE-sigInterOP-minutes-20220316 4 | ## 会议名称 5 | - 互联互通SIG讨论 6 | ## 记录人员 7 | - 张乐 8 | ## 会议时间 9 | - 2022/03/16 19:30-20:00 10 | ## 参加人员 11 | - HenryZhang、周雍恺、 Dylan、 Layne 、王方驰、李小林、军欢、张乐、车锦国 12 | ## 会议目的 13 | 1. 创建互联互通工作组； 14 | 2. 互联互通数据面系统架构模式实现方式讨论； 15 | 3. 互联互通API接口呈现形式讨论； 16 | ## 会议主要内容 17 | 1. 建议工作组命名为Sig InterOP； 18 | 2. 建议为互联互通后续工作制定一个计划和里程碑； 19 | 3. 互联互通工作组例会1-2周一次； 20 | 4. 互联互通数据面建议采用系统架构模式实现； 21 | 5. 建议邀约几家厂商加入互联互通工作组，共同讨论互联互通框架设计问题； 22 | 6. 互联互通呈现形式，可采用swagger定义api，将yaml文件上传至github； 23 | 7. 由周雍恺与王方驰协同负责互联互通工作组的组建与维护； 24 | 25 | ## 待完成事项 26 | 1. 联系初期成员，组建互联互通Sig； 27 | 1. 创建sig InterOP互联互通组Page，提交至FATE-Community/sigs目录下； 28 | 1. 需要制定互联互通工作计划和里程碑； 29 | 2. 需要创建一个repo，提交至github; 30 | 3. github上试验swagger yaml API定义； 31 | 4. 下次例会出一个初版本的框架示例进行讨论； 32 | 5. 讨论管理面基本元素； 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | -------------------------------------------------------------------------------- /SIGs/InterOP/README.md: -------------------------------------------------------------------------------- 1 | # FATE SIG on InterOP 2 | 3 | ## FATE SIG on InterOP focuses on the following topics: 4 | * Framework Design: Design a neutral interoperability framework to inter-connect heterogeneous PPC(privacy-preserving computing) platforms. 5 | * API and workflow definition: Define the interoperable API Interface, description and invoke samples. 6 | * Evaluating how to adapt FATE to the interoperable architecture. 7 | * Verification: Work with leading commercial PPC solutions to verify the interoperability framework and operate integration test. 8 | * Sharing latest research results and practical cases on interoperability. 9 | * Assist in solving problems related to interoperability. 10 | 11 | 12 | ## Tasks 13 | 1. Group formation 14 | 1. Create InterOP repository 15 | 1. Propose the interoperability framework 16 | 1. Define API and workflow of each module 17 | 1. FATE adaptation 18 | 1. Invite candidate PPC solutions to adapt to the interoperability framework 19 | 1. Test and evaluation 20 | 21 | ## Members 22 | | Name | Affline | Research Interest | Links | 23 | | ---------- | ------- | ----------------- | -------------------------- | 24 | | ZHOU Yongkai | UnionPay | Cloud Native, MPC, Federated Learning | https://github.com/vistakk | 25 | | WANG Fangchi | VMware | | | 26 | | WANG Peng | EverGrand | | | 27 | | LI Xiaolin | CMBC | | | 28 | | FAN Tao (Dylan) | Webank | | | 29 | | ZENG Jice (Jarvis) | Webank | | | 30 | | ZHANG Yifei | BoC | | | 31 | | LIU Zhanqi | Tencent | | | 32 | | SUN Junhuan | Clustar | | | 33 | | HE Hao | InsightOne | | | 34 | | ZHANG Le | UnionPay | Software Engineering, FML | | 35 | | CHE Jinguo | UnionPay | System Architecture, FML | | 36 | | ZHAO Bin | Clustar | | | 37 | -------------------------------------------------------------------------------- /SIGs/Multiplatform/README.md: -------------------------------------------------------------------------------- 1 | ### FATE SIG on Multiplatform focuses on the following topics: 2 | * Evaluate and verify the multiplatform support of existing algorithm/architecture/networking FATE components(2 latest versions and LTS version). 3 | * Review PRs related to algorithm/architecture/networking of multiplatform support. 4 | * Assist in solving problems related to multiplatform support. 5 | * Share latest research results and practical cases on multiplatform support. 6 | * Evaluate the development plan of FATE from a multiplatform support perspective. 7 | * Multiplatform support focuses on various hardware architecture/systems and databases adaptation,including but not limited to Kylin V10 OS(Phytium or HUAWEI,Kunpeng 920) and PostgreSQL(AntDb、TDSql). 8 | 9 | 10 | 11 | ### FATE SIG Multiplatform Members 12 | #### Chair: YUAN Zhiyong 13 | #### Co-Chair: Dylan FAN 14 | | Name | Affline | Research Interest | Links | 15 | |--------------------|------------|--------------------------------| -------------------------- | 16 | | YUAN Zhiyong | AsiaInfo | Federated Learning, MPC, LLM | https://github.com/yuanzhiyong | 17 | | Dylan FAN | WeBank | Machine Learning, Deep Learning, Federated Learning | https://github.com/dylan-fan | 18 | | YAO Yunfei | AsiaInfo | Cloud Native, Federated Learning | https://github.com/yyf1986 | 19 | | GAO Feng | China Unicom Digital Technology | Privacy-Preserving Computing，MPC, Federated Learning | https://github.com/reacher1130| 20 | | ZHANG Ning | China Unicom Digital Technology | Privacy-Preserving Computing，MPC | https://github.com/zhangning2222 | 21 | | BI Jianfeng | ChinaMobile | Machine Learning, Federated Learning | https://github.com/JeffyBeh | 22 | | XIE Yixing | GRG information Security Technology | Privacy-Preserving Computing，MPC，FederatedLearning | | 23 | 24 | -------------------------------------------------------------------------------- /SIGs/README.md: -------------------------------------------------------------------------------- 1 | # FATE Special Interest Groups (SIGs) 2 | 3 | ## What is FATE SIGs? 4 | 5 | The FATE Special Interest Groups (SIGs) are a vital part of the FATE ecosystem and provide expert advice and suggestions of a particular area or direction for the FATE community. A FATE SIG can include existing maintainers of the FATE community, external experts of a specific area, or anyone who can contribute to the FATE project in this particular direction. We have two active FATE SIGs now: SIG Security and SIG Tool. 6 | 7 | ## How is the FATE SIGs involved in the development process of FATE? 8 | 9 | Currently, the development of FATE is led by the FATE OSS Dev Team under the supervision of the FATE TSC Board. The FATE OSS Dev Team is responsible for requirements gathering, R&D, testing, and other FATE development-related works. FATE SIGs should assist in a particular area based on the requirements from the FATE OSS Dev Team. Possible involvement approaches include but are not limited to discussion on GitHub, online zoom meeting, offline meeting and so on. Minimally, each FATE SIG has a monthly online zoom meeting. Note all activities of FATE SIGs are publically visible and accessible. 10 | 11 | Additionally, FATE SIGs can also provide advice or suggestions for other teams in the FATE community: FATE Operation Team, FATE Security Team, and so on. 12 | 13 | ## How to join FATE SIGs? 14 | 15 | There are several ways to join FATE SIGs. 16 | 17 | 1. If you are already a FATE maintainer, you can directly join any FATE SIGs. 18 | 19 | 2. Anyone can apply to join any FATE SIG by submitting documents/materials/references showing that you are qualified for a FATE SIG. Your application will be evaluated/approved by the SIG you want to join. 20 | 21 | ## How to exit FATE SIGs? 22 | 23 | Anyone is free to exit FATE SIGs that he/she has joined. He/she has to notify the FATE SIG to confirm his/her exist. 24 | -------------------------------------------------------------------------------- /SIGs/Security/Meeting-minutes-2022-03-22.md: -------------------------------------------------------------------------------- 1 | # Meeting Minutes 2022-03-22 2 | 3 | 1. All members introduce themselves. 4 | 2. Henry gives an introduction to how FATE community works. 5 | 3. Dylan introduces the security facilities used in FATE, and some encountered security issues. Dylan also gives a brief introduction to the feature of FATE 1.9. 6 | 7 | TODO: 8 | 9 | 1. Check if the fully homomorphic encryption (via TenSEAL) can be used in FATE. 10 | -------------------------------------------------------------------------------- /SIGs/Security/README.md: -------------------------------------------------------------------------------- 1 | # FATE SIG on Security 2 | 3 | FATE SIG on Security focuses on the following topics: 4 | 5 | 1. Evaluating algorithm/architecture/networking security of existing FATE (2 latest versions and LTS version). 6 | 7 | 2. Evaluating the development plan of FATE from a security perspective. 8 | 9 | 3. Evaluating PR related to algorithm/architecture/networking security. 10 | 11 | 4. Assisting security-related issues. 12 | 13 | 5. Sharing latest research/industry highlights in the security fields. 14 | 15 | ## FATE SIG Security Members: 16 | 17 | | Name | Affline | Research Interest | Links | 18 | | ---------- | ------- | ----------------- | -------------------------- | 19 | | LIU Ximeng | National Natural Science Foundation of China
Peng Cheng Laboratory
Professor, Fuzhou University | FHE, MPC, Federated Learning | https://2uu.org | 20 | | WANG Leye | Assistant Professor, Peking Univerisity | Federated Learning | https://wangleye.github.io | 21 | | ZHAO Bowen | Associate Professor, Xidian Univerisity | MPC | https://www.researchgate.net/profile/Bowen-Zhao-4 | 22 | | GUO Kun | Associate Professor, Fuzhou University | Data Mining, Federated Learning, Distributed System | https://scholar.google.com/citations?user=qe6HxZQAAAAJ&hl=en | 23 | | LIU Yang | Xidian Univerisity | MPC, Federated Learning | https://scholar.google.com/citations?hl=zh-CN&user=IheXzHkAAAAJ | 24 | | CHAI Di | HKUST & Clustar | Matrix-related Encryption/Decryption | https://di-chai.github.io | 25 | | Henry ZHANG | VMWare | Cloud Native, Machine Learing, Blockchain | https://github.com/hainingzhang | 26 | | ZHANG Junxue | HKUST & Clustar | FHE | https://snowzjx.me | 27 | | Jarvis ZENG | WeBank | Machine Learning, Federated Learning, Distributed System, Cloud Native | https://github.com/jarviszeng-zjc | 28 | | Dylan FAN | WeBank | Machine Learning, Deep Learning, Federated Learning | https://github.com/dylan-fan | 29 | | MA Guoqiang | WeBank | Machine Learning, Deep Learning, Federated Learning | https://github.com/mgqa34 | 30 | | ZHOU Yongkai | UnionPay | Cloud Nativ Arch, MPC security | https://github.com/vistakk | 31 | | GONG Qiyuan | Intel Corporation | Data Anonymization, PPML, Federated Learning | https://github.com/qiyuangong | 32 | | CHENG Yong | Tencent | Federated Learning | https://github.com/YongGuCheng | 33 | | ZHANG Le | UnionPay | Machine Learning, Deep Learning | | 34 | | CHEN Zhongzheng | UnionPay | FL | | 35 | | ZHANG Yuanjian | UnionPay | Machine Learning, FL | https://publons.com/researcher/ABE–6483－2020/ | 36 | | CHE Jinguo | UnionPay | FL | https://github.com/majorinche | 37 | -------------------------------------------------------------------------------- /TSC Board.md: -------------------------------------------------------------------------------- 1 | # FATE TSC Board # 2 | 3 | [GOVERNANCE.md](./GOVERNANCE.md) describes governance guidelines and the board 4 | responsibilities. 5 | 6 | ## TSC Chair ## 7 | | Name | Term of office | 8 | | ------------ | --------------------- | 9 | | Qiang Yang | 2022.12.10~2023.12.09 | 10 | 11 | ## Honorable Chair ## 12 | | Name | Affiliation | 13 | | ------------ | --------------------- | 14 | | Jie Tang | Tsinghua University | 15 | 16 | ## TSC Board ## 17 | | Board member | Term of office | Representative | GitHub ID | 18 | | ------------ | --------------------- | -------------- | -------------------------- | 19 | | Clustar | 2021.11.11~2023.11.10 | Junxue Zhang | [snowzjx](https://github.com/snowzjx) | 20 | | ICBC | 2021.11.11~2023.11.10 | Chuang Zhang | [RyanSGH](https://github.com/RyanSGH) | 21 | | UnionPay | 2021.11.11~2023.11.10 | Yongkai Zhou | [vistakk](https://github.com/vistakk) | 22 | | VMware | 2021.11.11~2023.11.10 | Henry Zhang | [hainingzhang](https://github.com/hainingzhang ) | 23 | | WeBank | 2021.11.11~2023.11.10 | Qiang Yang |[QiangYang12](quianajiang@webank.com) | 24 | 25 | ## TSC secretary ## 26 | | Name | GitHub ID | 27 | | ------------ | --------------------- | 28 | | BingYin Lin | [kelley1069](https://github.com/Kelley1069) | -------------------------------------------------------------------------------- /TSC MAINTAINERS.md: -------------------------------------------------------------------------------- 1 | # FATE TSC Maintainers # 2 | 3 | [GOVERNANCE.md](./GOVERNANCE.md) describes governance guidelines and maintainer 4 | responsibilities. 5 | 6 | ## TSC Maintainers ## 7 | | Name | GitHub ID | Affiliation | Areas of expertise | 8 | | ---------------------------- | ------------------------------------------------ | --------------- | ------------------------------------------------------------ | 9 | | Dylan Fan | [dylan-fan](https://github.com/dylan-fan) | WeBank | Machine Learning,Deep Learning,Federated Learning | 10 | | Henry Zhang | [hainingzhang](https://github.com/hainingzhang ) | VMware | cloud native, Machine learing, blockchain | 11 | | Yang Liu | [lyyanjiu1jia1](https://github.com/lyyanjiu1jia1) | BytreDance | Privacy-Preserving Machine Learning, Distributed Optimization over networks | 12 | | Zotrseeew Ma | [mgqa34](https://github.com/mgqa34) | WeBank | Machine Learning,Deep Learning,Federated Learning | 13 | | Jarvis Zeng | [zengjice](https://github.com/zengjice) | WeBank | Big Data Architecture, Machine Learning, Federated Learning | 14 | | Yongkai Zhou | [vistakk](https://github.com/vistakk) | China UnionPay | Cloud Native, Data Intelligence, Security | 15 | | Chris Huo | [ChrisHuo-04](https://github.com/ChrisHuo-04) | CCBFT | Machine Learning,Deep Learning,Federated Learning | 16 | | Rade Liu | [ZhanqiLiu](https://github.com/ZhanqiLiu) | Tencent | Machine Learning,Deep Learning,Federated Learning| 17 | | Junxue Zhang | [snowzjx](https://github.com/snowzjx) | Clustar | High performance networking, distributed systems, federated learning | 18 | | Peng Wang | [wpdata](https://github.com/wpdata) | EB China Tech | Big Data Architecture，Machine Learning，Federated Learning | 19 | | Chuang Zhang | [RyanSGH](https://github.com/RyanSGH) | SDC ICBC| Machine Learning，Federated Learning| 20 | | Wenbin Wei | [weiwee](https://github.com/weiwee) | WeBank| Machine Learning，Federated Learning| 21 | | Anying Xu| [Aimee-Hsu](https://github.com/Aimee-Hsu) | ABC| Machine Learning，Federated Learning| 22 | | LaynePeng | [LaynePeng](https://github.com/LaynePeng) | VMWare|cloud computing, distributed computing, computer architecture, DevOps| 23 | | Runyuan Wang | [rainroyal](https://github.com/rainroyal) | BOC| Machine Learning, Federated Learning| 24 | | Qing Zhang | [mangoblended](https://github.com/mangoblended) | China Telecom| Cryptology,MPC,Federated Learning| 25 | 26 | 27 | 28 | -------------------------------------------------------------------------------- /meeting-minutes/FATE_Dev_Meeting/FATEDevMeeting20220210.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/meeting-minutes/FATE_Dev_Meeting/FATEDevMeeting20220210.pdf -------------------------------------------------------------------------------- /meeting-minutes/FATE_Dev_Meeting/FATEDevMeeting20220224.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/meeting-minutes/FATE_Dev_Meeting/FATEDevMeeting20220224.pdf -------------------------------------------------------------------------------- /meeting-minutes/FATE_Dev_Meeting/FATEDevMeeting20220310.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/meeting-minutes/FATE_Dev_Meeting/FATEDevMeeting20220310.pdf -------------------------------------------------------------------------------- /meeting-minutes/FATE_Dev_Meeting/FATEDevMeeting20220324.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/meeting-minutes/FATE_Dev_Meeting/FATEDevMeeting20220324.pdf -------------------------------------------------------------------------------- /meeting-minutes/FATE_Dev_Meeting/FATEDevMeeting20220407.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/meeting-minutes/FATE_Dev_Meeting/FATEDevMeeting20220407.pdf -------------------------------------------------------------------------------- /meeting-minutes/FATE_Dev_Meeting/FATEDevMeeting20220421.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/meeting-minutes/FATE_Dev_Meeting/FATEDevMeeting20220421.pdf -------------------------------------------------------------------------------- /meeting-minutes/FATE_Dev_Meeting/FATEDevMeeting20220512.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/meeting-minutes/FATE_Dev_Meeting/FATEDevMeeting20220512.pdf -------------------------------------------------------------------------------- /meeting-minutes/FATE_Dev_Meeting/FATEDevMeeting20220601.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/meeting-minutes/FATE_Dev_Meeting/FATEDevMeeting20220601.pdf -------------------------------------------------------------------------------- /meeting-minutes/FATE_Dev_Meeting/FATEDevMeeting20220616.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/meeting-minutes/FATE_Dev_Meeting/FATEDevMeeting20220616.pdf -------------------------------------------------------------------------------- /meeting-minutes/FATE_Dev_Meeting/FATEDevMeeting20220630.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/meeting-minutes/FATE_Dev_Meeting/FATEDevMeeting20220630.pdf -------------------------------------------------------------------------------- /meeting-minutes/FATE_Dev_Meeting/FATEDevMeeting20220714.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/meeting-minutes/FATE_Dev_Meeting/FATEDevMeeting20220714.pdf -------------------------------------------------------------------------------- /meeting-minutes/FATE_Dev_Meeting/FATEDevMeeting20220804.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/meeting-minutes/FATE_Dev_Meeting/FATEDevMeeting20220804.pdf -------------------------------------------------------------------------------- /meeting-minutes/FATE_Dev_Meeting/FATEDevMeeting20220825.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/meeting-minutes/FATE_Dev_Meeting/FATEDevMeeting20220825.pdf -------------------------------------------------------------------------------- /meeting-minutes/FATE_Dev_Meeting/README.md: -------------------------------------------------------------------------------- 1 | # About FATE Development Committee 2 | 3 | This directory contains the mintues of the FATE Development Committee Meetings. The FATE Development Committee is responsible for the development of the FATE project and building up a community 4 | for the FATE project. It is under the leadership of FATE TSC Board. The current committee members: 5 | 6 | **Chair:** Henry Zhang 7 | **Members:** Dylan Fan, Xiaolin Li, Layne Peng, Jarvis Zeng, Junxue Zhang, Yongkai Zhou 8 | 9 |
10 | 11 | 12 | **Documents** 13 | 14 | [Proposals](https://github.com/FederatedAI/FATE-Community/tree/master/proposal) 15 | 16 | [Development Process](https://github.com/FederatedAI/FATE-Community/blob/master/FederatedAI_PROJECT_PROCESS_GUIDELINE.md) 17 | 18 | 19 |
20 | 21 | **Project Development Dashboard** 22 | 23 | [FATE Project Dashboard](https://github.com/orgs/FederatedAI/projects?type=beta) 24 | 25 | [KubeFATE Project Dashboard](https://github.com/orgs/FederatedAI/projects/5/views/1) 26 | 27 |
28 | 29 | **Meeting Minutes:** 30 | 31 | [August 25, 2022](FATEDevMeeting20220825.pdf) 32 | 33 | [August 04, 2022](FATEDevMeeting20220804.pdf) 34 | 35 | [July 14, 2022](FATEDevMeeting20220714.pdf) 36 | 37 | [June 30, 2022](FATEDevMeeting20220630.pdf) 38 | 39 | [June 16, 2022](FATEDevMeeting20220616.pdf) 40 | 41 | [June 1, 2022](FATEDevMeeting20220601.pdf) 42 | 43 | [May 12, 2022](FATEDevMeeting20220512.pdf) 44 | 45 | [April 21, 2022](FATEDevMeeting20220421.pdf) 46 | 47 | [April 7, 2022](FATEDevMeeting20220407.pdf) 48 | 49 | [March 24, 2022](FATEDevMeeting20220324.pdf) 50 | 51 | [March 10, 2022](FATEDevMeeting20220310.pdf) 52 | 53 | [Feb 24, 2022](FATEDevMeeting20220224.pdf) 54 | 55 | [Feb 10, 2022](FATEDevMeeting20220210.pdf) 56 | 57 | **Meeting Schedule:** 58 | 59 | September 8, 2022 60 | 61 | September 22, 2022 62 | 63 | 64 | -------------------------------------------------------------------------------- /meeting-minutes/TSC_Board_Meeting/2021-12-02/TSC-Board-Meeting-20211202.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/meeting-minutes/TSC_Board_Meeting/2021-12-02/TSC-Board-Meeting-20211202.pdf -------------------------------------------------------------------------------- /meeting-minutes/TSC_Board_Meeting/2022-01-20/TSC-Board-Meeting-20220120.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/meeting-minutes/TSC_Board_Meeting/2022-01-20/TSC-Board-Meeting-20220120.pdf -------------------------------------------------------------------------------- /meeting-minutes/TSC_Board_Meeting/2022-06-23/TSC-Board-Meeting-20220623.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/meeting-minutes/TSC_Board_Meeting/2022-06-23/TSC-Board-Meeting-20220623.pdf -------------------------------------------------------------------------------- /meeting-minutes/TSC_Board_Meeting/2022-08-11/TSC-Board-Meeting-20220811.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/meeting-minutes/TSC_Board_Meeting/2022-08-11/TSC-Board-Meeting-20220811.pdf -------------------------------------------------------------------------------- /meeting-minutes/TSC_Board_Meeting/2023-01-12/TSC-Board-Meeting-20230112.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/meeting-minutes/TSC_Board_Meeting/2023-01-12/TSC-Board-Meeting-20230112.pdf -------------------------------------------------------------------------------- /meeting-minutes/TSC_Board_Meeting/2023-01-12/TSC-Board-Member-Summary-CN.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/meeting-minutes/TSC_Board_Meeting/2023-01-12/TSC-Board-Member-Summary-CN.pdf -------------------------------------------------------------------------------- /meeting-minutes/TSC_Board_Meeting/2023-01-12/TSC-Special-Committee-Summary-CN.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/meeting-minutes/TSC_Board_Meeting/2023-01-12/TSC-Special-Committee-Summary-CN.pdf -------------------------------------------------------------------------------- /meeting-minutes/TSC_Meeting/2020-01-15/minutes.md: -------------------------------------------------------------------------------- 1 | # Meeting minutes of FATE community on 2020/01/15 2 | 3 | ## Topic 4 | Formulated R&D key points and planning, operational planning and make a commercialization discussions. 5 | 6 | ## Attendees Present 7 | 8 | * Toby Chen@WeBank([Tianjian](https://github.com/Tianjian)) 9 | * Dylan Fan@WeBank([dylan-fan](https://github.com/dylan-fan)) 10 | * Henry Zhang@VMware([hainingzhang](https://github.com/hainingzhang)) 11 | * Sookie Qin@Tencent([sookieqin](https://github.com/sookieqin)) 12 | * Zotrseeew Ma@WeBank([mgqa34](https://github.com/mgqa34)) 13 | * Jarvis Zeng@WeBank([zengjice](https://github.com/zengjice)) 14 | 15 | ## Minutes 16 | 17 | ### R&D Planning 18 | 19 | Introduce several key project directions of FATE in 2020 including FATE-Cloud, FATE-Serving, FATE-Board, FATE-On-Spark, KubeFATE, Fed-Recommendation.Clarified the KubeFATE and its combination with FATE-Flow are the key points. 20 | 21 | Clarified the following goals: 22 | 1. Support for larger-scale data and enhance robustness of offline systems (switch Eggroll to 2.x version). 23 | 2. Version upgrade optimization & improve backward compatibility. 24 | 3. Covering majority conventional modeling methods for commercial scenario. 25 | 4. Enhance visualization & auditability of federal modeling algorithm process. 26 | 5. Algorithm acceleration & heterogeneous computing support. 27 | 6. Deeper support for deep learning scenarios. 28 | 7. Improve online inference services in stability, highly available, high performance, easy to deploy, easy to expand and easy to migrate. 29 | 8. Support for multiple secure computing protocols. 30 | 9. Interact with mainstream AI frameworks such as Tensorflow, Pytorch, PaddlePaddle etc. 31 | 32 | ### Operational Planning 33 | 1. Introduce milestones of 2020 Operational Planning 34 | 2. Salon: hold 4-5 technical salons in different cities including Beijing, Shanghai, Shenzhen, Wuhan 35 | 3. Conference: Promote FATE at domestic and international conferences such as Opensource summit, KubeCon 36 | 4. Safety standards: continue to promote technical standards, national secret certification, etc. 37 | 5. Establish regular open source community user meetings through Zoom 38 | 39 | ### Commercialization Discussions 40 | 41 | 1. In the first half of 2020, FATE will focus on product software polishing which means making the software functionality and stability more complete before carry out large-scale commercialization. Small-scale market commercial promotion and poc verification can be conducted in the early stage. 42 | 2. Commercial software closed-loop: Inter-operate with other BI software to achieve closed-loop commercial product requirements. 43 | 3. Discussed about how to establish a business demand collection mechanism. -------------------------------------------------------------------------------- /meeting-minutes/TSC_Meeting/2020-06-10/minutes.md: -------------------------------------------------------------------------------- 1 | # Meeting minutes of FATE community on 2020/06/10 2 | 3 | ## Topic 4 | FATE LTS version & China Unionpay joins FATE TSC 5 | 6 | ## Attendees Present 7 | 8 | * Toby Chen@WeBank(Tianjian) 9 | * Dylan Fan@WeBank(dylan-fan) 10 | * Henry Zhang@VMware(hainingzhang) 11 | * Sookie Qin@Tencent(sookieqin) 12 | * Zotrseeew Ma@WeBank(mgqa34) 13 | * Jarvis Zeng@WeBank(zengjice) 14 | * Layne Peng@VMware 15 | * Clarkieliu@Tencent 16 | 17 | ## Minutes 18 | 19 | ### New FATE maintainer 20 | 1. Introduced a new friend Yongkai Zhou from China UnionPay and the current progress of China UnionPay and FATE； 21 | 2. Implemented the decision of Yongkai Zhou to join FATE TSC; 22 | 23 | ### FATE version discussion 24 | 1. Discussed about the planning of FATE LTS version and determined FATE v1.5 as the beginning of FATE LTS. The maintenance cycle of LTS is planned to last for 2 years. 25 | 2. Discussed about the R&D planning of FATE v1.5, mainly includes FAST SBT, FTL reconstruction, FATE-Pipeline, retry scheduling optimization of FATE-Flow, etc. 26 | 27 | ### FATE-operator 28 | 1. FATE-operator, an object submit to KubeFlow project, has been shared by VMware. 29 | 2. The community promotion of FATE-operator will be launched later. 30 | 31 | ### Discussion of FATE roadmap 32 | 1. Support for homogeneous online serving: FATE provides model conversion function and supports existing online frameworks such as tf-serving. 33 | 2. Support standalone offline prediction in homogeneous scenario 34 | 3. Add multiple types of input components such as images and audio data 35 | 4. Support for CNN and RNN: Reused existing deep-learning frameworks in homogeneous scenario while lacking requirements in heterogeneous scenario. 36 | 5. Support for ARM. 37 | 38 | 39 | 40 | -------------------------------------------------------------------------------- /meeting-minutes/TSC_Meeting/2020-10-21/FATE- TSC第三次会议.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/meeting-minutes/TSC_Meeting/2020-10-21/FATE- TSC第三次会议.pdf -------------------------------------------------------------------------------- /meeting-minutes/TSC_Meeting/2020-12-29/FATE- TSC第四次会议.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/meeting-minutes/TSC_Meeting/2020-12-29/FATE- TSC第四次会议.pdf -------------------------------------------------------------------------------- /meeting-minutes/TSC_Meeting/2021-04-01/FATE- TSC- 2021 Q1.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/meeting-minutes/TSC_Meeting/2021-04-01/FATE- TSC- 2021 Q1.pdf -------------------------------------------------------------------------------- /meeting-minutes/TSC_Meeting/2021-06-24/FATE- TSC- 2021 Q2.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/meeting-minutes/TSC_Meeting/2021-06-24/FATE- TSC- 2021 Q2.pdf -------------------------------------------------------------------------------- /meeting-minutes/TSC_Meeting/2021-11-11/FATE-TSC-2021-Q4.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/meeting-minutes/TSC_Meeting/2021-11-11/FATE-TSC-2021-Q4.pdf -------------------------------------------------------------------------------- /meeting-minutes/TSC_Meeting/2022-03-17/FATE-TSC-2022-Q1.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/meeting-minutes/TSC_Meeting/2022-03-17/FATE-TSC-2022-Q1.pdf -------------------------------------------------------------------------------- /proposal/1.10.0/KubeFATE_v1.10.0_new_feature_list.md: -------------------------------------------------------------------------------- 1 | ## KubeFATE v1.10.0 new feature list 2 | 3 | 1. Support provision Hive as storage engine provider with KubeFATE [#634](https://github.com/FederatedAI/KubeFATE/issues/634) 4 | 5 | 2. Support FATE-Flow HA [#747](https://github.com/FederatedAI/KubeFATE/issues/747) 6 | 7 | 3. Support FATE v1.10.0 [#748](https://github.com/FederatedAI/KubeFATE/issues/748) 8 | 9 | 5. Fix some bugs [#730](https://github.com/FederatedAI/KubeFATE/issues/730), [#736](https://github.com/FederatedAI/KubeFATE/issues/736), [#739](https://github.com/FederatedAI/KubeFATE/issues/739), [#633](https://github.com/FederatedAI/KubeFATE/issues/633), [#753](https://github.com/FederatedAI/KubeFATE/pull/753) 10 | 11 | 12 | 13 | ## Timeline 14 | 15 | * Planning: 2022/09/01 -2022/09/15 16 | * Dev & Test: 2022/09/16 - Mid-December 17 | * Release: Mid-December 18 | * The above estimated timeline may be optimized according to the actual situation 19 | -------------------------------------------------------------------------------- /proposal/1.10.0/fate-feature_list.md: -------------------------------------------------------------------------------- 1 | ## Feature 1.10.0 2 | > FederatedML 3 | * Add semi-supervised Learning algorithm 4 | * Add intel paillier cryptosystem library as an optional paillier scheme 5 | * A more general way to support torch backend development in HomoNN 6 | * Support multi-host intersection base on ECDH\DH psi protocol 7 | * Optimize predicting process of Hetero SecureBoost 8 | * Support using manually built model to transform data in HeteroFeatureBinning 9 | * Support up sample with weight column in Sample Component 10 | 11 | > FATE-Flow 12 | * Support kerberos authentication on spark 13 | * Support importing user created model and using in later job with ModelLoader 14 | * Add two-way connectivity detection api 15 | * Support submitting job by cluster mode on spark 16 | 17 | > FATE-Board 18 | * Display training sample quantity at leaf node in SecureBoost 19 | * Optimization and arrangement of style library 20 | * throttle data stream according to status of job，for reducing server concurrency and log volume 21 | 22 | > Fate-Client 23 | * Integrate min-test task into flow client 24 | * Optimize fate client and pipeline initialization 25 | * Support resetting role and model_id\version in pipeline 26 | 27 | # R&D Plan 28 | * Dev Time: 2022/09/01 - 2022/11/15 29 | * Test Time: 2022/11/16 - 2022/12/15 30 | * Release Time: 2022/12/16 - 2022/12/20 31 | 32 | 33 | 34 | -------------------------------------------------------------------------------- /proposal/1.7.2/feature_list.md: -------------------------------------------------------------------------------- 1 | ## Feature 1.7.2 2 | > FederatedML 3 | * New batch strategy in coordinated Hetero LR: support masked batch data and batch shuffle 4 | * Model inference protection enhancement for Hetero SecureBoost with FED-EINI algorithm 5 | * Hetero SecureBoost supports split feature importance on host side, disables gain feature importance. 6 | * Offline SBT Feature transform component 7 | > FATE-Flow 8 | * Separate the base connection address of the data storage table from the data table information, and compatible with historical versions; 9 | * Optimize the component output data download interface; 10 | 11 | > FATE-Board 12 | * Support FATE-Board v1.7.2.1 13 | 14 | > Bug-Fix 15 | * Fixed Bug for HeteroPearson with changing default q_field value for spdz 16 | * Fix Data Transform's schema label name setting problem when `with_label` is False 17 | 18 | 19 | -------------------------------------------------------------------------------- /proposal/1.8.0/KubeFATE_v1.8_new_feature_list.md: -------------------------------------------------------------------------------- 1 | ##KubeFATE v1.8 new feature list: 2 | 3 | 1. Solve the warning of potential security vulnerabilities in Github pages #519 4 | 5 | 2. Adjust the file structure of Chart to facilitate the addition of new modules #526 6 | 7 | 3. Support specify ingress class names #523 8 | 9 | 4. Bug fix #501 10 | 11 | 5. Support FATE v1.8.0 #551 12 | 13 | 6. KubeFATE support liveness and readiness #552 14 | 15 | 16 | ##Timeline 17 | * Dev Time: 2022/03/11 - 2022/03/30 18 | * Test Time: 2022/03/31 - 2022/04/8 19 | * Release Time: 2022/04/13 - 2022/04/15（Sprint Review, Sprint Retrospective） 20 | 21 | -------------------------------------------------------------------------------- /proposal/1.8.0/feature_list.md: -------------------------------------------------------------------------------- 1 | ## Feature 1.8.0 2 | > HightLight 3 | * Add non-coordinated-version Hetero Linear Regression 4 | * Add SecureBoost-MO algorithm to speed up multi-class classification 5 | 6 | > FederatedML 7 | * Add SecureBoost-MO algorithm to speed up multi-class classification of Hetero & Homo SecureBoost 8 | * Merge Hetero FastSecureBoost into Hetero SecureBoost as a boosting strategy option 9 | * Add non-coordinated-version Hetero Linear Regression, based on integrated Hetero GLM framework, with mixed protocol of HE and SPDZ 10 | * Support weighted training in non-coordinated Hetero Logistic Regression & Linear Regression 11 | * Homo LR support one-vs-rest 12 | * Speed up DH Intersection implementation, 30%+ faster 13 | * Optimized Quantile Binning gk-summary structure & split point query 14 | 15 | > FATE-ARCH 16 | * Adjustable task_cores for standalone FATE 17 | 18 | > FATE-Test 19 | * Optimized testsuite printout table colorization 20 | * Optimized testsuite printout summary status 21 | * Include Paillier encryption performance evaluation 22 | * Include examples data upload and mnist download 23 | * Provide pipeline to dsl convert tools. 24 | 25 | > FATE-Flow 26 | * Optimize the model migration function to reduce user operation steps 27 | * Add version compatibility check in component center to support multiple parties to use different versions 28 | * Add batch disable table interface, and clean up tables based on filter fields 29 | 30 | > FATE-Board 31 | * Supports GBDTMO mode in SBT. 32 | * Add SSHE linr component. 33 | * Add Writer component. 34 | 35 | 36 | # R&D Plan 37 | Dev Time: 2022/02/24 - 2022/03/20 38 | Test Time: 2022/03/21 - 2022/04/12 39 | Release Time: 2022/04/13 - 2022/04/15 40 | 41 | 42 | 43 | -------------------------------------------------------------------------------- /proposal/1.9.0/KubeFATE_v1.9_new_feature_list.md: -------------------------------------------------------------------------------- 1 | ## KubeFATE v1.9 new feature list 2 | 3 | 1. Istio needs to support https https://github.com/FederatedAI/KubeFATE/issues/488 4 | 5 | 2. Yaml validation for cluster creation https://github.com/FederatedAI/KubeFATE/issues/517 6 | 7 | 3. Support rolling update for FATE https://github.com/FederatedAI/KubeFATE/issues/556 8 | 9 | 4. Support FATE v1.9.0 https://github.com/FederatedAI/KubeFATE/issues/566 10 | 11 | 5. Some Eggroll configurations are skewed due to historical path dependencies https://github.com/FederatedAI/KubeFATE/issues/578 12 | 13 | 6. A smaller/thinner edition of FATE to support only PSI functionality https://github.com/FederatedAI/KubeFATE/issues/581 14 | 15 | 7. Update KubeFATE all test cases based on FATE-Test https://github.com/FederatedAI/KubeFATE/issues/589 16 | 17 | 8. Support using certificate for rollsite in both K8s and docker-compose deployment https://github.com/FederatedAI/KubeFATE/issues/588 18 | 19 | 9. Optimize the doc for this project https://github.com/FederatedAI/KubeFATE/issues/591 20 | 21 | 22 | 23 | ## Timeline 24 | 25 | * Planning: 2022/04/18 -2022/04/19 26 | * Dev & Test: Apr 2022 - Mid-August 27 | * Release: Mid-August 28 | * The above estimated timeline may be optimized according to the actual situation 29 | 30 | -------------------------------------------------------------------------------- /proposal/1.9.0/fate-feature_list.md: -------------------------------------------------------------------------------- 1 | ## Feature 1.9.0 2 | > FederatedML 3 | * PSI Supports ECDH Protocol 4 | * PSI Support Exact Cardinality Estimation 5 | * Support specifying columns as intersection columns 6 | * Anonymous Feature Names Generation Optimization 7 | * Hetero Feature Selection Support Selection By Anonymous Feature Names 8 | * Hetero-NN Support PyTorch Backend 9 | * Support Multi-Host In Hetero-NN 10 | * Add Label Protection enhancement Strategy In Hetero-NN 11 | * export PMML model for guest-single-y case 12 | * Accelerated Paillier cryptosystem scheme on Intel AVX512/IFMA 13 | 14 | > FATE-ARCH 15 | * Add better support for upgrading from older major versions 16 | * Support Python version 3.8+ 17 | * Support interconnection between different versions 18 | * Support interconnection between eggroll , spark, standalone backend 19 | * Support for heterogeneous acceleration architecture (Maybe) 20 | * Support pulsar-client mode for federation 21 | 22 | > FATE-Flow 23 | * Added site dataset permission control 24 | * Reader component support feature anonymity 25 | * Added api data storage type 26 | * Add the api reader component to get the specified feature data 27 | * fate flow support HA 28 | * upload and table bind support specifying the id column 29 | * fate client and pipeline optimization 30 | 31 | > FATE-Board 32 | * Optimization of timer pause caused by browser label switchin 33 | * Optimize UI component 34 | 35 | 36 | # R&D Plan 37 | * Dev Time: 2022/04/20 - 2022/07/20 38 | * Test Time: 2022/07/21 - 2022/08/22 39 | * Release Time: 2022/08/22 - 2022/08/25 40 | 41 | 42 | 43 | -------------------------------------------------------------------------------- /proposal/PROPOSAL_Eggroll.md: -------------------------------------------------------------------------------- 1 | # Proposal: Eggroll will donate to the FedAI community 2 | 3 | 4 | # Background # 5 | [eggroll](https://github.com/WeBankFinTech/eggroll) is a Simple High Performance Computing Framework for [Federated] Machine Learning. Now it is the main core computing, storage, and communication engine for FATE. 6 |

7 | 8 |

9 | 10 | # Proposal # 11 | 12 | We will donate eggroll from WeBankFinTech to FedAI community. 13 | 14 | 15 | # Time # 16 | 2023/02 17 | -------------------------------------------------------------------------------- /proposal/PROPOSAL_FATE-LLM.md: -------------------------------------------------------------------------------- 1 | # Proposal: FATE-LLM will be in independent sub-repository 2 | 3 | 4 | # Background # 5 | FATE-LLM is a new project for supporting federated learning for LLM. 6 | 7 |

8 | 9 |

10 | 11 | # Proposal # 12 | 13 | We will use an independent sub-repository to manage FATE-LLM project. 14 | 15 | # RoadMap # 16 | The FATE-LLM project RoadMap is as following: 17 |

18 | 19 |

20 | 21 | # Time # 22 | 2023/05 -------------------------------------------------------------------------------- /proposal/PROPOSAL_FedIPR.md: -------------------------------------------------------------------------------- 1 | # Proposal: FedIPR: Federated Learning Model Ownership Verification 2 | Author: 3 | 4 | Discussion: N/A 5 | 6 | # Abstract # 7 | 8 | This proposal proposes FedIPR([cite](https://ieeexplore.ieee.org/document/9847383/)), an ownership verification method to protect the intellectual property (IP) of Homogeneous Federated Deep Neural Network (FedDNN) for FATE. 9 | 10 | # Background # 11 | Machine learning, especially deep neural network (DNN) technology, has achieved great success in many fields in recent years, and many technology companies are deploying neural network models in commercial products to improve efficiency. Training advanced neural network models requires large-scale datasets, enormous computing resources, and the ingenuity of designers. This is embodied in: (1) The scale of the training model applied by the deep learning model is huge. Taking GPT-3 as an example, the amount of data used for pre-training reaches 45TB, and the training cost exceeds 12 million US dollars, which has a very high economic cost. (2) In the process of training and deploying deep learning models to industrial application scenarios (such as smart finance, smart medical applications), it is necessary to introduce proprietary prior knowledge in fields such as finance and medical care, so the knowledge and experience of experts need to be introduced in the model design process to customize the model, which reflects the intellectual property of human brain power. (3) The training process of deep learning models requires massive data in specific fields as training resources, and there are data values and knowledge attributes. The above properties determine that the trained deep learning model has high commercial value and intellectual properties, which must be included in the intellectual property of the legal owner (ie the party that created it). Therefore, there is an urgent technical need to protect deep neural network (DNN) models from illegal copying, redistribution, or misuse. 12 | 13 | For expensive artificial intelligence models, attackers can use technical means or non-technical means to steal; but to confirm the theft and declare model ownership , it is completely from the perspective of artificial intelligence theory and methods, and the model's ownership authentication technology needs to be Guaranteed to provide a reliable and robust method of intellectual property protection without sacrificing model usability. 14 | 15 | Unlike model training in centralized scenarios, distributed training of federated learning involves multiple participants, and there is a greater risk of leaking artificial intelligence models. There are situations where participants are attacked by adversaries or the model free-riders. These situations constitute a violation of ownership of the federated learning model. 16 | 17 | In response to the copyright protection of the global model of federated learning, WeBank AI Lab and Shanghai Jiaotong University published an article on IEEE Transactions on Pattern Analysis and Machine Intelligence , a top academic journal of artificial intelligence([cite](https://ieeexplore.ieee.org/document/9847383/)) presented a paper titled " FedIPR : Ownership Verification for Federated Deep Neural Network Models " , and shared their thoughts on the protection of intellectual property rights of models from the perspectives of algorithms, protocols, security, etc. on the issue of intellectual property protection of federated learning models and work, a proposal named FedIPR The federated learning model copyright protection framework. 18 |

19 | 20 |

21 | 22 | # Proposal # 23 | 24 | The architecture of the proposed FedIPR as flow: 25 |

26 | 27 |

28 |
Figure 2: FedIPR Architecture
29 | 30 | Along with the training and distributing of the Federated Learning model, the functions of FedIPR are divided into two parts: the training part and the distributing part. 31 | 1) In the training part, Fig.2 (①), we need to implement three functions: 32 | 1) __Black-box embedding function__: In this function, each client embeds its private trigger set from the client side, and we need to implement a loss (Backdoor loss)([cite](https://ieeexplore.ieee.org/document/9847383/)) to train the trigger set. 33 | 2) __White-box embedding function__: In this function, each client embeds its private watermark into the normalization layers, and we also need to implement the loss (Sign loss)([cite](https://ieeexplore.ieee.org/document/9847383/)) to let the private watermark embed to the Federated model successfully in the training stage. 34 | 3) __Watermark verification function__: To allow the user to verify if the watermarks have been embedded successfully. 35 | 2) In the distributing part, we need to implement two functions: 36 | 1) __Black-box verification function__ Fig. 2 (②): This function is not needed to access model parameters and internal structures, so we do not need to provide additional APIs, and users can verify through the general inference API using the own trigger dataset. 37 | 2) __White-box verification function__ Fig. 2 (③): We need to implement an API for users to open the model parameters and structure and verify whether the model parameters are embedded with a given "watermark". 38 | 39 | The implementation detail of the proposed FedIPR in FATE as flow: 40 |

41 | 42 |

43 |
Figure 2: Implementation of FedIPR in FATE (the part in red box)
44 | 45 | 1) Add a Sign loss for white-box embedding in the loss module (the implementation detail: [cite](https://github.com/purp1eHaze/FedIPR/blob/master/models/losses/sign_loss.py)). 46 | 47 | 2) Add a passport layer for white-box embedding in the model_zoo module (the implementation detail: [cite](https://github.com/purp1eHaze/FedIPR/blob/master/models/layers/passportconv2d_private.py)). 48 | 3) The FedIPR training process implemented in the trainer module (the implementation detail: [cite](https://github.com/purp1eHaze/FedIPR/blob/master/main_fedIPR.py)). 49 | 50 | 51 | # Non-Goals # 52 | [Anything explicitly not covered by the proposed change.] 53 | 54 | # Rationale # 55 | The empirical study of the proposed FedIPR in terms of fidelity, significance and robustness of watermarks. Superior detection performances of both backdoor-based watermarks and feature-based watermarks demonstrated that this proposal provides a reliable and robust scheme for FedDNN ownership verification. 56 | 57 |

58 | 59 |

60 | 61 | 62 | Fidelity: main task accuracy of FedDNN model with FedIPR 63 | 64 |

65 | 66 |

67 | Significance: Watermark detection rate of FedDNN model with FedIPR compared to theoretical bound. 68 | 69 |

70 | 71 |

72 | 73 | 74 | # Compatibility # 75 | [A discussion of any compatibility issues that need to be considered] 76 | # Implementation # 77 | The Pytorch version of FedIPR has been released to the FederatedAI research repository in August 2022. 78 | 79 | FedIPR will be implemented by WebankAI research team and FATE team. 80 | 81 | FedIPR is planned to be released with FATE 1.11. 82 | # Open issues (if applicable) # 83 | 84 | N/A -------------------------------------------------------------------------------- /proposal/PROPOSAL_HARDWARE_ACC.md: -------------------------------------------------------------------------------- 1 | # Proposal: Hardware Accleration Support 2 | Author: <[Junxue ZHANG](https://github.com/snowzjx), Junhuan SUN, Bin ZHAO> 3 | 4 | Discussion: N/A 5 | 6 | # Abstract # 7 | This proposal intends to allow FATE to leverage hardware-based accelerators, such as GPU/FPGA, for better performance. 8 | 9 | This proposal will contribute a universal architecture for FATE to use these hardware-based accelerators, including APIs, memory layout standards, data structure, and so on. 10 | 11 | This proposal mainly targets accelerating cryptographic operations, such as Paillier encryption, ciphertext computation, and so on. 12 | 13 | # Background # 14 | In FATE, various cryptographic operations have been used to protect data privacy. Specifically, they are: 15 | 16 | 1. Paillier Encryption w/ Obfuscation. 17 | 18 | 2. Paillier Encryption w/o Obfuscation. 19 | 20 | 3. Paillier Decryption. 21 | 22 | 4. Ciphertext Matrix Addition. 23 | 24 | 5. Ciphertext & Cleartext Matrix Element-wise Multiplication. 25 | 26 | 6. Ciphertext & Cleartext Matrix Multiplication. 27 | 28 | 7. Ciphertext Matrix Summation. 29 | 30 | 8. RSA Encryption/Decryption. 31 | 32 | 9. RSA Blind. 33 | 34 | 10. RSA Unblind. 35 | 36 | Although preserving data privacy, these cryptographic operations also cause a dramatic performance penalty. In our experiment, these cryptographic operations cause >~80% total time when executing an end-to-end application. Thus, if we can efficiently accelerate these cryptographic operations, the end-to-end performance of FATE could be significantly improved. 37 | 38 | # Proposal # 39 | The architecture of our proposal is shown as follows and we mainly introduce the most important two parts: hardware acceleration library and heterogenous calculation functions. 40 | ![Architecture](./architecture.jpg) 41 | 42 | ## Hardware Acceleration Library ## 43 | The acceleration library is a well-developed SDK which implements ciphergraphic operations mentioned above with different hardware, including GPU, FPGA, etc. The library is usually developed with Python and C/C++ language and provides several Python APIs for different operations. Once an API is called, it receives the input data (like ciphertext, keys, ciphertext bitwidth, batch size and target device) and sends them to the hardware devices. The devices are then invoked to execute corresponding operations. After calculation, the output data is sent back or stored in destination memory address by the library. 44 | 45 | In addition to the computing operations, the library is also responsible for data format conversion, data transmission and cross-language binding. 46 | 47 | __Data format conversion__: Data preprocessing is required to reconstruct datasets for efficient batch processing on heterogeneous device. In data conversion API, raw data is loaded from database and the features and labels which come from the same mini-batch are densely packed together in an array-like architecture. 48 | 49 | After aggregation, serialization is performed to convert data format. In order to optimize the performance of heterogeneous device and fully utilize cross-device interface like PCIe, data structure should be converted into byte stream before it is sent. 50 | 51 | __Data transmission__: As the data format has been converted for better efficiency, data transmission between different parties for the new data format should also be introduced to reduce redundant data conversion. The \__getstate__ and \__setstate__ functions are overloaded to achieve automatic format processing during data transmission. 52 | 53 | __Cross-language binding__: To efficiently invoke heterogeneous devices, the interactions with the devices are usually implemented by languages like C++. Therefore, it is required to bind between C++ and Python. Cross-language binding is leveraged in almost every API. 54 | 55 | ## Heterogenous calculation functions ## 56 | The heterogeneous calculation functions are used to replace vallina functions in federatedml. In a training model like Hetero-LR, the functions with high computing capacity, like gradient computing, need to be replaced in order to achieve high throughput. 57 | 58 | The normal workflow for a heterogeneous function is as follows. 59 | 60 | __Data Preprocessing__: Before calculation, the data format conversion API should be called to convert all the source data into the format that can be directly handled by heterogeneous device. 61 | 62 | __Calculation Operations__: The preprocessed input data is then fed into calculation APIs to execute corresponding computing. 63 | 64 | __Data Conversion or Postprocessing__: 65 | When all the calculations are completed, the output data is either sent to another party or deserialized for subsequent operations in Federateml, such as the recovery of overall gradient obtained after decryption. 66 | 67 | ## Other changes ## 68 | __Interoperation__: To further extend the compatibility of heterogeneous acceleration, data format conversion before data transmission from server to hardware device is necessary. There should be some more attributes in the transfer class to indicate that these variables need to be converted before transmission if the job is processed between heterogeneous FATE and vallina FATE. 69 | 70 | __New Training Parameters__: To allow the users to conveniently choose the acceleration device or activate interoperability, some parameters should be added for the user to specify the target device and training mode (interoperation or not). These parameters are checked at the very begining of a training module and determine the APIs and functions to be called. 71 | 72 | # Non-Goals # 73 | [Anything explicitly not covered by the proposed change.] 74 | 75 | # Rationale # 76 | [A discussion of alternative approaches and the trade-offs, advantages, and disadvantages of the specified approach.] 77 | 78 | # Compatibility # 79 | [A discussion of any compatibility issues that need to be considered] 80 | 81 | # Implementation # 82 | [A description of the steps in the implementation, who will do them, and when.] 83 | 84 | # Open issues (if applicable) # 85 | 86 | N/A -------------------------------------------------------------------------------- /proposal/PROPOSAL_HIGHFLIP_FATE_Adatper.md: -------------------------------------------------------------------------------- 1 | # HIGHFLIP Fate Adatper Proposal 2 | 3 | Author: Chen Zhiyu 4 | 5 | Discussion: N/A 6 | 7 | Issue: N/A 8 | 9 | ## 1.HIGHFLIP Introduction 10 | HIGHFLIP is a **high**-layer (white box) **f**ederated **l**earning **i**ntercommunication **p**rotocol, which intends to build a unified upper-layer access interface for heterogeneous federated learning platforms, shield the internal implementation differences of federated learning platforms, and achieve unified control of nodes of different platforms. The java implemented version of HIGHFLIP is already published on github with Apache 2.0 License, and source code can be accessed from https://github.com/baidu/highflip. 11 | 12 | HIGHFLIP can be applied in two scenarios: proxy scenario and extension scenario，which is relying on unified interface access capability. 13 | - In the proxy scenario, by controlling a node that is deployed on the same type as the other party, it communicates with the heterogeneous counterpart federated learning platform node, so as to achieve the federated modeling capability with heterogeneous platforms. 14 | - In the extended scenario, expand the capabilities of existing platforms, integrate the operator functions of multiple platforms, and use them in one job. 15 | 16 | THE HIGHFLIP server is daynamically extensible plugin system, and it's plugin named adapter. Any federated learning platform manufacturer can write adapter used by highflip server to provide an industry-recognized interface. 17 | 18 | ![img.png](images/highflip/fate_adapter.drawio.png) 19 | 20 | 21 | ## 2.Why adapt HIGHFLIP 22 | FATE adaptation can realize the intercommunication capabilities for other three-party platforms with their own engines and platforms based on the FATE engine. When the HIGHFLIP adaptation work is completed, FATE will have an unified top-level intercommunication access interface HIGHFLIP. If other manufacturers need to interoperate with FATE, they can use the HIGHFLIP protocol to apply proxy scenarios and control a local FATE engine to assist the three parties' own platforms to complete the upper-level operation requirements. When HIGHFLIP becomes a unified interface for all federated learning platforms to access, third-party platforms intercommunicate with other adapted HIGHFLIP platforms without requiring additional transformation, because they can reuse the same method. 23 | 24 | FATE adaptation can combine FATE's capabilities with other manufacturers' engines, and further expand the application scenarios of FATE, not only limited to platforms that use the FATE engine. When the HIGHFLIP adaptation work is completed, by expanding the scenario, the workflow of other manufacturers will be able to include the operator components not only from their own platform but also from FATE, and corporately complete a federated learning job. 25 | 26 | ## 3.Adaptation description 27 | Adapter refers to the HIGHFLIP adapter plug-in, which implements the driving logic for interacting with the platform interfaces of different manufacturers. The plug-in can be dynamically loaded by the HIGHFLIP service. HIGHFLIP provides the definition of the adaptation interface. Manufacturers can implement the corresponding driver functions according to the definition in the interface, and register the implementation class in the HIGHFLIP system to complete the adaptation work. When the HIGHFLIP service receives an external HIGHFLIP request, it will call the driver logic registered in the system according to the content of the request to complete the corresponding platform operation capabilities. 28 | 29 | HIGHFLIP's Adapter provides a variety of adaptation interface types according to the adaptation function, namely: Platform, Job, Task, Data, Operator, Partner, Config, etc. Adaptation manufacturers can choose to fully adapt or partially adapt according to their own conditions. If there is no adaptation, the default adapter inside the system will be used to complete the corresponding function. 30 | 31 | The adaptation to FATE will be completed in multiple stages: 32 | 33 | - Stage 1: Minimal Subset Adaptation. That is, only the necessary functions of Job, Task, Data, and Operator are supported, and the Operator part only included Reader/Writer, Secure XGBoost, and PSI. This stage is mainly for FATE 1.9.0 and above version to carry out the adaptation work. 34 | 35 | - Stage 2: Full Function Adaptation. That is to say, the FATE capability is fully exposed to the HIGHFLIP interface, and other callers can fully operate the FATE function through the HIGHFLIP interface. 36 | 37 | Project will create a seperated repository in FederatedAI org, and named “highflip-fate-adapter”. 38 | The output of adapter is used by HIGHFLIP server project, and FATE is accessed by it. 39 | -------------------------------------------------------------------------------- /proposal/PROPOSAL_PAILLIER_SCHEME_IPCL.md: -------------------------------------------------------------------------------- 1 | # Proposal: Accelerated Paillier cryptosystem scheme on Intel AVX512/IFMA # 2 | Author: Jingyi Jin, [Sejun Kim](https://github.com/skmono), [Xiaoran Fang](https://github.com/fangxiaoran) 3 | 4 | Discussion: N/A 5 | 6 | Issue: [FATE-Community/issues/3909](https://github.com/FederatedAI/FATE/issues/3909) 7 | 8 | # Abstract # 9 | Motivated by Intel's prior proof of concept success with WeBank, where the modular exponentiation operation is accelerated by up-to 4.7x using Intel [IPP-Crypto](https://github.com/intel/ipp-crypto) on AVX512/IFMA systems, Intel developed a new library called Intel Paillier Cryptosystem Library that wraps out the optimization techniques. IPCL is being reviewed for full compliance to the ISO/IEC 18033-6 standards, and planned to be released in Q2 2022. 10 | 11 | The proposed feature is to integrate an accelerated version of Paillier cryptosystem on AVX512/IFMA enabled Intel systems, as an alternative to [fate_paillier](https://github.com/FederatedAI/FATE/blob/master/python/federatedml/secureprotol/fate_paillier.py). 12 | 13 | # Background # 14 | Prior work with WeBank increased confidence about using Intel IceLake CPUs to accelerate Paillier scheme. Key performance bottleneck is on Modular Exponentiation. This function can be accelerated using IFMA features AVX512 instruction set, and we can parallelize its computation using the SIMD features from AVX512, with packing the values in a size of 8 batch, as shown below. 15 | 16 |
17 | 18 |
19 | 20 | The overall speedup of multi-buffer modular exponentiation with IPP-Crypto compared to conventional implementation is up to 4.7x, in terms of throughput. 21 | 22 |
23 | 24 |
25 | 26 | Intel Paillier Cryptosystem Library is essentially composed with: 27 | 28 | 1. C++ backend: Primitive Paillier functionalites implemented with IPP-crypto, which automatically detects supported instruction sets of the system to enable multi-buffer modular exponentiation 29 | 2. IPCL Python: The Python extension module built with Python bindings of the C++ backend and wrapper for easier usage of the library. 30 | 31 | # Proposal # 32 | The figure below illustrates the structure of IPCL and how it is to be integrated to FATE. 33 | 34 |
35 | 36 |
37 | 38 | IPCL is to be offered as an alternative to FATE-Paillier by user selection. 39 | 40 | # Rationale # 41 | Advantages: 42 | 43 | - Only known open-source Paillier scheme compliant to ISO/IEC 18033-6 standard 44 | - Significant performance boost in encryption and decryption 45 | 46 | Trade-offs: 47 | 48 | - No performance gain in HE addition; further investigation is needed 49 | 50 | # Compatibility # 51 | 52 | - No support on Windows and MacOS; to be supported in future releases 53 | 54 | # Implementation # 55 | The implementation of IPCL Python module will be in-line with the existing [fate_paillier.py](https://github.com/FederatedAI/FATE/blob/master/python/federatedml/secureprotol/fate_paillier.py). Maintaining the consistency of the existing FATE code base will be the highest priority, as we elect to keep the class names of `fate_paillier.py` in IPCL Python. Our module will be regarded as an alternate option to `fate_paillier`. 56 | 57 | ## API ## 58 | ### IPCL Python function definition ### 59 | To make IPCL Python to be interchangeable with existing `fate_paillier`, the 4 main class names will be the same, defined in the Python wrapper for IPCL C++ backend. The core functions of each class will retain the same name as much as possible. 60 | 61 | | Class | Core function(s) | 62 | | ---------- | ---------- | 63 | | `PaillierKeypair` | `generate_keypair` (static) | 64 | | `PaillierPublicKey` | `encrypt` | 65 | | `PaillierPrivateKey` | `decrypt` | 66 | | `PaillierEncryptedNumber` | `+`, `*` operators | 67 | 68 | - `PaillierKeypair.generate_keypair`: Generates tuple of `PaillierPublicKey` and `PaillierPrivateKey` 69 | - `PaillierPublicKey.encrypt`: Encrypts single (or `list`, `numpy.array`) `int`/`float` and returns single (or `list`) `PaillierEncryptedNumber` containing the ciphertext 70 | - `PaillierPrivateKey.decrypt`: Takes single (or `list`) `PaillierEncryptedNumber` and returns single (or `list`) decrypted plaintext 71 | - `PaillierEncryptedNumber` operators: Provides all four base arithmetic operators (ciphertext/plaintext addition/subtraction, plaintext multiplication/division) 72 | 73 | ### Utilizing more C++ features ### 74 | While the base functionality is nearly the same, IPCL and IPCL-Python will be rely more on C++ based features than those on Python. 75 | 76 | - C++ OpenMP: Due to the bottleneck of data exchange between Python integers and C++ IPP-Crypto `BigNumber`, we will use OpenMP over Python `multiprocessing`, which becomes an overhead during serialization/deserialzation of IPCL C++ objects 77 | - Packed Ciphertext: Unlike conventional `fate_paillier` where encryption/decryption and HE operations are handled based on single values, IPCL-Python will use packed ciphertexts. Whatever the input, `encrypt` will return a single `PaillierEncryptedNumber` containing all the ciphertexts. 78 | 79 | ```Python 80 | x = np.random.rand(1000) 81 | ct_x = pubkey.encrypt(x) # returns single PaillierEncryptedNumber containing all the ciphertext of encrypted x 82 | dt_x = prikey.decrypt(ct_x) # return list of decrypted numbers of ct_x 83 | print(np.allclose(x, dt_x)) # will return True 84 | ``` 85 | 86 | - Additional math functions support: As ciphertexts will be packed into single `PaillierEncryptedNumber` object, `PaillierEncryptedNumber` will support additional functions 87 | 88 | | Function name | Description | 89 | | ------------- | ----------- | 90 | | `sum`/`mean` | Return sum/mean of all packed ciphertext | 91 | | `dot` | Returns dot product with plaintext array/list | 92 | | broadcasting | addition and multiplication both will support broadcasting natively (for scalar input) | 93 | 94 | ### Release and Distribution ### 95 | We plan to release IPCL and IPCL-Python open-source via **github** by end of Q2 2022. Following the release, we will upload IPCL-Python to **Python Package Index** for easier distribution. 96 | 97 | ### Continued support ### 98 | Initially, IPCL-Python is focused on acceleration on AVX512/IFMA based systems, we will continue expanding features to work on upcoming Intel technologies. We will also continue to support non-AVX512/IFMA systems, and address any issues/suggestions. 99 | 100 | # Open issues (if applicable) # 101 | N/A 102 | -------------------------------------------------------------------------------- /proposal/architecture.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/proposal/architecture.jpg -------------------------------------------------------------------------------- /proposal/images/163323639-4f33b5ad-3247-47d4-b385-680842181d00.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/proposal/images/163323639-4f33b5ad-3247-47d4-b385-680842181d00.png -------------------------------------------------------------------------------- /proposal/images/163324216-795479e1-0356-46b2-8e28-c0739e2bf356.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/proposal/images/163324216-795479e1-0356-46b2-8e28-c0739e2bf356.png -------------------------------------------------------------------------------- /proposal/images/163325531-e248f3fe-6e7a-43c6-9788-c66ca6d514a6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/proposal/images/163325531-e248f3fe-6e7a-43c6-9788-c66ca6d514a6.png -------------------------------------------------------------------------------- /proposal/images/FATE-LLM/FATE-LLM-plan.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/proposal/images/FATE-LLM/FATE-LLM-plan.png -------------------------------------------------------------------------------- /proposal/images/FATE-LLM/FATE-LLM-roadmap.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/proposal/images/FATE-LLM/FATE-LLM-roadmap.png -------------------------------------------------------------------------------- /proposal/images/eggroll.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/proposal/images/eggroll.png -------------------------------------------------------------------------------- /proposal/images/fedipr/ar_1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/proposal/images/fedipr/ar_1.jpg -------------------------------------------------------------------------------- /proposal/images/fedipr/fig5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/proposal/images/fedipr/fig5.png -------------------------------------------------------------------------------- /proposal/images/fedipr/fig6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/proposal/images/fedipr/fig6.png -------------------------------------------------------------------------------- /proposal/images/fedipr/fig7.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/proposal/images/fedipr/fig7.png -------------------------------------------------------------------------------- /proposal/images/fedipr/paper.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/proposal/images/fedipr/paper.jpg -------------------------------------------------------------------------------- /proposal/images/fedipr/t_1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/proposal/images/fedipr/t_1.png -------------------------------------------------------------------------------- /proposal/images/highflip/fate_adapter.drawio.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FederatedAI/FATE-Community/f951b23302eb6837c2914d64bedd88546e218e45/proposal/images/highflip/fate_adapter.drawio.png --------------------------------------------------------------------------------