-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improved Mixnet design: Random mixnet destination #307
Conversation
80e49f2
to
cfd87d9
Compare
* Refactor body type to encapsulate data * Use final payload as generic async read * fix sending SphinxPacket * use a common protocol for sending final payload to mixclient * add a missing TODO comment --------- Co-authored-by: Youngjoon Lee <taxihighway@gmail.com>
#[derive(Serialize, Deserialize, Clone, Debug)] | ||
pub enum MixnetClientMode { | ||
Sender, | ||
SenderReceiver(SocketAddr), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of making mixclient listen connections, I’ll make mixnode open another port only for the mixclient. I think that makes much sense. Then, the mixclient API could be much cleaner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’ll do this at the next PR to not make this PR bigger. Because this PR works now, I think we can go with this, as long as we agree on the MixnetClientMode design
In the previous design #302, the problem was that message senders must specify the mixnet destination (== the IP of
MixnetClient
). Please note that it's different from the message routing destination.But, in reality, senders doesn't have any information about the IP of
MixnetClient
s available.Instead, I improved the design like this:
nomos-node
always embed aMixnetClient
that receives Sphinx packets, reconstructs messages, and sends them to the network backend in itsnomos-node
.MixnetNode
, you must know at least oneMixnetClient
address.MixnetNode
operators should run their ownnomos-node
as well.MixnetNode
fromMixnetTopology
, they choose one moreMixnetNode
as a destination, randomly.MixnetNode
. Then, the message is reconstructed and is broadcasted/routed to all othernomos-node
s.nomos-node
operator, it's not mandatory to runMixnetNode
.With this design, the message sender doesn't need to know about the mixnet destination, as Alvaro suggested.
At the next PR, I'll show how to integrate these to the
nomos-node
.