Implementation's sensitivity to network latency about emp-zk HOT 10 CLOSED

calling send_data multiple times should not get impacted by RTT a lot, because all calls are in the same direction anyway. right now, I think we need to do <5 roundtripss per 10^7 gates. What's your statement size? Is it boolean or arithmetic?

from emp-zk.

Yes, exactly---that is why I am unsure.

I am doing a statement in arithmetic polynomial proof systems.

Hard to estimate the number of gates,
but it used 7 million OT triples from VOLE.

from emp-zk.

For the information, the communication taken from io->counter is 500MB. But varying the bandwidth seems to affect little.

from emp-zk.

OOOh, change https://github.com/emp-toolkit/emp-zk/blob/master/emp-zk/emp-zk-arith/ostriple.h#L12 to 1 and see if it works. 8 means we do checking 8 times more frequently (to reduce memory).

For boolean, we used FS so the frequency of checking does not matter much, but for arithmetic, we cannot use FS (not enough concrete security)

from emp-zk.

BTW, the boundary between offline/online phase is not really very clear in our case. To have a clear offline phase, we need to do offline for all gate and store them, and this is a huge memory cost. What we do is that we prepare offline phase for 10^7 each time and then do online for 10^7. Then we switch to offline and do 10^7 of them again. So the #rounds ~ #gates/10^7*small constant

from emp-zk.

After the change in ostriple, the time is still similar.

I will come back to this one later. If useful, I can clean up my code a little bit and share a repo.

And yes. Luckily in my situation, the one big bag of OT triples (10^7) is sufficient for the statement (~6 * 10^6).

Probably also interesting---even in the same machine, proving a statement of 6 * 10^6 is about 2x-3x slower than proving a tiny statement, though both of them use one bag of OT triples (same offline phase). This may reflect that the major overhead is not in the offline time, but in the online time. Does that match the expectation from the protocol?

from emp-zk.

A correction that the number of VOLE being used is 77 million. So there are indeed 8 calls to extension. The last reply contains an incorrect number.

from emp-zk.

Let me summarize: there are two issues: 1) the per-multiplication speed decreases significantly as the latency increase; 2) the per-multiplication speed decreases significantly as the batch size becomes small, even without counting the speed of the offline phase. I suppose all are about the arithmetic setting?

from emp-zk.

I will do a more controlled experiment.

Do you mean the per-multiplication speed "increases" or "decreases" significantly when the latency increases? And here the batch size refers to FP_CHECK_DIV_SZ in ostriple.h specifically?

from emp-zk.

updated! that's right. batch_size = 10^7/FP_CHECK_DIV_SZ

from emp-zk.