Use real trusted setup instead of a random generator

[alxkzmn]

No description provided.

[alxkzmn]

@leolara I need some advice here on how to better deal with the common functionality while creating the provers. The only difference between supercircuit and single circuit is in the compilation, so I offloaded it into a Halo2Compilable trait. I want it to stay private because it's only used in our halo2 backend. At the same time, it should be shared between both implementations of PlonkishHalo2. When I make it a super trait of PlonkishHalo2 here the clippy gives warning that Halo2Compilable is more private than PlonkishHalo2 which is my intention because I don't want to expose the compilation to a Chiquito API consumer. Do you think there's a better way to do that while not repeating the code?

[leolara]

Does this compile, that PlonkishHalo2 is public descendant from a private trait? Interesting

[alxkzmn]

It does :)

[leolara]

This looks like a good solution

[leolara]

Perhaps, it would be even more interesting a blanket trait impl

impl<T: Halo2Compilable> PlonkishHalo2 for T {
    fn create_halo2_prover ....
}

[leolara]

That way PlonkishHalo2 wouldn't have to inherit from the private Halo2Compilable

[leolara]

I think there might be more things to configure in the prover than that path. We should create a Config struct, that could pass the path or the Rng.

[leolara]

@alxkzmn I would call this method halo2_compile.

[alxkzmn]

Do you mean

pub trait PlonkishHalo2<W, WG: Halo2WitnessGenerator<Fr, W>>: Halo2Compilable<W, WG> {
    fn create_halo2_prover(&mut self, params: ProverParams) -> Halo2Prover<Fr, W, WG>;
}

struct ProverParams {
  Option<path>;
  Optin<rng>;
}

and let the caller create the ProverParams? Currently I like that the caller shouldn't worry about the way params are created. If the caller should pass the params, they'll have to take care about what rng to use, and we probably need to disallow them to create params with both rng and path at the same time.

[leolara]

@alxkzmn You are right, create_halo2_prover is specific for halo2, so it makes sense to get their native params.

[leolara]

@alxkzmn I think there has been a misunderstanding again.

I am saying to do:

impl<T: Halo2Compilable>  Halo2Provable for T {
    fn create_halo2_prover( ....
}

that way you don't need #[allow(private_bounds)]

[leolara]

With the trait Halo2Provable without default implementation for create_halo2_prover