Supernova params memory caching
Closed this issue · 3 comments
This is a question and maybe also a code issue, not sure. You guys have making some changes to the parameters in recent PRs so maybe this is a good time to ask.
I haven't seen any examples in the code of caching the supernova params in memory to avoid the expensive call to supernova_public_params(&instance_primary).unwrap();
each time one needs to verify a proof.
I was doing it like this in my code:
static PUBLIC_PARAMS: OnceCell<Arc<PublicParams<Fr, C1LEM<'static, Fr, MultiCoproc<Fr>>>>> = OnceCell::new();
fn get_public_params() -> Arc<PublicParams<Fr, C1LEM<'static, Fr, MultiCoproc<Fr>>>> {
PUBLIC_PARAMS.get_or_init(|| Arc::new(create_public_params())).clone()
}
fn create_public_params() -> PublicParams<Fr, C1LEM<'static, Fr, MultiCoproc<Fr>>> {
[...]
let instance_primary = Instance::new(REDUCTION_COUNT, lang_rc, true, Kind::SuperNovaAuxParams);
let pp = supernova_public_params(&instance_primary).unwrap();
pp
}
This worked well (whether or not it was the correct way 🤷) but it stopped working with the recent commits over the last day or so.
It seems to be related to the requirement that the lifetime of the store match the lifetime of the params.
let (proof, _z0, zi, _num_steps) = supernova_prover.prove_from_frames(&pp, &frames, &store...
| -------------------------------------------------^^^^^^-
| | |
| | borrowed value does not live long enough
| argument requires that `store` is borrowed for `'static`
...
346 | }
| - `store` dropped here while still borrowed
So my question is if there is a proper way to cache the params in memory that I'm not doing? Or if this is generally how it's supposed to be done then maybe there's issues with the lifetime requirements on the supernova_prover
.
I believe this is due to lurk-lang/arecibo#285 (adapted in Lurk as #1085, which I'd advise having a look at to see the lurk-side changes) and that @winston-h-zhang has an approach to fix this in lurk-lang/arecibo#288.
Would it be possible to set the arecibo dependency to use a commit prior to the PR that changed this in the meantime?
Yeah shouldn't be a problem. There's no rush.
Works good!