-
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
Create RLN proof without having the whole tree #79
Comments
wow, this is nice! |
Nice work! One thought wrt approach: In order to address this
|
That's a great idea. As a rule of thumb any API endpoint or protocol such as light-push should perform as much validations as possible, and inform the user if such message is invalid (like invalid root)
Once merkle proofs are fetched directly from the contract (see point ii in issue), the "NewMerkleRoot" event could act as that, and we avoid having an extra protocol on waku side. In other words, you can subscribe to that NewMerkleRoot event and whenever it changes, you request a new proof. Another idea could be to guarantee that all roots belonging to the last x blocks are valid. If we set this to 1 minute, then we could guarantee that proofs <1min will be valid. This would require to store way more merkle roots in some cases, since afaik each insertion/deletion "consumes" a slot in the window. Example, if 100 insertions are done in this last minute, we have to store 100 different merkle roots and validate each message against each one. Related to your first point, we could have an optimistic approach, where you assume your proof is valid until light-push errors saying otherwise. At that point you fetch a new one. |
I missed going through this. But got it and this would require querying contract to get the new root.I am trying to think if we can avoid blockchain interaction in lightClients. :) Hence suggesting some Waku protocol for this (It could be as simple as reusing existing FilterProtocol where merkleRoots are advertised in a contentTopic named RLN-membership-updates ). This does comes with it own challenge of trusting whoever broadcasts into this topic. But since mostly lightClients would actually use some RPC provider API for this anyways, maybe avoids that. |
I had thought about this, but validating a message against soo many roots maybe too costly. I think the current last 5 roots seem good enough. |
Yea, thought of this as well..but polling + this felt like the sweet spot to me. That way we reduce multiple RTT's for sending a message most of the time and only in some corner cases where suddenly a lot of registrations happen in a short span. |
1 final root per block |
Workshop agenda 14 Marc 2024 [1h]:
|
TLDR: We present a proof of concept for light clients, where they don't need to sync the whole tree to create RLN proofs to send their messages. PoC here
One of the main problems with light clients and RLN is that they require the whole Merkle tree to generate valid proofs. Meaning that they need to sync the whole tree to send a message into the network. This creates friction since syncing the whole tree takes several minutes, and the sync time increases with the number of memberships registered.
This issue proposes a proof of concept where light clients can generate RLN proofs with just a Merkle proof that their commitment belongs to the tree. This Merkle proof has a fixed size of 20 and can be fetched from:
This issue explores i) and presents this proof of concept to showcase the feature. The Merkle proofs are obtained with this service deployed in the sandbox machine. Endpoint available here, just replace the number with your commitment. Note that this Proof Of Concept is fully compatible with The Waku Network. Note that i) is a step in between towards ii). Any client can use this feature, see newly exported
generate_rln_proof_with_witness
from zerokit.Related PR:
Thanks @richard-ramos @rymnc for their help.
The text was updated successfully, but these errors were encountered: