Solidus is live on the Nano network

Nano Node v19 marches onto the main net

We are pleased to announce the release of the latest version of the Nano node software, in what is one of the most extensive protocol updates to date. Through a collection of significant updates and smaller targeted optimizations, Solidus brings the resilience and immutability necessary to foster trust and confidence in Nano as a leading digital currency.

The V19.0 release would not have been possible without our army of community beta-testers and contributors who have committed to providing the most efficient and comprehensive beta testing to date. Their work has been instrumental in ensuring that Solidus is well prepared for launch and we would like to extend our appreciation to all of the people involved in contributing to this release.

Before we get into the great features, there are some important upgrade considerations to call out. All node operators, services and exchanges integrating with Nano should closely review these details before upgrading.

Key upgrade considerations

Version Limits

Upgrades from versions V17.1 and earlier to V19 will involve a sequential database upgrade and impact participation of the node on the network. RPC calls will be unavailable for a long period of time amongst other impacts. It is highly recommended that nodes are upgraded to V18.0 first or a V18.0 ledger is acquired and used when upgrading to V19.0.

Confirmation tracking considerations

The addition of confirmation height to the database requires the node to validate that blocks are confirmed before the cementing can occur. This process can take up to 24 hours or longer to complete and will cause an increase in some resource usage, particularly network bandwidth increases, but won’t impact participation on the network. For integrations watching confirmations, the existing HTTP callback, block_confirm RPC and confirmation_history RPC methods will continue to function as before, however it is required that tracking of confirmed block hashes outside the node is done to avoid potential duplicate notifications from causing issues. This was a requirement in previous versions and remains the same with V19.

For those looking to utilize the new WebSocket confirmation subscription or new confirmed field in block_info RPC responses, special considerations should be taken if implementing before confirmation height updates are complete — find out more details see the V19.0 Release Notes.

Emitting nano_ prefixed addresses

In this and future versions, all addresses emitted from the node will use the nano_ prefix. It will continue to support input for xrb_ prefixed addresses, but all services must verify they are properly set up to handle the node outputting nano_ prefixed addresses.

Live network traffic over TCP

Live network traffic over TCP is now available and operates on the same port (7075 for main network, 54000 for beta network) as the bootstrapping network that was already available over TCP. Because of this, existing network setups that are open inbound and outbound on port 7075 for TCP should function as expected with V19.0. For those running production services, it is still recommended to verify network ports setup and consider setting up a new node on internal networks to ensure it can connect and participate on the main network before production nodes are upgraded. Details on checking this can be found in the V19.0 Release Notes under Upgrade Notices section.

Other items to review

New configuration options have been introduced to allow tuning of certain behaviors and resource usage on the node. This includes active elections size and bandwidth limiting along with some other potentially useful options to adjust. For details on these and other updates to RPC calls, CLI commands and more, review the V19.0 Release Notes.