Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minimize need for repeated generic arguments. #63

Open
Pratyush opened this issue Jul 16, 2021 · 1 comment · May be fixed by #68
Open

Minimize need for repeated generic arguments. #63

Pratyush opened this issue Jul 16, 2021 · 1 comment · May be fixed by #68
Labels
D-hard Difficulty: hard P-high Priority: high T-design Type: discuss API design and/or research

Comments

@Pratyush
Copy link
Member

Pratyush commented Jul 16, 2021

Using many gadgets requires repeating type parameters: once for the native version, and once for the constraint version. However, this seems redundant as usually there's only a single gadget for a particular primitive. So, it makes sense to tie the gadget to the native impl. We can do this via an extension trait, as follows:

pub trait CRHGadget<ConstraintF: Field>: CRH {
	type ParametersVar: AllocGadget<Self::Parameters>;
	type InputVar: AllocGadget<Self::Input>;
	type OutputVar: AllocGadget<Self::Output>;
	
	fn evaluate(params: &Self::ParametersVar, input: &[UInt8]) -> R1CSResult<Self::OutputVar>; 
}

impl CRHGadget for PedersenCRH { ... } // Note: this is implemented for *PedersenCRH*, not PedersenCRHGadget.

We can invoke this as

fn hash<H: CRHGadget<ConstraintF>, F: Field>(...) {
	H::evaluate(&params, &input)?;
}

We've reduced the number of type parameters greatly. This works for Gadget traits which don't contain variables themselves. What about Var traits, which contain variables? We can still use them, as follows:

trait FieldExt {
	type Var: FieldVar<...>;//figure out what to put in the type parameters.
}

impl FieldExt for FpN {
...
}

This would allow us to access the "unique" variable type for a given field element, without introducing multiple type parameters.

Feedback on this idea is very welcome!

@tsunrise
Copy link
Member

tsunrise commented Jul 16, 2021

should input be &Self::InputVar instead of &[UInt8]? (or rather, Borrow<Self::InputVar>)

Yeah this API looks good (if possible). One minor issue is that we have to bound input var is an AllocVar of Self::Input, which might not always be the case (in fact, InputVar do not even need to be Sized right?). It makes sense to bound OutputVar, but do we really need to bound InputVar?

@Pratyush Pratyush linked a pull request Aug 16, 2021 that will close this issue
6 tasks
@Pratyush Pratyush added D-hard Difficulty: hard P-high Priority: high T-design Type: discuss API design and/or research labels Sep 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
D-hard Difficulty: hard P-high Priority: high T-design Type: discuss API design and/or research
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants