fix: refact rln-relay and post sync test#3434
Conversation
|
You can find the image built from this PR at Built from c1dc003 |
c5860b8 to
cc3cb7e
Compare
|
Thanks so much for it @darshankabariya ! |
79657d1 to
57a17af
Compare
57a17af to
f300fe6
Compare
off-chain tree
8453259 to
5f7bcc3
Compare
691f1b9 to
426b327
Compare
|
Hi @Ivansete-status, @jm-clius, @stubbsta — |
jm-clius
left a comment
There was a problem hiding this comment.
Thanks! I've just eyeballed the changes for now - I think this is a good step towards simplification. So far one-ish question below.
There was a problem hiding this comment.
I might just be missing it, but why do we need an OffchainGroupManager at all? We now have the base interface, which we can implement again when we re-add a real offchain implementation?
There was a problem hiding this comment.
Yes, you got it right. Actually, I couldn’t find any use for the StaticGroupManager class, so I deprecated it along with its unit tests. As you noticed, I introduced the OffchainGroupManager interface—this idea came from your suggestion that we might support both offchain and onchain features in the future. I’ve left it unimplemented for now.
| @@ -0,0 +1,3 @@ | |||
| import off_chain/group_manager | |||
There was a problem hiding this comment.
Why have a barrel import for off_chain, but not for on_chain?
(Barrel imports are somewhat controversial, but for now that's beside the point :D )
There was a problem hiding this comment.
There’s another file in the same directory, waku/waku_rln_relay/group_manager/on_chain.nim, similar to the offchain one. It looks a bit oversimplified — I’ll take a closer look.
786bc6f to
49d66d5
Compare
Ivansete-status
left a comment
There was a problem hiding this comment.
Thanks for it! 🙌
Some comments.
For every snippet code that you remove, kindly add a clear explanation as to why we can remove it, for future reference.
Thanks!
|
|
||
| suite "Lightpush attaching RLN proofs": | ||
| asyncTest "Message is published when RLN enabled": | ||
| xasyncTest "Message is published when RLN enabled": |
There was a problem hiding this comment.
Why that is commented if may I ask?
There was a problem hiding this comment.
Unable testcase !!
|
|
||
| suite "proofGen": | ||
| test "Valid zk proof": | ||
| xasyncTest "Valid zk proof": |
There was a problem hiding this comment.
Same for that one. Why skipped?
| credentials.add(generateCredentials(rlnInstance)) | ||
| return credentials | ||
|
|
||
| suite "Offchain group manager": |
There was a problem hiding this comment.
Is this test suite running any test ?
It seems this whole module can be removed.
There was a problem hiding this comment.
Yes, I agree — we no longer need the off-chain testcase since there’s nothing left to test. but also there no harm at all, that why not delete.
| return err("proof verification failed: " & $proofVerifyRes.error()) | ||
| return ok(proofVerifyRes.value()) | ||
| ## Dummy implementation for verifyProof | ||
| return ok(true) |
There was a problem hiding this comment.
Why not the following?
| return ok(true) | |
| return err("veryfyProof is not implemented") |
There was a problem hiding this comment.
good idea !!
| template initializedGuard*(g: OffchainGroupManager): untyped = | ||
| discard |
There was a problem hiding this comment.
Why is everything discarded?
There was a problem hiding this comment.
Thanks for pointing out, I’ve updated all functions to return an unimplemented error.
1fbc1a4 to
d75552f
Compare
off-chain tree rln-relay and post sync test
rln-relay and post sync testrln-relay and post sync test
Ivansete-status
left a comment
There was a problem hiding this comment.
Some more comments, thanks ! 🙌
| raise | ||
| newException(CatchableError, "Failed to deploy test token contract: " & $error) |
There was a problem hiding this comment.
Is it strictly needed the change? I would avoid explicitly raising exceptions, if possible
There was a problem hiding this comment.
I updated it with the idea of unification. I noticed we mostly use exceptions in our code, so I replaced asserts with exceptions. But now i realize that is for is for binary not test. so assertion is better idea right ??
| let contractAddress = (await executeForgeContractDeployScripts(privateKey, acc, web3)).valueOr: | ||
| assert false, "Failed to deploy RLN contract: " & $error | ||
| return | ||
| raise newException(CatchableError, "Failed to deploy RLN contract: " & $error) |
|
|
||
| anvilProc = runAnvil() | ||
| tempManager = | ||
| cast[ptr OnchainGroupManager](allocShared0(sizeof(OnchainGroupManager))) |
There was a problem hiding this comment.
Why the manual allocation is needed?
There was a problem hiding this comment.
Actually, I need this onchainGroupManager to fetch real-time RLN metadata such as contractAddress and useMessageLimit. If we hardcode these values, then every time the default RLN metadata changes, we’ll also need to update the tests. but yes definatly it's finest way to fetch we also usg RlnConf default value but i feel over code.
| let proof = rlnPeer.groupManager.generateProof(input, epoch, 0).valueOr: | ||
| # Fetch Merkle proof either when a new root was detected *or* when the cache is empty. | ||
| if rootUpdated or manager.merkleProofCache.len == 0: | ||
| let proofResult = waitFor manager.fetchMerkleProofElements() |
There was a problem hiding this comment.
Even though this is for testing purposes only, the waitFor should be used with care and only in the top logic layers. Better await
| ): WakuRlnConfig = | ||
| let wakuRlnConfig = WakuRlnConfig( |
There was a problem hiding this comment.
| ): WakuRlnConfig = | |
| let wakuRlnConfig = WakuRlnConfig( | |
| ): WakuRlnConfig = | |
| ## For testing purposes only | |
| let wakuRlnConfig = WakuRlnConfig( |
There was a problem hiding this comment.
It’s already in the test file, so why do we need to mention it explicitly ?
|
|
||
| suite "RLN Relay v2: serde": | ||
| test "toLeaf: converts a rateCommitment to a valid leaf": | ||
| xasyncTest "toLeaf: converts a rateCommitment to a valid leaf": |
There was a problem hiding this comment.
| xasyncTest "toLeaf: converts a rateCommitment to a valid leaf": | |
| asyncTest "toLeaf: converts a rateCommitment to a valid leaf": |
There was a problem hiding this comment.
same !! as below
| check expectedLeaf == leafRes.value.inHex() | ||
|
|
||
| test "proofGen: generates a valid zk proof": | ||
| xasyncTest "proofGen: generates a valid zk proof": |
There was a problem hiding this comment.
| xasyncTest "proofGen: generates a valid zk proof": | |
| asyncTest "proofGen: generates a valid zk proof": |
There was a problem hiding this comment.
[tests/waku_rln_relay/test_rln_serde.nim] is no longer needed. It was testing proof generation in isolation, but after moving to the on-chain tree, proof generation requires running a node and registering membership. Since it’s no longer possible to generate proofs fully off-chain, this test case is obsolete. deleting whole file.
| if rootUpdated: | ||
| if g.membershipIndex.isNone(): | ||
| error "membershipIndex is not set; skipping proof update" | ||
| debug "membershipIndex is not set; skipping proof update" |
There was a problem hiding this comment.
Should not this be considered as an error?
There was a problem hiding this comment.
It’s no longer required because earlier registering RLN membership was mandatory, but now users can run the code without membership. so removed it. thanks for pointing out, it;s help me think new direction.
waku/waku_rln_relay/rln_relay.nim
Outdated
| proc getCurrentEpoch*(rlnPeer: WakuRLNRelay, t: float64 = -1.0): Epoch = | ||
| ## Returns the RLN epoch corresponding to `t` (Unix seconds). | ||
| ## If `t` is not supplied (or set to a negative value), the current time is used. | ||
| let timeToUse = | ||
| if t < 0.0: | ||
| epochTime() | ||
| else: | ||
| t | ||
| return rlnPeer.calcEpoch(timeToUse) |
There was a problem hiding this comment.
This can be simplified, considering that t is never being passed:
| proc getCurrentEpoch*(rlnPeer: WakuRLNRelay, t: float64 = -1.0): Epoch = | |
| ## Returns the RLN epoch corresponding to `t` (Unix seconds). | |
| ## If `t` is not supplied (or set to a negative value), the current time is used. | |
| let timeToUse = | |
| if t < 0.0: | |
| epochTime() | |
| else: | |
| t | |
| return rlnPeer.calcEpoch(timeToUse) | |
| proc getCurrentEpoch*(rlnPeer: WakuRLNRelay): Epoch = | |
| ## Returns the RLN epoch corresponding to current epochTimeme is used. | |
| return rlnPeer.calcEpoch(epochTime()) |
There was a problem hiding this comment.
Thanks for pointing that out. I had made the change for a specific test, but later realized that passing just one test isn’t a good reason to change the structure of this function. I forgot to revert it. finally remove that
9b30f0a to
9eae858
Compare
59c3591 to
610492c
Compare
Hi @Ivansete-status , thank you for the approval. I’ve addressed all your suggestions and updated the changes accordingly. All CI checks are green now and tests have been updated as well. If you see this before merging the PR, kindly have a look. |
jm-clius
left a comment
There was a problem hiding this comment.
Thanks! I'm ready to approve once I understand why the OffchainGroupManager exists at all. :) Will be happy to have a call if I'm missing some context or my comments are unclear.
| # Placeholder for future OffchainGroupManager re-implementation | ||
| type OffchainGroupManager* = ref object of GroupManager |
There was a problem hiding this comment.
Again, I don't understand why we have this non-implementation as placeholder. There is no real implementation and this is only referenced in tests (and in rln_relay.nim, where it probably shouldn't be included anymore, see my comment there). In other words, wherever you still use OffchainGroupManager in the tests it could just be GroupManager and we delete the files and folders for off_chain for now. Am I missing some important context?
There was a problem hiding this comment.
thanks for review. main objective for offchainGM is to serve as a future perspective, so that when we revisit the offchain tree, we can leverage the currently unimplemented offchainGM functionality. But I understand your point — we can remove offchainGM for now as well, should i remove or not ??
waku/waku_rln_relay/rln_relay.nim
Outdated
| @@ -447,11 +413,11 @@ proc mount( | |||
|
|
|||
| if not conf.dynamic: | |||
There was a problem hiding this comment.
We don't support non-dynamic group managers anymore, from what I can see. There's no "OffchainGroupManager" - just a stub with that name that will raise exceptions for every function call. In other words, we can remove this completely and mark the config item as deprecated.
There was a problem hiding this comment.
Yes!! we also need to remove that along with offchainGM.
jm-clius
left a comment
There was a problem hiding this comment.
Thanks! Two comments below, but no need to re-request review once addressed.
| let rlnInstance = createRLNInstance(tree_path = conf.treePath).valueOr: | ||
| return err("could not create RLN instance: " & $error) | ||
|
|
||
| if not conf.dynamic: |
There was a problem hiding this comment.
I think this config item must be marked in the external config as deprecated (and then removed within two releases). Presumably it will not break any existing deployments and the default is true in any case?
There was a problem hiding this comment.
it’s a really good idea. I found that the default value true for dynamic is set only inside NetworkMonitor. we will handle in seperate PR.
apps/benchmarks/benchmarks.nim
Outdated
| let credentials = toSeq(0 .. 1000).mapIt(membershipKeyGen(rlnIns).get()) | ||
|
|
||
| let manager = StaticGroupManager( | ||
| let manager = OffchainGroupManager( |
There was a problem hiding this comment.
I think this reference does not exist anymore. Perhaps instantiate the base GroupManager?
There was a problem hiding this comment.
Will update the benchmark accordingly.
Description
This refactor was necessary because we’ve already transitioned to a non-synchronous approach, and all sync-related code is being deprecated.
Over time, GroupManager became bloated with tightly coupled and complex logic. This PR initiates a refactor to improve the clarity, maintainability, and future extensibility of the RLN relay protocol.
Changes
Issue