-
Notifications
You must be signed in to change notification settings - Fork 0
Description
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()andfn check()tofn single_point_open()andfn single_point_verify(), - the multi-point procedures
fn batch_open()andfn batch_check()intofn multi_point_open()andfn 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 onfn 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.