feat: wasm #38

richard-ramos · 2022-08-30T20:24:24Z

How to compile zerokit for wasm and see example code:

Make sure you have nodejs installed and the build-essential package if using ubuntu.
Install wasm-pack

curl https://rustwasm.github.io/wasm-pack/installer/init.sh -sSf | sh

Compile zerokit for wasm32-unknown-unknown:

cd rln
wasm-pack build --release

Launch example app

cd www
npm install
npm start

Browse http://localhost:8080 and open the developer tools to see console logs

s1fr0 · 2022-08-31T07:45:13Z

Maybe it can be of help here to have a look to how we computed the circuit builder before switching to the current witness generator logic from semaphore-rs:

zerokit/rln/src/circuit.rs

Lines 66 to 74 in 9ca9c22

    
           pub fn CIRCOM(resources_folder: &str) -> Option<CircomBuilder<Bn254>> { 
        
               let wasm_path = format!("{resources_folder}{WASM_FILENAME}"); 
        
               let r1cs_path = format!("{resources_folder}{R1CS_FILENAME}"); 
        
               // Load the WASM and R1CS for witness and proof generation 
        
               let cfg = CircomConfig::<Bn254>::new(&wasm_path, &r1cs_path).unwrap(); 
        
               // We build and return the circuit 
        
               Some(CircomBuilder::new(cfg))

We had performance issues at that time, but those were mainly due to not compiling in release mode. So I expect that even that was a valid and efficient solution, although we never actually tested it. If this helps sorting out the wasm problem and there we measure no big regression in circuit performances, we can move back to that implementation.

rln/Cargo.toml

richard-ramos · 2022-09-02T19:20:38Z

rln/Cargo.toml

 ark-relations = { version = "0.3.0", default-features = false, features = [ "std" ] }
 ark-serialize = { version = "0.3.0", default-features = false }
-ark-circom = { git = "https://github.com/gakonst/ark-circom", features = ["circom-2"] }
-wasmer = { version = "2.0" }
+ark-circom = { git = "https://github.com/vacp2p/ark-circom", branch = "wasm", features = ["circom-2"] }


This is a fork I created so (most of) this dependency can be run in wasm

rln/Cargo.toml

richard-ramos · 2022-09-02T19:24:19Z

rln/www/index.js

+
+rln.init_panic_hook();
+
+function _base64ToArrayBuffer(base64) {


This helper function is for converting the circom, zkey and vk files from base64 to an Uint8Array

rln/src/ffi.rs

rln/src/public.rs

richard-ramos · 2022-09-02T19:36:23Z

rln/src/protocol.rs

+fn calculate_witness_element<E: ark_ec::PairingEngine>(
+    witness: Vec<BigInt>,
+    sanity_check: bool,
+) -> Result<Vec<E::Fr>> {
+    use ark_ff::{FpParameters, PrimeField};
+    let modulus = <<E::Fr as PrimeField>::Params as FpParameters>::MODULUS;
+
+    // convert it to field elements
+    use num_traits::Signed;
+    let witness = witness
+        .into_iter()
+        .map(|w| {
+            let w = if w.sign() == num_bigint::Sign::Minus {
+                // Need to negate the witness element if negative
+                modulus.into() - w.abs().to_biguint().unwrap()
+            } else {
+                w.to_biguint().unwrap()
+            };
+            E::Fr::from(w)
+        })
+        .collect::<Vec<_>>();
+
+    Ok(witness)
+}


This function was extracted from ark-circom, It's main difference is that it will receive the witness instead of calculating it inside the function.

rln/src/protocol.rs

richard-ramos · 2022-09-02T20:04:31Z

@s1fr0 , @staheri14
I wasn't able to make zerokit load the wasm file (I believe it's due to reasons explained in this issue: arkworks-rs/circom-compat#4), so I ended up doing the calculation on the JS side, hence why I have two functions for generating the proof instead of one (to obtain the json input to pass to the witness calculator, and another function that receives the calculated witness).

I'm currently having trouble with create_proof_with_reduction_and_matrices because it tries to use threads even after disabling the parallel feature. (I'm not sure what's going on here). The error I'm receiving is

panicked at 'The global thread pool has not been initialized.: ThreadPoolBuildError { kind: IOError(Error { kind: Unsupported, message: "operation not supported on this platform" }) }

I'll try cloning arkworks-rs/groth16 and adding some logs to that function to try to find out what's going on.

richard-ramos · 2022-09-02T20:06:21Z

rln/www/index.js

+        const msgLen = Buffer.allocUnsafe(8);
+        msgLen.writeUIntLE(uint8Msg.length, 0, 8);
+
+        // Converting index to LE bytes
+        const memIndexBytes = Buffer.allocUnsafe(8)
+        memIndexBytes.writeUIntLE(memIndex, 0, 8);


@fryorcraken I had to use a buffer here because i need the function writeUintLE

richard-ramos · 2022-09-02T20:12:29Z

rln/www/index.js

+const verifKeyUint8Array = _base64ToArrayBuffer(files.verification_key);
+const zkeyUint8Array = _base64ToArrayBuffer(files.zkey);
+const circomUint8Array = _base64ToArrayBuffer(files.rln_wasm);


Should a dev be able to specify the depth and the zkey and verification key to use? or should these be embedded in the code?

richard-ramos · 2022-09-04T03:15:47Z

Good news! I managed to generate proofs now! I had to make a change in vacp2p/ark-circom@dcde9ba so the parallels feature can be disabled, and this allows generating the proof in the browser without running into the error:

panicked at 'The global thread pool has not been initialized.: ThreadPoolBuildError { kind: IOError(Error { kind: Unsupported, message: "operation not supported on this platform" }) }

However, the proof generation is very slow. It takes ~9s. Perhaps there's a way to enable threads on wasm?
For now, I'm happy that I was able to move past this blocker, so I can continue with verifying the proof, extracting the JS code to a separate repository and reverting a lot of the changes I made that are unrelated to the task of running zerokit on the browser.

richard-ramos · 2022-09-04T03:32:18Z

I just noticed that if I don't open the devtools console immediatly, the proof generations is faster, i.e:

proof_gen_timer: 2492.31396484375 ms

~2.5s

🤔

s1fr0 · 2022-09-04T08:11:17Z

@richard-ramos this is great! So as we suspected, it was rayon enabled on dependencies that was creating the issue. Maybe this could be of help in the future for enabling multithreading: https://github.com/GoogleChromeLabs/wasm-bindgen-rayon

Regarding performance: does the delay happen only for the first proof generated or it takes 2.5s for all of them? When we struggled with the performance issue, those were affecting mainly the circom builder/witness calculator initialization (i.e., read the circuit wasm and load it) while proof generation and verification remained relatively fast. In other words we had a big delay ~60s (but in debug mode) for generating the first proof (since the witness generator had to be load first), while successive proofs using the same RLN object were generated fast (since the witness generator was ready). If that's the case we might able to manage it by init the witness generator while intializing the node.

Can you replicate execution of test_groth16_proofs_performance_ffi ?

richard-ramos · 2022-09-06T00:05:37Z

I think the code is now ready for a review. Please do not focus on the javascript code, as it is done only to see interop between js and rust: it is going to be removed from the repository, and is kept there so PR reviewers can see/test the wasm output.
Check previous comments regarding some changes done in rln/

richard-ramos · 2022-09-12T15:33:54Z

I will close the PR as I learned today that compiling zerokit to wasm is not needed.
It was a nice learning exercise tho :-/

oskarth · 2022-09-13T01:28:26Z

@richard-ramos First of all, amazing work on getting WASM support working!

I think there was some miscommunication here. The first/easiest thing to do here was to use existing JS RLN libraries, like zk-kit and other things from PSE. This seems like a riskier and harder path, but if it works that's great. Sanaz and Franck have some more context from PM call(s) about this too.

Regardless of if this is this the main path we choose or not we should definitely try to get it merged, so re-opening this. Will have a look at the PR a bit later.

oskarth

Trying this out, having some problems getting it to run.

    Compile zerokit for wasm32-unknown-unknown:

cd rln
wasm-pack build --release

I assume this should be rln-wasm? When I run in rln I get:

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

But when I run in rln-wasm the wasm-pack command succeeds.

npm install also works. However, when I run npm start I get:

ERROR in ../pkg/rln_wasm_bg.wasm
Import "__wbg_BigInt_1fab4952b6c4a499" from "./rln_wasm_bg.js" with Non-JS-compatible Func Sigurature (i64 as parameter) can only be used for direct wasm to wasm dependencies
 @ ../pkg/rln_wasm.js
 @ ./index.js
 @ ./bootstrap.js

ERROR in ../pkg/rln_wasm_bg.wasm
Import "__wbg_BigInt_d0c7d465bfa30d3b" from "./rln_wasm_bg.js" with Non-JS-compatible Func Sigurature (i64 as parameter) can only be used for direct wasm to wasm dependencies
 @ ../pkg/rln_wasm.js
 @ ./index.js
 @ ./bootstrap.js
ℹ ｢wdm｣: Failed to compile.

Any idea what could be wrong?

Env:

# Running on MBP M1
node --version: v18.9.0
wasm-pack --version: wasm-pack 0.10.3
rustc --version: rustc 1.63.0 (4b91a6ea7 2022-08-08)
npm --version: 8.19.1

oskarth · 2022-09-14T03:18:23Z

Few general comments:

Can we target master on this instead of release branch? And resolve conflicts
Can we add a simple README in crate with instructions like you wrote in OP, and then a brief sentence in RLN crate about WASM support existing in separate crate?

oskarth · 2022-09-14T03:19:26Z

rln-wasm/src/lib.rs

+    }
+
+    false
+}


Can we add some tests to this module? Super basic one

oskarth · 2022-09-14T03:19:55Z

rln-wasm/www/README.md

@@ -0,0 +1,20 @@
+# RLN WASM EXAMPLE APP


Oh I see there's a README here already! I missed it because I expected it to be in the rln-wasm dir

This example app will also be removed, and will exist in https://github.com/waku-org/js-rln/ :)

oskarth · 2022-09-14T03:21:28Z

rln/Cargo.toml

 ark-relations = { version = "0.3.0", default-features = false, features = [ "std" ] }
 ark-serialize = { version = "0.3.0", default-features = false }
-ark-circom = { git = "https://github.com/gakonst/ark-circom", features = ["circom-2"] }
-wasmer = { version = "2.0" }
+ark-circom = { git = "https://github.com/vacp2p/ark-circom", branch = "wasm", default-features = false, features = ["circom-2"] }


Can we upstream this as a PR to ark-circom too? Are all things in arkworks-rs/circom-compat#4 supported?

I think even if just partial support for our case it'd be a welcome PR!

Ah, I see in vacp2p/ark-circom@0e58714 that it requires disabling parallels. I wonder if it is possible to get the feature flag to be disabled when wasm flag is enabled? Perhaps in a conditional package list or something, WDYT?

Also any idea why parallels doesn't work?

Can we upstream this as a PR to ark-circom too?

I will create a PR for ark-circom, that way we don't have to maintain a separate fork!

any idea why parallels doesn't work?

While running with that feature enabled, the following error was generated:

The global thread pool has not been initialized.: ThreadPoolBuildError { kind: IOError(Error { kind: Unsupported, message: "operation not supported on this platform"

I was looking at https://github.com/GoogleChromeLabs/wasm-bindgen-rayon , which should enable concurrency using js web workers, but I feel like the effort of adding multithreading to zerokit-wasm should be done in a separate PR.

richard-ramos · 2022-09-18T19:11:24Z

Trying this out, having some problems getting it to run.

    Compile zerokit for wasm32-unknown-unknown:

cd rln
wasm-pack build --release

I assume this should be rln-wasm? When I run in rln I get:

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

But when I run in rln-wasm the wasm-pack command succeeds.

npm install also works. However, when I run npm start I get:

ERROR in ../pkg/rln_wasm_bg.wasm
Import "__wbg_BigInt_1fab4952b6c4a499" from "./rln_wasm_bg.js" with Non-JS-compatible Func Sigurature (i64 as parameter) can only be used for direct wasm to wasm dependencies
 @ ../pkg/rln_wasm.js
 @ ./index.js
 @ ./bootstrap.js

ERROR in ../pkg/rln_wasm_bg.wasm
Import "__wbg_BigInt_d0c7d465bfa30d3b" from "./rln_wasm_bg.js" with Non-JS-compatible Func Sigurature (i64 as parameter) can only be used for direct wasm to wasm dependencies
 @ ../pkg/rln_wasm.js
 @ ./index.js
 @ ./bootstrap.js
ℹ ｢wdm｣: Failed to compile.

Any idea what could be wrong?

Env:

# Running on MBP M1
node --version: v18.9.0
wasm-pack --version: wasm-pack 0.10.3
rustc --version: rustc 1.63.0 (4b91a6ea7 2022-08-08)
npm --version: 8.19.1

Please try again with the latest commit. I updated some js dependency versions, so it's necessary to do a npm i in www to download them.

oskarth · 2022-09-19T04:28:19Z

Works now! I see the proof verification in the console :)

richard-ramos · 2022-09-19T20:45:15Z

I added a couple of tests, and removed the example app since it's supposed to live in js-rln anyways. The only task pending is creating PRs for ark-circom

oskarth

LGTM! Feel free to merge, can do ark-circom upstream update in separate PR

oskarth · 2022-09-20T03:18:11Z

rln-wasm/README.md

+```
+cd rln-wasm
+wasm-pack build --release
+```


Maybe add a pointer to how https://github.com/waku-org/js-rln/? Maybe this belongs more in that repo, but looking at README not obvious to me how to run something similar to the example app that existed here before

richard-ramos force-pushed the wasm branch from 30ac1f3 to d88bf6c Compare August 30, 2022 22:12

richard-ramos changed the base branch from master to release-v0.1 August 30, 2022 23:08

richard-ramos force-pushed the wasm branch from 0be00c1 to cde40ba Compare September 2, 2022 18:58

richard-ramos commented Sep 2, 2022

View reviewed changes

richard-ramos force-pushed the wasm branch 3 times, most recently from fcabd96 to ddf0f8c Compare September 4, 2022 03:09

richard-ramos force-pushed the wasm branch from a5c309d to 2bba56f Compare September 4, 2022 16:31

richard-ramos marked this pull request as ready for review September 5, 2022 23:55

richard-ramos force-pushed the wasm branch 2 times, most recently from e107eaa to 924ea58 Compare September 6, 2022 00:02

richard-ramos requested review from s1fr0 and oskarth September 6, 2022 00:05

richard-ramos closed this Sep 12, 2022

oskarth reopened this Sep 13, 2022

oskarth reviewed Sep 14, 2022

View reviewed changes

rln-wasm/src/lib.rs

}

false

}

Copy link

Contributor

oskarth Sep 14, 2022

Choose a reason for hiding this comment

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

Can we add some tests to this module? Super basic one

richard-ramos reacted with thumbs up emoji

oskarth reviewed Sep 14, 2022

View reviewed changes

oskarth mentioned this pull request Sep 14, 2022

WASM support #40

Closed

oskarth added the track:zerokit Zerokit track (Applied ZK/Explorations) label Sep 14, 2022

richard-ramos force-pushed the wasm branch from 9ea289d to 1d7a5f7 Compare September 18, 2022 19:02

richard-ramos force-pushed the wasm branch from 1d7a5f7 to 0fdd565 Compare September 19, 2022 14:33

richard-ramos changed the base branch from release-v0.1 to master September 19, 2022 14:33

feat(rln): wasm

d168286

richard-ramos force-pushed the wasm branch from 0fdd565 to d168286 Compare September 19, 2022 14:36

richard-ramos added 3 commits September 19, 2022 12:13

chore: add test

327bf25

test(rln): adding basic test

10d41ff

chore: removing example app and adding README.md

020bb4a

chore: run clippy per crate

1125e0c

oskarth approved these changes Sep 20, 2022

View reviewed changes

richard-ramos merged commit c401c0b into master Sep 20, 2022

richard-ramos deleted the wasm branch October 3, 2022 12:53

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: wasm #38

feat: wasm #38

richard-ramos commented Aug 30, 2022 •

edited

Loading

s1fr0 commented Aug 31, 2022

richard-ramos Sep 2, 2022

richard-ramos Sep 2, 2022

richard-ramos Sep 2, 2022

richard-ramos commented Sep 2, 2022

richard-ramos Sep 2, 2022

richard-ramos Sep 2, 2022

richard-ramos commented Sep 4, 2022

richard-ramos commented Sep 4, 2022

s1fr0 commented Sep 4, 2022 •

edited

Loading

richard-ramos commented Sep 6, 2022 •

edited

Loading

richard-ramos commented Sep 12, 2022

oskarth commented Sep 13, 2022

oskarth left a comment •

edited

Loading

oskarth commented Sep 14, 2022

oskarth Sep 14, 2022

oskarth Sep 14, 2022

richard-ramos Sep 15, 2022

oskarth Sep 14, 2022

oskarth Sep 14, 2022

richard-ramos Sep 15, 2022

richard-ramos Sep 15, 2022

richard-ramos commented Sep 18, 2022

oskarth commented Sep 19, 2022

richard-ramos commented Sep 19, 2022

oskarth left a comment

oskarth Sep 20, 2022


		rln.init_panic_hook();

		function _base64ToArrayBuffer(base64) {

+                  }
+                  false
+              }

feat: wasm #38

feat: wasm #38

Conversation

richard-ramos commented Aug 30, 2022 • edited Loading

s1fr0 commented Aug 31, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

richard-ramos commented Sep 2, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

richard-ramos commented Sep 4, 2022

richard-ramos commented Sep 4, 2022

s1fr0 commented Sep 4, 2022 • edited Loading

richard-ramos commented Sep 6, 2022 • edited Loading

richard-ramos commented Sep 12, 2022

oskarth commented Sep 13, 2022

oskarth left a comment • edited Loading

Choose a reason for hiding this comment

oskarth commented Sep 14, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

richard-ramos commented Sep 18, 2022

oskarth commented Sep 19, 2022

richard-ramos commented Sep 19, 2022

oskarth left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

richard-ramos commented Aug 30, 2022 •

edited

Loading

s1fr0 commented Sep 4, 2022 •

edited

Loading

richard-ramos commented Sep 6, 2022 •

edited

Loading

oskarth left a comment •

edited

Loading