Current Status of Waku-Mix integration

Completed

  1. rfc draft of waku-mix published https://github.com/waku-org/specs/blob/master/standards/core/mix.md
  2. mix protocol integration status
    1. Request path integrated for lightpush protocol where destination peer doesn’t need to support mix
    2. All nwaku nodes that support mix form a mix overlay network and acts as intermediary/exit node
    3. Each mix node (entry/intermediate/exit) maintains a mix node pool to choose from for publishing.
    4. Discv5, Waku-Peer-exchange is used to discover mix nodes and maintain a node pool (i.e get mixpubKey of the node and its address). Node online status is not maintained as of now
    5. Simulations have been done for lightpush where latency introduced by mix has been captured https://forum.vac.dev/t/waku-mix-integration-simulations/469
    6. mix msgSize of 4K bytes set for waku
    7. if fragmentation to be implemented at mix layer it adds more complexity at exit nodes because they need to wait for all fragments to arrive in order to deliver them to destination.

Potential Next Steps/Points of discussion

  1. Implement Reply path using SURB for Lightpush (No open questions)
  2. Fragmentation of msgs to be implemented in mix or should it be taken care of by the higher layer?
    1. as of now msg of single size only allowed and any higher msgSize is rejected by mix
    2. Especially if exit node is not the destination then sender cannot choose different paths for the fragments.
    3. Or alternatively should we support multiple packet sizes in the mixnet - This may introduce additional challenges.
  3. Spam prevention in the mix overlay network.
    1. Can we use RLN in some form?
    2. In the current form RLN cannot be used as each packet only goes through few nodes in the network and the only way rate-limit can be verified is by querying/syncing with a blockchain for every message which doesn’t sound practical.
  4. Prevent attackers from biasing mix node selection.
    1. Once Discovery improvements planned by Vac are integrated, maybe this can be further analyzed
  5. Should we think of injecting cover traffic Or is to too soon and introduce it only after further analysis?
  6. Waku-Relay integration into mix. As of now it looks like there are 2 ways this can be done
    1. publishing via relay uses lightpush-with-mix to publish and rest of gossipsub functions remain same
    2. integrate gossipsub itself into mix such that when publishing 1 or more mesh-paths are mixed and rest are published without mixing. Need to understand further how this is being approached currently.
  7. As of now delay to be introduced by each mix node is included in the sphinx packet header by the sender. there is no way to confirm that the mentioned delay is enforced by a specific mix node.
    1. Could there be an approach to handle/address this?
    2. Is there any way nodes can attack mixnet this way (by causing more delays than specified which may result in packet loss)?