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

Persist Merkle tree, valid roots and last sync block #67

Open
fryorcraken opened this issue Sep 22, 2023 · 2 comments
Open

Persist Merkle tree, valid roots and last sync block #67

fryorcraken opened this issue Sep 22, 2023 · 2 comments
Assignees
Labels
enhancement New feature or request track:rln RLN Track (Secure Messaging/Applied ZK), e.g. relay and applications

Comments

@fryorcraken
Copy link
Contributor

fryorcraken commented Sep 22, 2023

Summary

Merkle tree, valid roots and last sync blocks are necessary to generate and validate proof.
This information is retrieved from the blockchain.

Accessing the blockchain represent several challenges:

  • Web3 wallet/ Web3 RPC Provider needs to be present, logged in and ready. Even if no "write" action is necessary it's unsure that read access is always available. Meaning user may have to log in.
  • An extra query before the node can start sending or verifying messages

Proposed solution

Cache the information locally (local storage?). The information is publicly available on the blockchain and does not need to be protected.

Note

  • Need to verify some assumptions. If using a wallet extension or wallet connect, can the Web3 Provider be used to read smart contract data without the user being logged in?
  • Should we look into and provide alternative to the usual Web3 Provider in terms of reading abilities.
  • There are probably some unknowns here (does sled-db run in wasm? should we create an specific persistance mechanism?).
  • This may be a nice to have. We can review and descope later.
@fryorcraken
Copy link
Contributor Author

@richard-ramos @rymnc except if sled-db magically store information in the local storage, and even so, it is most likely more efficient to pass on our persistence by storing data in json format in the browser's local storage.

@fryorcraken fryorcraken added enhancement New feature or request track:rln RLN Track (Secure Messaging/Applied ZK), e.g. relay and applications E:3.2: Basic DoS protection in production See https://github.com/waku-org/pm/issues/70 for details labels Sep 22, 2023
@rymnc
Copy link

rymnc commented Sep 22, 2023

@richard-ramos @rymnc except if sled-db magically store information in the local storage, and even so, it is most likely more efficient to pass on our persistence by storing data in json format in the browser's local storage.

not too sure about where the sled db will be stored in wasm land, but what we can do is add 2 fns to the rln-wasm api, import and export, which accepts a json blob and returns one respectively. This way, on initialisation of the rln object, you can "import" the json blob into the new sled db instance, and before shutting down, "export" it to localStorage?

@weboko weboko self-assigned this Sep 22, 2023
@weboko weboko removed the E:3.2: Basic DoS protection in production See https://github.com/waku-org/pm/issues/70 for details label Jan 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request track:rln RLN Track (Secure Messaging/Applied ZK), e.g. relay and applications
Projects
Status: To Do
Development

No branches or pull requests

3 participants