You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think that the only way to have this type is to create a vector of slices, take it as slice, and create another vector of that, and take it as slice. So we end up creating 2 vectors just to get this type. Why not pass a slice of vectors instead? It would simplify the interaction with the proving/verifying API.
Here's an example of the gymnastics that need to be done to create 1 proof:
let instances = circuit.instances(); // This is `Vec<Vec<F>>`
let instances_slice: &[&[Fr]] = &(instances
.iter()
.map(|instance| instance.as_slice())
.collect::<Vec<_>>()); // We already had a vector, but we need to create another one to hold slices instead of Vec :(
create_proof::<KZGCommitmentScheme<Bn256>, ProverSHPLONK<'_, Bn256>, _, _, _, _>(
¶ms,
&pk,
&[circuit],
&[instances_slice],
&mut rng,
&mut transcript,
)
.expect("proof generation should not fail");
I would propose to use change the API to use:
instances:&[Vec<Vec<Scheme::Scalar>>],
NOTE: If we apply this change on the legacy API, we will have a breaking change, so I suggest keeping the legacy API as it is. But we can do this change on the frontend-backend split API!
The text was updated successfully, but these errors were encountered:
Currently the API for proving/verifying receives the instances as:
halo2/halo2_proofs/src/plonk/prover.rs
Line 49 in 73408a1
I think that the only way to have this type is to create a vector of slices, take it as slice, and create another vector of that, and take it as slice. So we end up creating 2 vectors just to get this type. Why not pass a slice of vectors instead? It would simplify the interaction with the proving/verifying API.
Here's an example of the gymnastics that need to be done to create 1 proof:
I would propose to use change the API to use:
NOTE: If we apply this change on the legacy API, we will have a breaking change, so I suggest keeping the legacy API as it is. But we can do this change on the frontend-backend split API!
The text was updated successfully, but these errors were encountered: