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

Make keyset size independent of 'hiding' param #28

Closed
wants to merge 3 commits into from

Conversation

davxy
Copy link
Collaborator

@davxy davxy commented Aug 20, 2024

Domain::hiding is used to control whether we want to make the proof zk (or not) by randomizing (or not) the last 3 evaluations of the domain.

Currently, setting this parameter to false has the side effect of using the 3 zk-rows to make space for 3 extra items in the keyset part.

This results in the inability to verify a proof that was generated with hiding = false in a verifier domain where hiding = true (even though this parameter is not really relevant in the verifier's context).

My point is that it would be nice to have, given a certain domain size, a fixed size for the keyset part (regardless of whether hiding is being true or not).

This would also have the added benefit of allowing this parameter (set to false) to be leveraged for producing test vectors as well.

@davxy davxy requested a review from swasilyev August 20, 2024 08:57
@davxy davxy requested a review from burdges August 21, 2024 06:42
@davxy
Copy link
Collaborator Author

davxy commented Sep 4, 2024

@swasilyev do you think this is reasonable? 😁

@swasilyev
Copy link
Collaborator

swasilyev commented Sep 5, 2024

Just talked to @AlistairStewart. He says that if we go with 1023 validators, there will be not enough rows for apk-proofs. So we can't sacrifice these 3 rows in the non-hiding case.

@davxy davxy closed this Sep 9, 2024
@davxy davxy deleted the fixed-keyset-size branch September 9, 2024 12:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants