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

[Design Discussion] Zk Accel API via extra function parameter [Don't merge] #14

Draft
wants to merge 3 commits into
base: taiko/unstable
Choose a base branch
from

Conversation

mratsim
Copy link

@mratsim mratsim commented Jan 9, 2024

A followup on #12 and #13.

The changes required were surprisingly reasonable. No lifetime issues, no type pollution, no Send+Sync requirements.

Only the prover side has been updated to use Zal as on the verifier it's supposedly cheap and also there is a parallel iteration part when batch verification that would be incompatible with ZAL backend that use thead-local sxtorage:

let final_msm = self
.items
.into_par_iter()
.enumerate()
.map(|(i, item)| {
let instances: Vec<Vec<_>> = item
.instances
.iter()
.map(|i| i.iter().map(|c| &c[..]).collect())
.collect();
let instances: Vec<_> = instances.iter().map(|i| &i[..]).collect();
let strategy = BatchStrategy::new(params);
let mut transcript = Blake2bRead::init(&item.proof[..]);
verify_proof(params, vk, strategy, &instances, &mut transcript).map_err(|e| {
tracing::debug!("Batch item {} failed verification: {}", i, e);
e
})
})
.try_fold(
|| params.empty_msm(),
|msm, res| res.map(|proof_msm| accumulate_msm(msm, proof_msm)),
)
.try_reduce(|| params.empty_msm(), |a, b| Ok(accumulate_msm(a, b)));

In terms of API, users just need to pass engine to create_proof so breakage is minimal on external API and contained in halo2.

cc @CPerezz re our chat a couple hours ago

einar-taiko and others added 2 commits December 13, 2023 11:23
Deprecate pre-ZAL API

Insert patch in `Cargo.toml` for `../halo2curves`
Copy link

@CPerezz CPerezz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this approach a lot more than the prev two.

I thought about moving the engine to the Circuit trait as an associated type. But it would be missing create_proof and verify_proof functions.
Otherwise, if we add it to the prover, we are missing keygen.

Unsure if we need a better abstraction or something. Or we should simply settle for this.
Maybe we can discuss more during the next days.
Also, I highly suggest to start looking at privacy-scaling-explorations#243 to see how this will fit-in and if we should have anything in mind.

@@ -116,7 +118,7 @@ where
if P::QUERY_INSTANCE {
let instance_commitments_projective: Vec<_> = instance_values
.iter()
.map(|poly| params.commit_lagrange(poly, Blind::default()))
.map(|poly| params.commit_lagrange(engine, poly, Blind::default()))
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We were thinking on removing the poly definitions/utilities from this crate and move them to an external one where we can have MV and UV as well as optimizations like parallelism and maybe ZAL then too.

I'll follow-up on this. But would be nice to coordinate.

@mratsim
Copy link
Author

mratsim commented Jan 12, 2024

Some preliminary benches (using Pasta curves)

image
image

@CPerezz
Copy link

CPerezz commented Jan 17, 2024

First round of thoughts from @ed255 and me: https://hackmd.io/F6W1U6X8SLCqTciJt0nfiQ?edit

Happy to discuss more in a meeting or whatever works best

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants