PoC: rln-v2 in waku

[rymnc]

Problem

We do not have arbitrary messaging rates with rln in waku, leading to only 1 message per epoch (set to 1 second)

Suggested solution

We make use of rln-v2 instead of rln-v1, which brings variable messaging rates depending on the user's stake.

Till we have a viable tokenomics model for rln-v2, we will just proceed with linearly scaling the stake with the messaging rate.

Sub-issues for incremental changes

• chore(rln-relay): remove websocket from OnchainGroupManager
  • chore(rln-relay): remove websocket from OnchainGroupManager #2364
• rln-v2: Update waku-rln-contract bindings #2375
  • chore(rln-relay-v2): use rln-v2 contract code #2381
• rln-v2: Update zerokit submodule #2376
• rln-v2: Update C FFI api's #2377
  • feat(rln-relay-v2): update C FFI api's and serde #2385
• rln-v2: Update serde for proof generation and commitment insertion #2378
  • feat(rln-relay-v2): update C FFI api's and serde #2385
  • the rate commitment now has to be calculated within nwaku: poseidon([id_commitment, user_message_limit])
• rln-v2: Update command line arguments to rln-keystore-generator, which now accepts a message rate that the user registers themself with
  • feat(rln-relay-v2): rln-keystore-generator updates #2392
• rln-v2: Node must use a monotonically increasing nonce for each proof generation #2415
  • feat(rln-relay-v2): nonce/messageId manager #2413
  • Additionally, the node must clear this nonce every epoch
• rln-v2: refactor the message validation functions #2379
• Appropriate nullifierLog struct: fix(rln-relay): make nullifier log abide by epoch ordering #2508
• rln-v2: additional testing #2481

Additional context

Zerokit release: https://github.com/vacp2p/zerokit/releases/tag/v0.4.1

Acceptance criteria

• A user is able to register themself to the rln-v2 membership set and send multiple messages per epoch

[rymnc]

cc: @jm-clius @fryorcraken @alrevuelta @kaiserd

[fryorcraken]

We make use of rln-v2 instead of rln-v1, which brings variable messaging rates depending on the user's stake.

Till we have a viable tokenomics model for rln-v2, we will just proceed with linearly scaling the stake with the messaging rate.

Can you clarify what exact number we could look into?e,g, you lock 1DAI and you get 1000msgs/day, 2DAY you get 2000msgs/day? This is cool.

[rymnc]

yes, something along those lines. however, a day is too large of an epoch size to use - consider the calculations below

users = 10_000
nullifier_size = 128 bytes (with metadata)
epoch size = 1 day
avg_user_message_limit = 1_000


total storage used = 10_000 * 128 * 1_000 = 1.2 gigabytes (in memory)

if the day epoch size is a requirement from waku, we can work on a persistence layer for the nullifier table, but we will raise the hardware requirements for running a node on the network by consequence.