Onchain RLN + L2

[alrevuelta]

As discussed with @rymnc we will look into having the whole RLN tree onchain:

• Whole rln tree onchain makes it easier for light clients, no need to sync the tree. Related: RLN in resource-restricted clients #45
• Also easier for full nodes, since getting the tree is faster and less error prone.
• It becomes more expensive, because of the storage that its used. Migrating to a L2 would be a prerequisite for onchain rln trees.
• By now, the new contract will be compatible with the current code (eg nwaku). Meaning that the tree can be both synced (as it is right now) and fetched directly. This allows:
  • No changes needed in nwaku.
  • Allows js-waku to start using the onchain tree.

The idea is to do a PoC to asses if this is the way to go, and if it solves the problem stated in #45

[s-tikhomirov]

more expensive, because of the storage

Can EIP-4844 be relevant here? It introduces cheaper ephemeral on-chain storage with rollup data availability as the main use case.

[rymnc]

more expensive, because of the storage

Can EIP-4844 be relevant here? It introduces cheaper ephemeral on-chain storage with rollup data availability as the main use case.

I don't think we'll use blobs directly, just as a consequence of using an L2

[weboko]

As we discussed it back then it is important to expose API to get only needed part of the tree for proof generation, @rymnc

[rymnc]

After further investigation, here are a couple of points re:viability of having the whole tree on-chain -

1. Semaphore uses @zk-kit/incremental-merkle-tree under the hood, which processes insertions and obtains the new merkle tree root. We can then use a mapping from index => commitment, therefore, having the whole tree onchain. An optimization would be to store the intermediate node hashes in a mapping as well. A multicall can be executed to get all the inserted commitments.

2. If we do end up deploying to a zkevm, we deeply need to consider gas costs, since the block gas limit of the polygon zkevm is 4M gas. An insertion or removal with the tree onchain would be around 880k gas.

For clients that want to just verify and relay messages on TWN, having the root onchain makes it easy. They don't need to sync the tree, instead, just look at the contract and verify that a message has the right root. (+ for light clients)

For clients that want to generate proofs, we can add a view function to the contract which returns the pathIndices and pathSiblings for a given index. Therefore, the process to generate proofs in a light client would be -

1. make request to rpc for pathSiblings (pathIndices can be generated locally)
2. generate rln proof w/ output of 1, and other private inputs
3. broadcast

[rymnc]

cc: @alrevuelta closing the loop on the conversation we have had out of band, and in the vacp2p/rln-contract PR

I've deployed the contracts (with the whole tree onchain) to polygon-zkevm-testnet and sepolia

They have been verified.

[alrevuelta]

The idea is to do a PoC to asses if this is the way to go, and if it solves the problem stated in #45

PoC done here #72. Thanks @rymnc for the help.