Waku's Requirements on a Consensus Mechanism #333
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jm-clius
approved these changes
Aug 5, 2025
Contributor
jm-clius
left a comment
jm-clius
left a comment
There was a problem hiding this comment.
Yes, this is a good description of current on-chain use case. Thanks!
requirements/consensus.md
Outdated
| All Waku network nodes must enforce identical message validation rules to prevent network splits at the libp2p-gossipsub layer. | ||
| This necessitates consensus on the Merkle tree’s state across the network. | ||
|
|
||
| To achieve this, range validation is employed: a node verifies messages against the current root and a set of previous roots, accommodating proofs generated on recent prior roots. |
Contributor
There was a problem hiding this comment.
The clarification helps, but I find "range validation" unclear - why not:
Suggested change
| To achieve this, range validation is employed: a node verifies messages against the current root and a set of previous roots, accommodating proofs generated on recent prior roots. | |
| To achieve this, a node verifies messages against the current root and a window previous roots, accommodating proofs generated on recent prior roots. |
requirements/consensus.md
Outdated
| Re-evaluation may occur during migration to Status Network, given potential closer relation with RPC providers. | ||
|
|
||
| *Note:* These constraints primarily affect Waku Relay nodes (cloud/laptop-based). | ||
| Edge nodes (mobile/browser) require less frequent RPC access due to lower message volume and relaxed time constraints—since they verify messages without forwarding them (unlike relays, which must validate before propagation). |
Contributor
There was a problem hiding this comment.
Suggested change
| Edge nodes (mobile/browser) require less frequent RPC access due to lower message volume and relaxed time constraints—since they verify messages without forwarding them (unlike relays, which must validate before propagation). | |
| Edge nodes (mobile/browser) require less frequent RPC access due to lower message volume and relaxed time constraints—since they verify only the small subset of messages of interest to them. |
This seems more accurate to me, at least in terms of what we plan - edge nodes still need to verify messages that they publish with own RLN membership and probably messages that they receive via filter subscription too. However, this is presumably low-rate and can use some on-demand RPC-call strategy.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
First draft - early review only for Waku leads.