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

Can RLN proof verification scale? #30

Open
alrevuelta opened this issue Oct 12, 2023 · 4 comments
Open

Can RLN proof verification scale? #30

alrevuelta opened this issue Oct 12, 2023 · 4 comments

Comments

@alrevuelta
Copy link
Contributor

Without RLN it wasn't resource-intensive to validate relay messages. It was as simple as decoding it and accepting it if it complied with the WakuMessage type. This took almost no time and resources.

However with RLN in place, now each message has a proof that has to be verified. In #23 we ran some simulations and found that the validation of said proofs takes around 0.012 seconds each. But we didn't really stress test nwaku with multiple messages per second.

So we must ensure that rln proof verification can scale to multiple messages per second, and what is even more important, that average computers can handle it.

So we need to:

  • Run a nwaku node with rln enabled
  • Run multiple publishers with rln enabled, with total message rates in the topic of 10msg/s, 25msg/s, 50msg/s, 70 msg/s
  • See nwaku cpu and memory consumption and asses if consumer grade hardware can handle it.
  • Run same setup with rln off, and see the diff.
@rymnc
Copy link

rymnc commented Oct 12, 2023

This is a great idea!

@s-tikhomirov
Copy link
Contributor

Great question. A follow-up question could be: is it possible to outsource proof verification to a third party (with minimal trust assumptions)? Kinda like separate prover networks for ZK-rollups (that's for proof generation, not verification, but still). And by the way, how resource-heavy is proof generation?

@rymnc
Copy link

rymnc commented Oct 12, 2023

Great question. A follow-up question could be: is it possible to outsource proof verification to a third party (with minimal trust assumptions)? Kinda like separate prover networks for ZK-rollups (that's for proof generation, not verification, but still). And by the way, how resource-heavy is proof generation?

Err, outsourcing verification to a third party will introduce network latency (~200ms) which is much greater than verification times 😬

@alrevuelta
Copy link
Contributor Author

Great question. A follow-up question could be: is it possible to outsource proof verification to a third party (with minimal trust assumptions)? Kinda like separate prover networks for ZK-rollups (that's for proof generation, not verification, but still). And by the way, how resource-heavy is proof generation?

Agree with @rymnc, outsourcing would introduce a latency that makes it not feasible. Even if we had a blackbox service with infinite resources validating proofs in 0 time, the network delay kills the idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants