Pysyft: SecureNN forces tensors to be shared within 2 workers only

[aristizabal95]

Describe the bug
Many of the functions implemented inside syft/frameworks/torch/crypto/securenn.py are defined in such a way that AdditiveSharingTensors can only be shared among 2 workers. This is evident by this line of code: alice, bob = x_sh.locations which appears on the lines: 108, 144, 234, 387, etc. This means that trying to run any function declared in this manner (like relu(a_sh)) will cause unpacking issues if the tensor is shared among more than 2 workers.

To Reproduce
Working script demonstrating the issue:

import torch as th
import syft as sy

hook = sy.TorchHook(th)

# Create >2 workers
alice = sy.VirtualWorker(id="alice", hook=hook)
bob = sy.VirtualWorker(id="bob", hook=hook)
jack = sy.VirtualWorker(id="jack", hook=hook)

# Create a tensor and share it among all workers
a = th.zeros(3).fix_prec().share(alice, bob, jack)

# Run relu with the shared tensor
th.nn.functional.relu(a)

# Expected: relu should run without issues
# Unexpected: relu fails with ValueError: too many values to unpack ( expected 2 )

Expected behavior
Functions defined inside securenn.py, like relu() should run even if the tensor is shared with more than 2 workers.

Desktop (please complete the following information):

• OS: MacOS Mojave 10.14.5
• Version syft==0.1.19a1

Additional context
I stumbled upon this error when trying to do inferring with a model shared among 10 workers. The problem stopped when I shared it between 2.

This may be related to the issue #2341, although in that issue there's no reference to securenn.py functions and unpacking problems.

My guess is that this could be easily solved by changing the line alice, bob = x_sh.locations with workers = x_sh.locations, and unpacking the workers when necessary with *workers or for worker in workers. I'd be up to the task if that's the case, but then I wonder if there was any reason for why not to do this in the first place. If there's any reason I'd be happy to know.

[aristizabal95]

After reading SecureNN's research paper, I understand that this is not an issue with pysyft but a limitation in the implemented protocols. Still, I believe some assertions and documented exceptions could be added so that other users are aware of this limitation.

[meandmymind]

It's actually a great limitation, because 2 workers is not the usecase the PySyft is initially designed for (many independent parties training securely).
Would be great to hear, if there's any consideration about workarounds, or another protocols that supports >2 parties that can be implemented in PySyft in future.

[github-actions[bot]]

This issue has been marked stale because it has been open 30 days with no activity. Leave a comment or remove the stale label to unmark it. Otherwise, this will be closed in 7 days.