|
| 1 | +# Waku’s Requirements on Zerokit |
| 2 | + |
| 3 | +## Context |
| 4 | + |
| 5 | +Zerokit is the recommended library for cryptographic operations including Poseidon hashing, RLN identity generation, and proof verification. |
| 6 | +Waku relies on Zerokit, primarily for two implementaions: |
| 7 | +- js-waku (rln-wasm): credentials registrations, proof generation and verification (planned 2025H2) |
| 8 | +- nwaku: proof generation & verification (now), credentials (2025H2) |
| 9 | + |
| 10 | +Current JS integration faces two main challenges: |
| 11 | +- **WASM cold start/load latency:** The WASM blob load time improved from ~15 seconds (v0.1.0) to ~5 seconds (v0.2.0). |
| 12 | + - The split of the 5 seconds is as follows: |
| 13 | + - ~1.2 seconds for the WASM files download + decoding/compilation (~1MB) |
| 14 | + - ~3.6 seconds for the zkey download (~3MB) |
| 15 | +Notably, the current `rln-wasm` build includes proof generation and verification, which not all web apps built with Waku require. And even if one web app requires both credentials and proof verification/generation, it is likely done in different areas from a UX and functional PoV. This suggests a smaller, credential-only and proof-handling-only WASM libraries could further reduce load times for js-waku. |
| 16 | + |
| 17 | +- **Endianness mismatch:** js-waku uses big-endian (BE) throughout, as required by contracts, while Zerokit expects little-endian (LE). This necessitates conversion when interfacing between the two, though this is less critical than load latency. |
| 18 | + |
| 19 | +Additional minor challenges: |
| 20 | +- Lack of documentation regarding `InitOutput` and root exports. |
| 21 | +- Ambiguity around the sequence and role of initialization functions such as `init()`, `initPanicHook()`, etc. |
| 22 | + |
| 23 | +We aim to align expectations and optimize collaboration between the Waku and Vac ACZ teams by clearly expressing our functional and non-functional requirements. |
| 24 | + |
| 25 | +--- |
| 26 | + |
| 27 | +## Use Case 1: Credential Generation and Management |
| 28 | + |
| 29 | +**Used during:** |
| 30 | +- RLN registration |
| 31 | +- Identity derivation and key export |
| 32 | +- Interoperability between js-waku and nwaku |
| 33 | + |
| 34 | +### Functionality |
| 35 | + |
| 36 | +- **F1.1:** Generate deterministic identity commitment (`idCommitment`) from entropy/seed. |
| 37 | +- **F1.2:** Generate full identity object (`commitment`, `secret`, `nullifier`, `trapdoor`). |
| 38 | + |
| 39 | +### Usability |
| 40 | + |
| 41 | +- **U1.1:** API accepts and return Big-Endian (BE), so data can be passed to Web3 RPC API without manipulation. |
| 42 | +- **U1.2:** Documentation is provided to use APIs to generate and load credentials. |
| 43 | + |
| 44 | +### Reliability |
| 45 | + |
| 46 | +- **R1.1:** Inter-operability between Zerokit FFI (x86_64, ARM, binaries) and WASI (browser WASM) APIs. |
| 47 | +- **R2.2:** Zerokit must be fully interoperable the RLN EVM smart contract. |
| 48 | + |
| 49 | +### Performance |
| 50 | + |
| 51 | +- **P1.1:** Cold start under 5s for full WASM blob, including the zkey; ideally under 1s for reduced credential-only blob. |
| 52 | + |
| 53 | +### Supportability |
| 54 | + |
| 55 | +- **S1.1:** Available for: JavaScript/TypeScript (browsers) |
| 56 | +- **S1.2:** Available for Nim |
| 57 | + |
| 58 | + |
0 commit comments