* 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
AugmentedFCircuit (#84)
sonobe
Experimental folding schemes library implemented jointly by 0xPARC and PSE.
Sonobe is a modular library to fold arithmetic circuit instances in an Incremental Verifiable computation (IVC) style. It features multiple folding schemes and decider setups, allowing users to pick the scheme which best fits their needs.
Sonobe is conceived as an exploratory effort with the aim to push forward the practical side of folding schemes and advancing towards onchain (EVM) verification.
"The Sonobe module is one of the many units used to build modular origami. The popularity of Sonobe modular origami models derives from the simplicity of folding the modules, the sturdy and easy assembly, and the flexibility of the system."
Warning
: experimental code, do not use in production.
The code has not been audited. Several optimizations are also pending. Our focus so far has been on implementing the Nova and CycleFold schemes and achieving onchain (EVM) verification.
Schemes implemented
Folding schemes implemented:
- Nova: Recursive Zero-Knowledge Arguments from Folding Schemes, Abhiram Kothapalli, Srinath Setty, Ioanna Tzialla. 2021
- CycleFold: Folding-scheme-based recursive arguments over a cycle of elliptic curves, Abhiram Kothapalli, Srinath Setty. 2023
- HyperNova: Recursive arguments for customizable constraint systems, Abhiram Kothapalli, Srinath Setty. 2023
Work in progress:
- ProtoGalaxy: Efficient ProtoStar-style folding of multiple instances, Liam Eagen, Ariel Gabizon. 2023
Available frontends
Available frontends to define the folded circuit:
Usage
Build & test
You can test the library for both, WASM-targets and regular ones.
Regular targets
Tier-S targets allow the user to simply run cargo test or cargo build without needing to worry about anything.
We strongly recommend to test using the light-test feature. Which will omit the computationally intensive parts of the tests such as
generating a SNARK of 4~5M constraints to then verify it.
WASM targets
In order to build the lib for WASM-targets, use the following command:
cargo build -p folding-schemes --no-default-features --target wasm32-unknown-unknown --features "wasm, parallel".
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
Detailed usage and design documentation can be found at 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.
[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:
wasmfeature IS MANDATORY if compilation to WASM targets is desired.parallelfeature enables some parallelization optimizations available in the crate.light-testfeature 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 efficiently achieve incrementally verifiable computation (IVC), where the prover recursively proves the correct execution of the incremental computations.
Once the IVC iterations are completed, the IVC proof is compressed into the Decider proof, a zkSNARK proof which proves that applying n times the F function (the circuit being folded) to the initial state (z_0) results in the final state (z_n).
Where w_i are the external witnesses used at each iterative step.
In other words, it allows to prove efficiently that z_n = F(...~F(F(F(F(z_0, w_0), w_1), w_2), ...), w_{n-1}).
Overview of sonobe
Sonobe is a folding schemes modular library to fold arithmetic circuit instances in an incremental verifiable computation (IVC) style. It also provides the tools required to generate a zkSNARK proof out of an IVC proof and to verify it on Ethereum's EVM.
The development flow using Sonobe looks like:
- Define a circuit to be folded
- Set which folding scheme to be used (eg. Nova with CycleFold)
- Set a final decider to generate the final proof (eg. Spartan over Pasta curves)
- Generate the decider verifier
The folding scheme and decider used can be swapped with a few lines of code (eg. switching from a Decider that uses two Spartan proofs over a cycle of curves, to a Decider that uses a single Groth16 proof over the BN254 to be verified in an Ethereum smart contract).
The Sonobe docs contain more details about the usage and design of the library.
Complete examples can be found at folding-schemes/examples
License
Sonobe is MIT Licensed.
Acknowledgments
This project builds on top of multiple arkworks libraries. It uses Espresso system's virtual polynomial abstraction and its SumCheck implementation.
The Solidity templates used in nova_cyclefold_verifier.sol, use iden3's Groth16 implementation and a KZG10 Solidity template adapted from weijiekoh/libkzg.
In addition to the direct code contributors who make this repository possible, this project has been made possible by many conversations with Srinath Setty, Lev Soukhanov, Matej Penciak, Adrian Hamelink, François Garillot, Daniel Marin, Han Jian, Wyatt Benno, Nikkolas Gailly and Nalin Bhardwaj, to whom we are grateful.

