Mixnet PoC: Draft design #288
Conversation
mixnet/src/config.rs
Outdated
| pub addr: SocketAddr, | ||
| // TODO: add pubkeys | ||
| // TODO: find better ways to handle topology | ||
| pub topology: Vec<SocketAddr>, |
There was a problem hiding this comment.
Instead of having this static (or shared) topology, we may be able to leverage libp2p peer discovery. Mixnodes advertise their IP address and their public key (or libp2p peer_id) to other mixnodes. Then, each mixnode can pick 3 mixnodes randomly in order to build a Sphinx packet.
With this approach, the effect of mixing packets wouldn’t be high until a mixnode get enough advertisements.
There was a problem hiding this comment.
The important point here would be decoupling the libp2p::PeerId with nomos::NodeId, so that anyone cannot derive nomos::NodeId that is probably associated with stakes.
There was a problem hiding this comment.
I just talked with @danielSanchezQ about trying this DHT idea. I'll put a super simple prototype on top of this PR soon, so that we can continue discussions from it.
There was a problem hiding this comment.
Just implemented a naive approach of managing the topology: d55a293. This doesn't actually use DHT. Instead, each node broadcasts their external IP address and their public key via gossipsub, so that receiving nodes can update the mixnet topology that they hold in their memory.
Here, the public key should be different from the public key associated with nomos::NodeId.
| Command::Broadcast { topic, message } => { | ||
| match swarm.broadcast(&topic, message) { | ||
| Ok(id) => { | ||
| tracing::debug!("broadcasted message with id: {id} tp topic: {topic}"); | ||
| } | ||
| Err(e) => { | ||
| tracing::error!("failed to broadcast message to topic: {topic} {e:?}"); | ||
| } | ||
| } | ||
| let msg = MixnetMessage { topic, message }; | ||
| log_error!(mixnet_relay.send(MixnetMsg::Send(msg.as_bytes())).await); |
There was a problem hiding this comment.
What do you guys think about this strategy, using mixnet only for the first hop of gossipsub? This is one of strategies that we discussed. Although we haven't verified this strategy in detail, I'm getting an impression that this will probably meet our privacy requirements, as Lighthouse guys said.
There was a problem hiding this comment.
Yes, and for now is probably the easiest approach. So I think is the path to go.
| - [Libp2p](./src/backends/libp2p.rs) | ||
|
|
||
|
|
||
| ## Mixnet integration |
There was a problem hiding this comment.
Added a README to describe the approach of Mixnet PoC. I would say this design/implementation isn't optimal. It's probably a starting point that we can improve.
youngjoon-lee
changed the title
|
As this PR has lots of outdated discussions, I’ll open a new PR based on the design written in Notion: https://www.notion.so/Mixnet-Architecture-613f53cf11a245098c50af6b191d31d2 |
This PR isn't meant to be merged to the
master. Code quality is not good and is not tested.This is just for proposing the design of Mixnet integration and starting discussions from it.
If we agree on this design, we can merge this PR to the
mixnetbranch.For more contexts, please see #273.
This PR is proposing integrating MIxnet only for the first hop of gossipsub (actually before starting gossipsub).
Each Nomos node just throws a message to Mixnet instead of broadcasting it through gossipsub. A message goes through Mixnet, and the last mixnode in the route broadcasts the message via gossipsub.
This PR doesn't cover:
how to construct/manage the mixnet topology (mixnode address, and so on).: d55a293