Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(rln-relay): invalid start index being set results in invalid proofs #1915

Merged
merged 3 commits into from
Aug 18, 2023

Conversation

rymnc
Copy link
Contributor

@rymnc rymnc commented Aug 17, 2023

Description

This pr introduces a couple small changes for logging and fixes the startIndex starting from 0 instead of 1 like the contract

Changes

  • logging improvements
  • fixed startIndex

@rymnc
Copy link
Contributor Author

rymnc commented Aug 17, 2023

cc: @alrevuelta @richard-ramos thanks for the report!

@github-actions
Copy link

You can find the image built from this PR at

quay.io/wakuorg/nwaku-pr:1915

@@ -89,7 +89,7 @@ proc createRLNInstanceLocal(d = MerkleTreeDepth,
cache_capacity: 15_000,
mode: "high_throughput",
compression: false,
flush_interval: 12_000,
flush_interval: 500,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the flush_interval attribute used for?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is describes how often we flush pmtree cache to disk. just experimenting with waku-simulator here

@alrevuelta
Copy link
Contributor

Can confirm that after testing this PR with waku-simulator, valid proofs are now indeed considered valid.
Thanks!

@@ -501,6 +504,8 @@ method init*(g: OnchainGroupManager): Future[void] {.async.} =
except CatchableError:
error "failed to restart group sync", error = getCurrentExceptionMsg()

# Contract starts from the first index
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we calculating the startIndex manually (setting g.latestIndex to be 1 here, and then using that value in atomicBatch, instead of passing the index retrieved from the event logs?

I'm probably wrong, so please correct me if that's the case, but I think this might be problematic in case of a partial sync or if a lot of time has passed since the last sync, since in getAndHandleEvents the function setMetadata is called for each block chunk, and if for some reason we don't sync the full chain, the next time we start nwaku, it will load the metadata to retrieve the latest block that was synced, and will call atomicOperation passing the index 1, instead of the index from the logs that were emitted in the blocks that are being processed, thus the leaves from the merkle tree will be overwritten instead of inserting new elements.

Copy link
Contributor Author

@rymnc rymnc Aug 18, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, thanks for raising this issue - fixed in 048cdc2

@rymnc rymnc self-assigned this Aug 18, 2023
Copy link
Contributor

@alrevuelta alrevuelta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested the latest commit. lgtm.

@rymnc rymnc merged commit b3bb7a1 into master Aug 18, 2023
12 checks passed
@rymnc rymnc deleted the fix-proof branch August 18, 2023 11:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

None yet

3 participants