Replies: 2 comments 1 reply
-
|
This is a good topic. We realize that the essence of NVFLARE is two things: workers that can do things, and a control logic that directs/coordinates the workers. These two concepts don't have to be mapped to a centralized server/client topology. We chose to use this centralized topology for practical reasons:
Keep in mind that control logic is to be written by researchers, who prefer simple procedural programming. |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
using Blockchain and smart contractor? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
In a federated learning system you have a set of actors that belong to different parties of the federation and
These actors either have data, or control workflows.
For example;
institution
Ahas two researchersa_r0,a_r1and three private data sourcesa_d0,a_d1,a_d2institution
Bhas three researchersb_r0,b_r1, andb_r2and two private data sourcesb_d0,b_d1In this scenario there is a bipartite matching where one side represents researchers and the other data sources.
Since we are implementing a messaging system there is no need to have a central "Server" authority. We just need some way to negotiate role and permissions in order to manage who can send messages where.
Beta Was this translation helpful? Give feedback.
All reactions