Rln-Relay features/refactoring targeted for release 0.13.0

[staheri14]

Problem

This is to keep track of the rln-relay features to be ready for integration in the next nwaku release 0.13.0.

Below is a non-exclusive list of features and refactoring tasks that would be good to be tackled for the next release.
The task assignments are tentative.

• Move from Infura to our in-house Goerli Ethereum node infra(rln): unstable Goerli Ethereum Client #1269 (@rymnc)

• Tree root validation + keeping track of the state of the tree

  • feat(rln-relay): Keep track of the last processed event for membership changes  #1265 (@rymnc)
    • feat(rln-relay): track last seen event #1296 (@rymnc)
  • feat(rln-relay): The window of acceptable roots should change per block, not per event  #1266
    • feat(rln): ability to set leaves from a given index vacp2p/zerokit#63 (@rymnc)
    • feat(rln-relay): process blocks atomically #1349 (@rymnc)

• RLN relay metric collection and visualization on the dashboard

  • feat(rln-relay): add metrics dashboard #1275 (@rymnc)

• Metrics on chat2

  • chore(chat2): enable metrics #1203 (@rymnc)

• Key store for rln credential management.
  If we could integrate keystore, then the following issues will be addressed as well:

  • feat: Check field size when loading rln credential file #1113 (@s1fr0)
  • Rln-Relay: Persisting rln credentials  #1021 (@s1fr0)
  • feat: add keyfile support for RLN credentials secure storage #1285 (@s1fr0)

• Enabling zerokit by default

  • Enable Zerokit by default #1061 (@s1fr0)
  • feat: Use zerokit by default/deploy on test fleet #1227 (@s1fr0)
  • addressing 1061 would naturally resolve bug: having a mixed fleet of zerokit/rln and kilic/rln can cause the rlnIdentifier attribute to be lost #1213 (@s1fr0)

• Better error handling by rln-relay modules

  • Abstraction of writing persistent RLN credentials to a modular proc #1053 (@rymnc)
  • chore(rln-relay): handle Exceptions and CatchableErrors #1189 (@rymnc)
    • chore(rln-relay): remove all raises and replace with Result types #1321 (@rymnc)

• chore(rln-relay): fix circular dependency #1222 (@LNSD)

• removing killic lib

  • chore: remove support to Kilic's RLN libary #1314 (@s1fr0)
  • refactor(rln): remove kilic lib #1365 (@s1fr0)

• Removing ganache from makefile, and moving it to the test suites

  • chore(rln): update ganache #1347 (@s1fr0)

There are a couple of other low-hanging fruits which we can attempt in case the above list is completed earlier than the deadline.

Acceptance criteria

Getting the listed features ready and tested by the indicated deadline below.
Making sure there is no regression regarding the added features on the waku v2 fleets.

Deadline

November 8th (one week prior to the next release date).
cc: @jm-clius, @oskarth

[staheri14]

Please add your suggested tasks as a comment to this issue. Once prioritized, then we can update the issue description. @rymnc @s1fr0

[s1fr0]

The issue to be investigated that we discussed internally: #1270

[staheri14]

@rymnc Any comments on this?

[staheri14]

The issue to be investigated that we discussed internally: #1270

Added to the issue.

[s1fr0]

Maybe also vacp2p/rfc#511 and the corresponding vacp2p/rfc#522 ? Unclear the current state of these.

[LNSD]

The following issue covers the credentials store implementation; in it, you can find my comment based on the work assessment I did: #1021

I guess that you want to add it to this issue's description.

[rymnc]

@rymnc Any comments on this?

Looks like a great roadmap!

[s1fr0]

Post updated with new issues/PR related to keystore integration for RLN credentials.

[jm-clius]

Thanks for great progress team! As far as I know this has been reviewed and everything we want to include in the revised list for 0.13.0 has been merged? Could we get this issue in a state where we can close it by release time (EOB Monday 14 Nov)? In other words, any open listed issues/tasks should move to a new tracking issue (if applicable). Closing this issue is necessary to close the release milestone.

[rymnc]

Thanks for great progress team! As far as I know this has been reviewed and everything we want to include in the revised list for 0.13.0 has been merged? Could we get this issue in a state where we can close it by release time (EOB Monday 14 Nov)? In other words, any open listed issues/tasks should move to a new tracking issue (if applicable). Closing this issue is necessary to close the release milestone.

#1376 tracking here now

[s1fr0]

No change in #1367 was merged to master (closed draft PR) and hence it is not relevant for release v0.13.0.

IMO it should not be part of this issue and should be moved instead to #1376

[staheri14]

Thanks @rymnc, for opening the tracking issue; the current one can be closed.

[staheri14]

No change in #1367 was merged to master (closed draft PR) and hence it is not relevant for release v0.13.0.

IMO it should not be part of this issue and should be moved instead to #1376

@s1fr0 I think it is not gonna show up as part of the release as it is not merged. What is in this issue is just the description of the efforts that were made toward creating a separate API for group synchronization. WDYT?

[s1fr0]

Sure! My previous message was just in light of #1268 (comment) and also with respect to the issue title: i.e. features/refactoring targeted for release 0.13 and description "features to be ready for integration in the next nwaku release 0.13.0.".

For that reason I think is better to just move that to the issue targeting v 0.14 since is still pending. But nothing critical of course.

[staheri14]

I see that @rymnc has moved the refactoring part to the new issue, so I just closed this one.