feat: js-rln optimizations

[weboko]

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: waku-org/research#45

[rymnc]

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]

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:

• reducing size of files;
• removing auxiliary serialization: e.g if zkey and vkey can be included into wasm to speed things up;

[weboko]

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.