webb-tools / zero-knowledge-gadgets

Zero-knowledge gadgets for Webb's cross-chain blockchain applications.
Apache License 2.0
89 stars 29 forks source link

[TASK] Mixer API #171

Closed lazovicff closed 2 years ago

lazovicff commented 2 years ago

To make the API more configurable and more stable, I propose the following struct:

struct MixerR1CSProver<E: PairingEngine, H: FieldHasher<E::Fr>, const HEIGHT: usize> {
    engine: PhantomData<E>,
    hasher: PhantomData<H>,
}

Which will be defined as:

type MixerR1CSProver_Bn254_Poseidon_30 = MixerR1CSProver<Bn254, Poseidon<Bn254Fr>, 30>;

With the name convention: [prover name]_[ec]_[hasher]_[tree height]

With interface:

trait MixerProver<E: PairingEngine, H: FieldHasher<E::Fr>, const HEIGHT: usize> {
    // For creating leaves where we supply the secret and the nullifier, for generating new values, pass None
    pub fn create_leaf_with_privates<R: RngCore + CryptoRng>(
        curve: Curve,
        secret: Option<Vec<u8>>,
        nullifier: Option<Vec<u8>>
        rng: &mut R,
    ) -> Result<Leaf, Error>;
    // For making proofs
    pub fn create_proof<R: RngCore + CryptoRng>(
        curve: Curve,
        secret: Vec<u8>,
        nullifier: Vec<u8>,
        leaves: Vec<Vec<u8>>,
        index: u64,
        recipient: Vec<u8>,
        relayer: Vec<u8>,
        fee: u128,
        refund: u128,
        pk: Vec<u8>,
        rng: &mut R,
    ) -> Result<MixerProof, Error>;
}

NOTE: This interface can be implemented for both R1CS and PLONK systems

drewstone commented 2 years ago

In create_leaf_with_privates there's no hasher: H in the function definition. Should we also consider adding it there? Or where is the field hasher meant to come from?

Edit: we can do the following

struct MixerR1CSProver<E: PairingEngine, H: FieldHasher<E::Fr>, const HEIGHT: usize> {
    engine: PhantomData<E>,
    hasher: H,
}

and use self.hasher

drewstone commented 2 years ago

We also need to add self to these function definitions @filiplazovic unless you have another idea how we'd access struct fields.

lazovicff commented 2 years ago

Will leave this open, since we need to do the same for PLONK