Below, I am capturing all the outstanding tasks from my POV in different tracks. This issue is only for the sake of documentation and does not make sense to be followed with a PR. I tried to add some relevant GH issues in front of each task. However, there may be other relevant GH issues as well.
Projects/tasks that are/can be pursued in collaboration with the PSE group are annotated accordingly.
part of this task may require updating the constants in the Poseidon smart contract and re-deploying it, and testing it on a testnet (together with the RLN contract)
General improvement of user interface in chat2 and nwaku. There are various clean up and improvements GH issues in this regard.
Making RLN-Relay module structure compliant with the other Waku protocols (priority of this should be discussed in collaboration with the production team)
Security audit of
the RLN contract
the RLN circuit
the Waku-RLN-Relay codebase (not sure whether this one would be necessary or not)
Conducting the RLN circuit-dependent trusted setup
Providing zero entry for RLN-Relay message publisher (no crypto asset required): one solution relies on the lightpush protocol where a lightpush service provider makes a batch registration to the RLN membership group and utilizes its aggregated messaging rate to publish spam-protected messages on behalf of the light push requesters
Hybrid architecture for the membership Merkle tree storage management (super-peer/light-peer)
Better understanding of the risk of the zkSNARKs proofs malleability (perhaps will fall into the Waku message integrity area)
Evaluating and improving the security of the RLN-Relay: Identifying attack vectors like MEV and devising proper measures
Proper integration of pubsub topic and content topic in the rln identifier. Also, it would be good to think about a solution to derive rln secret shares based on the rln_identifier so that secret shares of two different app wont be combinable. The computation of rln_identifier should also be clarified in the RLN-Relay RFC.
Updating the rln-relay contract according to the current state of implementation e.g., atomic processing of the blocks to calculate valid and acceptable Merkle tree roots
Some rearchitecting in the current Waku-RLN-Relay module is desirable to be aligned with the positioning of the RLNP2P. The components outside of the core RLN functionality e.g., the group synchronization layer, should be extracted and converted into a separate module with a proper interface as a reusable lib. This can be initially done in nwaku codebase, then proper C APIs can be generated for those separate modules. It was discussed that the final implementation of RLNP2P can be in Rust rather than Nim (due to language features). Some relevant issues are: https://github.com/vacp2p/research/issues/110 another relevant issue https://github.com/vacp2p/research/issues/146
The problem of state synchronization among store nodes is described in https://github.com/vacp2p/research/issues/74.
Solutions can fall into the following categories depending on the nodes failure model:
Fail-stop fault-tolerant store protocol, provide state consistency across store nodes in the fail-stop failure model (intermittent availability of peers)
Byzantine fault-tolerant store protocol; provide state consistency across store nodes in the Byzantine failure model
Below, I am capturing all the outstanding tasks from my POV in different tracks. This issue is only for the sake of documentation and does not make sense to be followed with a PR. I tried to add some relevant GH issues in front of each task. However, there may be other relevant GH issues as well. Projects/tasks that are/can be pursued in collaboration with the PSE group are annotated accordingly.
RLN-Relay track
RLNP2P track
Incentive track
FT-store (w/ data sync) track
The problem of state synchronization among store nodes is described in https://github.com/vacp2p/research/issues/74. Solutions can fall into the following categories depending on the nodes failure model:
An initial solution idea utilizing MVDS is drafted in the following issue https://github.com/vacp2p/rfc/discussions/384 which is later moved to https://github.com/vacp2p/research/issues/73.
Applied ZK/Explorations tracks
Unknown track
cc: @oskarth