-
Notifications
You must be signed in to change notification settings - Fork 418
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: non-native sumcheck verifier #1042
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR implements implements first iteration of the non-native sumcheck verifier in-circuit. For that we have implemented:
The implementation follows the current field-specific sumcheck implementation quite closely, but trying to decouple it from the GKR. Namely, we define similar eqEval claims as in native GKR, but instead of deferring the final round evaluation to the next claim, we evaluate it directly. This type of claim allows to check multivariate polynomials over many instances.
This PR is not yet a full implementation - particularly, we still do not provide any public methods to construct sumcheck proofs. I'm still trying to figure out a safe and convenient way for that. The idea is that the circuit designer should never have to call the sumcheck prover manually, but instead has to only define the multivariate polynomial (something implementing gate interface) and the inputs, and the framework does all the rest (evaluates the gate at the inputs, computes the random challenges for taking random linear combination of the evaluation values, runs the sumcheck prover in a hint to obtain the proof and finally runs the in-circuit sumcheck verifier). But this is API design work which can be decoupled from sumcheck prover/verifier correctness review.
Related #834
Type of change
How has this been tested?
How has this been benchmarked?
Not yet benchmarked. Will add when prover is coupled.
Checklist:
golangci-lint
does not output errors locally