You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
The text was updated successfully, but these errors were encountered:
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
fn open()
andfn check()
tofn single_point_open()
andfn single_point_verify()
,fn batch_open()
andfn batch_check()
intofn multi_point_open()
andfn multi_point_verify()
.Likewise, their LC generalizations become
single_point_open/verify_combinations
andfn 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 anyindividual_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
and use these whenever possible:
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.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.
The text was updated successfully, but these errors were encountered: