You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi!
I think something is missing in the implementation. Please correct me if I'm wrong!
In each layer of the circuit we have 3 instances of the sumcheck protocol that can be performed in paraller but not entirely seperately! because these instances use the same public randomness provided by the verifier!
In this implementation, The GKRLinearSumchek works fine on its own, but is not applicable in the GKR scenario, since each instance uses its own randomness! In other words, in your implementation, each prover instance creates the randomness from the previous prover messages; However, all the prover messages should be summed and the randomness should be created upon the summed value.
Suggestion: I think it would be better if each instance had a handle to a common prover state.
Thanks
The text was updated successfully, but these errors were encountered:
This is a good idea; parallel composition/batching of the protocols should lead to big perf improvements for both the prover and the verifier. I'm not the maintainer of this code, and so wouldn't be comfortable implementing the change myself, but would be happy to review a PR for it!
Cool! I forked the repo and will create the PR soon.
BTW I think It would be better if the maintainer also confirmed my opinion. Since the Libra paper is somehow vague about this, I qoute from the paper:
"Due to linearity of the sumcheck protocol, the prover can execute these 3 instances simultaneously in every round, and sum up the individual messages and send them to the veriifer."
Hi!
I think something is missing in the implementation. Please correct me if I'm wrong!
In each layer of the circuit we have 3 instances of the sumcheck protocol that can be performed in paraller but not entirely seperately! because these instances use the same public randomness provided by the verifier!
In this implementation, The GKRLinearSumchek works fine on its own, but is not applicable in the GKR scenario, since each instance uses its own randomness! In other words, in your implementation, each prover instance creates the randomness from the previous prover messages; However, all the prover messages should be summed and the randomness should be created upon the summed value.
Suggestion: I think it would be better if each instance had a handle to a common prover state.
Thanks
The text was updated successfully, but these errors were encountered: