Reduce generics for common traits

[Pratyush]

Description

closes: #63 by following the approach of arkworks-rs/r1cs-std#83

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (main)
• Linked to Github issue with discussion and accepted design OR have an explanation in the PR that describes this work.
• Wrote unit tests
• Updated relevant documentation in the code
• Added a relevant changelog entry to the Pending section in CHANGELOG.md
• Re-reviewed Files changed in the Github PR explorer

[tsunrise]

This is so great! Thanks for doing this
some minor comments

[tsunrise]

nit: probably better to change param to params for consistency?

[tsunrise]

Wow, that's great!

[tsunrise]

I think the bounds are probably not needed? The bound is already present in ConfigGadget trait. Any config without such bound will not implement ConfigGadget correctly, no?

[Pratyush]

Unfortunately the bounds don't propagate =(

There's an RFC to fix that, but it's not implemented yet. Once it's implemented, I think the size of arkworks libraries will shrink by a large margin lol

[tsunrise]

oh no... hope that RFC will be stable soon

[Pratyush]

@weikengchen @ValarDragon what's an appropriate rate and capacity for this test?

[weikengchen]

Since this is just a test example, let us do 2 and 1.

[Pratyush]

Same here

[weikengchen]

Since this is just a test example, let us do 2 and 1.

[Pratyush]

Hi everyone, this PR should be reviewed in concert with arkworks-rs/r1cs-std#83.

High-level overview

At a high level, this PR reduces the boilerplate required for writing gadget code that is generic over the underlying components. Basically, instead of the following API:

fn hash<H: Hash<ConstraintF>, HG: HashGadget<H, ConstraintF>, ConstraintF: Field>(input: &[UInt8<ConstraintF>) -> Vec<UInt8<ConstraintF>> {
	HG::hash(input);
}

we have the following API:

fn hash<H: HashWithGadget<ConstraintF>, ConstraintF: Field>(input: &[UInt8<ConstraintF>) -> Vec<UInt8<ConstraintF>> {
	Gadget::<H>::hash(input);
}

Notice that we have fewer generic parameters, and furthermore it's conceptually cleaner: each "native" hash implementation has a single corresponding gadget implementation, instead of multiple possible ones implied by the current API:

impl HashGadget<Pedersen, ConstraintF> for PedersenGadget {
...
}

impl HashGadget<Blake2s, ConstraintF> for PedersenGadget> {
...
}

Design rationale:

This PR proposes a new design for gadgets:

/// Trait for the native version of the primitive
trait NativePrimitive {
	// native methods and types, eg:
	type Parameters;
	fn evaluate(...) -> Vec<u8>;
}

/// Trait for the native version equipped with a gadget:
trait PrimitiveWithGadget<ConstraintF: Field> {
	// gadget equivalents of the type
	type ParametersVar;
	fn evaluate_gadget(...) -> Vec<UInt8<ConstraintF>>;
}

/// Trait for use with `Gadget` type.
/// This is used mostly to allow using methods with appending gadget.
trait PrimitiveGadget<ConstraintF: Field> {
	type Native: PrimitiveWithGadget<ConstraintF, ParametersVar = Self::ParametersVar>;
	type ParametersVar;
	
	// Note the default implementation here means that we can avoid
	// duplicating code (and hence avoid errors)
	// (Ideally we'd do the same for the associated types, but unfortunately
	// associated type defaults are still unstable)
	fn evaluate(...) -> Vec<UInt8<ConstraintF>> {
		Self::Native::evaluate(...)
	}
}

/// This blanket implementation means that implementors only need with implement
/// the `NativePrimitive` and `PrimitiveWithGadget` traits, and are
/// then immediately able to use `Gadget::<N>::evaluate`.
impl<N, ConstraintF: Field> PrimitiveGadget<ConstraintF> for Gadget<N>
where
	N: PrimitiveWithGadget<ConstraintF>
{
	type Native = N;
	type ParametersVar = N::ParametersVar;
}

This new API allows the simpler usage seen above.

This design is somewhat more convoluted than necessary: it requires an extra trait, and indirection via the Gadget struct. However this is the cleanest design I could come up with that avoids compiler errors due to method resolution ambiguities. For example, the following simple candidate design doesn't work:

trait NativePrimitive {
	type Parameters;
	fn evaluate();
}
trait PrimitiveGadget: Native {
	type ParametersVar;
	fn evaluate();
}

This is because in the following context the compiler doesn't know which method to invoke:

fn thing<N: PrimitiveGadget>() {
	N::evaluate(); // Should we pick NativePrimitive::evaluate, or PrimitiveGadget::evaluate?
}