V24.0 Siglos is live

We are excited to release Nano node V24.0 Siglos on the live network! 

Alongside improving performance and stability, the updates in this version lay the foundation for future enhancements coming shortly after in V25.0, including a brand new bootstrapping algorithm: V24.0 implements the server side, with the remaining client side included in V25.

We therefore recommend that exchanges and services that are not facing issues of instability with their Nano node wait to upgrade to V25, which will encompass the full Ascending Bootstrapper.  

Key Upgrade Notices

This is a two-prong upgrade, services & exchanges who have not faced issues with your nano node, we recommend you save internal resources and await the arrival of V25.0 which will be within the next month (or so). 

There are no breaking changes, database migrations or other upgrade considerations for this release.

V24.0 should be a drop-in replacement for your current node, but as always thorough testing is highly recommended. 

In general, we encourage all exchanges, services and integrations to join the test network for performing integration testing. This network mimics the live network in work requirements but has a smaller number of nodes and a lower block count for easier setup.

Noteworthy Updates

Unit testing stability

One significant advancement for V24 is improved unit test stability and clarity. For a long time, we’ve had a discipline of including a unit test for each functional change added to the node. This discipline allows us to make more significant changes to the node while ensuring there aren’t regressions. Unfortunately over time, older unit tests were starting to fail intermittently, which was slowing down development progress.  

We took several weeks reviewing, documenting, and improving the node’s unit tests which has significantly aided subsequent development work.

Ascending bootstrap

V24 brings three major changes designed to improve bootstrap reliability:

1. We’ve added the ability for the bootstrap process to request blocks in ascending order. Doing this allows blocks to be inserted in their natural order, greatly decreasing reliance on the unchecked table.
   
   
2. We’ve created a new set of stateless bootstrap messages which allows bootstrap query/response to be sent through the node’s real-time socket. This also means the node doesn’t need to open secondary sockets in order to perform bootstrapping. Not needing to open additional sockets also allows nodes behind strict inbound firewalls to participate in bootstrapping.
   
   
3. We’re working on a new bootstrapping algorithm that is statistical and more randomised, making use of the above improvements. This algorithm will run continuously in the background, adjusting speed depending on sync status and will eventually supersede the legacy bootstrap algorithm.

Rebalancing buckets

In V23, we added the election scheduler process and set out an initial schedule of “buckets” in which transactions get prioritised for confirmation. This initial schedule uses powers of 2 from 0 to 128 to specify the lower bound for each bucket. This was a simple way to initially balance buckets but it needed refining to operate in the range of natural transactions. We’ve made an iterative improvement in this area, allowing our limited development resources to work on other advancements. 

In addition to rebalancing the scheduler buckets, we also adjusted the scheduling algorithm to consider both previous and subsequent balances. This addresses an issue with the scheduler where sending the full balance of an account would put the transaction in the lowest priority tier.

Hinted elections redesign

During a heavy spam attack, it’s possible that different nodes will observe the same blocks arriving at different times (for example, due to slow/fast hardware, network connection). This could negatively impact synchronisation of the election scheduler. Hinted elections is a mechanism that helps the standard scheduler get back on track.

A parallel election scheduling algorithm caches and looks at votes received from the network and starts elections for blocks that received the most voting weight and weren’t already prioritised by the standard election scheduler. The number of elections started via hinting is limited (by default 1000 vs 5000 for normal elections) and shouldn’t have an impact on normal elections, but helps the network stay in and get back to synchronised state faster.

Removal of UDP code

The nano protocol was originally written using UDP and later transitioned to TCP. The UDP server has been disabled for several versions however we still needed to maintain the UDP code because of its use in unit tests. Most of the unit tests have been rewritten and most of the UDP code removed.

Although this is a two-part upgrade, it’s a key part of the strategy for improving the overall performance and quality of service on the network over the long run. For a full rundown of the changes, head to the V24.0 Release Notes in our docs.

If you’re looking for even more granularity, we provide a complete changelog in GitHub of the 372 commits included in this release.

Binary builds can be found in the Build Options documentation and within GitHub release assets.

What to expect in V25.0

Ascending bootstrap client
A new bootstrapping client that makes use of message updates in V24 will be more reliable and performant.

Cleanup of submodules and C++20
The node code will be updated to use C++20. Several submodules will be updated to support this as well as cleaning up the compilation step which will simplify the build process.

Refactoring of subsystems
Several subsystems will be refactored and simplified: telemetry, backlog population, block processing.

The Nano Foundation team and community developers have been full steam ahead so far in 2023 - and long may it continue! If you would like to keep up to date with any upgrades or news relating to the Nano network itself, join the technical updates mailing list. 

We are always looking for contributions, whether they’re technical, community based or funding related. If you’re available to help, check out the relevant links below!

Technical Contributions >
Join the Community Programme >
Donate to the Development Fund >