-
Notifications
You must be signed in to change notification settings - Fork 0
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
Comments
This is a great idea! |
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 😬 |
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. |
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 theWakuMessage
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:
nwaku
node with rln enabled10msg/s
,25msg/s
,50msg/s
,70 msg/s
nwaku
cpu and memory consumption and asses if consumer grade hardware can handle it.The text was updated successfully, but these errors were encountered: