SyMPC
SyMPC copied to clipboard
OpenMined
Simulate the operations on the Workers
To properly test SyMPC we need to have installed the syft_0.3.0.
Add a method to simulate the parties operations (send and get) such that we might have a simple way to test some of the operations from our repository without installing syft.
Would this envolve simulating Node functions:
and Client functions:
Or we only need to stub one of the recv functions and one of the send functions?
I was thinking more only in stubbing the "send" function.
I was thinking that the "stores" from one client would be a "shared dictionary" - basically, all the operations we do are local - when you do a .send you only store the tensor/object in a local store that it is designated to that "client".
Aaaaah, you mean store and send.
And I would only need to stub the send function. If what I said is correct, I am gonna try to tackle this.
I am not 100% what is the best way to tackle this (create an abstract class and then extend it - and each worker to be like a "separate process").
Another thing to be careful is that we might have pieces of code like this:
client.lib.pythno.torch([1,2,3]) <--- this creates a remote tensor on the client (but we could do more stuff with each attribute we access from a client (probably you will need to use overwrite __getattr__ for our client)
While doing some preliminar investigation and experiments I saw that even if we simulate the send function somehow. We will still need the pysyft library installed.
What is the end goal? Decoupling SyMPC from PySyft, so that SyMPC does not depend on PySyft? Or we only want the tests to run without pysyft, eventhough needing it for the source code?
Yes! the end goal would be to decouple as much as possible from Syft, but being able to "register" the Syft VM/Duet in case someone wants to use it with Syft (or anything that kind of implements "our interface").
The problem we are trying to solve with this ticket is:
- faster development - sometimes there might be bugs that are not dependent on the SyMPC team to solve and we might need to open an issue in the Syft Core team.
- "Circular dependency" kind of issues - at some point we would need to add more allowed methods to be executed on the
ShareTensor(check this.
As an example for the last point. Suppose that we add a new method on the ShareTensor and we want to be able to call that operation remotely (like share_tensor_ptr.magic_method() where share_tensor_ptr is a ShareTensorPointer). We won't be able to run the tests successfully until Syft merges that PR, but the tests on Syft would also fail because it needs to add that magic_method and it requires it to be in SyMPC.
What are we doing for the moment, is to merge the failing PR in SyMPC - run the tests on Syft (they pass) - rerun the tests on SyMPC and make sure they pass