Skip to content
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

ParamsVerifierKZG is ParamsKZG even though it could be smaller #280

Closed
DamianStraszak opened this issue Feb 20, 2024 · 3 comments · Fixed by #318
Closed

ParamsVerifierKZG is ParamsKZG even though it could be smaller #280

DamianStraszak opened this issue Feb 20, 2024 · 3 comments · Fixed by #318
Assignees
Labels
tech-debt Tech-debt related issues

Comments

@DamianStraszak
Copy link

DamianStraszak commented Feb 20, 2024

ParamsKZG is a potentially huge piece of data and in the current implementation there is no way to avoid passing it as an argument to the verify_proof function, which is supposed to be blazingly fast (and it is!) so there is no point for it taking arguments that it's not even consuming.

This is because this function takes params: Scheme::ParamsVerifier as an argument and for KZG this is the full ParamsKZG (so 2^k elements) because of this line https://github.com/privacy-scaling-explorations/halo2/blob/main/halo2_backend/src/poly/kzg/commitment.rs#L273. Note that in reality it would be enough for ParamsVerifierKZG to be of constant size -- just a few group elements, because that's what you need to verify KZG commitments.

There was this issue #45 back in the days that kind of improved the situation. While the proof system has been adjusted for KZG, there is still the burden of supporting V::QUERY_INSTANCE = true in verify_proof so unfortunately this didn't fully solve the problem.

This problem is kind of solvable using some dirty tricks, but I think there should be something that we can do to make it pretty. Currently this issue causes me and my team a lot of pain :)

Is this a problem that is annoying anyone besides me? Would there be interest in some discussion and potentially a PR that would attempt to solve it? I would love to hear some opinions.

@CPerezz CPerezz added the tech-debt Tech-debt related issues label Feb 21, 2024
@CPerezz
Copy link
Member

CPerezz commented Feb 21, 2024

Indeed this is true, and we should be able to improve it.
I'm happy to see a PR trying to address that although can't guarantee will make it to main.

The best option I think is to quickly state a brief draft of the proposal on how to solve this. And discuss over the idea.

cc: @han0110 @kilic maybe there's some extra things that you want to add prior.

@davidnevadoc davidnevadoc self-assigned this Mar 12, 2024
@kilic
Copy link

kilic commented Mar 16, 2024

@DamianStraszak As far as I remember downsize API is introduced for this reason as a workaround

@davidnevadoc
Copy link

I believe downsize reduces the size of the domain and as a result it also changes the values of g_lagrange.
With a new struct for verifier parameters we can get rid of all the original G1 elements and most of the ones in Lagrange form.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tech-debt Tech-debt related issues
Projects
None yet
4 participants