-
Notifications
You must be signed in to change notification settings - Fork 60
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
base: main
Are you sure you want to change the base?
Conversation
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
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. 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? |
There was a problem hiding this 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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hope 30a78d3 looks better
There was a problem hiding this comment.
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..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
related: #169 (comment)
30a78d3
to
9bcf84c
Compare
There was a problem hiding this 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.
// Should we keep these? | ||
assert_eq!(z_i.len(), self.state_len()); | ||
assert_eq!(external_inputs.len(), self.external_inputs_len()); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
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 = [ |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
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`.
7ec21d6
to
47d908a
Compare
This PR resolves #155
The current approach, allows to:
prove_step
.load_witness
trait fn forFCircuit
.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