Have you considered implementing ABY2.0 protocol?

[BeStrongok]

Hi, :)
I'm noticed that the ABY2.0 protocol has constant round in online communication, which is very effective for Secure Two-Party Computation.
Have you considered implementing this protocol? When i'm benchmarking Cheetah, i don't think it's fast enougth, maybe this protocol is more efficiently?
BTW, because SPU has JIT compilation, i'm curious about how to divide offline & online process.

[fionser]

A quick response is no.

• For the current point, I am not seeing the advantage of using ABY2.0. Especially for large arithmetic computation (matmul, conv2d etc).
• Also, GC demands a significantly larger communication overhead. I am not sure whether the SPU team will have any idea to implement GC.

[icavan]

Hi, :) I'm noticed that the ABY2.0 protocol has constant round in online communication, which is very effective for Secure Two-Party Computation. Have you considered implementing this protocol? When i'm benchmarking Cheetah, i don't think it's fast enougth, maybe this protocol is more efficiently? BTW, because SPU has JIT compilation, i'm curious about how to divide offline & online process.

hi @BeStrongok , as @fionser point out, I do not think ABY 2.0 deserve the implementation since it will be slower than Cheetah. 2PC mpc is still quite challenging, if you've tested the cheetah LR performance, you'll find it at least 10x faster than the FATE 3pc Hetero LR, which is already quite amazing since Cheetah does not require a trusted Arbitor role.

hi @fionser , GC requires too much communication overhead, we do have an internal version but not yet been widely used in real business. We might consider adding one for research purposes.

[icavan]

Hi, :) I'm noticed that the ABY2.0 protocol has constant round in online communication, which is very effective for Secure Two-Party Computation. Have you considered implementing this protocol? When i'm benchmarking Cheetah, i don't think it's fast enougth, maybe this protocol is more efficiently? BTW, because SPU has JIT compilation, i'm curious about how to divide offline & online process.

BTW, the challenging part of 2PC protocol is the offline stage. Hence, constant round in the online stage does not really make a big difference.

Currently, the offline & online stages are merged together. We plan to add a Just-In-Time offline correlated randomness generator that tries to pre-compute the offline stuff beforehand. We believe it will help improve the performance of 2PC applications. Stay tuned.

[BeStrongok]

Hi, :) I'm noticed that the ABY2.0 protocol has constant round in online communication, which is very effective for Secure Two-Party Computation. Have you considered implementing this protocol? When i'm benchmarking Cheetah, i don't think it's fast enougth, maybe this protocol is more efficiently? BTW, because SPU has JIT compilation, i'm curious about how to divide offline & online process.

BTW, the challenging part of 2PC protocol is the offline stage. Hence, constant round in the online stage does not really make a big difference.

Currently, the offline & online stages are merged together. We plan to add a Just-In-Time offline correlated randomness generator that tries to pre-compute the offline stuff beforehand. We believe it will help improve the performance of 2PC applications. Stay tuned.

Thanks for quickly reply. @fionser @icavan :)
I think constant round in the online stage is really helpful in secure network inference, the pre-compute offline triples can be saved in database and be used in-time, especially when the network latency is very high.
Maybe an offline pre-compute service can be implemented for online inference, do you think this work make sense?
I will continue to learn Cheetah protocol, many principles and details are not yet fully understood.

[icavan]

Hi, :) I'm noticed that the ABY2.0 protocol has constant round in online communication, which is very effective for Secure Two-Party Computation. Have you considered implementing this protocol? When i'm benchmarking Cheetah, i don't think it's fast enougth, maybe this protocol is more efficiently? BTW, because SPU has JIT compilation, i'm curious about how to divide offline & online process.

BTW, the challenging part of 2PC protocol is the offline stage. Hence, constant round in the online stage does not really make a big difference.
Currently, the offline & online stages are merged together. We plan to add a Just-In-Time offline correlated randomness generator that tries to pre-compute the offline stuff beforehand. We believe it will help improve the performance of 2PC applications. Stay tuned.

Thanks for quickly reply. @fionser @icavan :) I think constant round in the online stage is really helpful in secure network inference, the pre-compute offline triples can be saved in database and be used in-time, especially when the network latency is very high. I will continue to learn Cheetah protocol, many principles and details are not yet fully understood.

Yes, constant round solutions like FHE/GC-style are appreciated, especially in inference scenarios. Users need to check what's the real bottleneck: computation, bandwidth, or latency. Hope you get your answer in your cases.

[BeStrongok]

Hi, :) I'm noticed that the ABY2.0 protocol has constant round in online communication, which is very effective for Secure Two-Party Computation. Have you considered implementing this protocol? When i'm benchmarking Cheetah, i don't think it's fast enougth, maybe this protocol is more efficiently? BTW, because SPU has JIT compilation, i'm curious about how to divide offline & online process.

BTW, the challenging part of 2PC protocol is the offline stage. Hence, constant round in the online stage does not really make a big difference.
Currently, the offline & online stages are merged together. We plan to add a Just-In-Time offline correlated randomness generator that tries to pre-compute the offline stuff beforehand. We believe it will help improve the performance of 2PC applications. Stay tuned.

Thanks for quickly reply. @fionser @icavan :) I think constant round in the online stage is really helpful in secure network inference, the pre-compute offline triples can be saved in database and be used in-time, especially when the network latency is very high. I will continue to learn Cheetah protocol, many principles and details are not yet fully understood.

Yes, constant round solutions like FHE/GC-style are appreciated, especially in inference scenarios. Users need to check what's the real bottleneck: computation, bandwidth, or latency. Hope you get your answer in your cases.

Thanks for your guidance, more research i need to do. My case is high latency, so constant round is really what i need. :) This is also a main reason i mentioned ABY2.0 protocol, but i ignored the GC performance.

[BeStrongok]

A quick response is no.

• For the current point, I am not seeing the advantage of using ABY2.0. Especially for large arithmetic computation (matmul, conv2d etc).
• Also, GC demands a significantly larger communication overhead. I am not sure whether the SPU team will have any idea to implement GC.

Thank you for point out this factors, GC is really expensive in large arithmetic computation, such as network communication. What confuses me is the high latency, parties are not peer-to-peer communication.
Such as A2B protocol, which is really common in mixed-protocol framework, could become slowly in high latency case.

[anakinxc]

Hi @BeStrongok

One question here, you mentioned you were benchmarking Cheetah, may I ask with which version of SPU?

Thanks

[BeStrongok]

Hi @BeStrongok

One question here, you mentioned you were benchmarking Cheetah, may I ask with which version of SPU?

Thanks

I have opened an issue about the performance of Cheetah here, the training time of SS-LR in one epoch is relatively slowly.
Maybe the SPU Team made some improvement in the subsequent version.
BTW, i'm reading some papers about the packed secret sharing, i.e. TURBOPACK, hope it can bring me help.

[anakinxc]

Hi @BeStrongok
One question here, you mentioned you were benchmarking Cheetah, may I ask with which version of SPU?
Thanks

I have opened an issue about the performance of Cheetah here, maybe the SPU Team made some improvement in the subsequent version.

Hi @BeStrongok,

That is pretty old.

We have made lots of improvements to both Cheetah(credits to @fionser) and other thingy. I would recommend you give it another try :P

[BeStrongok]

Hi @BeStrongok
One question here, you mentioned you were benchmarking Cheetah, may I ask with which version of SPU?
Thanks

I have opened an issue about the performance of Cheetah here, maybe the SPU Team made some improvement in the subsequent version.

Hi @BeStrongok,

That is pretty old.

We have made lots of improvements to both Cheetah(credits to @fionser) and other thingy. I would recommend you give it another try :P

Thanks, it's pretty cool! I will try new version!

[BeStrongok]

Hi, SPU Team:
I'm reading the paper of ABY2.0, and find that this paper introduced some improved primitives, such as sec. 5.3 Depth-Optimized Circuits and sec. 5.5 Truncation.
As for Depth-Optimized Circuits, the depth of circuits can be reduced from 6 to 3 in 64 bit length through 3- and 4-input AND/MUL gates.
As for Truncation, it refers SecureML and do not influence the communication round in multiplication.
I'm not sure these primitives have been implemented in SPU, if so, could you help me point out the corresponding code? I want to learn it, thanks very much!

[anakinxc]

Hi @BeStrongok

SPU has implemented PPA here.

For truncation, we have lots of truncation kernels. SecureML's you can find it here

Thanks

[BeStrongok]

Thanks for pointing these codes, it's really helpful! But it seems not the 3- and 4-input AND gates introduced by ABY2.
Maybe i'm wrong, i will learn your code carefully, thanks again! :)

[rivertalk]

Thanks for pointing these codes, it's really helpful! But it seems not the 3- and 4-input AND gates introduced by ABY2. Maybe i'm wrong, i will learn your code carefully, thanks again! :)

Hi @BeStrongok, sorry for the late reply.

You are right, the code is the simplest 2-input adder circuit. The 3- and 4- input circuit is NOT implemented in SPU for now.

IMHO, ABY 2.0 does not bring enough benefits (compared to Cheetah) under the premise of greatly increasing the complexity of the system, so in the case of limited time, we prefer to optimizing Cheetah instead of implement ABY 2.0.

However, the SPU itself is designed as an extensible system and we do not rule out the possibility of introducing ABY2.0. Of course, you are always welcome to contribute new protocols :P

[BeStrongok]

Thanks for pointing these codes, it's really helpful! But it seems not the 3- and 4-input AND gates introduced by ABY2. Maybe i'm wrong, i will learn your code carefully, thanks again! :)

Hi @BeStrongok, sorry for the late reply.

You are right, the code is the simplest 2-input adder circuit. The 3- and 4- input circuit is NOT implemented in SPU for now.

IMHO, ABY 2.0 does not bring enough benefits (compared to Cheetah) under the premise of greatly increasing the complexity of the system, so in the case of limited time, we prefer to optimizing Cheetah instead of implement ABY 2.0.

However, the SPU itself is designed as an extensible system and we do not rule out the possibility of introducing ABY2.0. Of course, you are always welcome to contribute new protocols :P

Yes, i think these generic primitives may be utilized to optimize the existed protocols in SPU, such as ABY3/Semi2k.
I will try to implement the 3- and 4- input circuit and to see if it can bring any benefits, the paper and wonderful implementation of Cheetah is the place where i will focus on learning.
Thanks for the helpful reply! :)