Enable WASM-compat and monitor it in the CI (#142)
* fix: Use `target_pointer_size` conditional compilation
There are some parts of the code where is needed to de/serialze
`usize`s. These, have sizes that vary depending on the target
achitecture the code is compiled for.
Hence, this adapts the de/serialization to the specific pointer size for
which the crate is being compiled to.
* change: Support WASM-compatibility and polish Cargo.toml
In order to support Wasm-compat and to simplify and improve `Cargo.toml`
readability, the follwing changes have been made:
- All the deps that can use `parallel` feature, do so. As `rayon`
supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported
- `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears
to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions
- By default, the crate uses `"ark-circom/default"` which selects the
`wasmer/sys` feature such that it knows where wasmer is
suposed to be run`.
- Added a `wasm` feature which forces `ark-circom/wasm` to be used
instead. Which internally selects the `wasmer/js` backend to be used
such that in-browser execution is possible.
- Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such
that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets,
this is not the case as they're automatically supported.
For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support
* feat: Support WASM-compatibility tests in CI
Add support for both testing the build of `sonobe/folding-schemes` for
WASM-targets and also, it's build as a dependency for a WASM-crate.
This includes a build job for the three main supported rust-WASM targets
and the same but for a thrid crate creted on-the-fly which uses
`sonobe/folding-schemes` as a dependency.
* chore: Add README docs about WASM-compat & feats
* ci: don't run WASM-compat job if PR is draft
* chore: depend on `arnaucube/circom-compat` fork.
Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we
can already switch to it as we were depending before.
* chore: minimal build/test instructions
* fix: CI typos
* fix: Update CI to use correct feature sets
* fix: `ark-grumpkin` versioning issues
As mentioned in
https://github.com/privacy-scaling-explorations/sonobe/issues/146
there's a big issue that involves some dependencies of the crate.
As a temporary fix, this forces the workspace to rely on a
"non-existing" version of `ark-grumpkin` which is immediately patched at
workspace-level for a custom version that @arnaucube owns with some
cherry-picked commits.
While this allows the CI to pass and crate to build, a better solution
is needed.
* fix: Clippy CI avoiding --all-targets
* fix: use `wasm` feat only with folding-schemes
Where the target can be any WASM one and the `parallel` feature is optional.
**Trying to build for a WASM-target without the `wasm` feature or viceversa will end up in a compilation error.**
### Docs
### Docs
Detailed usage and design documentation can be found at [Sonobe docs](https://privacy-scaling-explorations.github.io/sonobe-docs/).
Detailed usage and design documentation can be found at [Sonobe docs](https://privacy-scaling-explorations.github.io/sonobe-docs/).
### WASM-compatibility & features
The `sonobe/folding-schemes` crate is the only workspace member that supports WASM-target compilation. But, to have it working, `getrandom/js` needs
to be imported in the `Cargo.toml` of the crate that uses it as dependency.
```toml
[dependencies]
folding-schemes = { version = "0.1.0", default-features = false, features = ["parallel", "wasm"] }
getrandom = { version = "0.2", features = ["js"] }
```
See more details about `getrandom` here: https://docs.rs/getrandom/latest/getrandom/#webassembly-support.
Also, notice that:
- `wasm` feature **IS MANDATORY** if compilation to WASM targets is desired.
- `parallel` feature enables some parallelization optimizations available in the crate.
- `light-test` feature runs the computationally-intensive parts of the testing such as the full proof generation for the Eth-decider circuit
of Nova which is approximately 4-5M constraints. **This feature only matters when it comes to running Sonobe's tests.**
### Folding Schemes introduction
### Folding Schemes introduction
Folding schemes efficiently achieve incrementally verifiable computation (IVC), where the prover recursively proves the correct execution of the incremental computations.
Folding schemes efficiently achieve incrementally verifiable computation (IVC), where the prover recursively proves the correct execution of the incremental computations.