Skip to content
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

Add mixnode and mixnet-client crate #302

Merged
merged 22 commits into from
Aug 21, 2023
Merged

Add mixnode and mixnet-client crate #302

merged 22 commits into from
Aug 21, 2023

Conversation

youngjoon-lee
Copy link
Contributor

@youngjoon-lee youngjoon-lee commented Aug 14, 2023

Implemented the mixnode and mixnet-client crate, according to https://www.notion.so/Mixnet-Architecture-613f53cf11a245098c50af6b191d31d2.

NOTE:

  • This PR is going to be merged to the mixnet branch, not the master.
  • I recommend you to look at the test files first.

CHANGES:

  • mixnode: A core crate for implementing the mixnode binary
    • forwards Sphinx packets to next mixnodes.
  • mixnet-client: A client library for mixnet users (such as nomos-node)
    • splits a message into multiple Sphinx packets
    • sends Sphinx packets to the mixnodes.
    • receives Sphinx packets from mixnodess and re-assemble the message.

TODO:

  • Implement a nomos-mixnode binary using the mixnode crate.
  • Integrate the mixnet_client crate with Nomos network backends.
  • Refactoring
  • Many TODOs written in source code.
  • Cover traffic (We could postpone this a bit, as it's complex).

bacv and others added 6 commits August 10, 2023 12:56
* Add pruning methods

* Call pruning on node step method

* Fix tally retain closure
* Update sim engine on timeout qc

* Remove rebuild method
* implement research overlay

* Add branch overlay

* Branch overlay config in simulation

* Remove research related extensions

* Use branch_depth and chunks

---------

Co-authored-by: Gusto <bacvinka@gmail.com>
@youngjoon-lee youngjoon-lee changed the title Add mixnet crate Add mixnode and mixnet-client crate Aug 14, 2023
message_reconstructor: Arc<Mutex<MessageReconstructor>>,
) -> Result<(), Box<dyn Error>> {
let mut buf = Vec::new();
socket.read_to_end(&mut buf).await?;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to confirm, I guess this means a new connections is opened for each new message? This would indeed make sense given route is dynamic

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, for now. Later, I think we need to introduce better connection managements at some point, depending on how often the mixnet topology is updated. For example, Nym mixnodes stay connected with mixnodes in the next layer because they updated the topology once a day or an hour, iirc.

socket.read_to_end(&mut buf).await?;

let payload = Payload::from_bytes(&buf)?.recover_plaintext()?;
let fragment = Fragment::try_from_bytes(&payload)?;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no chunks?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand your comment correctly, this function just receives a single fragment (chunk) and throws it to the message reconstructor. The message reconstructor keeps all fragments previously received, in memory. If the message can be finally reconstructed with the newly received fragment, the message reconstrcutor returns the message fully reconstructed.

mixnet/client/src/sender.rs Outdated Show resolved Hide resolved
mixnet/mixnode/src/lib.rs Outdated Show resolved Hide resolved
let mut route: Vec<route::Node> = Vec::new();

for layer_id in 0..num_hops {
let layer = self.layers.get(layer_id).unwrap();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's not clear from the api that layer_ids are incremental

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you. I just realized that we don't actually need the LayerId type: ea23c6e

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also simplified the API by removing the num_hops: b8d3bad. We can revive it later after the first iteration is done.

}

impl Layer {
pub fn random_node(&self) -> Option<&Mixnode> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should probably ask the caller to provide the source of randomness

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point: 2fd055b.
I had to downgrade the rand and rand_xoshiro in the integration test, because nym-sphinx depends on the rand@v0.7.3. If we use the rand@v0.8, the following error occurs:

   --> mixnet/client/src/sender.rs:65:35
    |
65  |             .split_into_fragments(rng, plaintext_size_per_packet)
    |              -------------------- ^^^ the trait `rand_core::RngCore` is not implemented for `R`

bacv and others added 2 commits August 16, 2023 11:08
* Handle finished simulation

* Flush remaining records to the sink

* Write runtime metadata last
* Add rs lib, implement encoding

* Implement decoding
let mut msg = [0u8; 100 * 1024];
rand::thread_rng().fill_bytes(&mut msg);

let res = client1.send(msg.to_vec(), destination, &mut OsRng, topology.layers.len());
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zeegomo @danielSanchezQ
I just changed the mixnet design a bit in the PR #307, so that the message sender doesn't need to specify the mixnet destination explicitly. Please review that PR together with this PR. I put detailed descriptions there.

Copy link
Collaborator

@danielSanchezQ danielSanchezQ left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can go ahead with this. 🚀

@youngjoon-lee
Copy link
Contributor Author

youngjoon-lee commented Aug 21, 2023

@zeegomo I'm merging this PR since I've applied your suggestions and there have been many architectural changes (especially in PR #307). I think it's better to merge this now to the mixnet branch, so that we can improve it gradually together from there after you come back. I guess there would be many things to be refined/improved when we integrate the mixnet with network-backend.

@youngjoon-lee youngjoon-lee force-pushed the mixnet-node branch 2 times, most recently from 9be1b8f to 84dfb0f Compare August 21, 2023 12:42
@youngjoon-lee youngjoon-lee merged commit aec6258 into mixnet Aug 21, 2023
2 checks passed
@youngjoon-lee youngjoon-lee deleted the mixnet-node branch August 21, 2023 13:34
youngjoon-lee added a commit that referenced this pull request Aug 21, 2023
youngjoon-lee added a commit that referenced this pull request Sep 14, 2023
* Add `mixnode` and `mixnet-client` crate (#302)

* Add `mixnode` binary (#317)

* Integrate mixnet with libp2p network backend (#318)

* Fix #312: proper delays (#321)

* proper delays

* add missing duration param

* tiny fix: compilation error caused by `rand` 0.8 -> 0.7

* use `get_available_port()` for mixnet integration tests (#333)

* add missing comments

* Overwatch mixnet node (#339)

* Add mixnet service and overwatch app

* remove #[tokio::main]

---------

Co-authored-by: Youngjoon Lee <taxihighway@gmail.com>

* fix tests for the overwatch mixnode (#342)

* fix panic when corner case happen in RandomDelayIter (#335)

* Use `log` service for `mixnode` bin (#341)

* Use `wire` for MixnetMessage in libp2p (#347)

* Prevent tmixnet tests from running forever (#363)

* Use random delay when sending msgs to mixnet (#362)

* fix a minor compilation error caused by the latest master

* Fix run output fd (#343)

* add a connection pool

* Exp backoff (#332)

* move mixnet listening into separate task

* add exponential retry for insufficient peers in libp2p

* fix logging

* Fix MutexGuard across await (#373)

* Fix MutexGuard across await

Holding a MutexGuard across an await point is not a good idea.
Removing that solves the issues we had with the mixnet test

* Make mixnode handle bodies coming from the same source concurrently (#372)

---------

Co-authored-by: Youngjoon Lee <taxihighway@gmail.com>

* Move wait at network startup (#338)

We now wait after the call to 'subscribe' to give the network
the time to register peers in the mesh before starting to
publish messages

* Remove unused functions from mixnet connpool (#374)

* Mixnet benchmark (#375)

* merge fixes

* add `connection_pool_size` field to `config.yaml`

* Simplify mixnet topology (#393)

* Simplify bytes and duration range ser/de (#394)

* optimize bytes serde and duration serde

---------

Co-authored-by: Al Liu <scygliu1@gmail.com>
Co-authored-by: Daniel Sanchez <sanchez.quiros.daniel@gmail.com>
Co-authored-by: Giacomo Pasini <Zeegomo@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants