You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
RFC 51 introduces the idea of static sharding for Waku and specifies how static shards should be encoded in ENRs. A Waku client should be configurable to relay messages on one or more static shards, encode this information in its own advertised ENR and filter discovered peers to only consider those subscribed to the static shards that it's configured for.
#1763 added the following functionality towards achieving this:
ability to encoding static shards into an ENR, check if the record contains a specific shard and other utilities see module
ability to filter discovered discv5 nodes using a predicate function
However, to finish this feature, the following still needs to be finished:
the wakunode2 app should be configurable with static shards
a node configured for static shards should encode this in its own advertised ENR
a node configured for static shards should filter its discovered nodes to only consider those connected to one or more of its own configured static shards
Suggested solution
To achieve the above, I can see at least three self-contained steps, preferably completed in at least three incremental PRs:
Step 1: allow static shard configuration on wakunode2 application
This entails allowing the node to be configured for static shards via the app's --topic option.
Once configured for one or more static shards, the app should verify that:
there are no configured non-static shard topics
all configured static shards are from the same cluster (see RFC 51)
A node with static shard configuration should then encode this information in its ENR.
Step 2: move discv5 discovery loop into wakunode2 application
In order to sensibly create a predicate function by which to filter discovered nodes, the recurring task of discv5 lookups should move from the node to the application. This in turn would allow us to remove wakuDiscv5 as a node component.
Step 3: create predicate to filter discovered nodes on static shard
Once the discv5 discovery loop is part of the application (and not the underlying node), the application should create a predicate function by which to filter discovered node records (ENRs), if it detects a static shard configuration. This should use the already provided functionality to filter ENRs based on the static shard field.
Acceptance criteria
nodes configured with static shard topics advertise this in their ENR according to RFC51
discv5 no longer belongs to the waku_node, but to the wakunode2 application
nodes configured with static shard topics filter discovered nodes according to their own configuration
The text was updated successfully, but these errors were encountered:
Problem
This is a subtask for #1643
RFC 51 introduces the idea of static sharding for Waku and specifies how static shards should be encoded in ENRs. A Waku client should be configurable to relay messages on one or more static shards, encode this information in its own advertised ENR and filter discovered peers to only consider those subscribed to the static shards that it's configured for.
#1763 added the following functionality towards achieving this:
However, to finish this feature, the following still needs to be finished:
wakunode2
app should be configurable with static shardsSuggested solution
To achieve the above, I can see at least three self-contained steps, preferably completed in at least three incremental PRs:
Step 1: allow static shard configuration on
wakunode2
applicationThis entails allowing the node to be configured for static shards via the app's
--topic
option.Once configured for one or more static shards, the app should verify that:
A node with static shard configuration should then encode this information in its ENR.
Step 2: move discv5 discovery loop into
wakunode2
applicationIn order to sensibly create a predicate function by which to filter discovered nodes, the recurring task of discv5 lookups should move from the node to the application. This in turn would allow us to remove
wakuDiscv5
as a node component.Step 3: create predicate to filter discovered nodes on static shard
Once the discv5 discovery loop is part of the application (and not the underlying node), the application should create a predicate function by which to filter discovered node records (ENRs), if it detects a static shard configuration. This should use the already provided functionality to filter ENRs based on the static shard field.
Acceptance criteria
waku_node
, but to thewakunode2
applicationThe text was updated successfully, but these errors were encountered: