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
Using the PCS in a wider context will require absorbing the commitment for Fiat Shamir.
The current challenge is that Absorb is not implemented for AffineRepr, and the current pairing-based schemes in this repo have commitments of the form:
pub struct Commitment<E: Pairing>(
/// The commitment is a group element.
pub E::G1Affine,
);
We unfortunately can't add a blanket impl like:
impl<T> Absorb for T
where
T: AffineRepr,
{
fn to_sponge_bytes(&self, dest: &mut Vec<u8>) {
todo!()
}
fn to_sponge_field_elements<F: PrimeField>(&self, dest: &mut Vec<F>) {
todo!()
}
}
Rust complains "conflicting implementations of trait absorb::Absorb for type u8".
Option 1
We could add Absorb on AffineRepr in the ec crate. However, aside from creating a cyclic dependency from ec to crypto-primitives, I think this is not the best design.
Option 2
One solution is to further restrict G: AffineRepr + Absorb. This propagates into a lot of trait bounds in the poly-commit repo, though. The upside is that it doesn't require any upstream changes, and the two current implementors of AffineRepr which are the structs short_weierstrass::Affine and twisted_edwards::Affine already have Absorb implemented.
Option 3
Larger breaking refactor that makes use of the fact that most pairing computations (and certainly our implementations in ec::models) only ever support SW. The proposal is then to rip out the associated type G1Affine from Pairing, and restrict the class of pairings that can be done to SW-curves, so that we can have:
pub struct Commitment<P: SWCurveConfig>(
/// The commitment is a group element.
pub Affine<P>,
);
This almost works, as we still have IPA Commitment struct here in poly-commit which uses the trait AffineRepr (i.e. not an associated type from Pairing):
pub struct Commitment<G: AffineRepr> {
/// A Pedersen commitment to the polynomial.
pub comm: G,
...
}
And so mixing in Option 2 would need to happen anyway, but limited to one PCS.
Option 4
Any other ideas?
The text was updated successfully, but these errors were encountered:
Summary
Using the PCS in a wider context will require absorbing the commitment for Fiat Shamir.
The current challenge is that
Absorb
is not implemented forAffineRepr
, and the current pairing-based schemes in this repo have commitments of the form:We unfortunately can't add a blanket impl like:
Rust complains "conflicting implementations of trait
absorb::Absorb
for typeu8
".Option 1
We could add
Absorb
onAffineRepr
in the ec crate. However, aside from creating a cyclic dependency fromec
tocrypto-primitives
, I think this is not the best design.Option 2
One solution is to further restrict
G: AffineRepr + Absorb
. This propagates into a lot of trait bounds in the poly-commit repo, though. The upside is that it doesn't require any upstream changes, and the two current implementors ofAffineRepr
which are the structsshort_weierstrass::Affine
andtwisted_edwards::Affine
already haveAbsorb
implemented.Option 3
Larger breaking refactor that makes use of the fact that most pairing computations (and certainly our implementations in
ec::models
) only ever support SW. The proposal is then to rip out the associated typeG1Affine
fromPairing
, and restrict the class of pairings that can be done to SW-curves, so that we can have:This almost works, as we still have IPA
Commitment
struct here in poly-commit which uses the traitAffineRepr
(i.e. not an associated type fromPairing
):And so mixing in Option 2 would need to happen anyway, but limited to one PCS.
Option 4
Any other ideas?
The text was updated successfully, but these errors were encountered: