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

Restructuring PCs #6

Open
UlrichHaboeck75 opened this issue Apr 2, 2021 · 0 comments
Open

Restructuring PCs #6

UlrichHaboeck75 opened this issue Apr 2, 2021 · 0 comments
Assignees

Comments

@UlrichHaboeck75
Copy link

Independent of Maxims pull request I'd recommend to change the PC trait and change the names therein. The use of "batch" whenever one refers to multi-point procedures is highly misleading and we might get even more in trouble when we want to introduce batch verification (as Daniele implemented for the Mainchain side). Beyond that, passing "individual opening challenges" is not suitable beyond single point assertions as the logic of hashing/absorb-squeeze cannot be outsourced.

I'd opt to remove all individual opening challenges functions from the PC trait, and rename

  • the single point procedures fn open() and fn check() to fn single_point_open() and fn single_point_verify(),
  • the multi-point procedures fn batch_open() and fn batch_check() into fn multi_point_open() and fn multi_point_verify().

Likewise, their LC generalizations become single_point_open/verify_combinations and fn multi_point_open/verifiy_combinations(). Having not a sponge for now does not matter, we just templatize the functions with a random oracle, and compute the challenge hashes in the correct Fiat-Shamir treatment inside the open and verify functions (which do not call any individual_opening_challenges() functions).

Beyond that, I think we can improve the code organization within ipa_pc.
Every open and verify procedure depends on the elementary single-point single-segment procedures, which only handle single segmented polynomials/LCs at a single query point.
We can give them meaningful names such as

fn single_point_open/verify_segments() 
fn single_point_open/verify_segment_lcs()

and use these whenever possible:

  • Single-point assertions: The treatment of segmentation as well as degree proofs
    can rely on fn single_point_open/verify_segment_lc() by translating the opening/degree bound assertions into that of LC's. Doing so extends these functions to their arbitrary many segments variants.
  • Multi-point assertions: not much to do here, as the multi-point treatment a la Boneh, Gabizon just reduces the multi-point assertion to an equivalent single-point assertion.

Actually the approach how to treat segmentation and multi-point assertions is generic (as long as we stay in the class of linear commitment schemes). It might be worth to think about moving it outside ipa.

@UlrichHaboeck75 UlrichHaboeck75 changed the title Refactoring PCs Restructuring PCs Apr 6, 2021
@DanieleDiBenedetto DanieleDiBenedetto linked a pull request Dec 9, 2021 that will close this issue
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 a pull request may close this issue.

2 participants