What I want to have

• A mix queue per connection
• A constant transmission rate (Emitting drop messages if there is no real message)
• Unwrapping Sphinx messages before forwarding them, if possible

Libp2p Gossipsub Behaviour

• What we need from gossipsub
  • duplicate_cache
• Good to have (Maybe?)
  • heartbeat
  • peer scoring (based on not only heartbeat, but also message validations)
• What we don't need in gossipsub (or at least need to discuss)
  • subscription / GRAFT / PRUNE
  • message author/signature validation
  • Continuous gossiping using mcache and IHAVE/IWANT (maybe?)
    • The purpose of gossiping between mix nodes is not broadcasting messages to all mix nodes. It is okay as long as the target mix node receives the (Sphinx) message.

Implementation Strategies

1. Replacing ConnectionHandler of gossipsub::Behaviour with our own handler that has a mix queue.
   • MAYBE POSSIBLE by wrapping gossipsub::Behaviour to use our own handler without any modification of its behaviour.
   • Pros: We can leverage all p2p practices that have been researched and implemented in gossipsub.
   • Cons
     • The gossipsub::Handler and related functions are not public. We will end up rewriting all internal functions to make our handler behave as the gossipsub intends.
     • All control messages (heartbeat, IHAVE/IWANT, GRAFT/PRUNE) are also mixed by the mix queue. These further decrease the probability of the emission of real messages. Also we need to think about whether these control messages are really necessary in the mixnet protocol.
     • This alone doesn't solve "Unwrapping Sphinx messages before forwarding them".
2. Wrapping gossipsub::Behaviour and modifying some parts of its behaviour.
   • NOT POSSIBLE because most of the structs and functions in the gossipsub crate are not public. We will end up rewriting all internal functions in the gossipsub.
3. Writing our own behaviour and handler.
   • POSSIBLE, of course
   • Pros: Optimized message transmission without any control message
   • Cons: No peer scoring

My choice

I chose the option 3 because:

• It’s very simple to implement the Mixnet behaviour.
• Gossipsub is a complex protocol. I want to make the Mixnet protocol easy to debug, at least until we have a strong confidence that the new Mixnet protocol works well with the rest of the Nomos protocol.
• I don't want to break the property of mixing that we have experimented by adding control messages. If we want to leverage those control messages, we first need to discuss with the research.
• I want to write only code directly necessary to the Mixnet protocol. It would slow down our development and maintenance to rewrite internal functions already implemented in the gossipsub.

Discussion Points with the Research

• gossipsub has IWANT/IHAVE control messages. It keeps historical messages in a cache and tries to gossip it multiple times, so that any offline peer can receive messages once it becomes online. I don't use those control messages in the mixnet. Do we want to have them? That has the concept of sequence number of messages in order to simplify the IWANT/IHAVE mechanism, but I guess we need to check it in perspective of privacy that our Mixnet aims to have.