-
Notifications
You must be signed in to change notification settings - Fork 53
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
bug: RLN inconsistent state rejects valid messages #2928
Comments
this approach is probably less robust than our current implementation |
As discussed in our call, the option of linking RLN epochs to the underlying blockchain's slot is a promising idea, with some noteworthy tradeoffs -
Here's what the pseudocode would look like
We will have to do some preliminary analysis on variance of block-times of L2s we may be interested in for mainnet deployment to estimate actual values of cc: @alrevuelta |
@rymnc thanks! In general I like the idea, but perhaps there is an attack vector here.
On the other hand, I'm concerned because this still doesn't deterministically ensure messages are processed correctly since it relies on the local timestamp of each node. The shorter the block time, the more impact a biased clock will have. But in any case, I think it's a great way to start. |
Originally reported in #2870 this issue refers to the same problem but expands on the root cause of it, with a possible solution to fix it.
In short, valid messages containing valid RLN proofs are rejected by some nodes with
invalid message: provided root does not belong to acceptable window of roots
. This bug is difficult to reproduce but shows up more frequently when new RLN memberships are being inserted in the contract. With a static amount of memberships this won't show up.The problem is the following:
DefaultBlockPollRate
).invalid message: provided root does not belong to acceptable window of roots
error in some nodes.As shown in the image, we have some sort of race condition during this interval. If
nwaku1
creates a message att1
and propagates it to the network,nwaku2
will flag it as invalid andnwaku3
as valid. There is an inconsistency between the nodes, where the merkle trees are not guaranteed to be the same.Known the issue, there would be 2 ways to mitigate it (but not completely fix it):
DefaultBlockPollRate
. A lower value would reduce how likely this is to happen, since it will shorten the "ambiguity window". But the issue will still be there.So my proposal to fix this would be the following. We need to somehow connect RLN timestamps (aka epochs) to blockchain timestamps (aka blocks or slots). This would allow a proper ordering of events, so we can know if the RLN message we are receiving is from the future. In other words, if we receive a RLN message with timestamp 10 but we have just synced the blockchain till timestamp 9, then we know that we can't process this message, since we are not up to date. In this case, the node would need to sync first and validate after. With this, we will no longer reject a valid message, since we first sync, process after. The solution has to be ofc well designed to avoid unnecessary delays.
It's up for discussion how "connecting RLN timestamps to blockchain timestamps" will work. If using Ethereum L1, slots could be an option, since the happen at fixed 12s intervals. Unsure how it will work in L2s. And well, as a requirement we need a solution that is portable across chains/layers.
The text was updated successfully, but these errors were encountered: