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

Feat/hybrid snark agg #1438

Draft
wants to merge 25 commits into
base: v0.13
Choose a base branch
from
Draft

Feat/hybrid snark agg #1438

wants to merge 25 commits into from

Conversation

lispc
Copy link

@lispc lispc commented Oct 24, 2024

Description

[PR description]

Issue Link

[link issue here]

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

Contents

  • [item]

Rationale

[design decisions and extended information]

How Has This Been Tested?

[explanation]


How to fill a PR description

Please give a concise description of your PR.

The target readers could be future developers, reviewers, and auditors. By reading your description, they should easily understand the changes proposed in this pull request.

MUST: Reference the issue to resolve

Single responsibility

Is RECOMMENDED to create single responsibility commits, but not mandatory.

Anyway, you MUST enumerate the changes in a unitary way, e.g.

This PR contains:
- Cleanup of xxxx, yyyy
- Changed xxxx to yyyy in order to bla bla
- Added xxxx function to ...
- Refactored ....

Design choices

RECOMMENDED to:

  • What types of design choices did you face?
  • What decisions you have made?
  • Any valuable information that could help reviewers to think critically

@lispc
Copy link
Author

lispc commented Oct 24, 2024

some high level comments:

in aggregator crate:
the name, hybrid, i would recommend the a more general/broad name, meaning "1 in many", like muxer, oneshot and so on.
hybrid, meaning combining somethings different. Actually, in this design, we could even allow v0.12, v0.13, v0.14 chunks inside batch circuit if we will. (we just did not do that).
better don't use "sp1" part of naming. Use a name like proof_a / proof_lhs , or even an array/vector of proofs/procotols.

in prover crate:
it is ok to use the name "sp1"

@@ -37,7 +41,8 @@ impl<'params> Prover<'params> {
env::set_var("KECCAK_ROWS", BATCH_KECCAK_ROW.to_string());

let prover_impl = common::Prover::from_params_map(params_map);
let chunk_protocol = force_to_read(assets_dir, &CHUNK_PROTOCOL_FILENAME);
let halo2_protocol = force_to_read(assets_dir, &FD_HALO2_CHUNK_PROTOCOL);
let sp1_protocol = force_to_read(assets_dir, &FD_SP1_CHUNK_PROTOCOL);
Copy link
Author

Choose a reason for hiding this comment

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

so we usually generate this file inside sp1-halo2-wrapper repo, and copy it here?

Choose a reason for hiding this comment

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

Yes, we load the SNARK protocol from the halo2-backend for sp1. Since that won't change post-e2e tests, this will also be published as a part of the assets for that release

);
config
.flex_gate()
.assert_is_const(&mut ctx, &preprocessed_check, Fr::ONE);
Copy link
Author

@lispc lispc Oct 24, 2024

Choose a reason for hiding this comment

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

this may be a bit not very sound. Not each poly be either sp1 or halo2, but, all poly, either all be sp1 or all be halo2. I feel your constaints will allow poly[0] == sp1_poly[0] while poly[1] == halo2_poly[1]. It is not sound.

Though in real case, this unsoundness may not affect (not sure). better fix it later. (not high priority)

ok i see. Here the design is, you verify sp1 proof & protocol, you verify halo2 proof & protocol, and you assert one of them to be true. this design is ok. But not efficient. We should optimize it later. (Actually using this design do you really need loaded_preprocessed_as_witness?) the optimized design is, we could make sp1 chunk protocol and halo2 chunk protocol, the circuits shapes be same (only fixed_columns/vk be different). So the Plonk::<PCS>::succinct_verify is called once, not twice. And assert protocol_digest outside.

Choose a reason for hiding this comment

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

oh, I thought chunks in a batch could be either sp1 or halo2. Isn't that true?

Choose a reason for hiding this comment

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

Do you mean, a batch is all sp1 or all halo2?

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

Successfully merging this pull request may close these issues.

2 participants