feat: add custom queryFilter

[weboko]

Addressing the issue when RLNContract cannot fetch history if the range is too wide.
More details on the issue: waku-org/examples.waku.org#225 (comment)

[fryorcraken]

All the issue we are encountering are going to be dependent on the Wallet and RPC Provider.

MetaMask using infura is the one with an issue. But If a user used MetaMask with another provider, fetch chunk may need to be lower or higher.

Hence, a few things:

1. It should probably be configurable so webapp developer can fine tune the experience as it mays also depends on other calls they do to the blockchain
2. May be good to do further research and understand how other application do this (going through all logs of a contracts).
3. I believe we already discussed that with previous researcher, but maybe using event log as the only way to get information of existing membership is not a good smart contract design? I am not familiar with smart contract design patterns but a function call on the smart contract to get a list of memberships may be a more efficient approach, only using events to listen to new members. WDYT @rymnc ?

[rymnc]

re 3, we made the gas efficient choice to store all idCommitments in a mapping. While this makes the contract more gas efficient, it definitely increases complexity client side. If clients would prefer the tree being stored onchain, we can create a variant of the RLN contracts that do that. Let me know 🫡

[rymnc]

for reference, all eth2 implementations chunk and fetch event logs - https://github.com/status-im/nimbus-eth2/blob/55ae7d3b00fcb7029ced737eef8868690cbaa756/beacon_chain/eth1/eth1_monitor.nim#L642

[richard-ramos]

in go-waku, fetching logs in chunks was done like this: https://github.com/waku-org/go-waku/blob/master/waku/v2/protocol/rln/group_manager/dynamic/web3.go#L172-L236

[weboko]

re 3, we made the gas efficient choice to store all idCommitments in a mapping. While this makes the contract more gas efficient, it definitely increases complexity client side. If clients would prefer the tree being stored onchain, we can create a variant of the RLN contracts that do that. Let me know 🫡

since idCommitments are present on a contract that means there is no reason to query events, no?

[weboko]

It should probably be configurable so webapp developer can fine tune the experience as it mays also depends on other calls they do to the blockchain

Exposed configuration to outside

May be good to do further research and understand how other application do this (going through all logs of a contracts).

I did some research and I see when someone needs to query many blocks then there are two solutions - query in chunks (or have a gateway that allows huge query to run) or store data somewhere on a contract

are there any other solutions, @rymnc , @richard-ramos ?

[richard-ramos]

either that or use thegraph to query the events.

The problem with storing the data in the smart contract is that it will probably increase the cost of registering a new membership. Retrieving the query in chunks seem to be the usual workaround (here's an implementation i found in TS that we could use to retrieve the logs: https://github.com/MarkusSprunck/ethereum-event-scan/blob/master/src/app/services/reader.service.ts#L279-L358). I'm also thinking that to speedup loading the events next time the example is accessed, perhaps we should store them in localstorage or indexeddb, but that is something that could be implemented in future PRs