Nym mixnet stability update
We would like to post an update detailing our persistent issues with the stability of the current v0.11.0 Nym testnet. Throughout nearly the entire development of NymDrive, we have experienced a wholly non-functional mixnet that would regularly drop connections, send incomplete data, or simply fail to connect altogether. The few times we managed to connect, we have rarely witnessed speeds faster than 5bkps. These mixnet stability issues were observed across the board by other participants of this hackathon challenge. These issues have fundamentally impaired NymDrive, and prevented it from working as intended. These issues are still present at this very moment.
Repeated attempts to workaround the issue
We have spent over 60 hours exclusively dedicated to finding a workaround to this issue to ensure a stable application for the end user.
Running our own mixnet
First, we have attempted to run our own v0.11.0 mixnet in the hopes that the testnet was unstable due to its public and open nature. This process involved:
- Running our own validators
- Running 3 separate mixnets, all on different machines with unique IP addresses
- Running our own gateway
- Running our own validator-api
- Running a Rocket webserver in order to access the nym web wallet
- Issuing ourselves the punk cryptocurrency on our private mixnet
- Using these punks to bond our mixnodes to the network
Every step of this process was entirely undocumented and completely outside of the bounds of what one would expect to need in order to participate in this hackathon. Nonetheless, we relented, and got every component to run, with the validator-api properly executing with the monitor enabled, which recognized our three mixnodes. Despite this apparent success, we faced the same issues, and were entirely unable to connect or send any packets through our private mixnet.
Running on the v0.10.1 mixnet
Following this failed attempt, we realized that the v0.10.1 mixnet was still up and running due to members of that network forgetting to upgrade their nodes. We presumed that the v0.10.1 might have far greater stability as it is no longer widely used by the network, which has largely moved on to the newer v0.11.0 release. We therefore attempted to switch to this mixnet in hopes that it could address our issues. This involved:
- Rebuilding the entire nym repository with all components when checked out on the v0.10.1 tag
- Patching the v0.10.1 branch to use a newer cryptography library, as this version depended on a crate that was yanked for security reasons
- Rebuilding and patching nym-duplex to work with the v0.10.1 version
- Probing the network for valid gateway IDs
- Rerunning our entire backend infrastructure to use the older version
Despite this valiant attempt, we were unsuccessful, and failed to route any packets through the older mixnet.
Using the private QA testnet
In a last ditch effort, with all prior attempts failing, we decided to try and use the Nym team's Quality Assurance testnet that was running the latest bleeding edge Nym code. This QA mixnet isn't supposed to be public, but we found it by digging through the DNS records of the nymtech.net domain. This, yet again, required rebuilding everything to use the latest commits in the develop branch to ensure compatibility. Unfortunately, this attempt was also unsuccessful, as we did not have access to some internal information that would have allowed us to successfully connect to this QA testnet.
Mixnet toggle
Finally, despite our best efforts, we resolved to simply add an option within the GUI that disables the mixnet, and simply routes traffic directly to the server. This allowed for more reliable testing, and hopefully can be used to provide the reviewers with an opportunity to test our code even if the mixnet isn't properly routing traffic. We pursued every possible opportunity we could think of before resorting to making this change.
Log in or sign up for Devpost to join the conversation.