Why Nano node versions matter

There is no single "latest Nano version". Two independent node programs run the same network with unrelated version numbers, so V28.2 and V3.1 are both current releases. Comparing them as numbers is meaningless.

Two node makes, one network

A Nano node is any program that speaks the Nano protocol. Two are in wide use, and a representative may run either:

• The C++ node, the original reference implementation, currently at V28.2. Most of the network runs this.
• The Rust node, RsNano, a Rust port of the C++ node maintained as its own project, currently at V3.1. It numbers its own releases from scratch, which is why its version is so much lower.

A node reporting V3.1 is not behind one reporting V28.2. It is a different program, and it is up to date.

That is why NanoTicker scores each node against the newest release of its own make, and why the versions page tags both current releases as "Latest".

Why more than one node program is a good thing

If every node runs identical software, every node shares its bugs. One defect could halt the whole network at once, and software diversity is the standard defense.

RsNano is a port, not a clean-room rewrite, so the two share design decisions and a reading of the protocol, and a flaw there could hit both. What differs is the implementation: the memory model, the libraries, the concurrency, and the bugs that live in them. Real protection, but not total protection.

The cost is that both must read the protocol identically. That is demanding work, and a genuine disagreement between them would be serious.

Why running an old version matters

Node releases carry protocol fixes, performance work and changes to how nodes talk to each other. A rep left on an old release is not just missing improvements:

• It may confirm blocks more slowly, which slows the whole network down.
• It may fall behind on cementing, leaving a backlog of unconfirmed blocks.
• It may miss a fix other nodes already have, making it the weak point in an outage.

A rep's influence is its voting weight, so one large rep on an old release is a bigger problem than a dozen small ones. The versions page shows the split by weight as well as by node count, and the two can look very different.

How the data is collected

Nodes broadcast a telemetry message describing themselves: version, peer count, ledger size and more. NanoTicker reads what reps broadcast, so everything on the versions page is self-reported.

Some nodes report nothing. These show as Unknown, meaning no telemetry arrived, not an old version. A node reporting none is left unrated rather than scored on its version, so a missing reading is never read as an old one. Pre-release builds are left out of the "on latest" figure too: a release candidate is not a release.

Watching upgrades roll out

When a release ships, weight moves onto it over days or weeks, and the pace says a lot about how actively the network is maintained. NanoTicker records version changes as they happen and lists recently updated nodes under the version breakdown.

A rep that upgrades promptly is one someone is paying attention to, which is one of the six inputs to its health score.