Open bhgomes opened 2 years ago
Open Design Questions:
HomomorphicCommitment
trait?PolynomialCommitment
is hiding)?And a setup
method on an extension trait:
trait PolynomialCommitmentSetup<F>: PolynomialCommitment<F>
where
F: Field,
{
/// Samples a [`CommitKey`](Self::CommitKey) and [`VerifyKey`](Self::VerifyKey) for
/// this polynomial commitment scheme.
///
/// # Safety
///
/// In general, this sampling is not secure and could leak a trapdoor for this commitment scheme.
/// Instead, use keys generated by a multi-party trusted setup for more security against
/// trapdoor-based attacks.
fn setup<R>(rng: &mut R) -> (Self::CommitKey, Self::VerifyKey)
where
R: CryptoRng + RngCore + ?Sized;
}
For PLONK, we only need a subset of the
ark-poly-commit
interface and a lot of theark-poly-commit
APIs are unnecessarily restrictive. I propose the following trait for the generic PLONK interface:This design has some advantages over the
ark-poly-commit
interfaces like:String
s that we are also not usingark-poly-commit
interfaces require a method calledcommit
which performs an iterated sequence of commits. For each of the implementations in the standard arkworks library, this method does exactly the same thing (the implementation defined incommit_many
) but makes it required, not optional.It would then be relatively easy to implement KZG, IPA, etc. under this new API and expose them to users. Also, it would also be relatively easy to write an adapter from any
ark_poly_commit
implementer to this API since we have fewer requirements.