Nym Testnet - Up and Running
During the Chaos Communication Congress a few weeks ago, a group of people downloaded and built the initial version (0.1.0) of the Nym platform. Along with some other friendly souls, they became the proud operators of the brand new Nym testnet.
A bit of backstory.
The Nym mixnet will (eventually) be able to protect network privacy even against very strong attackers. It masks metadata to make it difficult or impossible to see who is communicating with who.
We have had a stable mixnet running in Go since October, but we weren’t happy with its performance. During the course of November and December, we rebuilt it in Rust to speed up cryptographic operation in Sphinx packet processing, and saw some very gratifying performance benefits. But we hadn’t yet tested out the new Rust code in any serious way.
As a result, the testnet deployment was a little stressful for me. I’m used to working in environments where a few minutes downtime is a big disaster. But our testnet was cooked for days while prior social commitments meant that our whole coding team unavoidably ate and drank our way through the Christmas holidays!
The biggest unexpected problem we had? IPv6. Unprompted, roughly half of the mixnode operators spontaneously chose to run their nodes using the internet’s new format. This makes sense: who wants to go begging to ISPs to try and snaffle up the limited remaining number of IPv4 addresses when there is a whole universe of freely available IPv6 addresses just waiting to be used?
We hadn’t paid consistent attention to IPv6 within our codebase, but we figured IPv6 was a fine idea. So early in the new year we built a new version (0.2.0) and released it quickly, to ensure that nodes and users could talk to each other. IPv6 is now fully supported within the Nym platform, and the overall system is also much smarter about directory services.
But there was another problem relating to IPv6: a large majority of ISPs in the UK (where we develop much of our code) don’t support it. I was shocked by this. We have bendy laptops, brain-interfaced prosthetic limbs, and kick-ass Ripley-style exoskeletons, but I can’t route IPv6 from home? What kind of crap future am I living in?
Anyway, the solutions are pretty simple. Layer 1 mixnodes, which clients communicate with directly, are going to need to talk IPv4 so that nobody gets penalized for either the forward-thinking nature of our testnet operators or the embarrassing slackness of the world’s ISPs.
Other nodes, i.e. in layers 2 and 3, can speak either IPv4 or IPv6. Node operators in each layer will need to ensure that their nodes can communicate with the nodes upstream downstream of them.
We are also doing two other things to ensure network health and reliable packet delivery.
First, we’re taking far more care with version numbers. Every node now self-reports its own version number, so that clients can be sure to pick compatible node paths. This will be very important for reliability: in long-running production deployments, it may be the case that some mixnet users run older client software versions and are unable to upgrade them. They’ll need to be able to choose from nodes that can support them.
Second, we’ve built a new health-check system to start measuring the overall health of the mixnet, and automatically find problems within the network so that clients can intelligently route around damaged mixnet segments.
This health-check system is primitive right now — but it will eventually form the basis of our mix-mining and incentives system, so it’s a cool bit of code to be working on. More on that later.
This is a big milestone for us, and we’re all really excited about it. Thanks to everyone who’s participating in our growing community of nodes!
Anyway, the solutions are pretty simple.
Layer 1 nodes, the ones at the front of the mixnet topology which clients communicate with directly, are going to need to talk IPv4 so that nobody gets penalized for either the forward-thinking nature of our testnet operators or the embarrassing slackness of the world’s ISPs. Other nodes, i.e. in layers 2 and 3, can speak either IPv4 or IPv6. Node operators in each layer will need to ensure that their nodes can communicate with the nodes downstream of them.
We are also doing two other things to ensure network health and reliable packet delivery.
First, we’re taking far more care with version numbers. Every node in the system now self-reports its own version number, so that clients can be sure to pick node paths using compatible nodes. This will be very important for reliability: in long-running production deployments, it may be the case that some mixnet users run older client software versions and are unable to upgrade them. They’ll need to be able to choose from nodes that can support them.
Second, we’ve built a new health-check system to start measuring the overall health of the mixnet, and automatically find problems within the network so that clients and mixnodes can respond intelligently and route around damaged mixnet segments. If a node becomes unavailable due to network problems, the health-check system will detect the problem, and the client will avoid that path through the mixnet.
This health-check system will eventually form the basis of our mix-mining capability and incentives system, so it’s a cool bit of code to start working on. More on that later.
This is a big milestone for us, and we’re all really excited about it. Thanks to everyone who’s participating in our growing community of nodes!