Skip to content

Restructuring PCs #6

@UlrichHaboeck75

Description

@UlrichHaboeck75

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.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions