Sumcheck #18
Sumcheck #18
Conversation
|
As far as I see, new file |
|
@mpenciak , I added basic unit-testing for primary part of sumcheck computation. There were some issues with using the right modulus and negation. Having this as an example, it should be easier to implement secondary part and update data contract as well as Python generator script. |
There was a problem hiding this comment.
I like the idea of having bunch of absorb functions, each taking its own type of input at a KeccakTranscript level. It seems to be a bit more ergonomic than what I used in pp-spartan branch, where I have similar bunch of toTranscriptBytes functions and I have to introduce a redundant intermediate uint8[] memory variable all the time, when I need to invoke absorb.
At the same time, after taking draft code from early version of this PR and adapting it for usage in pp-spartan branch, I have couple of remarks:
I think a lot of Sumcheck's logic can be implemented in a more generic way: in some places we can pass modulus as a uint256 variable (either Vesta or Pallas), also we can use passing function as a parameter if we need to use particular negation. Also, structures that operates with just uint256 can be defined only once.
It looks like you implemented some more types of evaluations, however, from my experience, the pp-spartan verification uses only sumcheck over UniPoly polynomials (this implementation is sufficient for e2e pp-spartan verification). Though I didn't check if other polynomials are used while IPA (as it is going to be replaced with KZG/Zeromorph eventually). Anyway, if these logic is useful and we want to keep it as a building block (yet unused in high-level verification), it needs to be somehow tested.
Note: The data contract has data for all of the outer, inner, and batched sumchecks, though only the outer data is used in the primary and secondary sumcheck tests. Once computational commitments are implemented, we can write end to end tests that will use the inner and batched data.