Continuing #10 Circom2 groth16 proof generation is now working, implemented a few missing functions from the spec here. Testcase also succeeds now: cargo test --features circom-2 groth16_proof_circom2

Problem

I want to be able to use circuits written and compiled with the new Rust based Circom 2.0 compiler https://github.com/iden3/circom as opposed to the current JS based one https://github.com/iden3/circom_old

When I try to use wasm and r1cs files generated by Circom 2.0 as per example usage (https://github.com/gakonst/ark-circom#example) it fails to compile.

I might be missing something fundamental here, but based on the release date of Circom 2.0 and the last update of this library it doesn't seem like Circom 2.0 support currently exists.

Details

Note: I'm not really a Rust programmer, nor am I that familiar with WebAssembly or the Circom compiler, so these are just some rough notes based on me trying to solve the above problem.

It seems to me things have changed w.r.t. the WASM interface. The first error we see is about a missing function:

thread 'main' panicked at 'function getFrLen not found', /home/oskarth/.cargo/git/checkouts/ark-circom-e5b2a9b30398f2b3/729ea33/src/witness/circom.rs:80:33

We can see this being added here: https://github.com/gakonst/ark-circom/blob/master/src/witness/circom.rs#L19

Old Circom 1.0 JS compiler has it here: https://github.com/iden3/circom_old/blob/c311ae355239bae76a83b92070cb21d249e77465/ports/wasm/build_runtime.js#L926

However, this doesn't exist in the new Circom 2.0 compiler.

Here's where the new WASM interface seems to be defined: https://github.com/iden3/circom/blob/f673727a97f972dad27df7cc5e4c38e45b37966d/code_producers/src/wasm_elements/witness_calculator.js#L10

There might also be other differences.

Attempt

I started trying to make compiler errors go away by adding stubs etc in a naive fashion. This resolved a few compiler errors.

See here for WIP debug branch diff: https://github.com/gakonst/ark-circom/compare/master...oskarth:master

I added a Circom 2 feature flag to switch between the two. This can probably be done cleaner with separate WitnessCalculator implementations etc, but conceptually it should work for not breaking existing compatibility.

I'm testing it from https://github.com/oskarth/hello-ark-circom and can confirm it works fine with Circom 1.0 compiled wasm/r1cs files.

After the initial compiler errors, I ran into things like not finding the prime 21888242871839275222246405745257275088548364400416034343698204186575808495617 in the WASM memory (?). I hardcoded some values based on circom-1 output just to see where things would end up.

The last compiler error I got was "thread 'main' panicked at 'Error: This parser only supports 32-byte fields" which happens here: https://github.com/gakonst/ark-circom/compare/master...oskarth:master#diff-97b759aa5cd8e3f3769343c3b3b2ae638f500527f0bd6e026c1a929273c851ebR96

For some reason it is 1 and not 32. That's where I stopped debugging.

Going forward

It isn't obvious to me how hard it is to implement Circom 2.0 support for ark-circom here, or if this is something that is planned. If it is just a few tweaks to get it to work, I can keep working on it with some pointers. If it requires more work, well, here's a feature request :)

Acceptance criteria

Circuits compiled with Rust-based Circom 2.0 compiler are able to generate witness, prove and verify.

^ @gakonst @kobigurk

Hello,

i'm new with rust and circom but I'm doing my best to learn.

I'm trying to compile the tornado-cash circuit and use ark-circom to interact with it. here are the circuits: https://github.com/tornadocash/tornado-core/tree/master/circuits they're using v1, but after 2 minor modifications it's compile. you can see my circuits here

I created a small and reproducible project to show my errors: https://github.com/albttx/ark-circom-tc and an issue https://github.com/albttx/ark-circom-tc/issues/1

the function to_array32 panic

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value',
/home/albttx/.cargo/git/checkouts/ark-circom-1c15f1eba3004428/cac27e6/src/witness/witness_calculator.rs:47:43

see the line here

here is the function

fn to_array32(s: &BigInt, size: usize) -> Vec<i32> {
    let mut res = vec![0; size as usize];
    let mut rem = s.clone();
    let radix = BigInt::from(0x100000000u64);
    let mut c = size - 1;
    while !rem.is_zero() {
        res[c] = (&rem % &radix).to_i32().unwrap();   // <-- error here
        rem /= &radix;
        c -= 1;
    }

    res
}

Could you guys help ?

This PR ensures all tests pass, regardless of if circom-2 feature flag is enabled or not.

Since Circom v2 support is still experimental, the feature flag is still there. Once it has been proven to work, we can remove the flag completely. With this PR we can enable CI to test Circom 2 paths, see https://github.com/gakonst/ark-circom/issues/15

With Circom 2 flag enabled, the version is set to either (1) what getVersion returns, or (2) defaults 1, since getVersion isn't implemented in Circom 1 WASM interface.

Parent issue: https://github.com/gakonst/ark-circom/issues/8

To test

cargo test
cargo test --features circom-2

Note

I couldn't figure out how to do both compile time check for feature flag with cfg_if and normal runtime check of WASM version. Hence nested if statement and helper functions to avoid code duplication of the two actual code paths. https://github.com/gakonst/ark-circom/pull/18/files#diff-d0bf3370220b21ebe5cbae1064dbf8a93524e8b002f73bd30974c4f1ca28cea7R129

Update: closes https://github.com/gakonst/ark-circom/issues/15

WIP PR towards https://github.com/gakonst/ark-circom/issues/8

Minimal subset of WASM interface has been ported based on https://docs.google.com/document/d/1P0j9zXjJRkhnyPT03VjxYBUySC8l4k41ZQ5LY7uyQnw/edit and https://github.com/oskarth/hello-circom/blob/master/multiplier2_js/witness_calculator.js#L74

Can be tested with cargo test groth16_proof_circom2 --features circom-2. All current tests should pass as normal since the feature flag circom-2 is off by default.

Can either clean up and merge as partial progress with minimal WASM interface, or keep open until R1CS format stuff is sorted.

Current state

https://github.com/gakonst/ark-circom/pull/10/commits/19faa5c30a5fe5269c00b7a687d557834eb36d2c

WIP: Debug R1CSfile header field_size in header is 1, not 32 as expected

Don't see anything recently changed here: https://github.com/iden3/r1csfile/blob/master/src/r1csfile.js (used by snarkjs)

But this seems new: https://github.com/iden3/circom/blob/0149dc0643c3842635fb758efc9ebc102f170a38/constraint_writers/src/r1cs_writer.rs

I also see this: https://github.com/gakonst/ark-circom/blob/11e6d04f3b88a8adb12cc157024ac4b5f11dd74f/src/circom/r1cs_reader.rs#L59-L62 which may or may not be related (haven't investigated in detail and currently not familiar the R1CS file format).

This is replacing i32 by u32 in various places when interacting with the wasm. Quote from the wasmer docs:

In Wasm integers are sign-agnostic, i.e. this can either be signed or unsigned.

However, this can create overflows, for example right in to_array32 (I've introduced the bug in my other PR #14): 0x100000000 - 1 obviously doesn't fit in i32 and let's the unwrap() fail.

This is not visible in the current test cases, but happens as soon as you feed in large numbers as signals like hashes, we could also add a test case to catch this in the future.

This avoids Wasm execution hanging due to problems such as wrong public input.

Mimics circom_runtime behaviour with less detailed debug information.

See https://github.com/iden3/circom_runtime/blob/master/js/witness_calculator.js#L52-L64

Adds test for wrong public input. Without early exit, the test stalls. With it, the Circom build step fails as expected.

Wasmer added support in version 2.1 for loading a .dylib as engine instead of a .wasm. This is useful, if you want to cross-compile this library to iOS.

The PR bumps the wasmer version to latest (2.2.1) and tries to load a dylib based on file extension in from_file.

It ensures backwards compatibility by treating the file as wasm in any other case.

ark-circom was using an old version of ethers, this PR bumps it up

cc @recmo re: https://github.com/worldcoin/semaphore-rs/commit/124043470e6fb47e5323a3133a03da394464b6de#diff-b1a35a68f14e696205874893c07fd24fdb88882b47c23cc0e0c80a30c7d53759R3

TODO:

1. The Solc struct is no longer present, need to use ethers::solc
2. compile_and_launch is no longer present either since the removal of Solc from ethers-core
3. There's a bug in Abigen which we track separately https://github.com/gakonst/ethers-rs/issues/1055

@gakonst this is a wip. We'd like to get the verifier related utilities working in Substrate, currently it throws no_std related errors when including such logic in a Substrate runtime. Is there any insight you can provide here on how we may update this repo to make this possible?

Running with cargo build --release --no-default-features --target wasm32-unknown-unknown still throws with

error: the wasm32-unknown-unknown target is not supported by default, you may need to enable the "js" feature. For more information see: https://docs.rs/getrandom/#webassembly-support
   --> /Users/drew/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.2.7/src/lib.rs:235:9
    |
235 | /         compile_error!("the wasm32-unknown-unknown target is not supported by \
236 | |                         default, you may need to enable the \"js\" feature. \
237 | |                         For more information see: \
238 | |                         https://docs.rs/getrandom/#webassembly-support");
    | |________________________________________________________________________^

error[E0433]: failed to resolve: use of undeclared crate or module `imp`
   --> /Users/drew/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.2.7/src/lib.rs:262:5
    |
262 |     imp::getrandom_inner(dest)
    |     ^^^ use of undeclared crate or module `imp`

I managed to use ark-circom's circomBuilder to load circom-generated r1cs and wasm files when they were created with circom v2.0.0 - v2.0.6 (also the subsequent trusted setup, proof creation and proof verification worked). It seems that from circom v2.0.7, breaking changes were introduced (see https://github.com/iden3/circom_runtime/pull/38) that make the generated wasm file incompatible with ark-circom. I tested with circuits compiled with circom v2.0.8 - current version and got the following error every time:

thread 'main' panicked at 'called Result::unwrap() on an Err value: Error while importing "runtime"."printErrorMessage": unknown import. Expected Function(FunctionType { params: [], results: [] })

Location: /home/user/.cargo/git/checkouts/ark-circom-1c15f1eba3004428/06eb075/src/witness/witness_calculator.rs:87:34', /home/user/.cargo/git/checkouts/ark-circom-1c15f1eba3004428/06eb075/src/circom/builder.rs:28:49 stack backtrace: 0: 0x5564991efa9d - std::backtrace_rs::backtrace::libunwind::trace::h8217d0a8f3fd2f41 at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5 1: 0x5564991efa9d - std::backtrace_rs::backtrace::trace_unsynchronized::h308103876b3af410 at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5 2: 0x5564991efa9d - std::sys_common::backtrace::_print_fmt::hc208018c6153605e at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/sys_common/backtrace.rs:66:5 3: 0x5564991efa9d - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hf89a7ed694dfb585 at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/sys_common/backtrace.rs:45:22 4: 0x556499212d4c - core::fmt::write::h21038c1382fe4264 at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/fmt/mod.rs:1197:17 5: 0x5564991ed7c1 - std::io::Write::write_fmt::h7dbb1c9a3c254aef at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/io/mod.rs:1672:15 6: 0x5564991f1245 - std::sys_common::backtrace::_print::h4e8889719c9ddeb8 at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/sys_common/backtrace.rs:48:5 7: 0x5564991f1245 - std::sys_common::backtrace::print::h1506fe2cb3022667 at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/sys_common/backtrace.rs:35:9 8: 0x5564991f1245 - std::panicking::default_hook::{{closure}}::hd9d7ce2a8a782440 at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:295:22 9: 0x5564991f0f66 - std::panicking::default_hook::h5b16ec25444b1b5d at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:314:9 10: 0x5564991f17d6 - std::panicking::rust_panic_with_hook::hb0138cb6e6fea3e4 at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:698:17 11: 0x5564991f16c7 - std::panicking::begin_panic_handler::{{closure}}::h4cb67095557cd1aa at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:588:13 12: 0x5564991eff54 - std::sys_common::backtrace::__rust_end_short_backtrace::h2bfcac279dcdc911 at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/sys_common/backtrace.rs:138:18 13: 0x5564991f13f9 - rust_begin_unwind at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:584:5 14: 0x556498d7b303 - core::panicking::panic_fmt::h1de71520faaa17d3 at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/panicking.rs:142:14 15: 0x556498d7b3f3 - core::result::unwrap_failed::hc0baa33ef8bc7db8 at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/result.rs:1805:5 16: 0x556498d8a4a6 - ark_circom::circom::builder::CircomConfig::new::h3f61e57d14c619f8 17: 0x556498dececb - ark_circom_tests::main::h0e7770b10430361b 18: 0x556498da4cd3 - std::sys_common::backtrace::__rust_begin_short_backtrace::h72cde959798951cc 19: 0x556498dcdd99 - std::rt::lang_start::{{closure}}::hf28b541f898e72af 20: 0x5564991e92be - core::ops::function::impls::<impl core::ops::function::FnOnce for &F>::call_once::h4937aaa125c8d4b2 at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/ops/function.rs:280:13 21: 0x5564991e92be - std::panicking::try::do_call::h6f5c70e8b0a34f92 at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:492:40 22: 0x5564991e92be - std::panicking::try::h68766ba264ecf2e2 at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:456:19 23: 0x5564991e92be - std::panic::catch_unwind::hc36033d2f9cc04af at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panic.rs:137:14 24: 0x5564991e92be - std::rt::lang_start_internal::{{closure}}::h78c037f4a1a28ded at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/rt.rs:128:48 25: 0x5564991e92be - std::panicking::try::do_call::he6e1fffda4c750ee at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:492:40 26: 0x5564991e92be - std::panicking::try::h48a77ddbb2f4c87a at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:456:19 27: 0x5564991e92be - std::panic::catch_unwind::hfa809b06a550a9e7 at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panic.rs:137:14 28: 0x5564991e92be - std::rt::lang_start_internal::h4db69ed48eaca005 at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/rt.rs:128:20 29: 0x556498df1ea2 - main 30: 0x7f49bf715083 - __libc_start_main at /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 31: 0x556498d7b5fe - _start 32: 0x0 -

I have noticed that ark_bn254::G1Affine and ark_bn254::G2Affine are not equal themselves after a round trip of converting to and from respective crate::ethereum::G1 and crate::ethereum::G2 types.

Example:

let g1 = G1Affine::default();
let g1_eth = G1::from(&g1);
let g1_2 = G1Affine::from(g1_eth);
assert_eq!(g1, g1_2);

g1 is represented as:

GroupAffine { x: Fp256(BigInteger256([0, 0, 0, 0])), y: Fp256(BigInteger256([15230403791020821917, 754611498739239741, 7381016538464732716, 1011752739694698287])), infinity: true }

g2 is represented as: GroupAffine { x: Fp256(BigInteger256([0, 0, 0, 0])), y: Fp256(BigInteger256([15230403791020821917, 754611498739239741, 7381016538464732716, 1011752739694698287])), infinity: false }

Similar situation happens with G2Affine -> G2 -> G2Affine.

Hi, I'm trying to use RLN circuits and it doesn't work (runs forever). However, in release mode everything works fine.

It stucks on CircomConfig::new().

What can be the problem ?

The ProvingKey<Bn254>, ConstraintMatrices<Fr> are shared through constant reference. WitnessCalculator is cloned and passed as mutable reference.

snarkjs and websnark are pretty popular on zk-snark projects. I am curious how can I generate proof with websnark or snarkjs, then verify the proof with ark-circom