Skip to content

Add Absorb trait bound on PCCommitment #143

Open
@mmagician

Description

@mmagician

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 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?

Metadata

Metadata

Assignees

No one assigned

    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