waku mix integration spec #53
Conversation
|
Requesting some initial input from @jimstir and Vac RFC team too. |
chaitanyaprem
force-pushed
the
feat-waku-mix
branch
from
2e52e22 to
941d171
Compare
chaitanyaprem
force-pushed
the
feat-waku-mix
branch
from
76c90a4 to
3bd82bd
Compare
chaitanyaprem
changed the title
chaitanyaprem
force-pushed
the
feat-waku-mix
branch
from
a86e712 to
aab4ffc
Compare
chaitanyaprem
force-pushed
the
feat-waku-mix
branch
from
aab4ffc to
ebf8b46
Compare
| Nodes that want higher anonymity while publishing a message via [lightpush](https://rfc.vac.dev/waku/standards/core/19/lightpush) or performing a [store](https://rfc.vac.dev/waku/standards/core/13/store) query SHOULD use the `mix` protocol to route their messages to the destination. | ||
| Sender Node that would like to use `mix` protocol SHOULD discover enough mix nodes so that there is always a healthy pool of mix nodes available for selection. | ||
| The pool size of mix nodes SHOULD be large enough for the mixing to be effective. | ||
| We RECOMMEND a pool size of at least 100 mix nodes for the mixing to be effective. |
There was a problem hiding this comment.
Is there any calculation to back up this number? What is considered "effective", by what metric?
There was a problem hiding this comment.
Not at this point in time, at this point we just know that the larger the node-pool to choose from gives higher anonymity. I think such analysis would be done by vac team or we can also do but at a later stages.
At this point it is just theoretical.
|
|
||
| In order to provide anonymity of the sender node from the `service-node`, `Single Use reply blocks` or `anonymous replies` as specified in the original [sphinx](#references) paper SHALL be used. | ||
|
|
||
| A node that sends messages using `mix` MAY use two redundant (paths)[https://rfc.vac.dev/vac/raw/mix#24-node-discovery] to have better reliability of the message being delivered. |
There was a problem hiding this comment.
What does it mean for two paths to be redundant? They must not have any node in common apart from the destination?
There was a problem hiding this comment.
Not necessarily, it just means choose 2 paths (each path is chosen randomly from node-pool). If the node pool is sufficiently large then the chance of a node being common in 2 paths selected in quick succession would be very low. But there is no gaurantee as such to ensure there is no common node in 2 paths.
| Mix protocol in waku network SHOULD have `rate-limiting/spam` protection to handle scenarios such as below: | ||
|
|
||
| 1. Any node can generate a mix packet and publish into the mix network. Hence there needs to be some validation as to who is allowed to publish and whether the user is within allowed rate-limits. | ||
| 2. Any node can intentionally generate paths which are broken and send messages into the mix network. |
There was a problem hiding this comment.
What is a broken path? Is it a path that includes a non-existent node? Other than that, do we assume that two live mix node can always form a hop in a path if a Sphinx packet says so?
There was a problem hiding this comment.
well, here it just means that somewhere along the path one of the mix nodes is not able to connect to the next node in the path. It could be that the node is no longer running or offline or just not reachable.
Some of these can be mitigated if the sender of the messages checks rechability and online status of all nodes in the path before sending the packet out.
These are all challenges that need to be solved in further phases.
| They MAY do so by updating their [ENR](#enr-updates) and using one of the ENR based discovery methods. | ||
|
|
||
| Nodes that want higher anonymity while publishing a message via [lightpush](https://rfc.vac.dev/waku/standards/core/19/lightpush) or performing a [store](https://rfc.vac.dev/waku/standards/core/13/store) query SHOULD use the `mix` protocol to route their messages to the destination. | ||
| Sender Node that would like to use `mix` protocol SHOULD discover enough mix nodes so that there is always a healthy pool of mix nodes available for selection. |
There was a problem hiding this comment.
It is critical that the discovered mix node pool is representative of the entire network and not biased toward specific subsets (e.g., nodes that are topologically closer). If discovery methods introduce bias, adversaries could manipulate pool selection, increasing the likelihood of compromised nodes being chosen.
While the recommended pool size (n = 100) seems reasonable, clarification on how this number was determined could be helpful. Assuming a 30% malicious node fraction and a truly random selection process, the expected fraction of malicious nodes in the pool remains ~30%. Under these conditions, selecting a 3-node path from the pool results in an ~9% chance that both the entry and exit nodes are adversarial—an acceptable risk level.
However, to ensure the discovered mix pool accurately reflects the overall network, the total network size (N) should be large enough (e.g., N ≥ 10n), assuming unbiased node discovery.
Therefore, explicitly stating these assumptions could be helpful—the discovered mix pool MUST be unbiased, and the network size N MUST be sufficiently large compared to the pool size.
There was a problem hiding this comment.
ok, that is a good point i.e discovery should not choose nodes that are topologically closer and should be unbiased. Will add that explicitly.
100 was just a number i have mentioned considering network size of 1000(which is the approx size of The Waku Network), did not arrive at it based on specific logic but more of a hunch :)
Therefore, explicitly stating these assumptions could be helpful—the discovered mix pool MUST be unbiased, and the network size
NMUST be sufficiently large compared to the pool size.
wondering if we should state the network size assumption. What if network size is itself 100, then having nodepool size of 100 also is good imo. Can we rather mention that node pool size should be atleast x% of network size or 100 whichever is applicable, not sure what x should be?
|
|
||
| 1. Any node can generate a mix packet and publish into the mix network. Hence there needs to be some validation as to who is allowed to publish and whether the user is within allowed rate-limits. | ||
| 2. Any node can intentionally generate paths which are broken and send messages into the mix network. | ||
| 3. An attacker can spawn a huge number of mix nodes so that user behaviour is observed in order to determine traffic patterns and deanonymize users. |
There was a problem hiding this comment.
It may be worth clarifying that while an attacker can introduce a large number of mix nodes to analyze traffic patterns, Sphinx encryption makes such attacks significantly more difficult. An adversary must control at least both the entry and exit nodes to successfully deanonymize a user, which becomes increasingly difficult as the network size grows.
There was a problem hiding this comment.
understood, but if the network makes it easy to spawn nodes (i.e at low cost and no friction of entry) then an attacker with resources can spin up a lot of nodes very easily.
This has to be solved some other way, which is why i wanted to highlight this point explicitly.
Co-authored-by: AkshayaMani <[email protected]>
Document explaining mix integration with waku.
This is still work in progress.
@jm-clius could you take a look at structure and suggest anything else that would be required to be added?