waku-org / js-rln

Browser library providing the cryptographic functions for Waku RLN Relay https://rfc.vac.dev/spec/17/
Apache License 2.0
5 stars 1 forks source link

feat: js-rln optimizations #85

Open weboko opened 11 months ago

weboko commented 11 months ago
This is a **feature request** ## Problem `@waku/rln` is slow. This investigation is done without measuring contract implications as for now it is lower than RLN problems It takes *~20s* to initialize RLN on _fast internet_ and *~40s* on _3g internet_ Following breakdown will be done on _3g internet_ Breakdown: 1. init `rln_wasm_bg.wasm`: **~6931.32 ms** 2. `zeroRLN` hook: 0.034 ms 3. init `rln.wasm`(witness calculator): **~3676.94 ms** 4. init `rln_final.zkey`: **~18692.76 ms** 5. init `zerokitRLN.newRLN`: **12444.46 ms** What is interesting is that (3) and (4) take *significantly* less time on fast internet. (3) and (4) happens on slow internet and most likely because of the size - (3) is 1.2 mb and (4) is 3.2 mb Further breakdown for (1): - fetching of the file is more or less the same regarding internet: 730 ms - `WebAssembly.instantiateStreaming` of the `rln_wasm_bg.wasm` takes: **6496.60 ms** Further breakdown for (3): - fetching `wasm` file: 572.31 ms - reading the file: **3102.37 ms** - it seems easy to mitigate Further breakdown for (4): - fetching is more or less the same: 575.53 ms - reading the file: **18112.36 ms** - it seems easy to mitigate Further breakdown for (5): - nothing to breakdown as it is proxy around `zerokit` operation - **12444.46 ms** - this takes the same time on any internet and is the most critical time consumer in our case ## Proposed Solutions - [ ] (1) can be mitigated by optimizingthe artifact (zerokit side); - [ ] (3) and (4) - try to use `instantiateStreaming` instead of reading bytes + check if possible to shrink files; - [ ] (5) should check if operation can be optimized or parameters(`zkey/vkey`) should be changed, in future should be improved with new version; ## Notes Ref: https://github.com/waku-org/research/issues/45
rymnc commented 11 months ago

based on our discussion, we have 3 approaches that may be of use -

  1. include the zkey, vkey and rln.wasm within the rln-wasm blob, to see if it saves time with the amount of serdes
  2. split the wasm blob into multiple, independent smaller blobs
  3. check compiler flags for rust => wasm
weboko commented 11 months ago

After investigating (3) and (4) I see that main time consumer is the same as for (1) and partially (4). It is serializing wasm into bytes and passing into zerokit - should be improved by:

weboko commented 11 months ago

Another metric - fetching the tree - is pretty much static and on slow 3g it takes 10-12s to fetch as of now. With faster internet is it 10s.