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/better browser support #169

Open
wants to merge 13 commits into
base: main
Choose a base branch
from
Open

Conversation

CPerezz
Copy link
Member

@CPerezz CPerezz commented Oct 15, 2024

This PR resolves #155

The current approach, allows to:

  1. Re-use the same traits to fit-in the Circom browser folding.
  2. Allows to receive the Circom-generated witness from the browser and load them into the circuit in order to fold via prove_step.
  3. Implements a mechanism that allows to keep having the same exact APIs (Exept for the addition of load_witness trait fn for FCircuit.

Current benchmarks situate the folding cost within the browser in arround 3.9s. Which is definitely not good. But better than the current status.

An example on how to use this can actually be seen at https://github.com/CPerezz/wasm-sonobe-integration

Since the witness is generated in the browser we need a way to store it
such that it can flow from `prove_step` into `generate_constraints` due
to the API restrictions.
This commit introduces CircomFCircuitBrowser, a structure that facilitates folding of
Circom-generated circuits in the browser via WASM. It loads R1CS data,
handles witness inputs, and generates constraints for the folding process.

Resolves: #155
@CPerezz
Copy link
Member Author

CPerezz commented Oct 15, 2024

I just noticed an important thing. Unsure if it's related specifically to that. But I've tried a ton of configs and can't really tell any other cause.

Originally, with this PR I was getting ~4s prove_step calls.
When my battery dropped to <25%, i got a performance regression of +5x. I was at ~27s per fold.

I'm not sure if this is expected. But it's definitely a pain point. I know having low battery doesn't help with performance. But wasn't expecting to get such a pitfall..

Does anyone know if that's a thing?

Copy link
Collaborator

@dmpierre dmpierre left a comment

Choose a reason for hiding this comment

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

I have a few questions, notably regarding formatting and the step_native method

Copy link
Collaborator

Choose a reason for hiding this comment

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

It seems like the formatting has some strange behaviour? Line 53 has 146 characters, while wrapping happens at line 78 at line 27.

Copy link
Member Author

Choose a reason for hiding this comment

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

I agree. Unsure why this happens TBH. Let me try to fix it.

Copy link
Member Author

Choose a reason for hiding this comment

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

Hope 30a78d3 looks better

Copy link
Member Author

Choose a reason for hiding this comment

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

Tried to solve it and makes the parser unhappy...

I don't think I can do much with this..

Copy link
Collaborator

Choose a reason for hiding this comment

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

related: #169 (comment)

folding-schemes/src/frontend/circom/browser.rs Outdated Show resolved Hide resolved
folding-schemes/src/frontend/circom/browser.rs Outdated Show resolved Hide resolved
folding-schemes/src/frontend/circom/browser.rs Outdated Show resolved Hide resolved
folding-schemes/src/frontend/circom/browser.rs Outdated Show resolved Hide resolved
Copy link
Collaborator

@arnaucube arnaucube left a comment

Choose a reason for hiding this comment

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

Nice! I like the load_witness method so that it does not affect the other frontends interfaces.

Since the file browser.rs does not contain any tests, I think that is good that we ensure that things work well. In the https://github.com/CPerezz/wasm-sonobe-integration example, it is folding once, but the first fold usually is not representative since is just the 'base case' (which has less logic than the following iteration steps, and also takes less time).
Could it be updated to fold >3 iterations? so that we can check that everything works fine when folding the output of the previous fold.

folding-schemes/src/frontend/circom/browser.rs Outdated Show resolved Hide resolved
Comment on lines 63 to 65
// Should we keep these?
assert_eq!(z_i.len(), self.state_len());
assert_eq!(external_inputs.len(), self.external_inputs_len());
Copy link
Collaborator

Choose a reason for hiding this comment

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

maybe this can be changed into an 'if' that returns an error instead of panicking? so that the user of the lib does not have an uncontrolled crash of the run but an error that they can decide how to manage.

Or at least under a test flag (#[cfg(test)]) as in the original Circom frontend folding-schemes/src/frontend/circom/mod.rs#L60

Copy link
Member Author

Choose a reason for hiding this comment

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

The problem that I want to avoid is having errors. Errors are really hard to optimize for whereas panics aren't.

Also, this assert should only trigger when you're testing. In prod, you should always have a way to ensure the lengths are correct. (Notice that your'e not going to change the circuit for which you're generating witness nor anything similar.

If honest, I'd entirely remove the panics and errors and simply do panic="abort in the profile.
But, for now I left the panics so that debugging is easier.

Copy link
Member Author

Choose a reason for hiding this comment

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

Or at least under a test flag (#[cfg(test)]) as in the original Circom frontend folding-schemes/src/frontend/circom/mod.rs#L60

Notice that under a testing flag, this will never be triggered. As you will need to compile the lib for testing to then compile also the tests within the WASM binary.

Copy link
Collaborator

Choose a reason for hiding this comment

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

with the test flag it will still be triggered when running the tests, no? (previous to going into wasm in the browser)

The point of those checks is not to panic the runtime of the program that uses sonobe, but to make the dev aware that the lenghts don't match.
With the assert_eq the app breaks without the dev being able to recover.

Copy link
Member Author

Choose a reason for hiding this comment

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

Sure, should we add an error then? Or simply ignore?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think that we can do it as in the lines linked in this comment: #169 (comment)

folding-schemes/Cargo.toml Outdated Show resolved Hide resolved
ark-poly = { version = "^0.4.0", default-features = false, features = ["parallel"] }
ark-std = { version = "^0.4.0", default-features = false, features = ["parallel"] }
ark-crypto-primitives = { version = "^0.4.0", default-features = false, features = ["r1cs", "sponge", "crh", "parallel"] }
ark-ec = { version = "^0.4.0", default-features = false, features = [
Copy link
Collaborator

Choose a reason for hiding this comment

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

One question, most of the changes in this file are formatting (mostly converting one-lines into multi-lines). Is there some standard that we could use, and if so could we apply it in the CI (and in our machines too) like we do with the rustfmt?
(the split into lines make it harder to read tho)

Copy link
Collaborator

Choose a reason for hiding this comment

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

Also it seems arbitrary as @dmpierre pointed in the comment #169 (comment)
(some shorter lines get split, while longer ones keep as a oneline)

Copy link
Member Author

Choose a reason for hiding this comment

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

VSCode did that for some reason I ignore..

Happy to bring this to the previous status or use whatever tool is suggested bu you guys.

folding-schemes/src/folding/nova/circuits.rs Outdated Show resolved Hide resolved
folding-schemes/src/folding/nova/mod.rs Outdated Show resolved Hide resolved
folding-schemes/src/frontend/circom/browser.rs Outdated Show resolved Hide resolved
@CPerezz
Copy link
Member Author

CPerezz commented Oct 18, 2024

Could it be updated to fold >3 iterations? so that we can check that everything works fine when folding the output of the previous fold.

I wanted to wait for the 0xPARC folks to code the full thing to actually merge this. As I don't want to use my example as a test of correctness.

But I can update it if desired.

As @arnaucube correctly suggested to me, the `wasm` feature can be omitted as the `wasmer` loader does not require it.

Therefore, feature set, CI and code has been updated accordingly.
Also, the browser feature has been renamed to `circom-browser`.
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.

Arrange circom's frontend witness_generator's wasm within wasm
3 participants